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 3/3] cpufreq: Tegra: implement intermediate frequency callbacks
Date: Thu, 29 May 2014 11:42:49 -0600 [thread overview]
Message-ID: <53877199.5090009@wwwdotorg.org> (raw)
In-Reply-To: <CAKohpomdOEspgfxNR5p=PVLCeSUYcUWZ2cWGGQo0b__ptKiYtw@mail.gmail.com>
On 05/22/2014 10:05 PM, Viresh Kumar wrote:
> On 22 May 2014 22:09, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> I think the call to tegra_target_intermediate() is wrong here; shouldn't
>> the cpufreq core guarantee that tegra_target_intermediate() has always
>> been called before tegra_target(), so there's no need to repeat that
>> call here?
>> Also, tegra_target() doesn't seem to follow the rule documented by patch
>> 2/3 that states ->target() should restore the orignal frequency on
>> error. I'm not even sure if that's possible in general.
>
> I thought I took care of that. Can you please give some example when
> we aren't restoring original frequency on failure ?
>
> About the rule, that has to be the expectation from core as there is no
> way out that for core to know what happened at end of target_index()..
>
> It can call get_rate() but that would be over engineering it looks ..
E.g. in the following code after the series is applied:
> ret = clk_set_rate(pll_x_clk, rate * 1000);
> /* Restore to earlier frequency on error, i.e. pll_x */
> if (ret)
> pr_err("Failed to change pll_x to %lu\n", rate);
>
> ret = clk_set_parent(cpu_clk, pll_x_clk);
If the clk_set_rate() failed, we have no idea what the pll_x rate is; I
don't think the clock API guarantees that zero HW changes have been made
if the function fails. Yet the code switches the CPU clock back to pll_x
without attempting to fix the pll_x rate to be the old rate. Perhaps
there's not much that can be done here though, since if one
clk_set_rate() failed, perhaps the one to fix it will too.
I suspect there are other issues, like switching between pll_p/pllx
might not be restored on error, and the EMC frequency isn't switched
back, etc.
next prev parent reply other threads:[~2014-05-29 17:42 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
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 [this message]
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=53877199.5090009@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 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.