Hi Kevin,
On 04/16/2013 12:53 AM, Kevin Hilman wrote:
Andrii Tseglytskyi <andrii.tseglytskyi@xxxxxx> writes:
From: "Andrii.Tseglytskyi" <andrii.tseglytskyi@xxxxxx>
Following patch series introduces the Adaptive Body-Bias
LDO driver, which handles LDOs voltage during OPP change routine.
Current implementation is based on patch series from
Mike Turquette:
http://marc.info/?l=linux-omap&m=134931341818379&w=2
ABB transition is a part of OPP changing sequence.
ABB can operate in the following modes:
- Bypass mode: Activated when ABB is not required
- FBB mode: Fast Body Bias mode, used on fast OPPs
Fast? I thought the 'F' was for Forward?
You are right. Should be 'Forward' here.
- RBB mode: Reverse Body Bias mode, used on slow OPPs
In current implementation ABB is converted to regulator.
Standalone OPP table is used to store ABB mode, it is defined
in device tree for each ABB regulator. It has the following format:
operating-points = <
/* uV ABB (0 - Bypass, 1 - FBB, 2 - RBB) */
880000 0
1060000 1
1250000 1
1260000 1
;
ABB regulator is linked to regulator chain
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:
cpufreq_cpu0
clk_set_rate(cpu0)
|
|-->set_voltage(ABB regulator) /* all ABB related stuff will be
handled here */
|
|-->set_voltage(smps123 regulator) /* actual voltage
scaling */
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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
