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

From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: Sudeep Holla <sudeep.holla@arm.com>,
	Amit Kucheria <amit.kucheria@linaro.org>
Cc: linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	bjorn.andersson@linaro.org, edubezval@gmail.com,
	agross@kernel.org, tdas@codeaurora.org, swboyd@chromium.org,
	ilina@codeaurora.org, "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	Zhang Rui <rui.zhang@intel.com>,
	linux-pm@vger.kernel.org
Subject: Re: [PATCH 5/5] cpufreq: qcom-hw: Move driver initialisation earlier
Date: Tue, 17 Sep 2019 14:47:22 +0200	[thread overview]
Message-ID: <58e60ca4-9615-bbdf-5fe7-2a0e1d7f48d8@linaro.org> (raw)
In-Reply-To: <20190917093412.GA24757@bogus>

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