On Mon, Feb 13, 2017 at 04:32:32PM +0100, Ulf Hansson wrote:
[...]Sure, I will help out :)
Okay, I see.Although, I don't know of other examples, besides the runtime PM useThe primary ask for that has been to enable runtime_pm for drivers. It's not
case, where non-atomic channel prepare/unprepare would make sense. Do
a new ask, but we somehow haven't gotten around to do it.
That for sharing the details.Yes, but do bear in mind that some cases do need atomic prepare. The primaryAs I said earlier, if we want to solve that problem a better idea is toAdding/re-designing dma APIs is a viable option to solve the runtime PM case.
actually split the prepare as we discussed in 
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 :)
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.
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..
It seems like some dma expert really need to be heavily involved if we
ever are going to complete this work. :-)
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.