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
> 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.