Re: Regression in i915 on 2.6.34-rc1
On Sun, 2010-03-21 at 18:19 -0600, Pete Zaitcev wrote: On Wed, 17 Mar 2010 08:26:59 -0700 Bjorn Helgaas bjorn.helg...@hp.com wrote: http://bugzilla.kernel.org/show_bug.cgi?id=15533 Any luck testing the patch from the bugzilla? I'd really like to get this figured out so we can get the fix in the next -rc and move on to the next _CRS issue :-) I was on vacation, sorry. Got to it today. In short, the test patch fails. Please see the dmesg with ACPI debugging in bugzilla as requested. Ping! If you haven't seen the last bugzilla update, I'd really like an acpidump and some details about what machine this is. Thanks, Bjorn -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Regression in i915 on 2.6.34-rc1
On Monday 15 March 2010 11:51:01 am Bjorn Helgaas wrote: On Saturday 13 March 2010 08:02:24 pm Bjorn Helgaas wrote: On Sat, 2010-03-13 at 13:46 -0700, Pete Zaitcev wrote: On Fri, 12 Mar 2010 22:37:56 -0700 Bjorn Helgaas bjorn.helg...@hp.com wrote: Thanks for the report. Would you mind posting the entire dmesg log, /proc/iomem contents, and lspci -vv output somewhere (maybe in bugzilla)? Done, new bug: http://bugzilla.kernel.org/show_bug.cgi?id=15533 Any luck testing the patch from the bugzilla? I'd really like to get this figured out so we can get the fix in the next -rc and move on to the next _CRS issue :-) Bjorn -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Regression in i915 on 2.6.34-rc1
On Saturday 13 March 2010 08:02:24 pm Bjorn Helgaas wrote: On Sat, 2010-03-13 at 13:46 -0700, Pete Zaitcev wrote: On Fri, 12 Mar 2010 22:37:56 -0700 Bjorn Helgaas bjorn.helg...@hp.com wrote: Thanks for the report. Would you mind posting the entire dmesg log, /proc/iomem contents, and lspci -vv output somewhere (maybe in bugzilla)? Done, new bug: http://bugzilla.kernel.org/show_bug.cgi?id=15533 Thanks! Sorry, I should have asked for the pci=nocrs (working) dmesg, too. Do you have that handy? What kind of machine is this? I don't suppose you have Windows on it; I'd really like to know what the Device Manager says about the PCI host bridge and graphics controller resources. I added two patches to the bugzilla: http://bugzilla.kernel.org/attachment.cgi?id=25522 (possible fix) http://bugzilla.kernel.org/attachment.cgi?id=25523 (additional debug) If the first patch fixes it, we're all set. If it doesn't, I'd like the additional debug info from the second patch. Thanks! Bjorn -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Regression in i915 on 2.6.34-rc1
On Fri, 2010-03-12 at 23:40 -0700, Pete Zaitcev wrote: On Fri, 12 Mar 2010 22:37:56 -0700 Bjorn Helgaas bjorn.helg...@hp.com wrote: Thanks for the report. Would you mind posting the entire dmesg log, /proc/iomem contents, and lspci -vv output somewhere (maybe in bugzilla)? The quote below isn't enough for me to see the problem, but http://bugzilla.kernel.org/show_bug.cgi?id=15480 is another regression related to this commit. [] Do you prefer me to attach the requested data to Yanko's bug, or file a new one for now? Personally, I guess I'd file a new one, on the assumption that you're seeing a different problem. Bjorn -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Regression in i915 on 2.6.34-rc1
On Sat, 2010-03-13 at 13:46 -0700, Pete Zaitcev wrote: On Fri, 12 Mar 2010 22:37:56 -0700 Bjorn Helgaas bjorn.helg...@hp.com wrote: Thanks for the report. Would you mind posting the entire dmesg log, /proc/iomem contents, and lspci -vv output somewhere (maybe in bugzilla)? Done, new bug: http://bugzilla.kernel.org/show_bug.cgi?id=15533 Thanks! Sorry, I should have asked for the pci=nocrs (working) dmesg, too. Do you have that handy? What kind of machine is this? I don't suppose you have Windows on it; I'd really like to know what the Device Manager says about the PCI host bridge and graphics controller resources. Bjorn -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Regression in i915 on 2.6.34-rc1
On Fri, 2010-03-12 at 22:37 -0700, Bjorn Helgaas wrote: On Fri, 2010-03-12 at 18:25 -0700, Pete Zaitcev wrote: On Thu, 11 Mar 2010 00:33:58 -0700, Pete Zaitcev zait...@redhat.com wrote: I apologise for answering to myself, but while there was no answer, git bisect found the offending commit and I verified that it was the culprit. Also, I am adding Bjorn and Jesse to cc:. I seem to hit a sudden regression in 2.6.34-rc1: the modeset fails. On this box it also means, no way to start X, which is unfortunate. Oh, and I forgot to mention: booting with pci=nocrs should be a workaround while we figure out the problem. Bjorn -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Regression in i915 on 2.6.34-rc1
On Fri, 2010-03-12 at 18:25 -0700, Pete Zaitcev wrote: On Thu, 11 Mar 2010 00:33:58 -0700, Pete Zaitcev zait...@redhat.com wrote: I apologise for answering to myself, but while there was no answer, git bisect found the offending commit and I verified that it was the culprit. Also, I am adding Bjorn and Jesse to cc:. I seem to hit a sudden regression in 2.6.34-rc1: the modeset fails. On this box it also means, no way to start X, which is unfortunate. Thanks for the report. Would you mind posting the entire dmesg log, /proc/iomem contents, and lspci -vv output somewhere (maybe in bugzilla)? The quote below isn't enough for me to see the problem, but http://bugzilla.kernel.org/show_bug.cgi?id=15480 is another regression related to this commit. There are some patches for that one here: http://lkml.org/lkml/2010/3/11/512, but without knowing more about the problem you're seeing, I don't want to waste your time trying them. Bjorn Here's a quote from bad dmesg (truncated front and back for brievity): Linux agpgart interface v0.103 agpgart-intel :00:00.0: Intel HD Graphics Chipset agpgart-intel :00:00.0: detected 131068K stolen memory agpgart-intel :00:00.0: AGP aperture is 256M @ 0xd000 tpm_tis 00:09: 1.2 TPM (device-id 0xB, rev-id 16) Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled udev: starting version 151 [drm] Initialized drm 1.1.0 20060810 i915 :00:02.0: PCI INT A - GSI 16 (level, low) - IRQ 16 i915 :00:02.0: setting latency timer to 64 alloc irq_desc for 33 on node -1 alloc kstat_irqs on node -1 i915 :00:02.0: irq 33 for MSI/MSI-X [drm] set up 127M of stolen space [drm:i915_gem_init_ringbuffer] *ERROR* Ring head not reset to zero ctl head tail start [drm:i915_gem_init_ringbuffer] *ERROR* Ring head forced to zero ctl head tail start [drm:i915_gem_init_ringbuffer] *ERROR* Ring initialization failed ctl head tail start [drm:i915_driver_load] *ERROR* failed to init modeset i915: probe of :00:02.0 failed with error -5 dracut: Starting plymouth daemon ... The commit follows appended. It's possible that the BIOS on this motherboard is not up to snuff, but the 2.6.33-rc8 worked fine, so clearly Linux can do it... right? Cheers, -- Pete commit 7bc5e3f2be32ae6fb0c74cd0f707f986b3a01a26 Author: Bjorn Helgaas bjorn.helg...@hp.com Date: Tue Feb 23 10:24:41 2010 -0700 x86/PCI: use host bridge _CRS info by default on 2008 and newer machines ... -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] DRM: add missing pci_enable_device()
On Monday 13 September 2004 5:28 pm, Dave Airlie wrote: This causes problems when DRI and fb are loaded and you unload dri.. guess what happens your fb??, or it does in theory I might have time to practice later, now the quick fix is to take the stealth/non-stealth code from CVS which we know works or we wait for Alan to finish his vga device code and we fix up the DRM and fb to use it ... this patch won't help anyways... OK, I'll assume you understand the issue and will resolve it. In the meantime, users of DRM will have to supply pci=routeirq. On Mon, 13 Sep 2004, Bjorn Helgaas wrote: Add pci_enable_device()/pci_disable_device. In the past, drivers often worked without this, but it is now required in order to route PCI interrupts correctly. Evan Paul Fletcher found this problem with 2.6.9-rc1-mm4 and X.org 6.8.0 and verified that this patch fixes it. Signed-off-by: Bjorn Helgaas [EMAIL PROTECTED] = drivers/char/drm/drm_drv.h 1.47 vs edited = --- 1.47/drivers/char/drm/drm_drv.h 2004-09-08 03:41:23 -06:00 +++ edited/drivers/char/drm/drm_drv.h 2004-09-13 12:27:16 -06:00 @@ -443,6 +443,8 @@ } up( dev-struct_sem ); + pci_disable_device( dev-pdev ); + return 0; } @@ -492,6 +494,9 @@ return -EPERM; dev-device = MKDEV(DRM_MAJOR, dev-minor ); dev-name = DRIVER_NAME; + + if ((retcode = pci_enable_device(pdev))) + return retcode; dev-pdev = pdev; #ifdef __alpha__ -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] DRM: add missing pci_enable_device()
Add pci_enable_device()/pci_disable_device. In the past, drivers often worked without this, but it is now required in order to route PCI interrupts correctly. Evan Paul Fletcher found this problem with 2.6.9-rc1-mm4 and X.org 6.8.0 and verified that this patch fixes it. Signed-off-by: Bjorn Helgaas [EMAIL PROTECTED] = drivers/char/drm/drm_drv.h 1.47 vs edited = --- 1.47/drivers/char/drm/drm_drv.h 2004-09-08 03:41:23 -06:00 +++ edited/drivers/char/drm/drm_drv.h 2004-09-13 12:27:16 -06:00 @@ -443,6 +443,8 @@ } up( dev-struct_sem ); + pci_disable_device( dev-pdev ); + return 0; } @@ -492,6 +494,9 @@ return -EPERM; dev-device = MKDEV(DRM_MAJOR, dev-minor ); dev-name = DRIVER_NAME; + + if ((retcode = pci_enable_device(pdev))) + return retcode; dev-pdev = pdev; #ifdef __alpha__ --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [PATCH] ati_pcigart: support 16K and 64K page size
This adds support for 16K and 64K system page sizes. # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet1.660 - 1.661 # drivers/char/drm/ati_pcigart.h 1.6 - 1.7 # # The following is the BitKeeper ChangeSet Log # # 02/09/14 [EMAIL PROTECTED]1.661 # Add 64K 16K page size support to ati_pcigart.h # # diff -Nru a/drivers/char/drm/ati_pcigart.h b/drivers/char/drm/ati_pcigart.h --- a/drivers/char/drm/ati_pcigart.hSat Sep 14 15:26:54 2002 +++ b/drivers/char/drm/ati_pcigart.hSat Sep 14 15:26:54 2002 @@ -29,14 +29,20 @@ #include drmP.h -#if PAGE_SIZE == 8192 +#if PAGE_SIZE == 65536 +# define ATI_PCIGART_TABLE_ORDER 0 +# define ATI_PCIGART_TABLE_PAGES (1 0) +#elif PAGE_SIZE == 16384 +# define ATI_PCIGART_TABLE_ORDER 1 +# define ATI_PCIGART_TABLE_PAGES (1 1) +#elif PAGE_SIZE == 8192 # define ATI_PCIGART_TABLE_ORDER 2 # define ATI_PCIGART_TABLE_PAGES (1 2) #elif PAGE_SIZE == 4096 # define ATI_PCIGART_TABLE_ORDER 3 # define ATI_PCIGART_TABLE_PAGES (1 3) #else -# error - PAGE_SIZE not 8K or 4K +# error - PAGE_SIZE not 64K, 16K, 8K or 4K #endif # define ATI_MAX_PCIGART_PAGES 8192/* 32 MB aperture, 4K pages */ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [PATCH] AGPGART 1/5: minor DRM interface cleanup
This cleans up the GART/DRM interface (in a backwards-compatible
way) and gets rid of the bogus assumption that GATT_entry ~0xfff
is a physical address.
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.686 - 1.687
# drivers/char/agp/agpgart_be.c 1.35- 1.36
# drivers/char/agp/agp.h 1.18- 1.19
#
# The following is the BitKeeper ChangeSet Log
#
# 02/09/27 [EMAIL PROTECTED]1.687
# Make agp_memory.memory[] (exported from agpgart to DRM) contain physical
# addresses, not GATT entries.
#
# DRM assumes agp_memory contains GATT entries, and it converts them to
# physical addresses with paddr = agp_memory.memory[i] mask. 460GX
# requires both a shift and a mask, so exporting plain physical addresses
# and a mask of ~0UL allows agpgart to add 460GX support without requiring
# DRM interface changes.
#
#
diff -Nru a/drivers/char/agp/agp.h b/drivers/char/agp/agp.h
--- a/drivers/char/agp/agp.hFri Sep 27 20:59:30 2002
+++ b/drivers/char/agp/agp.hFri Sep 27 20:59:30 2002
@@ -87,6 +87,7 @@
u32 *gatt_table;
u32 *gatt_table_real;
unsigned long scratch_page;
+ unsigned long scratch_page_real;
unsigned long gart_bus_addr;
unsigned long gatt_bus_addr;
u32 mode;
@@ -99,7 +100,6 @@
int needs_scratch_page;
int aperture_size_idx;
int num_aperture_sizes;
- int num_of_masks;
int capndx;
int cant_use_aperture;
diff -Nru a/drivers/char/agp/agpgart_be.c b/drivers/char/agp/agpgart_be.c
--- a/drivers/char/agp/agpgart_be.c Fri Sep 27 20:59:30 2002
+++ b/drivers/char/agp/agpgart_be.c Fri Sep 27 20:59:30 2002
@@ -209,7 +209,6 @@
}
if (curr-page_count != 0) {
for (i = 0; i curr-page_count; i++) {
- curr-memory[i] = ~(0x0fff);
agp_bridge.agp_destroy_page((unsigned long)
phys_to_virt(curr-memory[i]));
}
@@ -262,10 +261,7 @@
agp_free_memory(new);
return NULL;
}
- new-memory[i] =
- agp_bridge.mask_memory(
- virt_to_phys((void *) new-memory[i]),
- type);
+ new-memory[i] = virt_to_phys((void *) new-memory[i]);
new-page_count++;
}
@@ -311,9 +307,6 @@
int agp_copy_info(agp_kern_info * info)
{
- unsigned long page_mask = 0;
- int i;
-
memset(info, 0, sizeof(agp_kern_info));
if (agp_bridge.type == NOT_SUPPORTED) {
info-chipset = agp_bridge.type;
@@ -329,11 +322,7 @@
info-max_memory = agp_bridge.max_memory_agp;
info-current_memory = atomic_read(agp_bridge.current_memory_agp);
info-cant_use_aperture = agp_bridge.cant_use_aperture;
-
- for(i = 0; i agp_bridge.num_of_masks; i++)
- page_mask |= agp_bridge.mask_memory(page_mask, i);
-
- info-page_mask = ~page_mask;
+ info-page_mask = ~0UL;
return 0;
}
@@ -731,7 +720,8 @@
mem-is_flushed = TRUE;
}
for (i = 0, j = pg_start; i mem-page_count; i++, j++) {
- agp_bridge.gatt_table[j] = mem-memory[i];
+ agp_bridge.gatt_table[j] =
+ agp_bridge.mask_memory(mem-memory[i], mem-type);
}
agp_bridge.tlb_flush(mem);
@@ -976,7 +966,8 @@
CACHE_FLUSH();
for (i = 0, j = pg_start; i mem-page_count; i++, j++) {
OUTREG32(intel_i810_private.registers,
-I810_PTE_BASE + (j * 4), mem-memory[i]);
+I810_PTE_BASE + (j * 4),
+agp_bridge.mask_memory(mem-memory[i], mem-type));
}
CACHE_FLUSH();
@@ -1042,10 +1033,7 @@
agp_free_memory(new);
return NULL;
}
- new-memory[0] =
- agp_bridge.mask_memory(
- virt_to_phys((void *) new-memory[0]),
- type);
+ new-memory[0] = virt_to_phys((void *) new-memory[0]);
new-page_count = 1;
new-num_scratch_pages = 1;
new-type = AGP_PHYS_MEMORY;
@@ -1079,7 +1067,6 @@
intel_i810_private.i810_dev = i810_dev;
agp_bridge.masks = intel_i810_masks;
- agp_bridge.num_of_masks = 2;
agp_bridge.aperture_sizes = (void *) intel_i810_sizes;
agp_bridge.size_type = FIXED_APER_SIZE;
agp_bridge.num_aperture_sizes =
[Dri-devel] [PATCH] agpgart/DRM page_mask
I'd like to propose putting the attached patch into the IA64 tree.
The point is to be able to support both 460GX and a similar
HP chipset without having to put kludges in DRM.
Chris Ahna and Jeff Hartmann both seem to be OK with this
approach. It's not really IA64-specific, and I did try to get
it directly into 2.4.x/2.5.x, but there's really no benefit there
without the 460GX GART code. So it makes sense to me to
keep it with the 460GX code, and merge both into the main
tree at the same time.
--
Bjorn Helgaas - [EMAIL PROTECTED]
Linux Systems Operation RD
Hewlett-Packard
diff -u -r -X /home/helgaas/exclude linux-2.4.18-ia64-020226/drivers/char/agp/agp.h
build/linux-2.4.18-ia64-020226-pagemask/drivers/char/agp/agp.h
--- linux-2.4.18-ia64-020226/drivers/char/agp/agp.h Wed Mar 6 16:53:47 2002
+++ build/linux-2.4.18-ia64-020226-pagemask/drivers/char/agp/agp.h Wed Mar 6
+17:06:52 2002
@@ -99,7 +99,6 @@
int needs_scratch_page;
int aperture_size_idx;
int num_aperture_sizes;
- int num_of_masks;
int capndx;
int cant_use_aperture;
diff -u -r -X /home/helgaas/exclude
linux-2.4.18-ia64-020226/drivers/char/agp/agpgart_be.c
build/linux-2.4.18-ia64-020226-pagemask/drivers/char/agp/agpgart_be.c
--- linux-2.4.18-ia64-020226/drivers/char/agp/agpgart_be.c Wed Mar 6 16:53:47
2002
+++ build/linux-2.4.18-ia64-020226-pagemask/drivers/char/agp/agpgart_be.c Wed
+Mar 6 17:06:11 2002
@@ -212,8 +212,6 @@
if(agp_bridge.cant_use_aperture == 0) {
if (curr-page_count != 0) {
for (i = 0; i curr-page_count; i++) {
- curr-memory[i] = agp_bridge.unmask_memory(
-curr-memory[i]);
agp_bridge.agp_destroy_page((unsigned long)
phys_to_virt(curr-memory[i]));
}
@@ -302,10 +300,7 @@
agp_free_memory(new);
return NULL;
}
- new-memory[i] =
- agp_bridge.mask_memory(
- virt_to_phys((void *) new-memory[i]),
- type);
+ new-memory[i] = virt_to_phys((void *) new-memory[i]);
new-page_count++;
}
} else {
@@ -338,7 +333,7 @@
#else
paddr = pte_val(*pte) PAGE_MASK;
#endif
- new-memory[i] = agp_bridge.mask_memory(paddr, type);
+ new-memory[i] = paddr;
}
new-page_count = page_count;
@@ -384,9 +379,6 @@
void agp_copy_info(agp_kern_info * info)
{
- unsigned long page_mask = 0;
- int i;
-
memset(info, 0, sizeof(agp_kern_info));
if (agp_bridge.type == NOT_SUPPORTED) {
info-chipset = agp_bridge.type;
@@ -402,11 +394,7 @@
info-max_memory = agp_bridge.max_memory_agp;
info-current_memory = atomic_read(agp_bridge.current_memory_agp);
info-cant_use_aperture = agp_bridge.cant_use_aperture;
-
- for(i = 0; i agp_bridge.num_of_masks; i++)
- page_mask |= agp_bridge.mask_memory(page_mask, i);
-
- info-page_mask = ~page_mask;
+ info-page_mask = ~0UL;
}
/* End - Routine to copy over information structure */
@@ -835,7 +823,8 @@
mem-is_flushed = TRUE;
}
for (i = 0, j = pg_start; i mem-page_count; i++, j++) {
- agp_bridge.gatt_table[j] = mem-memory[i];
+ agp_bridge.gatt_table[j] =
+ agp_bridge.mask_memory(mem-memory[i], mem-type);
}
agp_bridge.tlb_flush(mem);
@@ -1077,7 +1066,8 @@
CACHE_FLUSH();
for (i = 0, j = pg_start; i mem-page_count; i++, j++) {
OUTREG32(intel_i810_private.registers,
-I810_PTE_BASE + (j * 4), mem-memory[i]);
+I810_PTE_BASE + (j * 4),
+agp_bridge.mask_memory(mem-memory[i], mem-type));
}
CACHE_FLUSH();
@@ -1143,10 +1133,7 @@
agp_free_memory(new);
return NULL;
}
- new-memory[0] =
- agp_bridge.mask_memory(
- virt_to_phys((void *) new-memory[0]),
- type);
+ new-memory[0] = virt_to_phys((void *) new-memory[0]);
new-page_count = 1;
new-num_scratch_pages = 1;
new-type = AGP_PHYS_MEMORY;
@@ -1180,7 +1167,6 @@
intel_i810_private.i810_dev = i810_dev;
agp_bridge.masks = intel_i810_masks;
- agp_bridge.num_of_masks = 2;
agp_bridge.aperture_sizes = (void
[Dri-devel] Re: agpgart/DRM page_mask changes
On Tuesday 05 March 2002 10:45, Jeff Hartmann wrote: I have no problem accepting the agpgart change, and I think its cleaner. We might want to modify that patch in the future so the old behavior can be selected, but thats not a big deal for now. Btw, do you have a working driver for the HP IA64 chipset? If you do, it might make sense to submit it to Linus and the 2.4 maintainer (I forget his name) at the same time you submit the patch. It makes things more likely to be included. If you find you need assistance getting the patch into the kernel (i.e. they ignore your patches), I can submit them for you. Yes, I do have a driver for the HP chipset, but I don't have a strategy for getting it upstream yet. It depends on a bunch of other stuff that is only in David Mosberger's IA64 tree, so my thought was that I would get the driver into the IA64 patch first. (The 460GX driver is in the same situation -- it's in the IA64 patch only.) I could push the page_mask changes to the IA64 patch at the same time, but David's preference was to put it straight into 2.4.x/2.5.x because it isn't IA64-specific. I do agree that it makes sense to bundle them with the 460GX and HP GART drivers because the justification is clearer. Actually, I'm starting to convince myself that pushing it into the IA64 patch along with the driver is the correct approach. Without the 460GX GART driver, there's no benefit to 2.4.x/2.5.x, only risk, so why would they bother with it? If you guys agree, I'll approach David again about putting it into the IA64 patch. -- Bjorn Helgaas - [EMAIL PROTECTED] Linux Systems Operation RD Hewlett-Packard ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] agpgart/DRM page_mask changes
Hi Jeff,
I'm still trying to resolve this issue for clean support of both the
Intel 460GX and the corresponding HP IA64 chipset.
We need either
(1) an agpgart patch like the attached one,
(2) a hack in DRM like the one below, or
(3) some other possibility I haven't thought of.
If we do the agpgart change, we don't need to change DRM,
which in my mind is a big plus.
Do you support putting the attached agpgart patch into the
2.4.x kernel stream (and/or 2.5.x)? If so, would you like to
push it upstream yourself, or should I continue beating my
head against the wall?
--- linux-2.4.17/drivers/char/drm/drm_vm.h Thu Nov 22 12:46:37 2001
+++ linux-2.4.17-ia64-011226/drivers/char/drm/drm_vm.h Mon Mar 4 10:45:04 2002
@@ -115,8 +115,16 @@
* Get the page, inc the use count, and return it
*/
offset = (baddr - agpmem-bound) PAGE_SHIFT;
- agpmem-memory-memory[offset] = dev-agp-page_mask;
- page = virt_to_page(__va(agpmem-memory-memory[offset]));
+
+#if defined(CONFIG_AGP_I460) defined(__ia64__)
+ if (dev-agp-agp_info.chipset == INTEL_460GX)
+ paddr = (agpmem-memory-memory[offset] 0xff) 1
2;
+ else
+ paddr = agpmem-memory-memory[offset] dev-agp-page_
mask;
+#else
+ paddr = agpmem-memory-memory[offset] dev-agp-page_mask;
+#endif
+ page = virt_to_page(__va(paddr));
get_page(page);
DRM_DEBUG(baddr = 0x%lx page = 0x%p, offset = 0x%lx\n,
--
Bjorn Helgaas - [EMAIL PROTECTED]
Linux Systems Operation RD
Hewlett-Packard
diff -u -r linux-2.4.19-pre2/drivers/char/agp/agp.h
build/linux-2.4.19-pre2-pagemask/drivers/char/agp/agp.h
--- linux-2.4.19-pre2/drivers/char/agp/agp.hMon Feb 25 12:37:57 2002
+++ build/linux-2.4.19-pre2-pagemask/drivers/char/agp/agp.h Fri Mar 1 17:16:39
+2002
@@ -99,7 +99,6 @@
int needs_scratch_page;
int aperture_size_idx;
int num_aperture_sizes;
- int num_of_masks;
int capndx;
int cant_use_aperture;
diff -u -r linux-2.4.19-pre2/drivers/char/agp/agpgart_be.c
build/linux-2.4.19-pre2-pagemask/drivers/char/agp/agpgart_be.c
--- linux-2.4.19-pre2/drivers/char/agp/agpgart_be.c Fri Mar 1 17:15:57 2002
+++ build/linux-2.4.19-pre2-pagemask/drivers/char/agp/agpgart_be.c Fri Mar 1
+17:16:39 2002
@@ -207,7 +207,6 @@
}
if (curr-page_count != 0) {
for (i = 0; i curr-page_count; i++) {
- curr-memory[i] = ~(0x0fff);
agp_bridge.agp_destroy_page((unsigned long)
phys_to_virt(curr-memory[i]));
}
@@ -260,10 +259,7 @@
agp_free_memory(new);
return NULL;
}
- new-memory[i] =
- agp_bridge.mask_memory(
- virt_to_phys((void *) new-memory[i]),
- type);
+ new-memory[i] = virt_to_phys((void *) new-memory[i]);
new-page_count++;
}
@@ -307,9 +303,6 @@
void agp_copy_info(agp_kern_info * info)
{
- unsigned long page_mask = 0;
- int i;
-
memset(info, 0, sizeof(agp_kern_info));
if (agp_bridge.type == NOT_SUPPORTED) {
info-chipset = agp_bridge.type;
@@ -325,11 +318,7 @@
info-max_memory = agp_bridge.max_memory_agp;
info-current_memory = atomic_read(agp_bridge.current_memory_agp);
info-cant_use_aperture = agp_bridge.cant_use_aperture;
-
- for(i = 0; i agp_bridge.num_of_masks; i++)
- page_mask |= agp_bridge.mask_memory(page_mask, i);
-
- info-page_mask = ~page_mask;
+ info-page_mask = ~0UL;
}
/* End - Routine to copy over information structure */
@@ -713,7 +702,8 @@
mem-is_flushed = TRUE;
}
for (i = 0, j = pg_start; i mem-page_count; i++, j++) {
- agp_bridge.gatt_table[j] = mem-memory[i];
+ agp_bridge.gatt_table[j] =
+ agp_bridge.mask_memory(mem-memory[i], mem-type);
}
agp_bridge.tlb_flush(mem);
@@ -949,7 +939,8 @@
CACHE_FLUSH();
for (i = 0, j = pg_start; i mem-page_count; i++, j++) {
OUTREG32(intel_i810_private.registers,
-I810_PTE_BASE + (j * 4), mem-memory[i]);
+I810_PTE_BASE + (j * 4),
+agp_bridge.mask_memory(mem-memory[i], mem-type));
}
CACHE_FLUSH();
@@ -1015,10 +1006,7 @@
agp_free_memory(new);
return NULL;
}
- new-memory[0] =
- agp_bridge.mask_memory(
- virt_to_phys((void *) new-memory[0
Re: [Dri-devel] [PATCH] 2.4.17 DRM(ioremap) oops fix
On Friday 25 January 2002 10:16 am, I wrote: When I start X on a kernel where agpgart is included but no gart device is found, X oopses on a null pointer dereference in radeon_ioremap. The attached patch avoids the oops, but should be reviewed by someone more knowledgeable about DRM than I. Chris Ahna pointed out that this bug only exists in the IA64 port and that Andreas Schwab had already posted a slightly more complete patch to LKML: http://marc.theaimsgroup.com/?l=linux-kernelm=101148145728933w=2 -- Bjorn Helgaas - [EMAIL PROTECTED] Linux Systems Operation RD Hewlett-Packard ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] i810 agpgart curiosity
On Monday 14 January 2002 9:57 am, Sottek, Matthew J wrote:
Why do you think that isn't a virtual address? agp_alloc_page
gets a page and returns page_addresss(page) which is the kernel
virtual address for the page, right?
agp_alloc_page (agp_generic_alloc_page in the i810 case) indeed returns a
kernel virtual address, but the next line I quoted:
new-memory[0] =
agp_bridge.mask_memory(
virt_to_phys((void *) new-memory[0]),
type);
converts it to a physical address, then intel_i810_mask_memory() ORs in
the GATT valid bit. The next line I quoted:
new-physical = virt_to_phys((void *) new-memory[0]);
takes that masked physical address and applies virt_to_phys to it, which
just seems wrong. Like I said, I don't have an i810, and I haven't
exhaustively analyzed it to see, for instance, whether new-physical is
even used anywhere, but it still looks wrong to me.
intel_i830_alloc_by_type() contains very similar code that makes more
sense to me:
if (type == AGP_PHYS_MEMORY) {
unsigned long physical;
...
nw-memory[0] = agp_bridge.agp_alloc_page();
physical = nw-memory[0];
...
nw-memory[0] = agp_bridge.mask_memory(virt_to_phys((void
*) nw-memory[0]),type);
...
nw-physical = virt_to_phys((void *) physical);
Although the temporary physical is mis-named, since it actually contains
a kernel virtual address :-)
Bjorn
-Original Message-
From: Bjorn Helgaas [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 11, 2002 10:31 AM
To: [EMAIL PROTECTED]
Subject: [Dri-devel] i810 agpgart curiosity
The following code in agpgart_be.c looks bogus to me:
static agp_memory *intel_i810_alloc_by_type(size_t pg_count, int type)
...
if(type == AGP_PHYS_MEMORY) {
...
new-memory[0] = agp_bridge.agp_alloc_page();
...
new-memory[0] =
agp_bridge.mask_memory(
virt_to_phys((void *)
new-memory[0]), type);
...
new-physical = virt_to_phys((void *) new-memory[0]);
I don't have an i810, so I can't verify anything, but it looks like it
puts garbage in new-physical. At least, it's calling virt_to_phys() on
something that is definitely NOT a virtual address!
Any i810 gurus care to comment?
--
Bjorn Helgaas - [EMAIL PROTECTED]
Linux Systems Operation RD
Hewlett-Packard
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] i810 agpgart curiosity
The following code in agpgart_be.c looks bogus to me:
static agp_memory *intel_i810_alloc_by_type(size_t pg_count, int type)
...
if(type == AGP_PHYS_MEMORY) {
...
new-memory[0] = agp_bridge.agp_alloc_page();
...
new-memory[0] =
agp_bridge.mask_memory(
virt_to_phys((void *) new-memory[0]),
type);
...
new-physical = virt_to_phys((void *) new-memory[0]);
I don't have an i810, so I can't verify anything, but it looks like it
puts garbage in new-physical. At least, it's calling virt_to_phys() on
something that is definitely NOT a virtual address!
Any i810 gurus care to comment?
--
Bjorn Helgaas - [EMAIL PROTECTED]
Linux Systems Operation RD
Hewlett-Packard
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] agpgart interface cleanup (enables new IA64 box)
DRM needs to know the physical addresses of pages bound into the AGP
aperture, and today that information is communicated from agpgart to DRM
in the memory[] array of the agp_memory structure. The problem is that
the values in the array are not simple physical addresses. Rather, they
are the physical addresses mangled to be suitable for direct insertion
into the GATT (the hardware-visible translation table).
Hence, DRM needs a way to unmangle these values to get the physical
address back. Today, agpgart exports a page_mask value, so DRM does the
equivalent of this:
paddr = agpmem-memory-memory[offset] dev-agp-page_mask;
This isn't sufficient for the 460GX, because its mangling function
requires a shift as well as a mask. The 460GX code (which is still in the
ia64 patch, not in the mainstream kernel) looks like this:
paddr = (agpmem-memory-memory[offset] 0xff) 12;
So DRM currently has chipset-specific code in it to unmangle the values in
memory[], while there's no reason for the mangled values to ever be
exported from agpgart. Worse, at least one soon-to-be-released IA64 box
has an unmangling function different from the 460GX.
The attached patch against 2.5.2-pre11 remedies all this by leaving the
plain physical addresses in memory[]. The chipset-specific mangling is
then done at the point where it is needed, when those values are inserted
into the GATT.
The patch is done so that agpgart still exports a page_mask; it's just
~0UL, so that old DRM modules will continue to work with new kernels.
These places are marked with #ifdef EXPORT_PAGE_MASK so it can be pulled
out eventually. New DRM modules will also work with old kernels, because
they still use page_mask (under #ifdef USE_PAGE_MASK).
--
Bjorn Helgaas - [EMAIL PROTECTED]
Linux Systems Operation RD
Hewlett-Packard
diff -u -ur -X /home/helgaas/exclude
linux-2.5.2-pre11/include/linux/agp_backend.h
linux-2.5.2-pre11+pagemask/include/linux/agp_backend.h
--- linux-2.5.2-pre11/include/linux/agp_backend.h Fri Nov 9 15:11:15 2001
+++ linux-2.5.2-pre11+pagemask/include/linux/agp_backend.h Fri Jan 11
11:02:15 2002
@@ -38,6 +38,13 @@
#define AGPGART_VERSION_MAJOR 0
#define AGPGART_VERSION_MINOR 99
+/*
+ * Old kernels exported mangled page addresses to DRM, which used
+ * page_mask to unmangle them. Old DRM, such as that distributed with
+ * XFree86, requires the page_mask.
+ */
+#define EXPORT_PAGE_MASK 1
+
enum chipset_type {
NOT_SUPPORTED,
INTEL_GENERIC,
@@ -92,7 +99,9 @@
int max_memory; /* In pages */
int current_memory;
int cant_use_aperture;
+#ifdef EXPORT_PAGE_MASK
unsigned long page_mask;
+#endif
} agp_kern_info;
/*
diff -u -ur -X /home/helgaas/exclude
linux-2.5.2-pre11/drivers/char/agp/agpgart_be.c
linux-2.5.2-pre11+pagemask/drivers/char/agp/agpgart_be.c
--- linux-2.5.2-pre11/drivers/char/agp/agpgart_be.c Fri Nov 30 09:52:41
2001
+++ linux-2.5.2-pre11+pagemask/drivers/char/agp/agpgart_be.cFri Jan 11
11:20:36 2002
@@ -207,7 +207,6 @@
}
if (curr-page_count != 0) {
for (i = 0; i curr-page_count; i++) {
- curr-memory[i] = ~(0x0fff);
agp_bridge.agp_destroy_page((unsigned long)
phys_to_virt(curr-memory[i]));
}
@@ -260,10 +259,7 @@
agp_free_memory(new);
return NULL;
}
- new-memory[i] =
- agp_bridge.mask_memory(
- virt_to_phys((void *) new-memory[i]),
- type);
+ new-memory[i] = virt_to_phys((void *) new-memory[i]);
new-page_count++;
}
@@ -307,9 +303,6 @@
void agp_copy_info(agp_kern_info * info)
{
- unsigned long page_mask = 0;
- int i;
-
memset(info, 0, sizeof(agp_kern_info));
if (agp_bridge.type == NOT_SUPPORTED) {
info-chipset = agp_bridge.type;
@@ -325,11 +318,9 @@
info-max_memory = agp_bridge.max_memory_agp;
info-current_memory = atomic_read(agp_bridge.current_memory_agp);
info-cant_use_aperture = agp_bridge.cant_use_aperture;
-
- for(i = 0; i agp_bridge.num_of_masks; i++)
- page_mask |= agp_bridge.mask_memory(page_mask, i);
-
- info-page_mask = ~page_mask;
+#ifdef EXPORT_PAGE_MASK
+ info-page_mask = ~0UL;
+#endif
}
/* End - Routine to copy over information structure */
@@ -746,7 +737,8 @@
mem-is_flushed = TRUE;
}
for (i = 0, j = pg_start; i mem-page_count; i++, j++) {
- agp_bridge.gatt_table[j] = mem-memory[i];
+ agp_bridge.gatt_table[j] =
+ agp_bridge.mask_memory(mem-memory[i], mem-type);
}
agp_bridge.tlb_flush(mem);
@@ -983,7 +975,8 @@
CACHE_FLUSH
Re: [Dri-devel] agp GATT table specification
On Monday 17 December 2001 2:55 pm, Philip Brown wrote: On Mon, Dec 17, 2001 at 10:52:04PM +0100, Alexander Stohr wrote: ... Anyways, you might consider reading open source like existing 440BX coding in agpgart in order to see what is required. err, that's what I'm DOING :-) Trouble is, there are virtually zero comments in the /dev/agpgart driver, and I'm not intimately familiar with the linux page allocation stuff, so it's not clear to me what kind of values are being put in the GATT table: addresses, or page numbers, or... It depends on the chipset. :-) Typically it is physical addresses, with an extra bit OR'd in to tell the chipset the entry is valid. The Intel 460GX is an exception; I think its GATT entries are page numbers with an extra bit. In general, the GATT entries are the output of the *_mask() functions, which take a physical address and a type as arguments. -- Bjorn Helgaas - [EMAIL PROTECTED] Linux Systems Operation RD Hewlett-Packard ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [PATCH] agpgart chipset knowledge encapsulation
The point of this patch is to remove a chipset dependency from DRM so it can cleanly support both the Intel 460GX and an HP IA64 chipset. I would normally send this to Jeff Hartmann, but he seems to have disappeared, leaving agpgart without an obvious maintainer. DRM needs to know the physical addresses of pages bound into the AGP aperture, and today that information is communicated from agpgart to DRM in the memory[] array of the agp_memory structure. The problem is that the values in the array are not simple physical addresses. Rather, they are the physical addresses mangled to be suitable for direct insertion into the GATT (the hardware-visible translation table). Hence, DRM needs a way to unmangle these values to get the physical address back. Today, agpgart exports a page_mask value, so DRM does the equivalent of this: paddr = agpmem-memory-memory[offset] dev-agp-page_mask; This isn't sufficient for the 460GX, because its mangling function requires a shift as well as a mask. The 460GX code (which is still in the ia64 patch, not in the mainstream kernel) looks like this: paddr = (agpmem-memory-memory[offset] 0xff) 12; So DRM currently has this chipset-specific code in it to unmangle the values in memory[], while there's no reason I know of for the mangled values to ever be exported from agpgart. The attached patch against 2.4.16 remedies this by leaving the plain physical addresses in memory[]. The chipset-specific mangling is then done at the point where it is needed, when those values are inserted into the GATT. It's a little tricky because the DRM code is distributed with XFree86 as well as with the kernel. All the combinations (old DRM + new kernel; new DRM + old kernel; new DRM + new kernel) should still work, but DRM has to check the kernel version it's compiled against, so there are three KERNEL_VERSION(...) instances in the patch that need to be adjusted to reflect the first version containing these changes. Any feedback is welcome, especially if you can test it. I've been able to test 460GX ATI Radeon, HP ATI Radeon, and Serverworks HE MGA G400, but obviously that's not exhaustive. Bjorn Helgaas -- Linux Systems Operation RD Hewlett-Packard Company Fort Collins, CO pagemask.diff.gz Description: GNU Zip compressed data
Re: [Dri-devel] [patch] encapsulate AGP/GART mask bits
On Friday 07 December 2001 2:09 am, Keith Whitwell wrote: What are the goals of your patch? Is it a cleanup, or is there something deeper you hope to gain? Yes, I should have made the goal clearer. This section of the diff is the relevant piece: --- linux+ia64/drivers/char/drm/drm_vm.hTue Nov 27 13:54:53 2001 +++ linux/drivers/char/drm/drm_vm.h Thu Dec 6 10:57:39 2001 @@ -115,18 +115,7 @@ * Get the page, inc the use count, and return it */ offset = (baddr - agpmem-bound) PAGE_SHIFT; - - /* -* This is bad. What we really want to do here is unmask -* the GART table entry held in the agp_memory structure. -* There isn't a convenient way to call agp_bridge.unmask_ -* memory from here, so hard code it for now. -*/ -#if defined(__ia64__) - paddr = (agpmem-memory-memory[offset] 0xff) 12; -#else - paddr = agpmem-memory-memory[offset] dev-agp-page_mask; -#endif + paddr = agpmem-memory-memory[offset]; page = virt_to_page(__va(paddr)); get_page(page); Note that the computation of paddr is machine-dependent. The existing code for __ia64__ (paddr = (agpmem-memory-memory[offset] 0xff) 12) is specific to the Intel 460GX chipset. I'm implementing support for an HP IA64 chipset, and our unmasking function is of course different from the 460's. So, we either have to have chipset-specific code in DRM to compute paddr, or export an API from AGP/GART (the page_mask stuff is a simple start at this, but as you can see, is not general enough to describe all unmask operations), or try to remove the need for the unmasking completely. This last is the avenue that I'm trying to pursue. The unmask operation is chipset-dependent, and ideally would be encapsulated within the AGP/GART module. I don't see any reason why the memory[] table needs to contain the masked values, so I simply put the unmasked values there (the unmodified physical addresses). The place where the masked values are needed is when they are actually inserted in the GATT, the table read by the chipset. Before my patch, the memory allocation functions apply the mask operation and put the result into memory[]. The functions that insert into the GATT just copied the values from memory[]. My patch changes things so that the memory allocation functions do not apply the mask, but rather put the unmodified physical addresses into memory[]. The GATT insertion functions then take the values from memory[], apply the mask operation, *then* put them into the GATT. Make sense? ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [patch] encapsulate AGP/GART mask bits
On Thursday 06 December 2001 6:35 pm, Alexander Stohr wrote: So far as i have seen your patch, i only feel a bit unsure on what problems that PAGE_MASK_INTERFACE changes might raise. It is part of the exported symbol/function agp_copy_info(), even if only of use between front and backend, anybody could have made use of it by attaching to it. That's why I left it there, under the #ifdef. I'm sure we'll have to keep it around for a while; I just put in the #ifdefs so if we can ever remove, it will be easy to find all the pieces. If someone can educate me about the right way to do this, that'd be great. Otherwise, I'll probably just add comments deprecating its use, add a #define for PAGE_MASK_INTERFACE, and be done with it. OT: Does someone know about Jeff Hartmann? Is he well and up again? I was hoping he might see my post here, but I haven't heard from him in months, either. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [patch] encapsulate AGP/GART mask bits
In the Linux AGP/GART driver, the agp_memory struct contains a memory[]
array with the physical address of every page in the block.
Currently, the elements of the memory[] array are the actual values put
into the GATT, i.e., they contain the valid bit and any other bits
required by the GART chipset as well as the physical address.
These mangled physical addresses are used by DRM, for example in
DRM(vm_nopage), where those extra chipset-specific bits have to be masked
out to obtain the actual physical address.
I propose a change along the lines of the following patch, which makes the
elements of memory[] plain physical addresses and keeps all the
chipset-specific bits encapsulated inside the AGP/GART module. The
general idea is to move the masking (chipset-specific address mangling)
from the memory allocation path to the GATT insertion path.
I'm not a DRM guru, so I'm sure there are subtleties I'm missing, and I
know there are some interface versioning issues to work out, but I'd
appreciate any feedback on the approach and advice on how to proceed. The
attached patch is against 2.4.16 with the IA64 patch applied.
--- linux+ia64/drivers/char/drm/drmP.h Tue Nov 27 13:54:53 2001
+++ linux/drivers/char/drm/drmP.h Thu Dec 6 14:11:34 2001
@@ -628,7 +628,9 @@
unsigned long base;
intagp_mtrr;
intcant_use_aperture;
+#ifdef PAGE_MASK_INTERFACE
unsigned long page_mask;
+#endif
} drm_agp_head_t;
#endif
--- linux+ia64/drivers/char/drm/drm_vm.hTue Nov 27 13:54:53 2001
+++ linux/drivers/char/drm/drm_vm.h Thu Dec 6 10:57:39 2001
@@ -115,18 +115,7 @@
* Get the page, inc the use count, and return it
*/
offset = (baddr - agpmem-bound) PAGE_SHIFT;
-
- /*
-* This is bad. What we really want to do here is unmask
-* the GART table entry held in the agp_memory structure.
-* There isn't a convenient way to call agp_bridge.unmask_
-* memory from here, so hard code it for now.
-*/
-#if defined(__ia64__)
- paddr = (agpmem-memory-memory[offset] 0xff) 12;
-#else
- paddr = agpmem-memory-memory[offset] dev-agp-page_mask;
-#endif
+ paddr = agpmem-memory-memory[offset];
page = virt_to_page(__va(paddr));
get_page(page);
--- linux+ia64/drivers/char/drm/drm_agpsupport.hTue Nov 27 13:54:53 2001
+++ linux/drivers/char/drm/drm_agpsupport.h Thu Dec 6 10:56:34 2001
@@ -321,10 +321,14 @@
}
#if LINUX_VERSION_CODE = 0x020408
head-cant_use_aperture = 0;
+#ifdef PAGE_MASK_INTERFACE
head-page_mask = ~(0xfff);
+#endif
#else
head-cant_use_aperture = head-agp_info.cant_use_aperture;
+#ifdef PAGE_MASK_INTERFACE
head-page_mask = head-agp_info.page_mask;
+#endif
#endif
DRM_INFO(AGP %d.%d on %s @ 0x%08lx %ZuMB\n,
--- linux+ia64/drivers/char/agp/agpgart_be.cTue Nov 27 13:54:53 2001
+++ linux/drivers/char/agp/agpgart_be.c Thu Dec 6 10:59:51 2001
@@ -212,8 +212,6 @@
if(agp_bridge.cant_use_aperture == 0) {
if (curr-page_count != 0) {
for (i = 0; i curr-page_count; i++) {
- curr-memory[i] = agp_bridge.unmask_memory(
-curr-memory[i]);
agp_bridge.agp_destroy_page((unsigned long)
phys_to_virt(curr-memory[i]));
}
@@ -302,10 +300,7 @@
agp_free_memory(new);
return NULL;
}
- new-memory[i] =
- agp_bridge.mask_memory(
- virt_to_phys((void *) new-memory[i]),
- type);
+ new-memory[i] = virt_to_phys((void *) new-memory[i]);
new-page_count++;
}
} else {
@@ -338,7 +333,7 @@
#else
paddr = pte_val(*pte) PAGE_MASK;
#endif
- new-memory[i] = agp_bridge.mask_memory(paddr, type);
+ new-memory[i] = paddr;
}
new-page_count = page_count;
@@ -403,10 +398,12 @@
info-current_memory = atomic_read(agp_bridge.current_memory_agp);
info-cant_use_aperture = agp_bridge.cant_use_aperture;
+#ifdef PAGE_MASK_INTERFACE
for(i = 0; i agp_bridge.num_of_masks; i++)
page_mask |= agp_bridge.mask_memory(page_mask, i);
info-page_mask = ~page_mask;
+#endif
}
/* End - Routine to copy over information structure */
@@ -825,7 +822,7 @@
