Re: [PATCH 5/5] cpufreq: qcom-hw: Move driver initialisation earlier

[Sudeep Holla]

On Tue, Sep 17, 2019 at 02:47:22PM +0200, Daniel Lezcano wrote:
>
> 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@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.
>
> module = mounted file system = very late initialization
>
> Is that the plan? Force every driver to load too late?
>

Yes. Something similar to what we have on desktops/servers.

> 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?
>

I am fine with that if it's really issue but it shouldn't become the
defacto trend.

> "The grand plan" will have to solve this first before doing the module
> move.
>

Sure, I just expressed my view as it looks to be going in different
direction for me.

> > 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.
>

OK, so this platform boots with default high OPP and needs thermal
mitigation that early ? If so, that's fine.

> > 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.
>

I understand the requirement, though for me it's really sounds stupid.

As Quentin pointed out, it would be good to get all those benchmark
details, and preferably in the commit log so that we can look back
whenever someone else take the same approach later.

--
Regards,
Sudeep