On Mon, Nov 03, 2014 at 06:59:37PM +0200, Laurent Pinchart wrote: > > > Many other drivers suffer from the same problem. While I won't reject your > > > proposed fix, I would prefer a more generic approach. > > > > > > One option that has been discussed previously was to use a work queue to > > > delay starting the DMA transfer to an interruptible context where > > > pm_runtime_get_sync() could be called. However, as Russell pointed out > > > [1], > > > even that won't work in all cases as the DMA slave might need the transfer > > > to be started before enabling part of its hardware (OMAP audio seem to be > > > such a case). > > > > > > I've heard a rumor of a possible DMA engine rework to forbid calling the > > > descriptor preparation API from atomic context. This could be used as a > > > base to implement runtime PM, as DMA slave drivers should not prepare > > > descriptors if they don't need to use them. However that's a long term > > > plan, and we need a solution sooner than that. > > > > Well it is not a rumour :) > > I didn't want to put too much pressure on you by quoting you on that :-) > > > I have been contemplating that now that async_tx will be killed so we dont > > have to worry about that usage. For the slave dma usage, we can change the > > prepare API to be non atomic. I think the users will be okay with approach. > > This way drivers can use runtime pm calls in prepare. > > I'd certainly welcome that. There's a couple of users we will need to fix as > they call the prepare API from an atomic context. I'm thinking about ASoC > drivers in particular. ASoC is impler to fix as we can do this is ASoC prepare which is not atomic. So we would need to split prepare and submit on that > Do you have any time line in mind ? Not yet, perhpaps the one after next merge window will be good target. -- ~Vinod -- 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
