| Message ID | b731b713d8738239c26361ece7f5cadea035b353.1568240476.git.amit.kucheria@linaro.org |
|---|---|
| State | Superseded |
| Headers | show |
| Series | None | expand |
Hi Sudeep, On 17/09/2019 11:34, Sudeep Holla wrote: > 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. module = mounted file system = very late initialization Is that the plan? Force every driver to load too late? There are core drivers which must be loaded as soon as possible. If the qcom driver is one of them, then what is the problem? "The grand plan" will have to solve this first before doing the module move. > Also there are few cpufreq drivers that are modules. Will > they have issues ? If not, why do we need this change at all. Because some boards don't have thermal issues with the cpufreq drivers as module, other boards have. > Needing > thermal mitigation during boot this earlier is still too much of > expectation, I would rather boot slowly than relying on this feature. And what if we want to boot faster? The boot time is one of a key point of benchmark. -- <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook | <http://twitter.com/#!/linaroorg> Twitter | <http://www.linaro.org/linaro-blog/> Blog
On 17-09-19, 10:34, Sudeep Holla wrote: > On Thu, Sep 12, 2019 at 04:02:34AM +0530, Amit Kucheria wrote: > > -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. Its been long that I got the opportunity to work on drivers directly, but as far as I remember (which should be incorrect based on your reply) we can still build a driver as module even if it has some postcore_initcall() declarations. They will execute at module insertion. Is that incorrect ? If not, then how is it going to affect android effort ? -- viresh
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); static void __exit qcom_cpufreq_hw_exit(void) {
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(-) -- 2.17.1