On Thu, Feb 23, 2017 at 4:53 PM, Koul, Vinod <vinod.koul@xxxxxxxxx> wrote: > On Thu, 2017-02-23 at 16:41 -0800, Dan Williams wrote: >> On Thu, Feb 23, 2017 at 4:13 PM, Vinod Koul <vinod.koul@xxxxxxxxx> >> wrote: >> > >> > There have been discussions on need for change of dmaengine API for >> > a) allow sleepy invocation of the prepare descriptor so that drivers >> > can >> > do the runtime pm (maybe move into core as well) >> > b) split the prepare operation to allocate and new prepare methods >> >> I'm wondering if you should you go even further and move to a more >> idiomatic model where a generic request is prepared outside the driver >> and passed in, rather than the current situation of requiring the >> driver to wrap a dma_async_tx_descriptor inside it's internal command >> structure. > > Yes that's certainly a good idea. I will work on that on my way back > home. good use of a long flight time :) The current situation of arose from a consideration of minimizing the overhead of descriptor setup. However it is clear now that it was a mistake and led to the explosion of ->prep() methods and awkward non-uniform locking across drivers. -- 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
