Re: [RFC PATCH 0/4] PM / Domains: Add support for explicit control of PM domains

From: Ulf Hansson
Date: Wed May 03 2017 - 13:12:22 EST


[...]

>>>
>>>> What is missing, is how a call to pm_runtime_get_sync() by a driver,
>>>> can inform the ->start() callback about what exact power resource(s)
>>>> it shall turn on, because it may not always be all of them. Similar
>>>> problem exists for pm_runtime_put().
>>>
>>> Yes that is missing too, but I still don't see how you bind a device to
>>> more than one power-domain :-(
>>
>> I think this is what Rafael wanted us avoid (because of the complexity
>> involved). Instead the suggestion is to deal with this on top of the
>> existing PM domain structure, as "power resources" instead. Unless I
>> missed his point. :-)
>>
>> Then *my* point is: To be able to implement that, still only allowing
>> one PM domain per device, we would anyway need a new layer in-between
>> the PM domain (genpd) and the driver controlling the device. Simply
>> because these two entities, needs to be able to exchange information
>> about which "power resources" that shall be turned off/on, when the
>> driver do pm_runtime_get|put().
>
> Right, but isn't this similar to what I was suggesting above in my
> previous email?

Perhaps it was, apologize for my ignorance in that case.

Then, isn't that quite what you already started hacking on in $subject
series? What's the new thing in your previous reply?

However, I was under the impression that Rafael preferred another way
- but again I might have missed his point.

>
> I was proposing to have such a lower-layer by splitting the existing
> genpd framework so the drivers would have the option of calling the
> lower-level power control functions to look-up pm-domains and control
> them directly from their rpm callbacks (if they need to). Same as we do
> for clocks. This way you would not need to mess with the genpd ->start()
> callback and leave it to the driver to handle itself as it knows what
> needs to be done. This assumes that the device is never bound to the
> pm-domain by the genpd core.

Yes, agree! To me this is the only solution what would really work.

Perhaps Rafael can confirm that he is fine with a solution like this?

Kind regards
Uffe