On 13 February 2017 at 16:47, Vinod Koul <vinod.koul@xxxxxxxxx> 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 >> >> you? >> > >> > 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 :) That sounds great! :-) > > 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. > Unfortunate not. We will have to meet some other time. Anyway, please keep me posted on any related topics. Kind regards Uffe -- 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
