Thread (8 messages) 8 messages, 3 authors, 2025-06-10

Re: [RFC PATCH] pmdomain: arm: scmi_pm_domain: Do lazy init as part of probe

From: Dhruva Gole <hidden>
Date: 2025-06-10 11:43:25
Also in: arm-scmi, linux-pm, lkml

Hi,

On May 30, 2025 at 17:31:08 +0100, Sudeep Holla wrote:
On Fri, May 30, 2025 at 04:05:27PM +0530, Dhruva Gole wrote:
quoted
Optimize the SCMI power domain driver to only initialize domains that are
actually referenced in the device tree. Previously, the driver would
initialize all possible domains up to the maximum ID, which could lead to
unnecessary firmware calls and longer probe times.

Key changes:
- Scan device tree to identify which power domains are actually referenced
How do this work with runtime DT overlays ?
Thanks for bringing this up, I hadn't considered runtime DT overlays for
this particular patch.
Off the top of my mind, we can initialize all at probe, but only query state
for referenced ones.
quoted
- Use bitmap to track needed domains instead of initializing all
- Only perform state queries and initialization for referenced domains
- Maintain proper array sizing for power domain framework compatibility
- Keep full provider structure to support late binding

This optimization reduces probe time and unnecessary firmware interactions
by only initializing power domains that are actually used in the system.
Why is this very specific to power domains only ? This must apply for other
domains like perf or clock or reset ?
Yes, it should. Starting out with just power domains for now though. I
haven't looked at other places like perf and clock yet.
quoted
For example, in a system with 100 possible domains but only 3 referenced
in the device tree, we now only initialize those 3 domains instead of
all 100.
Well, how much of these PD will get used in the final products ? I can
understand the need to use just 3 in devel platforms. Just trying to see
how realistic is the scenario ? Is there any other optimisation possible
from the firmware ? Does getting the state of a PD takes so much time
on the platform in question ?
Well, it's not only about how much time it takes on any particular platform
to query the state of a PD. Even if say it takes 10us to query it, it will
add a whole 1ms to the probe time. This mean 1ms more of boot time, and
perhaps boot time experts can chime in here but every optimisation
possible matters!
ARM systems are usually very strict on boot time requirements.

Even if we somehow optimise the firmware, to me it seems like kernel is
wasting time querrying for something that it doesn't need at that moment.

Just replying here to your next reply on the thread:
And I missed another point. Someone will soon complain Linux no longer
turns off unused power domains. So I am inclined against this optimisation.
We need to consider all the above point before .
I agree on some points like the runtime overlay. However I am not sure
why Linux should be the one to turn OFF power domains that it's
_unaware_ of. "unused" would probably be a wrong assumption to make.
There maybe other entities that would be using power domains that
are not in the device tree. (For eg. an RTOS running on the same system
accessing a PD that is controlled by the SCP firmware but not mentioned in the
device tree.)

While one may argue that's why firmware should be the one to keep ref
counts to avoid resource conflicts, one could also argue that firmwares
could be the one to turn off unused power domains.

Why should the kernel touch something that it hasn't been told about
explicitly in the DT? Isn't the whole point of DT to be the literal
hardware descriptor for the kernel? So if something doesn't exist in the
DT, kernel shouldn't have other places telling it does - in this context
power domains.

-- 
Best regards,
Dhruva Gole
Texas Instruments Incorporated
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help