regulator/OMAP: support VC/VP support in dts

Hi,

Texas Instrument's OMAP Processor have a dedicated hardware module which is customised to operate with Power Management IC(PMIC) over an dedicated I2C. The communication involves a few SoC internal modules as follows:
PMIC - The power management chip on the dedicated I2C (sometimes called I2C_SR) Voltage controller - consists of an hardware i2c controller and interface customized for PMICs. VC consists of multiple VC Channels, each channel representing a variable voltage rail supply to the SoC.
Voltage Processor(VP) - controls the voltage requests to VC channel SmartReflex(Adaptive Voltage control) - (SR/AVS)- specialized hardware block which can dynamically control device voltage without software intervention. This module communicates with VP.

In the simplest view, a simple voltage set operation is as follows:
Vp->VC Channel -> VC -> PMIC

Note, there may be dedicated PMIC per variable voltage rail OR PMICs which provide control for multiple SMPS supplying variable rails etc.

In addition, there is an Adaptive Voltage Control (AVS) technique called SmartReflex which can operate (in a configuration called continous monitoring hardware loop or class 3 mode of operation), in which the SmartReflex block communicates with Voltage Processor.

We have an OMAP specific implementation in arch/arm/mach-omap2 which does not tree VC/VP or PMIC as Linux devices, but as data which is configured as needed.

In this series, we introduce replacement approach which has support for only Device Tree as OMAP is transitioning completely away from non-DT approach.

As an overview, the following approach is taken.

PMIC is now the regulator driver - generic omap-pmic-regulator (patch #1) Voltage controller and voltage controller channel is handled by driver/power/avs/omap_vc.c

Voltage processor is handled by driver/power/avs/omap_vp.c

Benefit of using drivers/power/avs is also to set the foundation to convert SmartReflex AVS into device tree based solution. (next stage).

S/w dependency is as follows:
Voltage controller <- Voltage Processor
Voltage Processor registers with OMAP_PMIC it's controller operations OMAP_PMIC uses the controller operations to call vp which in turn calls VC to setup the communication chain.

This allows us to maintain this as a module if needed as well (something our existing implementation was not capable of doing).

The series is also available here:
https://github.com/nmenon/linux-2.6-playground/commits/devel/vc-vp-regulator-rfc
git://github.com/nmenon/linux-2.6-playground.git
branch: devel/vc-vp-regulator-setv-v1-rfc-2

This depends on a few patches for cpufreq/clock node I added in, merged with 3.10-rc6 master + the following for-next branches benoit/for_3.11/dts
mturquette/clk-next
broonie/for-next
rafael/linux-next
Available as branch: devel/vc-vp-base

Note:
1. AVS device tree conversion will have to depend on this due to dependency on VP
2. Clock node strategy used here is based on implementation I had posted here:

	http://marc.info/?t=136804008400001&r=1&w=2

3. I chose OMAP4460 based PandaBoard ES platform as my development platform and patch #4 in this series is an attempt to showcase how it will look like.
Rationale: weird PMIC configuration was used in PandaBoard ES. Ability to handle that platform makes introduction to other platforms/SoCs trivial.
4. Once this approach is agreed upon, I can do the dts changes for all SoCs OMAP3-5 and will post a formal series.

Related defects:
https://bugzilla.kernel.org/show_bug.cgi?id=58541
https://bugzilla.kernel.org/show_bug.cgi?id=58611

Related discussion:
v1 of RFC: http://marc.info/?t=136924689600005&r=1&w=2

    related discussion: http://marc.info/?t=137166954900005&r=1&w=2

Nishanth Menon (8):
regulator: Introduce OMAP regulator to control PMIC over VC/VP PM / AVS: Introduce support for OMAP Voltage Controller(VC) with
device tree nodes
PM / AVS: Introduce support for OMAP Voltage Processor(VP) with
device tree nodes
ARM: dts: OMAP4: add voltage controller nodes
ARM: dts: OMAP4: add voltage processor nodes
ARM: dts: TWL6030/OMAP4: Add OMAP voltage path linkage
ARM: dts: omap4-panda-es: add TPS62361 supply for vdd_mpu
ARM: dts: OMAP4-panda-es: use tps regulator as cpu0 supply

 .../devicetree/bindings/power/omap-vc.txt          |   99 ++
 .../devicetree/bindings/power/omap-vp.txt          |   39 +
 .../bindings/regulator/omap-pmic-regulator.txt     |   41 +
 arch/arm/boot/dts/omap4-panda-common.dtsi          |    1 +
 arch/arm/boot/dts/omap4-panda-es.dts               |   35 +
 arch/arm/boot/dts/omap4-sdp.dts                    |    1 +
 arch/arm/boot/dts/omap4-var-som.dts                |    1 +
 arch/arm/boot/dts/omap4.dtsi                       |   73 +-
 arch/arm/boot/dts/omap443x.dtsi                    |   32 +-
 arch/arm/boot/dts/omap4460.dtsi                    |   33 +-
 arch/arm/boot/dts/tps62361_omap.dtsi               |   18 +
 arch/arm/boot/dts/twl6030_omap4.dtsi               |   35 +
 drivers/power/avs/Kconfig                          |   15 +
 drivers/power/avs/Makefile                         |   20 +
 drivers/power/avs/omap_vc.c                        | 1513 ++++++++++++++++++++
 drivers/power/avs/omap_vc.h                        |   67 +
 drivers/power/avs/omap_vp.c                        |  892 ++++++++++++
 drivers/regulator/Kconfig                          |   12 +
 drivers/regulator/Makefile                         |    1 +
 drivers/regulator/omap-pmic-regulator.c            |  638 +++++++++
 include/linux/regulator/omap-pmic-regulator.h      |  162 +++
 21 files changed, 3724 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/power/omap-vc.txt
 create mode 100644 Documentation/devicetree/bindings/power/omap-vp.txt
 create mode 100644 Documentation/devicetree/bindings/regulator/omap-pmic-regulator.txt
 create mode 100644 arch/arm/boot/dts/tps62361_omap.dtsi
 create mode 100644 arch/arm/boot/dts/twl6030_omap4.dtsi
 create mode 100644 drivers/power/avs/omap_vc.c
 create mode 100644 drivers/power/avs/omap_vc.h
 create mode 100644 drivers/power/avs/omap_vp.c
 create mode 100644 drivers/regulator/omap-pmic-regulator.c
 create mode 100644 include/linux/regulator/omap-pmic-regulator.h

1.7.9.5

Texas Instrument's OMAP SoC generations since OMAP3-5 introduced an TI custom hardware block to better facilitate and standardize integration of Power Management ICs which communicate over I2C.

In fact, many custom PMICs were designed to be usable over this interface. On the other hand, generic PMICs which are compatible to the I2C protocol supported by Voltage controller may also be used.

In general, the following categories of PMICs exist:

a) PMICs which are completely controlled by voltage controller/voltage processor pair - this implies even configuration needs to be done over the same interface. Example: TPS62361 used on PandaBoard-ES and many OMAP4460 based platforms. Few Maxim and Fairchild PMICs used on certain products would fall in this category.
- Note: in this case, there may not even exist/needed to support an "traditional Linux regulator driver"

b) PMICs which provide two views over two I2C interfaces - however, voltage can only be set only on one of them. Example: TWL4030/5030:
allows us to use Voltage controller once we set up a bit over regular I2C - This is used in OMAP3. TWO6030/TWL6032 - configuration *has* to be performed over regular i2c (example smps_offset) and voltage control *has* to be performed by using voltage controller/processor.
- Note: in this case, there may exist "traditional Linux regulator driver" however, it may not support in any form SMPS modelling for that part of the device which is exposed to voltage controller/processor.
c) PMICs which allow voltage and configurations over either i2c interfaces - TWL6035/TWL6037/Palmas family of TI processor
- Note: in this case, there may exist "traditional Linux regulator driver" and, it may support in some form SMPS modelling for that part of the device which is exposed to voltage controller/processor.
d) custom PMICs which are setup so that no configuration is needed to be performed and they operate with preset register offsets and minimal conferability using voltage controller/processor.
- Note: in this case, there may not even exist/needed to support an "traditional Linux regulator driver"

However, no matter the type of PMIC used, the OMAP view of a PMIC is generic when used over voltage controller/processor. We attempt to model this generic view of the regulator represented by OMAP SoC.

Alternative to this approach would be to "hack" into the get voltage/set voltage interfaces of regulator drivers which represent the rest of the PMIC controlled over regular I2C interface and re-route the requests to voltage controller/processor. But, by doing that, we needlessly create additional code which may be abstracted out into device tree node information.

Since the regulator node representing PMIC, voltage controller, processors are probed at varied points in time, probe deferral is used to sequence in the right order. It is expected by the driver to register omap_pmic_register_controller_ops providing mandatory operations at the earliest possible opportunity.

Despite the current SoCs implementing the solution based on voltage controller and voltage processor (which are part of the OMAP SoC modules which enable Adaptive Voltage Scaling class support), the interfaces are generic enough to handle future equivalent modules.

---
 .../bindings/regulator/omap-pmic-regulator.txt     |   41 ++
 drivers/regulator/Kconfig                          |   12 +
 drivers/regulator/Makefile                         |    1 +
 drivers/regulator/omap-pmic-regulator.c            |  638 ++++++++++++++++++++
 include/linux/regulator/omap-pmic-regulator.h      |  162 +++++
 5 files changed, 854 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/regulator/omap-pmic-regulator.txt
 create mode 100644 drivers/regulator/omap-pmic-regulator.c
 create mode 100644 include/linux/regulator/omap-pmic-regulator.h

new file mode 100644
index 0000000..6991e58
@@ -0,0 +1,41 @@
+Generic Power Management IC(PMIC) Regulator for Texas Instruments OMAP SoCs
+
+Required Properties:
+- compatible: Should be one of:
+  - "ti,omap-twl4030-vdd1" - TWL4030/5030/TPS65950 VDD1
+  - "ti,omap-twl4030-vdd2" - TWL4030/5030/TPS65950 VDD2
+  - "ti,omap-twl6030-vcore1" - TWL6030 VCORE1
+  - "ti,omap-twl6030-vcore2" - TWL6030 VCORE2
+  - "ti,omap-twl6030-vcore3" - TWL6030 VCORE3
+  - "ti,omap-tps62361" - TPS62361 VSEL1
+  - "ti,omap-twl6032-smps1" - TWL6032 SMPS1
+  - "ti,omap-twl6032-smps2" - TWL6032 SMPS2
+  - "ti,omap-twl6032-smps5" - TWL6032 SMPS5
+  - "ti,omap-twl6035-smps1" - TWL6035/6037 in SMPS1, 12, 123 configuration
+  - "ti,omap-twl6035-smps4" - TWL6035/6037 in SMPS4, 45 configuration
+  - "ti,omap-twl6035-smps8" - TWL6035/6037 in SMPS8 configuration
+
+Optional Properties:
+- gpios: OF device-tree gpio specification - can be an array, will be setup
+	in the order of definition and set to the flags.
+- pinctrl: OF device-tree pinctrl definitions as needed (usually for the GPIOs)
+- ti,boot-voltage-micro-volts - voltage in microvolts that bootloader is leaving
+	over the PMIC at. This may be 'PMIC data manual configuration' if
+	bootloader does not set an value, or appropritate value.
+
+
+Example: Sample PMIC description
+omap_tps62361: tps62361 {
+	compatible = "ti,omap-tps62361";
+};
+
+/* Board Specific configuration */
+&omap_tps62361 {
+	pinctrl-names = "default";
+	pinctrl-0 = <
+		&tps62361_wkgpio_pins
+	>;
+	gpios = <&gpio1 7 1>;	/* gpio_wk7 */
+
+	ti,boot-voltage-micro-volts=<1200000>;
+};

index 9296425..e14b534 100644
@@ -482,6 +482,18 @@ config REGULATOR_TI_ABB
 	  on TI SoCs may be unstable without enabling this as it provides
 	  device specific optimized bias to allow/optimize functionality.
 
+config REGULATOR_TI_OMAP_PMIC
+	tristate "TI Generic regulator for Voltage Processor / Controller"
+	depends on ARCH_OMAP
+	help
+	  Select this option to support PMICs over Texas Instruments'
+	  custom Voltage Processor + Voltage Controller data interface
+	  used in OMAP SoCs. This is a specific "write-only" interface
+	  designed to interface with I2C based PMICs.
+
+	  This option enables the regulator driver representing the PMIC
+	  on the OMAP VC/VP hardware.
+
 config REGULATOR_VEXPRESS
 	tristate "Versatile Express regulators"
 	depends on VEXPRESS_CONFIG

index 26e6c4a..8874e74 100644
@@ -64,6 +64,7 @@ obj-$(CONFIG_REGULATOR_TPS65912) += tps65912-regulator.o
 obj-$(CONFIG_REGULATOR_TPS80031) += tps80031-regulator.o
 obj-$(CONFIG_REGULATOR_TWL4030) += twl-regulator.o
 obj-$(CONFIG_REGULATOR_TI_ABB) += ti-abb-regulator.o
+obj-$(CONFIG_REGULATOR_TI_OMAP_PMIC) += omap-pmic-regulator.o
 obj-$(CONFIG_REGULATOR_VEXPRESS) += vexpress.o
 obj-$(CONFIG_REGULATOR_WM831X) += wm831x-dcdc.o
 obj-$(CONFIG_REGULATOR_WM831X) += wm831x-isink.o

1.7.9.5

I like the idea and had tried to implement it as well..lets get down to the details: If I understand what you are stating,
regulators such as twl-regulator has the same/similar data that is represented here. twl-regulator uses standard i2c path, it cannot send voltage over so called "SR path". Alrite, so, lets say we reuse definition of VDD1,
option 1) we just bypass get_voltage/set_voltage to point through to this function. result will be something similar to what we got here[1] Again, based on this discussion, it is wrong - and we already did implement the *wrong* way in OMAP and the new code is supposed to throw away the old code once all relevant platforms are converted to DT.
- now, we could improve this by passing rdev and slurp out required data from regulator structures, but obviously, as you pointed out, it wont be sufficient.
- In this solution, we will have existing regulator drivers supporting additional data path. *but* that also means that existing regulator drivers will need to be modified to handle multiple data path and "Just Work" wont happen - so not really good other than screw up existing regulator drivers with handling OMAP specific APIs in them.

option 2) make omap_pmic regulator use twl_regulator - regulator chaining.
- we already agreed that this is conceptually wrong[2](regulator talking to another regulator). So wont debate more here.
- but here, you'd have omap_pmic regulator "using twl/existing regulators" to pick up data about slew, conversion information etc..

This series attempts to keep omap pmic delta simplified to just the additional PMIC data, no replication of code or "OMAP specific infection" of existing generic regulators.

Is there any other suggestions how to pick up the data from an existing regulator and avoid few bytes of data replication?

[1]
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/mach-omap2/omap_twl.c#n142
[2] http://marc.info/?t=136513865200005&r=1&w=2

Regards,
Nishanth Menon

On Fri, Jul 05, 2013 at 08:55:07AM -0500, Nishanth Menon wrote:

Please write in paragraphs, an enormous wall of unbroken text isn't helpful for legibility.

I don't really know what you mean when you say "bypass get_voltage/set_voltage so it's kind of hard to comment... the link you posted appears to be a link to the code I'm reviewing so it's not terribly enlightening.

What makes you think that the existing regulator drivers need to be modified? They already have all the data exported to the core (or should do)... the only thing that's missing is the timeouts and it's not at all obvious why those need to be tuned per device.

Again I don't know what this is.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130705/37daebf2/attachment.sig>

Apologies on the same. Will try to do better.

:) it is similar, yes. by bypass get/set_voltage, I mean something like [1]

data path difference - Almost all standard regulators use i2c (standard i2c APIs) for every other SMPS/LDO except for the ones controlled by OMAP custom i2c path(vc/vp), the set_voltage/get_voltage needs a different implementation when it comes to using the vc/vp path.

I see that twl-regulator does not indeed do it, but, assuming the regulators have all the data exported to the core, the data is hidden in struct regulator_desc which is private to the device and driver. lets go through these:

OMAP VC hardware has no idea about how long to wait before giving up on an ongoing i2c transaction. This may depend on PMIC and what it does before acking on i2c.

Lets ignore this for the moment.

[1]
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=63bfff4e20211b464cbea6e79e5fd36df227c154

Regards,
Nishanth Menon

No, that's not a good idea.

That's just a simple matter of programming to fix, and any regulator which can work with this sort of table based stuff you're looking at here must also be able to be converted to work with the equivalent code in the regulator core so open coding is a deficiency in the driver.

There's no information about how to use this register in your bindings... but anyway, can't be too hard to add this if it's actually used.

Like I say I just don't see why this is even specified per device.

Or just trivially calculate it as we do currently.

Anything that implements a custom set_voltage() won't work with your data structure either...

Why would any of the drivers need to change to do this? They're already exporting the information.

So pick a high number (it's only for error cases...)?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130705/b856fb33/attachment.sig>

I agree.

OK, conceptually, I am a bit lost here (may be I thinking about "how the heck am I supposed to implement this?") - Hoping for your patience in trying to get through to my thick skull :)

Taking an example of twl-regulator and omap_pmic, are you suggesting omap_pmic to be a user twl-regulator using include/linux/regulator/consumer.h? or are you suggesting that omap_pmic should not be a regulator at all?

Could you suggest what you have in your mind here, I can see how we can make that happen. I am not averse to writing new code ofcourse.

Yes it is, and also happens to be how OMAPs achieve maximum power savings - when low power modes are achieved in OMAP(automatic hardware assisted commands are send to the specific command registers in PMIC and viceversa on wakeup) - but this also happens to be very specific to OMAP way of handling things. I can refer to the Reference Manual as to how it actually works, but that'd be an overkill, I will try to expand on the bindings a little more, I guess.

It would not work with OMAP either ;). But that said, drivers do freely implement custom set_voltage/get_voltage primarily because there are ranges in supported voltages that are non-linear and try to be generic to work on non-OMAP platforms as well. However, within the supported range, only the linear ranges are used with OMAP.

I am thinking here: two regulator drivers, using same rdev/desc for getting the data. probably makes no sense, I agree.

from hardware perspective yeah, if it does not lockup (based on erratas on specific devices ;) ). it also controls in part, the latency of response to Voltage processor from Voltage controller also needed for computing SmartReflex latencies (as it should consider worst case conditions)

Regards,
Nishanth Menon

No, I'm suggesting that omap_pmic find the TWL driver data at runtime (eg, using the device tree to locate the relevant regulator) and get the information out of the regulator driver that way. It can then tell the hardware about the data that way without having to explictly add every single regulator both standalone and to the OMAP driver.

OK, so this is a register defined by the OMAP architecture? I think it's reasonable to add something to allow this to be obtained to the core, using a DT property seems yucky since every board usingt this is going to have to cut'n'paste the value. Some sort of custom parameter readback thing perhaps, it doesn't have to be too generic.

Yes, that's kind of my point - as with the code Paul was implementing it doesn't matter if you can't support every single regualtor since the hardware design constrains what the regulator can do. The regualtor framework already has helpers which factor out the code for anything which has the limiations the OMAP hardware has (or where it doesn't we could add them) so there shouldn't be any need for a driver to provide custom callbacks.

OK, that's a bit more interesting but I expect such regulators will actually work with the linear ranges helpers I added the other day (Marvell had a PMIC using them and I realised that the same pattern can be applied to a bunch of other devices). Do you think that'd cover the cases you're aware of?

Another option is for the drivers to provide the data and use the helpers for their linear ranges as part of a more complex implementation.

OK, that's a bit more fun but I think the kernel wants that information
in general anyway since a software cpufreq driver or something might
want to make the same latency decisions. This is what set_voltage_time()
is for in part. But to a first approximation is there really much
variation in the numbers?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130705/15e22df1/attachment.sig>

Apologies on delayed response, I had spend sometime thinking about this(and try some prototype code), here it goes:

case #1 - TPS62361 has a single SMPS and a single generic i2c bus, one can talk on. In this case, you'd associate the regulator device in one place - i2cX or on custom SoC hardware interface.

When used with custom SoC hardware interface, generic tps62361 regulator which talks regular i2c wont even probe for omap_pmic to get the regulator data from tps62361 regulator driver. Even if we were to define the generic TPS62361 in dts nodes, it will fail probe as it cant access any of it's registers using generic i2c.

case #2 - TWL6030/2 has a multiple SMPS and LDOs and a two i2c bus one can talk on. however, SMPS meant for SoC can only be controlled by custom SoC hardware. In this case, we'd not even have a regulator_register taking place for SMPS controlled by custom hardware.

I am lost as to how we can even do this?

All the dts node tells for an SMPS today is:

vaux3: regulator-vaux3 {
         compatible = "ti,twl6030-vaux3";
} as an example.

the slew data is embedded inside the twl-regulator data structures - if it never gets probed, it wont make that data available in regulator core information.

so doing something like:

omap_pmic_vdd_mpu {
	pmic-supply = <&vcore1>;
};
wont work, unless we define a phandle vcore1.
vcore1: regulator-vcore1 {
	compatible="ti,twl6030-vcore1";
};

wont help us either, because this wont be an SMPS that twl-regulator can even try to control.

So, how would omap_pmic find vcore1 twl driver data when it does not even twl6030 does not even probe vcore1? and making twl-regulator.c probe vcore1 (aka making it probe for a device that it cannot manage) is conceptually wrong, no (not to mention wrong definition of two device nodes in dt blob for the same device)?

I might say yes, but that will only be because I just know OMAP architecture alone, Have'nt had enough indepth knowledge of other architectures to make a broader statement :(

custom of->match data parameter is how it is done today in this patch

custom callback context was as follows: if we force the SoC generic regulators to use OMAP custom interfaces, then we have a need for custom callbacks, else w.r.t PMIC data, covered above, we do not need any custom callbacks, agreed.

Having looked at a few regulator driver implementations, there seems to be the following combinations:
a) drivers which have n ranges of linear voltages for incremental selector
b) drivers with 1 range of linear voltages only for all ranges of selectors
c) drivers with 1 range of linear voltages and nonlinear voltage values for other vsels.

between PMICs? yep, twl4030 does 4mV/uSec, 6030 can do 6mV/uSec, TPS62361 can do 32mV/uSec, TWL6035/37 does 0.220mV/uSec

For a given PMIC, voltage X to Y time will vary ofcourse. SmartReflex AVS is something cpufreq wont know about -> completely different topic of its own :)

What we are representing is data for PMIC supported on specific SoC hardware controller interface meant just for PMIC - IMHO, it is similar to data that twl-regulator stores for the SMPS/LDOs that it can control
- given these are starting to become legacy platforms (OMAP3,4,5) and the fact that it is a one-off(at this point in time) knwon custom hardware doing stuff like this, we would'nt expect too much churn either there(new PMICs added etc). On the flip side, I do understand your concern with scalability and ease of re-use here. but given that we have'nt seen much of a churn in this data for years on the go now, I'd expect lesser in the future. This dedicated interface has been dropped in our future chips precisely due to the lack of scalability to PMIC choices such as those using SPI.

just my 2 cents.

Regards,
Nishanth Menon

This seems like something we should be able to cope with by for example adding a bus for the custom PMIC interface or otherwise finding a way to get to the data at runtime based on the compatible string. This would need some custom code in the regulators but would have the advantage of keeping the data the same at least. Hrm.

Everything else is just a special case of option a - either there's just a single range or there's a bunch of ranges each with a single value. I suspect that ranges will be the most useful thing for any hardware which can practically be used by these regulators anyway.

Those are ramp rates, they're not I2C I/O limits. Ramp rates we already
know about. I think what you're saying here is that this latency value
is actually about worst case ramp times?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130709/3dbf5b82/attachment.sig>

I had considered introducing a custom bus for custom PMIC interface, but as you stated below, standard regulators will probably need some custom monkeying around.

Ofcourse,this will be to add custom set/get_voltage implementation using this "custom API" which we discussed was'nt that good an idea.

I am at a stalemate as to where we should go from here.

True, but slightly different topic though.

Arrgh.. my bad. I confused ramp time with I2C transfer timeout parameter. I know that I2C bus can be held[1] by PMIC as long as it is busy. Some custom ASIC can do some weird stuff I suppose. I dont seem to have clear data points in the sketchy TRMs for 6030/2 , 6035, 5030, for these other than to state it is i2c specification compliant (/me grumbles). So, I just have emperical value which is a bit conservative and seem to work on the devices.

[1] http://www.i2c-bus.org/clock-generation-stretching-arbitration/

Regards,
Nishanth Menon

We should just be able to use the platform bus here.

No, if the regulator isn't being interacted with directly then it doesn't need to export any operations - just data. The operations would come from the magic SoC hardware that controls the regulator. The code in the drivers should be very small, if it isn't there's no point in doing this.

OK, no problem - like we said further up the thread I think adding
something to get the data
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130710/c6ebfb65/attachment-0001.sig>

Texas Instrument's OMAP SoC generations since OMAP3-5 introduced an TI custom hardware block to better facilitate and standardize integration of Power Management ICs which communicate over I2C called Voltage Controller(VC).

This is an specialized hardware block meant to support PMIC chips and is customized to that requirement. Even though it functions as an I2C controller, it is a write-only interface whose configurations are custom to PMICs.

We have an existing implementation in mach-omap2 which has been re factored and moved out as a separate driver. This new driver is DT only and the separation was meant to get a maintainable driver which does not have to deal with legacy platform_data dependencies. The legacy driver is retained to support non-DT boot and functionality will be migrated to the DT-only version as we enable features.

Currently, this implementation considers only the basic steps needed for voltage scaling and exposing voltage controller as a device whose child devices are voltage controller channel devices.

We may need to do additional timing configurations to enable Low power mode voltage transitions, but this will be completed in a following series. We may need a few tweaks to hook the Adaptive Voltage Scaling(AVS) implementation for OMAP which also uses the same voltage controller to talk to PMICs.

This driver is meant to interface with voltage processor when the voltage processor attempts devm_omap_vc_channel_get for the VC channel corresponding to the voltage processor.

---
 .../devicetree/bindings/power/omap-vc.txt          |   99 ++
 drivers/power/avs/Kconfig                          |   15 +
 drivers/power/avs/Makefile                         |   20 +
 drivers/power/avs/omap_vc.c                        | 1513 ++++++++++++++++++++
 drivers/power/avs/omap_vc.h                        |   67 +
 5 files changed, 1714 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/power/omap-vc.txt
 create mode 100644 drivers/power/avs/omap_vc.c
 create mode 100644 drivers/power/avs/omap_vc.h

new file mode 100644
index 0000000..f97737c
@@ -0,0 +1,99 @@
+Voltage Controller driver for Texas Instruments OMAP SoCs
+
+Voltage Controller Properties:
+The following are the properties of the voltage controller node
+Required Properties:
+- compatible: Should be one of:
+  - "ti,omap3-vc" - for OMAP3 family of devices
+  - "ti,omap4-vc" - for OMAP4 family of devices
+  - "ti,omap5-vc" - for OMAP5 family of devices
+- reg: Address and length of the register set for the device. It contains
+  the information of registers in the same order as described by reg-names
+- reg-names: Should contain the reg names
+  - "base-address"	- contains base address of VC module
+- clocks: should point to the clock node used by VC module, usually sysclk
+- ti,i2c-clk-scl-low: is mandatory if ti,i2c-pad-load is not used. contains
+  hex to represent timing for slow I2C phase low clock time.
+- ti,i2c-clk-scl-high: is mandatory if ti,i2c-pad-load is not used. contains
+  hex to represent timing for slow I2C phase high clock time.
+- ti,i2c-clk-hsscl-low: is mandatory if ti,i2c-pad-load is not used and
+  ti,i2c-high-speed is used, contains hex to represent timing for high speed I2C
+  phase low clock time.
+- ti,i2c-clk-hsscl-high: is mandatory if ti,i2c-pad-load is not used and
+  ti,i2c-high-speed is used, contains hex to represent timing for high speed I2C
+  phase high clock time.
+- Must contain VC channel nodes which belong to the Voltage controller.
+
+Optional Properties:
+- ti,i2c-high-speed: bool to indicate if VC should operate in high speed I2C
+  mode.
+- ti,i2c-pad-load: if ti,i2c-high-speed, then this is optional to auto load
+  pre-calculated I2C clock timing configuration. This is denoted in pico-farads.
+- ti,i2c-pcb-length: if ti,i2c-pad-load, then this is optional to select the
+  pre-calculated I2C clock timing configuration. default of '63' is used.
+  This is denoted in millimeters.
+- pinctrl: Most OMAP SoCs do not allow pinctrl option to select VC's I2C path.
+  it is usually hardcoded by default. Define "default" pinctrl-0 as needed.
+
+Voltage Controller Channel Properties:
+The following are the properties of the voltage controller channel nodes
+Required Properties:
+- compatible: Should be one of:
+  - ti,omap3-vc-channel-0 - Channel 0 on OMAP3 family of devices
+  - ti,omap3-vc-channel-1 - Channel 1 on OMAP3 family of devices
+  - ti,omap4-vc-channel-mpu - Channel MPU on OMAP4 family of devices
+  - ti,omap4-vc-channel-iva - Channel IVA on OMAP4 family of devices
+  - ti,omap4-vc-channel-core - Channel CORE on OMAP4 family of devices
+  - ti,omap5-vc-channel-mpu - Channel MPU on OMAP5 family of devices
+  - ti,omap5-vc-channel-mm - Channel MM on OMAP5 family of devices
+  - ti,omap5-vc-channel-core - Channel CORE on OMAP5 family of devices
+- ti,master-channel: bool to mark the "master channel". Only ONE channel is
+  to be marked as master channel depending on SoC specification.
+
+Optional Properties:
+- ti,retention-micro-volts: retention voltage for the voltage controller in
+  micro-volts
+- ti,off-micro-volts: OFF mode voltage for the voltage controller in micro-volts
+- ti,use-master-slave-addr: available only for a "non-master" channel. This
+  indicates the the channel will use master channel's slave address. Usually
+  used when the PMIC has the same slave address for all SMPSs.
+- ti,use-master-voltage-reg-addr: available only for a "non-master" channel.
+  channel will use voltage register of the master channel to send voltage
+  commands - usually used in "ganged" voltage rail configuration - NOTE: this
+  is useful only when doing voltage transitions alone and not using AVS.
+- ti,use-master-command-reg-addr: available only for a "non-master" channel.
+  channel will use command register of the master channel to send command
+  values - usually used in "ganged" voltage rail configuration - NOTE: this
+  is useful only when doing voltage transitions alone and not using AVS.
+- ti,use-master-command-reg-val: available only for a "non-master" channel.
+  channel will use command value of the master channel to send commands
+  - usually used in "ganged" voltage rail configuration - NOTE: this
+  is useful only when doing voltage transitions alone and not using AVS.
+
+Example:
+SoC file: (example from OMAP4)
+vc: vc at 0x4A307B88 {
+		compatible = "ti,omap4-vc";
+		clocks = <&sysclk_in>;
+		reg = <0x4A307B88 0x40>;
+		reg-names = "base-address";
+
+		vc_mpu: vc_mpu {
+			compatible = "ti,omap4-vc-channel-mpu";
+			ti,master-channel;
+			ti,retention-micro-volts = <750000>;
+			ti,off-micro-volts = <0>;
+		};
+
+		vc_iva: vc_iva {
+			compatible = "ti,omap4-vc-channel-iva";
+			ti,retention-micro-volts = <750000>;
+			ti,off-micro-volts = <0>;
+		};
+
+		vc_core: vc_core {
+			compatible = "ti,omap4-vc-channel-core";
+			ti,retention-micro-volts = <750000>;
+			ti,off-micro-volts = <0>;
+		};
+	};

index 2a1008b..68dff06 100644
@@ -10,3 +10,18 @@ menuconfig POWER_AVS
 	  AVS is also called SmartReflex on OMAP devices.
 
 	  Say Y here to enable Adaptive Voltage Scaling class support.
+
+config POWER_TI_HARDWARE_VOLTAGE_CONTROL
+	tristate "TI OMAP SoC Voltage Control support"
+	depends on OF && ARCH_OMAP && REGULATOR_TI_OMAP_PMIC
+	select REGMAP_MMIO
+	help
+	  Select this option to support Texas Instruments' custom Voltage
+	  Processor + Voltage Controller data interface used in OMAP SoCs
+	  to enable Adaptive Voltage Scaling(AVS) and Device Frequency and
+	  Voltage Scaling(DVFS). This is a specific "write-only" interface
+	  designed to interface with I2C based PMICs. These two subsystems
+	  in OMAP do not exist independent of each other as they are
+	  practically useless without each other.
+
+	  Say Y here to enable TI OMAP SoC Voltage Control support.

index 0843386..95d5f59 100644
@@ -1 +1,21 @@
 obj-$(CONFIG_POWER_AVS_OMAP)		+= smartreflex.o
+
+ifneq ($(CONFIG_POWER_TI_HARDWARE_VOLTAGE_CONTROL),)
+
+# OMAP Common
+omap-volt-common			=  omap_vc.o
+
+# OMAP SoC specific
+ifneq ($(CONFIG_ARCH_OMAP3),)
+obj-$(CONFIG_POWER_TI_HARDWARE_VOLTAGE_CONTROL) += $(omap-volt-common)
+endif
+
+ifneq ($(CONFIG_ARCH_OMAP4),)
+obj-$(CONFIG_POWER_TI_HARDWARE_VOLTAGE_CONTROL) += $(omap-volt-common)
+endif
+
+ifneq ($(CONFIG_SOC_OMAP5),)
+obj-$(CONFIG_POWER_TI_HARDWARE_VOLTAGE_CONTROL) += $(omap-volt-common)
+endif
+
+endif

1.7.9.5

Texas Instrument's OMAP SoC generations since OMAP3-5 introduced an TI custom hardware block to better facilitate and standardize integration of Power Management ICs which communicate over I2C called Voltage Processor(VP).

This is an specialized hardware block meant to support PMIC chips only over Voltage Controller(VC) interface. This provides an interface for SmartReflex AVS module to send adjustment steps which is converted into voltage values and send onwards by VP to VC. VP is also used to set the voltage of the PMIC by commanding using "forceupdate".

We have an existing implementation in mach-omap2 which has been re factored and moved out as a separate driver. This new driver is DT only and the separation was meant to get a maintainable driver which does not have to deal with legacy platform_data dependencies. The legacy driver is retained to support non-DT boot and functionality will be migrated to the DT-only version as we enable features.

Currently, this implementation considers only the basic steps needed for voltage scaling and exposing voltage processor which hooks on to Voltage Controller driver and OMAP PMIC driver to provide an regulator interface over OMAP PMIC driver.

We may need to do additional timing configurations to enable Low power mode voltage transitions and to hook the Adaptive Voltage Scaling(AVS) implementation for OMAP which also uses the same voltage controller to talk to PMICs. This needs to be addressed in a later series.

This driver is meant to interface with OMAP PMIC driver when the controller driver registers it's operations with OMAP PMIC driver and associates with an voltage controller channel. This enables the full communication path between the OMAP PMIC regulator to the external PMIC hardware over OMAP Voltage Processor and OMAP Voltage Controller.

---
 .../devicetree/bindings/power/omap-vp.txt          |   39 +
 drivers/power/avs/Makefile                         |    2 +-
 drivers/power/avs/omap_vp.c                        |  892 ++++++++++++++++++++
 3 files changed, 932 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/power/omap-vp.txt
 create mode 100644 drivers/power/avs/omap_vp.c

new file mode 100644
index 0000000..b690e35
@@ -0,0 +1,39 @@
+Voltage Controller driver for Texas Instruments OMAP SoCs
+
+Voltage Controller Properties:
+The following are the properties of the voltage controller node
+Required Properties:
+- compatible: Should be one of:
+  - "ti,omap3-vp" - for OMAP3 family of devices
+  - "ti,omap4-vp" - for OMAP4 family of devices
+  - "ti,omap5-vp" - for OMAP5 family of devices
+- reg: Address and length of the register set for the device. It contains
+  the information of registers in the same order as described by reg-names
+- reg-names: Should contain the reg names
+  - "base-address"	- contains base address of VP module
+  - "int-address"	- contains base address of interrupt register for VP module
+- clocks: should point to the clock node used by VC module, usually sysclk
+- ti,min-micro-volts - SoC supported min operational voltage in micro-volts
+- ti,max-micro-volts - SoC supported max operational voltage in micro-volts
+- ti,min-step-micro-volts - SoC supported min operational voltage steps in micro-volts
+- ti,max-step-micro-volts - SoC supported max operational voltage steps in micro-volts
+- ti,tranxdone-status-mask: Mask to the int-register to write-to-clear mask
+	indicating VP has completed operation in sending command to Voltage Controller.
+- ti,vc-channel - phandle to the Voltage Controller Channel device used by this Voltage
+	Processor.
+Example:
+vp_mpu: vp at 0x4a307b58 {
+	compatible = "ti,omap4-vp";
+
+	reg = <0x4a307b58 0x18>, <0x4A306014 0x4>;
+	reg-names = "base-address", "int-address";
+	ti,tranxdone-status-mask=<0x20>;
+
+	clocks = <&sysclk_in>;
+
+	ti,vc-channel = <&vc_mpu>;
+	ti,min-step-micro-volts = <10000>;
+	ti,max-step-micro-volts = <50000>;
+	ti,min-micro-volts = <750000>;
+	ti,max-micro-volts = <1410000>;
+};

index 95d5f59..535cab5 100644
@@ -3,7 +3,7 @@ obj-$(CONFIG_POWER_AVS_OMAP)		+= smartreflex.o
 ifneq ($(CONFIG_POWER_TI_HARDWARE_VOLTAGE_CONTROL),)
 
 # OMAP Common
-omap-volt-common			=  omap_vc.o
+omap-volt-common			=  omap_vc.o omap_vp.o
 
 # OMAP SoC specific
 ifneq ($(CONFIG_ARCH_OMAP3),)

1.7.9.5

OMAP443x, OMAP446x SoC use same offsets for voltage controller, however their voltage characteristics differ a little.

Introduce the voltage controller nodes for the same.

---
 arch/arm/boot/dts/omap4.dtsi    |   26 ++++++++++++++++++++++++++
 arch/arm/boot/dts/omap443x.dtsi |   15 +++++++++++++++
 arch/arm/boot/dts/omap4460.dtsi |   16 ++++++++++++++++
 3 files changed, 57 insertions(+)

index 3b44546..a153e8d 100644
@@ -104,6 +104,11 @@
 			ti,hwmods = "counter_32k";
 		};
 
+		sysclk_in: sys_clkin {
+			#clock-cells = <0>;
+			compatible = "ti,omap-clock";
+		};
+
 		dpll_mpu: dpll_mpu {
 			#clock-cells = <0>;
 			compatible = "ti,omap-clock";

@@ -663,5 +668,26 @@
 			ram-bits = <12>;
 			ti,has-mailbox;
 		};
+
+		vc: vc at 0x4A307B88 {
+			compatible = "ti,omap4-vc";
+			clocks = <&sysclk_in>;
+			reg = <0x4A307B88 0x40>;
+			reg-names = "base-address";
+
+			ti,i2c-high-speed; /* belongs to board file */
+			vc_mpu: vc_mpu {
+				compatible = "ti,omap4-vc-channel-mpu";
+				ti,master-channel;
+			};
+
+			vc_iva: vc_iva {
+				compatible = "ti,omap4-vc-channel-iva";
+			};
+
+			vc_core: vc_core {
+				compatible = "ti,omap4-vc-channel-core";
+			};
+		};
 	};
 };

index bcf455e..2b0deb5 100644
@@ -31,3 +31,18 @@
 		compatible = "ti,omap4430-bandgap";
 	};
 };
+
+&vc_mpu {
+	ti,retention-micro-volts = <750000>;
+	ti,off-micro-volts = <0>;
+};
+
+&vc_iva {
+	ti,retention-micro-volts = <750000>;
+	ti,off-micro-volts = <0>;
+};
+
+&vc_core {
+	ti,retention-micro-volts = <750000>;
+	ti,off-micro-volts = <0>;
+};

index c2f0f39..16210a1 100644
@@ -39,3 +39,19 @@
 		gpios = <&gpio3 22 0>; /* tshut */
 	};
 };
+
+&vc_mpu {
+	ti,retention-micro-volts = <750000>;
+	/* Erratum i738: Reliability impact work around */
+	ti,off-micro-volts = <750000>;
+};
+
+&vc_iva {
+	ti,retention-micro-volts = <750000>;
+	ti,off-micro-volts = <0>;
+};
+
+&vc_core {
+	ti,retention-micro-volts = <750000>;
+	ti,off-micro-volts = <0>;
+};

1.7.9.5

OMAP443x, OMAP446x SoC use same offsets for voltage processor, however their voltage characteristics differ a little.

Introduce the voltage processor nodes for the same.

---
 arch/arm/boot/dts/omap4.dtsi    |   43 +++++++++++++++++++++++++++++++++++++++
 arch/arm/boot/dts/omap443x.dtsi |   15 ++++++++++++++
 arch/arm/boot/dts/omap4460.dtsi |   15 ++++++++++++++
 3 files changed, 73 insertions(+)

index a153e8d..3c75b23 100644
@@ -689,5 +689,48 @@
 				compatible = "ti,omap4-vc-channel-core";
 			};
 		};
+
+		vp_mpu: vp at 0x4A307B58 {
+			compatible = "ti,omap4-vp";
+
+			reg = <0x4A307b58 0x18>, <0x4A306014 0x4>;
+			reg-names = "base-address", "int-address";
+			ti,tranxdone-status-mask=<0x20>;
+
+			clocks = <&sysclk_in>;
+
+			ti,vc-channel = <&vc_mpu>;
+			ti,min-step-micro-volts = <10000>;
+			ti,max-step-micro-volts = <50000>;
+		};
+
+		vp_iva: vp at 0x4A307B70 {
+			compatible = "ti,omap4-vp";
+
+			reg = <0x4A307B70 0x18>, <0x4A306010 0x4>;
+			reg-names = "base-address", "int-address";
+			ti,tranxdone-status-mask=<0x20000000>;
+
+			clocks = <&sysclk_in>;
+
+			ti,vc-channel = <&vc_iva>;
+			ti,min-step-micro-volts = <10000>;
+			ti,max-step-micro-volts = <50000>;
+		};
+
+		vp_core: vp at 0x4A307B40 {
+			compatible = "ti,omap4-vp";
+
+			reg = <0x4A307b40 0x18>, <0x4A306010 0x4>;
+			reg-names = "base-address", "int-address";
+			ti,tranxdone-status-mask=<0x200000>;
+
+			clocks = <&sysclk_in>;
+
+			regulator_name = "vdd_core";
+			ti,vc-channel = <&vc_core>;
+			ti,min-step-micro-volts = <10000>;
+			ti,max-step-micro-volts = <50000>;
+		};
 	};
 };

index 2b0deb5..e759937 100644
@@ -46,3 +46,18 @@
 	ti,retention-micro-volts = <750000>;
 	ti,off-micro-volts = <0>;
 };
+
+&vp_mpu {
+	ti,min-micro-volts = <750000>;
+	ti,max-micro-volts = <1388000>;
+};
+
+&vp_iva {
+	ti,min-micro-volts = <750000>;
+	ti,max-micro-volts = <1291000>;
+};
+
+&vp_core {
+	ti,min-micro-volts = <750000>;
+	ti,max-micro-volts = <1127000>;
+};

index 16210a1..8320865 100644
@@ -55,3 +55,18 @@
 	ti,retention-micro-volts = <750000>;
 	ti,off-micro-volts = <0>;
 };
+
+&vp_mpu {
+	ti,min-micro-volts = <750000>;
+	ti,max-micro-volts = <1380000>;
+};
+
+&vp_iva {
+	ti,min-micro-volts = <750000>;
+	ti,max-micro-volts = <1375000>;
+};
+
+&vp_core {
+	ti,min-micro-volts = <750000>;
+	ti,max-micro-volts = <1250000>;
+};

1.7.9.5

OMAP4430 and 4460 platforms use TWL6030 to power voltage rails. However, on 4460, we use twl6030 only for iva and core voltage rails.

Introduce an twl6030_omap4.dtsi to be able to reuse the base definition for all OMAP4 platforms and the delta change only for panda-es platform which is based on 4460.

---
 arch/arm/boot/dts/omap4-panda-common.dtsi |    1 +
 arch/arm/boot/dts/omap4-panda-es.dts      |   13 +++++++++++
 arch/arm/boot/dts/omap4-sdp.dts           |    1 +
 arch/arm/boot/dts/omap4-var-som.dts       |    1 +
 arch/arm/boot/dts/twl6030_omap4.dtsi      |   35 +++++++++++++++++++++++++++++
 5 files changed, 51 insertions(+)
 create mode 100644 arch/arm/boot/dts/twl6030_omap4.dtsi

index 00cbaa5..2b15c2b 100644
@@ -199,6 +199,7 @@
 };
 
 #include "twl6030.dtsi"
+#include "twl6030_omap4.dtsi"
 
 &i2c2 {
 	pinctrl-names = "default";

index 56c4354..49017c5 100644
@@ -62,3 +62,16 @@
 		gpios = <&gpio1 8 GPIO_ACTIVE_HIGH>;
 	};
 };
+
+&omap_twl6030_vcore1 {
+	ti,vp = <&vp_core>;
+};
+
+&omap_twl6030_vcore2 {
+	ti,vp = <&vp_iva>;
+};
+
+&omap_twl6030_vcore3 {
+	/* We use TPS62361 on this platform instead */
+	status = "disabled";
+};

index 7951b4e..2f81b4d5 100644
@@ -337,6 +337,7 @@
 };
 
 #include "twl6030.dtsi"
+#include "twl6030_omap4.dtsi"
 
 &i2c2 {
 	pinctrl-names = "default";

index b41269e..6f0b763 100644
@@ -40,6 +40,7 @@
 };
 
 #include "twl6030.dtsi"
+#include "twl6030_omap4.dtsi"
 
 &i2c2 {
 	clock-frequency = <400000>;

new file mode 100644
index 0000000..7724039
@@ -0,0 +1,35 @@
+/*
+ * TWL6030 entries specific for OMAP
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *	Nishanth Menon
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+&twl {
+	omap_twl6030_vcore1: vcore1 {
+		compatible = "ti,omap-twl6030-vcore1";
+		ti,boot-voltage-micro-volts = <1200000>;
+		ti,vp = <&vp_mpu>;
+	};
+
+	omap_twl6030_vcore2: vcore2 {
+		compatible = "ti,omap-twl6030-vcore2";
+		ti,boot-voltage-micro-volts = <1200000>;
+		ti,vp = <&vp_iva>;
+	};
+
+	omap_twl6030_vcore3: vcore3 {
+		compatible = "ti,omap-twl6030-vcore3";
+		ti,boot-voltage-micro-volts = <1200000>;
+		ti,vp = <&vp_core>;
+	};
+};
+
+&vc {
+	ti,i2c-high-speed;
+	ti,i2c-pad-load = <3>;
+};

1.7.9.5

Unlike other OMAP4 platforms including the the "vanilla" PandaBoard, PandaBoard-ES uses TPS62361 to supply vdd_mpu.

---
 arch/arm/boot/dts/omap4-panda-es.dts |   18 ++++++++++++++++++
 arch/arm/boot/dts/tps62361_omap.dtsi |   18 ++++++++++++++++++
 2 files changed, 36 insertions(+)
 create mode 100644 arch/arm/boot/dts/tps62361_omap.dtsi

index 49017c5..325816c 100644
@@ -75,3 +75,21 @@
 	/* We use TPS62361 on this platform instead */
 	status = "disabled";
 };
+
+#include "tps62361_omap.dtsi"
+
+&omap4_pmx_wkup {
+	tps62361_wkgpio_pins: pinmux_tps62361_wkpins {
+		pinctrl-single,pins = <
+			0x1a (PIN_OUTPUT | MUX_MODE3 | OFF_EN | OFFOUT_VAL) /* gpio_wk7 */
+		>;
+	};
+};
+
+&omap_tps62361 {
+	pinctrl-names = "default";
+	pinctrl-0 = <
+		&tps62361_wkgpio_pins
+	>;
+	gpios = <&gpio1 7 GPIO_ACTIVE_HIGH>;
+};

new file mode 100644
index 0000000..ee261ec
@@ -0,0 +1,18 @@
+/*
+ * TPS62361 entries specific for OMAP
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *	Nishanth Menon
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/ {
+	omap_tps62361: tps62361 {
+		compatible = "ti,omap-tps62361";
+		ti,boot-voltage-micro-volts = <1203000>;
+		ti,vp = <&vp_mpu>;
+	};
+};

1.7.9.5

TPS62361 is used for cpufreq regulation. As part of this change use labels that can be used to reference cpu0 to setup it's supply.

---
 arch/arm/boot/dts/omap4-panda-es.dts |    4 ++++
 arch/arm/boot/dts/omap4.dtsi         |    4 ++--
 arch/arm/boot/dts/omap443x.dtsi      |    2 +-
 arch/arm/boot/dts/omap4460.dtsi      |    2 +-
 4 files changed, 8 insertions(+), 4 deletions(-)

index 325816c..d2ce518 100644
@@ -93,3 +93,7 @@
 	>;
 	gpios = <&gpio1 7 GPIO_ACTIVE_HIGH>;
 };
+
+&cpu0 {
+	cpu0-supply = <&omap_tps62361>;
+};

index 3c75b23..127b974 100644
@@ -24,13 +24,13 @@
 	};
 
 	cpus {
-		cpu at 0 {
+		cpu0: cpu at 0 {
 			compatible = "arm,cortex-a9";
 			next-level-cache = <&L2>;
 			clocks = <&dpll_mpu>;
 			clock-names = "cpu";
 		};
-		cpu at 1 {
+		cpu1: cpu at 1 {
 			compatible = "arm,cortex-a9";
 			next-level-cache = <&L2>;
 		};

index e759937..91a5f70 100644
@@ -12,7 +12,7 @@
 
 / {
 	cpus {
-		cpu at 0 {
+		cpu0: cpu at 0 {
 			/* OMAP443x variants OPP50-OPPNT */
 			operating-points = <
 				/* kHz    uV */

index 8320865..9827e35 100644
@@ -12,7 +12,7 @@
 / {
 	cpus {
 		/* OMAP446x 'standard device' variants OPP50 to OPPTurbo */
-		cpu at 0 {
+		cpu0: cpu@0 {
 			operating-points = <
 				/* kHz    uV */
 				350000  1025000

1.7.9.5