Re: [RFC] on-chip coherent memory API for DMA

[David Brownell]

James Bottomley wrote:
> On Thu, 2004-07-01 at 09:45, David Brownell wrote:
>
> > Seems unreasonable to me, unless there's also an API to change
> > the mode of the dma_alloc_coherent() memory from the normal
> > "CPU can read/write as usual" to the exotic "need to use special
> > memory accessors".  (And another to report what mode the API is
> > in at the current moment.)
>
>
> No. That's why you specify how you'd like the memory to be treated.  If
> you don't want the memory to be accessible only via IO accessors, then
> you specify DMA_MEMORY_MAP and take the failure if the platform can't
> handle it.

That can work when the scope of "DMA" knowledge is just
one driver ... but when that driver is plugging into a
framework, it's as likely to be some other code (maybe
a higher level driver) that just wants RAM address space
which, for whatever reasons, is DMA-coherent.  And hey,
the way to get this is dma_alloc_coherent ... or in some
cases, pci_alloc_consistent.

Which is why my comment was that the new feature of
returning some kind of memory cookie usable on that one
IBM box (etc) should just use a different allocator API.
It doesn't allocate RAM "similarly to __get_free_pages";
it'd be returning something drivers can't treat as RAM.


> > And I don't like modal APIs like that, which is why it'd make
> > more sense to me to have a new allocator API for this new
> > kind of DMA memory.  (Which IS for that IBM processor, yes?)
>
>
> There is no "new" kind of memory.  This is currently how *all* I/O
> memory is accessed.  DMA_MEMORY_MAP is actually the new bit since it
> allows I/O memory to be treated as normal memory.

This isn't I/O address space, needing PIO I/O accessors,
and as returned by the new DMA_MEMORY_IO mode.  (And why
wouldn't ioremap already handle that?)

This is how to allocate DMA-ready buffers that have certain
characteristics aren't useful only to the lowest level
drivers in the stack.  Drivers depend on alloc_coherent to
behave in the way you (originally) said DMA_MEMORY_MAP works.
The more detailed API specs (DMA-mapping.txt not DMA-API.txt)
are very clear that the behavior is like RAM.


> > So -- you're saying it's not a bug that a __GFP_NOFAIL|__GFP_WAIT
> > allocation be able to fail?  Curious.  I'd have thought the API
> > was clear about that.  Allocating 128 MB from a 1 MB region must
> > of course fail, but allocating one page just needs a wait/wakeup.
>
>
> It can *only* happen if you specify DMA_MEMORY_EXCLUSIVE; that preempts
> the GFP_ flags and the application must be coded with this in mind. 
> Otherwise it will respect the GFP_ flags.

You'd have to change the spec to allow that.  Wouldn't it be
a lot simpler to just pass the GFP flags down to that lowlevel
code, so it can eventually start doing what the highlevel code
told it to do?  :)

Special cases make for fragile systems.

- Dave



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/