mbox series

[v3,0/6] Initialise thermal framework and cpufreq earlier during boot

Message ID cover.1571314830.git.amit.kucheria@linaro.org
Headers show
Series Initialise thermal framework and cpufreq earlier during boot | expand

Message

Amit Kucheria Oct. 17, 2019, 12:27 p.m. UTC
Changes since v2:
- Missed one patch when posting v2. Respinning.

Changes since v1:
- Completely get rid of netlink support in the thermal framework.
- This changes the early init patch to a single line - change to
  core_initcall. Changed authorship of patch since it is nothing like the
  original. Lina, let me know if you feel otherwise.
- I've tested to make sure that the qcom-cpufreq-hw driver continues to
  work correctly as a module so this won't impact Android's GKI plans.
- Collected Acks

Device boot needs to be as fast as possible while keeping under the thermal
envelope. Now that thermal framework is built-in to the kernel, we can
initialize it earlier to enable thermal mitigation during boot.

We also need the cpufreq HW drivers to be initialised earlier to act as the
cooling devices. This series only converts over the qcom-hw driver to
initialize earlier but can be extended to other platforms as well.

Amit Kucheria (6):
  thermal: Remove netlink support
  thermal: Initialize thermal subsystem earlier
  cpufreq: Initialise the governors in core_initcall
  cpufreq: Initialize cpufreq-dt driver earlier
  clk: qcom: Initialise clock drivers earlier
  cpufreq: qcom-hw: Move driver initialisation earlier

 .../driver-api/thermal/sysfs-api.rst          |  26 +----
 drivers/clk/qcom/clk-rpmh.c                   |   2 +-
 drivers/clk/qcom/gcc-qcs404.c                 |   2 +-
 drivers/clk/qcom/gcc-sdm845.c                 |   2 +-
 drivers/cpufreq/cpufreq-dt-platdev.c          |   2 +-
 drivers/cpufreq/cpufreq_conservative.c        |   2 +-
 drivers/cpufreq/cpufreq_ondemand.c            |   2 +-
 drivers/cpufreq/cpufreq_performance.c         |   2 +-
 drivers/cpufreq/cpufreq_powersave.c           |   2 +-
 drivers/cpufreq/cpufreq_userspace.c           |   2 +-
 drivers/cpufreq/qcom-cpufreq-hw.c             |   2 +-
 drivers/thermal/thermal_core.c                | 110 +-----------------
 include/linux/thermal.h                       |  11 --
 13 files changed, 22 insertions(+), 145 deletions(-)

-- 
2.17.1

Comments

Amit Kucheria Oct. 17, 2019, 7:42 p.m. UTC | #1
On Fri, Oct 18, 2019 at 12:41 AM Rafael J. Wysocki <rafael@kernel.org> wrote:
>

> On Thu, Oct 17, 2019 at 2:28 PM Amit Kucheria <amit.kucheria@linaro.org> wrote:

> >

> > Initialise the cpufreq governors earlier to allow for earlier

> > performance control during the boot process.

> >

> > Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>

> > Acked-by: Viresh Kumar <viresh.kumar@linaro.org>

>

> You also want to do that for the schedutil governor I think.


Indeed. Thanks for the review. I'll respin.

>

> > ---

> >  drivers/cpufreq/cpufreq_conservative.c | 2 +-

> >  drivers/cpufreq/cpufreq_ondemand.c     | 2 +-

> >  drivers/cpufreq/cpufreq_performance.c  | 2 +-

> >  drivers/cpufreq/cpufreq_powersave.c    | 2 +-

> >  drivers/cpufreq/cpufreq_userspace.c    | 2 +-

> >  5 files changed, 5 insertions(+), 5 deletions(-)

> >

> > diff --git a/drivers/cpufreq/cpufreq_conservative.c b/drivers/cpufreq/cpufreq_conservative.c

> > index b66e81c06a57..737ff3b9c2c0 100644

> > --- a/drivers/cpufreq/cpufreq_conservative.c

> > +++ b/drivers/cpufreq/cpufreq_conservative.c

> > @@ -346,7 +346,7 @@ struct cpufreq_governor *cpufreq_default_governor(void)

> >         return CPU_FREQ_GOV_CONSERVATIVE;

> >  }

> >

> > -fs_initcall(cpufreq_gov_dbs_init);

> > +core_initcall(cpufreq_gov_dbs_init);

> >  #else

> >  module_init(cpufreq_gov_dbs_init);

> >  #endif

> > diff --git a/drivers/cpufreq/cpufreq_ondemand.c b/drivers/cpufreq/cpufreq_ondemand.c

> > index dced033875bf..82a4d37ddecb 100644

> > --- a/drivers/cpufreq/cpufreq_ondemand.c

> > +++ b/drivers/cpufreq/cpufreq_ondemand.c

> > @@ -483,7 +483,7 @@ struct cpufreq_governor *cpufreq_default_governor(void)

> >         return CPU_FREQ_GOV_ONDEMAND;

> >  }

> >

> > -fs_initcall(cpufreq_gov_dbs_init);

> > +core_initcall(cpufreq_gov_dbs_init);

> >  #else

> >  module_init(cpufreq_gov_dbs_init);

> >  #endif

> > diff --git a/drivers/cpufreq/cpufreq_performance.c b/drivers/cpufreq/cpufreq_performance.c

> > index aaa04dfcacd9..def9afe0f5b8 100644

> > --- a/drivers/cpufreq/cpufreq_performance.c

> > +++ b/drivers/cpufreq/cpufreq_performance.c

> > @@ -50,5 +50,5 @@ MODULE_AUTHOR("Dominik Brodowski <linux@brodo.de>");

> >  MODULE_DESCRIPTION("CPUfreq policy governor 'performance'");

> >  MODULE_LICENSE("GPL");

> >

> > -fs_initcall(cpufreq_gov_performance_init);

> > +core_initcall(cpufreq_gov_performance_init);

> >  module_exit(cpufreq_gov_performance_exit);

> > diff --git a/drivers/cpufreq/cpufreq_powersave.c b/drivers/cpufreq/cpufreq_powersave.c

> > index c143dc237d87..1ae66019eb83 100644

> > --- a/drivers/cpufreq/cpufreq_powersave.c

> > +++ b/drivers/cpufreq/cpufreq_powersave.c

> > @@ -43,7 +43,7 @@ struct cpufreq_governor *cpufreq_default_governor(void)

> >         return &cpufreq_gov_powersave;

> >  }

> >

> > -fs_initcall(cpufreq_gov_powersave_init);

> > +core_initcall(cpufreq_gov_powersave_init);

> >  #else

> >  module_init(cpufreq_gov_powersave_init);

> >  #endif

> > diff --git a/drivers/cpufreq/cpufreq_userspace.c b/drivers/cpufreq/cpufreq_userspace.c

> > index cbd81c58cb8f..b43e7cd502c5 100644

> > --- a/drivers/cpufreq/cpufreq_userspace.c

> > +++ b/drivers/cpufreq/cpufreq_userspace.c

> > @@ -147,7 +147,7 @@ struct cpufreq_governor *cpufreq_default_governor(void)

> >         return &cpufreq_gov_userspace;

> >  }

> >

> > -fs_initcall(cpufreq_gov_userspace_init);

> > +core_initcall(cpufreq_gov_userspace_init);

> >  #else

> >  module_init(cpufreq_gov_userspace_init);

> >  #endif

> > --

> > 2.17.1

> >
Viresh Kumar Oct. 18, 2019, 6:03 a.m. UTC | #2
On 17-10-19, 10:47, Stephen Boyd wrote:
> Quoting Amit Kucheria (2019-10-17 05:27:37)

> > Initialise the clock drivers on sdm845 and qcs404 in core_initcall so we

> > can have earlier access to cpufreq during booting.

> > 

> > Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>

> > ---

> 

> Acked-by: Stephen Boyd <sboyd@kernel.org>

> 

> Makes me sad again.


I am wondering why it makes you sad ? :)

-- 
viresh
Sudeep Holla Oct. 29, 2019, 1:06 a.m. UTC | #3
On Mon, Oct 28, 2019 at 10:22:24AM -0700, Stephen Boyd wrote:
> Quoting Viresh Kumar (2019-10-17 23:03:45)

> > On 17-10-19, 10:47, Stephen Boyd wrote:

> > > Quoting Amit Kucheria (2019-10-17 05:27:37)

> > > > Initialise the clock drivers on sdm845 and qcs404 in core_initcall so we

> > > > can have earlier access to cpufreq during booting.

> > > >

> > > > Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>

> > > > ---

> > >

> > > Acked-by: Stephen Boyd <sboyd@kernel.org>

> > >

> > > Makes me sad again.

> >

> > I am wondering why it makes you sad ? :)

> >

>

> We're playing games with initcall levels :(

>


+1, which will come back and bite us hard soon :)

--
Regards,
Sudeep
Viresh Kumar Nov. 5, 2019, 6:50 a.m. UTC | #4
On 29-10-19, 09:06, Sudeep Holla wrote:
> On Mon, Oct 28, 2019 at 10:22:24AM -0700, Stephen Boyd wrote:

> > Quoting Viresh Kumar (2019-10-17 23:03:45)

> > > On 17-10-19, 10:47, Stephen Boyd wrote:

> > > > Quoting Amit Kucheria (2019-10-17 05:27:37)

> > > > > Initialise the clock drivers on sdm845 and qcs404 in core_initcall so we

> > > > > can have earlier access to cpufreq during booting.

> > > > >

> > > > > Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>

> > > > > ---

> > > >

> > > > Acked-by: Stephen Boyd <sboyd@kernel.org>

> > > >

> > > > Makes me sad again.

> > >

> > > I am wondering why it makes you sad ? :)

> > >

> >

> > We're playing games with initcall levels :(

> >

> 

> +1, which will come back and bite us hard soon :)


:)

I don't like reordering init calls as well, but only when they are
used to avoid issues and probe things in a particular order. While the
only thing we are doing here is to get things to probe earlier, which
isn't wrong IMO :)

Lets see if it bites us anytime soon, I would be surprised really :)

-- 
viresh