[PATCH 1/5] ARM: define the PrimeCell DMA API

Dan Williams dan.j.williams at intel.com
Wed Mar 24 19:30:48 EDT 2010


On Wed, Mar 24, 2010 at 3:13 PM, Linus WALLEIJ
<linus.walleij at stericsson.com> wrote:
> [Dan]
>
>> What are your semantics for keeping the transaction information alive
>> until it gets consumed.  Currently the dma_ctrl_flags have the
>> DMA_CTRL_ACK bit to specify that the descriptor not be
>> recycled/destroyed until the client has a chance to attach a dependent
>> operation.  Seems you need something similar to indicate that the
>> residue information not be destroyed until it is consumed.  In other
>> words how does a client guarantee that the engine provides the
>> information it needs?
>
> Well exactly to avoid that kind of trouble I STOP (or PAUSE),
> get numer of bytes left, then terminate in that order. This
> keeps the descriptor.

But doesn't this assume you win the race with the engine completing
and cleaning up the descriptor before the 'stop' takes effect?

> Perhaps it's better to keep the two functions _pause() and
> _get_residue() and indicate that device_terminate_all()
> may destroy the state.

The configuration issues will always be arch specific I grant you
that, but I think we can define top level "operation query" and
"channel control" apis in a generic/extensible fashion.  Something
like:

1/ Change ->device_terminate_all() into ->device_control():

enum {
	DMA_TERMINATE_ALL, /* legacy semantics */
	DMA_PAUSE, /* your new primecell command semantics */
} dma_crtl;

int (*device_control)(struct dma_chan *chan, enum dma_ctrl cmd);


2/ Change device_is_tx_complete to device_tx_status along the lines of
what Guennadi and I talked about.

--
Dan



More information about the linux-arm-kernel mailing list