Here's a patch which adds AGP support to i think all G5 at
least uninorth3 chipset. If you could test it even if i am quite
confident there is no bug in it :)
I also cleaned up a bit the old uninorth by using PAGE_SHIFT,
PAGE_MASK and other defined macro where they shoud have
been used.
Ben i corrected the issue i got with fan, i was writting some
wrong magic in wrong place.
So you should have agp enable with this patch, thus if anyone
with a g5 & r200 would test the dri to see if it could successfull
use the agp for the video card. Anyother way to test it ?
If you use Xorg you may need to add this to your conf file if
you see that you font are corrupted (it seems there is a bug
somewhere in dri)
Option "XaaNoScanlineImageWriteRect"
best,
Jerome Glisse
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2004-12-27 08:50:05
+ if((uninorth_rev >= 0x30) && (uninorth_rev <= 0x33)) {
+ /*
+ * We need to to set REQ_DEPTH to 7 for U3 versions 1.0, 2.1,
+ * 2.2 and 2.3, Darwin do so.
+ */
+ command |= (7 << AGPSTAT_RQ_DEPTH_SHIFT);
+ }
Some revs of U3 (3.x) do have some high bits sets in the version
register, you should probably mask it with 0x3f ... Though on the other
hand, I don't know if revisions prior to 3.x were ever used on
production...
Ben.
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2004-12-27 08:52:06
+/* The following seems to only be used only on U3 [off-list ref] */
+#define UNI_N_CFG_GART_SYNCMODE 0x00040000
+#define UNI_N_CFG_GART_PERFRD 0x00080000
+#define UNI_N_CFG_GART_B2BGNT 0x00200000
+#define UNI_N_CFG_GART_FASTDDR 0x00400000
Please, call them U3_*
quoted hunk
/* My understanding of UniNorth AGP as of UniNorth rev 1.0x,
* revision 1.5 (x4 AGP) may need further changes.
diff -Naur linux/include/linux/pci_ids.h linux-new/include/linux/pci_ids.h
I changed the name to proper one :) And masked
the rev version, Darwin do so to even if it is unlikely
that such revision have been used for production.
thanx for your comments, will you push it too the kernel
(after testing) or do i have to send it elsewhere ? :)
Anyway this is not a critical issue but if we manage to
make the r300 chipset working (even only for 2d accel)
than this could be usefull for users :)
best,
Jerome Glisse
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2004-12-27 13:32:00
On Mon, 2004-12-27 at 13:51 +0100, Jerome Glisse wrote:
I changed the name to proper one :) And masked
the rev version, Darwin do so to even if it is unlikely
that such revision have been used for production.
Good !
thanx for your comments, will you push it too the kernel.
(after testing) or doI i have to send it elsewhere ? :)
Nah, I'll take care of it when I'm back from vacation.
Anyway this is not a critical issue but if we manage to
make the r300 chipset working (even only for 2d accel)
than this could be usefull for users :)
Sure. There is still a pending issue though with AGP on the G5. The
problem is that we create a non-cacheable mapping for the RAM pages of
the AGP aperture (both in-kernel and for userland) while they already
have a cacheable mapping via the normal kernel linear mapping of main
memory.
The result is that there is a potential cache aliasing issue, aggravated
by the fact that the G5 is quite aggressive on pre-fetching and thuis,
may end up prefetching some of the AGP cache lines (via the linear
mapping) even if no actual access is ever done to these pages.
Unfortunately, if a collision occurs (a non-cacheable access to some
space that do exist in the cache at the same time), the result is
undefined, and is likely to result in a checkstop (the CPU just stops).
I really don't know of a simple remedy at this point. The problem is
partially due to the fact that we do the linear mapping using large
pages, so we can't simply undo the cacheable mapping for the pages that
ended up beeing allocated for AGP... An option would be to eventually
reserve the AGP memory early during boot and not include it in the
linear mapping at all. Another thing to test is that maybe U3 is smart
enough to snoop AGP accesses, and thus we could have the AGP mappings be
cacheable as well (though that may require some stronger synchronisation
directives in the DRM code).
Ben.
Sure. There is still a pending issue though with AGP on the G5. The
problem is that we create a non-cacheable mapping for the RAM pages of
the AGP aperture (both in-kernel and for userland) while they already
have a cacheable mapping via the normal kernel linear mapping of main
memory.
The result is that there is a potential cache aliasing issue, aggravated
by the fact that the G5 is quite aggressive on pre-fetching and thuis,
may end up prefetching some of the AGP cache lines (via the linear
mapping) even if no actual access is ever done to these pages.
Unfortunately, if a collision occurs (a non-cacheable access to some
space that do exist in the cache at the same time), the result is
undefined, and is likely to result in a checkstop (the CPU just stops).
I really don't know of a simple remedy at this point. The problem is
partially due to the fact that we do the linear mapping using large
pages, so we can't simply undo the cacheable mapping for the pages that
ended up beeing allocated for AGP... An option would be to eventually
reserve the AGP memory early during boot and not include it in the
linear mapping at all. Another thing to test is that maybe U3 is smart
enough to snoop AGP accesses, and thus we could have the AGP mappings be
cacheable as well (though that may require some stronger synchronisation
directives in the DRM code).
Ben.
I got some lockup after adding agp support but i don't know if
it came from my playing with the r300 (most probable
source :)) or from the cache collision you are talking about.
Anyway it's not time to think to that :) Have good hollydays.
I will look a bit further in this to see if i can find anythings
that may helps.
best,
Jerome Glisse
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2004-12-27 13:52:43
I got some lockup after adding agp support but i don't know if
it came from my playing with the r300 (most probable
source :)) or from the cache collision you are talking about.
Anyway it's not time to think to that :) Have good hollydays.
I will look a bit further in this to see if i can find anythings
that may helps.
One possiblily to fix the potential issue of cache collision would be to
steal the AGP pages from the hugetlb pool (large pages) instead of small
4k pages. This would make it possible to unmap them individually from
the kernel linear mapping...
Ben.
From: Jon Loeliger <hidden> Date: 2005-01-03 18:56:39
On Mon, 2004-12-27 at 06:51, Jerome Glisse wrote:
quoted hunk
/* My understanding of UniNorth AGP as of UniNorth rev 1.0x,
* revision 1.5 (x4 AGP) may need further changes.
diff -Naur linux/include/linux/pci_ids.h linux-new/include/linux/pci_ids.h