public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Stephen Warren <swarren@wwwdotorg.org>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Lists linaro-kernel <linaro-kernel@lists.linaro.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Arvind Chauhan <arvind.chauhan@arm.com>,
	Stephen Warren <swarren@nvidia.com>,
	Doug Anderson <dianders@chromium.org>,
	Russell King - ARM Linux <linux@arm.linux.org.uk>,
	Nicolas Pitre <nicolas.pitre@linaro.org>,
	Thomas Abraham <thomas.abraham@linaro.org>,
	Peter De Schrijver <pdeschrijver@nvidia.com>
Subject: Re: [PATCH V4 2/3] cpufreq: add support for intermediate (stable) frequencies
Date: Fri, 23 May 2014 09:56:04 -0600	[thread overview]
Message-ID: <537F6F94.7040900@wwwdotorg.org> (raw)
In-Reply-To: <CAKohpokhiTpTd-ByFUuOL1hR7MnKPPQj-peH7S5oFxowKt0BeQ@mail.gmail.com>

On 05/22/2014 10:24 PM, Viresh Kumar wrote:
> On 22 May 2014 22:07, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> It seems rather odd to set both freqs->old and freqs->new to the
>> intermediate frequency upon success. It feels like it would make more
>> sense to remove that final else clause above, and do the following where
>> this function is called:

>>>  static int __target_index(struct cpufreq_policy *policy,
>>>                         struct cpufreq_frequency_table *freq_table, int index)
>>>  {
>>> -     struct cpufreq_freqs freqs;
>>> +     struct cpufreq_freqs freqs = {.old = policy->cur, .flags = 0};
>>> +     unsigned int intermediate_freq = 0;
>>>       int retval = -EINVAL;
>>>       bool notify;
>>>
>>>       notify = !(cpufreq_driver->flags & CPUFREQ_ASYNC_NOTIFICATION);
>>> -
>>>       if (notify) {
>>> -             freqs.old = policy->cur;
>>> -             freqs.new = freq_table[index].frequency;
>>> -             freqs.flags = 0;
>>> +             /* Handle switching to intermediate frequency */
>>> +             if (cpufreq_driver->get_intermediate) {
>>> +                     retval = __target_intermediate(policy, &freqs, index);
>>> +                     if (retval)
>>> +                             return retval;
>>
>> Shouldn't this all be outside the if (notify) block, so that
>> __target_intermediate is always called, and it's just the notify
>> callbacks that gets skipped if (!notify)?
> 
> So, this is logic I had:
> 
> Should we support 'intermediate freq' infrastructure when driver wants
> to handle notifications themselves?
> 
> Probably not.
> 
> The whole point of implementing this 'intermediate freq' infrastructure is to
> get rid of code redundancy while sending notifications. If drivers want to
> handle notifications then they better handle intermediate freqs as well in
> their target_index() callback. They don't need to implement another routine
> for intermediate stuff..

Oh OK, I guess the "notify" value is static then, and driver defined, so
this is fine.


  reply	other threads:[~2014-05-23 15:56 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-21  8:59 [PATCH V4 0/3] cpufreq: add support for intermediate (stable) frequencies Viresh Kumar
2014-05-21  8:59 ` [PATCH V4 1/3] cpufreq: handle calls to ->target_index() in separate routine Viresh Kumar
2014-05-26 23:21   ` Rafael J. Wysocki
2014-05-26 23:59     ` Viresh Kumar
2014-05-21  8:59 ` [PATCH V4 2/3] cpufreq: add support for intermediate (stable) frequencies Viresh Kumar
2014-05-22 16:37   ` Stephen Warren
2014-05-23  4:24     ` Viresh Kumar
2014-05-23 15:56       ` Stephen Warren [this message]
2014-05-26  4:01         ` Viresh Kumar
2014-05-28 19:40   ` Doug Anderson
2014-05-30  1:19     ` Viresh Kumar
2014-05-21  8:59 ` [PATCH V4 3/3] cpufreq: Tegra: implement intermediate frequency callbacks Viresh Kumar
2014-05-22 16:39   ` Stephen Warren
2014-05-23  4:05     ` Viresh Kumar
2014-05-29 17:42       ` Stephen Warren
2014-06-02 10:01         ` Viresh Kumar
2014-05-29 17:40   ` Stephen Warren
2014-05-30  1:56     ` Viresh Kumar
2014-05-30 16:26       ` Stephen Warren
2014-06-02 10:06         ` Viresh Kumar
2014-06-02 16:50           ` Stephen Warren

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=537F6F94.7040900@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --cc=arvind.chauhan@arm.com \
    --cc=dianders@chromium.org \
    --cc=linaro-kernel@lists.linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=nicolas.pitre@linaro.org \
    --cc=pdeschrijver@nvidia.com \
    --cc=rjw@rjwysocki.net \
    --cc=swarren@nvidia.com \
    --cc=thomas.abraham@linaro.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox