agp/intel_gtt.c and drm/i915/i915_dma.c don't calculate this the same
way: The intel-gtt code seems to use the actual gtt size, the drm
module just the mappable. Go with the logic from the drm module because
that's the more conservative choice.
But conserve the original code in intel_gtt_total_size for later use.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The dedection function in drm/i915/i915_dma.c works without it, so
drop it here, too. All the values are disdinct, anyway.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This somewhat aligns it with the version in drm/i915/i915_dma.c.
Changes:
- s/gtt_entries/stolen_size
- track overhead entries in a seperate var (the effective gtt size
calculation will be extracted later on).
- subtract the overhead at the end instead of in each clause.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This uses the new mappable gtt size detection from the previous patch.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This implementation is stolen from drm/i915, but is equivalent to
the code sprinkled over intel-gtt.c in the various fetch_size functions.
It's not yet used anywhere, though.
Also introduce intel_gtt_init which only calls intel_gtt_stolen_entries.
Over the course of the next patches, this will grow untill it contains
the complete init sequence starting from the call to gtt_mappable_entries.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
First simple step towards a more generic initialization. This
is needed to disentangle the agp stuff from the stuff that is
actually needed by drm/i915.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When the intel-gtt code now longer depends on agp, we cannot rely
on this. So store a local reference in intel-gtt.c.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Add a few definitions to it that are already shared and that will
be shared in the future (like the number of stolen entries).
No functional changes in here.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Now that the disentangling is complete, stop including intel-gtt.c
from intel-agp.c.
The linux build system _really_ doesn't allow .c source files with the
same name as the module. It fails with the following message when trying
to build such a bugger:
make[3]: Circular drivers/char/agp/intel-agp.o <- drivers/char/agp/intel-agp.o dependency dropped.
Instead of renameing intel-agp.c I've simply created a new module out
of intel-gtt.c. Renaming intel-agp.ko to something else is not an option
for it will surely kill someones boot process.
This also paves the way to use the gtt code without loading the agp
driver.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This just splits the device list into two and moves the gtt related stuff
to intel-gtt.c. The two new devices lists also lose the not longer needed
fields. There where only about 5 cases anyway with both a gmch and a
possible agp port, so the duplication of entries is rather small.
Additionally kill 2 out of the three Ironlake mobile entries that
only differed in host bridge pci id.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
New pci ids for GT2 and GT2+ on desktop and mobile sandybridge,
and graphics device ids for server sandybridge. Also rename original
ids string to reflect GT1 version.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: stable@kernel.org
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Sandybridge GTT has new cache control bits in PTE, which controls
graphics page cache in LLC or LLC/MLC, so we need to extend the mask
function to respect the new bits.
And set cache control to always LLC only by default on Gen6.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: stable@kernel.org
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
It should shift bit 39-32 into pte's bit 11-4.
Reported-by:Takashi Iwai <tiwai@suse.de>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: stable@kernel.org
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Make sure we always detect when we fail to correctly allocate the Isoch
Flush Page and print an error to warn the user about the likely memory
corruption that will result in invalid rendering or worse.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Some BIOSes will claim a large chunk of stolen space. Unless we
reclaim it, our aperture for remapping buffer objects will be
constrained. So clamp the stolen space to 32M and ignore the rest.
Fixes https://bugzilla.kernel.org/show_bug.cgi?id=15469 among others.
Adding the ignored stolen memory back into the general pool using the
memory hotplug code is left as an exercise for the reader.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Simon Farnsworth <simon.farnsworth@onelan.com>
Tested-by: Artem S. Tashkinov <t.artem@mailcity.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
A side-effect of being able to use custom page allocations with the
sg_table is that it cannot reap the partially constructed scatterlist if
fails to allocate a page. So we need to call sg_free_table() ourselves
if sg_alloc_table() fails.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc Dave Airlie <airlied@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
[anholt: Split this patch out of a larger patch for Sandybridge fixes]
Signed-off-by: Eric Anholt <eric@anholt.net>
When "onboard video memory" is set do "disabled" in BIOS on Asus P4P800-VM
board (i865G), kernel oopses with memory corruption:
https://bugs.freedesktop.org/show_bug.cgi?id=28430
Fix that by cleanly aborting the initialization.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
BugLink: https://bugs.launchpad.net/bugs/597075
commit f1befe71fa introduced a
regression when detecting aperture size of some i915 adapters, e.g.,
those on the Intel Q35 chipset.
The original report: https://bugzilla.kernel.org/show_bug.cgi?id=15733
The regression report: https://bugzilla.kernel.org/show_bug.cgi?id=16294
According to the specification found at
http://intellinuxgraphics.org/VOL_1_graphics_core.pdf, the PCI config
space register I830_GMCH_CTRL is a mirror of GMCH Graphics
Control. The correct macro for isolating the aperture size bits is
therefore I830_GMCH_GMS_MASK along with the attendant changes to the
case statement.
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Tested-by: Kees Cook <kees.cook@canonical.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Eric Anholt <eric@anholt.net>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
References:
Bug 15733 - Crash when accessing nonexistent GTT entries in i915
https://bugzilla.kernel.org/show_bug.cgi?id=15733
On G33 and above, the size of the GTT space is determined by the GMCH
control register. Prior to this revision, the size is determined by the
size of the aperture. So we must careful to map and fill the appropriate
range depending on chipset.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
Not needed for the GTT and inconsistent: Sometimes the _new_ size
was stored there ...
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
We don't use the generic insert/remove_memory functions that
require this. So kill this useless code.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
intel-agp.c contains actually two different drivers: An agp driver
for _physical_ agp slots an the gtt driver that is used by the intel
drm modules. Split them to prevent any further confusion.
This patch just moves the code and includes intel-gtt.c in intel-agp.c
Later patches will untangle these two drivers further.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
Daniel Vetter