DRI R300 corrupted display purely DRI issue ? G5 AGP support
Jerome Glisse
j.glisse at free.fr
Sun Dec 26 02:58:17 EST 2004
Hi,
So i get my G5 AGP working but i get a corrupted display like Keith Conger
reported no so long on one of this mailing list. My question is anybody
working on it ? If no i will try to correct this but i fear that now i will
have less time to spend on R300 (for the next month). Anyway you can
grab a screenshot here :
http://dj.planet-d.net/Capture.png
As Vladimir said this must be related to an endian issue...
Between Michael Option "BusType" "PCI" is not working properly (drm
refuse to do any mapping but this must be related to r300 drm not r200 ?)
I also see this in my syslog :
Dec 25 16:25:33 localhost kernel: [drm:radeon_cp_init] *ERROR*
radeon_cp_init called without lock held
Dec 25 16:25:33 localhost kernel: [drm:radeon_unlock] *ERROR* Process
2460 using kernel context 0
R300 related too ?
Now PPC stuff :)
For adding support to G5 i have to add some values & device id
but i am not sure on the proper naming for them. Below what i
choose :
include/linux/pci_ids.h
#define PCI_DEVICE_ID_APPLE_UNI_N_AGP8 0x0059
Maybe i better use :
#define PCI_DEVICE_ID_APPLE_UNI_N_AGP3 0x0059
as it seems that this is an AGP3 controller.
I need to add this to include/asm/uninorth.h this seems to
be only used by AGP3 uninorth G5 controller. This values
came from darwin, their names too. I am only using PERFRD
at the moment but others maybe usefull latter if we had features
like fastwrite.
#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
I use a magic value (not so magic thought :)) 12 which correspond
to PAGE_SHIFT in darwin this value depend on page size. Is there
any equivalent infos in linux ? For the moment i use a hardcoded value.
I changed uninorth_tbl_flush, uninorth_cleanup,
uninorth_insert_memory, uninorth_agp_enable
So, i am wondering if it's not better to have a different driver
like uninorth3 (for AGP3) instead of having test to see if we have
a G5 agp or an older one in each functions. Moreover maybe more
of the generic version of agp3(drivers/char/agp/generic.c) could be used.
Any comment on this would be appreciated.
best,
Jerome Glisse
More information about the Linuxppc64-dev
mailing list