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@xxxxxxxxxx>
> ---
> 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
