At Thu, 21 Aug 2008 23:41:18 +0200, Thomas Bogendoerfer wrote: > > On Thu, Aug 21, 2008 at 06:03:43PM +0200, Takashi Iwai wrote: > > > Thanks for clarification. > > > How about the revised patch below (for PARISC)? > > the PARISC part will not work for 735 systems, because the CPU can't > map memory uncached, iirc. > > > ... and the below is for MIPS. > > for most MIPS system you need the same trick as for PARISC and use > uncached memory. But there are systems, which can't use uncached > memory. > > One of the is SGI IP28, which needs to be switched to a special > slower mode for uncached accesses, which we avoid completly in the > kernel right now and I don't think making the switch to slow mode > possible in user space is a good idea. > > SGI Origin 200/2000, SGI Onyx and some Challenge Systems have a > different problem: > > "Uncached Memory Access in SGI Origin 2000 and in Challenge and Onyx Series > > Access to uncached memory is not supported in these systems, in which > cache coherency is maintained by the hardware, even under access from > CPUs and concurrent DMA. There is never a need (and no approved way) > to access uncached memory in these systems." > > That's from the IRIX Device Driver guide. > > Right now I can't think of a solutin, which works on every MIPS system. Thanks for detailed information. I don't think that this must work for *every* platform, too, and it's not expected from the driver. The systems without uncached memory access can simply return an error from dma_mmap_coherent() call, so that the driver can disable the mmap. That'd be enough. The current problem is that such an architecture / platform specific thing isn't exposed at all. If the driver suppose that mmap would work as if normal pages, then it results in a crash. The dma_mmap_coherent() can hide ugliness inside the arch code, and also can give you an error if unmappable, at least. Now, how to handle these exceptions: a question comes into my mind again -- how does the framebuffer handle these as well? Any pointer appreciated. Thanks! Takashi
