lkml.org 
[lkml]   [2019]   [Sep]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 5/5] cpufreq: qcom-hw: Move driver initialisation earlier
On Thu, Sep 12, 2019 at 04:02:34AM +0530, Amit Kucheria wrote:
> Allow qcom-hw driver to initialise right after the cpufreq and thermal
> subsystems are initialised in core_initcall so we get earlier access to
> thermal mitigation.
>
> Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
> ---
> drivers/cpufreq/qcom-cpufreq-hw.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c b/drivers/cpufreq/qcom-cpufreq-hw.c
> index 4b0b50403901..04676cc82ba6 100644
> --- a/drivers/cpufreq/qcom-cpufreq-hw.c
> +++ b/drivers/cpufreq/qcom-cpufreq-hw.c
> @@ -327,7 +327,7 @@ static int __init qcom_cpufreq_hw_init(void)
> {
> return platform_driver_register(&qcom_cpufreq_hw_driver);
> }
> -device_initcall(qcom_cpufreq_hw_init);
> +postcore_initcall(qcom_cpufreq_hw_init);

I am fine with core framework initcall pushed to earlier initcall levels
if required, but for individual/platform specific drivers I am not so
happy to see that.

This goes against the grand plan of single common kernel strategy by
Android moving all drivers as modules. We might decide to make this
a module. Also there are few cpufreq drivers that are modules. Will
they have issues ? If not, why do we need this change at all. Needing
thermal mitigation during boot this earlier is still too much of
expectation, I would rather boot slowly than relying on this feature.

--
Regards,
Sudeep

\
 
 \ /
  Last update: 2019-09-17 11:35    [W:0.096 / U:3.712 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site