>
>>
>> Ok, since performance and detection seems just ok, I would suggest the
>> attached
>> patch as a fix. Unlike Nicolas I don't see a need for an additional
>> i830MP
>> patch, its only the correct detection of the different i830 setups
>> that needs
>> to be done IMHO.
>> If there are no further complaints we should submit the patch. What do
>> you
>> think Nicolas?
>>
>
> Well, I prefer my version on the patch (of course :-), and I find it
> cleaner. Let me explain why : by just adding the 'break', you will fall
> back to the generic initialization routines, which work in most of the
> cases. However, if you look deeper the code & the specs, they are not
> really that good. Esp., you will see that the APSIZE register is
> accessed through 16bit reads/writes, whereas the spec says this is a 8
> bit register. I have been taught not to write where it is not
> explicitely allowed to. Moreover, the 'tlbflush' mechanism also writes
> over reserved bits when using the generic routine. My patch is just a
> adaptation of what had been done for the Intel 8xx routines (to which I
> have contributed), so my way is more consistent with what was previously
> done.
> However, before submitting the patch, I would like to hear from Didier
> about the X server stuff.
> Does it still hard-locks when you start it ? If testgart works (which
> seems to be the case... btw, yes the 8MB alloced by the program are
> normal) and X locks, this would look more like a DRI/X problem (I saw
> some problems w. Radeon cards on the dri-devel list, which do not seem
> to be fully solved yet)
No more X hard locks.
Compiled & installed latest CVS X (20011127), which includes a Radeon
DGA 2.0 patch : everything fine and dandy (except for my 3D performance
problem).
Kudos to the developer community.
Kind regards,
Didier
Didier Moens
-----
RUG/VIB - Dept. Molecular Biology - Core IT
tel ++32(9)2645309 fax ++32(9)2645348
http://www.dmb.rug.ac.be
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/