... and switch to a more classical store-reg-on-suspend, restore-on-resume
way of doing things. Obviously this is just preparation for the future,
the code is not there at all, yet.
This is needed because the next patch adjusts this register and everything
in it (not just the pagetable address) needs to be restored on resume.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In cleaning up the mask functions in bdd3072, the setting of the PTE
valid bit was dropped for Sandybridge.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In commit e517a5e970 the call to
map_page_into_agp() got removed from intel_i830_setup_flush(), but the
counterpart call from intel_i830_fini_flush() to unmap_page_from_agp()
was left in place.
Additionally, the page allocated here never gets its physical address
used for sending to hardware, so there's no need to allocate it with
GFP_DMA32. Nor is __GFP_ZERO really necessary, as the page is used
only to store data to force flushing of some internal processor state.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Cc: Eric Anholt <eric@anholt.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The old code didn't clean up the i830 chipset flush page. And it
looks nicer.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Storing this explicitly makes for clearer code and hopefully
less further confusion.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Consolidate everything in intel-gtt.c and also kill the export
of intel_max_stolen.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This is the last differentiator between the different fake agp drivers.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
That indirection mess can now go. Add a dummy i81x gtt_driver to
avoid a NULL pointer check.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Like before, but now with the added bonus of being able to kill
quite a bit of no-longer userful code (the old dmar support stuff).
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Beef up the generic version to support dmar. Otherwise like for the i830.
v2: Don't try to DMA remap on resume for already remapped pages.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Well, not all too generic because it does not yet support dmar.
Add a new function check_flags to ensure that non-gem code does
not try to screw us over.
v2: Beautify i830_check_flags with an idea from Chris Wilson.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
intel-gtt.c now handles the scratch page itself, so drop all that
was just there to support it.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Like for i830. intel_i9xx_configure is now unused, so kill it.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
And put it to use in the gtt configuration code that writes
the scratch page addr in all gtt ptes. This makes intel_i830_configure
generic, hence rename it to intel_fake_agp_configure.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The intel gtt fake agp driver is the only agp driver to use dma
address remapping. So it makes sense to fold this code back into the
only user (and thus reduce the reliance on the agp code).
This patch does the first step by initializing (and remapping) the
scratch page in a new function intel_gtt_setup_scratch_page.
Unfortunately intel_gtt_cleanup had to move to avoid a forward
declaration. The new scratch page is not yet used, though.
v2: Refactor out scratch page teardown. Suggested by Chris Wilson on
irc. This makes it clear what's going on and results in a nice
symmetry between setup and teardown.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
On i915 [EeePCs] something scribles over the registers during suspend
and resume so we must save a copy of the PGETBL_CTL register programmed
by the BIOS and restore that upon resume.
Reported-by: Sitsofe Wheeler <sitsofe@yahoo.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Use the detection from intel-gtt.ko instead. Hooray!
Also move the stolen mem allocator to the other gtt stuff in dev_prv->mem.
v2: Chris Wilson noted that my error handling was crap. Fix it. He also
said that this fixes a problem on his i845. Indeed, i915_probe_agp
misses a special case for i830/i845 stolen mem detection.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=25476
Cc: stable@kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This way create_gatt_table become dummy glue functions for the fake
agp driver - rename them accordingly (and kill the now unnecessary
i9xx copy).
With this change, the gtt initialization code is almost independant
from the agp stuff. Two things are still missing:
- the scratch page is created by the generic agp code.
- filling the whole gtt with scratch_page ptes is not yet consolidated -
this needs abstracted pte handling, first.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The only difference between i915 and i965 was the calculation of the
gtt address. So merge these two paths into one. Otherwise the same
changes as in the i830 setup consolidation.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Slighlty reordered sequence was necessary. Also don't set
agp_bridge->gatt_bus_addr anymore. Only used by generic agp helper
functions, hence unnecessary for the intel fake agp driver.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This way around this can be extracted into common code.
Also use a common cleanup function (and give it a generic name).
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Also move the Sandybdridge size detection into gtt_total_entries, like
the rest.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Slight reordering of the init sequence required.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Same idea as INTEL_INFO from drm/i915. This
- reduces the dependancy on agp_driver
- stops the what-does-IS_I965G-mean confusion (here it's just gen4, in
drm/i915 it's gen >=4)
- further prepares the separation of the fake agp driver from the rest.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In commit f1befe71 Chris Wilson added some code to clear the full gtt
on g33/pineview instead of just the mappable part. The code looks like
it was copy-pasted from agp/intel-gtt.c, at least an identical piece
of code is still there (in intel_i830_init_gtt_entries). This lead to
a regression in 2.6.35 which was supposedly fixed in commit e7b96f28
Now this commit makes absolutely no sense to me. It seems to be
slightly confused about chipset generations - it references docs for
4th gen but the regression concerns 3rd gen g33. Luckily the the g33
gmch docs are available with the GMCH Graphics Control pci config
register definitions. The other (bigger problem) is that the new
check in there uses the i830 stolen mem bits (.5M, 1M or 8M of stolen
mem). They are different since the i855GM.
The most likely case is that it hits the 512M fallback, which was
probably the right thing for the boxes this was tested on.
So the original approach by Chris Wilson seems to be wrong and the
current code is definitely wrong. There is a third approach by Jesse
Barnes from his RFC patch "Who wants a bigger GTT mapping range?"
where he simply shoves g33 in the same clause like later chipset
generations.
I've asked him and Jesse confirmed that this should work. So implement
it.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=16891$
Tested-by: Anisse Astier <anisse@astier.eu>
Cc: stable@kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Start to separate the fake agp driver from the rest of intel-gtt.c
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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>
