Messages in this thread | | | Date | Tue, 25 Nov 2008 16:21:58 +0100 | From | Nicolas Ferre <> | Subject | Re: [PATCH] dmaengine: at_hdmac: new driver for the Atmel AHB DMA Controller |
| |
Dan Williams : > On Fri, Nov 14, 2008 at 9:34 AM, Nicolas Ferre <nicolas.ferre@atmel.com> wrote: >>>> include/linux/at_hdmac.h | 26 + >>> ...this header should be moved somewhere under arch/arm/include. >> This is where dw_dmac.h resides. Moreover, if one day this IP is implemented >> on a different architecture, it will be good not to reach it through >> arch/arm path. > > Ok, I won't gate acceptance on this since dw_dmac already set the > precedent, but shouldn't the header move after the IP has been > duplicated? Just my 2cents.
Ok, I follow your advice.
>>>> + memset(desc, 0, sizeof(struct at_desc)); >>>> + dma_async_tx_descriptor_init(&desc->txd, chan); >>>> + async_tx_ack(&desc->txd); >>> the DMA_CTRL_ACK bit is under control of the client. It should be >>> read-only to the driver (except for extra descriptors that the driver >>> creates on behalf of the client). >> This is precisely where the descriptors are been created so, I thought it >> should be ok to initialize this bit. Am I right ? >> > > 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).
Can I only consider this information without taking care of the chaining dependency (and loose this information in a multi-descriptor operation) ? 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) ?
Kind regards, -- Nicolas Ferre
| |