Re: DMA API issues

[Russell King <rmk+lkml@arm.linux.org.uk>]

On Wed, Jun 23, 2004 at 06:01:04PM +0200, Takashi Iwai wrote:
> At Wed, 23 Jun 2004 16:44:19 +0100,
> Russell King wrote:
> > 
> > On Wed, Jun 23, 2004 at 05:36:57PM +0200, Takashi Iwai wrote:
> > > > and a similar one for the ARM-specific "write combining" case (for
> > > > framebuffers utilising the DMA API)?
> > > 
> > > pgprot_noncached() is used on many other architectures in fbmem.c
> > > (well, not really, but the result is identical).
> > > Should it be provided as another one, or is it used as default in
> > > dma_mmap_coherent()?
> > 
> > The whole point is to kill the idea that drivers should have to know
> > about page protection crap.  That should be wholely contained within
> > the architecture implementation.
> 
> I agree.  My question is whether we need to handle different cases
> with cached, non-cached and writecombine, according to the demand of
> the driver.  In other words, do we always handle these mmap pages to
> be non-cached (except for writecombine version)?

No - the driver should have _zero_ visibility of this.  The only time
the cache property comes in is where the architecture needs to alter
these properties to achieve the requirements of the interface - IOW
to provide user space with a DMA-coherent mapping.

Remember that some architectures are unable to disable caching on a
page by page basis, yet may be able to offer fully-cached DMA coherent
mmaps, and therefore such driver interference is wrong.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core