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
next prev parent 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