Messages in this thread | | | Subject | Re: [PATCHv4] DMAEngine: Define interleaved transfer request api | From | Vinod Koul <> | Date | Fri, 07 Oct 2011 11:15:46 +0530 |
| |
On Wed, 2011-10-05 at 11:14 -0700, Williams, Dan J wrote: > This new operation type strikes me as being in a similar vein to > commit a08abd8c "async_tx: structify submission arguments, add > scribble", in that we convert multiple submission arguments into one > description template. With some tweaks it could probably even cover > the DMA_CYCLIC, but probably could not cover the raid ops. In general > I'm concerned about operation type proliferation, so if we added this > one I'd like to see others removed. For slave cases, we have DMA_SLAVE, DMA_CYCLIC and some support memcpy as well.
I think we should have kept DMA_CYCLIC as a special case of DMA_SLAVE (thru a flag perhaps) not a new API, if all agree i can fix that up for 3.3
Thru this patch Jassi gave a very good try at merging DMA_SLAVE and memcpy, but more we debate this, I am still not convinced about merging memcpy and DMA_SLAVE yet.
I would still argue that if we split this on same lines as current mechanism, we have clean way to convey all details for both cases.
maybe I am being pessimist, but my vote goes for simpler things
Thoughts...?
For other memcpy cases like xor, etc, I don't think I have looked at finer detail to comment on it, but if we can make a generic mempy API with ops specified for what "type" of memcpy we could reduce it :)
-- ~Vinod
| |