Messages in this thread | | | Subject | Re: [PATCH 8/9] PM / Domains: Add support for multi PM domains per device to genpd | From | Jon Hunter <> | Date | Wed, 23 May 2018 10:07:43 +0100 |
| |
On 23/05/18 07:12, Ulf Hansson wrote:
...
>>>>> Thanks for sending this. Believe it or not this has still been on my to-do list >>>>> and so we definitely need a solution for Tegra. >>>>> >>>>> Looking at the above it appears that additional power-domains exposed as devices >>>>> to the client device. So I assume that this means that the drivers for devices >>>>> with multiple power-domains will need to call RPM APIs for each of these >>>>> additional power-domains. Is that correct? >>>> >>>> They can, but should not! >>>> >>>> Instead, the driver shall use device_link_add() and device_link_del(), >>>> dynamically, depending on what PM domain that their original device >>>> needs for the current running use case. >>>> >>>> In that way, they keep existing runtime PM deployment, operating on >>>> its original device. >>> >>> OK, sounds good. Any reason why the linking cannot be handled by the above API? Is there a use-case where you would not want it linked? >> >> I am guessing the linking is what would give the driver the ability to decide which subset of powerdomains it actually wants to control >> at any point using runtime PM. If we have cases wherein the driver would want to turn on/off _all_ its associated powerdomains _always_ >> then a default linking of all would help. > > First, I think we need to decide on *where* the linking should be > done, not at both places, as that would just mess up synchronization > of who is responsible for calling the device_link_del() at detach. > > Second, It would in principle be fine to call device_link_add() and > device_link_del() as a part of the attach/detach APIs. However, there > is a downside to such solution, which would be that the driver then > needs call the detach API, just to do device_link_del(). Of course > then it would also needs to call the attach API later if/when needed. > Doing this adds unnecessary overhead - comparing to just let the > driver call device_link_add|del() when needed. On the upside, yes, it > would put less burden on the drivers as it then only needs to care > about using one set of functions. > > Which solution do you prefer?
Any reason why we could not add a 'boolean' argument to the API to indicate whether the new device should be linked? I think that I prefer the API handles it, but I can see there could be instances where drivers may wish to handle it themselves.
Rajendra, do you have a use-case right now where the driver would want to handle the linking?
Cheers Jon
-- nvpublic
| |