Re: [git pull] AGP patches for 2.6.28-rc4

From: Dave Airlie
Date: Thu Nov 06 2008 - 01:52:08 EST


On Thu, Nov 6, 2008 at 4:46 PM, Dave Airlie <airlied@xxxxxxxx> wrote:
> Hi Linus,
>
> Please pull the 'agp-fixes' branch from
> git://master.kernel.org/pub/scm/linux/kernel/git/airlied/agp-2.6.git agp-fixes

Actually Linus please skip this, we really want this PAE patch in but
I suspect I will need
to do more widespread changes than this patch does :(

Dave.

>
> This contains two fixes,
>
> oops fix: intel g33 fix for 1MB aperture setting
>
> PAE kernel + AGP + GEM fix. The patch contains more explaination, but
> since GEM uses shmem to allocate pages it can pass highmem pages into AGP,
> AGP just needs to pass those addressess around cleanly in dma_addr_t. The
> correct answer is to use struct page *, but that is way too invasive for
> this stage of a kernel release.
>
> Dave.
>
> drivers/char/agp/agp.h | 8 ++++----
> drivers/char/agp/efficeon-agp.c | 2 +-
> drivers/char/agp/generic.c | 15 ++++++---------
> drivers/char/agp/hp-agp.c | 2 +-
> drivers/char/agp/i460-agp.c | 2 +-
> drivers/char/agp/intel-agp.c | 11 +++++++++--
> drivers/char/agp/parisc-agp.c | 2 +-
> drivers/char/agp/sgi-agp.c | 2 +-
> drivers/gpu/drm/drm_memory.c | 3 ++-
> drivers/gpu/drm/drm_vm.c | 4 ++--
> include/linux/agp_backend.h | 4 ++--
> 11 files changed, 30 insertions(+), 25 deletions(-)
>
> commit d5e4cc00c911a72709a8d012179980a6157ba552
> Author: Brandon Philips <bphilips@xxxxxxx>
> Date: Tue Oct 28 22:22:18 2008 -0700
>
> intel-agp: Avoid oops for G33 on 1MB stolen case
>
> This is similar to f443675affe3f16dd428e46f0f7fd3f4d703eeab which was
> reverted because it broke older X.org driver. This patch only fixes
> the 1MB stolen case since it causes an oops.
>
> Xorg will not work without the accompanying patch[1] but avoiding an
> oops and making it possible to work with patched xorg driver is
> reasonable.
>
> [1] http://ifup.org/~philips/review/xf86-video-intel-G33-1mb.patch
>
> Explanation of the oops:
>
> > static void intel_i830_init_gtt_entries(void)
> ...
> > } else if (IS_G33) {
> > /* G33's GTT size defined in gmch_ctrl */
> > switch (gmch_ctrl & G33_PGETBL_SIZE_MASK) {
> > case G33_PGETBL_SIZE_1M:
> > size = 1024;
> > break;
> ...
> > size += 4;
>
> size = 1028
>
> Then since we have the BIOS setting 1MB for the device in the GMCH
> control we get to here:
>
> > } else {
> > switch (gmch_ctrl & I855_GMCH_GMS_MASK) {
> > case I855_GMCH_GMS_STOLEN_1M:
> > gtt_entries = MB(1) - KB(size);
> > break;
>
> MB(1) = 1 * 1024 * 1024
> KB(1028) = 1028 * 1024
>
> MB(1) - KB(1028) = -4096
>
> > gtt_entries /= KB(4);
> > intel_private.gtt_entries = gtt_entries;
>
> We end up with -1 in gtt_entries.
>
> This leads to intel_i915_configure reading/writing to areas outside of
> mapped memory and the oops.
>
> Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=391261
>
> Signed-off-by: Brandon Philips <bphilips@xxxxxxx>
> Signed-off-by: Dave Airlie <airlied@xxxxxxxx>
>
> commit b4f5dfa4b12efeea816a6f16ddb4c8851adbd39a
> Author: Pierre Willenbrock <pierre@xxxxxxxxxx>
> Date: Mon Nov 3 21:14:56 2008 -0800
>
> agp: change physical address type from unsigned long to dma_addr_t
>
> This fixes enough of the interface for i915 DRM with CONFIG_HIGHMEM64. It
> doesn't fix the physical addresses when passed to intelfb, mtrr or userspace.
>
> airlied: This patch is sufficent to fix GEM use cases, we should overhaul AGP
> later to make it use struct page *, instead of this. AGP allocated pages are
> safe because we never use highmem pages, GEM allocated pages never use
> virt_to_*.
>
> Signed-off-by: Pierre Willenbrock <pierre@xxxxxxxxxx>
> Signed-off-by: Eric Anholt <eric@xxxxxxxxxx>
> Signed-off-by: Dave Airlie <airlied@xxxxxxxx>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/