Re: [PATCH v3 0/5] Subject: The power allocator thermal governor

[Eduardo Valentin <edubezval@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2789 bytes --]

On Mon, Mar 02, 2015 at 05:40:54PM +0000, Javi Merino wrote:
> On Mon, Mar 02, 2015 at 05:28:50PM +0000, Eduardo Valentin wrote:
> > On Mon, Mar 02, 2015 at 05:17:18PM +0000, Javi Merino wrote:
> > > *** BLURB HERE ***
> > > 
> > > Hi linux-pm,
> > > 
> > > Introduce the power allocator governor, a thermal governor that
> > > allocates device power to control temperature.  This series is based
> > > on branch "linus" of Eduardo's linux-soc-thermal tree:
> > > 
> > > git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.git
> > > 
> > > Changes since v2:
> > >   - Address Eduardo's review
> > >     + Turn variable-size array in divvy_up_power() into a
> > >       devm_kcalloc() as suggested by Eduardo
> > >     + Remove #ifdeffery from thermal_core.c as suggested by Eduardo
> > >   - Bring back cpufreq's CPUFREQ_UPDATE_POLICY_CPU notifier in order
> > >     to update the cpu device in cpu_cooling.c when cpufreq changes
> > >     the policy cpu.
> > 
> > 
> > Can you please elaborate a bit more on the issue you saw to decide to
> > bring this functionality back?
> 
> I explained it in patch 5 ("thermal: cpu_cooling: update the cpu
> device when cpufreq updates the policy cpu"): When cpufreq changes the
> policy cpu, the cpufreq cooling device needs to update the cached cpu
> device accordingly.
> 
> > Can we keep the cpufreq changes as a separated thread? To me if the
> > issue happens to power allocator, it also happens to the other
> > governors.
> 
> The cached cpu device was introduced in patch 98ea0816118f ("thermal:
> cpu_cooling: implement the power cooling device API") in your tree.
> I'm posting it here because it only affects doesn't affect other
> governors.
> 
> > I don't want to block power allocator due to the cpufreq
> > changes.
> 
> You don't have to.  It's the last two patches precisely for that.  You
> can merge everything up to patch 3 without depending on cpufreq
> changes.
> 
> > Besides, cpufreq changes should go via the proper cpufreq tree, not the
> > thermal tree.
> 
> It's a change to cpu_cooling (patch 5) that needs a revert of cpufreq
> (patch 4).  The change to cpu_cooling depends on the patches already
> in your branch.  So you will have to carry this patch in your branch
> with an Ack from the cpufreq maintainers.

Yes, the patches in the thermal code depend on code in my tree.
However, changes in cpufreq are not depending on any code in my tree.
Unless there is a direct dependency, I would prefer to send them via the
correct tree.

I simple don't feel comfortable sending stuff that are really part of
what is described in MAINTAINERS. But if you get an ack from cpufreq,
then of course, I can consider it.

> 
> Cheers,
> Javi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]