Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM
On 13 February 2017 at 16:47, Vinod Koulwrote: > 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
Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM
On 13 February 2017 at 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 >> >> 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
Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM
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 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 :) 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 there. [...] Best regards -- Marek Szyprowski, PhD Samsung R Institute Poland
Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM
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 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 :) 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 there. [...] Best regards -- Marek Szyprowski, PhD Samsung R Institute Poland
Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM
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 :) 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. > > [...] > > >> > >> 1) Dependencies between dma drivers and dma client drivers during system > >> PM. For example, a dma client driver needs the dma controller to be > >> operational (remain system resumed), until the dma client driver itself > >> becomes system suspended. > >> > >> The *only* currently available solution for this, is to try to system > >> suspend the dma controller later than the dma client, via using the *late > >> or the *noirq system PM callbacks. This works for most cases, but it > >> becomes a problem when the dma client also needs to be system suspended at > >> the *late or the *noirq phase. Clearly this solution that doesn't scale. > >> > >> Using device links explicitly solves this problem as it allows to specify > >> this dependency between devices. > > > > Yes this is an interesting point. Yes till now people have been doing above > > to workaround this problem, but hey this is not a unique to dmaengine. Any > > subsystem which provides services to others has this issue, so the solution > > much be driver or pm framework and not unique to dmaengine. > > I definitely agree, these problems aren't unique to the dmaengine > subsystem. Exactly how/where to manage them, that I guess, is the key > question. > > However, I can't resist from finding the device links useful, as those > really do address and solve our issues from a runtime/system PM point > of view. > > > > >> 2) We won't avoid dma clients from getting -EPROBE_DEFER when requesting > >> their dma channels in their ->probe() routines. This would be possible, if > >> we can set up the device links at device initialization. > > > > Well setting those links is not practical at initialization time. Most > > modern dma controllers feature a SW mux, with multiple clients connecting > > and requesting, would we link all of them? Most of times dmaengine driver > > wont know about those.. > > Okay, I see! > > Kind regards > Uffe -- ~Vinod
Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM
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 :) 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. > > [...] > > >> > >> 1) Dependencies between dma drivers and dma client drivers during system > >> PM. For example, a dma client driver needs the dma controller to be > >> operational (remain system resumed), until the dma client driver itself > >> becomes system suspended. > >> > >> The *only* currently available solution for this, is to try to system > >> suspend the dma controller later than the dma client, via using the *late > >> or the *noirq system PM callbacks. This works for most cases, but it > >> becomes a problem when the dma client also needs to be system suspended at > >> the *late or the *noirq phase. Clearly this solution that doesn't scale. > >> > >> Using device links explicitly solves this problem as it allows to specify > >> this dependency between devices. > > > > Yes this is an interesting point. Yes till now people have been doing above > > to workaround this problem, but hey this is not a unique to dmaengine. Any > > subsystem which provides services to others has this issue, so the solution > > much be driver or pm framework and not unique to dmaengine. > > I definitely agree, these problems aren't unique to the dmaengine > subsystem. Exactly how/where to manage them, that I guess, is the key > question. > > However, I can't resist from finding the device links useful, as those > really do address and solve our issues from a runtime/system PM point > of view. > > > > >> 2) We won't avoid dma clients from getting -EPROBE_DEFER when requesting > >> their dma channels in their ->probe() routines. This would be possible, if > >> we can set up the device links at device initialization. > > > > Well setting those links is not practical at initialization time. Most > > modern dma controllers feature a SW mux, with multiple clients connecting > > and requesting, would we link all of them? Most of times dmaengine driver > > wont know about those.. > > Okay, I see! > > Kind regards > Uffe -- ~Vinod
Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM
[...] >> 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. :-) [...] >> >> 1) Dependencies between dma drivers and dma client drivers during system >> PM. For example, a dma client driver needs the dma controller to be >> operational (remain system resumed), until the dma client driver itself >> becomes system suspended. >> >> The *only* currently available solution for this, is to try to system >> suspend the dma controller later than the dma client, via using the *late >> or the *noirq system PM callbacks. This works for most cases, but it >> becomes a problem when the dma client also needs to be system suspended at >> the *late or the *noirq phase. Clearly this solution that doesn't scale. >> >> Using device links explicitly solves this problem as it allows to specify >> this dependency between devices. > > Yes this is an interesting point. Yes till now people have been doing above > to workaround this problem, but hey this is not a unique to dmaengine. Any > subsystem which provides services to others has this issue, so the solution > much be driver or pm framework and not unique to dmaengine. I definitely agree, these problems aren't unique to the dmaengine subsystem. Exactly how/where to manage them, that I guess, is the key question. However, I can't resist from finding the device links useful, as those really do address and solve our issues from a runtime/system PM point of view. > >> 2) We won't avoid dma clients from getting -EPROBE_DEFER when requesting >> their dma channels in their ->probe() routines. This would be possible, if >> we can set up the device links at device initialization. > > Well setting those links is not practical at initialization time. Most > modern dma controllers feature a SW mux, with multiple clients connecting > and requesting, would we link all of them? Most of times dmaengine driver > wont know about those.. Okay, I see! Kind regards Uffe
Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM
[...] >> 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. :-) [...] >> >> 1) Dependencies between dma drivers and dma client drivers during system >> PM. For example, a dma client driver needs the dma controller to be >> operational (remain system resumed), until the dma client driver itself >> becomes system suspended. >> >> The *only* currently available solution for this, is to try to system >> suspend the dma controller later than the dma client, via using the *late >> or the *noirq system PM callbacks. This works for most cases, but it >> becomes a problem when the dma client also needs to be system suspended at >> the *late or the *noirq phase. Clearly this solution that doesn't scale. >> >> Using device links explicitly solves this problem as it allows to specify >> this dependency between devices. > > Yes this is an interesting point. Yes till now people have been doing above > to workaround this problem, but hey this is not a unique to dmaengine. Any > subsystem which provides services to others has this issue, so the solution > much be driver or pm framework and not unique to dmaengine. I definitely agree, these problems aren't unique to the dmaengine subsystem. Exactly how/where to manage them, that I guess, is the key question. However, I can't resist from finding the device links useful, as those really do address and solve our issues from a runtime/system PM point of view. > >> 2) We won't avoid dma clients from getting -EPROBE_DEFER when requesting >> their dma channels in their ->probe() routines. This would be possible, if >> we can set up the device links at device initialization. > > Well setting those links is not practical at initialization time. Most > modern dma controllers feature a SW mux, with multiple clients connecting > and requesting, would we link all of them? Most of times dmaengine driver > wont know about those.. Okay, I see! Kind regards Uffe
Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM
[...] >> The only related PM thing, that shall be the decision of the driver, >> is whether it wants to enable runtime PM or not, during ->probe(). > > > So do you want to create the links during the DMAengine driver probe? How do > you > plan to find all the client devices? Please note that you really want to > create > links to devices which will really use the DMA engine calls. Some client > drivers might decide in runtime weather to use DMA engine or not, depending > on > other data. I don't have great plan, just wanted to share my thoughts around the problems we want to solve. [...] >> >> If we could set up the device link already at device initialization, >> it should also be possible to avoid getting -EPROBE_DEFER for dma >> client drivers when requesting their dma channels. > > > At the first glance this sounds like an ultimate solution for all problems, > but I don't think that device links can be used this way. If I get it right, > you would like to create links on client device initialization, preferably > somewhere in the kernel driver core. This will be handled somehow by a > completely generic code, which will create a link each pair of devices, > which are connected by a phandle. Is this what you meant? Please note that > that time no driver for both client and provider are probed. IMHO that > doesn't look like a right generic approach > > How that code will know get following information: > 1. is it really needed to create a link for given device pair? > 2. what link flags should it use? > 3. what about circular dependencies? > 4. what about runtime optional dependencies? > 5. what about non-dt platforms? acpi? > To give a good answer of these questions, I need to spend more time investigating. However, from a top-level point of view, I think the device links seems like the perfect match for solving the runtime/system PM problems. No matter whether we can set up the links at device initialization time, driver probe or whatever time. > This looks like another newer ending story of "how can we avoid deferred > probe > in a generic way". IMHO we should first solve the problem of irq-safe > runtime > PM in DMA engine drivers first. I proposed how it can be done with device > links. > With no changes in the client API. Later if one decide to extend the client > API > in a way it will allow other runtime PM implementation - I see no problem to > convert pl330 driver to the new approach, but for the time being - this > would > be the easiest way to get it really functional. Agree, let's drop the deferred probe topic from the discussions - it's just going to be overwhelming. :-) [...] >> So besides solving the irq-safe issue for dma driver, using the >> device-links has additionally two advantages. I already mentioned the >> -EPROBE_DEFER issue above. > > > Not really. IMHO device links can be properly established once both drivers > are probed... Okay. > >> >> The second thing, is the runtime/system PM relations we get for free >> by using the links. In other words, the dma driver/core don't need to >> care about dealing with pm_runtime_get|put() as that would be managed >> by the dma client driver. > > > IMHO there might be drivers which don't want to use device links based > runtime > PM in favor of irq-safe PM or something else. This should be really left to > drivers. Okay. Kind regards Uffe
Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM
[...] >> The only related PM thing, that shall be the decision of the driver, >> is whether it wants to enable runtime PM or not, during ->probe(). > > > So do you want to create the links during the DMAengine driver probe? How do > you > plan to find all the client devices? Please note that you really want to > create > links to devices which will really use the DMA engine calls. Some client > drivers might decide in runtime weather to use DMA engine or not, depending > on > other data. I don't have great plan, just wanted to share my thoughts around the problems we want to solve. [...] >> >> If we could set up the device link already at device initialization, >> it should also be possible to avoid getting -EPROBE_DEFER for dma >> client drivers when requesting their dma channels. > > > At the first glance this sounds like an ultimate solution for all problems, > but I don't think that device links can be used this way. If I get it right, > you would like to create links on client device initialization, preferably > somewhere in the kernel driver core. This will be handled somehow by a > completely generic code, which will create a link each pair of devices, > which are connected by a phandle. Is this what you meant? Please note that > that time no driver for both client and provider are probed. IMHO that > doesn't look like a right generic approach > > How that code will know get following information: > 1. is it really needed to create a link for given device pair? > 2. what link flags should it use? > 3. what about circular dependencies? > 4. what about runtime optional dependencies? > 5. what about non-dt platforms? acpi? > To give a good answer of these questions, I need to spend more time investigating. However, from a top-level point of view, I think the device links seems like the perfect match for solving the runtime/system PM problems. No matter whether we can set up the links at device initialization time, driver probe or whatever time. > This looks like another newer ending story of "how can we avoid deferred > probe > in a generic way". IMHO we should first solve the problem of irq-safe > runtime > PM in DMA engine drivers first. I proposed how it can be done with device > links. > With no changes in the client API. Later if one decide to extend the client > API > in a way it will allow other runtime PM implementation - I see no problem to > convert pl330 driver to the new approach, but for the time being - this > would > be the easiest way to get it really functional. Agree, let's drop the deferred probe topic from the discussions - it's just going to be overwhelming. :-) [...] >> So besides solving the irq-safe issue for dma driver, using the >> device-links has additionally two advantages. I already mentioned the >> -EPROBE_DEFER issue above. > > > Not really. IMHO device links can be properly established once both drivers > are probed... Okay. > >> >> The second thing, is the runtime/system PM relations we get for free >> by using the links. In other words, the dma driver/core don't need to >> care about dealing with pm_runtime_get|put() as that would be managed >> by the dma client driver. > > > IMHO there might be drivers which don't want to use device links based > runtime > PM in favor of irq-safe PM or something else. This should be really left to > drivers. Okay. Kind regards Uffe
Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM
On Mon, Feb 13, 2017 at 01:15:27PM +0100, Marek Szyprowski 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? > > Changing GFP_ATOMIC to GFP_KERNEL in some calls in the DMA engine drivers > would be also a nice present for the memory management subsystem if there > is no real reason to drain atomic pools. The reason for the calls being atomic is that they will be invoked from atomic context. All prepare callbacks, submit, issue_pending are in that context. You have to be mindful that we can prepare and issue next txn from dmaengine callback which is a tasklet. > >>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. > > > >[...] > > > >>>So besides solving the irq-safe issue for dma driver, using the > >>>device-links has additionally two advantages. I already mentioned the > >>>-EPROBE_DEFER issue above. > >>> > >>>The second thing, is the runtime/system PM relations we get for free > >>>by using the links. In other words, the dma driver/core don't need to > >>>care about dealing with pm_runtime_get|put() as that would be managed > >>>by the dma client driver. > >>Yeah sorry took me a while to figure that out :), If we do a different API > >>then dmaengine core can call pm_runtime_get|put() from non-atomic context. > >Yes, it can and this works from runtime PM point of view. But the > >following issues would remain unsolved. > > > >1) > >Dependencies between dma drivers and dma client drivers during system > >PM. For example, a dma client driver needs the dma controller to be > >operational (remain system resumed), until the dma client driver > >itself becomes system suspended. > > > >The *only* currently available solution for this, is to try to system > >suspend the dma controller later than the dma client, via using the > >*late or the *noirq system PM callbacks. This works for most cases, > >but it becomes a problem when the dma client also needs to be system > >suspended at the *late or the *noirq phase. Clearly this solution that > >doesn't scale. > > > >Using device links explicitly solves this problem as it allows to > >specify this dependency between devices. > > Frankly, then creating device links has to be added to EVERY subsystem, > which involves getting access to the resources provided by the other > device. More or less this will apply to all kernel frameworks, which > provide kind of ABC_get_XYZ(dev, ...) functions (like clk_get, phy_get, > dma_chan_get, ...). Sounds like a topic for another lng discussion. Yeah, that was my view too :-) > >2) > >We won't avoid dma clients from getting -EPROBE_DEFER when requesting > >their dma channels in their ->probe() routines. This would be > >possible, if we can set up the device links at device initialization. > > The question is which core (DMA engine?, kernel device subsystem?) and > how to find all clients before they call dma_chan_get(). Thanks -- ~Vinod
Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM
On Mon, Feb 13, 2017 at 01:15:27PM +0100, Marek Szyprowski 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? > > Changing GFP_ATOMIC to GFP_KERNEL in some calls in the DMA engine drivers > would be also a nice present for the memory management subsystem if there > is no real reason to drain atomic pools. The reason for the calls being atomic is that they will be invoked from atomic context. All prepare callbacks, submit, issue_pending are in that context. You have to be mindful that we can prepare and issue next txn from dmaengine callback which is a tasklet. > >>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. > > > >[...] > > > >>>So besides solving the irq-safe issue for dma driver, using the > >>>device-links has additionally two advantages. I already mentioned the > >>>-EPROBE_DEFER issue above. > >>> > >>>The second thing, is the runtime/system PM relations we get for free > >>>by using the links. In other words, the dma driver/core don't need to > >>>care about dealing with pm_runtime_get|put() as that would be managed > >>>by the dma client driver. > >>Yeah sorry took me a while to figure that out :), If we do a different API > >>then dmaengine core can call pm_runtime_get|put() from non-atomic context. > >Yes, it can and this works from runtime PM point of view. But the > >following issues would remain unsolved. > > > >1) > >Dependencies between dma drivers and dma client drivers during system > >PM. For example, a dma client driver needs the dma controller to be > >operational (remain system resumed), until the dma client driver > >itself becomes system suspended. > > > >The *only* currently available solution for this, is to try to system > >suspend the dma controller later than the dma client, via using the > >*late or the *noirq system PM callbacks. This works for most cases, > >but it becomes a problem when the dma client also needs to be system > >suspended at the *late or the *noirq phase. Clearly this solution that > >doesn't scale. > > > >Using device links explicitly solves this problem as it allows to > >specify this dependency between devices. > > Frankly, then creating device links has to be added to EVERY subsystem, > which involves getting access to the resources provided by the other > device. More or less this will apply to all kernel frameworks, which > provide kind of ABC_get_XYZ(dev, ...) functions (like clk_get, phy_get, > dma_chan_get, ...). Sounds like a topic for another lng discussion. Yeah, that was my view too :-) > >2) > >We won't avoid dma clients from getting -EPROBE_DEFER when requesting > >their dma channels in their ->probe() routines. This would be > >possible, if we can set up the device links at device initialization. > > The question is which core (DMA engine?, kernel device subsystem?) and > how to find all clients before they call dma_chan_get(). Thanks -- ~Vinod
Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM
On Mon, Feb 13, 2017 at 12:11:54PM +0100, Ulf Hansson wrote: > >> > >> If we could set up the device link already at device initialization, > >> it should also be possible to avoid getting -EPROBE_DEFER for dma > >> client drivers when requesting their dma channels. > > > > Well if we defer then driver will regiser with dmaengine after it is > > probed, so a client will either get a channel or not. IOW we won't get > > -EPROBE_DEFER. > > I didn't quite get this. What do you mean by "if we defer..."? > > Defer into *what* and defer of *what*? Could you please elaborate. Nevermind I think below is much interesting now.. > >> Again, allow me to fill in. This issue exists for all ARM SoC which > >> has a dma controller residing in a PM domain. I think that is quite > >> many. > >> > >> Currently the only solution I have seen for this problem, but which I > >> really dislike. That is, each dma client driver requests/releases > >> their dma channel from their respective ->runtime_suspend|resume() > >> callbacks - then the dma driver can use the dma request/release hooks, > >> to do pm_runtime_get|put() which then becomes non-irq-safe. > > > > Yeah that is not the best way to do. But looking at it current one doesnt > > seem best fit either. > > > > So on seeing the device_link_add() I was thinking that this is some SoC > > dependent problem being solved whereas the problem statmement is non-atomic > > channel prepare. > > You may be right. > > 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. > > 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.. > >> So besides solving the irq-safe issue for dma driver, using the > >> device-links has additionally two advantages. I already mentioned the > >> -EPROBE_DEFER issue above. > >> > >> The second thing, is the runtime/system PM relations we get for free by > >> using the links. In other words, the dma driver/core don't need to care > >> about dealing with pm_runtime_get|put() as that would be managed by the > >> dma client driver. > > > > Yeah sorry took me a while to figure that out :), If we do a different > > API then dmaengine core can call pm_runtime_get|put() from non-atomic > > context. > > Yes, it can and this works from runtime PM point of view. But the > following issues would remain unsolved. > > 1) Dependencies between dma drivers and dma client drivers during system > PM. For example, a dma client driver needs the dma controller to be > operational (remain system resumed), until the dma client driver itself > becomes system suspended. > > The *only* currently available solution for this, is to try to system > suspend the dma controller later than the dma client, via using the *late > or the *noirq system PM callbacks. This works for most cases, but it > becomes a problem when the dma client also needs to be system suspended at > the *late or the *noirq phase. Clearly this solution that doesn't scale. > > Using device links explicitly solves this problem as it allows to specify > this dependency between devices. Yes this is an interesting point. Yes till now people have been doing above to workaround this problem, but hey this is not a unique to dmaengine. Any subsystem which provides services to others has this issue, so the solution much be driver or pm framework and not unique to dmaengine. > 2) We won't avoid dma clients from getting -EPROBE_DEFER when requesting > their dma channels in their ->probe() routines. This would be possible, if > we can set up the device links at device initialization. Well setting those links is not practical at initialization time. Most modern dma controllers feature a SW mux, with multiple clients connecting and requesting, would we link all of them? Most of times dmaengine driver wont know about those.. Thanks --
Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM
On Mon, Feb 13, 2017 at 12:11:54PM +0100, Ulf Hansson wrote: > >> > >> If we could set up the device link already at device initialization, > >> it should also be possible to avoid getting -EPROBE_DEFER for dma > >> client drivers when requesting their dma channels. > > > > Well if we defer then driver will regiser with dmaengine after it is > > probed, so a client will either get a channel or not. IOW we won't get > > -EPROBE_DEFER. > > I didn't quite get this. What do you mean by "if we defer..."? > > Defer into *what* and defer of *what*? Could you please elaborate. Nevermind I think below is much interesting now.. > >> Again, allow me to fill in. This issue exists for all ARM SoC which > >> has a dma controller residing in a PM domain. I think that is quite > >> many. > >> > >> Currently the only solution I have seen for this problem, but which I > >> really dislike. That is, each dma client driver requests/releases > >> their dma channel from their respective ->runtime_suspend|resume() > >> callbacks - then the dma driver can use the dma request/release hooks, > >> to do pm_runtime_get|put() which then becomes non-irq-safe. > > > > Yeah that is not the best way to do. But looking at it current one doesnt > > seem best fit either. > > > > So on seeing the device_link_add() I was thinking that this is some SoC > > dependent problem being solved whereas the problem statmement is non-atomic > > channel prepare. > > You may be right. > > 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. > > 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.. > >> So besides solving the irq-safe issue for dma driver, using the > >> device-links has additionally two advantages. I already mentioned the > >> -EPROBE_DEFER issue above. > >> > >> The second thing, is the runtime/system PM relations we get for free by > >> using the links. In other words, the dma driver/core don't need to care > >> about dealing with pm_runtime_get|put() as that would be managed by the > >> dma client driver. > > > > Yeah sorry took me a while to figure that out :), If we do a different > > API then dmaengine core can call pm_runtime_get|put() from non-atomic > > context. > > Yes, it can and this works from runtime PM point of view. But the > following issues would remain unsolved. > > 1) Dependencies between dma drivers and dma client drivers during system > PM. For example, a dma client driver needs the dma controller to be > operational (remain system resumed), until the dma client driver itself > becomes system suspended. > > The *only* currently available solution for this, is to try to system > suspend the dma controller later than the dma client, via using the *late > or the *noirq system PM callbacks. This works for most cases, but it > becomes a problem when the dma client also needs to be system suspended at > the *late or the *noirq phase. Clearly this solution that doesn't scale. > > Using device links explicitly solves this problem as it allows to specify > this dependency between devices. Yes this is an interesting point. Yes till now people have been doing above to workaround this problem, but hey this is not a unique to dmaengine. Any subsystem which provides services to others has this issue, so the solution much be driver or pm framework and not unique to dmaengine. > 2) We won't avoid dma clients from getting -EPROBE_DEFER when requesting > their dma channels in their ->probe() routines. This would be possible, if > we can set up the device links at device initialization. Well setting those links is not practical at initialization time. Most modern dma controllers feature a SW mux, with multiple clients connecting and requesting, would we link all of them? Most of times dmaengine driver wont know about those.. Thanks --
Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM
Hi Ulf, On 2017-02-13 12:11, Ulf Hansson wrote: If we could set up the device link already at device initialization, it should also be possible to avoid getting -EPROBE_DEFER for dma client drivers when requesting their dma channels. Well if we defer then driver will regiser with dmaengine after it is probed, so a client will either get a channel or not. IOW we won't get -EPROBE_DEFER. I didn't quite get this. What do you mean by "if we defer..."? Defer into *what* and defer of *what*? Could you please elaborate. [...] Again, allow me to fill in. This issue exists for all ARM SoC which has a dma controller residing in a PM domain. I think that is quite many. Currently the only solution I have seen for this problem, but which I really dislike. That is, each dma client driver requests/releases their dma channel from their respective ->runtime_suspend|resume() callbacks - then the dma driver can use the dma request/release hooks, to do pm_runtime_get|put() which then becomes non-irq-safe. Yeah that is not the best way to do. But looking at it current one doesnt seem best fit either. So on seeing the device_link_add() I was thinking that this is some SoC dependent problem being solved whereas the problem statmement is non-atomic channel prepare. You may be right. 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? Changing GFP_ATOMIC to GFP_KERNEL in some calls in the DMA engine drivers would be also a nice present for the memory management subsystem if there is no real reason to drain atomic pools. 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. [...] So besides solving the irq-safe issue for dma driver, using the device-links has additionally two advantages. I already mentioned the -EPROBE_DEFER issue above. The second thing, is the runtime/system PM relations we get for free by using the links. In other words, the dma driver/core don't need to care about dealing with pm_runtime_get|put() as that would be managed by the dma client driver. Yeah sorry took me a while to figure that out :), If we do a different API then dmaengine core can call pm_runtime_get|put() from non-atomic context. Yes, it can and this works from runtime PM point of view. But the following issues would remain unsolved. 1) Dependencies between dma drivers and dma client drivers during system PM. For example, a dma client driver needs the dma controller to be operational (remain system resumed), until the dma client driver itself becomes system suspended. The *only* currently available solution for this, is to try to system suspend the dma controller later than the dma client, via using the *late or the *noirq system PM callbacks. This works for most cases, but it becomes a problem when the dma client also needs to be system suspended at the *late or the *noirq phase. Clearly this solution that doesn't scale. Using device links explicitly solves this problem as it allows to specify this dependency between devices. Frankly, then creating device links has to be added to EVERY subsystem, which involves getting access to the resources provided by the other device. More or less this will apply to all kernel frameworks, which provide kind of ABC_get_XYZ(dev, ...) functions (like clk_get, phy_get, dma_chan_get, ...). Sounds like a topic for another lng discussion. 2) We won't avoid dma clients from getting -EPROBE_DEFER when requesting their dma channels in their ->probe() routines. This would be possible, if we can set up the device links at device initialization. The question is which core (DMA engine?, kernel device subsystem?) and how to find all clients before they call dma_chan_get(). Best regards -- Marek Szyprowski, PhD Samsung R Institute Poland
Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM
Hi Ulf, On 2017-02-13 12:11, Ulf Hansson wrote: If we could set up the device link already at device initialization, it should also be possible to avoid getting -EPROBE_DEFER for dma client drivers when requesting their dma channels. Well if we defer then driver will regiser with dmaengine after it is probed, so a client will either get a channel or not. IOW we won't get -EPROBE_DEFER. I didn't quite get this. What do you mean by "if we defer..."? Defer into *what* and defer of *what*? Could you please elaborate. [...] Again, allow me to fill in. This issue exists for all ARM SoC which has a dma controller residing in a PM domain. I think that is quite many. Currently the only solution I have seen for this problem, but which I really dislike. That is, each dma client driver requests/releases their dma channel from their respective ->runtime_suspend|resume() callbacks - then the dma driver can use the dma request/release hooks, to do pm_runtime_get|put() which then becomes non-irq-safe. Yeah that is not the best way to do. But looking at it current one doesnt seem best fit either. So on seeing the device_link_add() I was thinking that this is some SoC dependent problem being solved whereas the problem statmement is non-atomic channel prepare. You may be right. 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? Changing GFP_ATOMIC to GFP_KERNEL in some calls in the DMA engine drivers would be also a nice present for the memory management subsystem if there is no real reason to drain atomic pools. 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. [...] So besides solving the irq-safe issue for dma driver, using the device-links has additionally two advantages. I already mentioned the -EPROBE_DEFER issue above. The second thing, is the runtime/system PM relations we get for free by using the links. In other words, the dma driver/core don't need to care about dealing with pm_runtime_get|put() as that would be managed by the dma client driver. Yeah sorry took me a while to figure that out :), If we do a different API then dmaengine core can call pm_runtime_get|put() from non-atomic context. Yes, it can and this works from runtime PM point of view. But the following issues would remain unsolved. 1) Dependencies between dma drivers and dma client drivers during system PM. For example, a dma client driver needs the dma controller to be operational (remain system resumed), until the dma client driver itself becomes system suspended. The *only* currently available solution for this, is to try to system suspend the dma controller later than the dma client, via using the *late or the *noirq system PM callbacks. This works for most cases, but it becomes a problem when the dma client also needs to be system suspended at the *late or the *noirq phase. Clearly this solution that doesn't scale. Using device links explicitly solves this problem as it allows to specify this dependency between devices. Frankly, then creating device links has to be added to EVERY subsystem, which involves getting access to the resources provided by the other device. More or less this will apply to all kernel frameworks, which provide kind of ABC_get_XYZ(dev, ...) functions (like clk_get, phy_get, dma_chan_get, ...). Sounds like a topic for another lng discussion. 2) We won't avoid dma clients from getting -EPROBE_DEFER when requesting their dma channels in their ->probe() routines. This would be possible, if we can set up the device links at device initialization. The question is which core (DMA engine?, kernel device subsystem?) and how to find all clients before they call dma_chan_get(). Best regards -- Marek Szyprowski, PhD Samsung R Institute Poland
Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM
Hi Vinod, On 2017-02-13 03:03, Vinod Koul wrote: On Fri, Feb 10, 2017 at 02:57:09PM +0100, Ulf Hansson wrote: On 10 February 2017 at 12:51, Marek Szyprowskiwrote: On 2017-02-10 05:50, Vinod Koul wrote: On Thu, Feb 09, 2017 at 03:22:51PM +0100, Marek Szyprowski wrote: +static int pl330_set_slave(struct dma_chan *chan, struct device *slave) +{ + struct dma_pl330_chan *pch = to_pchan(chan); + struct pl330_dmac *pl330 = pch->dmac; + int i; + + mutex_lock(>rpm_lock); + + for (i = 0; i < pl330->num_peripherals; i++) { + if (pl330->peripherals[i].chan.slave == slave && + pl330->peripherals[i].slave_link) { + pch->slave_link = pl330->peripherals[i].slave_link; + goto done; + } + } + + pch->slave_link = device_link_add(slave, pl330->ddma.dev, + DL_FLAG_PM_RUNTIME | DL_FLAG_RPM_ACTIVE); So you are going to add the link on channel allocation and tear down on the freeup. Right. Channel allocation is typically done once per driver operation and it won't hurt system performance. I am not sure I really like the idea here. Could you point what's wrong with it? First, these thing shouldn't be handled in the drivers. These things should be set in core and each driver setting the links doesn't sound great to me. Which core? And what's wrong with the device links? They have been introduced to model relations between devices that are behind the usual parent/child/bus topology. I think Vinod mean the dmaengine core. Which also would make perfect sense to me as it would benefit all dma drivers. Right. The only related PM thing, that shall be the decision of the driver, is whether it wants to enable runtime PM or not, during ->probe(). We can do pm_runtime_enabled() to check and that and do when enabled.. Another subtle issue is that there can be only one link between devices, but it is common to request more than one channel per client device (for example "tx" and "rx"), but this can be handled by internal reference counting. Second, should the link be always there and we only mange the state? Here it seems that we have link being created and destroyed, so why not mark it ACTIVE and DORMANT instead... Link state is managed by device core and should not be touched by the drivers. It is related to both provider and consumer drivers states (probed/not probed/etc). Second we would need to create those links first. The question is where to create them then. Just to fill in, to me this is really also the key question. If we could set up the device link already at device initialization, it should also be possible to avoid getting -EPROBE_DEFER for dma client drivers when requesting their dma channels. Well if we defer then driver will regiser with dmaengine after it is probed, so a client will either get a channel or not. IOW we won't get -EPROBE_DEFER. I don't get how this will work. IMHO the link should be created WHEN client driver requests the channel, because otherwise we will get links that might be not used at all (for example optional DMA usage, but the link will force DMA controller to active state even if client device doesn't want to use DMA at all). So if client requests it for the first time and the DMA engine has not been probed yet, there is no way to avoid -EPROBE_DEFER. Lastly, looking at th description of the issue here, am perceiving (maybe my understanding is not quite right here) that you have an IP block in SoC which has multiple things and share common stuff and doing right PM is a challenge for you, right? Nope. Doing right PM in my SoC is not that complex and I would say it is rather typical for any embedded stuff. It works fine (in terms of the power consumption reduction) when all drivers simply properly manage their runtime PM state, thus if device is not in use, the state is set to suspended and finally, the power domain gets turned off. I've used device links for PM only because the current DMA engine API is simply insufficient to implement it in the other way. I want to let a power domain, which contains a few devices, among those a PL330 device, to get turned off when there is no activity. Handling power domain power on / off requires non-atomic context, what is typical for runtime pm calls. For that I need to have non-irq-safe runtime pm implemented for all devices that belongs to that domains. Again, allow me to fill in. This issue exists for all ARM SoC which has a dma controller residing in a PM domain. I think that is quite many. Currently the only solution I have seen for this problem, but which I really dislike. That is, each dma client driver requests/releases their dma channel from their respective ->runtime_suspend|resume() callbacks - then the dma driver can use the dma request/release hooks, to do pm_runtime_get|put() which then becomes non-irq-safe.
Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM
Hi Vinod, On 2017-02-13 03:03, Vinod Koul wrote: On Fri, Feb 10, 2017 at 02:57:09PM +0100, Ulf Hansson wrote: On 10 February 2017 at 12:51, Marek Szyprowski wrote: On 2017-02-10 05:50, Vinod Koul wrote: On Thu, Feb 09, 2017 at 03:22:51PM +0100, Marek Szyprowski wrote: +static int pl330_set_slave(struct dma_chan *chan, struct device *slave) +{ + struct dma_pl330_chan *pch = to_pchan(chan); + struct pl330_dmac *pl330 = pch->dmac; + int i; + + mutex_lock(>rpm_lock); + + for (i = 0; i < pl330->num_peripherals; i++) { + if (pl330->peripherals[i].chan.slave == slave && + pl330->peripherals[i].slave_link) { + pch->slave_link = pl330->peripherals[i].slave_link; + goto done; + } + } + + pch->slave_link = device_link_add(slave, pl330->ddma.dev, + DL_FLAG_PM_RUNTIME | DL_FLAG_RPM_ACTIVE); So you are going to add the link on channel allocation and tear down on the freeup. Right. Channel allocation is typically done once per driver operation and it won't hurt system performance. I am not sure I really like the idea here. Could you point what's wrong with it? First, these thing shouldn't be handled in the drivers. These things should be set in core and each driver setting the links doesn't sound great to me. Which core? And what's wrong with the device links? They have been introduced to model relations between devices that are behind the usual parent/child/bus topology. I think Vinod mean the dmaengine core. Which also would make perfect sense to me as it would benefit all dma drivers. Right. The only related PM thing, that shall be the decision of the driver, is whether it wants to enable runtime PM or not, during ->probe(). We can do pm_runtime_enabled() to check and that and do when enabled.. Another subtle issue is that there can be only one link between devices, but it is common to request more than one channel per client device (for example "tx" and "rx"), but this can be handled by internal reference counting. Second, should the link be always there and we only mange the state? Here it seems that we have link being created and destroyed, so why not mark it ACTIVE and DORMANT instead... Link state is managed by device core and should not be touched by the drivers. It is related to both provider and consumer drivers states (probed/not probed/etc). Second we would need to create those links first. The question is where to create them then. Just to fill in, to me this is really also the key question. If we could set up the device link already at device initialization, it should also be possible to avoid getting -EPROBE_DEFER for dma client drivers when requesting their dma channels. Well if we defer then driver will regiser with dmaengine after it is probed, so a client will either get a channel or not. IOW we won't get -EPROBE_DEFER. I don't get how this will work. IMHO the link should be created WHEN client driver requests the channel, because otherwise we will get links that might be not used at all (for example optional DMA usage, but the link will force DMA controller to active state even if client device doesn't want to use DMA at all). So if client requests it for the first time and the DMA engine has not been probed yet, there is no way to avoid -EPROBE_DEFER. Lastly, looking at th description of the issue here, am perceiving (maybe my understanding is not quite right here) that you have an IP block in SoC which has multiple things and share common stuff and doing right PM is a challenge for you, right? Nope. Doing right PM in my SoC is not that complex and I would say it is rather typical for any embedded stuff. It works fine (in terms of the power consumption reduction) when all drivers simply properly manage their runtime PM state, thus if device is not in use, the state is set to suspended and finally, the power domain gets turned off. I've used device links for PM only because the current DMA engine API is simply insufficient to implement it in the other way. I want to let a power domain, which contains a few devices, among those a PL330 device, to get turned off when there is no activity. Handling power domain power on / off requires non-atomic context, what is typical for runtime pm calls. For that I need to have non-irq-safe runtime pm implemented for all devices that belongs to that domains. Again, allow me to fill in. This issue exists for all ARM SoC which has a dma controller residing in a PM domain. I think that is quite many. Currently the only solution I have seen for this problem, but which I really dislike. That is, each dma client driver requests/releases their dma channel from their respective ->runtime_suspend|resume() callbacks - then the dma driver can use the dma request/release hooks, to do pm_runtime_get|put() which then becomes non-irq-safe. Yeah that is not the best
Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM
Hi Ulf, On 2017-02-10 14:57, Ulf Hansson wrote: On 10 February 2017 at 12:51, Marek Szyprowskiwrote: On 2017-02-10 05:50, Vinod Koul wrote: On Thu, Feb 09, 2017 at 03:22:51PM +0100, Marek Szyprowski wrote: +static int pl330_set_slave(struct dma_chan *chan, struct device *slave) +{ + struct dma_pl330_chan *pch = to_pchan(chan); + struct pl330_dmac *pl330 = pch->dmac; + int i; + + mutex_lock(>rpm_lock); + + for (i = 0; i < pl330->num_peripherals; i++) { + if (pl330->peripherals[i].chan.slave == slave && + pl330->peripherals[i].slave_link) { + pch->slave_link = pl330->peripherals[i].slave_link; + goto done; + } + } + + pch->slave_link = device_link_add(slave, pl330->ddma.dev, + DL_FLAG_PM_RUNTIME | DL_FLAG_RPM_ACTIVE); So you are going to add the link on channel allocation and tear down on the freeup. Right. Channel allocation is typically done once per driver operation and it won't hurt system performance. I am not sure I really like the idea here. Could you point what's wrong with it? First, these thing shouldn't be handled in the drivers. These things should be set in core and each driver setting the links doesn't sound great to me. Which core? And what's wrong with the device links? They have been introduced to model relations between devices that are behind the usual parent/child/bus topology. I think Vinod mean the dmaengine core. Which also would make perfect sense to me as it would benefit all dma drivers. The only related PM thing, that shall be the decision of the driver, is whether it wants to enable runtime PM or not, during ->probe(). So do you want to create the links during the DMAengine driver probe? How do you plan to find all the client devices? Please note that you really want to create links to devices which will really use the DMA engine calls. Some client drivers might decide in runtime weather to use DMA engine or not, depending on other data. Second, should the link be always there and we only mange the state? Here it seems that we have link being created and destroyed, so why not mark it ACTIVE and DORMANT instead... Link state is managed by device core and should not be touched by the drivers. It is related to both provider and consumer drivers states (probed/not probed/etc). Second we would need to create those links first. The question is where to create them then. Just to fill in, to me this is really also the key question. If we could set up the device link already at device initialization, it should also be possible to avoid getting -EPROBE_DEFER for dma client drivers when requesting their dma channels. At the first glance this sounds like an ultimate solution for all problems, but I don't think that device links can be used this way. If I get it right, you would like to create links on client device initialization, preferably somewhere in the kernel driver core. This will be handled somehow by a completely generic code, which will create a link each pair of devices, which are connected by a phandle. Is this what you meant? Please note that that time no driver for both client and provider are probed. IMHO that doesn't look like a right generic approach How that code will know get following information: 1. is it really needed to create a link for given device pair? 2. what link flags should it use? 3. what about circular dependencies? 4. what about runtime optional dependencies? 5. what about non-dt platforms? acpi? This looks like another newer ending story of "how can we avoid deferred probe in a generic way". IMHO we should first solve the problem of irq-safe runtime PM in DMA engine drivers first. I proposed how it can be done with device links. With no changes in the client API. Later if one decide to extend the client API in a way it will allow other runtime PM implementation - I see no problem to convert pl330 driver to the new approach, but for the time being - this would be the easiest way to get it really functional. Lastly, looking at th description of the issue here, am perceiving (maybe my understanding is not quite right here) that you have an IP block in SoC which has multiple things and share common stuff and doing right PM is a challenge for you, right? Nope. Doing right PM in my SoC is not that complex and I would say it is rather typical for any embedded stuff. It works fine (in terms of the power consumption reduction) when all drivers simply properly manage their runtime PM state, thus if device is not in use, the state is set to suspended and finally, the power domain gets turned off. I've used device links for PM only because the current DMA engine API is simply insufficient to implement it in the other way. I want to let a power domain, which contains a few devices, among those a PL330 device, to get turned
Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM
Hi Ulf, On 2017-02-10 14:57, Ulf Hansson wrote: On 10 February 2017 at 12:51, Marek Szyprowski wrote: On 2017-02-10 05:50, Vinod Koul wrote: On Thu, Feb 09, 2017 at 03:22:51PM +0100, Marek Szyprowski wrote: +static int pl330_set_slave(struct dma_chan *chan, struct device *slave) +{ + struct dma_pl330_chan *pch = to_pchan(chan); + struct pl330_dmac *pl330 = pch->dmac; + int i; + + mutex_lock(>rpm_lock); + + for (i = 0; i < pl330->num_peripherals; i++) { + if (pl330->peripherals[i].chan.slave == slave && + pl330->peripherals[i].slave_link) { + pch->slave_link = pl330->peripherals[i].slave_link; + goto done; + } + } + + pch->slave_link = device_link_add(slave, pl330->ddma.dev, + DL_FLAG_PM_RUNTIME | DL_FLAG_RPM_ACTIVE); So you are going to add the link on channel allocation and tear down on the freeup. Right. Channel allocation is typically done once per driver operation and it won't hurt system performance. I am not sure I really like the idea here. Could you point what's wrong with it? First, these thing shouldn't be handled in the drivers. These things should be set in core and each driver setting the links doesn't sound great to me. Which core? And what's wrong with the device links? They have been introduced to model relations between devices that are behind the usual parent/child/bus topology. I think Vinod mean the dmaengine core. Which also would make perfect sense to me as it would benefit all dma drivers. The only related PM thing, that shall be the decision of the driver, is whether it wants to enable runtime PM or not, during ->probe(). So do you want to create the links during the DMAengine driver probe? How do you plan to find all the client devices? Please note that you really want to create links to devices which will really use the DMA engine calls. Some client drivers might decide in runtime weather to use DMA engine or not, depending on other data. Second, should the link be always there and we only mange the state? Here it seems that we have link being created and destroyed, so why not mark it ACTIVE and DORMANT instead... Link state is managed by device core and should not be touched by the drivers. It is related to both provider and consumer drivers states (probed/not probed/etc). Second we would need to create those links first. The question is where to create them then. Just to fill in, to me this is really also the key question. If we could set up the device link already at device initialization, it should also be possible to avoid getting -EPROBE_DEFER for dma client drivers when requesting their dma channels. At the first glance this sounds like an ultimate solution for all problems, but I don't think that device links can be used this way. If I get it right, you would like to create links on client device initialization, preferably somewhere in the kernel driver core. This will be handled somehow by a completely generic code, which will create a link each pair of devices, which are connected by a phandle. Is this what you meant? Please note that that time no driver for both client and provider are probed. IMHO that doesn't look like a right generic approach How that code will know get following information: 1. is it really needed to create a link for given device pair? 2. what link flags should it use? 3. what about circular dependencies? 4. what about runtime optional dependencies? 5. what about non-dt platforms? acpi? This looks like another newer ending story of "how can we avoid deferred probe in a generic way". IMHO we should first solve the problem of irq-safe runtime PM in DMA engine drivers first. I proposed how it can be done with device links. With no changes in the client API. Later if one decide to extend the client API in a way it will allow other runtime PM implementation - I see no problem to convert pl330 driver to the new approach, but for the time being - this would be the easiest way to get it really functional. Lastly, looking at th description of the issue here, am perceiving (maybe my understanding is not quite right here) that you have an IP block in SoC which has multiple things and share common stuff and doing right PM is a challenge for you, right? Nope. Doing right PM in my SoC is not that complex and I would say it is rather typical for any embedded stuff. It works fine (in terms of the power consumption reduction) when all drivers simply properly manage their runtime PM state, thus if device is not in use, the state is set to suspended and finally, the power domain gets turned off. I've used device links for PM only because the current DMA engine API is simply insufficient to implement it in the other way. I want to let a power domain, which contains a few devices, among those a PL330 device, to get turned off when there is no
Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM
>> >> If we could set up the device link already at device initialization, >> it should also be possible to avoid getting -EPROBE_DEFER for dma >> client drivers when requesting their dma channels. > > Well if we defer then driver will regiser with dmaengine after it is > probed, so a client will either get a channel or not. IOW we won't get > -EPROBE_DEFER. I didn't quite get this. What do you mean by "if we defer..."? Defer into *what* and defer of *what*? Could you please elaborate. [...] >> >> Again, allow me to fill in. This issue exists for all ARM SoC which >> has a dma controller residing in a PM domain. I think that is quite >> many. >> >> Currently the only solution I have seen for this problem, but which I >> really dislike. That is, each dma client driver requests/releases >> their dma channel from their respective ->runtime_suspend|resume() >> callbacks - then the dma driver can use the dma request/release hooks, >> to do pm_runtime_get|put() which then becomes non-irq-safe. > > Yeah that is not the best way to do. But looking at it current one doesnt > seem best fit either. > > So on seeing the device_link_add() I was thinking that this is some SoC > dependent problem being solved whereas the problem statmement is non-atomic > channel prepare. You may be right. 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? > > 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. [...] >> >> So besides solving the irq-safe issue for dma driver, using the >> device-links has additionally two advantages. I already mentioned the >> -EPROBE_DEFER issue above. >> >> The second thing, is the runtime/system PM relations we get for free >> by using the links. In other words, the dma driver/core don't need to >> care about dealing with pm_runtime_get|put() as that would be managed >> by the dma client driver. > > Yeah sorry took me a while to figure that out :), If we do a different API > then dmaengine core can call pm_runtime_get|put() from non-atomic context. Yes, it can and this works from runtime PM point of view. But the following issues would remain unsolved. 1) Dependencies between dma drivers and dma client drivers during system PM. For example, a dma client driver needs the dma controller to be operational (remain system resumed), until the dma client driver itself becomes system suspended. The *only* currently available solution for this, is to try to system suspend the dma controller later than the dma client, via using the *late or the *noirq system PM callbacks. This works for most cases, but it becomes a problem when the dma client also needs to be system suspended at the *late or the *noirq phase. Clearly this solution that doesn't scale. Using device links explicitly solves this problem as it allows to specify this dependency between devices. 2) We won't avoid dma clients from getting -EPROBE_DEFER when requesting their dma channels in their ->probe() routines. This would be possible, if we can set up the device links at device initialization. > > [1]: http://www.spinics.net/lists/dmaengine/msg11570.html > > -- > ~Vinod Kind regards Uffe
Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM
>> >> If we could set up the device link already at device initialization, >> it should also be possible to avoid getting -EPROBE_DEFER for dma >> client drivers when requesting their dma channels. > > Well if we defer then driver will regiser with dmaengine after it is > probed, so a client will either get a channel or not. IOW we won't get > -EPROBE_DEFER. I didn't quite get this. What do you mean by "if we defer..."? Defer into *what* and defer of *what*? Could you please elaborate. [...] >> >> Again, allow me to fill in. This issue exists for all ARM SoC which >> has a dma controller residing in a PM domain. I think that is quite >> many. >> >> Currently the only solution I have seen for this problem, but which I >> really dislike. That is, each dma client driver requests/releases >> their dma channel from their respective ->runtime_suspend|resume() >> callbacks - then the dma driver can use the dma request/release hooks, >> to do pm_runtime_get|put() which then becomes non-irq-safe. > > Yeah that is not the best way to do. But looking at it current one doesnt > seem best fit either. > > So on seeing the device_link_add() I was thinking that this is some SoC > dependent problem being solved whereas the problem statmement is non-atomic > channel prepare. You may be right. 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? > > 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. [...] >> >> So besides solving the irq-safe issue for dma driver, using the >> device-links has additionally two advantages. I already mentioned the >> -EPROBE_DEFER issue above. >> >> The second thing, is the runtime/system PM relations we get for free >> by using the links. In other words, the dma driver/core don't need to >> care about dealing with pm_runtime_get|put() as that would be managed >> by the dma client driver. > > Yeah sorry took me a while to figure that out :), If we do a different API > then dmaengine core can call pm_runtime_get|put() from non-atomic context. Yes, it can and this works from runtime PM point of view. But the following issues would remain unsolved. 1) Dependencies between dma drivers and dma client drivers during system PM. For example, a dma client driver needs the dma controller to be operational (remain system resumed), until the dma client driver itself becomes system suspended. The *only* currently available solution for this, is to try to system suspend the dma controller later than the dma client, via using the *late or the *noirq system PM callbacks. This works for most cases, but it becomes a problem when the dma client also needs to be system suspended at the *late or the *noirq phase. Clearly this solution that doesn't scale. Using device links explicitly solves this problem as it allows to specify this dependency between devices. 2) We won't avoid dma clients from getting -EPROBE_DEFER when requesting their dma channels in their ->probe() routines. This would be possible, if we can set up the device links at device initialization. > > [1]: http://www.spinics.net/lists/dmaengine/msg11570.html > > -- > ~Vinod Kind regards Uffe
Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM
On Fri, Feb 10, 2017 at 02:57:09PM +0100, Ulf Hansson wrote: > On 10 February 2017 at 12:51, Marek Szyprowski> wrote: > > Hi Vinod, > > > > On 2017-02-10 05:50, Vinod Koul wrote: > >> > >> On Thu, Feb 09, 2017 at 03:22:51PM +0100, Marek Szyprowski wrote: > >> > >>> +static int pl330_set_slave(struct dma_chan *chan, struct device *slave) > >>> +{ > >>> + struct dma_pl330_chan *pch = to_pchan(chan); > >>> + struct pl330_dmac *pl330 = pch->dmac; > >>> + int i; > >>> + > >>> + mutex_lock(>rpm_lock); > >>> + > >>> + for (i = 0; i < pl330->num_peripherals; i++) { > >>> + if (pl330->peripherals[i].chan.slave == slave && > >>> + pl330->peripherals[i].slave_link) { > >>> + pch->slave_link = > >>> pl330->peripherals[i].slave_link; > >>> + goto done; > >>> + } > >>> + } > >>> + > >>> + pch->slave_link = device_link_add(slave, pl330->ddma.dev, > >>> + DL_FLAG_PM_RUNTIME | > >>> DL_FLAG_RPM_ACTIVE); > >> > >> So you are going to add the link on channel allocation and tear down on > >> the > >> freeup. > > > > > > Right. Channel allocation is typically done once per driver operation and it > > won't hurt system performance. > > > >> I am not sure I really like the idea here. > > > > > > Could you point what's wrong with it? > > > >> First, these thing shouldn't be handled in the drivers. These things > >> should > >> be set in core and each driver setting the links doesn't sound great to > >> me. > > > > > > Which core? And what's wrong with the device links? They have been > > introduced to > > model relations between devices that are behind the usual parent/child/bus > > topology. > > I think Vinod mean the dmaengine core. Which also would make perfect > sense to me as it would benefit all dma drivers. Right. > The only related PM thing, that shall be the decision of the driver, > is whether it wants to enable runtime PM or not, during ->probe(). We can do pm_runtime_enabled() to check and that and do when enabled.. > >> Second, should the link be always there and we only mange the state? Here > >> it > >> seems that we have link being created and destroyed, so why not mark it > >> ACTIVE and DORMANT instead... > > > > > > Link state is managed by device core and should not be touched by the > > drivers. > > It is related to both provider and consumer drivers states (probed/not > > probed/etc). > > > > Second we would need to create those links first. The question is where to > > create them then. > > Just to fill in, to me this is really also the key question. > > If we could set up the device link already at device initialization, > it should also be possible to avoid getting -EPROBE_DEFER for dma > client drivers when requesting their dma channels. Well if we defer then driver will regiser with dmaengine after it is probed, so a client will either get a channel or not. IOW we won't get -EPROBE_DEFER. > > > > >> Lastly, looking at th description of the issue here, am perceiving (maybe > >> my > >> understanding is not quite right here) that you have an IP block in SoC > >> which has multiple things and share common stuff and doing right PM is a > >> challenge for you, right? > > > > > > Nope. Doing right PM in my SoC is not that complex and I would say it is > > rather > > typical for any embedded stuff. It works fine (in terms of the power > > consumption reduction) when all drivers simply properly manage their runtime > > PM state, thus if device is not in use, the state is set to suspended and > > finally, the power domain gets turned off. > > > > I've used device links for PM only because the current DMA engine API is > > simply insufficient to implement it in the other way. > > > > I want to let a power domain, which contains a few devices, among those a > > PL330 > > device, to get turned off when there is no activity. Handling power domain > > power > > on / off requires non-atomic context, what is typical for runtime pm calls. > > For > > that I need to have non-irq-safe runtime pm implemented for all devices that > > belongs to that domains. > > Again, allow me to fill in. This issue exists for all ARM SoC which > has a dma controller residing in a PM domain. I think that is quite > many. > > Currently the only solution I have seen for this problem, but which I > really dislike. That is, each dma client driver requests/releases > their dma channel from their respective ->runtime_suspend|resume() > callbacks - then the dma driver can use the dma request/release hooks, > to do pm_runtime_get|put() which then becomes non-irq-safe. Yeah that is not the best way to do. But looking at it current one doesnt seem best fit either. So on seeing the device_link_add() I was thinking that this is some SoC dependent problem being solved whereas the problem statmement is non-atomic channel prepare. As I said
Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM
On Fri, Feb 10, 2017 at 02:57:09PM +0100, Ulf Hansson wrote: > On 10 February 2017 at 12:51, Marek Szyprowski > wrote: > > Hi Vinod, > > > > On 2017-02-10 05:50, Vinod Koul wrote: > >> > >> On Thu, Feb 09, 2017 at 03:22:51PM +0100, Marek Szyprowski wrote: > >> > >>> +static int pl330_set_slave(struct dma_chan *chan, struct device *slave) > >>> +{ > >>> + struct dma_pl330_chan *pch = to_pchan(chan); > >>> + struct pl330_dmac *pl330 = pch->dmac; > >>> + int i; > >>> + > >>> + mutex_lock(>rpm_lock); > >>> + > >>> + for (i = 0; i < pl330->num_peripherals; i++) { > >>> + if (pl330->peripherals[i].chan.slave == slave && > >>> + pl330->peripherals[i].slave_link) { > >>> + pch->slave_link = > >>> pl330->peripherals[i].slave_link; > >>> + goto done; > >>> + } > >>> + } > >>> + > >>> + pch->slave_link = device_link_add(slave, pl330->ddma.dev, > >>> + DL_FLAG_PM_RUNTIME | > >>> DL_FLAG_RPM_ACTIVE); > >> > >> So you are going to add the link on channel allocation and tear down on > >> the > >> freeup. > > > > > > Right. Channel allocation is typically done once per driver operation and it > > won't hurt system performance. > > > >> I am not sure I really like the idea here. > > > > > > Could you point what's wrong with it? > > > >> First, these thing shouldn't be handled in the drivers. These things > >> should > >> be set in core and each driver setting the links doesn't sound great to > >> me. > > > > > > Which core? And what's wrong with the device links? They have been > > introduced to > > model relations between devices that are behind the usual parent/child/bus > > topology. > > I think Vinod mean the dmaengine core. Which also would make perfect > sense to me as it would benefit all dma drivers. Right. > The only related PM thing, that shall be the decision of the driver, > is whether it wants to enable runtime PM or not, during ->probe(). We can do pm_runtime_enabled() to check and that and do when enabled.. > >> Second, should the link be always there and we only mange the state? Here > >> it > >> seems that we have link being created and destroyed, so why not mark it > >> ACTIVE and DORMANT instead... > > > > > > Link state is managed by device core and should not be touched by the > > drivers. > > It is related to both provider and consumer drivers states (probed/not > > probed/etc). > > > > Second we would need to create those links first. The question is where to > > create them then. > > Just to fill in, to me this is really also the key question. > > If we could set up the device link already at device initialization, > it should also be possible to avoid getting -EPROBE_DEFER for dma > client drivers when requesting their dma channels. Well if we defer then driver will regiser with dmaengine after it is probed, so a client will either get a channel or not. IOW we won't get -EPROBE_DEFER. > > > > >> Lastly, looking at th description of the issue here, am perceiving (maybe > >> my > >> understanding is not quite right here) that you have an IP block in SoC > >> which has multiple things and share common stuff and doing right PM is a > >> challenge for you, right? > > > > > > Nope. Doing right PM in my SoC is not that complex and I would say it is > > rather > > typical for any embedded stuff. It works fine (in terms of the power > > consumption reduction) when all drivers simply properly manage their runtime > > PM state, thus if device is not in use, the state is set to suspended and > > finally, the power domain gets turned off. > > > > I've used device links for PM only because the current DMA engine API is > > simply insufficient to implement it in the other way. > > > > I want to let a power domain, which contains a few devices, among those a > > PL330 > > device, to get turned off when there is no activity. Handling power domain > > power > > on / off requires non-atomic context, what is typical for runtime pm calls. > > For > > that I need to have non-irq-safe runtime pm implemented for all devices that > > belongs to that domains. > > Again, allow me to fill in. This issue exists for all ARM SoC which > has a dma controller residing in a PM domain. I think that is quite > many. > > Currently the only solution I have seen for this problem, but which I > really dislike. That is, each dma client driver requests/releases > their dma channel from their respective ->runtime_suspend|resume() > callbacks - then the dma driver can use the dma request/release hooks, > to do pm_runtime_get|put() which then becomes non-irq-safe. Yeah that is not the best way to do. But looking at it current one doesnt seem best fit either. So on seeing the device_link_add() I was thinking that this is some SoC dependent problem being solved whereas the problem statmement is non-atomic channel prepare. As I said earlier, if we want to
Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM
On 10 February 2017 at 12:51, Marek Szyprowskiwrote: > Hi Vinod, > > On 2017-02-10 05:50, Vinod Koul wrote: >> >> On Thu, Feb 09, 2017 at 03:22:51PM +0100, Marek Szyprowski wrote: >> >>> +static int pl330_set_slave(struct dma_chan *chan, struct device *slave) >>> +{ >>> + struct dma_pl330_chan *pch = to_pchan(chan); >>> + struct pl330_dmac *pl330 = pch->dmac; >>> + int i; >>> + >>> + mutex_lock(>rpm_lock); >>> + >>> + for (i = 0; i < pl330->num_peripherals; i++) { >>> + if (pl330->peripherals[i].chan.slave == slave && >>> + pl330->peripherals[i].slave_link) { >>> + pch->slave_link = >>> pl330->peripherals[i].slave_link; >>> + goto done; >>> + } >>> + } >>> + >>> + pch->slave_link = device_link_add(slave, pl330->ddma.dev, >>> + DL_FLAG_PM_RUNTIME | >>> DL_FLAG_RPM_ACTIVE); >> >> So you are going to add the link on channel allocation and tear down on >> the >> freeup. > > > Right. Channel allocation is typically done once per driver operation and it > won't hurt system performance. > >> I am not sure I really like the idea here. > > > Could you point what's wrong with it? > >> First, these thing shouldn't be handled in the drivers. These things >> should >> be set in core and each driver setting the links doesn't sound great to >> me. > > > Which core? And what's wrong with the device links? They have been > introduced to > model relations between devices that are behind the usual parent/child/bus > topology. I think Vinod mean the dmaengine core. Which also would make perfect sense to me as it would benefit all dma drivers. The only related PM thing, that shall be the decision of the driver, is whether it wants to enable runtime PM or not, during ->probe(). > >> Second, should the link be always there and we only mange the state? Here >> it >> seems that we have link being created and destroyed, so why not mark it >> ACTIVE and DORMANT instead... > > > Link state is managed by device core and should not be touched by the > drivers. > It is related to both provider and consumer drivers states (probed/not > probed/etc). > > Second we would need to create those links first. The question is where to > create them then. Just to fill in, to me this is really also the key question. If we could set up the device link already at device initialization, it should also be possible to avoid getting -EPROBE_DEFER for dma client drivers when requesting their dma channels. > >> Lastly, looking at th description of the issue here, am perceiving (maybe >> my >> understanding is not quite right here) that you have an IP block in SoC >> which has multiple things and share common stuff and doing right PM is a >> challenge for you, right? > > > Nope. Doing right PM in my SoC is not that complex and I would say it is > rather > typical for any embedded stuff. It works fine (in terms of the power > consumption reduction) when all drivers simply properly manage their runtime > PM state, thus if device is not in use, the state is set to suspended and > finally, the power domain gets turned off. > > I've used device links for PM only because the current DMA engine API is > simply insufficient to implement it in the other way. > > I want to let a power domain, which contains a few devices, among those a > PL330 > device, to get turned off when there is no activity. Handling power domain > power > on / off requires non-atomic context, what is typical for runtime pm calls. > For > that I need to have non-irq-safe runtime pm implemented for all devices that > belongs to that domains. Again, allow me to fill in. This issue exists for all ARM SoC which has a dma controller residing in a PM domain. I think that is quite many. Currently the only solution I have seen for this problem, but which I really dislike. That is, each dma client driver requests/releases their dma channel from their respective ->runtime_suspend|resume() callbacks - then the dma driver can use the dma request/release hooks, to do pm_runtime_get|put() which then becomes non-irq-safe. > > The problem with PL330 driver is that it use irq-safe runtime pm, which like > it > was stated in the patch description doesn't bring much benefits. To switch > to > standard (non-irq-safe) runtime pm, the pm_runtime calls have to be done > from > a context which permits sleeping. The problem with DMA engine driver API is > that > most of its callbacks have to be IRQ-safe and frankly only > device_{alloc,release}_chan_resources() what more or less maps to > dma_request_chan()/dma_release_channel() and friends. There are DMA engine > drivers which do runtime PM calls there (tegra20-apb-dma, sirf-dma, cppi41, > rcar-dmac), but this is not really efficient. DMA engine clients usually > allocate > dma channel during their probe() and keep them for the whole driver life. In > turn > this
Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM
On 10 February 2017 at 12:51, Marek Szyprowski wrote: > Hi Vinod, > > On 2017-02-10 05:50, Vinod Koul wrote: >> >> On Thu, Feb 09, 2017 at 03:22:51PM +0100, Marek Szyprowski wrote: >> >>> +static int pl330_set_slave(struct dma_chan *chan, struct device *slave) >>> +{ >>> + struct dma_pl330_chan *pch = to_pchan(chan); >>> + struct pl330_dmac *pl330 = pch->dmac; >>> + int i; >>> + >>> + mutex_lock(>rpm_lock); >>> + >>> + for (i = 0; i < pl330->num_peripherals; i++) { >>> + if (pl330->peripherals[i].chan.slave == slave && >>> + pl330->peripherals[i].slave_link) { >>> + pch->slave_link = >>> pl330->peripherals[i].slave_link; >>> + goto done; >>> + } >>> + } >>> + >>> + pch->slave_link = device_link_add(slave, pl330->ddma.dev, >>> + DL_FLAG_PM_RUNTIME | >>> DL_FLAG_RPM_ACTIVE); >> >> So you are going to add the link on channel allocation and tear down on >> the >> freeup. > > > Right. Channel allocation is typically done once per driver operation and it > won't hurt system performance. > >> I am not sure I really like the idea here. > > > Could you point what's wrong with it? > >> First, these thing shouldn't be handled in the drivers. These things >> should >> be set in core and each driver setting the links doesn't sound great to >> me. > > > Which core? And what's wrong with the device links? They have been > introduced to > model relations between devices that are behind the usual parent/child/bus > topology. I think Vinod mean the dmaengine core. Which also would make perfect sense to me as it would benefit all dma drivers. The only related PM thing, that shall be the decision of the driver, is whether it wants to enable runtime PM or not, during ->probe(). > >> Second, should the link be always there and we only mange the state? Here >> it >> seems that we have link being created and destroyed, so why not mark it >> ACTIVE and DORMANT instead... > > > Link state is managed by device core and should not be touched by the > drivers. > It is related to both provider and consumer drivers states (probed/not > probed/etc). > > Second we would need to create those links first. The question is where to > create them then. Just to fill in, to me this is really also the key question. If we could set up the device link already at device initialization, it should also be possible to avoid getting -EPROBE_DEFER for dma client drivers when requesting their dma channels. > >> Lastly, looking at th description of the issue here, am perceiving (maybe >> my >> understanding is not quite right here) that you have an IP block in SoC >> which has multiple things and share common stuff and doing right PM is a >> challenge for you, right? > > > Nope. Doing right PM in my SoC is not that complex and I would say it is > rather > typical for any embedded stuff. It works fine (in terms of the power > consumption reduction) when all drivers simply properly manage their runtime > PM state, thus if device is not in use, the state is set to suspended and > finally, the power domain gets turned off. > > I've used device links for PM only because the current DMA engine API is > simply insufficient to implement it in the other way. > > I want to let a power domain, which contains a few devices, among those a > PL330 > device, to get turned off when there is no activity. Handling power domain > power > on / off requires non-atomic context, what is typical for runtime pm calls. > For > that I need to have non-irq-safe runtime pm implemented for all devices that > belongs to that domains. Again, allow me to fill in. This issue exists for all ARM SoC which has a dma controller residing in a PM domain. I think that is quite many. Currently the only solution I have seen for this problem, but which I really dislike. That is, each dma client driver requests/releases their dma channel from their respective ->runtime_suspend|resume() callbacks - then the dma driver can use the dma request/release hooks, to do pm_runtime_get|put() which then becomes non-irq-safe. > > The problem with PL330 driver is that it use irq-safe runtime pm, which like > it > was stated in the patch description doesn't bring much benefits. To switch > to > standard (non-irq-safe) runtime pm, the pm_runtime calls have to be done > from > a context which permits sleeping. The problem with DMA engine driver API is > that > most of its callbacks have to be IRQ-safe and frankly only > device_{alloc,release}_chan_resources() what more or less maps to > dma_request_chan()/dma_release_channel() and friends. There are DMA engine > drivers which do runtime PM calls there (tegra20-apb-dma, sirf-dma, cppi41, > rcar-dmac), but this is not really efficient. DMA engine clients usually > allocate > dma channel during their probe() and keep them for the whole driver life. In > turn > this very similar to calling
Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM
Hi Vinod, On 2017-02-10 05:50, Vinod Koul wrote: On Thu, Feb 09, 2017 at 03:22:51PM +0100, Marek Szyprowski wrote: +static int pl330_set_slave(struct dma_chan *chan, struct device *slave) +{ + struct dma_pl330_chan *pch = to_pchan(chan); + struct pl330_dmac *pl330 = pch->dmac; + int i; + + mutex_lock(>rpm_lock); + + for (i = 0; i < pl330->num_peripherals; i++) { + if (pl330->peripherals[i].chan.slave == slave && + pl330->peripherals[i].slave_link) { + pch->slave_link = pl330->peripherals[i].slave_link; + goto done; + } + } + + pch->slave_link = device_link_add(slave, pl330->ddma.dev, + DL_FLAG_PM_RUNTIME | DL_FLAG_RPM_ACTIVE); So you are going to add the link on channel allocation and tear down on the freeup. Right. Channel allocation is typically done once per driver operation and it won't hurt system performance. I am not sure I really like the idea here. Could you point what's wrong with it? First, these thing shouldn't be handled in the drivers. These things should be set in core and each driver setting the links doesn't sound great to me. Which core? And what's wrong with the device links? They have been introduced to model relations between devices that are behind the usual parent/child/bus topology. Second, should the link be always there and we only mange the state? Here it seems that we have link being created and destroyed, so why not mark it ACTIVE and DORMANT instead... Link state is managed by device core and should not be touched by the drivers. It is related to both provider and consumer drivers states (probed/not probed/etc). Second we would need to create those links first. The question is where to create them then. Lastly, looking at th description of the issue here, am perceiving (maybe my understanding is not quite right here) that you have an IP block in SoC which has multiple things and share common stuff and doing right PM is a challenge for you, right? Nope. Doing right PM in my SoC is not that complex and I would say it is rather typical for any embedded stuff. It works fine (in terms of the power consumption reduction) when all drivers simply properly manage their runtime PM state, thus if device is not in use, the state is set to suspended and finally, the power domain gets turned off. I've used device links for PM only because the current DMA engine API is simply insufficient to implement it in the other way. I want to let a power domain, which contains a few devices, among those a PL330 device, to get turned off when there is no activity. Handling power domain power on / off requires non-atomic context, what is typical for runtime pm calls. For that I need to have non-irq-safe runtime pm implemented for all devices that belongs to that domains. The problem with PL330 driver is that it use irq-safe runtime pm, which like it was stated in the patch description doesn't bring much benefits. To switch to standard (non-irq-safe) runtime pm, the pm_runtime calls have to be done from a context which permits sleeping. The problem with DMA engine driver API is that most of its callbacks have to be IRQ-safe and frankly only device_{alloc,release}_chan_resources() what more or less maps to dma_request_chan()/dma_release_channel() and friends. There are DMA engine drivers which do runtime PM calls there (tegra20-apb-dma, sirf-dma, cppi41, rcar-dmac), but this is not really efficient. DMA engine clients usually allocate dma channel during their probe() and keep them for the whole driver life. In turn this very similar to calling pm_runtime_get() in the DMA engine driver probe(). The result of both approaches is that DMA engine device keeps its power domain enabled almost all the time. This problem is also mentioned in the DMA engine TODO list, you have pointed me yesterday. To avoid such situation that DMA engine driver blocks turning off the power domain and avoid changing DMA engine client API I came up with the device links pm based approach. I don't want to duplicate the description here, the details were in the patch description, however if you have any particular question about the details, let me know and I will try to clarify it more. Best regards -- Marek Szyprowski, PhD Samsung R Institute Poland
Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM
Hi Vinod, On 2017-02-10 05:50, Vinod Koul wrote: On Thu, Feb 09, 2017 at 03:22:51PM +0100, Marek Szyprowski wrote: +static int pl330_set_slave(struct dma_chan *chan, struct device *slave) +{ + struct dma_pl330_chan *pch = to_pchan(chan); + struct pl330_dmac *pl330 = pch->dmac; + int i; + + mutex_lock(>rpm_lock); + + for (i = 0; i < pl330->num_peripherals; i++) { + if (pl330->peripherals[i].chan.slave == slave && + pl330->peripherals[i].slave_link) { + pch->slave_link = pl330->peripherals[i].slave_link; + goto done; + } + } + + pch->slave_link = device_link_add(slave, pl330->ddma.dev, + DL_FLAG_PM_RUNTIME | DL_FLAG_RPM_ACTIVE); So you are going to add the link on channel allocation and tear down on the freeup. Right. Channel allocation is typically done once per driver operation and it won't hurt system performance. I am not sure I really like the idea here. Could you point what's wrong with it? First, these thing shouldn't be handled in the drivers. These things should be set in core and each driver setting the links doesn't sound great to me. Which core? And what's wrong with the device links? They have been introduced to model relations between devices that are behind the usual parent/child/bus topology. Second, should the link be always there and we only mange the state? Here it seems that we have link being created and destroyed, so why not mark it ACTIVE and DORMANT instead... Link state is managed by device core and should not be touched by the drivers. It is related to both provider and consumer drivers states (probed/not probed/etc). Second we would need to create those links first. The question is where to create them then. Lastly, looking at th description of the issue here, am perceiving (maybe my understanding is not quite right here) that you have an IP block in SoC which has multiple things and share common stuff and doing right PM is a challenge for you, right? Nope. Doing right PM in my SoC is not that complex and I would say it is rather typical for any embedded stuff. It works fine (in terms of the power consumption reduction) when all drivers simply properly manage their runtime PM state, thus if device is not in use, the state is set to suspended and finally, the power domain gets turned off. I've used device links for PM only because the current DMA engine API is simply insufficient to implement it in the other way. I want to let a power domain, which contains a few devices, among those a PL330 device, to get turned off when there is no activity. Handling power domain power on / off requires non-atomic context, what is typical for runtime pm calls. For that I need to have non-irq-safe runtime pm implemented for all devices that belongs to that domains. The problem with PL330 driver is that it use irq-safe runtime pm, which like it was stated in the patch description doesn't bring much benefits. To switch to standard (non-irq-safe) runtime pm, the pm_runtime calls have to be done from a context which permits sleeping. The problem with DMA engine driver API is that most of its callbacks have to be IRQ-safe and frankly only device_{alloc,release}_chan_resources() what more or less maps to dma_request_chan()/dma_release_channel() and friends. There are DMA engine drivers which do runtime PM calls there (tegra20-apb-dma, sirf-dma, cppi41, rcar-dmac), but this is not really efficient. DMA engine clients usually allocate dma channel during their probe() and keep them for the whole driver life. In turn this very similar to calling pm_runtime_get() in the DMA engine driver probe(). The result of both approaches is that DMA engine device keeps its power domain enabled almost all the time. This problem is also mentioned in the DMA engine TODO list, you have pointed me yesterday. To avoid such situation that DMA engine driver blocks turning off the power domain and avoid changing DMA engine client API I came up with the device links pm based approach. I don't want to duplicate the description here, the details were in the patch description, however if you have any particular question about the details, let me know and I will try to clarify it more. Best regards -- Marek Szyprowski, PhD Samsung R Institute Poland
Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM
On Thu, Feb 09, 2017 at 03:22:51PM +0100, Marek Szyprowski wrote: > +static int pl330_set_slave(struct dma_chan *chan, struct device *slave) > +{ > + struct dma_pl330_chan *pch = to_pchan(chan); > + struct pl330_dmac *pl330 = pch->dmac; > + int i; > + > + mutex_lock(>rpm_lock); > + > + for (i = 0; i < pl330->num_peripherals; i++) { > + if (pl330->peripherals[i].chan.slave == slave && > + pl330->peripherals[i].slave_link) { > + pch->slave_link = pl330->peripherals[i].slave_link; > + goto done; > + } > + } > + > + pch->slave_link = device_link_add(slave, pl330->ddma.dev, > +DL_FLAG_PM_RUNTIME | DL_FLAG_RPM_ACTIVE); So you are going to add the link on channel allocation and tear down on the freeup. I am not sure I really like the idea here. First, these thing shouldn't be handled in the drivers. These things should be set in core and each driver setting the links doesn't sound great to me. Second, should the link be always there and we only mange the state? Here it seems that we have link being created and destroyed, so why not mark it ACTIVE and DORMANT instead... Lastly, looking at th description of the issue here, am perceiving (maybe my understanding is not quite right here) that you have an IP block in SoC which has multiple things and share common stuff and doing right PM is a challenge for you, right? -- ~Vinod
Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM
On Thu, Feb 09, 2017 at 03:22:51PM +0100, Marek Szyprowski wrote: > +static int pl330_set_slave(struct dma_chan *chan, struct device *slave) > +{ > + struct dma_pl330_chan *pch = to_pchan(chan); > + struct pl330_dmac *pl330 = pch->dmac; > + int i; > + > + mutex_lock(>rpm_lock); > + > + for (i = 0; i < pl330->num_peripherals; i++) { > + if (pl330->peripherals[i].chan.slave == slave && > + pl330->peripherals[i].slave_link) { > + pch->slave_link = pl330->peripherals[i].slave_link; > + goto done; > + } > + } > + > + pch->slave_link = device_link_add(slave, pl330->ddma.dev, > +DL_FLAG_PM_RUNTIME | DL_FLAG_RPM_ACTIVE); So you are going to add the link on channel allocation and tear down on the freeup. I am not sure I really like the idea here. First, these thing shouldn't be handled in the drivers. These things should be set in core and each driver setting the links doesn't sound great to me. Second, should the link be always there and we only mange the state? Here it seems that we have link being created and destroyed, so why not mark it ACTIVE and DORMANT instead... Lastly, looking at th description of the issue here, am perceiving (maybe my understanding is not quite right here) that you have an IP block in SoC which has multiple things and share common stuff and doing right PM is a challenge for you, right? -- ~Vinod