[PATCH 0/5] cpuidle: psci: Various improvements for PSCI PM domains

[Lukasz Luba]

Hi Ulf,

On 6/15/20 4:20 PM, Ulf Hansson wrote:
> The main change in this series is done in patch 5/5, which implements support
> to prevent domain idlestates until all PSCI PM domain consumers are ready for
> it. To reach that point the corresponding code for cpuidle-psci and
> cpuidle-psci-domain, needed to be converted into platform drivers, which is
> done by the earlier changes in the series.
> 
> Additionally, some improvements have been made to the error path, which becomes
> easier when the code gets converted to platform drivers.
> 
> Deployment for a Qcom SoC, which actually takes full benefit of these changes
> are also in the pipe, but deferring then a bit until $subject series have been
> discussed.
> 
> Kind regards
> Ulf Hansson
> 
> Ulf Hansson (5):
>    cpuidle: psci: Fail cpuidle registration if set OSI mode failed
>    cpuidle: psci: Fix error path via converting to a platform driver
>    cpuidle: psci: Split into two separate build objects
>    cpuidle: psci: Convert PM domain to platform driver
>    cpuidle: psci: Prevent domain idlestates until consumers are ready
> 
>   drivers/cpuidle/Kconfig.arm           |  10 ++
>   drivers/cpuidle/Makefile              |   5 +-
>   drivers/cpuidle/cpuidle-psci-domain.c |  74 +++++++++-----
>   drivers/cpuidle/cpuidle-psci.c        | 141 +++++++++++++++-----------
>   drivers/cpuidle/cpuidle-psci.h        |  11 +-
>   5 files changed, 150 insertions(+), 91 deletions(-)
> 

Since I am interested in some CPU idle statistics (residency, etc),
I would like to help you and Sudeep in reviewing the patch set.

Could you clarify some bit below?
1. There is Qcom SoC which has dependencies between PSCI PM domain
consumers and this CPU idle - thus we cannot register and use CPU
idle driver till related drivers fully setup.
2. The proposed solution is to use platform driver and plat. device
for this CPU idle driver, to have access to deferred probe mechanism and
wait for the consumer drivers fully probed state.
3. Do you have maybe some estimations how long it takes for these
consumers to be fully probed?
4. Changing just this CPU idle driver registration point (to
late_initcall()) phase in time is not a solution.

Regards,
Lukasz