>
> 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)
Best regards
-- Nicolas Aspert Signal Processing Laboratory (LTS) Swiss Federal Institute of Technology (EPFL)- 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/
This archive was generated by hypermail 2b29 : Fri Nov 30 2001 - 21:00:26 EST