Linux on ARM based TI OMAP SoCs
 help / color / mirror / Atom feed
From: Mike Turquette <mturquette@linaro.org>
To: Andrii Tseglytskyi <andrii.tseglytskyi@ti.com>,
	Kevin Hilman <khilman@linaro.org>
Cc: linux-omap@vger.kernel.org, "Benoît Cousson" <b-cousson@ti.com>,
	"Tero Kristo" <t-kristo@ti.com>
Subject: Re: [RFC PATCH v2 0/6] ARM: OMAP3+: Introduce ABB driver
Date: Tue, 16 Apr 2013 12:07:03 -0700	[thread overview]
Message-ID: <20130416190703.19887.10780@quantum> (raw)
In-Reply-To: <516D46CC.3080705@ti.com>

Quoting Andrii Tseglytskyi (2013-04-16 05:40:44)
> On 04/16/2013 12:53 AM, Kevin Hilman wrote:
> > In addition to Mike's comments (which I completely agree with), it would
> > be very helfpul to see how this is actually used.  e.g, how the
> > regulators are chained together, how the proper ordering is managed,
> > etc. etc.
> 
> We would like to handle voltage scaling in the following way:
> 

I expanded the example below to include the SR AVS regulator.

> cpufreq_cpu0
> clk_set_rate(cpu0)
>      |
>      |-->set_voltage(ABB regulator)
>                  |
>                  |-->set_voltage(AVS)
>                             |
>                             |-->set_voltage(smps123 regulator)

Hi Andrii,

Why was regulator chaining chosen over a simple sequence of calls to
regulator_set_voltage?  Instead of nested calls into the regulator
framework, why don't you just make the calls serially?  E.g:

regulator_set_voltage(abb_reg, foo_volt);
regulator_set_voltage(avs_reg, bar_volt);
regulator_set_voltage(smps123_reg, baz_volt);

It is still to be determined where these calls originate from; maybe
from clock notifiers, maybe directly from the cpufreq driver's .target()
callback, or maybe somewhere else.  Regardless, I do not see why
regulator chaining is truly necessary here.  You are just calling
regulator_set_voltage in sequence on a few regulators, right?

I think it would help me a lot to understand why regulator chaining is a
requirement for this to work properly.

Thanks,
Mike

> 
> 
> This simple model will be extended to handle AVS as a part of the chain.
> smps123 regulator may be changed to VP/VC regulator.
> 
> Following example is from integration branch, which already has smps123 
> regulator.
> It demonstrates an example of linkage to chain. ABB regulator is linked 
> with smps123 and cpu0 inside device tree.
> cpu0 calls set_voltage() function for ABB, and then ABB calls 
> set_voltage() function for smps123 to do actual voltage scaling.
> 
> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
> index bb5ee70..c8cbbee 100644
> --- a/arch/arm/boot/dts/omap5.dtsi
> +++ b/arch/arm/boot/dts/omap5.dtsi
> @@ -36,7 +36,7 @@
>          cpus {
>                  cpu@0 {
>                          compatible = "arm,cortex-a15";
> -                       cpu0-supply = <&smps123_reg>;
> +                       cpu0-supply = <&abb_mpu>;
>                          operating-points = <
>                                  /* kHz    uV */
>                                  /* Only for Nominal Samples */
> @@ -94,6 +94,7 @@
>                  reg = <0x4ae07cdc 0x8>,
>                        <0x4ae06014 0x4>;
>                  ti,tranxdone_status_mask = <0x80>;
> +               avs-supply = <&smps123_reg>;
>                  operating-points = <
>                          /* uV   ABB */
>                          880000  0
> 
> This RFC patch series is verified together with:
> https://patchwork.kernel.org/patch/2445091/
> 
> Kevin, what do you think about this model in general? Does it fit to 
> regulator framework?
> 
> Thank you.
> 
> Regards,
> Andrii

  reply	other threads:[~2013-04-16 19:07 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-15 13:28 [RFC PATCH v2 0/6] ARM: OMAP3+: Introduce ABB driver Andrii Tseglytskyi
2013-04-15 13:28 ` [RFC PATCH v2 1/6] ARM: dts: OMAP36xx: add device tree for ABB Andrii Tseglytskyi
2013-04-15 13:28 ` [RFC PATCH v2 2/6] ARM: dts: OMAP4: " Andrii Tseglytskyi
2013-04-15 13:28 ` [RFC PATCH v2 3/6] ARM: dts: OMAP5: " Andrii Tseglytskyi
2013-04-15 13:28 ` [RFC PATCH v2 4/6] ARM: OMAP3+: ABB: add aliases for sysclk used in ABB driver Andrii Tseglytskyi
2013-04-15 13:28 ` [RFC PATCH v2 5/6] ARM: OMAP3+: ABB: introduce " Andrii Tseglytskyi
2013-04-15 16:43   ` Mike Turquette
2013-04-16 11:28     ` Andrii Tseglytskyi
2013-04-15 13:28 ` [RFC PATCH v2 6/6] ARM: OMAP3+: ABB: introduce debugfs entry Andrii Tseglytskyi
2013-04-15 21:53 ` [RFC PATCH v2 0/6] ARM: OMAP3+: Introduce ABB driver Kevin Hilman
2013-04-16 12:40   ` Andrii Tseglytskyi
2013-04-16 19:07     ` Mike Turquette [this message]
2013-04-18 12:47       ` Grygorii Strashko
2013-04-16 19:18     ` Kevin Hilman
2013-04-18 10:55       ` Andrii Tseglytskyi

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=20130416190703.19887.10780@quantum \
    --to=mturquette@linaro.org \
    --cc=andrii.tseglytskyi@ti.com \
    --cc=b-cousson@ti.com \
    --cc=khilman@linaro.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=t-kristo@ti.com \
    /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