[PATCH v2 1/4] PM: device: Introduce platform_resources_managed flag

[Michal Wilczynski]

On 4/16/25 16:48, Rafael J. Wysocki wrote:
> On Wed, Apr 16, 2025 at 3:32 PM Michal Wilczynski
> <m.wilczynski at samsung.com> wrote:
>>
>> On 4/15/25 18:42, Rafael J. Wysocki wrote:
>>> On Mon, Apr 14, 2025 at 8:53 PM Michal Wilczynski
>>> <m.wilczynski at samsung.com> wrote:
>>>>
>>>> Introduce a new dev_pm_info flag - platform_resources_managed, to
>>>> indicate whether platform PM resources such as clocks or resets are
>>>> managed externally (e.g. by a generic power domain driver) instead of
>>>> directly by the consumer device driver.
>>>
>>> I think that this is genpd-specific and so I don't think it belongs in
>>> struct dev_pm_info.
>>>
>>> There is dev->power.subsys_data->domain_data, why not use it for this?
>>
>> Hi Rafael,
>>
>> Thanks for the feedback.
>>
>> You're right — this behavior is specific to genpd, so embedding the flag
>> directly in struct dev_pm_info may not be the best choice. Using
>> dev->power.subsys_data->domain_data makes more sense and avoids bloating
>> the core PM structure.
>>
>>>
>>> Also, it should be documented way more comprehensively IMV.
>>>
>>> Who is supposed to set it and when?  What does it mean when it is set?
>>
>> To clarify the intended usage, I would propose adding the following
>> explanation to the commit message:
>>
>> "This flag is intended to be set by a generic PM domain driver (e.g.,
>> from within its attach_dev callback) to indicate that it will manage
>> platform specific runtime power management resources — such as clocks
>> and resets — on behalf of the consumer device. This implies a delegation
>> of runtime PM control to the PM domain, typically implemented through
>> its start and stop callbacks.
>>
>> When this flag is set, the consumer driver (e.g., drm/imagination) can
>> check it and skip managing such resources in its runtime PM callbacks
>> (runtime_suspend, runtime_resume), avoiding conflicts or redundant
>> operations."
> 
> This sounds good and I would also put it into a code comment somewhere.
> 
> I guess you'll need helpers for setting and testing this flag, so
> their kerneldoc comments can be used for that.
> 
>> This could also be included as a code comment near the flag definition
>> if you think that’s appropriate.
>>
>> Also, as discussed earlier with Maxime and Matt [1], this is not about
>> full "resource ownership," but more about delegating runtime control of
>> PM resources like clocks/resets to the genpd. That nuance may be worth
>> reflecting in the flag name as well, I would rename it to let's say
>> 'runtime_pm_platform_res_delegated', or more concise
>> 'runtime_pm_delegated'.
> 
> Or just "rpm_delegated" I suppose.
> 
> But if the genpd driver is going to set that flag, it will rather mean
> that this driver will now control the resources in question, so the
> driver should not attempt to manipulate them directly.  Is my
> understanding correct?

Yes, your understanding is correct — with one minor clarification.

When the genpd driver sets the flag, it indicates that it will take over
control of the relevant PM resources in the context of runtime PM, i.e.,
via its start() and stop() callbacks. As a result, the device driver
should not manipulate those resources from within its RUNTIME_PM_OPS
(e.g., runtime_suspend, runtime_resume) to avoid conflicts.

However, outside of the runtime PM callbacks, the consumer device driver
may still access or use those resources if needed e.g for devfreq.

> 
> Assuming that it is correct, how is the device driver going to know
> which resources in particular are now controlled by the genpd driver?

Good question — to allow finer-grained control, we could replace the
current single boolean flag with a u32 bitmask field. Each bit would
correspond to a specific category of platform managed resources. For
example:

#define RPM_TAKEOVER_CLK	BIT(0)
#define RPM_TAKEOVER_RESET	BIT(1)

This would allow a PM domain driver to selectively declare which
resources it is taking over and let the consumer driver query only the
relevant parts.

> 
> Also "rpm_takeover" may be a better name for the flag in that case.

Sounds good, bitmask could also be named like that

> 
>> [1] - https://lore.kernel.org/all/a3142259-1c72-45b9-b148-5e5e6bef87f9@samsung.com/
>>
>>>
>>>> This flag enables device drivers to cooperate with SoC-specific PM
>>>> domains by conditionally skipping management of clocks and resets when
>>>> the platform owns them.
>>>>
>>>> This idea was discussed on the mailing list [1].
>>>>
>>>> [1] - https://lore.kernel.org/all/CAPDyKFq=BF5f2i_Sr1cmVqtVAMgr=0FqsksL7RHZLKn++y0uwg@mail.gmail.com/
>>>>
>>>> Signed-off-by: Michal Wilczynski <m.wilczynski at samsung.com>
>>>> ---
>>>>  include/linux/device.h | 11 +++++++++++
>>>>  include/linux/pm.h     |  1 +
>>>>  2 files changed, 12 insertions(+)
>>>>
>>>> diff --git a/include/linux/device.h b/include/linux/device.h
>>>> index 79e49fe494b7c4c70d902886db63c4cfe5b4de4f..3e7a36dd874cfb6b98e2451c7a876989aa9f1913 100644
>>>> --- a/include/linux/device.h
>>>> +++ b/include/linux/device.h
>>>> @@ -881,6 +881,17 @@ static inline bool device_async_suspend_enabled(struct device *dev)
>>>>         return !!dev->power.async_suspend;
>>>>  }
>>>>
>>>> +static inline bool device_platform_resources_pm_managed(struct device *dev)
>>>
>>> Could this function name be shorter?
>>
>> Maybe:
>>
>> static inline bool dev_is_runtime_pm_delegated(struct device *dev);
>> static inline void dev_set_runtime_pm_delegated(struct device *dev, bool val);
> 
> What about
> 
> dev_pm_genpd_rpm_delegated()
> dev_pm_genpd_set_rpm_delegated()
> 
> respectively (or analogously with the "takeover" variant)?

Right sounds good, so if you also like a bitmask idea they could look
like this:

static inline bool dev_pm_genpd_rpm_takeover(struct device *dev, u32 flags);
static inline void dev_pm_genpd_set_rpm_takeover(struct device *dev, u32 flags);

Regards,
Michał

>