public inbox for linux-arm-kernel@lists.infradead.org 
 help / color / mirror / Atom feed
From: sboyd@codeaurora•org (Stephen Boyd)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 2/2] cpufreq: cpu0: Extend support beyond CPU0
Date: Thu, 26 Jun 2014 17:06:00 -0700	[thread overview]
Message-ID: <53ACB568.4000903@codeaurora.org> (raw)
In-Reply-To: <CAKohpo=Q7eWNwcK6KF9_U-zD0g=96QHW9hiQupLpV5GqoWE+mA@mail.gmail.com>

On 06/26/14 03:52, Viresh Kumar wrote:
> On 26 June 2014 00:32, Stephen Boyd <sboyd@codeaurora•org> wrote:
>> I don't think this driver should be using regulator_get_optional() (Mark
>> B. please correct me if I'm wrong). I doubt a supply is actually
>> optional for CPUs, just some DTs aren't specifying them. In those cases,
>> the regulator core will insert a dummy supply and the code will work
>> without having to check for probe defer and error pointers.
> Hi Stephen,
>
> Thanks for your comments.
>
> Leaving the above one, I have tried to fix all you mentioned. And it surely
> looks much better now.
>
> I would like to wait for a day or two before sending V2, as people might
> be reviewing it and the above issue is still wide open..
>
> But in case you wanna test it (completely changed I must say, but
> for good), its here:
>
> git://git.linaro.org/people/viresh.kumar/linux.git cpufreq/cpu0-krait-v2

I gave it a spin. It looks mostly good except for the infinite loop:

diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index b7ee67c4d1c0..6744321ae33d 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -138,8 +138,10 @@ try_again:
                }
 
                /* Try with "cpu-supply" */
-               if (reg == reg_cpu0)
+               if (reg == reg_cpu0) {
+                       reg = reg_cpu;
                        goto try_again;
+               }
 
                dev_warn(cpu_dev, "failed to get cpu%d regulator: %ld\n",
                         cpu, PTR_ERR(cpu_reg));

and I think we just want reg_cpu to be "cpu", not "cpu-supply" because I
think the regulator core adds in the "-supply" part already.

After fixing that I can get cpufreq going. I'm currently working on
populating the OPPs at runtime without relying on DT. So eventually I'll
need this patch:

diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index b7ee67c4d1c0..6744321ae33d 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -239,11 +241,6 @@ static int cpu0_cpufreq_init(struct cpufreq_policy *policy)
        }
 
        ret = of_init_opp_table(cpu_dev);
-       if (ret) {
-               dev_err(cpu_dev, "failed to init OPP table: %d\n", ret);
-               goto out_put_node;
-       }
-
        ret = dev_pm_opp_init_cpufreq_table(cpu_dev, &freq_table);
        if (ret) {
                dev_err(cpu_dev, "failed to init cpufreq table: %d\n", ret);

which I hope is ok.

Finally, checking for equivalent pointers from clk_get() will work now,
but it isn't future-proof if/when the clock framework starts returning
dynamically allocated clock pointers for each clk_get() invocation.
Maybe we need a function in the common clock framework that tells us if
the clocks are the same either via DT or by taking two clock pointers?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

  reply	other threads:[~2014-06-27  0:06 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-25  8:42 [PATCH 0/2] cpufreq: cpu0: Extend support beyond CPU0 Viresh Kumar
2014-06-25  8:42 ` [PATCH 1/2] cpufreq: Add support for per-policy driver data Viresh Kumar
2014-06-25  8:42 ` [PATCH 2/2] cpufreq: cpu0: Extend support beyond CPU0 Viresh Kumar
2014-06-25 19:02   ` Stephen Boyd
2014-06-26  1:55     ` Viresh Kumar
2014-06-26  7:34     ` Viresh Kumar
2014-06-26 10:52     ` Viresh Kumar
2014-06-27  0:06       ` Stephen Boyd [this message]
2014-06-27  1:53         ` Mike Turquette
2014-06-27  2:15           ` Viresh Kumar
2014-06-30  7:57             ` Viresh Kumar
2014-06-30 18:33               ` Rob Herring
2014-07-01 11:14                 ` Viresh Kumar
2014-07-01 22:00                   ` Mike Turquette
2014-07-02  3:32                     ` Viresh Kumar
2014-06-27  2:26         ` Viresh Kumar
2014-06-26 22:08     ` Mark Brown
2014-06-28 14:52   ` Shawn Guo
2014-06-30  4:50     ` Viresh Kumar

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=53ACB568.4000903@codeaurora.org \
    --to=sboyd@codeaurora$(echo .)org \
    --cc=linux-arm-kernel@lists$(echo .)infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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