Messages in this thread | | | Date | Thu, 4 Dec 2008 11:26:10 -0700 | From | "Dan Williams" <> | Subject | Re: [PATCH] dmaengine: at_hdmac: new driver for the Atmel AHB DMA Controller |
| |
On Tue, Nov 25, 2008 at 8:21 AM, Nicolas Ferre <nicolas.ferre@atmel.com> wrote: >> >> They will be acknowledged by client code. Calls like async_memcpy >> assume that the the ack bit is clear by default so they can specify >> some actions to run at completion time. By setting it early, at >> descriptor allocation time, async_tx will get confused. > > This ack bit is annoying me : I cannot figure out how it is used for plain > memcopy/slave offload calls... > > Moreover, at recycle time, if I keep a descriptor chain as a whole, I have > to introduce another state for my descriptors : consumed but not freed yet > (with another linked list management). > If I only take care of the ACK flag for releasing descriptors, I loose the > dependency in my descriptor chain (in a multi-descriptor memcpy case).
Maybe I misread your driver... in the multi-descriptor memcpy case it is perfectly fine to set the ack-bit in the driver for all but the last descriptor in the chain. The client is only expected to attach dependencies at the end of the chain.
> Can I only consider this information without taking care of the chaining > dependency (and loose this information in a multi-descriptor operation) ?
You can lose it for all but the last descriptor.
> Or, may I drop this DMA_CTRL_ACK bit management as I do not have the > usefulness of redoing an operations on one descriptor (no xor engine) ? >
If you will never need to run async_memcpy and don't want to handle the bit then you could set DMA_PRIVATE and the channels would never be picked up by the async_tx api. But, I am not convinced we need to take that step yet.
> Kind regards, > -- > Nicolas Ferre >
Thanks, Dan
| |