Vinod Koul <vinod.koul@xxxxxxxxx> writes: Hi Vinod, > On Fri, Mar 13, 2015 at 10:23:50AM +0100, Robert Jarzmik wrote: >> As these buffers are huge, the preparation is not negligible (a thousand >> hardware linked descriptors for 1 frame), and there are usually 6 frames in the >> ring. The pxa architecture (at least pxa27x) is quite old, and the cost to >> recalculate the descriptors chain is not negligible (2ms to 10ms). Moreover this >> time is needed to handle unqueued buffers : store them or compress them, etc ... > the dmaengine driver is not expected to do buffer mapping for slave cases, > so I am still not clear where the savings are coming from. Why are you talking about "buffer mapping" ? It's not a matter of mapping, it's _hardware_ descriptor calculation, ie. the structures the DMA IP consumes to perform the "linked list chain".. These structures are calculated out of the dma mapping done at driver level (which is done only once, at preparation). > You can keep the buffer ready or prepare ahead of time and submit when > required. Well, as long as the image capture is ongoing for that case, for obvious reasons I can't. As the userspace can dequeue and requeue it at any time, I can't "prepare in advance". It's the userspace which is driving the time, and userspace is not very real-time friendly ... >> As this is video capture, the real time aspect is important. Missing one frame >> here and there makes the video human unfriendly (as opposed to disk/io subsystem >> where this is not that important). > And preparing buffer ahead of time can help As I said above, it's userspace driven. >> Ah and to be more precise about what I'm thinking of [1], this is what I have in >> mind. I don't know if it's the way to go, but it will make the query more >> concrete. I also have a driver in preparation for pxa architecture with this, >> and I want to check if the requirements are met for me to upstream it. >> >> Cheers. >> >> Robert >> >> [1] Patch to support conversation > Before this pls read up on this Documentation/crypto/async-tx-api.txt > Section 3.3 Ah you mean the "ACK" flag is what I'm looking for, right ? I can use that, as long as I can resubmit a tx without "acking" it, which looks fine wrt the documentation you made me read. One more thing, there is another usecase, in which case you'll want to have a release function : - driver does a tx = dmaengine_prep_slave_sg() - driver is forced to shutdown : => dmaengine_terminate_all() The tx was never submitted. How should the resources by freed in that case ? Cheers. -- Robert -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
