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:4.278 / U:0.404 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site