[lkml]   [2018]   [May]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 8/9] PM / Domains: Add support for multi PM domains per device to genpd

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?



 \ /
  Last update: 2018-05-23 11:07    [W:0.095 / U:0.644 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site