[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