Re: [PATCH] arm: dts: twl6030: typical connection to omap4 as a separate dtsi file
) /* sys_nirq1.sys_nirq1 */ + ; + }; +}; -- Regards, Nishanth Menon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/4] dra7: I2C/MCSPI/UART pin control datas
On 07/19/2013 11:24 AM, Sourav Poddar wrote: These series add support for I2C/MCSPI/UART pin control datas. The series is done on top of Rajendra Nayak series[1](posted to the list), which has basic dt boot enable for dra7. These patches has been tested, along with I2C and UART patches from wolfram sang patch series[2]. [1]: http://www.spinics.net/lists/linux-omap/msg93535.html [2]: https://lkml.org/lkml/2013/7/10/335 Sourav Poddar (4): arm: dts: omap5-evm: Add I2c pinctrl data arm: dts: omap5-evm: Add I2c pinctrl data arm: dts: dra7-evm: Add SPI pinctrl data arm: dts: dra7-evm: Add UART pinctrl data arch/arm/boot/dts/dra7-evm.dts | 123 arch/arm/boot/dts/dra7.dtsi| 15 + 2 files changed, 138 insertions(+), 0 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html DRA7 DTS is not merged yet, If I am not mistaken. Ref[1] [2] So why not squash these to [2]? [1] http://marc.info/?t=13733551791r=1w=2 [2] http://marc.info/?l=linux-arm-kernelm=137335590702349w=2 -- Regards, Nishanth Menon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/3] misc: Add crossbar driver
On 07/18/2013 11:43 AM, Sricharan R wrote:
Some socs have a large number of interrupts/dma requests to service
the needs of its many peripherals and subsystems. All of the
requests lines from the subsystems are not needed at the same
time, so they have to be muxed to the controllers appropriately.
In such places a interrupt/dma controllers are preceded by an
IRQ/DMA CROSSBAR that provides flexibility in muxing the device
requests to the controller inputs.
The Peripheral irq/dma requests are connected to one crossbar's input
and the output of the crossbar is connected to controller's input
line. On POR, there are some mappings which are done by default.
Those peripherals which do not have a mapping on POR, should be configured
to route its requests using the crossbar.
The drivers identifies every controller's crossbar as individual devices.
The mappings can be specified from the DT crossbar nodes and those gets mapped
during the crossbar device's probe. The mappings can also be specified by adding
the crossbar lines to the peripheral device nodes and map it with
crossbar_map/unmap apis.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
.../devicetree/bindings/arm/omap/crossbar.txt | 24 ++
drivers/misc/Kconfig |8 +
drivers/misc/Makefile |1 +
drivers/misc/crossbar.c| 258
include/linux/crossbar.h | 71 ++
5 files changed, 362 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/omap/crossbar.txt
create mode 100644 drivers/misc/crossbar.c
create mode 100644 include/linux/crossbar.h
diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt
b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
new file mode 100644
index 000..02a8a28
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
@@ -0,0 +1,24 @@
+* TI - IRQ/DMA Crossbar
+
+This version is an implementation of the Crossbar IRQ/DMA IP
+
+Required properties:
+- compatible : Should be ti,dra-crossbar
+- crossbar-name: Name of the controller to which crossbar output is routed
+- reg: Contains crossbar register address range
+- reg-width: Represents the width of the individual registers
+- crossbar-lines: Default mappings.Should contain the crossbar-name
+ device name, int/dma request number, crossbar number,
+ register offset in the same order.
+
+Examples:
+ crossbar_mpu: mpuirq@4a002a48 {
+ compatible = crossbar;
+ crossbar-name = mpu-irq;
+ reg = 0x4a002a48 0x0130;
+ reg-width = 16;
+ crossbar-lines = mpu-irq, rtc-ss-alarm, 0x9f 0xd9
0x12c,
+mpu-irq, mcasp3-arevt, 0x9e 0x96
0x12a,
+mpu-irq, mcasp3-axevt, 0x9d 0x97
0x128;
+ };
I carry forward my TI internal objection to this approach:
NAK.
DRA7 uses a cross bar to map a line to GIC interrupt. Flow of interrupt
is as follows:
hardware IP block -interrupt line- IRQ Cross bar - GIC IRQ line --
MPU IRQ.
What we have done today for DRA is to provide IRQ numbers as direct maps
from hardware IP block to GIC based on default IRQ cross bar mapping.
Lets see what happens as a result of this:
https://patchwork.kernel.org/patch/2825148/ (introducing DTS for DRA7)
uart1 to uart6 is defined. while in fact 10 uarts exist on IP block.
uart1: serial@4806a000 {
snip
+ interrupts = 0 72 0x4;
Assumes that GIC interrupt by default mapping used.
Now, think of a product that wants to use UART10 instead of UART1, SoC
design allows you do that by doing a remapping of GIC interrupt to
UART10 - which is awesome.
Option 1: u-boot/bootloader
mw.l IRQ_CROSSBAR_address with value to map uart10 to GIC IRQ for UART1,
Option 2: in kernel do a raw_writel version of option 1.
This patch does option 1 in kernel in a fancy way - why the heck would
I want to do that when u-boot allows me to do the same thing in uEnv.txt
Option 3: map GIC interrupt to IRQ CROSS bar dynamically.
a) Allows us to define every single IP available on DRA7 SoC.
b) GIC allocation happens dynamically
c) allow products use IPs as needed.
Sorry, Conceptually option 3 is the right approach in my view.
instead of doing
uart1: serial@4806a000 {
snip
+ interrupts = GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH;
we should be able to do the following:
uart1: serial@4806a000 {
snip
+ interrupts = TI_IRQ_CROSSBAR 192 IRQ_TYPE_LEVEL_HIGH;
and not worry about the GIC interrupt number used
--
Regards,
Nishanth Menon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/3] ARM: dts: DRA: Add crossbar device binding
On 07/18/2013 11:43 AM, Sricharan R wrote:
This adds the irq/dma crossbar device nodes.
There is a IRQ and DMA crossbar device in the soc, which
maps the irq/dma requests from the peripherals to the
mpu/dsp/ipu/eve interrupt and sdma/edma controller's inputs.
The Peripheral irq/dma requests are connected to only one crossbar
input and the output of the crossbar is connected to only one
controller's input line. On POR, there are some mappings which
are done by default. Those peripherals which do not have a
mapping on POR, should be configured to route its requests
using the crossbar control registers.
What is POR? Plan on Record? I supppose, we just love our TLA?
The irq/dma mapping for some peripherals are
added with the crossbar nodes here.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index a5d9350..e6208b4 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -85,6 +85,25 @@
ranges;
ti,hwmods = l3_main_1, l3_main_2;
+ crossbar_mpu: mpuirq@4a002a48 {
+ compatible = crossbar;
+ crossbar-name = mpu-irq;
+ reg = 0x4a002a48 0x0130;
+ reg-width = 16;
+ crossbar-lines = mpu-irq, rtc-ss-alarm, 0x9f 0xd9
0x12c,
+mpu-irq, mcasp3-arevt, 0x9e 0x96
0x12a,
+mpu-irq, mcasp3-axevt, 0x9d 0x97
0x128;
a) I'd like to use UART10. oh, let me guess: we dont map all cross bar
options here.. just certain ones
b) I like to use random 6 uarts out of the available 10 uarts on the fly.
c) I'd like to use IRQCROSS bar such that i use all the hardware block
instances that dont have default GIC IRQ mapping.
+ };
+
+ crossbar_dma: dmareq@4a002b78 {
+ compatible = crossbar;
+ crossbar-name = dma-req;
+ reg = 0x4a002b78 0x0100;
+ reg-width = 16;
+ crossbar-lines = dma-req, mcasp3-rx, 0x7e 0x84
0xfc,
+dma-req, mcasp3-tx, 0x7d 0x85
0xfa;
+ };
+
counter32k: counter@4ae04000 {
compatible = ti,omap-counter32k;
reg = 0x4ae04000 0x40;
--
Regards,
Nishanth Menon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/3] misc: Add crossbar driver
On Thu, Jul 18, 2013 at 6:39 PM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
On Thursday 18 July 2013 02:56 PM, Nishanth Menon wrote:
On 07/18/2013 11:43 AM, Sricharan R wrote:
Some socs have a large number of interrupts/dma requests to service
the needs of its many peripherals and subsystems. All of the
requests lines from the subsystems are not needed at the same
time, so they have to be muxed to the controllers appropriately.
In such places a interrupt/dma controllers are preceded by an
IRQ/DMA CROSSBAR that provides flexibility in muxing the device
requests to the controller inputs.
The Peripheral irq/dma requests are connected to one crossbar's input
and the output of the crossbar is connected to controller's input
line. On POR, there are some mappings which are done by default.
Those peripherals which do not have a mapping on POR, should be configured
to route its requests using the crossbar.
The drivers identifies every controller's crossbar as individual devices.
The mappings can be specified from the DT crossbar nodes and those gets
mapped
during the crossbar device's probe. The mappings can also be specified by
adding
the crossbar lines to the peripheral device nodes and map it with
crossbar_map/unmap apis.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
.../devicetree/bindings/arm/omap/crossbar.txt | 24 ++
drivers/misc/Kconfig |8 +
drivers/misc/Makefile |1 +
drivers/misc/crossbar.c| 258
include/linux/crossbar.h | 71 ++
5 files changed, 362 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/omap/crossbar.txt
create mode 100644 drivers/misc/crossbar.c
create mode 100644 include/linux/crossbar.h
diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt
b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
new file mode 100644
index 000..02a8a28
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
@@ -0,0 +1,24 @@
+* TI - IRQ/DMA Crossbar
+
+This version is an implementation of the Crossbar IRQ/DMA IP
+
+Required properties:
+- compatible : Should be ti,dra-crossbar
+- crossbar-name: Name of the controller to which crossbar output is routed
+- reg:Contains crossbar register address range
+- reg-width: Represents the width of the individual registers
+- crossbar-lines: Default mappings.Should contain the crossbar-name
+ device name, int/dma request number, crossbar number,
+ register offset in the same order.
+
+Examples:
+crossbar_mpu: mpuirq@4a002a48 {
+compatible = crossbar;
+crossbar-name = mpu-irq;
+reg = 0x4a002a48 0x0130;
+reg-width = 16;
+crossbar-lines = mpu-irq, rtc-ss-alarm, 0x9f 0xd9 0x12c,
+ mpu-irq, mcasp3-arevt, 0x9e 0x96 0x12a,
+ mpu-irq, mcasp3-axevt, 0x9d 0x97 0x128;
+};
I carry forward my TI internal objection to this approach:
NAK.
DRA7 uses a cross bar to map a line to GIC interrupt. Flow of interrupt is
as follows:
hardware IP block -interrupt line- IRQ Cross bar - GIC IRQ line -- MPU
IRQ.
What we have done today for DRA is to provide IRQ numbers as direct maps
from hardware IP block to GIC based on default IRQ cross bar mapping.
Lets see what happens as a result of this:
https://patchwork.kernel.org/patch/2825148/ (introducing DTS for DRA7)
uart1 to uart6 is defined. while in fact 10 uarts exist on IP block.
uart1: serial@4806a000 {
snip
+interrupts = 0 72 0x4;
Assumes that GIC interrupt by default mapping used.
Now, think of a product that wants to use UART10 instead of UART1, SoC
design allows you do that by doing a remapping of GIC interrupt to UART10 -
which is awesome.
Option 1: u-boot/bootloader
mw.l IRQ_CROSSBAR_address with value to map uart10 to GIC IRQ for UART1,
Option 2: in kernel do a raw_writel version of option 1.
This patch does option 1 in kernel in a fancy way - why the heck would I
want to do that when u-boot allows me to do the same thing in uEnv.txt
Option 3: map GIC interrupt to IRQ CROSS bar dynamically.
a) Allows us to define every single IP available on DRA7 SoC.
b) GIC allocation happens dynamically
c) allow products use IPs as needed.
Sorry, Conceptually option 3 is the right approach in my view.
instead of doing
uart1: serial@4806a000 {
snip
+interrupts = GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH;
we should be able to do the following:
uart1: serial@4806a000 {
snip
+interrupts = TI_IRQ_CROSSBAR 192 IRQ_TYPE_LEVEL_HIGH;
and not worry about the GIC interrupt number used
Since the cross-bar is not limited t0 IRQ lines and applicable for
DMA request lines as well, making it IRQ chip doesn't make sense. Its
not typical
[PATCH 8/9] ARM: dts: omap5-uevm: update LDO7 voltage to 2V and settings
commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.
However, The regulator information is based on an older temporary
pre-production board variant and does not reflect production board
750-2628-XXX boards.
LDO4 supplies VDD_VPP which is vpp1. This is currently configured for
1.5V which as per data manual A pulse width of 1000 ns and an amplitude
of 2V is required to program each eFuse bit. Otherwise, VPP1 must not
be supplied.
So, fix the voltage to 2V. and disable the supply since we have no plans
of programming efuse bits - it can only be done once - in factory.
Further it is not enabled by default by PMIC so, 'boot-on' must be
removed, and the 'always-on' needs to be removed to achieve pulsing
if efuse needs to be programmed.
Reported-by: Marc Jüttner m-juett...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 3ff5874..ef05676 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -397,10 +397,10 @@
ldo7_reg: ldo7 {
/* VDD_VPP: vpp1 */
regulator-name = ldo7;
- regulator-min-microvolt = 150;
- regulator-max-microvolt = 150;
- regulator-always-on;
- regulator-boot-on;
+ regulator-min-microvolt = 200;
+ regulator-max-microvolt = 200;
+ /* Only for efuse reprograming! */
+ status = disabled;
};
ldo8_reg: ldo8 {
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 5/9] ARM: dts: omap5-uevm: update LDO3 voltage to 1.5V and settings
commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.
However, The regulator information is based on an older temporary
pre-production board variant and does not reflect production board
750-2628-XXX boards.
LDO3 supplies Low Latency Interface(LLI) hardware module which is a
special hardware to communicate with Modem. However since uEVM is
not setup by default for this communication, this should be disabled
by default.
Further, vdda_lli is supposed to be 1.5V and not 3V.
Reported-by: Marc Jüttner m-juett...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index a55f4d8..c6d560b 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -362,10 +362,11 @@
ldo3_reg: ldo3 {
/* VDDAPHY_MDM: vdda_lli */
regulator-name = ldo3;
- regulator-min-microvolt = 300;
- regulator-max-microvolt = 300;
- regulator-always-on;
+ regulator-min-microvolt = 150;
+ regulator-max-microvolt = 150;
regulator-boot-on;
+ /* Only if Modem is used */
+ status = disabled;
};
ldo4_reg: ldo4 {
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 7/9] ARM: dts: omap5-uevm: update LDO6 voltage to 1.2V
commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.
However, The regulator information is based on an older temporary
pre-production board variant and does not reflect production board
750-2628-XXX boards.
LDO6 supplies the board specified VDDS_1V2_WKUP supply going to
ldo_emu_wkup/vdds_hsic. To stay within the SoC specification supply
1.2V instead of 1.5V.
Reported-by: Marc Jüttner m-juett...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 1550d6a..3ff5874 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -388,8 +388,8 @@
ldo6_reg: ldo6 {
/* VDDS_1V2_WKUP: hsic/ldo_emu_wkup */
regulator-name = ldo6;
- regulator-min-microvolt = 150;
- regulator-max-microvolt = 150;
+ regulator-min-microvolt = 120;
+ regulator-max-microvolt = 120;
regulator-always-on;
regulator-boot-on;
};
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 0/9] ARM: dts: omap5-uevm: fixup wrong regulator configuration
Due to wrong older revision of documentation used as reference, we seem to have a bunch of LDOs wrongly configured on OMAP5 uEVM. This series is based power tree on production board 750-2628-XXX platform. Unfortunately, the wrong voltages may be detrimental to OMAP5 as they supply hardware blocks at voltages that are out of specification. Also available at: based on v3.11-rc1 tag http link: https://github.com/nmenon/linux-2.6-playground/commits/push/omap5-palmas-fixes git link: git://github.com/nmenon/linux-2.6-playground.git branch: push/omap5-palmas-fixes Tested with https://patchwork.kernel.org/patch/2545061/ + https://git.kernel.org/cgit/linux/kernel/git/ssantosh/linux.git/log/?h=for_3.11/out_of_tree/omap5_clk_data Test result: http://pastebin.com/YqASYkXG Relevant documentation: - OMAP5 uEVM documentation: https://www.svtronics.com/omap/omap54xx?product_id=33 - OMAP5432 Data Manual: http://www.ti.com/product/OMAP5432 - TWL6037 / OTP information: Currently available only under NDA Nishanth Menon (9): ARM: dts: omap5-uevm: document regulator signals used on the actual board ARM: dts: omap5-uevm: update SMPS9 settings ARM: dts: omap5-uevm: update and disable unused regulators LDO[28] ARM: dts: omap5-uevm: update LDO1 voltage to 1.5V and settings ARM: dts: omap5-uevm: update LDO3 voltage to 1.5V and settings ARM: dts: omap5-uevm: update LDO4 voltage to 1.5V and settings ARM: dts: omap5-uevm: update LDO6 voltage to 1.2V ARM: dts: omap5-uevm: update LDO7 voltage to 2V and settings ARM: dts: omap5-uevm: update SDCARD LDO9 and resource REGEN3 arch/arm/boot/dts/omap5-uevm.dts | 78 -- 1 file changed, 49 insertions(+), 29 deletions(-) -- 1.7.9.5 Regards, Nishanth Menon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 6/9] ARM: dts: omap5-uevm: update LDO4 voltage to 1.5V and settings
commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.
However, The regulator information is based on an older temporary
pre-production board variant and does not reflect production board
750-2628-XXX boards.
LDO4 supplies VDDAPHY_DISP which is vdda_dsiporta/c/vdda_hdmi
This can only be supplied at 1.5V or 1.8V and we currently
supply 2.2V.
To prevent any potential device damage risk, use the specified
1.5V-1.8V supply.
Remove 'always-on' and 'boot-on' settings here as it is a 'on need'
supply to SoC IP and is not enabled by PMIC by default at boot.
Reported-by: Marc Jüttner m-juett...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index c6d560b..1550d6a 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -372,10 +372,8 @@
ldo4_reg: ldo4 {
/* VDDAPHY_DISP: vdda_dsiport/hdmi */
regulator-name = ldo4;
- regulator-min-microvolt = 220;
- regulator-max-microvolt = 220;
- regulator-always-on;
- regulator-boot-on;
+ regulator-min-microvolt = 150;
+ regulator-max-microvolt = 180;
};
ldo5_reg: ldo5 {
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/9] ARM: dts: omap5-uevm: document regulator signals used on the actual board
commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.
However, currently we use the Palmas regulator names which is used for
different purposes on uEVM. Document the same based on 750-2628-XXX
boards - which is meant to be supported by this dts.
Reported-by: Marc Jüttner m-juett...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 08b7267..b430b8f 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -282,6 +282,7 @@
regulators {
smps123_reg: smps123 {
+ /* VDD_OPP_MPU */
regulator-name = smps123;
regulator-min-microvolt = 60;
regulator-max-microvolt = 150;
@@ -290,6 +291,7 @@
};
smps45_reg: smps45 {
+ /* VDD_OPP_MM */
regulator-name = smps45;
regulator-min-microvolt = 60;
regulator-max-microvolt = 131;
@@ -298,6 +300,7 @@
};
smps6_reg: smps6 {
+ /* VDD_DDR3 - over VDD_SMPS6 */
regulator-name = smps6;
regulator-min-microvolt = 120;
regulator-max-microvolt = 120;
@@ -306,6 +309,7 @@
};
smps7_reg: smps7 {
+ /* VDDS_1v8_OMAP over VDDS_1v8_MAIN */
regulator-name = smps7;
regulator-min-microvolt = 180;
regulator-max-microvolt = 180;
@@ -314,6 +318,7 @@
};
smps8_reg: smps8 {
+ /* VDD_OPP_CORE */
regulator-name = smps8;
regulator-min-microvolt = 60;
regulator-max-microvolt = 131;
@@ -322,6 +327,7 @@
};
smps9_reg: smps9 {
+ /* VDDA_2v1_AUD over VDD_2v1 */
regulator-name = smps9;
regulator-min-microvolt = 210;
regulator-max-microvolt = 210;
@@ -331,6 +337,7 @@
};
smps10_reg: smps10 {
+ /* VBUS_5V_OTG */
regulator-name = smps10;
regulator-min-microvolt = 500;
regulator-max-microvolt = 500;
@@ -339,6 +346,7 @@
};
ldo1_reg: ldo1 {
+ /* VDDAPHY_CAM: vdda_csiport */
regulator-name = ldo1;
regulator-min-microvolt = 280;
regulator-max-microvolt = 280;
@@ -347,6 +355,7 @@
};
ldo2_reg: ldo2 {
+ /* VCC_2V8_DISP: Does not go anywhere */
regulator-name = ldo2;
regulator-min-microvolt = 290;
regulator-max-microvolt = 290;
@@ -355,6 +364,7 @@
};
ldo3_reg: ldo3 {
+ /* VDDAPHY_MDM: vdda_lli */
regulator-name = ldo3;
regulator-min-microvolt = 300;
regulator-max-microvolt = 300;
@@ -363,6 +373,7 @@
};
ldo4_reg: ldo4 {
+ /* VDDAPHY_DISP: vdda_dsiport/hdmi */
regulator-name = ldo4;
regulator-min-microvolt = 220;
regulator-max
[PATCH 2/9] ARM: dts: omap5-uevm: update SMPS9 settings
commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7 (ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes) introduced regulator entries for OMAP5uEVM. However, The regulator information is based on an older temporary pre-production board variant and does not reflect production board 750-2628-XXX boards. SMPS9 supplies TWL6040 over VDDA_2v1_AUD. This regulator needs to be enabled only when audio is active. Since it does not come active by default, it does not require always-on or boot-on. Reported-by: Marc Jüttner m-juett...@ti.com Signed-off-by: Nishanth Menon n...@ti.com --- arch/arm/boot/dts/omap5-uevm.dts |2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts index b430b8f..6709f1e 100644 --- a/arch/arm/boot/dts/omap5-uevm.dts +++ b/arch/arm/boot/dts/omap5-uevm.dts @@ -331,8 +331,6 @@ regulator-name = smps9; regulator-min-microvolt = 210; regulator-max-microvolt = 210; - regulator-always-on; - regulator-boot-on; ti,smps-range = 0x80; }; -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 9/9] ARM: dts: omap5-uevm: update SDCARD LDO9 and resource REGEN3
commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.
However, The regulator information is based on an older temporary
pre-production board variant and does not reflect production board
750-2628-XXX boards.
LDO9 supplies the board specified vdds_sdcard supply going within SoC
specification of 1.8V or 3.0V. Further the supply is controlled by
switch enabled by REGEN3. So, introduce REGEN3 and map sdcard slot to
be powered by LDO9. Remove 'always-on' allowing the LDO to be disabled
on need basis.
Reported-by: Marc Jüttner m-juett...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index ef05676..65d7b60 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -235,7 +235,7 @@
};
mmc1 {
- vmmc-supply = vmmcsd_fixed;
+ vmmc-supply = ldo9_reg;
bus-width = 4;
};
@@ -417,8 +417,7 @@
/* VCC_DV_SDIO: vdds_sdcard */
regulator-name = ldo9;
regulator-min-microvolt = 180;
- regulator-max-microvolt = 330;
- regulator-always-on;
+ regulator-max-microvolt = 300;
regulator-boot-on;
};
@@ -439,6 +438,13 @@
regulator-always-on;
regulator-boot-on;
};
+
+ regen3_reg: regen3 {
+ /* REGEN3 controls LDO9 supply to card
*/
+ regulator-name = regen3;
+ regulator-always-on;
+ regulator-boot-on;
+ };
};
};
};
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 3/9] ARM: dts: omap5-uevm: update and disable unused regulators LDO[28]
commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.
However, The regulator information is based on an older temporary
pre-production board variant and does not reflect production board
750-2628-XXX boards - On production boards, LDO2 and 8 are unused.
LDO2 and LDO8 do not go to any peripheral or connector on the board.
Further, these unused regulators should have been 2.8V for LDO2 and
3.0V for LDO8. Mark these LDOs as disabled in the dts until needed.
Reported-by: Marc Jüttner m-juett...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 6709f1e..87b3e9e 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -355,10 +355,10 @@
ldo2_reg: ldo2 {
/* VCC_2V8_DISP: Does not go anywhere */
regulator-name = ldo2;
- regulator-min-microvolt = 290;
- regulator-max-microvolt = 290;
- regulator-always-on;
- regulator-boot-on;
+ regulator-min-microvolt = 280;
+ regulator-max-microvolt = 280;
+ /* Unused */
+ status = disabled;
};
ldo3_reg: ldo3 {
@@ -409,10 +409,11 @@
ldo8_reg: ldo8 {
/* VDD_3v0: Does not go anywhere */
regulator-name = ldo8;
- regulator-min-microvolt = 150;
- regulator-max-microvolt = 150;
- regulator-always-on;
+ regulator-min-microvolt = 300;
+ regulator-max-microvolt = 300;
regulator-boot-on;
+ /* Unused */
+ status = disabled;
};
ldo9_reg: ldo9 {
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 4/9] ARM: dts: omap5-uevm: update LDO1 voltage to 1.5V and settings
commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.
However, The regulator information is based on an older temporary
pre-production board variant and does not reflect production board
750-2628-XXX boards.
LDO1 supplies VDDAPHY_CAM which is OMAP5's vdda_csiporta/b/c. This
can only be supplied at 1.5V or 1.8V and we currently supply 2.8V.
To prevent any potential device damage risk, use the specified
1.5V-1.8V supply.
Remove 'always-on' and 'boot-on' settings here as it is
a 'on need' supply to SoC IP and is not enabled by PMIC by
default at boot.
Reported-by: Marc Jüttner m-juett...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 87b3e9e..a55f4d8 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -346,10 +346,8 @@
ldo1_reg: ldo1 {
/* VDDAPHY_CAM: vdda_csiport */
regulator-name = ldo1;
- regulator-min-microvolt = 280;
- regulator-max-microvolt = 280;
- regulator-always-on;
- regulator-boot-on;
+ regulator-min-microvolt = 150;
+ regulator-max-microvolt = 180;
};
ldo2_reg: ldo2 {
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/2] regulator: palmas-pmic: doc: fix typo for sleep-mode
commit 3c870e3f9d9d98f1ab98614b3b1fd5c79287d361 (regulator: palmas: Change the DT node property names to follow the convention) Missed updating mode-sleep from sleep-mode. Fix the same. Documentation seems proper for this property. Signed-off-by: Nishanth Menon n...@ti.com --- .../devicetree/bindings/regulator/palmas-pmic.txt |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt index d5a3086..04d67f0 100644 --- a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt +++ b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt @@ -31,7 +31,7 @@ Optional nodes: Optional sub-node properties: ti,warm-reset - maintain voltage during warm reset(boolean) ti,roof-floor - control voltage selection by pin(boolean) - ti,sleep-mode - mode to adopt in pmic sleep 0 - off, 1 - auto, + ti,mode-sleep - mode to adopt in pmic sleep 0 - off, 1 - auto, 2 - eco, 3 - forced pwm ti,tstep - slope control 0 - Jump, 1 10mV/us, 2 5mV/us, 3 2.5mV/us ti,smps-range - OTP has the wrong range set for the hardware so override -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/2] regulator: palmas-pmic: doc: update device tree bindings
On 09:23-20130716, Nishanth Menon wrote: We seem to have a few missing updates to device tree bindings with the latest set of changes getting merged in. Oops.. seems like I have an old mailID for Mark :( Based on v3.11-rc1 tag Nishanth Menon (2): regulator: palmas-pmic: doc: fix typo for sleep-mode regulator: palmas-pmic: doc: remove ti,tstep .../devicetree/bindings/regulator/palmas-pmic.txt |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) -- 1.7.9.5 Regards, Nishanth Menon -- Regards, Nishanth Menon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V2 0/2] regulator: palmas-pmic: doc: update device tree bindings
We seem to have a few missing updates to device tree bindings with the latest set of changes getting merged in. Changes since V1: Apologies on the spam, looks like I got the wrong mail ID first time around :( minor commit message cleanups V1: http://marc.info/?l=linux-docm=137398467901450w=2 Based on v3.11-rc1 tag Nishanth Menon (2): regulator: palmas-pmic: doc: fix typo for sleep-mode regulator: palmas-pmic: doc: remove ti,tstep .../devicetree/bindings/regulator/palmas-pmic.txt |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) -- 1.7.9.5 Regards, Nishanth Menon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V2 2/2] regulator: palmas-pmic: doc: remove ti,tstep
commit 28d1e8cd671a53d6b4f967abbbc2a55f7bd333f6
(regulator: palma: add ramp delay support through regulator constraints)
Removed the regulator's ti,step option from driver without updating the
documentation.
So, remove from documentation and example as well.
Signed-off-by: Nishanth Menon n...@ti.com
---
.../devicetree/bindings/regulator/palmas-pmic.txt |2 --
1 file changed, 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
index 04d67f0..30b0581 100644
--- a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
+++ b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
@@ -33,7 +33,6 @@ Optional nodes:
ti,roof-floor - control voltage selection by pin(boolean)
ti,mode-sleep - mode to adopt in pmic sleep 0 - off, 1 - auto,
2 - eco, 3 - forced pwm
- ti,tstep - slope control 0 - Jump, 1 10mV/us, 2 5mV/us, 3
2.5mV/us
ti,smps-range - OTP has the wrong range set for the hardware so
override
0 - low range, 1 - high range.
@@ -59,7 +58,6 @@ pmic {
ti,warm-reset;
ti,roof-floor;
ti,mode-sleep = 0;
- ti,tstep = 0;
ti,smps-range = 1;
};
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH V2 1/8] regulator: Introduce OMAP regulator to control PMIC over VC/VP
On 07/09/2013 10:29 AM, Mark Brown wrote: On Mon, Jul 08, 2013 at 12:22:36PM -0500, Nishanth Menon wrote: 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. 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 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. 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. 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. 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. 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. 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. True, but slightly different topic though. 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? between PMICs? yep, twl4030 does 4mV/uSec, 6030 can do 6mV/uSec, TPS62361 can do 32mV/uSec, TWL6035/37 does 0.220mV/uSec 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? 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 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH V2 1/8] regulator: Introduce OMAP regulator to control PMIC over VC/VP
On 07/05/2013 12:47 PM, Mark Brown wrote:
On Fri, Jul 05, 2013 at 12:33:10PM -0500, Nishanth Menon wrote:
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?
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.
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)?
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.
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.
OK, so this is a register defined by the OMAP architecture? I think
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 :(
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.
custom of-match data parameter is how it is done today in this patch
Anything that implements a custom set_voltage() won't work with your
data structure either...
It would not work with OMAP either ;). But that said, drivers do
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.
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.
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.
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
Re: [RFC PATCH V2 1/8] regulator: Introduce OMAP regulator to control PMIC over VC/VP
On 16:41-20130704, Mark Brown wrote:
On Fri, Jun 21, 2013 at 04:25:42PM -0500, Nishanth Menon wrote:
+static const struct omap_pmic_info omap_twl4030_vdd1 = {
+ .slave_addr = 0x12,
+ .voltage_reg_addr = 0x00,
+ .cmd_reg_addr = 0x00,
+ .i2c_timeout_us = 200,
+ .slew_rate_uV = 4000,
+ .step_size_uV = 12500,
+ .min_uV = 60,
+ .max_uV = 145,
+ .voltage_selector_offset = 0,
+ .voltage_selector_mask = 0x7F,
+ .voltage_selector_setbits = 0x0,
+ .voltage_selector_zero = false,
+};
So, this still has the thing where all the data about the PMIC is
replicated (but now in this driver). It should be possible to pull all
the above information except possibly the I2C timeout and perhaps the
I2C address (if there's a separate control interface) from the standard
regulator core data structures for the PMIC. This would allow the
driver to Just Work with any PMIC without needing to add it in two
places.
Other than that this looks good, the only issue I see is where the
driver is getting the data from.
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=13651386525r=1w=2
--
Regards,
Nishanth Menon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH V2 1/8] regulator: Introduce OMAP regulator to control PMIC over VC/VP
On 07/05/2013 09:08 AM, Mark Brown wrote:
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.
Apologies on the same. Will try to do better.
On 16:41-20130704, Mark Brown wrote:
So, this still has the thing where all the data about the PMIC is
replicated (but now in this driver). It should be possible to pull all
the above information except possibly the I2C timeout and perhaps the
I2C address (if there's a separate control interface) from the standard
regulator core data structures for the PMIC. This would allow the
driver to Just Work with any PMIC without needing to add it in two
places.
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]
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.
:) it is similar, yes. by bypass get/set_voltage, I mean something like [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.
What makes you think that the existing regulator drivers need to be
modified?
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.
They already have all the data exported to the core (or
should do)...
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:
+static const struct omap_pmic_info omap_twl4030_vdd1 = {
+ .slave_addr = 0x12,
Not readily exposed, but we can solve that using reg=0x12; in dts -
this might not be duplication as the register address will be unique for
the bus.
+ .voltage_reg_addr = 0x00,
desc-vsel_reg maps fine
+ .cmd_reg_addr = 0x00,
command register is used for sending low power state commands - which is
not the same as voltage register or vsel_reg as used in depicted in
regulator_desc.
+ .i2c_timeout_us = 200,
yep, does not match up.
+ .slew_rate_uV = 4000,
desc-ramp_delay maps fine
+ .step_size_uV = 12500,
desc-uV_step maps fine.
+ .min_uV = 60,
desc-min_uV maps fine.
+ .max_uV = 145,
can be used with constraints, but most regulator drivers seem to store
this internally.
+ .voltage_selector_offset = 0,
+ .voltage_selector_mask = 0x7F,
+ .voltage_selector_setbits = 0x0,
+ .voltage_selector_zero = false,
to an extent we can map these to vsel_mask, linear_min_sel etc. (again
assuming the regulator driver has populated it - most that implement
custom set_voltage, get_voltage do not do that.
Now, How do you suggest I pick up this data in omap_pmic regulator?
linux/regulator/consumer.h does not seem appropriate omap_pmic is not
really a consumer of the regulator and further all the detailed data is
not exposed either.
Other option is to make rdev available to omap_pmic regulator - which
again implies change in existing regulator driver?
the only thing that's missing is the timeouts and it's
not at all obvious why those need to be tuned per device.
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.
option 2) make omap_pmic regulator use twl_regulator - regulator
chaining.
Again I don't know what this is.
Lets ignore this for the moment.
[1]
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=63bfff4e20211b464cbea6e79e5fd36df227c154
--
Regards,
Nishanth Menon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH V2 1/8] regulator: Introduce OMAP regulator to control PMIC over VC/VP
On 07/05/2013 11:52 AM, Mark Brown wrote: On Fri, Jul 05, 2013 at 09:50:34AM -0500, Nishanth Menon wrote: On 07/05/2013 09:08 AM, Mark Brown wrote: 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] 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. :) it is similar, yes. by bypass get/set_voltage, I mean something like [1] No, that's not a good idea. I agree. What makes you think that the existing regulator drivers need to be modified? 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. They already have all the data exported to the core (or should do)... 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: 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. 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. + .cmd_reg_addr = 0x00, command register is used for sending low power state commands - which is not the same as voltage register or vsel_reg as used in depicted in regulator_desc. 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. 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. + .i2c_timeout_us = 200, yep, does not match up. Like I say I just don't see why this is even specified per device. + .max_uV = 145, can be used with constraints, but most regulator drivers seem to store this internally. Or just trivially calculate it as we do currently. + .voltage_selector_offset = 0, + .voltage_selector_mask = 0x7F, + .voltage_selector_setbits = 0x0, + .voltage_selector_zero = false, to an extent we can map these to vsel_mask, linear_min_sel etc. (again assuming the regulator driver has populated it - most that implement custom set_voltage, get_voltage do not do that. Anything that implements a custom set_voltage() won't work with your data structure either... 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. Other option is to make rdev available to omap_pmic regulator - which again implies change in existing regulator driver? Why would any of the drivers need to change to do this? They're already exporting the information. I am thinking here: two regulator drivers, using same rdev/desc for getting the data. probably makes no sense, I agree. the only thing that's missing is the timeouts and it's not at all obvious why those need to be tuned per device. 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. So pick a high number (it's only for error cases...)? 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
Re: [PATCH v2 4/9] wl12xx: use frequency instead of enumerations for pdata clocks
is used, 0 for SDIO IRQs */
@@ -58,8 +36,10 @@ struct wl1251_platform_data {
struct wl12xx_platform_data {
int irq;
unsigned long irq_flags;
- int board_ref_clock;
- int board_tcxo_clock;
+ int ref_clock_freq; /* in Hertz */
+ bool ref_clock_xtal;/* specify whether the clock is XTAL or not */
+ int tcxo_clock_freq;/* in Hertz */
+ bool tcxo_clock_xtal; /* specify whether the clock is XTAL or not */
};
#ifdef CONFIG_WILINK_PLATFORM_DATA
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Regards,
Nishanth Menon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] Documentation: dt: bindings: TI WiLink modules
On 11:47-20130627, Luciano Coelho wrote:
(added mailing lists and everyone back to the thread)
On Wed, 2013-06-26 at 23:38 -0500, Nishanth Menon wrote:
On 06/25/2013 03:35 AM, Luciano Coelho wrote:
+Optional properties:
+
+
+- refclock: the internal WLAN reference clock frequency (required for
+ WiLink6 and WiLink7; not used for WiLink8). Must be one of the
+ following:
+ 0 = 19.2 MHz
+ 1 = 26.0 MHz
+ 2 = 38.4 MHz
+ 3 = 52.0 MHz
+ 4 = 38.4 MHz, XTAL
+ 5 = 26.0 MHz, XTAL
+
+- tcxoclock: the internal WLAN TCXO clock frequency (required for
+ WiLink7 not used for WiLink6 and WiLink8). Must be one of the
+ following:
+ 0 = 19.200 MHz
+ 1 = 26.000 MHz
+ 2 = 38.400 MHz
+ 3 = 52.000 MHz
+ 4 = 16.368 MHz
+ 5 = 32.736 MHz
+ 6 = 16.800 MHz
+ 7 = 33.600 MHz
just a gentle query - why not use frequency itself here in Hz for
refclock and txoclk?
I thought about using the actual frequencies, but I decided not to do
so, because I'd have to convert them to these values anyway. These
values are used to configure the firmware and it uses these
enumerations.
Could we not hide this under preprocessor macros instead? just wondering
of txoclock = 6; kind of usage.. easy to make mistakes and easier to
confuse a new reader :).
just my 2 cents.
might not another option of using
node {
clocks=clk;
}
Usually refclock is an external clock source, no?
No. In the WiLink case, both refclock and tcxoclock are internal
clocks. They are in the module itself and what we need to do is tell
the WiLink chip what the module's clocks look like.
the above allows you to do an devm_clk_get and clk_get_rate() to figure
out the exact clock frequency.
No, we can't use these calls, because they are internal clocks.
Please see my more complete explanation as an answer to Tony's email.
K thanks.
Thanks for your review!
Glad to be of help.
--
Regards,
Nishanth Menon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] Documentation: dt: bindings: TI WiLink modules
On Thu, Jun 27, 2013 at 7:58 AM, Luciano Coelho coe...@ti.com wrote: On Thu, 2013-06-27 at 07:51 -0500, Nishanth Menon wrote: On 11:47-20130627, Luciano Coelho wrote: (added mailing lists and everyone back to the thread) On Wed, 2013-06-26 at 23:38 -0500, Nishanth Menon wrote: On 06/25/2013 03:35 AM, Luciano Coelho wrote: +Optional properties: + + +- refclock: the internal WLAN reference clock frequency (required for + WiLink6 and WiLink7; not used for WiLink8). Must be one of the + following: + 0 = 19.2 MHz + 1 = 26.0 MHz + 2 = 38.4 MHz + 3 = 52.0 MHz + 4 = 38.4 MHz, XTAL + 5 = 26.0 MHz, XTAL + +- tcxoclock: the internal WLAN TCXO clock frequency (required for + WiLink7 not used for WiLink6 and WiLink8). Must be one of the + following: + 0 = 19.200 MHz + 1 = 26.000 MHz + 2 = 38.400 MHz + 3 = 52.000 MHz + 4 = 16.368 MHz + 5 = 32.736 MHz + 6 = 16.800 MHz + 7 = 33.600 MHz just a gentle query - why not use frequency itself here in Hz for refclock and txoclk? I thought about using the actual frequencies, but I decided not to do so, because I'd have to convert them to these values anyway. These values are used to configure the firmware and it uses these enumerations. Could we not hide this under preprocessor macros instead? just wondering of txoclock = 6; kind of usage.. easy to make mistakes and easier to confuse a new reader :). Yes, I guess we could create some preprocessor macros for this. But the documentation would remain the same. I can't add preprocessor macros to the bindings documentation. ;) For the actual DTS files, I could add a wilink.dtsi with enumerations for these values so they could be used in the node definitions. But I'm not sure it's going to be that valuable in the end. The way GPIO HIGH was defined might help to provide guidance I think :) Regards, NM ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] Documentation: dt: bindings: TI WiLink modules
On Thu, Jun 27, 2013 at 8:30 AM, Luciano Coelho coe...@ti.com wrote: On Thu, 2013-06-27 at 08:23 -0500, Nishanth Menon wrote: On 06/27/2013 08:19 AM, Luciano Coelho wrote: On Thu, 2013-06-27 at 08:15 -0500, Nishanth Menon wrote: On Thu, Jun 27, 2013 at 7:58 AM, Luciano Coelho coe...@ti.com wrote: For the actual DTS files, I could add a wilink.dtsi with enumerations for these values so they could be used in the node definitions. But I'm not sure it's going to be that valuable in the end. The way GPIO HIGH was defined might help to provide guidance I think :) Where? As far as I can see, the GPIO flags are defined in a bitmap. include/dt-bindings/gpio/gpio.h Thanks! I don't see these macros used anywhere, though. umm... I'd think you have'nt looked deep enough / lists :) And corresponding kernel header: include/linux/of_gpio.h This seems to be a completely different thing. This is the header that contains the helper functions to get GPIO-related device tree nodes, isn't it? That is true, but it also contains the flag for level which needs to be in sync with the gpio.h dts header. just a hint. not saying frequencies were defined in header. for systems that define frequencies - example cpufreq OPPs, clock node usage, we do not use indexing to frequency, instead, that is the responsibility of driver to convert frequency back to required index. git grep frequency Documentation/devicetree/bindings gives you how the precedence looks like. Personally, if given a choice, I'd go with actual frequencies rather than indexes. If I do that, I need to add also a separate flag to define whether the XTAL clock is used or not. For instance, we have 26MHz and 26MHz crystal; and 38.4MHz and 38.4MHz crystal... Yes, you would have to. at the same time, it is easy for module maker to provide dtsi corresponding to exact h/w representation on his module using wilink chip without being worried about weird index value whose meaning is hidden in binding On the flip side, It also allows driver to reject frequencies / configurations that are not supported by the corresponding chip. As I said, just my 2 cents. Personally, I'd like dts files to be as readable as c files without having to dig through bindings document. Regards, Nishanth Menon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] Documentation: dt: bindings: TI WiLink modules
On 06/27/2013 01:51 PM, Luciano Coelho wrote:
On Thu, 2013-06-27 at 08:39 -0500, Nishanth Menon wrote:
On Thu, Jun 27, 2013 at 8:30 AM, Luciano Coelho coe...@ti.com wrote:
On Thu, 2013-06-27 at 08:23 -0500, Nishanth Menon wrote:
On 06/27/2013 08:19 AM, Luciano Coelho wrote:
On Thu, 2013-06-27 at 08:15 -0500, Nishanth Menon wrote:
On Thu, Jun 27, 2013 at 7:58 AM, Luciano Coelho coe...@ti.com wrote:
For the actual DTS files, I could add a wilink.dtsi with enumerations
for these values so they could be used in the node definitions. But I'm
not sure it's going to be that valuable in the end.
The way GPIO HIGH was defined might help to provide guidance I think :)
Where? As far as I can see, the GPIO flags are defined in a bitmap.
include/dt-bindings/gpio/gpio.h
Thanks! I don't see these macros used anywhere, though.
umm... I'd think you have'nt looked deep enough / lists :)
If you mean mailing lists, you're right, I didn't. I just did a git
grep for the macros and didn't find any users.
git grep GPIO_ACTIVE_[HIGH|LOW] arch/arm/boot/dts/|wc -l
344
on next-20130626. anyways, besides the point.
This seems to be a completely different thing. This is the header that
contains the helper functions to get GPIO-related device tree nodes,
isn't it?
That is true, but it also contains the flag for level which needs to
be in sync with the gpio.h dts header.
just a hint. not saying frequencies were defined in header. for systems
that define frequencies - example cpufreq OPPs, clock node usage, we do
not use indexing to frequency, instead, that is the responsibility of
driver to convert frequency back to required index.
git grep frequency Documentation/devicetree/bindings gives you how the
precedence looks like.
Personally, if given a choice, I'd go with actual frequencies rather
than indexes.
If I do that, I need to add also a separate flag to define whether the
XTAL clock is used or not. For instance, we have 26MHz and 26MHz
crystal; and 38.4MHz and 38.4MHz crystal...
Yes, you would have to. at the same time, it is easy for module maker
to provide dtsi corresponding to exact h/w representation on his
module using wilink chip without being worried about weird index value
whose meaning is hidden in binding
The module makers need to know about the bindings and read the document
before they specify the node in DTS. I think for clarity, a comment in
the DTS file stating the actual frequency is good enough. Simpler and
more efficient (in terms of DT binary size and module code size) than
adding the actual frequencies.
On the flip side, It also allows driver to reject frequencies /
configurations that are not supported by the corresponding chip.
It's actually much easier to reject frequencies that are not valid with
the enumeration. if (refclock 5) { bail_out(); }. If I need to
check every frequency, I need to add an array of valid frequencies and
so on. Waste of code, IMHO.
As I said, just my 2 cents. Personally, I'd like dts files to be as
readable as c files without having to dig through bindings document.
As I said before, for readability, adding a comment with the frequency
is good enough. This is what I did for PandaES's DTS (not sent out
yet):
wlan {
compatible = ti,wilink6;
interrupt-parent = gpio2;
interrupts = 21 0x4; /* gpio line 53, high level triggered
*/
refclock = 2; /* 38.4 MHz */
};
Looks more readable to me than:
wlan {
compatible = ti,wilink6;
interrupt-parent = gpio2;
interrupts = 21 0x4; /* gpio line 53, high level triggered
*/
refclock = 38400;
refclock_xtal = 0;
};
The macro idea sounds better to me, but in this case this code is so
simple that I don't think it's really worth it.
And, from another point of view, I see this as only a specification of
the module's details. The frequency value is not really used anywhere
outside the module, so we don't see it. I don't think there's a good
reason to expose the actual frequency to the kernel (and parse it back
to the values the firmware needs), since nothing else inside the kernel
will care about it.
Overview: we are adding bindings for
Documentation/devicetree/bindings/net/wireless/ti-wilink.txt Which I
believe is intended to be generic.
Current frequencies supported for tcxoclock is the following for WiLink7
+ 0 = 19.200 MHz
+ 1 = 26.000 MHz
+ 2 = 38.400 MHz
+ 3 = 52.000 MHz
+ 4 = 16.368 MHz
+ 5 = 32.736 MHz
+ 6 = 16.800 MHz
+ 7 = 33.600 MHz
Say wilink9 comes along and redefines this map OR introduces support for
20MHz support making the map 0-8, you'd no longer be able to support
this map. or say a new update of firmware magically changes this mapping
or something unexpected.
If the translation and validation is done in the driver, it is trivial
to handle without
Re: [PATCH] Documentation: dt: bindings: TI WiLink modules
On 06/27/2013 02:46 PM, Luciano Coelho wrote: On Thu, 2013-06-27 at 14:12 -0500, Nishanth Menon wrote: [...] Indexes to another entity is always a maintenance burden in the longer run and needs judicious control. If it is possible to avoid it by selecting the right parameters, I am a hard advocate for the same. I tend to agree. But you need a balance. In theory you're right. But I think if you take the real world example, it is over-engineering. Anyway, if you *really* think this needs to be changed, I think we're in a deadlock here and I'd like to hear other people's opinions. I don't mind making the change, but I'm still not convinced it is worth it, since it just adds complexity. And hey, this is too much bikeshedding for such a small detail. Lol :) Alrite, if no one else is complaining, I am not going to block it either. -- Regards, Nishanth Menon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2] ARM: DTS: OMAP4: Add OMAP4 Blaze Tablet support
On Wed, Jun 26, 2013 at 3:03 AM, Ruslan Bilovol ruslan.bilo...@ti.com wrote:
Hi Nishanth,
On Tue, Jun 25, 2013 at 3:43 PM, Nishanth Menon n...@ti.com wrote:
On 06/25/2013 07:01 AM, Nishanth Menon wrote:
On 06/25/2013 06:32 AM, Ruslan Bilovol wrote:
The OMAP4 Blaze Tablet is TI OMAP4 processor-based
development platform in a tablet formfactor.
The platform contains many of the features found in
present-day handsets (such as audio, video, wireless
functions and user interfaces) and in addition
contains features for software development and test.
This patch adds initial support for the OMAP4 Blaze
Tablet development platform. Additional functionality
depends on different drivers and code modifications that
are not upstreamed yet or do not support DT yet, so will
be added later.--
http://svtronics.com/omap/sevm4460,blaze,omap might help too :)
Yes, forgot to add this information from cover-letter from previous
version of patch :)
;) - link was wrong!
http://svtronics.com/omap?product_id=15 is more like it - Blaze
tablet by default comes in 4460/4470 variants. I suggest introducing
4470 variant here.
I am aware of the SOM compatibility and ability to support 4430 SOM on
tablet as well, but to keep tablet alive and reduce scope of testing,
keeping just 4470 in place might be a good choice.
just my 2 cents, no strong feelings towards either. :)
[...]
+
+#include twl6030.dtsi
+
Might be good to see the TWL interrupt pin information made available as
well?
Allow me to rephrase a comment a little bit more :)
Similar to twl4030_omap3.dtsi, we could introduce twl6030_omap4.dtsi. this
could contain the common pins used for 6030.
omap4_pmx_wkup {
pinctrl-names = default;
pinctrl-0 =
twl6030_wkup_pins
;
twl6030_wkup_pins: pinmux_twl6030_wkup_pins {
pinctrl-single,pins =
0x14 (PIN_OUTPUT | MUX_MODE2)
;
};
};
twl6030_pins: pinmux_twl6030_pins {
pinctrl-single,pins =
0x15e (WAKEUP_EN | PIN_INPUT_PULLUP | MUX_MODE0)
/* sys_nirq1.sys_nirq1 */
;
};
which is now already duplicated in 2 places (SDP and Panda), and in this
patch duplicated again.
Agree, I'm planning to do this later as part of moving common things into
some System-On-Module(SOM)-specific files, as discussed previously
here https://patchwork.kernel.org/patch/2118371/
I dont think I was mentioning about that - I just would really like to
avoid duplication of 6030 information all over the place. if we can
avoid it, lets start consolidating.
Regards,
Nishanth Menon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2] ARM: DTS: OMAP4: Add OMAP4 Blaze Tablet support
On 06/25/2013 06:32 AM, Ruslan Bilovol wrote: The OMAP4 Blaze Tablet is TI OMAP4 processor-based development platform in a tablet formfactor. The platform contains many of the features found in present-day handsets (such as audio, video, wireless functions and user interfaces) and in addition contains features for software development and test. This patch adds initial support for the OMAP4 Blaze Tablet development platform. Additional functionality depends on different drivers and code modifications that are not upstreamed yet or do not support DT yet, so will be added later. http://svtronics.com/omap/sevm4460,blaze,omap might help too :) [...] + +#include twl6030.dtsi + Might be good to see the TWL interrupt pin information made available as well? [...] Regards, Nishanth Menon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2] ARM: DTS: OMAP4: Add OMAP4 Blaze Tablet support
On 06/25/2013 07:01 AM, Nishanth Menon wrote:
On 06/25/2013 06:32 AM, Ruslan Bilovol wrote:
The OMAP4 Blaze Tablet is TI OMAP4 processor-based
development platform in a tablet formfactor.
The platform contains many of the features found in
present-day handsets (such as audio, video, wireless
functions and user interfaces) and in addition
contains features for software development and test.
This patch adds initial support for the OMAP4 Blaze
Tablet development platform. Additional functionality
depends on different drivers and code modifications that
are not upstreamed yet or do not support DT yet, so will
be added later.
http://svtronics.com/omap/sevm4460,blaze,omap might help too :)
[...]
+
+#include twl6030.dtsi
+
Might be good to see the TWL interrupt pin information made available as
well?
Allow me to rephrase a comment a little bit more :)
Similar to twl4030_omap3.dtsi, we could introduce twl6030_omap4.dtsi.
this could contain the common pins used for 6030.
omap4_pmx_wkup {
pinctrl-names = default;
pinctrl-0 =
twl6030_wkup_pins
;
twl6030_wkup_pins: pinmux_twl6030_wkup_pins {
pinctrl-single,pins =
0x14 (PIN_OUTPUT | MUX_MODE2)
;
};
};
twl6030_pins: pinmux_twl6030_pins {
pinctrl-single,pins =
0x15e (WAKEUP_EN | PIN_INPUT_PULLUP | MUX_MODE0) /*
sys_nirq1.sys_nirq1 */
;
};
which is now already duplicated in 2 places (SDP and Panda), and in this
patch duplicated again.
just my 2 cents :(
---
Regards,
Nishanth Menon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv2 02/11] CLK: use of_property_read_u32 instead of read_u8
On 17:57-20130620, Mike Turquette wrote:
On Wed, Jun 19, 2013 at 6:18 AM, Tero Kristo t-kri...@ti.com wrote:
of_property_read_u8 does not work properly because of endianess problem
with its current implementation, and this causes it to always return
0 with little endian architectures. Instead, use property_read_u32
until this is fixed.
Tero,
Thanks for the fix. Heiko Stubner pointed out to me that in order to
read a u8 value the DT node needs to specify /bits/ 8 before the
values. From the of_property_read_u8_array kerneldoc:
/**
...
* dts entry of array should be like:
* property = /bits/ 8 0x50 0x60 0x70;
*
* The out_value is modified only if a valid u8 value can be decoded.
*/
Still I think it is a bit silly to have to do this in all of the
bindings, so I'm going to roll this patch into my next version of the
series if only for the sake of readability. Not only that but it is
slightly more future proof for the binding to use a u32 value. The
fact that the implementation in Linux uses a u8 is of little
consequence to the binding. I'll also add a cast like the following
to your patch:
clk = clk_register_gate(NULL, clk_name, parent_name, 0, reg, (u8) bit_idx,
clk_gate_flags, NULL);
Given that dtb size could be directly impacted, could we consider
something like a preprocessor macro to make it readable, yet not too
huge dts size?
Signed-off-by: Tero Kristo t-kri...@ti.com
---
drivers/clk/clk-divider.c |4 ++--
drivers/clk/clk-gate.c|4 ++--
drivers/clk/clk-mux.c |4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index 17ea475..3413602 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -361,7 +361,7 @@ void of_divider_clk_setup(struct device_node *node)
const char *parent_name;
u8 clk_divider_flags = 0;
u32 mask = 0;
- u8 shift = 0;
+ u32 shift = 0;
struct clk_div_table *table;
of_property_read_string(node, clock-output-names, clk_name);
@@ -375,7 +375,7 @@ void of_divider_clk_setup(struct device_node *node)
return;
}
- if (of_property_read_u8(node, bit-shift, shift)) {
+ if (of_property_read_u32(node, bit-shift, shift)) {
shift = __ffs(mask);
pr_debug(%s: bit-shift property defaults to 0x%x for %s\n,
__func__, shift, node-name);
diff --git a/drivers/clk/clk-gate.c b/drivers/clk/clk-gate.c
index 72cf99d..61b4dc1 100644
--- a/drivers/clk/clk-gate.c
+++ b/drivers/clk/clk-gate.c
@@ -162,7 +162,7 @@ void of_gate_clk_setup(struct device_node *node)
void __iomem *reg;
const char *parent_name;
u8 clk_gate_flags = 0;
- u8 bit_idx = 0;
+ u32 bit_idx = 0;
of_property_read_string(node, clock-output-names, clk_name);
@@ -170,7 +170,7 @@ void of_gate_clk_setup(struct device_node *node)
reg = of_iomap(node, 0);
- if (of_property_read_u8(node, bit-shift, bit_idx)) {
+ if (of_property_read_u32(node, bit-shift, bit_idx)) {
pr_err(%s: missing bit-shift property for %s\n,
__func__, node-name);
return;
diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
index c9f9f32..e63dd1b 100644
--- a/drivers/clk/clk-mux.c
+++ b/drivers/clk/clk-mux.c
@@ -170,7 +170,7 @@ void of_mux_clk_setup(struct device_node *node)
int i;
u8 clk_mux_flags = 0;
u32 mask = 0;
- u8 shift = 0;
+ u32 shift = 0;
of_property_read_string(node, clock-output-names, clk_name);
@@ -194,7 +194,7 @@ void of_mux_clk_setup(struct device_node *node)
return;
}
- if (of_property_read_u8(node, bit-shift, shift)) {
+ if (of_property_read_u32(node, bit-shift, shift)) {
shift = __ffs(mask);
pr_debug(%s: bit-shift property defaults to 0x%x for %s\n,
__func__, shift, node-name);
--
1.7.9.5
--
Regards,
Nishanth Menon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH V2 5/8] ARM: dts: OMAP4: add voltage processor nodes
OMAP443x, OMAP446x SoC use same offsets for voltage processor,
however their voltage characteristics differ a little.
Introduce the voltage processor nodes for the same.
Signed-off-by: Nishanth Menon n...@ti.com
---
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(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index a153e8d..3c75b23 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -689,5 +689,48 @@
compatible = ti,omap4-vc-channel-core;
};
};
+
+ vp_mpu: vp@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 = 1;
+ ti,max-step-micro-volts = 5;
+ };
+
+ vp_iva: vp@0x4A307B70 {
+ compatible = ti,omap4-vp;
+
+ reg = 0x4A307B70 0x18, 0x4A306010 0x4;
+ reg-names = base-address, int-address;
+ ti,tranxdone-status-mask=0x2000;
+
+ clocks = sysclk_in;
+
+ ti,vc-channel = vc_iva;
+ ti,min-step-micro-volts = 1;
+ ti,max-step-micro-volts = 5;
+ };
+
+ vp_core: vp@0x4A307B40 {
+ compatible = ti,omap4-vp;
+
+ reg = 0x4A307b40 0x18, 0x4A306010 0x4;
+ reg-names = base-address, int-address;
+ ti,tranxdone-status-mask=0x20;
+
+ clocks = sysclk_in;
+
+ regulator_name = vdd_core;
+ ti,vc-channel = vc_core;
+ ti,min-step-micro-volts = 1;
+ ti,max-step-micro-volts = 5;
+ };
};
};
diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index 2b0deb5..e759937 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -46,3 +46,18 @@
ti,retention-micro-volts = 75;
ti,off-micro-volts = 0;
};
+
+vp_mpu {
+ ti,min-micro-volts = 75;
+ ti,max-micro-volts = 1388000;
+};
+
+vp_iva {
+ ti,min-micro-volts = 75;
+ ti,max-micro-volts = 1291000;
+};
+
+vp_core {
+ ti,min-micro-volts = 75;
+ ti,max-micro-volts = 1127000;
+};
diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
index 16210a1..8320865 100644
--- a/arch/arm/boot/dts/omap4460.dtsi
+++ b/arch/arm/boot/dts/omap4460.dtsi
@@ -55,3 +55,18 @@
ti,retention-micro-volts = 75;
ti,off-micro-volts = 0;
};
+
+vp_mpu {
+ ti,min-micro-volts = 75;
+ ti,max-micro-volts = 138;
+};
+
+vp_iva {
+ ti,min-micro-volts = 75;
+ ti,max-micro-volts = 1375000;
+};
+
+vp_core {
+ ti,min-micro-volts = 75;
+ ti,max-micro-volts = 125;
+};
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH V2 4/8] ARM: dts: OMAP4: add voltage controller nodes
OMAP443x, OMAP446x SoC use same offsets for voltage controller,
however their voltage characteristics differ a little.
Introduce the voltage controller nodes for the same.
Signed-off-by: Nishanth Menon n...@ti.com
---
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(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 3b44546..a153e8d 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -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@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;
+ };
+ };
};
};
diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index bcf455e..2b0deb5 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -31,3 +31,18 @@
compatible = ti,omap4430-bandgap;
};
};
+
+vc_mpu {
+ ti,retention-micro-volts = 75;
+ ti,off-micro-volts = 0;
+};
+
+vc_iva {
+ ti,retention-micro-volts = 75;
+ ti,off-micro-volts = 0;
+};
+
+vc_core {
+ ti,retention-micro-volts = 75;
+ ti,off-micro-volts = 0;
+};
diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
index c2f0f39..16210a1 100644
--- a/arch/arm/boot/dts/omap4460.dtsi
+++ b/arch/arm/boot/dts/omap4460.dtsi
@@ -39,3 +39,19 @@
gpios = gpio3 22 0; /* tshut */
};
};
+
+vc_mpu {
+ ti,retention-micro-volts = 75;
+ /* Erratum i738: Reliability impact work around */
+ ti,off-micro-volts = 75;
+};
+
+vc_iva {
+ ti,retention-micro-volts = 75;
+ ti,off-micro-volts = 0;
+};
+
+vc_core {
+ ti,retention-micro-volts = 75;
+ ti,off-micro-volts = 0;
+};
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH V2 6/8] ARM: dts: TWL6030/OMAP4: Add OMAP voltage path linkage
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.
Signed-off-by: Nishanth Menon n...@ti.com
---
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
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 00cbaa5..2b15c2b 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -199,6 +199,7 @@
};
#include twl6030.dtsi
+#include twl6030_omap4.dtsi
i2c2 {
pinctrl-names = default;
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index 56c4354..49017c5 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -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;
+};
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 7951b4e..2f81b4d5 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -337,6 +337,7 @@
};
#include twl6030.dtsi
+#include twl6030_omap4.dtsi
i2c2 {
pinctrl-names = default;
diff --git a/arch/arm/boot/dts/omap4-var-som.dts
b/arch/arm/boot/dts/omap4-var-som.dts
index b41269e..6f0b763 100644
--- a/arch/arm/boot/dts/omap4-var-som.dts
+++ b/arch/arm/boot/dts/omap4-var-som.dts
@@ -40,6 +40,7 @@
};
#include twl6030.dtsi
+#include twl6030_omap4.dtsi
i2c2 {
clock-frequency = 40;
diff --git a/arch/arm/boot/dts/twl6030_omap4.dtsi
b/arch/arm/boot/dts/twl6030_omap4.dtsi
new file mode 100644
index 000..7724039
--- /dev/null
+++ b/arch/arm/boot/dts/twl6030_omap4.dtsi
@@ -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 = 120;
+ ti,vp = vp_mpu;
+ };
+
+ omap_twl6030_vcore2: vcore2 {
+ compatible = ti,omap-twl6030-vcore2;
+ ti,boot-voltage-micro-volts = 120;
+ ti,vp = vp_iva;
+ };
+
+ omap_twl6030_vcore3: vcore3 {
+ compatible = ti,omap-twl6030-vcore3;
+ ti,boot-voltage-micro-volts = 120;
+ ti,vp = vp_core;
+ };
+};
+
+vc {
+ ti,i2c-high-speed;
+ ti,i2c-pad-load = 3;
+};
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH V2 7/8] ARM: dts: omap4-panda-es: add TPS62361 supply for vdd_mpu
Unlike other OMAP4 platforms including the the vanilla PandaBoard,
PandaBoard-ES uses TPS62361 to supply vdd_mpu.
Signed-off-by: Nishanth Menon n...@ti.com
---
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
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index 49017c5..325816c 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -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;
+};
diff --git a/arch/arm/boot/dts/tps62361_omap.dtsi
b/arch/arm/boot/dts/tps62361_omap.dtsi
new file mode 100644
index 000..ee261ec
--- /dev/null
+++ b/arch/arm/boot/dts/tps62361_omap.dtsi
@@ -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
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH V2 8/8] ARM: dts: OMAP4-panda-es: use tps regulator as cpu0 supply
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.
Signed-off-by: Nishanth Menon n...@ti.com
---
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(-)
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index 325816c..d2ce518 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -93,3 +93,7 @@
;
gpios = gpio1 7 GPIO_ACTIVE_HIGH;
};
+
+cpu0 {
+ cpu0-supply = omap_tps62361;
+};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 3c75b23..127b974 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -24,13 +24,13 @@
};
cpus {
- cpu@0 {
+ cpu0: cpu@0 {
compatible = arm,cortex-a9;
next-level-cache = L2;
clocks = dpll_mpu;
clock-names = cpu;
};
- cpu@1 {
+ cpu1: cpu@1 {
compatible = arm,cortex-a9;
next-level-cache = L2;
};
diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index e759937..91a5f70 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -12,7 +12,7 @@
/ {
cpus {
- cpu@0 {
+ cpu0: cpu@0 {
/* OMAP443x variants OPP50-OPPNT */
operating-points =
/* kHzuV */
diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
index 8320865..9827e35 100644
--- a/arch/arm/boot/dts/omap4460.dtsi
+++ b/arch/arm/boot/dts/omap4460.dtsi
@@ -12,7 +12,7 @@
/ {
cpus {
/* OMAP446x 'standard device' variants OPP50 to OPPTurbo */
- cpu@0 {
+ cpu0: cpu@0 {
operating-points =
/* kHzuV */
35 1025000
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH V2 1/8] regulator: Introduce OMAP regulator to control PMIC over VC/VP
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. [grygorii.stras...@ti.com, ta...@ti.com: co-developer] Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com Signed-off-by: Taras Kondratiuk ta...@ti.com Signed-off-by: Nishanth Menon n...@ti.com --- .../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 diff --git a/Documentation/devicetree/bindings/regulator/omap-pmic-regulator.txt b/Documentation/devicetree/bindings/regulator/omap-pmic-regulator.txt new file mode 100644 index 000..6991e58 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/omap-pmic-regulator.txt @@ -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
[RFC PATCH V2 0/8] 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=13680400841r=1w=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=13692468965r=1w=2 related discussion: http://marc.info/?t=13716695495r=1w=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
[RFC PATCH V2 2/8] PM / AVS: Introduce support for OMAP Voltage Controller(VC) with device tree nodes
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. [grygorii.stras...@ti.com, ta...@ti.com: co-developer] Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com Signed-off-by: Taras Kondratiuk ta...@ti.com Signed-off-by: Nishanth Menon n...@ti.com --- .../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 diff --git a/Documentation/devicetree/bindings/power/omap-vc.txt b/Documentation/devicetree/bindings/power/omap-vc.txt new file mode 100644 index 000..f97737c --- /dev/null +++ b/Documentation/devicetree/bindings/power/omap-vc.txt @@ -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
[RFC PATCH V2 3/8] PM / AVS: Introduce support for OMAP Voltage Processor(VP) with device tree nodes
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.
[grygorii.stras...@ti.com, ta...@ti.com: co-developer]
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
Signed-off-by: Taras Kondratiuk ta...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
.../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
diff --git a/Documentation/devicetree/bindings/power/omap-vp.txt
b/Documentation/devicetree/bindings/power/omap-vp.txt
new file mode 100644
index 000..b690e35
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/omap-vp.txt
@@ -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@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 = 1;
+ ti,max-step-micro-volts = 5;
+ ti,min-micro-volts = 75;
+ ti,max-micro-volts = 141;
+};
diff --git a/drivers/power/avs/Makefile b/drivers/power/avs/Makefile
index 95d5f59..535cab5 100644
--- a/drivers/power/avs/Makefile
+++ b/drivers/power/avs/Makefile
@@ -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),)
diff --git a/drivers/power/avs/omap_vp.c b/drivers/power/avs
Re: [PATCHv2 10/11] ARM: dts: omap4 clock data
On 16:19-20130619, Tero Kristo wrote:
snip
diff --git a/arch/arm/boot/dts/omap4-clocks.dtsi
b/arch/arm/boot/dts/omap4-clocks.dtsi
new file mode 100644
index 000..b420d8a
--- /dev/null
+++ b/arch/arm/boot/dts/omap4-clocks.dtsi
[...]
+/* XXX Missing round_rate, set_rate in ops */
could be dropped?
+dpll_core_m3x2_div_ck: dpll_core_m3x2_div_ck@4a004134 {
+ compatible = divider-clock;
+ clocks = dpll_core_x2_ck;
+ #clock-cells = 0;
+ reg = 0x4a004134 0x4;
+ bit-mask = 0x1f;
+ index-starts-at-one;
+};
[..]
+
+/* XXX Missing round_rate, set_rate in ops */
could be dropped?
+dpll_per_m3x2_div_ck: dpll_per_m3x2_div_ck@4a008154 {
+ compatible = divider-clock;
+ clocks = dpll_per_x2_ck;
+ #clock-cells = 0;
+ reg = 0x4a008154 0x4;
+ bit-mask = 0x1f;
+ index-starts-at-one;
+};
+
[...]
+
+/*
+ * clocks specific to omap4460
+ */
+/*
+ * clocks specific to omap4430
+ */
+/*
+ * clocks common to omap44xx
+ */
could be dropped?
btw, are we differentiating 4430 and 4460?A
Example:
bandgap_fclk in 4430
Vs
div_ts_ck, bandgap_ts_fclk in 4460?
--
Regards,
Nishanth Menon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv2 10/11] ARM: dts: omap4 clock data
On 16:49-20130619, Tero Kristo wrote: On 06/19/2013 04:30 PM, Nishanth Menon wrote: On 16:19-20130619, Tero Kristo wrote: [...] + +/* + * clocks specific to omap4460 + */ +/* + * clocks specific to omap4430 + */ +/* + * clocks common to omap44xx + */ could be dropped? Same. btw, are we differentiating 4430 and 4460?A Example: bandgap_fclk in 4430 Vs div_ts_ck, bandgap_ts_fclk in 4460? Both nodes are available for both SoCs as of now. Driver should differentiate which clock node to use though. Added Eduardo for commenting this part, maybe we should add a couple of entries to the list in cclock44xx_data.c...? How about this: we do have 443x.dtsi and 4460.dtsi - add the corresponding clock nodes there? ideally, driver should just do devm_clk_get and should not worry about what SoC revision it is running on. -- Regards, Nishanth Menon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH 1/4] regulator: Introduce OMAP regulator to control PMIC over VC/VP
On 19:01-20130610, Mark Brown wrote: On Mon, Jun 10, 2013 at 12:51:42PM -0500, Nishanth Menon wrote: a) Tegra seems to use Lookup Table for sending predefinied voltage values to PMIC. OMAP has no concept of lookup table. They seem to be doing basically the same thing here, you've got a linear map of selector to voltage too AFAICT. b) Tegra and OMAP h/w blocks seem to use I2C - that is good. c) How about the i2c slave and register addresses, slew rates, start, end voltages, max voltages that SoC can support etc, I am yet to understand those. d) OMAP has 3 modules - AVS (SmartReflex), Voltage Processor(VP), Voltage Controller(VC) - I am not yet sure about the Tegra hardware blocks involved. This all seems like it's at the implementation detail level - the bit that seems like we should be able to share it is the big picture bit for how we describe how the AP side stuff and PMIC are hooked up without having to have a bunch of completely non-framework stuff for things like describing the PMIC. I am having a bit of a difficulty trying to understand your concern here. Problem statement: OMAP has this weird custom h/w where one programs the voltage and that voltage is send over i2c - this is not same as Tegra's lookup table array which automatically sends out entries, in OMAP, software has to trigger the voltage transition This path is split into 3 different modules - AVS, VC, VP - This is implementation detail as you already mentioned. Anyhow, to recap, the overview of the hardware interface is as follows: PMIC that OMAP interfaces to are of two categories: a) ones that talk only on the custom OMAP VC path b) ones that talk both custom OMAP VC and regular i2c (e.g. twl4030,6030,palmas) The voltage control for a voltage rail (e.g. vdd_mpu) is again PMIC specific a) 6030 will not allow voltage to be set over regular i2c b) 4030 allows either custom i2c path OR regular i2c path (only 1 at a time). c) palmas allows both custom i2c path AND regular i2c path to set voltage! From a Linux angle, when using regular i2c, it is a piece of cake. Standard regulator uses regular i2c, vc-vp angle avoided Example: Palmas: we'd use the regular palmas driver to do this. When using custom i2c path(vc/vp/avs), it gets a bit complex We'd like (if possible) drivers like cpufreq to be ignorant of regulator and transfer path used ofcourse as this depends on the board component selection. E.g. 4030/palmas/6030 vdd_mpu can be represented as a regulator, which in turn uses custom OMAP data transfer path to set voltage I was trying to understand your statement as to what Paul was doing (which was basically pull out the vsel values and put them in his hardware lookup table for h/w to auto send the voltage) Vs what I was attempting to do (describe OMAP's view of the PMIC and provide data path). In my view, we were trying to do voltage scale in two completely different ways depending on the SoC we were working on. If your concern was describing PMIC parameters in dts, I can easily move them inside the omap_pmic driver and provide required compatible flags. If, on the other hand, the entire approach followed is flawed, I'd like to understand the rationale for the same. -- Regards, Nishanth Menon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH 1/4] regulator: Introduce OMAP regulator to control PMIC over VC/VP
On 15:47-20130613, Mark Brown wrote: On Thu, Jun 13, 2013 at 08:39:50AM -0500, Nishanth Menon wrote: I am having a bit of a difficulty trying to understand your concern here. Your device tree for this stuff appears to mostly consist of repeating the description of the PMIC that we already have - this really doesn't seem like a great result. Problem statement: OMAP has this weird custom h/w where one programs the voltage and that voltage is send over i2c - this is not same as Tegra's lookup table array which automatically sends out entries, in OMAP, software has to trigger the voltage transition The basic idea that's important here is that you need to figure out how to tell the hardware what to write - how those writes get triggered is a separate problem. If your concern was describing PMIC parameters in dts, I can easily move them inside the omap_pmic driver and provide required compatible flags. If, on the other hand, the entire approach followed is flawed, I'd like to understand the rationale for the same. That's the biggest problem I saw so far but to be honest I've not drilled down too much into the specifics. From my point of view the main thing is how this fits into the frameworks and so on, having the register information in the DT was an alarm flag that suggested the overall approach was a concern. OK. would you be ok with an generic omap_pmic driver if the PMIC specific data set is moved into OF compatible data? I am proposing moving the following into OF match data. ti,i2c-slave-address ti,i2c-voltage-register ti,i2c-command-register ti,slew-rate-microvolt ti,step-size-micro-volts ti,voltage-selector-set-bits ti,voltage-selector-mask ti,voltage-selector-offset ti,non-zero-voltage-selector The only thing I propose to retain is board specific variations - e.g. gpios, boot voltage and standard regulator min,max overrides if any. I can also do voltage selector based operations while at it. -- Regards, Nishanth Menon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH 1/4] regulator: Introduce OMAP regulator to control PMIC over VC/VP
On Thu, Jun 13, 2013 at 10:07 AM, Mark Brown broo...@kernel.org wrote: On Thu, Jun 13, 2013 at 09:58:03AM -0500, Nishanth Menon wrote: I am proposing moving the following into OF match data. ti,i2c-slave-address ti,i2c-voltage-register ti,i2c-command-register ti,slew-rate-microvolt ti,step-size-micro-volts ti,voltage-selector-set-bits ti,voltage-selector-mask ti,voltage-selector-offset ti,non-zero-voltage-selector The only thing I propose to retain is board specific variations - e.g. gpios, boot voltage and standard regulator min,max overrides if any. I can also do voltage selector based operations while at it. OK, this sounds like a step in the right direction. Thanks for the review and guidance. I will post a new RFC series with the above changes in a day or so. Regards, Nishanth Menon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH 1/4] regulator: Introduce OMAP regulator to control PMIC over VC/VP
+Paul. On Mon, Jun 10, 2013 at 5:31 AM, Mark Brown broo...@kernel.org wrote: On Wed, May 22, 2013 at 01:18:34PM -0500, Nishanth Menon wrote: So, the biggest problem here has been patch 4 (having to have a hack to deploy this stuff is a bit worrying) plus the general not having a real driver thing. Patch #4 in this series was a hack as it was not properly split up and organized as a proper DTS series -it was meant as a proof of concept - not entirely meant to indicate the remaining 1-3 patches were hacks :). +- ti,i2c-slave-address - I2C slave address of the PMIC +- ti,i2c-voltage-register - I2C register address where voltage commands are + to be set. +- ti,i2c-command-register - I2C register address where commands are to be set + when OMAP enters low power state. This may be the same as + ti,i2c-voltage-register depending on the PMIC. +- ti,slew-rate-microvolt - worst case slew rate of rise / fall for voltage + transition in microvolts per microseconds (uV/uS) +- step-size-micro-volts - Step size in micovolts as to what one step in voltage + selector increment translates to. See example. +- regulator-min-microvolt - Minimum voltage in microvolts which is supported by + the PMIC in ti,step-size-microvolt increments. See example. +- regulator-max-microvolt - Maximum voltage in microvolts which is supported + by the PMIC in ti,step-size-microvolt increments. See example. The other thing is this whole business of encoding the properties of the PMIC in the DT like this. Paul Walmsley has started doing some work for some similiar hardware where instead of doing this the regulator is in the DT as normal and then the driver for the offloaded voltage scaling gets the information about the register layout from the regulator driver. This is a bit neater overall and would cope with determining which method to use at runtime. I think you mean http://marc.info/?t=13705924913r=1w=2 series. I will dig into it. if it is possible for Tegra and OMAP to use the same framework and strategy to deal with these kind of h/w blocks, all the more better. Regards, Nishanth Menon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH 1/4] regulator: Introduce OMAP regulator to control PMIC over VC/VP
On Mon, Jun 10, 2013 at 11:49 AM, Mark Brown broo...@kernel.org wrote: On Mon, Jun 10, 2013 at 11:16:59AM -0500, Nishanth Menon wrote: On Mon, Jun 10, 2013 at 5:31 AM, Mark Brown broo...@kernel.org wrote: On Wed, May 22, 2013 at 01:18:34PM -0500, Nishanth Menon wrote: So, the biggest problem here has been patch 4 (having to have a hack to deploy this stuff is a bit worrying) plus the general not having a real driver thing. Patch #4 in this series was a hack as it was not properly split up and organized as a proper DTS series -it was meant as a proof of concept - not entirely meant to indicate the remaining 1-3 patches were hacks :). The way it reads is that you're building up to a hack - if what you've done isn't enabling a sensible solution there might be a problem with the earlier steps. Understood, I should have taken extra steps to split up the patch into it's logical series, but wanted to get a quick feel from community about the approach before spending time on it. I apologize for the confusion caused. I think you mean http://marc.info/?t=13705924913r=1w=2 series. I will dig into it. if it is possible for Tegra and OMAP to use the same framework and strategy to deal with these kind of h/w blocks, all the more better. Not just better, if each system doing this sort of thing needs to reinvent the wheel something is going wrong. Fair enough, I did spend a short while digging through the discussion in the series, I need to find Tegra TRM to see if there is commonolity between OMAP and what Tegra does at hardware level. a) Tegra seems to use Lookup Table for sending predefinied voltage values to PMIC. OMAP has no concept of lookup table. b) Tegra and OMAP h/w blocks seem to use I2C - that is good. c) How about the i2c slave and register addresses, slew rates, start, end voltages, max voltages that SoC can support etc, I am yet to understand those. d) OMAP has 3 modules - AVS (SmartReflex), Voltage Processor(VP), Voltage Controller(VC) - I am not yet sure about the Tegra hardware blocks involved. maybe Paul could comment as well, I suppose if we could take a common approach between Tegra and OMAP. Regards, Nishanth Menon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH 0/4] 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-rfc This depends on a few patches for cpufreq/clock node i added in, merged with 3.10-rc2 master and a intermediate GPIO fix from Dan that I picked up available in 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=13680400841r=1w=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. example patch for 4430 sdp: http://pastebin.com/SkAGB273 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 Nishanth Menon (4): 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 HACK: OMAP4460/TPS/TWL/PandaBoardES - Enable VP regulator for cpufreq .../devicetree/bindings/power/omap-vc.txt | 99 ++ .../devicetree/bindings/power/omap-vp.txt | 39 + .../bindings/regulator/omap-pmic-regulator.txt | 121 ++ arch/arm/boot/dts/omap4-panda-es.dts | 55 +- arch/arm/boot/dts/omap4.dtsi | 84 ++ arch/arm/boot/dts/omap4460.dtsi|1 + arch/arm/boot/dts/tps62361.dtsi| 90 ++ arch/arm/boot/dts/twl6030.dtsi | 68 + drivers/power/avs/Kconfig | 15 + drivers/power/avs/Makefile | 20 + drivers/power/avs/omap_vc.c| 1508 drivers/power/avs/omap_vc.h| 67 + drivers/power/avs/omap_vp.c| 886 drivers/regulator/Kconfig | 12 + drivers/regulator/Makefile |1 + drivers/regulator/omap-pmic-regulator.c| 554 +++ include/linux/regulator/omap-pmic-regulator.h | 147
[RFC PATCH 4/4] HACK: OMAP4460/TPS/TWL/PandaBoardES - Enable VP regulator for cpufreq
This is just an example patch - Tested on PandaBoard-ES OMAP4460
Connectivity is as follows:
VP_MPU - VC_CH_MPU - VC - TPS62361
TPS62631 Voltage register selection is done using GPIO (GPIO_WK 7)
VP_IVA - VC_CH_IVA - VC - TWL6030/vcore2
VP_CORE - VC_CH_CORE - VC - TWL6030/vcore1
NOT-Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/omap4-panda-es.dts | 55 +++--
arch/arm/boot/dts/omap4.dtsi | 84 +++
arch/arm/boot/dts/omap4460.dtsi |1 +
arch/arm/boot/dts/tps62361.dtsi | 90 ++
arch/arm/boot/dts/twl6030.dtsi | 68 +
5 files changed, 294 insertions(+), 4 deletions(-)
create mode 100644 arch/arm/boot/dts/tps62361.dtsi
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index 08d2e38..71aa5f3 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -43,10 +43,18 @@
};
};
-led_wkgpio_pins {
- pinctrl-single,pins =
- 0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
- ;
+omap4_pmx_wkup {
+ led_wkgpio_pins: pinmux_leds_wkpins {
+ pinctrl-single,pins =
+ 0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
+ ;
+ };
+
+ tps62361_wkgpio_pins: pinmux_tps62361_wkpins {
+ pinctrl-single,pins =
+ 0x1a 0xa03 /* gpio_wk7 OUTPUT | MODE 3 |OFF_HI */
+ ;
+ };
};
leds {
@@ -68,3 +76,42 @@
linux,default-trigger = mmc0;
};
};
+
+#define TPS62361_PD_VSEL0
+#include tps62361.dtsi
+
+/* Board Specific configuration */
+omap_tps62361 {
+ pinctrl-names = default;
+ pinctrl-0 =
+ tps62361_wkgpio_pins
+ ;
+ gpios = gpio1 7 1; /* gpio_wk7 Set to HIGH */
+
+ ti,boot-voltage-micro-volts=1203000;
+ ti,vp=vp_mpu;
+};
+
+omap_twl6030_vcore1 {
+ ti,boot-voltage-micro-volts=120;
+ ti,vp=vp_core;
+};
+
+omap_twl6030_vcore2 {
+ ti,boot-voltage-micro-volts=120;
+ ti,vp = vp_iva;
+};
+
+omap_twl6030_vcore3 {
+ status = disabled;
+};
+
+vc_mpu {
+ /* Due to potential lifetime impact, OFF voltage is set to RET V: TPS*/
+ ti,off-micro-volts = 75;
+};
+
+vc {
+ ti,i2c-high-speed;
+ ti,i2c-pad-load=3;
+};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 1c6d969..b9fd360 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -108,6 +108,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;
@@ -667,5 +672,84 @@
ram-bits = 12;
ti,has-mailbox;
};
+
+ vc: vc@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;
+ ti,retention-micro-volts = 75;
+ ti,off-micro-volts = 0;
+ };
+
+ vc_iva: vc_iva {
+ compatible = ti,omap4-vc-channel-iva;
+ ti,retention-micro-volts = 75;
+ ti,off-micro-volts = 0;
+ };
+
+ vc_core: vc_core {
+ compatible = ti,omap4-vc-channel-core;
+ ti,retention-micro-volts = 75;
+ ti,off-micro-volts = 0;
+ };
+ };
+
+ vp_mpu: vp@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 = 1;
+ ti,max-step-micro-volts = 5;
+ /* HACKs: belongs to SoC specific file */
+ ti,min-micro-volts = 75;
+ ti,max-micro-volts = 141;
+ };
+
+ vp_iva: vp@0x4a307b70
[RFC PATCH 3/4] PM / AVS: Introduce support for OMAP Voltage Processor(VP) with device tree nodes
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.
[grygorii.stras...@ti.com: co-developer]
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
.../devicetree/bindings/power/omap-vp.txt | 39 +
drivers/power/avs/Makefile |2 +-
drivers/power/avs/omap_vp.c| 886
3 files changed, 926 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/power/omap-vp.txt
create mode 100644 drivers/power/avs/omap_vp.c
diff --git a/Documentation/devicetree/bindings/power/omap-vp.txt
b/Documentation/devicetree/bindings/power/omap-vp.txt
new file mode 100644
index 000..b690e35
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/omap-vp.txt
@@ -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@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 = 1;
+ ti,max-step-micro-volts = 5;
+ ti,min-micro-volts = 75;
+ ti,max-micro-volts = 141;
+};
diff --git a/drivers/power/avs/Makefile b/drivers/power/avs/Makefile
index 95d5f59..535cab5 100644
--- a/drivers/power/avs/Makefile
+++ b/drivers/power/avs/Makefile
@@ -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),)
diff --git a/drivers/power/avs/omap_vp.c b/drivers/power/avs/omap_vp.c
new file mode 100644
index 000..b6a155d
[RFC PATCH 1/4] regulator: Introduce OMAP regulator to control PMIC over VC/VP
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. [grygorii.stras...@ti.com: co-developer] Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com Signed-off-by: Nishanth Menon n...@ti.com --- .../bindings/regulator/omap-pmic-regulator.txt | 121 + drivers/regulator/Kconfig | 12 + drivers/regulator/Makefile |1 + drivers/regulator/omap-pmic-regulator.c| 554 include/linux/regulator/omap-pmic-regulator.h | 147 ++ 5 files changed, 835 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 diff --git a/Documentation/devicetree/bindings/regulator/omap-pmic-regulator.txt b/Documentation/devicetree/bindings/regulator/omap-pmic-regulator.txt new file mode 100644 index 000..b87dd3c --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/omap-pmic-regulator.txt @@ -0,0 +1,121 @@ +Generic Power Management IC(PMIC) Regulator for Texas Instruments OMAP SoCs + +Required Properties: +- compatible: Should be: + - ti,omap-pmic + +- ti,i2c-slave-address - I2C slave address of the PMIC +- ti,i2c-voltage-register - I2C register address where voltage commands are + to be set. +- ti,i2c-command-register - I2C register address where commands are to be set + when OMAP enters low power state. This may be the same as + ti,i2c-voltage-register depending on the PMIC. +- ti,slew-rate-microvolt - worst case slew rate of rise / fall for voltage + transition in microvolts per microseconds (uV/uS) +- step-size-micro-volts - Step size in micovolts as to what one step
[RFC PATCH 2/4] PM / AVS: Introduce support for OMAP Voltage Controller(VC) with device tree nodes
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. [grygorii.stras...@ti.com: co-developer] Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com Signed-off-by: Nishanth Menon n...@ti.com --- .../devicetree/bindings/power/omap-vc.txt | 99 ++ drivers/power/avs/Kconfig | 15 + drivers/power/avs/Makefile | 20 + drivers/power/avs/omap_vc.c| 1508 drivers/power/avs/omap_vc.h| 67 + 5 files changed, 1709 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 diff --git a/Documentation/devicetree/bindings/power/omap-vc.txt b/Documentation/devicetree/bindings/power/omap-vc.txt new file mode 100644 index 000..f97737c --- /dev/null +++ b/Documentation/devicetree/bindings/power/omap-vc.txt @@ -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
Re: [PATCH v5] ARM:dts:omap4-panda: Update the LED support for the panda DTS
On 08:21-20130517, Dan Murphy wrote:
[...]
May be others with better DT experience can help here..
but here is a trick to reduce dts file changes:
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index f1d8c21..08d2e38 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -34,3 +34,37 @@
0x5e 0x100 /* hdmi_sda.hdmi_sda INPUT | MODE 0 */
;
};
+
+omap4_pmx_core {
+ led_gpio_pins: gpio_led_pmx {
+ pinctrl-single,pins =
+ 0xb6 0x3/* gpio_110 OUTPUT | MODE 3 */
+ ;
+ };
+};
+
+led_wkgpio_pins {
+ pinctrl-single,pins =
+ 0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
+ ;
+};
+
+leds {
+ compatible = gpio-leds;
+ pinctrl-names = default;
Normally, override will either add (if new param) OR replace (if same param)
So the above two are superfluous.
+ pinctrl-0 =
+ led_gpio_pins
+ led_wkgpio_pins
+ ;
These are needed
+
+ heartbeat {
+ label = pandaboard::status1;
can drop this
+ gpios = gpio4 14 0;
needed
+ linux,default-trigger = heartbeat;
can be dropped
+ };
+ mmc {
+ label = pandaboard::status2;
could be dropped
+ gpios = gpio1 8 0;
needed
+ linux,default-trigger = mmc0;
could be dropped.
--
Regards,
Nishanth Menon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4] ARM:dts:omap4-panda: Update the LED support for the panda DTS
On Thu, May 16, 2013 at 10:35 AM, Dan Murphy dmur...@ti.com wrote: I am not sure you really want to do this. If I make the pinctrl part of the led structure then the only way the gpio_wk7 on a1-a3 to be configured is when the CONFIG_LEDS_GPIO flag is set. Do you really want that dependency? You did say it was a key fix At least this way the pins are configured regardless of that flag. That is better as the system will be left in the pinmux configuration handed over from bootloader. The point being, muxing up pins even when not needed(config switched off) has no real benefit - in this case albeit, the default mux was causing a bug. pinctrl IMHO should be considered as any other resource, if it is not mandatory for boot, and needed only for a device functionality when probed, it should done there only. just my 2 cents. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4] ARM:dts:omap4-panda: Update the LED support for the panda DTS
On 11:46-20130515, Dan Murphy wrote:
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
A1-A3 = gpio_wk7
ES = gpio_110
There is no change to LED D2
Abstract away the pinmux and the LED definitions for the two boards into
the respective DTS files.
Signed-off-by: Dan Murphy dmur...@ti.com
---
nit: Giving patch history is a nice practise.
arch/arm/boot/dts/omap4-panda-common.dtsi | 16 +++-
arch/arm/boot/dts/omap4-panda-es.dts | 40
+
2 files changed, 55 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 03bd60d..2b516af 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -16,7 +16,7 @@
reg = 0x8000 0x4000; /* 1 GB */
};
- leds {
+ leds: leds {
compatible = gpio-leds;
heartbeat {
label = pandaboard::status1;
@@ -137,6 +137,20 @@
I missed noticing this previously, Apologies on the same.
Considering that drivers/leds/leds-gpio.c has ability to handle pinctrl,
One better option might be to provide pinctrl phandle with leds -
Couple of reasons why this might be good:
a) one gets the following warning at boot:
leds-gpio leds.8: pins are not configured from the driver
b) you donot need to setup the pins by default at boot - it is not
mandatory for the system functionality, instead we do it *if* the driver
is enabled.
Further, optionally, all you'd have to do in panda-es.dts is the following
led_wkgpio_pins {
pinctrl-single,pins =
0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
;
}
Similarly for gpios override for panda-es.
};
};
+omap4_pmx_wkup {
+ pinctrl-names = default;
+ pinctrl-0 =
+ led_wkgpio_pins
+ ;
+
+ led_wkgpio_pins: pinmux_leds_wkpins {
+ pinctrl-single,pins =
+ 0x1a 0x3/* gpio_wk7 OUTPUT | MODE 3 */
+ 0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
+ ;
+ };
+};
+
i2c1 {
pinctrl-names = default;
pinctrl-0 = i2c1_pins;
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index f1d8c21..e6f696d 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -34,3 +34,43 @@
0x5e 0x100 /* hdmi_sda.hdmi_sda INPUT | MODE 0 */
;
};
+
+leds {
+ compatible = gpio-leds;
+ heartbeat {
+ label = pandaboard::status1;
+ gpios = gpio4 14 0;
+ linux,default-trigger = heartbeat;
+ };
+ mmc {
+ label = pandaboard::status2;
+ gpios = gpio1 8 0;
+ linux,default-trigger = mmc0;
+ };
+};
+
+omap4_pmx_core {
+ pinctrl-names = default;
+ pinctrl-0 =
+ led_gpio_pins
+ ;
+
+ led_gpio_pins: gpio_led_pmx {
+ pinctrl-single,pins =
+ 0xb6 0x3/* gpio_110 OUTPUT | MODE 3 */
+ ;
+ };
+};
+
+omap4_pmx_wkup {
+ pinctrl-names = default;
+ pinctrl-0 =
+ led_wkgpio_pins
+ ;
+
+ led_wkgpio_pins: pinmux_leds_wkpins {
+ pinctrl-single,pins =
+ 0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
+ ;
+ };
+};
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Regards,
Nishanth Menon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3] ARM:dts:omap4-panda:Update the LED support for the panda DTS
$subject - add a space?
s/ARM:dts:omap4-panda:Update/ARM: dts: omap4-panda: Update/ ?
On 09:17-20130514, Dan Murphy wrote:
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
A1-A3 = gpio_wk7
Thanks for fixing this - this is a key fix else, GPIO_7 which controls
VSEL for VDD_MPU on PandaBoard-ES will create all kind of ruckus (change
voltage on heartbeat)!
ES = gpio_110
There is no change to LED D2
Abstract away the pinmux and the LED definitions for the two boards into
the respective DTS files.
Signed-off-by: Dan Murphy dmur...@ti.com
---
[...]
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index f1d8c21..8d1ba03 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -34,3 +34,43 @@
0x5e 0x100 /* hdmi_sda.hdmi_sda INPUT | MODE 0 */
;
};
+
+leds {
+ compatible = gpio-leds;
+ heartbeat {
+ label = pandaboard::status1;
+ gpios = gpio4 14 0;
+ linux,default-trigger = heartbeat;
+ };
+ mmc {
+ label = pandaboard::status2;
+ gpios = gpio1 8 0;
+ linux,default-trigger = gpio;
mmc0?
+ };
+};
+
Other that that,
Tested-by: Nishanth Menon n...@ti.com
--
Regards,
Nishanth Menon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 1/5] regulator: Introduce TI Adaptive Body Bias(ABB) on-chip LDO driver
Hi Mark, On 10:02-20130503, Mark Brown wrote: On Thu, May 02, 2013 at 12:20:10PM -0500, Nishanth Menon wrote: From: Andrii.Tseglytskyi andrii.tseglyts...@ti.com Adaptive Body Biasing (ABB) modulates transistor bias voltages dynamically in order to optimize switching speed versus leakage. I've applied this but please note that I still have deep concerns about some of the discussion about controlling this from other regulators. Thanks for the merge. We don't have any further plans of pursuing the concept of regulator chaining for upstream. After an off-line chat with Mike T, we are planning on introducing OMAP specific notifier hooks to clock framework. This should allow us to do the appropriate sequencing necessary to control AVS, regulators for ABB and PMIC in the right sequence. -- Regards, Nishanth Menon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 4/5] ARM: dts: OMAP4460: Add device nodes for ABB
From: Andrii.Tseglytskyi andrii.tseglyts...@ti.com
Add ABB device nodes for OMAP4460 device Data is based on OMAP4460
Technical Reference Manual revision Z (April 2013)
[n...@ti.com: co-developer]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Andrii.Tseglytskyi andrii.tseglyts...@ti.com
---
arch/arm/boot/dts/omap4460.dtsi | 38 ++
1 file changed, 38 insertions(+)
diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
index 2cf227c..e854c41 100644
--- a/arch/arm/boot/dts/omap4460.dtsi
+++ b/arch/arm/boot/dts/omap4460.dtsi
@@ -29,4 +29,42 @@
0 55 0x4;
ti,hwmods = debugss;
};
+
+ ocp {
+ abb_mpu: regulator-abb-mpu {
+ status = okay;
+
+ reg = 0x4a307bd0 0x8, 0x4a306014 0x4,
+ 0x4A002268 0x4;
+ reg-names = base-address, int-address,
+ efuse-address;
+
+ ti,abb_info =
+ /*uVABB efuse rbb_m fbb_m vset_m*/
+ 1025000 0 0 0 0 0
+ 120 0 0 0 0 0
+ 1313000 0 0 0x10 0x4 0
+ 1375000 1 0 0 0 0
+ 1389000 1 0 0 0 0
+ ;
+ };
+
+ abb_iva: regulator-abb-iva {
+ status = okay;
+
+ reg = 0x4a307bd8 0x8, 0x4a306010 0x4,
+ 0x4A002268 0x4;
+ reg-names = base-address, int-address,
+ efuse-address;
+
+ ti,abb_info =
+ /*uVABB efuse rbb_m fbb_m vset_m*/
+ 95 0 0 0 0 0
+ 114 0 0 0 0 0
+ 1291000 0 0 0x20 0 0
+ 1375000 1 0 0 0 0
+ 1376000 1 0 0 0 0
+ ;
+ };
+ };
};
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 3/5] ARM: dts: OMAP443x: Add device nodes for ABB
From: Andrii.Tseglytskyi andrii.tseglyts...@ti.com
Add ABB device nodes for OMAP443x family of devices. abb_iva is
populated, but disabled as it is not used on current OMAP443x family,
but the node is used on OMAP446x family. Data is based on OMAP443x
Technical Reference Manual revision AN (April 2013).
[n...@ti.com: co-developer]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Andrii.Tseglytskyi andrii.tseglyts...@ti.com
---
arch/arm/boot/dts/omap4.dtsi| 32
arch/arm/boot/dts/omap443x.dtsi | 26 ++
2 files changed, 58 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 1c6d969..8f6a1fb 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -108,6 +108,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;
@@ -667,5 +672,32 @@
ram-bits = 12;
ti,has-mailbox;
};
+
+ abb_mpu: regulator-abb-mpu {
+ compatible = ti,abb-v2;
+ regulator-name = abb_mpu;
+ #address-cells = 0;
+ #size-cells = 0;
+ ti,tranxdone-status-mask = 0x80;
+ clocks = sysclk_in;
+ ti,settling-time = 50;
+ ti,clock-cycles = 16;
+
+ status = disabled;
+ };
+
+ abb_iva: regulator-abb-iva {
+ compatible = ti,abb-v2;
+ regulator-name = abb_iva;
+ #address-cells = 0;
+ #size-cells = 0;
+ ti,tranxdone-status-mask = 0x8000;
+ clocks = sysclk_in;
+ ti,settling-time = 50;
+ ti,clock-cycles = 16;
+
+ status = disabled;
+ };
+
};
};
diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index cccf39a..377e519 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -24,4 +24,30 @@
clock-latency = 30; /* From legacy driver */
};
};
+
+ ocp {
+ abb_mpu: regulator-abb-mpu {
+ status = okay;
+
+ reg = 0x4a307bd0 0x8, 0x4a306014 0x4;
+ reg-names = base-address, int-address;
+
+ ti,abb_info =
+ /*uVABB efuse rbb_m fbb_m vset_m*/
+ 1025000 0 0 0 0 0
+ 120 0 0 0 0 0
+ 1313000 0 0 0 0 0
+ 1375000 1 0 0 0 0
+ 1389000 1 0 0 0 0
+ ;
+ };
+
+ /* Default unused, just provide register info for record */
+ abb_iva: regulator-abb-iva {
+ reg = 0x4a307bd8 0x8, 0x4a306010 0x4;
+ reg-names = base-address, int-address;
+ };
+
+ };
+
};
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 2/5] ARM: dts: OMAP36xx: Add device node for ABB
From: Andrii.Tseglytskyi andrii.tseglyts...@ti.com
Add ABB device node for OMAP36xx family of devices. Data is based on
OMAP36XX Technical Reference Manual revision AB (Dec 2012).
[n...@ti.com: co-developer]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Andrii.Tseglytskyi andrii.tseglyts...@ti.com
---
arch/arm/boot/dts/omap3.dtsi|5 +
arch/arm/boot/dts/omap36xx.dtsi | 20
2 files changed, 25 insertions(+)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 58c6ed6..5d97201 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -75,6 +75,11 @@
ti,hwmods = counter_32k;
};
+ sysclk: sys {
+ #clock-cells = 0;
+ compatible = ti,omap-clock;
+ };
+
dpll1: dpll1 {
#clock-cells = 0;
compatible = ti,omap-clock;
diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
index f3447bc..38cdcb0 100644
--- a/arch/arm/boot/dts/omap36xx.dtsi
+++ b/arch/arm/boot/dts/omap36xx.dtsi
@@ -34,5 +34,25 @@
ti,hwmods = uart4;
clock-frequency = 4800;
};
+
+ abb_mpu_iva: regulator-abb-mpu {
+ compatible = ti,abb-v1;
+ regulator-name = abb_mpu_iva;
+ #address-cell = 0;
+ #size-cells = 0;
+ reg = 0x483072f0 0x8, 0x48306818 0x4;
+ reg-names = base-address, int-address;
+ ti,tranxdone-status-mask = 0x400;
+ clocks = sysclk;
+ ti,settling-time = 30;
+ ti,clock-cycles = 8;
+ ti,abb_info =
+ /*uVABB efuse rbb_m fbb_m vset_m*/
+ 1012500 0 0 0 0 0
+ 120 0 0 0 0 0
+ 1325000 0 0 0 0 0
+ 1375000 1 0 0 0 0
+ ;
+ };
};
};
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 0/5] regulator/OMAP: Support TI Adaptive Body Bias(ABB) on-chip LDO driver
Adaptive Body Biasing (ABB) modulates transistor bias voltages dynamically in order to optimize switching speed versus leakage. Texas Instruments' SoC processors have an on chip LDO subsystem which is part of the SmartReflex 2 technology and provides support for this power management technique with Forward Body Biasing (FBB) and Reverse Body Biasing (RBB). These modulate the body voltage of transistor cells or blocks dynamically to gain performance and reduce leakage. This series introduces ABB regulator and associated data for controlling ABB module on OMAP3630+ TI SoCs. Usage of ABB LDO is part of SoC's OPP voltage transition sequence. We just introduce the regulator in this series for LDO control, however, the actual sequence of control of this regulator is left to the implementation of SoC OPP voltage transition of the appropriate domain. Note: We only support device tree supported boot in this series. Testing and Caveats: - Sanity tested on OMAP3,4,5 platforms - verified with omapconf. - Testing performed with regulator virtual consumer: http://pastebin.com/Knp1fSxA - OMAP5 clock nodes are introduced, but clock data is missing in upstream - tested with private tree with requisite clock nodes introduced. Clock node has been commented out in this series. V3 of this series also available (with testing patch): http link: https://github.com/nmenon/linux-2.6-playground/commits/devel/abb-regulator-v3 git link: git://github.com/nmenon/linux-2.6-playground.git branch: devel/abb-regulator-v3 Changes in V3: - Regulator is purely meant to control ABB LDO. - The regulator chaining for doing voltage scale for entire SoC voltage domain has been dropped. - Debugfs entries meant to expose ABB registers has been dropped as the same functionality can be achieved with readmem like omapconf application. - Re-factored regulator logic to make it simpler using the existing voltage indexing support of regulator framework. - Implemented efuse based detection strategy and provided requisite data to cover all existing OMAPs using ABB. - Depends on OMAP clock driver introduced in: http://marc.info/?t=13658075851r=1w=2 V2: http://marc.info/?t=13660326147r=1w=2n=3 V1/RFC: http://marc.info/?l=linux-omapm=136449099409794w=2 Andrii.Tseglytskyi (5): regulator: Introduce TI Adaptive Body Bias(ABB) on-chip LDO driver ARM: dts: OMAP36xx: Add device node for ABB ARM: dts: OMAP443x: Add device nodes for ABB ARM: dts: OMAP4460: Add device nodes for ABB ARM: dts: OMAP5: Add device nodes for ABB .../bindings/regulator/ti-abb-regulator.txt| 128 +++ arch/arm/boot/dts/omap3.dtsi |5 + arch/arm/boot/dts/omap36xx.dtsi| 20 + arch/arm/boot/dts/omap4.dtsi | 32 + arch/arm/boot/dts/omap443x.dtsi| 26 + arch/arm/boot/dts/omap4460.dtsi| 38 + arch/arm/boot/dts/omap5.dtsi | 67 ++ drivers/regulator/Kconfig | 10 + drivers/regulator/Makefile |1 + drivers/regulator/ti-abb-regulator.c | 912 10 files changed, 1239 insertions(+) create mode 100644 Documentation/devicetree/bindings/regulator/ti-abb-regulator.txt create mode 100644 drivers/regulator/ti-abb-regulator.c -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 5/5] ARM: dts: OMAP5: Add device nodes for ABB
From: Andrii.Tseglytskyi andrii.tseglyts...@ti.com
Add ABB device nodes for OMAP5 family of devices. Data is based on
OMAP543x Technical Reference Manual revision U (April 2013).
NOTE: clock node has been disabled in this patch due to the lack of
OMAP5 clock data.
[n...@ti.com: co-developer]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Andrii.Tseglytskyi andrii.tseglyts...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 67 ++
1 file changed, 67 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 3dd7ff8..a9d86d2 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -667,5 +667,72 @@
ctrl-module = omap_control_usb;
};
};
+
+ abb_mpu: regulator-abb-mpu {
+ compatible = ti,abb-v2;
+ regulator-name = abb_mpu;
+ #address-cells = 0;
+ #size-cells = 0;
+ /* clocks = sysclk_in; - once we have clock data */
+ ti,settling-time = 50;
+ ti,clock-cycles = 16;
+
+ reg = 0x4ae07cdc 0x8, 0x4ae06014 0x4,
+ 0x4a0021ac 0x18, 0x4ae0C318 0x4;
+ reg-names = base-address, int-address,
+ efuse-address, ldo-address;
+ ti,tranxdone-status-mask = 0x80;
+ /* LDOVBBMPU_MUX_CTRL */
+ ti,ldovbb-override-mask = 0x400;
+ /* LDOVBBMPU_VSET_OUT */
+ ti,ldovbb-vset-mask = 0x1F;
+
+ /*
+* NOTE: only FBB mode used but actual vset will
+* determine final biasing
+*/
+ ti,abb_info =
+ /*uVABB efuse rbb_m fbb_m vset_m*/
+ 88 0 0x4 0 0x2000 0x1F00
+ 106 0 0x8 0 0x2000 0x1F00
+ 125 0 0x100 0x2000 0x1F00
+ 126 1 0x140 0x2000 0x1F00
+ ;
+
+ status = disabled;
+ };
+
+ abb_mm: regulator-abb-mm {
+ compatible = ti,abb-v2;
+ regulator-name = abb_iva;
+ #address-cells = 0;
+ #size-cells = 0;
+ /* clocks = sysclk_in; - once we have clock data */
+ ti,settling-time = 50;
+ ti,clock-cycles = 16;
+
+ reg = 0x4ae07ce4 0x8, 0x4ae06010 0x4,
+ 0x4a002194 0x14, 0x4ae0C314 0x4;
+ reg-names = base-address, int-address,
+ efuse-address, ldo-address;
+ ti,tranxdone-status-mask = 0x8000;
+ /* LDOVBBMM_MUX_CTRL */
+ ti,ldovbb-override-mask = 0x400;
+ /* LDOVBBMM_VSET_OUT */
+ ti,ldovbb-vset-mask = 0x1F;
+
+ /*
+* NOTE: only FBB mode used but actual vset will
+* determine final biasing
+*/
+ ti,abb_info =
+ /*uVABB efuse rbb_m fbb_m vset_m*/
+ 88 0 0x4 0 0x2000 0x1F00
+ 1025000 0 0x8 0 0x2000 0x1F00
+ 112 1 0x100 0x2000 0x1F00
+ ;
+
+ status = disabled;
+ };
};
};
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 1/5] regulator: Introduce TI Adaptive Body Bias(ABB) on-chip LDO driver
From: Andrii.Tseglytskyi andrii.tseglyts...@ti.com Adaptive Body Biasing (ABB) modulates transistor bias voltages dynamically in order to optimize switching speed versus leakage. Texas Instruments' SmartReflex 2 technology provides support for this power management technique with Forward Body Biasing (FBB) and Reverse Body Biasing (RBB). These modulate the body voltage of transistor cells or blocks dynamically to gain performance and reduce leakage. TI's SmartReflex white paper[1] has further information for usage in conjunction with other power management techniques. The application of FBB/RBB technique is determined for each unique device in some process nodes, whereas, they are mandated on other process nodes. In a nutshell, ABB technique is implemented on TI SoC as an on-chip LDO which has ABB module controlling the bias voltage. However, the voltage is unique per device. These vary per SoC family and the manner in which these techniques are used may vary depending on the Operating Performance Point (OPP) voltage targeted. For example: OMAP3630/OMAP4430: certain OPPs mandate usage of FBB independent of devices. OMAP4460/OMAP4470: certain OPPs mandate usage of FBB, while others may optionally use FBB or optimization with RBB. OMAP5: ALL OPPs may optionally use ABB, and ABB biasing voltage is influenced by vset fused in s/w and requiring s/w override of default values. Further, two generations of ABB module are used in various TI SoCs. They have remained mostly register field compatible, however the register offset had switched between versions. We introduce ABB LDO support in the form of a regulator which is controlled by voltages denoting the desired Operating Performance Point which is targeted. However, since ABB transition is part of OPP change sequence, the sequencing required to ensure sane operation w.r.t OPP change is left to the controlling driver (example: cpufreq SoC driver) using standard regulator operations. The driver supports all ABB modes and ability to override ABB LDO vset control efuse based ABB mode detection etc. Current implementation is heavily influenced by the original patch series [2][3] from Mike Turquette. However, the current implementation supports only device tree based information. [1] http://www.ti.com/pdfs/wtbu/smartreflex_whitepaper.pdf [2] http://marc.info/?l=linux-omapm=134931341818379w=2 [3] http://marc.info/?l=linux-arm-kernelm=134931402406853w=2 [n...@ti.com: co-developer] Signed-off-by: Nishanth Menon n...@ti.com Signed-off-by: Andrii.Tseglytskyi andrii.tseglyts...@ti.com --- V2: http://marc.info/?l=linux-omapm=136611169104414w=2 V1: http://marc.info/?l=linux-omapm=13648105843w=2 .../bindings/regulator/ti-abb-regulator.txt| 128 +++ drivers/regulator/Kconfig | 10 + drivers/regulator/Makefile |1 + drivers/regulator/ti-abb-regulator.c | 912 4 files changed, 1051 insertions(+) create mode 100644 Documentation/devicetree/bindings/regulator/ti-abb-regulator.txt create mode 100644 drivers/regulator/ti-abb-regulator.c diff --git a/Documentation/devicetree/bindings/regulator/ti-abb-regulator.txt b/Documentation/devicetree/bindings/regulator/ti-abb-regulator.txt new file mode 100644 index 000..2e57a33 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/ti-abb-regulator.txt @@ -0,0 +1,128 @@ +Adaptive Body Bias(ABB) SoC internal LDO regulator for Texas Instruments SoCs + +Required Properties: +- compatible: Should be one of: + - ti,abb-v1 for older SoCs like OMAP3 + - ti,abb-v2 for newer SoCs like OMAP4, OMAP5 +- 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 ABB module + - int-address - contains address of interrupt register for ABB module + (also see Optional properties) +- #address-cell: should be 0 +- #size-cell: should be 0 +- clocks: should point to the clock node used by ABB module +- ti,settling-time: Settling time in uSecs from SoC documentation for ABB module + to settle down(target time for SR2_WTCNT_VALUE). +- ti,clock-cycles: SoC specific data about count of system ti,clock-cycles used for + computing settling time from SoC Documentation for ABB module(clock + cycles for SR2_WTCNT_VALUE). +- ti,tranxdone-status-mask: Mask to the int-register to write-to-clear mask + indicating LDO tranxdone (operation complete). +- ti,abb_info: An array of 6-tuples u32 items providing information about ABB + configuration needed per operational voltage of the device. + Each item consists of the following in the same order: + volt: voltage in uV - Only used to index ABB information. + ABB mode: one of the following: + 0-bypass + 1
Re: [PATCH 1/2] PM / OPP: add support to specify phandle of another node for OPP
;
}
@@ -741,5 +745,15 @@ int of_init_opp_table(struct device *dev)
return 0;
}
missing EOL?
+/**
+ * of_init_opp_table() - Initialize opp table from device tree
+ * @dev: device pointer used to lookup device OPPs.
+ *
+ * Register the initial OPP table with the OPP library for given device.
+ */
+int of_init_opp_table(struct device *dev)
+{
+ return of_init_opp_table_from_ofnode(dev, dev-of_node);
+}
EXPORT_SYMBOL_GPL(of_init_opp_table);
#endif
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-pm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Regards,
Nishanth Menon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/2] PM / OPP: check for existing OPP list when initialising from device tree
On 12:11-20130501, sudeep.karkadanage...@arm.com wrote: From: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com CPUs are registered as devices and their OPPs can be initialised from the device tree. Whenever CPUs can be hotplugged out, the corresponding cpu devices are not removed. As a result all their OPPs remain intact even when they are offlined. But when they are hotplugged back-in, the cpufreq along with other cpu related subsystem gets re-initialised. Since its almost same as secondary cpu being brought up, no special consideration is taken in the hotplug path. As a result of this the cpufreq will try to initialise the OPPs again though the cpu device already contains the OPPs. This patch checks if there exist an OPP list associated with the device, before attempting to initialise it. Signed-off-by: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com --- drivers/base/power/opp.c |5 + 1 file changed, 5 insertions(+) diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c index 4dfdc01..66d52d2 100644 --- a/drivers/base/power/opp.c +++ b/drivers/base/power/opp.c @@ -706,6 +706,11 @@ static int of_init_opp_table_from_ofnode(struct device *dev, const __be32 *val; int nr; + /* Check for existing list for 'dev' */ + dev_opp = find_device_opp(dev); + if (!IS_ERR(dev_opp)) + return 0; /* Device OPP already initialized */ + It gets a little touchy here - the normal expectation is for the OPP entries to be populated onetime at boot. For example - driver bug where same device was attempted twice Vs the usecase you mention here - how'd we differentiate between the two? prop = of_find_property(of_node, operating-points, NULL); if (!prop) return -ENODEV; -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-pm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Regards, Nishanth Menon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/2] PM / OPP: add support to specify phandle of another node for OPP
On 17:28-20130501, Sudeep KarkadaNagesha wrote:
On 01/05/13 15:41, Nishanth Menon wrote:
On 12:11-20130501, sudeep.karkadanage...@arm.com wrote:
From: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
If more than one similar devices share the same OPPs, currently we
need to replicate the OPP entries in all the nodes.
Nice, thanks.
Few drivers like cpufreq depend on physical cpu0 node to specify the
cpufreq-cpu0?
Yes when I originally wrote this patch cpufreq-cpu0 was using cpu0 node.
But later sometimes it was changed to parse all the nodes.
giving an explicit example like cpufreq-cpu0 might be helpful - but we
may have more cases like this else where with co-processors (devfreq
world).
[...]
+a SoC or in a single cluster on a SoC, then we need to avoid replicating
the
+OPPs in all the nodes. We can specify the phandle of the node with which
the
+current node shares the operating points instead.
+
+Examples:
+Consider an SMP with 4 CPUs all sharing the same OPPs.
We might want to descr
I could not get what exactly you mean by 'descr', do you mean more
descriptive ? If so, what exactly you would like to add ?
Arrgh.. Typical of me to forget my reply thread and leave it dangling
when someone interrupts me :( Sigh.. Apologies about that.
I intended the following:
An example of bL might be 4 A15s and 3 a7s? A15s have different
frequencies Vs A7s?
The example below could easily be covered by cpufreq-cpu0 - so an actual
usage illustrated will help.
+
+cpu0: cpu@0 {
+ compatible = arm,cortex-a9;
+ reg = 0;
+ next-level-cache = L2;
+ operating-points =
+ /* kHzuV */
+ 792000 110
+ 396000 95
+ 198000 85
+ ;
+};
+
+cpu1: cpu@1 {
+ compatible = arm,cortex-a9;
+ reg = 1;
+ next-level-cache = L2;
+ operating-points = cpu0;
+};
[...]
{
+ struct device_opp *dev_opp = NULL;
dev_opp is not used until patch #2 - please introduce it in that patch.
Correct it was meant to be in patch#2, will move in next version
I'd hold on to the rev 2 until we are clear that we have precedence for
allowing parameters to have two different formats.
I might optionally go with introducing a new parameter to indicate
phandle lists similar to pinctrl.. Just a thought. There may be other
usage for the same in addition to resolving the scenario you mention.
Trivial example:
cpu0 can take three different operating-point sets -
default - 300MHz, 600MHz, 800MHz
regular performance - 300MHz, 600MHz, 800MHz, 1GHz
performance - 300MHz, 600MHz, 800MHz, 1GHz, 1.7GHz
Choice is made which set it picks up.
making operating-points as a phandle by itself is questionable as it
does not really represent an hardware device - but options for
operation.
--
Regards,
Nishanth Menon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/2] ARM: dts: OMAP36xx: Fix CPU OPP voltages
commit 3027e26 (ARM: dts: OMAP36xx: Add CPU OPP table)
introduced wrong OPP voltages per OPP by mistake. Sync the OPP
tables with existing OMAP36xx OPP data in
arch/arm/mach-omap2/opp3xxx_data.c
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/omap36xx.dtsi |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
index b89233e..f3447bc 100644
--- a/arch/arm/boot/dts/omap36xx.dtsi
+++ b/arch/arm/boot/dts/omap36xx.dtsi
@@ -20,9 +20,9 @@
cpu@0 {
operating-points =
/* kHzuV */
- 30 975000
- 60 1075000
- 80 120
+ 30 1012500
+ 60 120
+ 80 1325000
;
clock-latency = 30; /* From legacy driver */
};
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 0/2] ARM: dts: OMAP36xx/OMAP4460 Fix CPU OPP voltages
Hi, It seems that I have not been paying close attention to actual voltage value seen on scope to map it back to verify the validity of the voltage value. Even though I did verify[1] that voltage did scale to values in DT entries, the values in the case of 3630 and 4460 were lower than what the spec voltage was as per opp_data files. This series is based off Benoit's tree here: http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git/log/?h=for_3.10/dts Commit ID's in the patches to indicate regressions are from there as well. Would be good to have this fix merged to 3.10 dts entries. I have cross verified that OMAP3430,3630,4430 and 4460 entries now match that of corresponding opp*_data.c My sincere apologies on the oversight. Nishanth Menon (2): ARM: dts: OMAP36xx: Fix CPU OPP voltages ARM: dts: OMAP4460: Fix CPU OPP voltages arch/arm/boot/dts/omap36xx.dtsi |6 +++--- arch/arm/boot/dts/omap4460.dtsi |6 +++--- 2 files changed, 6 insertions(+), 6 deletions(-) [1] http://marc.info/?l=linux-arm-kernelm=136580742724210w=2 Regards, Nishanth Menon -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 2/2] ARM: dts: OMAP4460: Fix CPU OPP voltages
commit d16fb25 (ARM: dts: OMAP4460: Add CPU OPP table)
introduced wrong OPP voltages per OPP by mistake. Sync the OPP
tables with existing OMAP4460 OPP data in
arch/arm/mach-omap2/opp4xxx_data.c
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/omap4460.dtsi |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
index 7c2c23c..2cf227c 100644
--- a/arch/arm/boot/dts/omap4460.dtsi
+++ b/arch/arm/boot/dts/omap4460.dtsi
@@ -15,9 +15,9 @@
cpu@0 {
operating-points =
/* kHzuV */
- 35 975000
- 70 1075000
- 92 120
+ 35 1025000
+ 70 120
+ 92 1313000
;
clock-latency = 30; /* From legacy driver */
};
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V4 1/6] clk: OMAP: introduce device tree binding to kernel clock data
On Mon, Apr 15, 2013 at 11:22 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 04/12/2013 04:54 PM, Nishanth Menon wrote: OMAP clock data is located in arch/arm/mach-omap2/cclockXYZ_data.c. However, this presents an obstacle for using these clock nodes in Device Tree definitions. This is especially true for board specific clocks initially. The fixed clocks are currently found via clock aliases table. There are many possible approaches to this problem as discussed in the following thread: http://marc.info/?t=13637032569r=1w=2. Highlights of the options: a) device specific clk_add_alias: cons: driver handling required b) using an generic clk node and indexing to reach the clock required. This is similar in approach taken by tegra and few other platforms. Example usage: clock = clk 5; cons: potential to have mismatches in indexed table and associated dtb data. In addition, managing continued documentation in bindings as clock indexing increases. Even though readability angle could be improved by using preprocessing of DT using macros, indexed approach is inherently risky from cases like the following: clk indexes in kernel: 1 - mpu_dpll 2 - aux_clk1 3 - core_clk DT entry for peripheral X uses clk 2 to reach aux_clk1. Now, let's say kernel updates indices to: 1 - mpu_dpll 2 - per_dpll 3 - aux_clk1 4 - core_clk using the old dtb(or dts missing an update), on new kernel which has updated indices will result in per_dpll now controlled for peripheral X without warning or any potential error detection. Even though we could claim this is user error, such errors are hard to track down and fix. The error in case (b) is that you shouldn't be changing the DT bindings after they've first been created. That would avoid the problem situation. The person using the old DTB with the new kernel didn't commit user error. That is what we'd like folks to follow, but when code is in development, or productization, there is no saying the type of mistakes people end up doing. An alternate approach introduced here is to introduce device tree bindings corresponding to the clock nodes required in DT definition for SoC which automatically maps back to the definitions in cclockXYZ_data.c. Well, I haven't read the patches, but isn't that exactly what the 2 is in clk 2? partly so. yes: it indexes back to the right clock node - at that point the comparison stops. we just point back on naming as needed and introduce nodes purely for the ones that we need. Regards, Nishanth Menon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V4 1/6] clk: OMAP: introduce device tree binding to kernel clock data
On 10:22-20130413, Tony Lindgren wrote:
* Nishanth Menon n...@ti.com [130412 16:43]:
Thanks for checking up. Fixed all of them below, will post part of
series again, only if I need to address further comments in other
patches..
Thanks it seems that the other ones are ready to go, just one
more comment below.
[...]
+static struct clk *omap_clk_src_get(struct of_phandle_args *clkspec, void
*data)
+{
+ struct clk *clk;
+ char clk_name[32];
+ struct device_node *np = clkspec-np;
+
+ snprintf(clk_name, 32, %s_ck, np-name);
+ clk = clk_get(NULL, clk_name);
+ if (IS_ERR(clk)) {
+ pr_err(%s: could not get clock %s(%ld)\n, __func__,
+ clk_name, PTR_ERR(clk));
+ goto out;
+ }
+ clk_put(clk);
It seems that clk_put() is actually wrong here. That's because
of_clk_get() should boild down to just the look up of the clock
and then clk_get() on it, so no double clk_get() is done in this
case. Once the consumer driver is done, it will just call clk_put()
on it.
Yep - updated version below.
From d0bf3fce235cff46feac7f5ef1a40e2fa0f2aa12 Mon Sep 17 00:00:00 2001
From: Nishanth Menon n...@ti.com
Date: Tue, 9 Apr 2013 19:26:40 -0500
Subject: [PATCH V5.1 1/6] clk: OMAP: introduce device tree binding to kernel
clock
data
OMAP clock data is located in arch/arm/mach-omap2/cclockXYZ_data.c.
However, this presents an obstacle for using these clock nodes in
Device Tree definitions. This is especially true for board specific
clocks initially. The fixed clocks are currently found via clock
aliases table. There are many possible approaches to this problem as
discussed in the following thread:
http://marc.info/?t=13637032569r=1w=2.
Highlights of the options:
a) device specific clk_add_alias:
cons: driver handling required
b) using an generic clk node and indexing to reach the clock required.
This is similar in approach taken by tegra and few other platforms.
Example usage: clock = clk 5;
cons: potential to have mismatches in indexed table and associated
dtb data. In addition, managing continued documentation in bindings
as clock indexing increases. Even though readability angle could be
improved by using preprocessing of DT using macros, indexed
approach is inherently risky from cases like the following:
clk indexes in kernel:
1 - mpu_dpll
2 - aux_clk1
3 - core_clk
DT entry for peripheral X uses clk 2 to reach aux_clk1. Now, let's
say kernel updates indices to:
1 - mpu_dpll
2 - per_dpll
3 - aux_clk1
4 - core_clk
using the old dtb(or dts missing an update), on new kernel which
has updated indices will result in per_dpll now controlled for
peripheral X without warning or any potential error detection.
Even though we could claim this is user error, such errors are hard
to track down and fix.
An alternate approach introduced here is to introduce device tree
bindings corresponding to the clock nodes required in DT definition
for SoC which automatically maps back to the definitions in
cclockXYZ_data.c.
The driver introduced here to do this mapping will eventually be the
place where the clock handling will migrate to. We need to consider
this angle as well so that the solution will be an valid transition
point for moving the clock data out of kernel image (into device tree
or firmware load etc..).
Overall strategy introduced here is simple: a clock node described in
device tree blob is used to identify the exact clock provided in the
SoC specific data. This is then linked back using of_clk_add_provider
to the device node to be accessible by of_clk_get.
Based on discussion contributions from Roger Quadros, Grygorii Strashko
and others.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Mike Turquette mturque...@linaro.org
Cc: Paul Walmsley p...@pwsan.com
[t...@atomide.com: co-developed]
Signed-off-by: Tony Lindgren t...@atomide.com
Signed-off-by: Nishanth Menon n...@ti.com
---
.../devicetree/bindings/clock/omap-clock.txt | 40 +
drivers/clk/Makefile |1 +
drivers/clk/omap/Makefile |1 +
drivers/clk/omap/clk.c | 91
4 files changed, 133 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/omap-clock.txt
create mode 100644 drivers/clk/omap/Makefile
create mode 100644 drivers/clk/omap/clk.c
diff --git a/Documentation/devicetree/bindings/clock/omap-clock.txt
b/Documentation/devicetree/bindings/clock/omap-clock.txt
new file mode 100644
index 000..047c1e7
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/omap-clock.txt
@@ -0,0 +1,40 @@
+Device Tree Clock bindings for Texas Instrument's OMAP compatible platforms
+
+This binding is an initial minimal binding that may be enhanced as part of
+transitioning OMAP clock data out of kernel image.
+
+This binding uses the common clock binding[1].
+
+[1
[PATCH V4 0/6] ARM: OMAP3+: support cpufreq-cpu0 for device tree boot
The following version 4 of the series arose from trying to use BeagleBoard-XM (OMAP3 variant) for doing CPU DVFS using cpufreq-cpu0. This series enables the generic cpufreq-cpu0 driver to be used in device tree enabled boot while maintaining support of the legacy omap-cpufreq driver when used in non device tree enabled boot. However, in order to enable complete SoC entitlement for OMAP platforms, with this series, key features are still pending on device tree adaptation for OMAP: A) clock framework data transition to DT - this should happen soon, so this series hacks the clock node for the time being as suggested in review of original series[1]. B) On processors that use voltage controller, voltage processor (VC/VP hardware loop using I2C_SR path) - we have started work on transitioning them to regulator framework driven by DT. C) Adaptive Body Bias and SmartReflex AVS conversion to DT. [2] Note: At this point in time, we do not have DT entries for clock on OMAP platforms. Common Clock Framework(CCF) could also control regulators[3]. Once these conversions are complete, there might be minimal cleanup work to switch to the new data structure changes. Key benefit of the series is to allow all relevant TI platforms now to use a single cpufreq driver and equivalent frameworks in addition be part of the transition to device tree. NOTE: As a result of this series: 1. omap-cpufreq will be used only in non device tree boot scenario. we should delete this driver once the 100% DT conversion is complete. 2. Generic cpufreq-cpu0 will be used only in device tree boot scenario. boot systems. Key changes in version 4 since version 3: - OMAP clock driver introduced as discussed in http://marc.info/?t=13637032569r=1w=2 - cpufreq-cpu0 dummy device introduced in pm.c late_initcall: discussed in http://marc.info/?t=13645077344r=1w=2 - updated test script (prints regulator voltage where available) - parts of the series probably belong to different maintainer: consolidated as a single series to aid review in-context. version 3 of the series: http://marc.info/?l=linux-pmm=136450759315742w=2 available at: http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git/log/?h=for_3.10/dts version 2 of the series: http://marc.info/?t=13637157023r=1w=2 available at: https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-omap-all-v2 version 1 of the series: http://marc.info/?t=13632948545r=1w=2 available at: https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-omap-all-v1 [1] Original discussion thread which triggered this series: http://marc.info/?l=linux-pmm=136304313700602w=2 https://patchwork.kernel.org/patch/2251841/ https://patchwork.kernel.org/patch/2251851/ [2] ABB RFC: http://marc.info/?l=linux-omapm=136449099409794w=2 [3] CCF DVFS patches: https://patchwork.kernel.org/patch/2195431/ https://patchwork.kernel.org/patch/2195421/ https://patchwork.kernel.org/patch/2195451/ https://patchwork.kernel.org/patch/2195441/ https://patchwork.kernel.org/patch/2195461/ Version 4 is now based on a few branches to prevent merge conflicts(v3.9-rc6): git://git.linaro.org/people/mturquette/linux.git clk-next 38e4aa0 clk: sunxi: Unify oscillator clock git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git linux-next 584fa10 Merge branch 'pm-runtime-next' git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.10/dts 1fac4ff ARM: dts: Add OMAP3430 (merged branch is called baseline-v4 on my tree) Version 4 is also available at: https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-omap-all-v4 git link: git://github.com/nmenon/linux-2.6-playground.git branch: cpufreq-cpu0-omap-all-v4 Test coverage: test script: http://pastebin.com/z4yqZrBg Platforms verified: beaglebone(rev A6a) - AM33xx compatible - http://pastebin.com/YnSNiTnx beagleboard (rev C1D) - OMAP3430 compatible - DT enabled boot: http://pastebin.com/eGaDD3B4 - No DT enabled boot: http://pastebin.com/5xqsNBA6 omap3-beagle-xm -OMAP3630 compatible - http://pastebin.com/FdrG4Rna Pandaboard -(OMAP4430 ES2.1) - http://pastebin.com/1jjSRKQh Pandaboard-ES -(OMAP4460 ES1.1) - http://pastebin.com/B5acTbch Nishanth Menon (6): clk: OMAP: introduce device tree binding to kernel clock data [Clk probably belongs to mike's tree?] ARM: dts: OMAP3: add clock nodes for CPU ARM: dts: OMAP4: add clock nodes for CPU ARM: dts: AM33XX: add clock nodes for CPU [The above probably belong to Benoit's tree] ARM: OMAP2+: AM33XX: add lateinit hook for calling pm late init ARM: OMAP3+: use cpu0-cpufreq driver in device tree
[PATCH V4 2/6] ARM: dts: OMAP3: add clock nodes for CPU
OMAP34xx and OMAP36xx platforms use dpll1 clock. Add same to common
definition.
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
RFC of this patch was discussed in http://marc.info/?t=13637032569r=1w=2
along with the detailed context as to why this is an intermediate step.
previous revisions of cpufreq-cpu0 support do not use this approach.
[Probably belongs to Benoit's tree]
arch/arm/boot/dts/omap3.dtsi |7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 559b02f..58c6ed6 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -23,6 +23,8 @@
cpus {
cpu@0 {
compatible = arm,cortex-a8;
+ clocks = dpll1;
+ clock-names = cpu;
};
};
@@ -73,6 +75,11 @@
ti,hwmods = counter_32k;
};
+ dpll1: dpll1 {
+ #clock-cells = 0;
+ compatible = ti,omap-clock;
+ };
+
intc: interrupt-controller@4820 {
compatible = ti,omap2-intc;
interrupt-controller;
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V4 1/6] clk: OMAP: introduce device tree binding to kernel clock data
OMAP clock data is located in arch/arm/mach-omap2/cclockXYZ_data.c.
However, this presents an obstacle for using these clock nodes in
Device Tree definitions. This is especially true for board specific
clocks initially. The fixed clocks are currently found via clock
aliases table. There are many possible approaches to this problem as
discussed in the following thread:
http://marc.info/?t=13637032569r=1w=2.
Highlights of the options:
a) device specific clk_add_alias:
cons: driver handling required
b) using an generic clk node and indexing to reach the clock required.
This is similar in approach taken by tegra and few other platforms.
Example usage: clock = clk 5;
cons: potential to have mismatches in indexed table and associated
dtb data. In addition, managing continued documentation in bindings
as clock indexing increases. Even though readability angle could be
improved by using preprocessing of DT using macros, indexed
approach is inherently risky from cases like the following:
clk indexes in kernel:
1 - mpu_dpll
2 - aux_clk1
3 - core_clk
DT entry for peripheral X uses clk 2 to reach aux_clk1. Now, let's
say kernel updates indices to:
1 - mpu_dpll
2 - per_dpll
3 - aux_clk1
4 - core_clk
using the old dtb(or dts missing an update), on new kernel which
has updated indices will result in per_dpll now controlled for
peripheral X without warning or any potential error detection.
Even though we could claim this is user error, such errors are hard
to track down and fix.
An alternate approach introduced here is to introduce device tree
bindings corresponding to the clock nodes required in DT definition
for SoC which automatically maps back to the definitions in
cclockXYZ_data.c.
The driver introduced here to do this mapping will eventually be the
place where the clock handling will migrate to. We need to consider
this angle as well so that the solution will be an valid transition
point for moving the clock data out of kernel image (into device tree
or firmware load etc..).
Overall strategy introduced here is simple: a clock node described in
device tree blob is used to identify the exact clock provided in the
SoC specific data. This is then linked back using of_clk_add_provider
to the device node to be accessible by of_clk_get.
Based on discussion contributions from Roger Quadros, Grygorii Strashko
and others.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Mike Turquette mturque...@linaro.org
Cc: Paul Walmsley p...@pwsan.com
[t...@atomide.com: co-developed]
Signed-off-by: Tony Lindgren t...@atomide.com
Signed-off-by: Nishanth Menon n...@ti.com
---
RFC of this patch was discussed in http://marc.info/?t=13637032569r=1w=2
along with the detailed context as to why this is an intermediate step.
Previous revisions of cpufreq-cpu0 support do not use this approach.
[Might eventually belong to Mike's tree.]
.../devicetree/bindings/clock/omap-clock.txt | 40
drivers/clk/Makefile |1 +
drivers/clk/omap/Makefile |1 +
drivers/clk/omap/clk.c | 96
4 files changed, 138 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/omap-clock.txt
create mode 100644 drivers/clk/omap/Makefile
create mode 100644 drivers/clk/omap/clk.c
diff --git a/Documentation/devicetree/bindings/clock/omap-clock.txt
b/Documentation/devicetree/bindings/clock/omap-clock.txt
new file mode 100644
index 000..047c1e7
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/omap-clock.txt
@@ -0,0 +1,40 @@
+Device Tree Clock bindings for Texas Instrument's OMAP compatible platforms
+
+This binding is an initial minimal binding that may be enhanced as part of
+transitioning OMAP clock data out of kernel image.
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be ti,omap-clock
+- #clock-cells : from common clock binding; shall be set to 0.
+NOTE:
+node name should map to clock database in
arch/arm/mach-omap2/cclockSoC_data.c
+Since all clocks are described with _ck, the node name is optimized to drop the
+usage of _ck. For example, a clock called dpll1_ck will be defined as dpll1.
+
+Example #1: describing clock node for CPU on OMAP34xx platform:
+Ref: arch/arm/mach-omap2/cclock3xxx_data.c
+describes the CPU clock to be as follows
+ CLK(NULL, dpll1_ck, dpll1_ck, CK_3XXX),
+Corresponding binding will be:
+ dpll1: dpll1 {
+ #clock-cells = 0;
+ compatible = ti,omap-clock;
+ };
+And it's usage will be:
+ clocks = dpll1;
+
+Example #2: describing clock node for auxilary clock #3 on OMAP443x platform:
+Ref: arch/arm/mach-omap2/cclock44xx_data.c
+describes the auxclk3 clock to be as follows:
+ CLK(NULL, auxclk3_ck, auxclk3_ck
[PATCH V4 3/6] ARM: dts: OMAP4: add clock nodes for CPU
OMAP443x, OMAP446x and OMAP447x platforms use dpll_mpu clock.
Add same to common definition.
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
RFC of this patch approach for OMAP3 was discussed in
http://marc.info/?t=13637032569r=1w=2
along with the detailed context as to why this is an intermediate step.
previous revisions of cpufreq-cpu0 support do not use this approach.
[Probably belongs to Benoit's tree]
arch/arm/boot/dts/omap4.dtsi |7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 2a56428..1c6d969 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -31,6 +31,8 @@
cpu@0 {
compatible = arm,cortex-a9;
next-level-cache = L2;
+ clocks = dpll_mpu;
+ clock-names = cpu;
};
cpu@1 {
compatible = arm,cortex-a9;
@@ -106,6 +108,11 @@
ti,hwmods = counter_32k;
};
+ dpll_mpu: dpll_mpu {
+ #clock-cells = 0;
+ compatible = ti,omap-clock;
+ };
+
omap4_pmx_core: pinmux@4a100040 {
compatible = ti,omap4-padconf, pinctrl-single;
reg = 0x4a100040 0x0196;
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V4 4/6] ARM: dts: AM33XX: add clock nodes for CPU
AM33XX based platforms use dpll_mpu clock. Add same to common dtsi
and remove the dummy clock node entry as AM33XX platform supports
only device tree based boot.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Tony Lindgren t...@atomide.com
Signed-off-by: Nishanth Menon n...@ti.com
---
RFC of this patch was discussed in http://marc.info/?t=13637032569r=1w=2
along with the detailed context as to why this is an intermediate step.
previous revisions of cpufreq-cpu0 support do not use this approach.
[Probably belongs to Benoit/Tony/Paul tree?]
arch/arm/boot/dts/am33xx.dtsi |7 +++
arch/arm/mach-omap2/cclock33xx_data.c |1 -
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index df62830..3aed044 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -42,6 +42,8 @@
275000 1125000
;
voltage-tolerance = 2; /* 2 percentage */
+ clocks = dpll_mpu;
+ clock-names = cpu;
clock-latency = 30; /* From omap-cpufreq driver */
};
};
@@ -89,6 +91,11 @@
reg = 0x4820 0x1000;
};
+ dpll_mpu: dpll_mpu {
+ #clock-cells = 0;
+ compatible = ti,omap-clock;
+ };
+
gpio0: gpio@44e07000 {
compatible = ti,omap4-gpio;
ti,hwmods = gpio1;
diff --git a/arch/arm/mach-omap2/cclock33xx_data.c
b/arch/arm/mach-omap2/cclock33xx_data.c
index 7f091c8..8be6832 100644
--- a/arch/arm/mach-omap2/cclock33xx_data.c
+++ b/arch/arm/mach-omap2/cclock33xx_data.c
@@ -852,7 +852,6 @@ static struct omap_clk am33xx_clks[] = {
CLK(NULL, dpll_core_m5_ck, dpll_core_m5_ck,
CK_AM33XX),
CLK(NULL, dpll_core_m6_ck, dpll_core_m6_ck,
CK_AM33XX),
CLK(NULL, dpll_mpu_ck, dpll_mpu_ck, CK_AM33XX),
- CLK(cpu0, NULL, dpll_mpu_ck, CK_AM33XX),
CLK(NULL, dpll_mpu_m2_ck, dpll_mpu_m2_ck,
CK_AM33XX),
CLK(NULL, dpll_ddr_ck, dpll_ddr_ck, CK_AM33XX),
CLK(NULL, dpll_ddr_m2_ck, dpll_ddr_m2_ck,
CK_AM33XX),
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V4 6/6] ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot
With OMAP3+ and AM33xx supported SoC having defined CPU device tree
entries with operating-points and clock nodes defined, we can now use
the SoC generic cpufreq-cpu0 driver by registering appropriate device.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Tony Lindgren t...@atomide.com
Signed-off-by: Nishanth Menon n...@ti.com
---
Introduced as a result of alignment in
http://marc.info/?t=13645077344r=1w=2
previous versions do not use this approach.
This would probably be good to get merged *after* Rafael's tree is merged in.
[Probably belongs to Kevin/Tony's tree?]
arch/arm/mach-omap2/pm.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 8d15f9a..6cf95160 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -267,7 +267,12 @@ static void __init omap4_init_voltages(void)
static inline void omap_init_cpufreq(void)
{
- struct platform_device_info devinfo = { .name = omap-cpufreq, };
+ struct platform_device_info devinfo = { };
+
+ if (!of_have_populated_dt())
+ devinfo.name = omap-cpufreq;
+ else
+ devinfo.name = cpufreq-cpu0;
platform_device_register_full(devinfo);
}
@@ -301,9 +306,9 @@ int __init omap2_common_pm_late_init(void)
/* Smartreflex device init */
omap_devinit_smartreflex();
- /* cpufreq dummy device instantiation */
- omap_init_cpufreq();
}
+ /* cpufreq dummy device instantiation */
+ omap_init_cpufreq();
#ifdef CONFIG_SUSPEND
suspend_set_ops(omap_pm_ops);
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V4 5/6] ARM: OMAP2+: AM33XX: add lateinit hook for calling pm late init
Call OMAP2+ generic lateinit hook from AM specific late init hook.
This allows the generic late initializations such as cpufreq hooks
to be active.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Tony Lindgren t...@atomide.com
Signed-off-by: Nishanth Menon n...@ti.com
---
Introduced as a result of alignment in
http://marc.info/?t=13645077344r=1w=2
previous versions do not use this approach.
[Probably belongs to Kevin/Tony's tree?]
arch/arm/mach-omap2/board-generic.c |1 +
arch/arm/mach-omap2/common.h|1 +
arch/arm/mach-omap2/io.c|6 ++
3 files changed, 8 insertions(+)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index afa509a..86e8479 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -141,6 +141,7 @@ DT_MACHINE_START(AM33XX_DT, Generic AM33XX (Flattened
Device Tree))
.init_irq = omap_intc_of_init,
.handle_irq = omap3_intc_handle_irq,
.init_machine = omap_generic_init,
+ .init_late = am33xx_init_late,
.init_time = omap3_am33xx_gptimer_timer_init,
.dt_compat = am33xx_boards_compat,
.restart= am33xx_restart,
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 14522d0..65f2ebc 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -108,6 +108,7 @@ void omap35xx_init_late(void);
void omap3630_init_late(void);
void am35xx_init_late(void);
void ti81xx_init_late(void);
+void am33xx_init_late(void);
int omap2_common_pm_late_init(void);
#if defined(CONFIG_SOC_OMAP2420) || defined(CONFIG_SOC_OMAP2430)
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 5c445ca..61f5b84 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -576,6 +576,12 @@ void __init am33xx_init_early(void)
omap_hwmod_init_postsetup();
omap_clk_init = am33xx_clk_init;
}
+
+void __init am33xx_init_late(void)
+{
+ omap2_common_pm_late_init();
+}
+
#endif
#ifdef CONFIG_ARCH_OMAP4
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V4 1/6] clk: OMAP: introduce device tree binding to kernel clock data
On 16:31-20130412, Tony Lindgren wrote:
* Nishanth Menon n...@ti.com [130412 15:59]:
--- /dev/null
+++ b/drivers/clk/omap/clk.c
+/**
+ * omap_clk_src_get() - Get OMAP clock from node name when needed
+ * @clkspec: clkspec argument
+ * @data: unused
+ *
+ * REVISIT: We assume the following:
+ * 1. omap clock names end with _ck
+ * 2. omap clock names are under 32 characters in length
+ */
+static struct clk *omap_clk_src_get(struct of_phandle_args *clkspec, void
*data)
+{
+ struct clk *clk;
+ char clk_name[32];
+ struct device_node *np = clkspec-np;
+
+ /* Set up things so consumer can call clk_get() with name */
I would leave out the comment above, it's a leftover from
the clk_add_alias() version that we don't need because of
of_clk_get().
+ snprintf(clk_name, 32, %s_ck, np-name);
+ clk = clk_get(NULL, clk_name);
+ if (IS_ERR(clk)) {
+ pr_err(%s: could not get clock %s(%ld)\n, __func__,
+ clk_name, PTR_ERR(clk));
+ goto out;
+ }
+ clk_put(clk);
+
+out:
+ return clk;
+}
+
+/**
+ * omap_clk_probe() - create link from DT definition to clock data
+ * @pdev: device node
+ *
+ * NOTE: We assume that omap clocks are not removed.
+ */
How about drop the comment on clocks being removed above.
It no longer an issue, so maybe something like this instead:
* Note that we look up the clock lazily when the consumer
* driver does of_clk_get() and initialize a NULL clock here.
+static int omap_clk_probe(struct platform_device *pdev)
+{
+ int res;
+ struct device_node *np = pdev-dev.of_node;
+
+ /* This allows the driver to of_clk_get() */
+ res = of_clk_add_provider(np, omap_clk_src_get, NULL);
+ if (res)
+ dev_err(pdev-dev, could not add provider(%d)\n, res);
+
+ return res;
+}
+
+/* We assume here that OMAP clocks will not be removed */
Then the above comment can be removed too.
Thanks for checking up. Fixed all of them below, will post part of
series again, only if I need to address further comments in other
patches..
From f96c04860794f9bbfe240a8661641a7c90dd1640 Mon Sep 17 00:00:00 2001
From: Nishanth Menon n...@ti.com
Date: Tue, 9 Apr 2013 19:26:40 -0500
Subject: [PATCH V5 1/6] clk: OMAP: introduce device tree binding to kernel clock
data
OMAP clock data is located in arch/arm/mach-omap2/cclockXYZ_data.c.
However, this presents an obstacle for using these clock nodes in
Device Tree definitions. This is especially true for board specific
clocks initially. The fixed clocks are currently found via clock
aliases table. There are many possible approaches to this problem as
discussed in the following thread:
http://marc.info/?t=13637032569r=1w=2.
Highlights of the options:
a) device specific clk_add_alias:
cons: driver handling required
b) using an generic clk node and indexing to reach the clock required.
This is similar in approach taken by tegra and few other platforms.
Example usage: clock = clk 5;
cons: potential to have mismatches in indexed table and associated
dtb data. In addition, managing continued documentation in bindings
as clock indexing increases. Even though readability angle could be
improved by using preprocessing of DT using macros, indexed
approach is inherently risky from cases like the following:
clk indexes in kernel:
1 - mpu_dpll
2 - aux_clk1
3 - core_clk
DT entry for peripheral X uses clk 2 to reach aux_clk1. Now, let's
say kernel updates indices to:
1 - mpu_dpll
2 - per_dpll
3 - aux_clk1
4 - core_clk
using the old dtb(or dts missing an update), on new kernel which
has updated indices will result in per_dpll now controlled for
peripheral X without warning or any potential error detection.
Even though we could claim this is user error, such errors are hard
to track down and fix.
An alternate approach introduced here is to introduce device tree
bindings corresponding to the clock nodes required in DT definition
for SoC which automatically maps back to the definitions in
cclockXYZ_data.c.
The driver introduced here to do this mapping will eventually be the
place where the clock handling will migrate to. We need to consider
this angle as well so that the solution will be an valid transition
point for moving the clock data out of kernel image (into device tree
or firmware load etc..).
Overall strategy introduced here is simple: a clock node described in
device tree blob is used to identify the exact clock provided in the
SoC specific data. This is then linked back using of_clk_add_provider
to the device node to be accessible by of_clk_get.
Based on discussion contributions from Roger Quadros, Grygorii Strashko
and others.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Mike Turquette mturque...@linaro.org
Cc: Paul Walmsley p...@pwsan.com
[t...@atomide.com: co-developed]
Signed-off-by: Tony Lindgren t
Re: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
On Thu, Apr 11, 2013 at 1:46 PM, Mike Turquette mturque...@linaro.org wrote: Quoting Nishanth Menon (2013-04-10 10:39:21) diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c new file mode 100644 index 000..63a4cce --- /dev/null +++ b/drivers/clk/omap/clk.c @@ -0,0 +1,94 @@ +/* + * Texas Instruments OMAP Clock driver + * + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/ + * Nishanth Menon + * Tony Lindgren t...@atomide.com + * + * 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. + * + * This program is distributed as is WITHOUT ANY WARRANTY of any + * kind, whether express or implied; without even the implied warranty + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include linux/clkdev.h +#include linux/clk-private.h Please use clk-provider.h. Otherwise this looks like an OK transitional k. thanks for checking up on this. will update. solution. Hopefully this will be replaced with a more legitimate clock driver for 3.11. I hope so too. At least we should start debate with the direction we'd like to take and start migrating towards that purpose. Regards, Nishanth Menon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
On Thu, Apr 11, 2013 at 2:48 AM, Roger Quadros rog...@ti.com wrote: On 04/10/2013 08:39 PM, Nishanth Menon wrote: On 13:55-20130410, Roger Quadros wrote: On 04/10/2013 11:06 AM, Mike Turquette wrote: Quoting Nishanth Menon (2013-04-09 13:49:00) Folks, this does seem to be the best compromise we can achieve at this point in time. feedback on this approach is much appreciated - if folks are ok, I can post this as an formal patch series. This looks fine to me. Minor comments below. Thanks on the review. will fix in my next post Regards, Nishanth Menon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
On 13:55-20130410, Roger Quadros wrote: On 04/10/2013 11:06 AM, Mike Turquette wrote: Quoting Nishanth Menon (2013-04-09 13:49:00) On 10:43-20130409, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [130409 09:54]: * Roger Quadros rog...@ti.com [130409 03:00]: On 04/05/2013 06:58 PM, Tony Lindgren wrote: Can't you just use the clock name there to get it? In device tree we don't pass around clock names. You can either get a phandle or an index to the clock. e.g. Documentation/devicetree/bindings/clock/imx31-clock.txt Yes I understand that. But the driver/clock/omap driver can just remap the DT device initially so the board specific clock is found from the clock alias table. Basically initially a passthrough driver that can be enhanced to parse DT clock bindings and load data from /lib/firmware. Actually probably the driver/clock/omap can even do even less initially. There probably even no need to remap clocks there. As long as the DT clock driver understands that a board specific auxclk is specified in the DT it can just call clk_add_alias() so the driver will get the right auxclk from cclock44xx_data.c. Then other features can be added later on like to allocate a clock entirely based on the binding etc. I did try to have an implementation for cpufreq using clock nodes. unfortunately, device tree wont let me have arguments of strings :( So, I am unable to do clock = clk mpu_dpll; instead, I am forced to do clock = clk 249; See http://article.gmane.org/gmane.linux.ports.arm.kernel/229034 Awesome. Thanks for pointing this out Mike. Now all we need to do is create a named define for each clock index in the header file. Approach #3: Thanks to Tony for collaborating on this: Works for cpufreq-cpu0 - additional patches: http://pastebin.com/GHnTRVJf, http://pastebin.com/FZS89J6L (tested on beagleXM) Work for USB - http://pastebin.com/aJpDnXci - thanks Roger for testing this. Details in the patch below (Tony, I have added you as collaborator for helping in getting this working-clk_add_alias was'nt needed in the internal patch discussion we had - I have taken a bit of freedom in adding your contributions to the patch below) Folks, this does seem to be the best compromise we can achieve at this point in time. feedback on this approach is much appreciated - if folks are ok, I can post this as an formal patch series. From 130a41821bf57081ca45ef654029175d173135e6 Mon Sep 17 00:00:00 2001 From: Nishanth Menon n...@ti.com Date: Tue, 9 Apr 2013 19:26:40 -0500 Subject: [RFC PATCH] clk: OMAP: introduce device tree binding to kernel clock data OMAP clock data is located in arch/arm/mach-omap2/cclockXYZ_data.c. However, this presents an obstacle for using these clock nodes in Device Tree definitions. There are many possible approaches to this problem as discussed in the following thread: http://marc.info/?t=13637032569r=1w=2 Highlights of the options: a) device specific clk_add_alias: cons: driver handling required b) using an generic clk node and indexing to reach the clock required. This is similar in approach taken by tegra and few other platforms. example clock = clk 5; cons: potential to have mismatches in indexed table and associated dtb data. In addition, managing continued documentation in bindings as clock indexing increases. Even though readability angle could be improved by using preprocessing of DT using macros, indexed approach is inherently risky from cases like the following: clk indexes in kernel: 1 - mpu_dpll 2 - aux_clk1 3 - core_clk DT entry for peripheral x uses clk 2, kernel updates to: 1 - mpu_dpll 2 - per_dpll 3 - aux_clk1 4 - core_clk using the old dtb(or dts missing an update), on new kernel which has updated indices will result in per_dpll now controlled for peripheral X without warning or any potential error detection and warning. Even though we can claim this is user error, such errors are hard to track down and fix. An alternate approach introduced here is to introduce device tree bindings corresponding to the clock nodes required in DT definition for SoC which automatically maps back to the definitions in cclockXYZ_data.c. The driver introduced here to do this mapping will eventually be the place where the clock handling will migrate to. We need to consider this angle as well so that the solution will be an valid transition point for moving the clock data out of kernel image (into device tree or firmware load etc..). Overall strategy introduced here is simple: an clock node described in device tree blob is used to identify the exact clock provided in the SoC specific data. This is then linked back using of_clk_add_provider to the device node to be accessible by of_clk_get. Based on discussion contributions from Roger Quadros, Grygorii Strashko and others. [t...@atomide.com: co-developed] Signed-off-by: Tony Lindgren t
Re: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
Hi Tony,
On Wed, Apr 10, 2013 at 1:49 PM, Tony Lindgren t...@atomide.com wrote:
* Nishanth Menon n...@ti.com [130410 10:44]:
Details in the patch below (Tony, I have added you as collaborator for
helping in getting this working-clk_add_alias was'nt needed in the
internal patch discussion we had - I have taken a bit of freedom in
adding your contributions to the patch below)
OK thanks. Noticed few minor things, see below.
Thanks on the checkup
Folks, this does seem to be the best compromise we can achieve at this
point in time. feedback on this approach is much appreciated - if folks
are ok, I can post this as an formal patch series.
From 130a41821bf57081ca45ef654029175d173135e6 Mon Sep 17 00:00:00 2001
From: Nishanth Menon n...@ti.com
Date: Tue, 9 Apr 2013 19:26:40 -0500
Subject: [RFC PATCH] clk: OMAP: introduce device tree binding to kernel clock
data
OMAP clock data is located in arch/arm/mach-omap2/cclockXYZ_data.c.
However, this presents an obstacle for using these clock nodes in
Device Tree definitions. There are many possible approaches to this
problem as discussed in the following thread:
http://marc.info/?t=13637032569r=1w=2
It might be worth clarifying that this is especially for the board
specific clocks initially. The fixed clocks are currently found via
the clock aliases table.
Ack.
[...]
+Example #2: describing clock node for auxilary clock #3 on OMAP443x
platform:
+Ref: arch/arm/mach-omap2/cclock44xx_data.c
+describes the auxclk3 clock to be as follows:
+ CLK(NULL, auxclk3_ck, auxclk3_ck,CK_443X),
+Corresponding binding will be:
+ auxclk3: auxclk3 {
+ #clock-cells = 1;
+ compatible = ti,omap-clock;
+ };
+And it's usage will be:
+ clocks = auxclk3;
The #clock-cells in the auxclk3 example should also be 0 instead of 1
AFAIK. We should only use #clock-cells = 1 when the same physical
clock provides multiple outputs. I believe the auxclocks are all separate,
but that needs to be verified.
Oops.. my bad. you are correct here - auxclk is single output. all of them.
will fix.
[...]
+static int omap_clk_probe(struct platform_device *pdev)
+{
+ struct clk *clk;
+ int res;
+
+ const struct of_device_id *match;
+ struct device_node *np = pdev-dev.of_node;
+ char clk_name[32];
+
+ match = of_match_device(omap_clk_of_match, pdev-dev);
+
+ /* Set up things so consumer can call clk_get() with name */
+ snprintf(clk_name, 32, %s_ck, np-name);
+ clk = clk_get(NULL, clk_name);
+ if (IS_ERR(clk)) {
+ res = PTR_ERR(clk);
+ dev_err(pdev-dev, could not get clock %s (%d)\n,
+ clk_name, res);
+ goto out;
+ }
It seems that at least for now we can assume the naming will stay
that way, then if we need other rules for finding clocks, we can
add omap_match_clock() function or something.
ack.
+ /* This allows the driver to of_clk_get() */
+ res = of_clk_add_provider(np, of_clk_src_simple_get, clk);
+ if (res)
+ dev_err(pdev-dev, could not add provider for %s (%d)\n,
+ clk_name, res);
+
+ clk_put(clk);
+out:
+ return res;
+}
We can avoid the concern of storing the struct clk * and do the
look up lazily on consumer driver probe by setting a dummy struct
clk * here. Then replace of_clk_src_simple_get() with a custom
omap_clk_src_get() that does the lookup and replaces the struct
clk * with the real one.
Hmm.. this is interesting. will give it a try. Thanks on the suggestion.
Regards,
Nishanth Menon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
On 10:43-20130409, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [130409 09:54]:
* Roger Quadros rog...@ti.com [130409 03:00]:
On 04/05/2013 06:58 PM, Tony Lindgren wrote:
Can't you just use the clock name there to get it?
In device tree we don't pass around clock names. You can either get
a phandle or an index to the clock.
e.g. Documentation/devicetree/bindings/clock/imx31-clock.txt
Yes I understand that. But the driver/clock/omap driver can just
remap the DT device initially so the board specific clock is
found from the clock alias table. Basically initially a passthrough
driver that can be enhanced to parse DT clock bindings and load
data from /lib/firmware.
Actually probably the driver/clock/omap can even do even less
initially. There probably even no need to remap clocks there.
As long as the DT clock driver understands that a board specific
auxclk is specified in the DT it can just call clk_add_alias() so
the driver will get the right auxclk from cclock44xx_data.c.
Then other features can be added later on like to allocate a
clock entirely based on the binding etc.
I did try to have an implementation for cpufreq using clock nodes.
unfortunately, device tree wont let me have arguments of strings :(
So, I am unable to do clock = clk mpu_dpll;
instead, I am forced to do clock = clk 249;
Here is an attempt on beagleXM - adds every clock node to the list.
Tons of un-necessary prints added to give an idea - see log:
http://pastebin.com/F9A2zSTr
Would an cleaned up version be good enough as a step #1 of transition?
From 7d373bdb9e9549c1b6ba1775a8dfd96ebe78abfb Mon Sep 17 00:00:00 2001
From: Nishanth Menon n...@ti.com
Date: Tue, 26 Mar 2013 10:23:27 +
Subject: [PATCH] OMAP: add devicetree support for clock nodes.
Dummy patch based on Roger's original idea
Nyet-Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/omap3.dtsi |5 ++
arch/arm/boot/dts/omap34xx.dtsi |2 +
arch/arm/mach-omap2/cclock3xxx_data.c |3 +-
arch/arm/mach-omap2/cclock44xx_data.c |3 +-
arch/arm/mach-omap2/pm.c | 11 +++-
drivers/clk/Kconfig |6 ++
drivers/clk/Makefile |2 +
drivers/clk/ti.c | 100 +
include/linux/clk/ti.h| 30 ++
9 files changed, 157 insertions(+), 5 deletions(-)
create mode 100644 drivers/clk/ti.c
create mode 100644 include/linux/clk/ti.h
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 3344f05..a08990d 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -73,6 +73,11 @@
ti,hwmods = counter_32k;
};
+ clks: clocks {
+ compatible = ti,clock;
+ #clock-cells = 1;
+ };
+
intc: interrupt-controller@4820 {
compatible = ti,omap2-intc;
interrupt-controller;
diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi
index 75ed4ae..93c2621 100644
--- a/arch/arm/boot/dts/omap34xx.dtsi
+++ b/arch/arm/boot/dts/omap34xx.dtsi
@@ -23,6 +23,8 @@
60 135
;
clock-latency = 30; /* From legacy driver */
+ clocks = clks 249; /* index to cpufreq_ck */
+ clock-names = cpu;
};
};
};
diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c
b/arch/arm/mach-omap2/cclock3xxx_data.c
index 4579c3c..d5d5ef5 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -22,6 +22,7 @@
#include linux/clk-private.h
#include linux/list.h
#include linux/io.h
+#include linux/clk/ti.h
#include soc.h
#include iomap.h
@@ -3574,7 +3575,7 @@ int __init omap3xxx_clk_init(void)
for (c = omap3xxx_clks; c omap3xxx_clks + ARRAY_SIZE(omap3xxx_clks);
c++)
if (c-cpu cpu_clkflg) {
- clkdev_add(c-lk);
+ ti_clk_node_add(c-lk);
if (!__clk_init(NULL, c-lk.clk))
omap2_init_clk_hw_omap_clocks(c-lk.clk);
}
diff --git a/arch/arm/mach-omap2/cclock44xx_data.c
b/arch/arm/mach-omap2/cclock44xx_data.c
index 0c6834a..338ef64 100644
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -27,6 +27,7 @@
#include linux/clk-private.h
#include linux/clkdev.h
#include linux/io.h
+#include linux/clk/ti.h
#include soc.h
#include iomap.h
@@ -1697,7 +1698,7 @@ int __init omap4xxx_clk_init(void)
for (c = omap44xx_clks; c omap44xx_clks + ARRAY_SIZE(omap44xx_clks);
c++) {
if (c-cpu cpu_clkflg
Re: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
On 15:49-20130409, Nishanth Menon wrote:
On 10:43-20130409, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [130409 09:54]:
* Roger Quadros rog...@ti.com [130409 03:00]:
On 04/05/2013 06:58 PM, Tony Lindgren wrote:
Can't you just use the clock name there to get it?
In device tree we don't pass around clock names. You can either get
a phandle or an index to the clock.
e.g. Documentation/devicetree/bindings/clock/imx31-clock.txt
Yes I understand that. But the driver/clock/omap driver can just
remap the DT device initially so the board specific clock is
found from the clock alias table. Basically initially a passthrough
driver that can be enhanced to parse DT clock bindings and load
data from /lib/firmware.
Actually probably the driver/clock/omap can even do even less
initially. There probably even no need to remap clocks there.
As long as the DT clock driver understands that a board specific
auxclk is specified in the DT it can just call clk_add_alias() so
the driver will get the right auxclk from cclock44xx_data.c.
Then other features can be added later on like to allocate a
clock entirely based on the binding etc.
I did try to have an implementation for cpufreq using clock nodes.
unfortunately, device tree wont let me have arguments of strings :(
So, I am unable to do clock = clk mpu_dpll;
instead, I am forced to do clock = clk 249;
Here is an attempt on beagleXM - adds every clock node to the list.
Tons of un-necessary prints added to give an idea - see log:
http://pastebin.com/F9A2zSTr
Would an cleaned up version be good enough as a step #1 of transition?
Approach #2:
Here is yet another revision - here I am trying to avoid the risk of
folks messing up indexing. for example: using an older DTB with newer
kernel, clocks being inserted into existing list etc. to prevent these,
we add an DT_ID for omap clock nodes, and use it to uniquely identify
the clock node. We try to minimize(not avoidable with integer indexing)
mistakes during development/productization.
From 2b576affdc6f6bf0b51ebf9b85ef4319357a7994 Mon Sep 17 00:00:00 2001
From: Nishanth Menon n...@ti.com
Date: Tue, 26 Mar 2013 10:23:27 +
Subject: [RFC PATCH V2] OMAP: add devicetree support for clock nodes.(rev 2)
Dummy patch based on Roger's original idea
this time have lesser possibiltiy of screwing up indices. instead
use a specific integer ID to uniquely (TI SoC wide) identify an clock.
on the flip side, we do not all make clock nodes to be accesible from DT
clock indexing.
Nyet-Signed-off-by: Nishanth Menon n...@ti.com
---
.../devicetree/bindings/clock/ti,clock.txt | 48 +++
arch/arm/boot/dts/omap3.dtsi |5 ++
arch/arm/boot/dts/omap34xx.dtsi|2 +
arch/arm/boot/dts/omap4.dtsi |5 ++
arch/arm/boot/dts/omap443x.dtsi|2 +
arch/arm/mach-omap2/cclock3xxx_data.c |5 +-
arch/arm/mach-omap2/cclock44xx_data.c |5 +-
arch/arm/mach-omap2/clock.h| 12 +++
arch/arm/mach-omap2/pm.c | 11 ++-
drivers/clk/Kconfig|6 ++
drivers/clk/Makefile |2 +
drivers/clk/ti.c | 85
include/linux/clk/ti.h | 30 +++
13 files changed, 211 insertions(+), 7 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/ti,clock.txt
create mode 100644 drivers/clk/ti.c
create mode 100644 include/linux/clk/ti.h
diff --git a/Documentation/devicetree/bindings/clock/ti,clock.txt
b/Documentation/devicetree/bindings/clock/ti,clock.txt
new file mode 100644
index 000..53c947c
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti,clock.txt
@@ -0,0 +1,48 @@
+* Clock bindings for Texas Instruments clocks
+
+Required properties:
+- compatible: Should be ti,clock
+- #clock-cells: Should be 1
+
+The clock consumer should specify the desired clock by having the clock
+ID in its clocks phandle cell. The following is a list of ID reservations
+across TI SoCs
+
+ Clock ID
+ --
+ cpu clock 1
+
+The definition is used by SoC clock data using CLKDT() macro
+(example of OMAP2+).
+
+Example Steps:
+/* step 1: definiting an SoC nodes compatible with ti clocks -skip if already
done */
+clks: clocks {
+ compatible = ti,clock;
+ #clock-cells = 1;
+};
+
+/* step 2: Modify the bindings documentation to reserve an ID */
+ auxclk0_ck 2
+ auxclk1_ck 3
+ auxclk2_ck 4
+ auxclk3_ck 5
+ auxclk4_ck 6
+ auxclk5_ck 7
+etc. use an unique number not conflicting with previous reservations.
+WARNING: DONOT insert values - this breaks backward compatibility.
+/* Step 3: replace in clock data file
Re: [PATCH v2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
On 11:47-20130405, Roger Quadros wrote: On 04/02/2013 11:23 AM, Roger Quadros wrote: + Paul On 03/26/2013 12:23 PM, Roger Quadros wrote: Register a device tree clock provider for the clocks on the OMAP4 SoC. Also provide the binding information. For now we only provide AUXCLKs. NOTE: this patch depends on https://patchwork.kernel.org/patch/2312211/ Signed-off-by: Roger Quadros rog...@ti.com --- .../devicetree/bindings/clock/omap4-clock.txt | 33 arch/arm/boot/dts/omap4.dtsi |5 ++ arch/arm/mach-omap2/cclock44xx_data.c | 41 3 files changed, 79 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/omap4-clock.txt If we are doing this, we might as well do for all platforms(OMAP3-5, AM..) in an series, no? -- Regards, Nishanth Menon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V2 0/8] ARM: OMAP3+: support cpufreq-cpu0 for device tree boot
Hi Benoit, On Thu, Mar 28, 2013 at 6:03 AM, Benoit Cousson b-cous...@ti.com wrote: The patches 1 to 6 looks good to me. Beside the pretty long Cc list, that should not necessarily contain all the mailing list. Arrgh.. my bad. I will keep it in mind for the future. Since you are changing / renaming some DTS files, and to avoid any merge conflict I will apply only these 6 patches. DTS and driver changes are in theory orthogonal enough to allow merging them separately and in any order. I'll update my branch with these patches ASAP. Thanks. I will post a v3 of remaining patches later today. Regards, Nishanth Menon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V2 8/8] cpufreq: OMAP: donot allow to be used with device tree
On 11:39-20130327, Kevin Hilman wrote:
Nishanth Menon n...@ti.com writes:
#include linux/module.h
@@ -174,6 +175,19 @@ static inline void freq_table_free(void)
static int __cpuinit omap_cpu_init(struct cpufreq_policy *policy)
{
int result = 0;
+ struct device_node *np;
+
+ /*
+* If we have a device tree node describing OPPs,
+* we will NOT permit usage of omap-cpufreq driver.
+* use cpufreq-cpu0 driver to manage.
+*/
+ if (of_have_populated_dt()) {
+ for_each_child_of_node(of_find_node_by_path(/cpus), np) {
+ if (of_get_property(np, operating-points, NULL))
+ return -EPERM;
+ }
+ }
I think it's much cleaner to just convert this to a platform_driver like
was done for the generic driver[1]. Then the registration in the
previous patch can register the omap driver when needed.
Thanks for the review.
Yes. I agree. Will wait for any further comments on the DT angle before
I send out an V3.
--
Regards,
Nishanth Menon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V2 6/8] ARM: dts: OMAP4460: Add CPU OPP table
Add DT OPP table for OMAP4460 family of devices. This data is
decoded by OF with of_init_opp_table() helper function.
OPP data here is based on existing opp4xxx_data.c
This is in preparation to use generic cpufreq-cpu0 driver for device
tree enabled boot. Legacy non device tree enabled boot continues to
use omap-cpufreq.c and opp4xxx_data.c.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Jon Hunter jon-hun...@ti.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Shawn Guo shawn@linaro.org
Cc: Keerthy j-keer...@ti.com
Cc: linux-o...@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: cpuf...@vger.kernel.org
Cc: linux...@vger.kernel.org
Signed-off-by: Nishanth Menon n...@ti.com
---
Changes in V2:
- depend on 4460.dtsi available in benoit/for_3.10/dts branch
- donot delete the OPP table entries in omap4xxx_data.c
- little more verbose commit log
V1: https://patchwork.kernel.org/patch/2273611/
arch/arm/boot/dts/omap4460.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
index e09b3e1..7c2c23c 100644
--- a/arch/arm/boot/dts/omap4460.dtsi
+++ b/arch/arm/boot/dts/omap4460.dtsi
@@ -10,6 +10,19 @@
/include/ omap4.dtsi
/ {
+ cpus {
+ /* OMAP446x 'standard device' variants OPP50 to OPPTurbo */
+ cpu@0 {
+ operating-points =
+ /* kHzuV */
+ 35 975000
+ 70 1075000
+ 92 120
+ ;
+ clock-latency = 30; /* From legacy driver */
+ };
+ };
+
pmu {
compatible = arm,cortex-a9-pmu;
interrupts = 0 54 0x4,
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V2 8/8] cpufreq: OMAP: donot allow to be used with device tree
We now use Soc generic cpufreq-cpu0 driver using DT entries.
However to allow cpufreq-cpu0 and omap-cpufreq drivers to co-exist,
we need to ensure the following using the same image:
1. With device tree boot, we use cpufreq-cpu0
2. With non device tree boot, we use omap-cpufreq
In the case of (1), we will have cpu OPPs and regulator registered
as part of the DT, to ensure that omap-cpufreq and cpufreq-cpu0 don't
conflict in managing the frequency of the same cpu, we should not
permit init to pass in omap-cpufreq.
In the case of (2), we will not have the cpufreq-cpu0 device, hence
only omap-cpufreq will be active.
So, to acommodate both these usage conditions, we fail init of
omap-cpufreq when we boot with device tree.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Jon Hunter jon-hun...@ti.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Shawn Guo shawn@linaro.org
Cc: Keerthy j-keer...@ti.com
Cc: linux-o...@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: cpuf...@vger.kernel.org
Cc: linux...@vger.kernel.org
Signed-off-by: Nishanth Menon n...@ti.com
---
Changes in V2:
- donot remove support for omap-cpufreq in non-DT boot
- little more verbose commit log
V1: https://patchwork.kernel.org/patch/2273641/
drivers/cpufreq/omap-cpufreq.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index 9128c07..9382ed0 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -22,6 +22,7 @@
#include linux/err.h
#include linux/clk.h
#include linux/io.h
+#include linux/of.h
#include linux/opp.h
#include linux/cpu.h
#include linux/module.h
@@ -174,6 +175,19 @@ static inline void freq_table_free(void)
static int __cpuinit omap_cpu_init(struct cpufreq_policy *policy)
{
int result = 0;
+ struct device_node *np;
+
+ /*
+* If we have a device tree node describing OPPs,
+* we will NOT permit usage of omap-cpufreq driver.
+* use cpufreq-cpu0 driver to manage.
+*/
+ if (of_have_populated_dt()) {
+ for_each_child_of_node(of_find_node_by_path(/cpus), np) {
+ if (of_get_property(np, operating-points, NULL))
+ return -EPERM;
+ }
+ }
mpu_clk = clk_get(NULL, cpufreq_ck);
if (IS_ERR(mpu_clk))
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V2 2/8] ARM: dts: OMAP36xx: Add CPU OPP table
Add DT OPP table for OMAP36xx/37xx family of devices. This data is
decoded by OF with of_init_opp_table() helper function.
OPP data here is based on existing opp3xxx_data.c
This is in preparation to use generic cpufreq-cpu0 driver for device
tree enabled boot. Legacy non device tree enabled boot continues to
use omap-cpufreq.c and opp3xxx_data.c.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Jon Hunter jon-hun...@ti.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Shawn Guo shawn@linaro.org
Cc: Keerthy j-keer...@ti.com
Cc: linux-o...@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: cpuf...@vger.kernel.org
Cc: linux...@vger.kernel.org
Signed-off-by: Nishanth Menon n...@ti.com
---
Changes in V2:
- donot delete the OPP table entries in omap3xxx_data.c
- little more verbose commit log
V1: https://patchwork.kernel.org/patch/2273681/
arch/arm/boot/dts/omap36xx.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
index 96bf028..b89233e 100644
--- a/arch/arm/boot/dts/omap36xx.dtsi
+++ b/arch/arm/boot/dts/omap36xx.dtsi
@@ -15,6 +15,19 @@
serial3 = uart4;
};
+ cpus {
+ /* OMAP3630/OMAP37xx 'standard device' variants OPP50 to OPP130
*/
+ cpu@0 {
+ operating-points =
+ /* kHzuV */
+ 30 975000
+ 60 1075000
+ 80 120
+ ;
+ clock-latency = 30; /* From legacy driver */
+ };
+ };
+
ocp {
uart4: serial@49042000 {
compatible = ti,omap3-uart;
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V2 4/8] ARM: dts: OMAP443x: Add CPU OPP table
Add DT OPP table for OMAP443x family of devices. This data is
decoded by OF with of_init_opp_table() helper function.
OPP data here is based on existing opp4xxx_data.c
Since the omap4460 OPP tables would be different from OMAP443x,
introduce an new omap443x.dtsi for 443x specific entries and use
existing omap4.dtsi as the common dtsi file for all OMAP4 platforms.
This is in preparation to use generic cpufreq-cpu0 driver for device
tree enabled boot. Legacy non device tree enabled boot continues to
use omap-cpufreq.c and opp4xxx_data.c.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Jon Hunter jon-hun...@ti.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Shawn Guo shawn@linaro.org
Cc: Keerthy j-keer...@ti.com
Cc: linux-o...@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: cpuf...@vger.kernel.org
Cc: linux...@vger.kernel.org
Signed-off-by: Nishanth Menon n...@ti.com
---
Changes in V2:
- introduce omap443x.dtsi
- donot delete the OPP table entries in omap4xxx_data.c
- little more verbose commit log
V1: https://patchwork.kernel.org/patch/2273581/
arch/arm/boot/dts/omap4-panda.dts |2 +-
arch/arm/boot/dts/omap4-sdp.dts |2 +-
arch/arm/boot/dts/omap4-var-som.dts |2 +-
arch/arm/boot/dts/omap443x.dtsi | 27 +++
4 files changed, 30 insertions(+), 3 deletions(-)
create mode 100644 arch/arm/boot/dts/omap443x.dtsi
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index 1751a25..e05b1b0 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -7,7 +7,7 @@
*/
/dts-v1/;
-/include/ omap4.dtsi
+/include/ omap443x.dtsi
/include/ elpida_ecb240abacn.dtsi
/ {
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index a93a19d..c387bdc 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -7,7 +7,7 @@
*/
/dts-v1/;
-/include/ omap4.dtsi
+/include/ omap443x.dtsi
/include/ elpida_ecb240abacn.dtsi
/ {
diff --git a/arch/arm/boot/dts/omap4-var-som.dts
b/arch/arm/boot/dts/omap4-var-som.dts
index 6601e6a..222a413 100644
--- a/arch/arm/boot/dts/omap4-var-som.dts
+++ b/arch/arm/boot/dts/omap4-var-som.dts
@@ -7,7 +7,7 @@
*/
/dts-v1/;
-/include/ omap4.dtsi
+/include/ omap443x.dtsi
/ {
model = Variscite OMAP4 SOM;
diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
new file mode 100644
index 000..cccf39a
--- /dev/null
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -0,0 +1,27 @@
+/*
+ * Device Tree Source for OMAP443x SoC
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/include/ omap4.dtsi
+
+/ {
+ cpus {
+ cpu@0 {
+ /* OMAP443x variants OPP50-OPPNT */
+ operating-points =
+ /* kHzuV */
+ 30 1025000
+ 60 120
+ 80 1313000
+ 1008000 1375000
+ ;
+ clock-latency = 30; /* From legacy driver */
+ };
+ };
+};
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V2 1/8] ARM: dts: OMAP34xx/35xx: Add CPU OPP table
Add DT OPP table for OMAP34xx/35xx family of devices. This data is
decoded by OF with of_init_opp_table() helper function.
OPP data here is based on existing opp3xxx_data.c
Since the omap36xx OPP tables would be different from OMAP34xx/35xx,
introduce an new omap34xx.dtsi for 34xx/35xx specific entries and use
existing omap3.dtsi as the common dtsi file for all OMAP3 platforms.
This is in preparation to use generic cpufreq-cpu0 driver for device
tree enabled boot. Legacy non device tree enabled boot continues to
use omap-cpufreq.c and opp3xxx_data.c.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Jon Hunter jon-hun...@ti.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Shawn Guo shawn@linaro.org
Cc: Keerthy j-keer...@ti.com
Cc: linux-o...@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: cpuf...@vger.kernel.org
Cc: linux...@vger.kernel.org
Signed-off-by: Nishanth Menon n...@ti.com
---
Changes in V2:
- introduce omap34xx.dtsi
- donot delete the OPP table entries in omap3xxx_data.c
- little more verbose commit log
V1: https://patchwork.kernel.org/patch/2273571/
arch/arm/boot/dts/am3517-evm.dts|2 +-
arch/arm/boot/dts/am3517_mt_ventoux.dts |2 +-
arch/arm/boot/dts/omap3-beagle.dts |2 +-
arch/arm/boot/dts/omap3-devkit8000.dts |2 +-
arch/arm/boot/dts/omap3-evm.dts |2 +-
arch/arm/boot/dts/omap3-igep.dtsi |2 +-
arch/arm/boot/dts/omap3-overo.dtsi |2 +-
arch/arm/boot/dts/omap3430-sdp.dts |2 +-
arch/arm/boot/dts/omap34xx.dtsi | 28
9 files changed, 36 insertions(+), 8 deletions(-)
create mode 100644 arch/arm/boot/dts/omap34xx.dtsi
diff --git a/arch/arm/boot/dts/am3517-evm.dts b/arch/arm/boot/dts/am3517-evm.dts
index 474f760..e9b5bda 100644
--- a/arch/arm/boot/dts/am3517-evm.dts
+++ b/arch/arm/boot/dts/am3517-evm.dts
@@ -7,7 +7,7 @@
*/
/dts-v1/;
-/include/ omap3.dtsi
+/include/ omap34xx.dtsi
/ {
model = TI AM3517 EVM (AM3517/05);
diff --git a/arch/arm/boot/dts/am3517_mt_ventoux.dts
b/arch/arm/boot/dts/am3517_mt_ventoux.dts
index 5eb26d7..5568683 100644
--- a/arch/arm/boot/dts/am3517_mt_ventoux.dts
+++ b/arch/arm/boot/dts/am3517_mt_ventoux.dts
@@ -7,7 +7,7 @@
*/
/dts-v1/;
-/include/ omap3.dtsi
+/include/ omap34xx.dtsi
/ {
model = TeeJet Mt.Ventoux;
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index f624dc8..418550c 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -7,7 +7,7 @@
*/
/dts-v1/;
-/include/ omap3.dtsi
+/include/ omap34xx.dtsi
/ {
model = TI OMAP3 BeagleBoard;
diff --git a/arch/arm/boot/dts/omap3-devkit8000.dts
b/arch/arm/boot/dts/omap3-devkit8000.dts
index 54d3da7..8a5cdcc 100644
--- a/arch/arm/boot/dts/omap3-devkit8000.dts
+++ b/arch/arm/boot/dts/omap3-devkit8000.dts
@@ -7,7 +7,7 @@
*/
/dts-v1/;
-/include/ omap3.dtsi
+/include/ omap34xx.dtsi
/ {
model = TimLL OMAP3 Devkit8000;
compatible = timll,omap3-devkit8000, ti,omap3;
diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
index 6e6f80d..f14370e 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -7,7 +7,7 @@
*/
/dts-v1/;
-/include/ omap3.dtsi
+/include/ omap34xx.dtsi
/ {
model = TI OMAP3 EVM (OMAP3530, AM/DM37x);
diff --git a/arch/arm/boot/dts/omap3-igep.dtsi
b/arch/arm/boot/dts/omap3-igep.dtsi
index dd01c46..f8fe3b7 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -10,7 +10,7 @@
*/
/dts-v1/;
-/include/ omap3.dtsi
+/include/ omap34xx.dtsi
/ {
memory {
diff --git a/arch/arm/boot/dts/omap3-overo.dtsi
b/arch/arm/boot/dts/omap3-overo.dtsi
index 2d93a08..d4a7280 100644
--- a/arch/arm/boot/dts/omap3-overo.dtsi
+++ b/arch/arm/boot/dts/omap3-overo.dtsi
@@ -11,7 +11,7 @@
*/
/dts-v1/;
-/include/ omap3.dtsi
+/include/ omap34xx.dtsi
/ {
pwmleds {
diff --git a/arch/arm/boot/dts/omap3430-sdp.dts
b/arch/arm/boot/dts/omap3430-sdp.dts
index 535a6f9..05cd8ba 100644
--- a/arch/arm/boot/dts/omap3430-sdp.dts
+++ b/arch/arm/boot/dts/omap3430-sdp.dts
@@ -7,7 +7,7 @@
*/
/dts-v1/;
-/include/ omap3.dtsi
+/include/ omap34xx.dtsi
/ {
model = TI OMAP3430 SDP;
diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi
new file mode 100644
index 000..75ed4ae
--- /dev/null
+++ b/arch/arm/boot/dts/omap34xx.dtsi
@@ -0,0 +1,28 @@
+/*
+ * Device Tree Source for OMAP34xx/OMAP35xx SoC
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/include/ omap3.dtsi
+
+/ {
+ cpus
[PATCH V2 0/8] ARM: OMAP3+: support cpufreq-cpu0 for device tree boot
Hi, The following version 2 of the series arose from trying to use BeagleBoard-XM (OMAP3 variant) for doing CPU DVFS using cpufreq-cpu0. This series enables the generic cpufreq-cpu0 driver to be used in device tree enabled boot while maintaining support of the legacy omap-cpufreq driver when used in non device tree enabled boot. However, in order to enable complete SoC entitlement for OMAP platforms, with this series, key features are still pending on device tree adaptation for OMAP: A) clock framework data transition to DT - this should happen soon, so this series hacks the clock node for the time being as suggested in review of original series[1]. B) On processors that use voltage controller, voltage processor (VC/VP hardware loop using I2C_SR path) - we have started work on transitioning them to regulator framework driven by DT. C) Adaptive Body Bias and SmartReflex AVS conversion to DT. As a result of these pending features: - OMAP4 TWL6030 and TPS62361 which set voltage ONLY over I2C_SR have no regulators associated at the moment - fortunately, we boot at highest voltage, so things still work. - Missing ABB and AVS implies that for few of the SoCs (3630, OMAP4), I have not added those OPPs in DT yet - this also needs alignment with iMX, AM series pending work, where certain OPPs need enabling based on efuse programmed bit sequences - since it is an add-on work, it is not addressed here. Note: At this point in time, we do not have DT entries for clock on OMAP platforms. Common Clock Framework(CCF) could also control regulators[2]. Once these conversions are complete, there will be minimal cleanup work to switch to the new data structure changes. Key benefit of the series is to allow all relevant TI platforms now to use a single cpufreq driver and equivalent frameworks in addition be part of the transition to device tree. NOTE: As a result of this series: 1. omap-cpufreq will be used only in non device tree boot scenario. we should delete this driver once the 100% DT conversion is complete. 2. Generic cpufreq-cpu0 will be used only in device tree boot scenario. boot systems. Key changes in version 2: - series now rebased on Device tree patches queued for OMAP 3.10 - cpufreq-cpu0 and omap_cpufreq will co-exist and used depending on usage of device tree. - minor wording, cleanups for the same. - omap3.dtsi and omap4.dtsi now become common dtsi which is used by omap34xx.dtsi, omap36xx.dtsi, omap443x.dtsi, omap4460.dtsi as needed. version 1 of the series: http://marc.info/?t=13632948545r=1w=2 available at: https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-omap-all-v1 [1] Original discussion thread which triggered this series: http://marc.info/?l=linux-pmm=136304313700602w=2 https://patchwork.kernel.org/patch/2251841/ https://patchwork.kernel.org/patch/2251851/ [2] CCF DVFS patches: https://patchwork.kernel.org/patch/2195431/ https://patchwork.kernel.org/patch/2195421/ https://patchwork.kernel.org/patch/2195451/ https://patchwork.kernel.org/patch/2195441/ https://patchwork.kernel.org/patch/2195461/ Version 2 is now based on for-3.10/dts branch from Benoit: http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git/log/?h=for_3.10/dts 44fab7a ARM: dts: omap3-devkit8000: Add NAND DT node Version 2 is also available at: https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-omap-all-v2 git link: git://github.com/nmenon/linux-2.6-playground.git branch: cpufreq-cpu0-omap-all-v2 Test coverage: test script: http://pastebin.com/zrr8ptge Platforms verified: beaglebone(rev A6a) - AM33xx compatible - http://pastebin.com/PUx5h6Jy beagleboard (rev C1D) - OMAP3430 compatible - http://pastebin.com/SycCinFb (DT) http://pastebin.com/qwJHw9Ev (no DT) omap3-beagle-xm -OMAP3630 compatible - http://pastebin.com/tVEXeVZC Pandaboard -(OMAP4430 ES2.2) verified with omapconf - http://pastebin.com/cAtytfW0 Pandaboard-ES -(OMAP4460 ES1.1) verified with omapconf - http://pastebin.com/3EymNTMp Nishanth Menon (8): ARM: dts: OMAP34xx/35xx: Add CPU OPP table ARM: dts: OMAP36xx: Add CPU OPP table ARM: dts: OMAP3: use twl4030 vdd1 regulator for CPU ARM: dts: OMAP443x: Add CPU OPP table ARM: dts: omap4-panda: move generic sections to panda-common ARM: dts: OMAP4460: Add CPU OPP table ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot cpufreq: OMAP: donot allow to be used with device tree arch/arm/boot/dts/am3517-evm.dts |2 +- arch/arm/boot/dts/am3517_mt_ventoux.dts |2 +- arch/arm/boot/dts/omap3-beagle-xm.dts |6 + arch/arm/boot/dts/omap3-beagle.dts|8 +- arch/arm/boot/dts/omap3-devkit8000.dts|2 +- arch/arm/boot/dts/omap3-evm.dts |8 +- arch/arm/boot/dts/omap3-igep.dtsi |2
[PATCH V2 3/8] ARM: dts: OMAP3: use twl4030 vdd1 regulator for CPU
Define VDD1 regulator in twl4030 DT and mark it as the supply for the
various OMAP34xx/35xx/36xx/37xx platforms (all use TWL4030 variants with
VDD1 supplying the CPU).
NOTE: This currently will use I2C1 bus communication path to set the
voltage in device tree boot. In the legacy non device tree boot, we
continue to use twl-common.c which bypasses I2C1 bus communication path
and uses I2C4 bus path using OMAP voltage libraries. We should
eventually be able to use I2C4 path once we have voltage regulator for
OMAP which is capable of using the voltage controller/voltage processor
IP blocks.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Jon Hunter jon-hun...@ti.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Shawn Guo shawn@linaro.org
Cc: Keerthy j-keer...@ti.com
Cc: linux-o...@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: cpuf...@vger.kernel.org
Cc: linux...@vger.kernel.org
Signed-off-by: Nishanth Menon n...@ti.com
---
Changes in V2:
- little more verbose commit log (no functional changes)
V1: https://patchwork.kernel.org/patch/2273701/
arch/arm/boot/dts/omap3-beagle-xm.dts |6 ++
arch/arm/boot/dts/omap3-beagle.dts|6 ++
arch/arm/boot/dts/omap3-evm.dts |6 ++
arch/arm/boot/dts/twl4030.dtsi|6 ++
4 files changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 1177ff6..5a31964 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -13,6 +13,12 @@
model = TI OMAP3 BeagleBoard xM;
compatible = ti,omap3-beagle-xm, ti,omap3-beagle, ti,omap3;
+ cpus {
+ cpu@0 {
+ cpu0-supply = vcc;
+ };
+ };
+
memory {
device_type = memory;
reg = 0x8000 0x2000; /* 512 MB */
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index 418550c..07dea0a 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -13,6 +13,12 @@
model = TI OMAP3 BeagleBoard;
compatible = ti,omap3-beagle, ti,omap3;
+ cpus {
+ cpu@0 {
+ cpu0-supply = vcc;
+ };
+ };
+
memory {
device_type = memory;
reg = 0x8000 0x1000; /* 256 MB */
diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
index f14370e..05f51e1 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -13,6 +13,12 @@
model = TI OMAP3 EVM (OMAP3530, AM/DM37x);
compatible = ti,omap3-evm, ti,omap3;
+ cpus {
+ cpu@0 {
+ cpu0-supply = vcc;
+ };
+ };
+
memory {
device_type = memory;
reg = 0x8000 0x1000; /* 256 MB */
diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
index 23c0cdd..b3034da 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -23,6 +23,12 @@
compatible = ti,twl4030-wdt;
};
+ vcc: regulator-vdd1 {
+ compatible = ti,twl4030-vdd1;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 145;
+ };
+
vdac: regulator-vdac {
compatible = ti,twl4030-vdac;
regulator-min-microvolt = 180;
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V2 5/8] ARM: dts: omap4-panda: move generic sections to panda-common
PandaBoard, PandaBoard-A4 revisions use OMAP4430.
PandaBoard-ES version of the board uses OMAP4460.
Move the original panda dts file into a common dtsi used by all panda
variants. This allows us to introduce SoC variation for PandaBoard ES
without impacting other PandaBoard versions that are supported.
As part of this change, since OMAP4460 adds on to OMAP4430, add
omap4.dtsi to omap4460.dtsi.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Jon Hunter jon-hun...@ti.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Shawn Guo shawn@linaro.org
Cc: Keerthy j-keer...@ti.com
Cc: linux-o...@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: cpuf...@vger.kernel.org
Cc: linux...@vger.kernel.org
Signed-off-by: Nishanth Menon n...@ti.com
---
Changes in V2:
- use omap443x.dtsi and 4460.dtsi
- little more verbose commit log
V1: https://patchwork.kernel.org/patch/2273671/
arch/arm/boot/dts/omap4-panda-a4.dts |5 +-
arch/arm/boot/dts/omap4-panda-common.dtsi | 251 +
arch/arm/boot/dts/omap4-panda-es.dts |3 +-
arch/arm/boot/dts/omap4-panda.dts | 245 +---
arch/arm/boot/dts/omap4460.dtsi |1 +
5 files changed, 259 insertions(+), 246 deletions(-)
create mode 100644 arch/arm/boot/dts/omap4-panda-common.dtsi
diff --git a/arch/arm/boot/dts/omap4-panda-a4.dts
b/arch/arm/boot/dts/omap4-panda-a4.dts
index 75466d2..e30cdf0 100644
--- a/arch/arm/boot/dts/omap4-panda-a4.dts
+++ b/arch/arm/boot/dts/omap4-panda-a4.dts
@@ -5,7 +5,10 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
-/include/ omap4-panda.dts
+/dts-v1/;
+
+/include/ omap443x.dtsi
+/include/ omap4-panda-common.dtsi
/* Pandaboard Rev A4+ have external pullups on SCL SDA */
dss_hdmi_pins {
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
new file mode 100644
index 000..03bd60d
--- /dev/null
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -0,0 +1,251 @@
+/*
+ * Copyright (C) 2011-2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * 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.
+ */
+/include/ elpida_ecb240abacn.dtsi
+
+/ {
+ model = TI OMAP4 PandaBoard;
+ compatible = ti,omap4-panda, ti,omap4430, ti,omap4;
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x4000; /* 1 GB */
+ };
+
+ leds {
+ compatible = gpio-leds;
+ heartbeat {
+ label = pandaboard::status1;
+ gpios = gpio1 7 0;
+ linux,default-trigger = heartbeat;
+ };
+
+ mmc {
+ label = pandaboard::status2;
+ gpios = gpio1 8 0;
+ linux,default-trigger = mmc0;
+ };
+ };
+
+ sound: sound {
+ compatible = ti,abe-twl6040;
+ ti,model = PandaBoard;
+
+ ti,mclk-freq = 3840;
+
+ ti,mcpdm = mcpdm;
+
+ ti,twl6040 = twl6040;
+
+ /* Audio routing */
+ ti,audio-routing =
+ Headset Stereophone, HSOL,
+ Headset Stereophone, HSOR,
+ Ext Spk, HFL,
+ Ext Spk, HFR,
+ Line Out, AUXL,
+ Line Out, AUXR,
+ HSMIC, Headset Mic,
+ Headset Mic, Headset Mic Bias,
+ AFML, Line In,
+ AFMR, Line In;
+ };
+};
+
+omap4_pmx_core {
+ pinctrl-names = default;
+ pinctrl-0 =
+ twl6040_pins
+ mcpdm_pins
+ mcbsp1_pins
+ dss_hdmi_pins
+ tpd12s015_pins
+ ;
+
+ twl6040_pins: pinmux_twl6040_pins {
+ pinctrl-single,pins =
+ 0xe0 0x3/* hdq_sio.gpio_127 OUTPUT | MODE3 */
+ 0x160 0x100 /* sys_nirq2.sys_nirq2 INPUT | MODE0 */
+ ;
+ };
+
+ mcpdm_pins: pinmux_mcpdm_pins {
+ pinctrl-single,pins =
+ 0xc6 0x108 /* abe_pdm_ul_data.abe_pdm_ul_data
INPUT PULLDOWN | MODE0 */
+ 0xc8 0x108 /* abe_pdm_dl_data.abe_pdm_dl_data
INPUT PULLDOWN | MODE0 */
+ 0xca 0x118 /* abe_pdm_frame.abe_pdm_frame INPUT
PULLUP | MODE0 */
+ 0xcc 0x108 /* abe_pdm_lb_clk.abe_pdm_lb_clk INPUT
PULLDOWN | MODE0 */
+ 0xce 0x108
[PATCH V2 7/8] ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot
With OMAP3+ and AM33xx supported SoC having defined CPU device tree
entries with operating-points defined, we can now use the SoC
generic cpufreq-cpu0 driver by registering appropriate device.
As part of this change, add dummy clock node to use cpufreq-cpu0.
This is an suggested solution till we have OMAP clock nodes in DT.
Once the DT conversion is complete, we can then do:
clocks = dpll_mpu_ck; or the SoC specific equivalent.
Inspired by patch: https://patchwork.kernel.org/patch/2067841/
now made generic.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Jon Hunter jon-hun...@ti.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Shawn Guo shawn@linaro.org
Cc: Keerthy j-keer...@ti.com
Cc: linux-o...@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: cpuf...@vger.kernel.org
Cc: linux...@vger.kernel.org
Signed-off-by: Nishanth Menon n...@ti.com
---
Changes in V2:
- no functional changes
V1: https://patchwork.kernel.org/patch/2273621/
arch/arm/mach-omap2/board-generic.c |5 +
arch/arm/mach-omap2/cclock33xx_data.c |2 +-
arch/arm/mach-omap2/cclock3xxx_data.c |3 ++-
arch/arm/mach-omap2/cclock44xx_data.c |3 ++-
4 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index afa509a..5b147ef 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -49,6 +49,11 @@ static void __init omap_generic_init(void)
omap4_panda_display_init_of();
else if (of_machine_is_compatible(ti,omap4-sdp))
omap_4430sdp_display_init_of();
+
+ if (IS_ENABLED(CONFIG_GENERIC_CPUFREQ_CPU0)) {
+ struct platform_device_info devinfo = { .name = cpufreq-cpu0,
};
+ platform_device_register_full(devinfo);
+ }
}
#ifdef CONFIG_SOC_OMAP2420
diff --git a/arch/arm/mach-omap2/cclock33xx_data.c
b/arch/arm/mach-omap2/cclock33xx_data.c
index 476b820..cf7e736 100644
--- a/arch/arm/mach-omap2/cclock33xx_data.c
+++ b/arch/arm/mach-omap2/cclock33xx_data.c
@@ -852,7 +852,7 @@ static struct omap_clk am33xx_clks[] = {
CLK(NULL, dpll_core_m5_ck, dpll_core_m5_ck,
CK_AM33XX),
CLK(NULL, dpll_core_m6_ck, dpll_core_m6_ck,
CK_AM33XX),
CLK(NULL, dpll_mpu_ck, dpll_mpu_ck, CK_AM33XX),
- CLK(cpu0, NULL, dpll_mpu_ck, CK_AM33XX),
+ CLK(cpufreq-cpu0.0, NULL, dpll_mpu_ck,
CK_AM33XX),
CLK(NULL, dpll_mpu_m2_ck, dpll_mpu_m2_ck,
CK_AM33XX),
CLK(NULL, dpll_ddr_ck, dpll_ddr_ck, CK_AM33XX),
CLK(NULL, dpll_ddr_m2_ck, dpll_ddr_m2_ck,
CK_AM33XX),
diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c
b/arch/arm/mach-omap2/cclock3xxx_data.c
index 4579c3c..5a5b471 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -3501,7 +3501,8 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, uart4_ick,uart4_ick_am35xx, CK_AM35XX),
CLK(NULL, timer_32k_ck, omap_32k_fck, CK_3XXX),
CLK(NULL, timer_sys_ck, sys_ck,CK_3XXX),
- CLK(NULL, cpufreq_ck, dpll1_ck, CK_3XXX),
+ CLK(NULL, cpufreq_ck, dpll1_ck, CK_3XXX), /* used in
non-device tree boot */
+ CLK(cpufreq-cpu0.0, NULL, dpll1_ck, CK_3XXX), /* used in
device tree boot */
};
static const char *enable_init_clks[] = {
diff --git a/arch/arm/mach-omap2/cclock44xx_data.c
b/arch/arm/mach-omap2/cclock44xx_data.c
index 3d58f33..bcea785 100644
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -1660,7 +1660,8 @@ static struct omap_clk omap44xx_clks[] = {
CLK(4013a000.timer, timer_sys_ck, syc_clk_div_ck,
CK_443X),
CLK(4013c000.timer, timer_sys_ck, syc_clk_div_ck,
CK_443X),
CLK(4013e000.timer, timer_sys_ck, syc_clk_div_ck,
CK_443X),
- CLK(NULL, cpufreq_ck, dpll_mpu_ck, CK_443X),
+ CLK(NULL, cpufreq_ck, dpll_mpu_ck, CK_443X), /* used in
non-device tree boot */
+ CLK(cpufreq-cpu0.0, NULL, dpll_mpu_ck, CK_443X), /* used in
device tree boot */
};
int __init omap4xxx_clk_init(void)
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
