All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Javi Merino" <javi.merino@arm.com>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Linux PM list <linux-pm@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Punit Agrawal <Punit.Agrawal@arm.com>,
	Mark Brown <broonie@kernel.org>, Zhang Rui <rui.zhang@intel.com>,
	Eduardo Valentin <edubezval@gmail.com>
Subject: Re: [RFC PATCH v6 6/9] thermal: cpu_cooling: implement the power cooling device API
Date: Mon, 8 Dec 2014 12:50:34 +0000	[thread overview]
Message-ID: <20141208125033.GB2980@e104805> (raw)
In-Reply-To: <CAOh2x==BKyS08th2d4r0Q2UGqhzAwj6sqOgFsH6J0pWup+OU_A@mail.gmail.com>

On Mon, Dec 08, 2014 at 05:49:00AM +0000, Viresh Kumar wrote:
> Hi Javi,

Hi Viresh,

> Looks like ARM's exchange server screwed up your patch?
> 
> This is how I see it with gmail's show-original option:
> 
> +=09cpufreq_device->dyn_power_table =3D power_table;
> +=09cpufreq_device->dyn_power_table_entries =3D i;
> +
> 
> I have seen this a lot, while I was in ARM. Had to adopt some work-arounds to
> get over it. :)

Sigh.  Care to share them (privately I guess)?
 
> On Sat, Dec 6, 2014 at 12:34 AM, Javi Merino <javi.merino@arm.com> wrote:
> 
> > diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
> 
> > +static int build_dyn_power_table(struct cpufreq_cooling_device *cpufreq_device,
> > +                               u32 capacitance)
> > +{
> > +       struct power_table *power_table;
> > +       struct dev_pm_opp *opp;
> > +       struct device *dev = NULL;
> > +       int num_opps, cpu, i, ret = 0;
> 
> Why not initialize num_opps and i to 0 here?

ok

> > +       unsigned long freq;
> > +
> > +       num_opps = 0;
> > +
> > +       rcu_read_lock();
> > +
> > +       for_each_cpu(cpu, &cpufreq_device->allowed_cpus) {
> 
> All these CPUs must be sharing the OPPs as they must be supplied
> from a single clock line. But probably you need to iterate over all
> because you don't know which ones share OPP. Right ? Probably
> the work I am doing around getting new OPP bindings might solve
> this..

Is this loop pointless?  I seem to recall that it was needed but I
forgot the details.  If you think it is, I can remove it.

> > +               dev = get_cpu_device(cpu);
> > +               if (!dev)
> 
> Is this allowed? I understand you can continue, but this is not
> possible. Right ? So, print a error here?

Ok, now it prints an error.

> > +                       continue;
> > +
> > +               num_opps = dev_pm_opp_get_opp_count(dev);
> > +               if (num_opps > 0) {
> > +                       break;
> > +               } else if (num_opps < 0) {
> > +                       ret = num_opps;
> > +                       goto unlock;
> > +               }
> > +       }
> > +
> > +       if (num_opps == 0) {
> > +               ret = -EINVAL;
> > +               goto unlock;
> > +       }
> > +
> > +       power_table = kcalloc(num_opps, sizeof(*power_table), GFP_KERNEL);
> > +
> > +       i = 0;
> 
> Either initialize i at the beginning or in the initialization part of
> for loop below.

As part of the for loop.
 
> > +       for (freq = 0;
> > +            opp = dev_pm_opp_find_freq_ceil(dev, &freq), !IS_ERR(opp);
> > +            freq++) {
> > +               u32 freq_mhz, voltage_mv;
> > +               u64 power;
> > +
> > +               freq_mhz = freq / 1000000;
> > +               voltage_mv = dev_pm_opp_get_voltage(opp) / 1000;
> > +
> > +               /*
> > +                * Do the multiplication with MHz and millivolt so as
> > +                * to not overflow.
> > +                */
> > +               power = (u64)capacitance * freq_mhz * voltage_mv * voltage_mv;
> > +               do_div(power, 1000000000);
> > +
> > +               /* frequency is stored in power_table in KHz */
> > +               power_table[i].frequency = freq / 1000;
> > +               power_table[i].power = power;
> > +
> > +               i++;
> 
> Why here and not with freq++?

As part of the for loop as well.
 
> > +       }
> > +
> > +       if (i == 0) {
> > +               ret = PTR_ERR(opp);
> > +               goto unlock;
> > +       }
> > +
> > +       cpufreq_device->dyn_power_table = power_table;
> > +       cpufreq_device->dyn_power_table_entries = i;
> > +
> > +unlock:
> > +       rcu_read_unlock();
> > +       return ret;
> > +}
> > +
> > +static u32 cpu_freq_to_power(struct cpufreq_cooling_device *cpufreq_device,
> > +                       u32 freq)
> 
> Because the patch is screwed up a bit, I really can't see if the 'u'
> or u32 is directly
> below the 's' of struct cpufreq_cooling_device. Running checkpatch with --strict
> will take care of that probably. Sorry if you have already taken care of that..

It wasn't.  I'll run checkpatch with --strict on next submission.

> > +{
> > +       int i;
> > +       struct power_table *pt = cpufreq_device->dyn_power_table;
> > +
> > +       for (i = 1; i < cpufreq_device->dyn_power_table_entries; i++)
> > +               if (freq < pt[i].frequency)
> > +                       break;
> > +
> > +       return pt[i - 1].power;
> > +}
> 
> > +static u32 get_static_power(struct cpufreq_cooling_device *cpufreq_device,
> > +                       unsigned long freq)
> > +{
> > +       struct device *cpu_dev;
> > +       struct dev_pm_opp *opp;
> > +       unsigned long voltage;
> > +       struct cpumask *cpumask = &cpufreq_device->allowed_cpus;
> > +       unsigned long freq_hz = freq * 1000;
> > +
> > +       if (!cpufreq_device->plat_get_static_power)
> > +               return 0;
> > +
> > +       cpu_dev = get_cpu_device(cpumask_any(cpumask));
> 
> Similar to the way you have used for-each-cpu earlier, the cpu
> returned from above maynot have opps attached to it. Right ?
> 
> Probably you can keep a copy of the cpu_dev we have opps attached
> with somewhere and reuse it.

Sounds like a good idea, done.

> > +
> > +       rcu_read_lock();
> > +
> > +       opp = dev_pm_opp_find_freq_exact(cpu_dev, freq_hz, true);
> 
> So, this might fail if I am not wrong.
> 
> > +       voltage = dev_pm_opp_get_voltage(opp);
> > +
> > +       rcu_read_unlock();
> > +
> > +       if (voltage == 0) {
> > +               dev_warn_ratelimited(cpu_dev,
> > +                               "Failed to get voltage for frequency %lu: %ld\n",
> > +                               freq_hz, IS_ERR(opp) ? PTR_ERR(opp) : 0);
> > +               return 0;
> > +       }
> > +
> > +       return cpufreq_device->plat_get_static_power(cpumask, voltage);
> > +}
> 

Cheers,
Javi


  reply	other threads:[~2014-12-08 12:50 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-05 19:04 [RFC PATCH v6 0/9] The power allocator thermal governor Javi Merino
2014-12-05 19:04 ` [RFC PATCH v6 1/9] tracing: Add array printing helpers Javi Merino
2014-12-08 14:39   ` Dave P Martin
2014-12-08 15:42   ` Steven Rostedt
2014-12-08 16:04     ` Dave P Martin
2014-12-10 10:52       ` Javi Merino
2014-12-05 19:04 ` [RFC PATCH v6 2/9] tools lib traceevent: Generalize numeric argument Javi Merino
2014-12-05 19:04 ` [RFC PATCH v6 3/9] tools lib traceevent: Add support for __print_u{8,16,32,64}_array() Javi Merino
2014-12-05 19:04 ` [RFC PATCH v6 4/9] thermal: let governors have private data for each thermal zone Javi Merino
2014-12-08  4:11   ` Zhang Rui
2015-01-23 14:33     ` Javi Merino
2014-12-05 19:04 ` [RFC PATCH v6 5/9] thermal: extend the cooling device API to include power information Javi Merino
2014-12-23 15:14   ` Eduardo Valentin
2015-01-05 15:37     ` Javi Merino
2015-01-05 21:04       ` Eduardo Valentin
2015-01-06 10:34         ` Javi Merino
2015-01-06 13:08           ` Eduardo Valentin
2014-12-05 19:04 ` [RFC PATCH v6 6/9] thermal: cpu_cooling: implement the power cooling device API Javi Merino
2014-12-08  5:49   ` Viresh Kumar
2014-12-08 12:50     ` Javi Merino [this message]
2014-12-08 13:31       ` Viresh Kumar
2014-12-08 14:22         ` Javi Merino
2014-12-09  1:59           ` Viresh Kumar
2014-12-09 10:32             ` Javi Merino
2014-12-09 10:36               ` Viresh Kumar
2014-12-09 11:00                 ` Javi Merino
2014-12-09 11:06                   ` Viresh Kumar
2014-12-09 11:23                     ` Javi Merino
2015-01-02 14:37                   ` Eduardo Valentin
2015-01-05 16:53                     ` Javi Merino
2015-01-05 20:44                       ` Eduardo Valentin
2015-01-06 11:01                         ` Javi Merino
2015-01-28  5:23   ` Eduardo Valentin
2015-01-29 11:19     ` Punit Agrawal
2015-01-29  0:15       ` Eduardo Valentin
2015-01-29 19:06         ` Javi Merino
2014-12-05 19:04 ` [RFC PATCH v6 7/9] thermal: introduce the Power Allocator governor Javi Merino
2015-01-02 15:46   ` Eduardo Valentin
2015-01-06 13:23     ` Javi Merino
2015-01-06 14:18       ` Eduardo Valentin
2015-01-06 14:50         ` Javi Merino
2015-01-02 15:51   ` Eduardo Valentin
2014-12-05 19:04 ` [RFC PATCH v6 8/9] thermal: add trace events to the power allocator governor Javi Merino
2014-12-05 19:04 ` [RFC PATCH v6 9/9] of: thermal: Introduce sustainable power for a thermal zone Javi Merino
2015-01-02 15:53   ` Eduardo Valentin
2015-01-06  9:42     ` Javi Merino
2015-01-06 13:13       ` Eduardo Valentin
2015-01-06 13:29         ` Javi Merino

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141208125033.GB2980@e104805 \
    --to=javi.merino@arm.com \
    --cc=Punit.Agrawal@arm.com \
    --cc=broonie@kernel.org \
    --cc=edubezval@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=rui.zhang@intel.com \
    --cc=viresh.kumar@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.