Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM

From: Marek Szyprowski
Date: Tue Feb 14 2017 - 02:50:55 EST

Hi Vinod,

On 2017-02-13 16:47, Vinod Koul wrote:
On Mon, Feb 13, 2017 at 04:32:32PM +0100, Ulf Hansson wrote:

Although, I don't know of other examples, besides the runtime PM use
case, where non-atomic channel prepare/unprepare would make sense. Do
The primary ask for that has been to enable runtime_pm for drivers. It's not
a new ask, but we somehow haven't gotten around to do it.
Okay, I see.

As I said earlier, if we want to solve that problem a better idea is to
actually split the prepare as we discussed in [1]

This way we can get a non atomic descriptor allocate/prepare and release.
Yes we need to redesign the APIs to solve this, but if you guys are up for
it, I think we can do it and avoid any further round abouts :)
Adding/re-designing dma APIs is a viable option to solve the runtime PM case.

Changes would be needed for all related dma client drivers as well,
although if that's what we need to do - let's do it.
Yes, but do bear in mind that some cases do need atomic prepare. The primary
cases for DMA had that in mind and also submitting next transaction from the
callback (tasklet) context, so that won't go away.

It would help in other cases where clients know that they will not be in
atomic context so we provide additional non-atomic "allocation" followed by
prepare, so that drivers can split the work among these and people can do
runtime_pm and other things..
That for sharing the details.

It seems like some dma expert really need to be heavily involved if we
ever are going to complete this work. :-)
Sure, I will help out :)

If anyone of you are in Portland next week, then we can discuss these f2f. I
will try taking a stab at the new API design next week.

I'm not going to Portland, but I hope that you will have a fruitful discussion


Best regards
Marek Szyprowski, PhD
Samsung R&D Institute Poland