Re: [PATCH] ARM: OMAP3: Fix iva2_pwrdm settings for 3703

2013-05-22 Thread Yegor Yefremov 
On Tue, May 21, 2013 at 8:20 PM, Kevin Hilman khil...@linaro.org wrote:
 Tony Lindgren t...@atomide.com writes:

 * Yegor Yefremov yegorsli...@googlemail.com [130517 14:34]:
 On Fri, May 17, 2013 at 8:56 PM, Mark A. Greer mgr...@animalcreek.com 
 wrote:
  On Thu, May 16, 2013 at 12:19:20PM +0200, Yegor Yefremov wrote:
  On 15.05.2013 23:50, Mark A. Greer wrote:
   On Wed, May 15, 2013 at 10:07:35AM -0700, Tony Lindgren wrote:
 
   Mark, do you have some omap3 with no iva (other than am3703) to test 
   the
   idle states with?
  
   I have an am35xx which isn't supposed to have an IVA so I can test 
   with it
   (although, I'm not sure how well the kernel works on the am35xx these 
   days).
  
   I'm a bit busy today but I'll try booting the am35xx tomorrow and if it
   comes up, see what I can figure out.
 
  I think this issue is relevant to am3517 as you can see from this
  thread: http://thread.gmane.org/gmane.linux.ports.arm.omap/97903
  I could boot only with your patch 
  http://www.spinics.net/lists/arm-kernel/msg168865.html
 
  I have such a system running, so if you have any other patches/ideas to 
  test, I would do it.
 
  Yegor, since I've so far been unable to get my am3517evm to fire up, can
  you play around with the 3517 to see if there appears to be iva registers
  that can be read/written to safely?  In particular, can the code that 
  idles
  the iva be run safely on an am3517?

 I'll look into this next week. am3517 and IVA seems to be a really big
 mystery. In the TI forum will be stated, there is no IVA:
 http://e2e.ti.com/support/arm/sitara_arm/f/791/t/150961.aspx, but TRM
 has various appearances of IVA2 registers, but no real
 description/explanation of what is IVA and how to eat it.

 On 3703 it looks like the whole omap3_iva_idle() reset is needed, except
 for setting the iva2 bootmode to idle. So I'm planning to merge the following
 patch with just comments update this week unless somebody has a better fix
 in mind.

 Regards,

 Tony


 From: Tony Lindgren t...@atomide.com
 Date: Tue, 14 May 2013 20:28:15 -0700
 Subject: [PATCH] ARM: OMAP3: Fix iva2_pwrdm settings for 3703

 Commit a819c4f1 (ARM: OMAP3: PM: Only access IVA if one exists)
 changed PM to not access IVA registers on omaps that don't have
 them. Turns out we still need to idle iva2 as otherwise
 iva2_pwrdm will stay on and block deeper idle states.

 It seems that the only part of the reset that may not be needed
 is the setting of the iva2 boot mode to idle. But as that register
 seems to be there and is harmless if no iva2 is on the SoC, it's
 probably safest to do the complete reset.

 Signed-off-by: Tony Lindgren t...@atomide.com

 Acked-by: Kevin Hilman khil...@linaro.org

Tested-by: Yegor Yefremov yegorsli...@googlemail.com
--
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

Re: [PATCH] arm: configs: omap2plus_defconfig: enable USB bits which work

2013-05-22 Thread Roger Quadros 
On 05/14/2013 05:09 PM, Kevin Hilman wrote:
 Felipe Balbi ba...@ti.com writes:
 
 those USB bits work fine, so we can enable them
 safely. Plus, without USB_PHY EHCI wouldn't work
 and it would take quite a few bogus error reports
 until all users got the new changes.

 Signed-off-by: Felipe Balbi ba...@ti.com
 ---

 comiple tested only. Would be great to have someone
 testing on actual HW. Right now I don't have access
 to my HW.

 cheers

  arch/arm/configs/omap2plus_defconfig | 9 +
  1 file changed, 9 insertions(+)

 diff --git a/arch/arm/configs/omap2plus_defconfig 
 b/arch/arm/configs/omap2plus_defconfig
 index c1ef64b..a1fc0ca 100644
 --- a/arch/arm/configs/omap2plus_defconfig
 +++ b/arch/arm/configs/omap2plus_defconfig
 @@ -74,6 +74,7 @@ CONFIG_CMA=y
  CONFIG_CONNECTOR=y
  CONFIG_DEVTMPFS=y
  CONFIG_DEVTMPFS_MOUNT=y
 +CONFIG_OMAP_OCP2SCP=y
  CONFIG_MTD=y
  CONFIG_MTD_CMDLINE_PARTS=y
  CONFIG_MTD_CHAR=y
 @@ -206,10 +207,18 @@ CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
  CONFIG_USB_DEVICEFS=y
  CONFIG_USB_SUSPEND=y
  CONFIG_USB_MON=y
 +CONFIG_USB_EHCI_HCD=y
 
 NAK (on this particular change)
 
 This cannot be enable by default yet as EHCI *still* breaks core
 retention[1] (which has been broken since at least v3.5, almost a year
 now.)

True. Due to broken smart idle/wakeup, EHCI host has to rely on
IO Daisy chaining mechanism for remote wakeup.

So this can't be fixed till we have daisy chaining working with device tree
boot. I do have an implementation that works with MACH boot but I don't see
any point in upstreaming those as we would be moving eventually to device tree
only boot.

cheers,
-roger
--
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

[PATCH 1/5] ARM: dts: OMAP2+: use #include for all device trees

2013-05-22 Thread Florian Vaussard 
Replace /include/ by #include for OMAP2+ DT, in order to use the
C pre-processor, making use of #define features possible.

Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
 arch/arm/boot/dts/omap2.dtsi  |2 +-
 arch/arm/boot/dts/omap2420-h4.dts |2 +-
 arch/arm/boot/dts/omap2420.dtsi   |2 +-
 arch/arm/boot/dts/omap2430.dtsi   |2 +-
 arch/arm/boot/dts/omap3-beagle-xm.dts |4 ++--
 arch/arm/boot/dts/omap3-beagle.dts|4 ++--
 arch/arm/boot/dts/omap3-devkit8000.dts|4 ++--
 arch/arm/boot/dts/omap3-evm.dts   |4 ++--
 arch/arm/boot/dts/omap3-igep.dtsi |4 ++--
 arch/arm/boot/dts/omap3-igep0020.dts  |2 +-
 arch/arm/boot/dts/omap3-igep0030.dts  |2 +-
 arch/arm/boot/dts/omap3-overo.dtsi|4 ++--
 arch/arm/boot/dts/omap3-tobi.dts  |2 +-
 arch/arm/boot/dts/omap3.dtsi  |2 +-
 arch/arm/boot/dts/omap3430-sdp.dts|4 ++--
 arch/arm/boot/dts/omap34xx.dtsi   |2 +-
 arch/arm/boot/dts/omap36xx.dtsi   |2 +-
 arch/arm/boot/dts/omap4-panda-a4.dts  |4 ++--
 arch/arm/boot/dts/omap4-panda-common.dtsi |4 ++--
 arch/arm/boot/dts/omap4-panda-es.dts  |4 ++--
 arch/arm/boot/dts/omap4-panda.dts |4 ++--
 arch/arm/boot/dts/omap4-sdp-es23plus.dts  |2 +-
 arch/arm/boot/dts/omap4-sdp.dts   |6 +++---
 arch/arm/boot/dts/omap4-var-som.dts   |4 ++--
 arch/arm/boot/dts/omap4.dtsi  |2 +-
 arch/arm/boot/dts/omap443x.dtsi   |2 +-
 arch/arm/boot/dts/omap4460.dtsi   |2 +-
 arch/arm/boot/dts/omap5-evm.dts   |4 ++--
 arch/arm/boot/dts/omap5.dtsi  |2 +-
 29 files changed, 44 insertions(+), 44 deletions(-)

diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
index 37aa748..e6e4587 100644
--- a/arch/arm/boot/dts/omap2.dtsi
+++ b/arch/arm/boot/dts/omap2.dtsi
@@ -8,7 +8,7 @@
  * kind, whether express or implied.
  */
 
-/include/ skeleton.dtsi
+#include skeleton.dtsi
 
 / {
compatible = ti,omap2430, ti,omap2420, ti,omap2;
diff --git a/arch/arm/boot/dts/omap2420-h4.dts 
b/arch/arm/boot/dts/omap2420-h4.dts
index 68282ee..224c08f 100644
--- a/arch/arm/boot/dts/omap2420-h4.dts
+++ b/arch/arm/boot/dts/omap2420-h4.dts
@@ -7,7 +7,7 @@
  */
 /dts-v1/;
 
-/include/ omap2420.dtsi
+#include omap2420.dtsi
 
 / {
model = TI OMAP2420 H4 board;
diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi
index da5b285..c8f9c55 100644
--- a/arch/arm/boot/dts/omap2420.dtsi
+++ b/arch/arm/boot/dts/omap2420.dtsi
@@ -8,7 +8,7 @@
  * kind, whether express or implied.
  */
 
-/include/ omap2.dtsi
+#include omap2.dtsi
 
 / {
compatible = ti,omap2420, ti,omap2;
diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
index 054bc44..c535a5a 100644
--- a/arch/arm/boot/dts/omap2430.dtsi
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -8,7 +8,7 @@
  * kind, whether express or implied.
  */
 
-/include/ omap2.dtsi
+#include omap2.dtsi
 
 / {
compatible = ti,omap2430, ti,omap2;
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts 
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 3046d1f..e0ce823 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -7,7 +7,7 @@
  */
 /dts-v1/;
 
-/include/ omap36xx.dtsi
+#include omap36xx.dtsi
 
 / {
model = TI OMAP3 BeagleBoard xM;
@@ -75,7 +75,7 @@
};
 };
 
-/include/ twl4030.dtsi
+#include twl4030.dtsi
 
 i2c2 {
clock-frequency = 40;
diff --git a/arch/arm/boot/dts/omap3-beagle.dts 
b/arch/arm/boot/dts/omap3-beagle.dts
index 6eec699..fcac96a 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -7,7 +7,7 @@
  */
 /dts-v1/;
 
-/include/ omap34xx.dtsi
+#include omap34xx.dtsi
 
 / {
model = TI OMAP3 BeagleBoard;
@@ -107,7 +107,7 @@
};
 };
 
-/include/ twl4030.dtsi
+#include twl4030.dtsi
 
 mmc1 {
vmmc-supply = vmmc1;
diff --git a/arch/arm/boot/dts/omap3-devkit8000.dts 
b/arch/arm/boot/dts/omap3-devkit8000.dts
index 8a5cdcc..8d0f5e4 100644
--- a/arch/arm/boot/dts/omap3-devkit8000.dts
+++ b/arch/arm/boot/dts/omap3-devkit8000.dts
@@ -7,7 +7,7 @@
  */
 /dts-v1/;
 
-/include/ omap34xx.dtsi
+#include omap34xx.dtsi
 / {
model = TimLL OMAP3 Devkit8000;
compatible = timll,omap3-devkit8000, ti,omap3;
@@ -80,7 +80,7 @@
status = disabled;
 };
 
-/include/ twl4030.dtsi
+#include twl4030.dtsi
 
 mmc1 {
vmmc-supply = vmmc1;
diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
index 96d1c20..d75759b 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -7,7 +7,7 @@
  */
 /dts-v1/;
 
-/include/ omap34xx.dtsi
+#include omap34xx.dtsi
 
 / {
model = TI OMAP3 EVM (OMAP3530, AM/DM37x);
@@ -44,7 +44,7 @@
};
 };
 
-/include/ twl4030.dtsi

[PATCH 2/5] ARM: dts: OMAP2+: create a DT header for GPIO

2013-05-22 Thread Florian Vaussard 
Define the OMAP_GPIO macro to conveniently use GPIO inside OMAP DT.
For example:

gpios = gpio6 3 0;  /* GPIO 163 */

can be replaced by

gpios = OMAP_GPIO(163, 0);

Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
 include/dt-bindings/gpio/omap-gpio.h |  289 ++
 1 files changed, 289 insertions(+), 0 deletions(-)
 create mode 100644 include/dt-bindings/gpio/omap-gpio.h

diff --git a/include/dt-bindings/gpio/omap-gpio.h 
b/include/dt-bindings/gpio/omap-gpio.h
new file mode 100644
index 000..64f2686
--- /dev/null
+++ b/include/dt-bindings/gpio/omap-gpio.h
@@ -0,0 +1,289 @@
+/*
+ * This header provides macros and constants for binding ti,omap*-gpio
+ *
+ * Compatible with OMAP2, OMAP3, OMAP4 and OMAP5.
+ */
+
+#ifndef _DT_BINDINGS_GPIO_OMAP_GPIO_H
+#define _DT_BINDINGS_GPIO_OMAP_GPIO_H
+
+#include dt-bindings/gpio/gpio.h
+
+#define OMAP_GPIO_0_BANKgpio1
+#define OMAP_GPIO_1_BANKgpio1
+#define OMAP_GPIO_2_BANKgpio1
+#define OMAP_GPIO_3_BANKgpio1
+#define OMAP_GPIO_4_BANKgpio1
+#define OMAP_GPIO_5_BANKgpio1
+#define OMAP_GPIO_6_BANKgpio1
+#define OMAP_GPIO_7_BANKgpio1
+#define OMAP_GPIO_8_BANKgpio1
+#define OMAP_GPIO_9_BANKgpio1
+#define OMAP_GPIO_10_BANK   gpio1
+#define OMAP_GPIO_11_BANK   gpio1
+#define OMAP_GPIO_12_BANK   gpio1
+#define OMAP_GPIO_13_BANK   gpio1
+#define OMAP_GPIO_14_BANK   gpio1
+#define OMAP_GPIO_15_BANK   gpio1
+#define OMAP_GPIO_16_BANK   gpio1
+#define OMAP_GPIO_17_BANK   gpio1
+#define OMAP_GPIO_18_BANK   gpio1
+#define OMAP_GPIO_19_BANK   gpio1
+#define OMAP_GPIO_20_BANK   gpio1
+#define OMAP_GPIO_21_BANK   gpio1
+#define OMAP_GPIO_22_BANK   gpio1
+#define OMAP_GPIO_23_BANK   gpio1
+#define OMAP_GPIO_24_BANK   gpio1
+#define OMAP_GPIO_25_BANK   gpio1
+#define OMAP_GPIO_26_BANK   gpio1
+#define OMAP_GPIO_27_BANK   gpio1
+#define OMAP_GPIO_28_BANK   gpio1
+#define OMAP_GPIO_29_BANK   gpio1
+#define OMAP_GPIO_30_BANK   gpio1
+#define OMAP_GPIO_31_BANK   gpio1
+
+#define OMAP_GPIO_32_BANK   gpio2
+#define OMAP_GPIO_33_BANK   gpio2
+#define OMAP_GPIO_34_BANK   gpio2
+#define OMAP_GPIO_35_BANK   gpio2
+#define OMAP_GPIO_36_BANK   gpio2
+#define OMAP_GPIO_37_BANK   gpio2
+#define OMAP_GPIO_38_BANK   gpio2
+#define OMAP_GPIO_39_BANK   gpio2
+#define OMAP_GPIO_40_BANK   gpio2
+#define OMAP_GPIO_41_BANK   gpio2
+#define OMAP_GPIO_42_BANK   gpio2
+#define OMAP_GPIO_43_BANK   gpio2
+#define OMAP_GPIO_44_BANK   gpio2
+#define OMAP_GPIO_45_BANK   gpio2
+#define OMAP_GPIO_46_BANK   gpio2
+#define OMAP_GPIO_47_BANK   gpio2
+#define OMAP_GPIO_48_BANK   gpio2
+#define OMAP_GPIO_49_BANK   gpio2
+#define OMAP_GPIO_50_BANK   gpio2
+#define OMAP_GPIO_51_BANK   gpio2
+#define OMAP_GPIO_52_BANK   gpio2
+#define OMAP_GPIO_53_BANK   gpio2
+#define OMAP_GPIO_54_BANK   gpio2
+#define OMAP_GPIO_55_BANK   gpio2
+#define OMAP_GPIO_56_BANK   gpio2
+#define OMAP_GPIO_57_BANK   gpio2
+#define OMAP_GPIO_58_BANK   gpio2
+#define OMAP_GPIO_59_BANK   gpio2
+#define OMAP_GPIO_60_BANK   gpio2
+#define OMAP_GPIO_61_BANK   gpio2
+#define OMAP_GPIO_62_BANK   gpio2
+#define OMAP_GPIO_63_BANK   gpio2
+
+#define OMAP_GPIO_64_BANK   gpio3
+#define OMAP_GPIO_65_BANK   gpio3
+#define OMAP_GPIO_66_BANK   gpio3
+#define OMAP_GPIO_67_BANK   gpio3
+#define OMAP_GPIO_68_BANK   gpio3
+#define OMAP_GPIO_69_BANK   gpio3
+#define OMAP_GPIO_70_BANK   gpio3
+#define OMAP_GPIO_71_BANK   gpio3
+#define OMAP_GPIO_72_BANK   gpio3
+#define OMAP_GPIO_73_BANK   gpio3
+#define OMAP_GPIO_74_BANK   gpio3
+#define OMAP_GPIO_75_BANK   gpio3
+#define OMAP_GPIO_76_BANK   gpio3
+#define OMAP_GPIO_77_BANK   gpio3
+#define OMAP_GPIO_78_BANK   gpio3
+#define OMAP_GPIO_79_BANK   gpio3
+#define OMAP_GPIO_80_BANK   gpio3
+#define OMAP_GPIO_81_BANK   gpio3
+#define OMAP_GPIO_82_BANK   gpio3
+#define OMAP_GPIO_83_BANK   gpio3
+#define OMAP_GPIO_84_BANK   gpio3
+#define OMAP_GPIO_85_BANK   gpio3
+#define OMAP_GPIO_86_BANK   gpio3
+#define OMAP_GPIO_87_BANK   gpio3
+#define OMAP_GPIO_88_BANK   gpio3
+#define OMAP_GPIO_89_BANK   gpio3
+#define OMAP_GPIO_90_BANK   gpio3
+#define OMAP_GPIO_91_BANK   gpio3
+#define OMAP_GPIO_92_BANK   gpio3
+#define OMAP_GPIO_93_BANK   gpio3
+#define OMAP_GPIO_94_BANK   gpio3
+#define OMAP_GPIO_95_BANK   gpio3
+
+#define OMAP_GPIO_96_BANK   gpio4
+#define OMAP_GPIO_97_BANK   gpio4
+#define OMAP_GPIO_98_BANK   gpio4
+#define OMAP_GPIO_99_BANK   gpio4
+#define OMAP_GPIO_100_BANK  gpio4
+#define OMAP_GPIO_101_BANK  gpio4
+#define OMAP_GPIO_102_BANK  gpio4
+#define OMAP_GPIO_103_BANK  gpio4
+#define OMAP_GPIO_104_BANK  gpio4

[PATCH 3/5] ARM: dts: OMAP2+: convert DT files to use the new OMAP_GPIO macro

2013-05-22 Thread Florian Vaussard 
Use OMAP_GPIO(), in conjunction with standard GPIO flags, to enhance the
readability of DT GPIOs.

Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
 arch/arm/boot/dts/omap2.dtsi  |2 ++
 arch/arm/boot/dts/omap3-beagle-xm.dts |4 ++--
 arch/arm/boot/dts/omap3-beagle.dts|6 +++---
 arch/arm/boot/dts/omap3-devkit8000.dts|6 +++---
 arch/arm/boot/dts/omap3-igep0020.dts  |6 +++---
 arch/arm/boot/dts/omap3-igep0030.dts  |2 +-
 arch/arm/boot/dts/omap3-tobi.dts  |2 +-
 arch/arm/boot/dts/omap3.dtsi  |2 ++
 arch/arm/boot/dts/omap4-panda-common.dtsi |6 +++---
 arch/arm/boot/dts/omap4-sdp.dts   |   20 ++--
 arch/arm/boot/dts/omap4.dtsi  |2 ++
 arch/arm/boot/dts/omap5.dtsi  |2 ++
 12 files changed, 34 insertions(+), 26 deletions(-)

diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
index e6e4587..7ea5df4 100644
--- a/arch/arm/boot/dts/omap2.dtsi
+++ b/arch/arm/boot/dts/omap2.dtsi
@@ -8,6 +8,8 @@
  * kind, whether express or implied.
  */
 
+#include dt-bindings/gpio/omap-gpio.h
+
 #include skeleton.dtsi
 
 / {
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts 
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index e0ce823..e773a5e 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -29,13 +29,13 @@
 
heartbeat {
label = beagleboard::usr0;
-   gpios = gpio5 22 0; /* 150 - D6 LED */
+   gpios = OMAP_GPIO(150, GPIO_ACTIVE_HIGH); /* 150 - D6 
LED */
linux,default-trigger = heartbeat;
};
 
mmc {
label = beagleboard::usr1;
-   gpios = gpio5 21 0; /* 149 - D7 LED */
+   gpios = OMAP_GPIO(149, GPIO_ACTIVE_HIGH); /* 149 - D7 
LED */
linux,default-trigger = mmc0;
};
};
diff --git a/arch/arm/boot/dts/omap3-beagle.dts 
b/arch/arm/boot/dts/omap3-beagle.dts
index fcac96a..f1fd002 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -33,13 +33,13 @@
 
heartbeat {
label = beagleboard::usr0;
-   gpios = gpio5 22 0; /* 150 - D6 LED */
+   gpios = OMAP_GPIO(150, GPIO_ACTIVE_HIGH); /* 150 - D6 
LED */
linux,default-trigger = heartbeat;
};
 
mmc {
label = beagleboard::usr1;
-   gpios = gpio5 21 0; /* 149 - D7 LED */
+   gpios = OMAP_GPIO(149, GPIO_ACTIVE_HIGH); /* 149 - D7 
LED */
linux,default-trigger = mmc0;
};
};
@@ -50,7 +50,7 @@
regulator-name = hsusb2_reset;
regulator-min-microvolt = 330;
regulator-max-microvolt = 330;
-   gpio = gpio5 19 0;   /* gpio_147 */
+   gpio = OMAP_GPIO(147, GPIO_ACTIVE_HIGH);
startup-delay-us = 7;
enable-active-high;
};
diff --git a/arch/arm/boot/dts/omap3-devkit8000.dts 
b/arch/arm/boot/dts/omap3-devkit8000.dts
index 8d0f5e4..fecb5ac 100644
--- a/arch/arm/boot/dts/omap3-devkit8000.dts
+++ b/arch/arm/boot/dts/omap3-devkit8000.dts
@@ -22,21 +22,21 @@
 
heartbeat {
label = devkit8000::led1;
-   gpios = gpio6 26 0;  /* 186 - LED1 */
+   gpios = OMAP_GPIO(186, GPIO_ACTIVE_HIGH);   /* 186 
- LED1 */
default-state = on;
linux,default-trigger = heartbeat;
};
 
mmc {
label = devkit8000::led2;
-   gpios = gpio6 3 0;   /* 163 - LED2 */
+   gpios = OMAP_GPIO(163, GPIO_ACTIVE_HIGH);   /* 163 
- LED2 */
default-state = on;
linux,default-trigger = none;
};
 
usr {
label = devkit8000::led3;
-   gpios = gpio6 4 0;   /* 164 - LED3 */
+   gpios = OMAP_GPIO(164, GPIO_ACTIVE_HIGH);   /* 164 
- LED3 */
default-state = on;
linux,default-trigger = usr;
 };
diff --git a/arch/arm/boot/dts/omap3-igep0020.dts 
b/arch/arm/boot/dts/omap3-igep0020.dts
index 2f96a5c..4be8ba1 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -19,19 +19,19 @@
compatible = gpio-leds;
boot {
 label = omap3:green:boot;
-gpios = gpio1 26 0;
+gpios = OMAP_GPIO(26, GPIO_ACTIVE_HIGH);

[PATCH 4/5] ARM: dts: OMAP3: fix incorrect notation for musb-hdrc interrupt

2013-05-22 Thread Florian Vaussard 
On OMAP3, the INTC interrupt controller has only 1 cell.

Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
 arch/arm/boot/dts/omap3.dtsi |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 15049b8..0f3be20 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -518,7 +518,7 @@
usb_otg_hs: usb_otg_hs@480ab000 {
compatible = ti,omap3-musb;
reg = 0x480ab000 0x1000;
-   interrupts = 0 92 0x4, 0 93 0x4;
+   interrupts = 92, 93;
interrupt-names = mc, dma;
ti,hwmods = usb_otg_hs;
multipoint = 1;
-- 
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

[PATCH 0/5] ARM: dts: OMAP2+: use preprocessor for device trees

2013-05-22 Thread Florian Vaussard 
Hello,

Following a similar proposal by Stephen Warren for tegra [1], this series
makes use of the C preprocessor when compiling OMAP DT files, and
accomplishes some improvements to improve overall readability.

Patch 2 creates a header file to define the OMAP_GPIO() macro, used by
patch 3 to make GPIOs more readable.
Likewise patch 5 uses the existing constants to make IRQs more readable.
Patch 4 is a small random fix.

This series was boot-tested on omap3-tobi. For other targets, the
decompiled .dtb were diff'ed before and after applying the series
to guarantee identity.

Best regards,

Florian

[1] https://patchwork.kernel.org/patch/2560091/

Florian Vaussard (5):
  ARM: dts: OMAP2+: use #include for all device trees
  ARM: dts: OMAP2+: create a DT header for GPIO
  ARM: dts: OMAP2+: convert DT files to use the new OMAP_GPIO macro
  ARM: dts: OMAP3: fix incorrect notation for musb-hdrc interrupt
  ARM: dts: OMAP4/5: use existing constants for IRQs

 arch/arm/boot/dts/omap2.dtsi  |4 +-
 arch/arm/boot/dts/omap2420-h4.dts |2 +-
 arch/arm/boot/dts/omap2420.dtsi   |2 +-
 arch/arm/boot/dts/omap2430.dtsi   |2 +-
 arch/arm/boot/dts/omap3-beagle-xm.dts |8 +-
 arch/arm/boot/dts/omap3-beagle.dts|   10 +-
 arch/arm/boot/dts/omap3-devkit8000.dts|   10 +-
 arch/arm/boot/dts/omap3-evm.dts   |4 +-
 arch/arm/boot/dts/omap3-igep.dtsi |4 +-
 arch/arm/boot/dts/omap3-igep0020.dts  |8 +-
 arch/arm/boot/dts/omap3-igep0030.dts  |4 +-
 arch/arm/boot/dts/omap3-overo.dtsi|4 +-
 arch/arm/boot/dts/omap3-tobi.dts  |4 +-
 arch/arm/boot/dts/omap3.dtsi  |6 +-
 arch/arm/boot/dts/omap3430-sdp.dts|4 +-
 arch/arm/boot/dts/omap34xx.dtsi   |2 +-
 arch/arm/boot/dts/omap36xx.dtsi   |2 +-
 arch/arm/boot/dts/omap4-panda-a4.dts  |4 +-
 arch/arm/boot/dts/omap4-panda-common.dtsi |   18 +-
 arch/arm/boot/dts/omap4-panda-es.dts  |4 +-
 arch/arm/boot/dts/omap4-panda.dts |4 +-
 arch/arm/boot/dts/omap4-sdp-es23plus.dts  |2 +-
 arch/arm/boot/dts/omap4-sdp.dts   |   32 ++--
 arch/arm/boot/dts/omap4-var-som.dts   |8 +-
 arch/arm/boot/dts/omap4.dtsi  |  117 ++--
 arch/arm/boot/dts/omap443x.dtsi   |2 +-
 arch/arm/boot/dts/omap4460.dtsi   |6 +-
 arch/arm/boot/dts/omap5-evm.dts   |4 +-
 arch/arm/boot/dts/omap5.dtsi  |  125 +++--
 include/dt-bindings/gpio/omap-gpio.h  |  289 +
 30 files changed, 497 insertions(+), 198 deletions(-)
 create mode 100644 include/dt-bindings/gpio/omap-gpio.h

-- 
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

[PATCH 5/5] ARM: dts: OMAP4/5: use existing constants for IRQs

2013-05-22 Thread Florian Vaussard 
Use the constants defined in include/dt-bindings/interrupt-controller/
to enhance readability.

Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
 arch/arm/boot/dts/omap4-panda-common.dtsi |8 +-
 arch/arm/boot/dts/omap4-sdp.dts   |6 +-
 arch/arm/boot/dts/omap4-var-som.dts   |4 +-
 arch/arm/boot/dts/omap4.dtsi  |  113 ++-
 arch/arm/boot/dts/omap4460.dtsi   |4 +-
 arch/arm/boot/dts/omap5.dtsi  |  121 +++--
 6 files changed, 129 insertions(+), 127 deletions(-)

diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi 
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index b71f5cd..c2354c9 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -145,16 +145,16 @@
 
twl: twl@48 {
reg = 0x48;
-   /* SPI = 0, IRQ# = 7, 4 = active high level-sensitive */
-   interrupts = 0 7 4; /* IRQ_SYS_1N cascaded to gic */
+   /* IRQ# = 7 */
+   interrupts = GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH; /* IRQ_SYS_1N 
cascaded to gic */
interrupt-parent = gic;
};
 
twl6040: twl@4b {
compatible = ti,twl6040;
reg = 0x4b;
-   /* SPI = 0, IRQ# = 119, 4 = active high level-sensitive */
-   interrupts = 0 119 4; /* IRQ_SYS_2N cascaded to gic */
+   /* IRQ# = 119 */
+   interrupts = GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH; /* IRQ_SYS_2N 
cascaded to gic */
interrupt-parent = gic;
ti,audpwron-gpio = OMAP_GPIO(127, GPIO_ACTIVE_HIGH);
 
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index f55bb68..3ce4987 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -286,7 +286,7 @@
twl: twl@48 {
reg = 0x48;
/* SPI = 0, IRQ# = 7, 4 = active high level-sensitive */
-   interrupts = 0 7 4; /* IRQ_SYS_1N cascaded to gic */
+   interrupts = GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH; /* IRQ_SYS_1N 
cascaded to gic */
interrupt-parent = gic;
};
 
@@ -294,7 +294,7 @@
compatible = ti,twl6040;
reg = 0x4b;
/* SPI = 0, IRQ# = 119, 4 = active high level-sensitive */
-   interrupts = 0 119 4; /* IRQ_SYS_2N cascaded to gic */
+   interrupts = GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH; /* IRQ_SYS_2N 
cascaded to gic */
interrupt-parent = gic;
ti,audpwron-gpio = OMAP_GPIO(127, GPIO_ACTIVE_HIGH);
 
@@ -375,7 +375,7 @@
spi-max-frequency = 2400;
reg = 0;
interrupt-parent = gpio2;
-   interrupts = 2 8; /* gpio line 34, low triggered */
+   interrupts = 2 IRQ_TYPE_LEVEL_LOW; /* gpio line 34, low 
triggered */
vdd-supply = vdd_eth;
};
 };
diff --git a/arch/arm/boot/dts/omap4-var-som.dts 
b/arch/arm/boot/dts/omap4-var-som.dts
index 6593607..135ba45 100644
--- a/arch/arm/boot/dts/omap4-var-som.dts
+++ b/arch/arm/boot/dts/omap4-var-som.dts
@@ -34,7 +34,7 @@
twl: twl@48 {
reg = 0x48;
/* SPI = 0, IRQ# = 7, 4 = active high level-sensitive */
-   interrupts = 0 7 4; /* IRQ_SYS_1N cascaded to gic */
+   interrupts = GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH; /* IRQ_SYS_1N 
cascaded to gic */
interrupt-parent = gic;
};
 };
@@ -68,7 +68,7 @@
spi-max-frequency = 2400;
reg = 0;
interrupt-parent = gpio6;
-   interrupts = 11 8; /* gpio line 171, low triggered */
+   interrupts = 11 IRQ_TYPE_LEVEL_LOW; /* gpio line 171, low 
triggered */
vdd-supply = vdd_eth;
};
 };
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 3c00b72..d1037ac 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -15,6 +15,7 @@
 /memreserve/ 0x9d00 0x0300;
 
 #include dt-bindings/gpio/omap-gpio.h
+#include dt-bindings/interrupt-controller/arm-gic.h
 
 #include skeleton.dtsi
 
@@ -58,7 +59,7 @@
local-timer@0x48240600 {
compatible = arm,cortex-a9-twd-timer;
reg = 0x48240600 0x20;
-   interrupts = 1 13 0x304;
+   interrupts = GIC_PPI 13 (GIC_CPU_MASK_RAW(3) | 
IRQ_TYPE_LEVEL_HIGH);
};
 
/*
@@ -99,8 +100,8 @@
reg = 0x4400 0x1000,
  0x4480 0x2000,
  0x4500 0x1000;
-   interrupts = 0 9 0x4,
-0 10 0x4;
+   interrupts = GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH;
 
counter32k: counter@4a304000 {
compatible =

Re: [PATCH 2/5] ARM: dts: OMAP2+: create a DT header for GPIO

2013-05-22 Thread Stephen Warren 
On 05/22/2013 08:27 AM, Florian Vaussard wrote:
 Define the OMAP_GPIO macro to conveniently use GPIO inside OMAP DT.
 For example:
 
   gpios = gpio6 3 0;  /* GPIO 163 */
 
 can be replaced by
 
   gpios = OMAP_GPIO(163, 0);

 diff --git a/include/dt-bindings/gpio/omap-gpio.h 
 b/include/dt-bindings/gpio/omap-gpio.h

 +#define OMAP_GPIO_0_BANKgpio1
 +#define OMAP_GPIO_1_BANKgpio1
 +#define OMAP_GPIO_2_BANKgpio1
 +#define OMAP_GPIO_3_BANKgpio1

There are a /lot/ of those. Is this really worth it?

If the OMAP GPIO HW is already represented as a bunch of separate DT
nodes which represent separate GPIO blocks, then I would have thought
the syntax gpioN M 0 more directly represents what would be found in
the HW manual? If not, surely the DT should have a single node to
represent a single GPIO controller, which just happens to internally
support a bunch of register arrays.
--
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

Re: [PATCH 3/5] ARM: dts: OMAP2+: convert DT files to use the new OMAP_GPIO macro

2013-05-22 Thread Stephen Warren 
On 05/22/2013 08:27 AM, Florian Vaussard wrote:
 Use OMAP_GPIO(), in conjunction with standard GPIO flags, to enhance the
 readability of DT GPIOs.

 diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts 
 b/arch/arm/boot/dts/omap3-beagle-xm.dts
 index e0ce823..e773a5e 100644
 --- a/arch/arm/boot/dts/omap3-beagle-xm.dts
 +++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
 @@ -29,13 +29,13 @@
  
   heartbeat {
   label = beagleboard::usr0;
 - gpios = gpio5 22 0; /* 150 - D6 LED */
 + gpios = OMAP_GPIO(150, GPIO_ACTIVE_HIGH); /* 150 - D6 
 LED */

One of the advantages of cpp support for me is the ability to remove the
redundant part of the command. In other words, perhaps remove the 150
- since that information is part of the OMAP_GPIO() call, leaving
just /* D6 LED */. I might have expected D6 to be the label too, thus
removing any need for the comment.
--
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

Re: [PATCH 2/5] ARM: dts: OMAP2+: create a DT header for GPIO

2013-05-22 Thread Tony Lindgren 
* Stephen Warren swar...@wwwdotorg.org [130522 08:32]:
 On 05/22/2013 08:27 AM, Florian Vaussard wrote:
  Define the OMAP_GPIO macro to conveniently use GPIO inside OMAP DT.
  For example:
  
  gpios = gpio6 3 0;  /* GPIO 163 */
  
  can be replaced by
  
  gpios = OMAP_GPIO(163, 0);
 
  diff --git a/include/dt-bindings/gpio/omap-gpio.h 
  b/include/dt-bindings/gpio/omap-gpio.h
 
  +#define OMAP_GPIO_0_BANKgpio1
  +#define OMAP_GPIO_1_BANKgpio1
  +#define OMAP_GPIO_2_BANKgpio1
  +#define OMAP_GPIO_3_BANKgpio1
 
 There are a /lot/ of those. Is this really worth it?
 
 If the OMAP GPIO HW is already represented as a bunch of separate DT
 nodes which represent separate GPIO blocks, then I would have thought
 the syntax gpioN M 0 more directly represents what would be found in
 the HW manual? If not, surely the DT should have a single node to
 represent a single GPIO controller, which just happens to internally
 support a bunch of register arrays.

Yes I agree, let's not go back to numbering anything except within the
a single instance. If anything, we can put the gpio number into comments.

Regards,

Tony
--
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

Re: [PATCH 4/5] ARM: dts: OMAP3: fix incorrect notation for musb-hdrc interrupt

2013-05-22 Thread Tony Lindgren 
* Florian Vaussard florian.vauss...@epfl.ch [130522 07:33]:
 On OMAP3, the INTC interrupt controller has only 1 cell.
 
 Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch

Thanks a similar fix is already queued up and on it's way to mainline
tree.

Regards,

Tony

 ---
  arch/arm/boot/dts/omap3.dtsi |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
 index 15049b8..0f3be20 100644
 --- a/arch/arm/boot/dts/omap3.dtsi
 +++ b/arch/arm/boot/dts/omap3.dtsi
 @@ -518,7 +518,7 @@
   usb_otg_hs: usb_otg_hs@480ab000 {
   compatible = ti,omap3-musb;
   reg = 0x480ab000 0x1000;
 - interrupts = 0 92 0x4, 0 93 0x4;
 + interrupts = 92, 93;
   interrupt-names = mc, dma;
   ti,hwmods = usb_otg_hs;
   multipoint = 1;
 -- 
 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

Re: [PATCH 1/5] ARM: dts: OMAP2+: use #include for all device trees

2013-05-22 Thread Tony Lindgren 
* Florian Vaussard florian.vauss...@epfl.ch [130522 07:33]:
 Replace /include/ by #include for OMAP2+ DT, in order to use the
 C pre-processor, making use of #define features possible.

This is good, but let's use it with case. Probably the best use
for this right now is to add defines for the mux modes from
mach-omap2/mux.h as that makes the raw values readable without
comments.

Regards,

Tony
--
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

Re: [PATCH 2/5] ARM: dts: OMAP2+: create a DT header for GPIO

2013-05-22 Thread Florian Vaussard 

Hello Stephan, Tony,

Thank you for your reviews.

On 05/22/2013 05:34 PM, Tony Lindgren wrote:

* Stephen Warren swar...@wwwdotorg.org [130522 08:32]:

On 05/22/2013 08:27 AM, Florian Vaussard wrote:

Define the OMAP_GPIO macro to conveniently use GPIO inside OMAP DT.
For example:

gpios = gpio6 3 0;  /* GPIO 163 */

can be replaced by

gpios = OMAP_GPIO(163, 0);



diff --git a/include/dt-bindings/gpio/omap-gpio.h 
b/include/dt-bindings/gpio/omap-gpio.h



+#define OMAP_GPIO_0_BANKgpio1
+#define OMAP_GPIO_1_BANKgpio1
+#define OMAP_GPIO_2_BANKgpio1
+#define OMAP_GPIO_3_BANKgpio1


There are a /lot/ of those. Is this really worth it?

If the OMAP GPIO HW is already represented as a bunch of separate DT
nodes which represent separate GPIO blocks, then I would have thought
the syntax gpioN M 0 more directly represents what would be found in
the HW manual? If not, surely the DT should have a single node to
represent a single GPIO controller, which just happens to internally
support a bunch of register arrays.


Yes I agree, let's not go back to numbering anything except within the
a single instance. If anything, we can put the gpio number into comments.



From a board point a view, I consider this macro as being easier to use,
than having to perform the necessary arithmetic to get the bank + offset
for each GPIO when converting existing boards or developing new ones.

But I also agree with you, and I was sad not to find a more elegant
way. Maybe someone with better preprocessor skills could come up with
a better solution?

Regards,

Florian
--
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

Re: [PATCH 3/5] ARM: dts: OMAP2+: convert DT files to use the new OMAP_GPIO macro

2013-05-22 Thread Florian Vaussard 

Hi Stepen,

Thank you for your review,

On 05/22/2013 05:28 PM, Stephen Warren wrote:

On 05/22/2013 08:27 AM, Florian Vaussard wrote:

Use OMAP_GPIO(), in conjunction with standard GPIO flags, to enhance the
readability of DT GPIOs.



diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts 
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index e0ce823..e773a5e 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -29,13 +29,13 @@

heartbeat {
label = beagleboard::usr0;
-   gpios = gpio5 22 0; /* 150 - D6 LED */
+   gpios = OMAP_GPIO(150, GPIO_ACTIVE_HIGH); /* 150 - D6 
LED */


One of the advantages of cpp support for me is the ability to remove the
redundant part of the command. In other words, perhaps remove the 150
- since that information is part of the OMAP_GPIO() call, leaving
just /* D6 LED */. I might have expected D6 to be the label too, thus
removing any need for the comment.



I agree. I removed almost all the comments from the other files. For 
here, I would

leave /* D6 LED */ as you suggest.

Regards,

Florian
--
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

Re: [PATCH 2/5] ARM: dts: OMAP2+: create a DT header for GPIO

2013-05-22 Thread Stephen Warren 
On 05/22/2013 10:00 AM, Florian Vaussard wrote:
 Hello Stephan, Tony,
 
 Thank you for your reviews.
 
 On 05/22/2013 05:34 PM, Tony Lindgren wrote:
 * Stephen Warren swar...@wwwdotorg.org [130522 08:32]:
 On 05/22/2013 08:27 AM, Florian Vaussard wrote:
 Define the OMAP_GPIO macro to conveniently use GPIO inside OMAP DT.
 For example:

 gpios = gpio6 3 0;  /* GPIO 163 */

 can be replaced by

 gpios = OMAP_GPIO(163, 0);

 diff --git a/include/dt-bindings/gpio/omap-gpio.h
 b/include/dt-bindings/gpio/omap-gpio.h

 +#define OMAP_GPIO_0_BANKgpio1
 +#define OMAP_GPIO_1_BANKgpio1
 +#define OMAP_GPIO_2_BANKgpio1
 +#define OMAP_GPIO_3_BANKgpio1

 There are a /lot/ of those. Is this really worth it?
...
 From a board point a view, I consider this macro as being easier to use,
 than having to perform the necessary arithmetic to get the bank + offset
 for each GPIO when converting existing boards or developing new ones.
 
 But I also agree with you, and I was sad not to find a more elegant
 way. Maybe someone with better preprocessor skills could come up with
 a better solution?

I did a quick bit of searching before, and while cpp is certainly
capable of doing the shifting/masking required to calculate the bank ID
directly, I don't think it's capable of constructing the symbol gpio1 as
opposed to the string gpio1:-( I'd love to be proven wrong though, but
the torture e.g. cpp 99 bottles of beer on the wall goes through to
stuff implies it isn't possible.
--
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

Re: [PATCH 1/5] ARM: dts: OMAP2+: use #include for all device trees

2013-05-22 Thread Florian Vaussard 

Hi Tony,

On 05/22/2013 05:40 PM, Tony Lindgren wrote:

* Florian Vaussard florian.vauss...@epfl.ch [130522 07:33]:

Replace /include/ by #include for OMAP2+ DT, in order to use the
C pre-processor, making use of #define features possible.


This is good, but let's use it with case. Probably the best use
for this right now is to add defines for the mux modes from
mach-omap2/mux.h as that makes the raw values readable without
comments.



I think that one first good case is the IRQs in patch 5. But I
agree, adding defines for the mux modes would be great. I can have
a look at it for a v2.

Regards,

Florian
--
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

[RFC PATCH 0/4] regulator/OMAP: support VC/VP support in dts

2013-05-22 Thread Nishanth Menon 
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

2013-05-22 Thread Nishanth Menon 
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

2013-05-22 Thread Nishanth Menon 
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

2013-05-22 Thread Nishanth Menon 
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 in

[RFC PATCH 2/4] PM / AVS: Introduce support for OMAP Voltage Controller(VC) with device tree nodes

2013-05-22 Thread Nishanth Menon 
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
+  -

[RFC/RFT] ARM: dts: add minimal DT support for Nokia N950 N9

2013-05-22 Thread Aaro Koskinen 
Add minimal DT support for Nokia N950  N9. The basic boot works. I can
connect to both devices with USB networking  ssh. dmesg output looks OK.

Functionality compared to the legacy board file:

- MMC not detected - reason unknown, any tips welcome

- OneNAND missing completely

Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
 arch/arm/boot/dts/Makefile   |2 +
 arch/arm/boot/dts/omap3-n9.dts   |   18 
 arch/arm/boot/dts/omap3-n950-n9.dtsi |   84 ++
 arch/arm/boot/dts/omap3-n950.dts |   18 
 4 files changed, 122 insertions(+)
 create mode 100644 arch/arm/boot/dts/omap3-n9.dts
 create mode 100644 arch/arm/boot/dts/omap3-n950-n9.dtsi
 create mode 100644 arch/arm/boot/dts/omap3-n950.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b9f7121..e7e1c82 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -144,6 +144,8 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap3-tobi.dtb \
omap3-igep0020.dtb \
omap3-igep0030.dtb \
+   omap3-n9.dtb \
+   omap3-n950.dtb \
omap4-panda.dtb \
omap4-panda-a4.dtb \
omap4-panda-es.dtb \
diff --git a/arch/arm/boot/dts/omap3-n9.dts b/arch/arm/boot/dts/omap3-n9.dts
new file mode 100644
index 000..0553b33
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-n9.dts
@@ -0,0 +1,18 @@
+/*
+ * omap3-n9.dts - Device Tree file for Nokia N9
+ *
+ * Written by: Aaro Koskinen aaro.koski...@iki.fi
+ *
+ * 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.
+ */
+
+/dts-v1/;
+
+/include/ omap3-n950-n9.dtsi
+
+/ {
+   model = Nokia N9;
+   compatible = nokia,omap3-n9, ti,omap3;
+};
diff --git a/arch/arm/boot/dts/omap3-n950-n9.dtsi 
b/arch/arm/boot/dts/omap3-n950-n9.dtsi
new file mode 100644
index 000..3f983f7
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-n950-n9.dtsi
@@ -0,0 +1,84 @@
+/*
+ * omap3-n950-n9.dtsi - Device Tree file for Nokia N950  N9 (common stuff)
+ *
+ * Written by: Aaro Koskinen aaro.koski...@iki.fi
+ *
+ * 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/ omap36xx.dtsi
+
+/ {
+   cpus {
+   cpu@0 {
+   cpu0-supply = vcc;
+   };
+   };
+
+   memory {
+   device_type = memory;
+   reg = 0x8000 0x4000; /* 1 GB */
+   };
+
+   rm6xx_vemmc: fixedregulator@0 {
+   compatible = regulator-fixed;
+   regulator-name = VEMMC;
+   regulator-min-microvolt = 290;
+   regulator-max-microvolt = 290;
+   gpio = gpio5 29 0; /* gpio line 157 */
+   startup-delay-us = 150;
+   enable-active-high;
+   };
+};
+
+i2c1 {
+   clock-frequency = 290;
+
+   twl: twl@48 {
+   reg = 0x48;
+   interrupts = 7; /* SYS_NIRQ cascaded to intc */
+   interrupt-parent = intc;
+   };
+};
+
+/include/ twl4030.dtsi
+
+twl {
+   compatible = ti,twl5031;
+};
+
+twl_gpio {
+   ti,pullups  = 0x01; /* BIT(0) */
+   ti,pulldowns= 0x008106; /* BIT(1) | BIT(2) | BIT(8) | BIT(15) */
+};
+
+i2c2 {
+   clock-frequency = 40;
+};
+
+i2c3 {
+   clock-frequency = 40;
+};
+
+mmc1 {
+   status = disabled;
+};
+
+mmc2 {
+   vmmc-supply = rm6xx_vemmc;
+   bus-width = 4;
+   ti,non-removable;
+};
+
+mmc3 {
+   status = disabled;
+};
+
+usb_otg_hs {
+   interface-type = 0;
+   usb-phy = usb2_phy;
+   mode = 3;
+   power = 50;
+};
diff --git a/arch/arm/boot/dts/omap3-n950.dts b/arch/arm/boot/dts/omap3-n950.dts
new file mode 100644
index 000..25fd9ec
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-n950.dts
@@ -0,0 +1,18 @@
+/*
+ * omap3-n950.dts - Device Tree file for Nokia N950
+ *
+ * Written by: Aaro Koskinen aaro.koski...@iki.fi
+ *
+ * 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.
+ */
+
+/dts-v1/;
+
+/include/ omap3-n950-n9.dtsi
+
+/ {
+   model = Nokia N950;
+   compatible = nokia,omap3-n950, ti,omap3;
+};
-- 
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

Re: [GIT PULL] ARM: OMAP2+: hwmod/serial: fix DT case

2013-05-22 Thread Olof Johansson 
On Tue, May 21, 2013 at 11:11:10AM -0700, Tony Lindgren wrote:
 Olof,
 
 Care to pull this into your fixes directly?


Pulled, thanks.

-Olof
--
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

Re: [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression

2013-05-22 Thread Aaro Koskinen 
On Tue, May 21, 2013 at 08:37:16PM +0100, Jon Hunter wrote:
 On 21/05/13 18:39, Aaro Koskinen wrote:
  On Mon, May 20, 2013 at 10:46:21AM -0700, Tony Lindgren wrote:
  * Tony Lindgren t...@atomide.com [130516 14:50]:
  * Aaro Koskinen aaro.koski...@iki.fi [130516 14:05]:
  On Thu, May 16, 2013 at 11:09:34AM -0700, Tony Lindgren wrote:
  * Aaro Koskinen aaro.koski...@iki.fi [130513 13:58]:
  I tested 3.10-rc1 on OMAP1 / Nokia 770, and Retu MFD probe is broken:
 
  [2.264221] retu-mfd 2-0001: Retu v3.2 found
  [2.281951] retu-mfd 2-0001: Failed to allocate IRQs: -12
  [2.300140] retu-mfd: probe of 2-0001 failed with error -12
 
  The error is coming from regmap code. According to git bisect, it is
  caused by:
 
 commit ede4d7a5b9835510fd1f724367f68d2fa4128453
 Author: Jon Hunter jon-hun...@ti.com
 Date:   Fri Mar 1 11:22:47 2013 -0600
 
 gpio/omap: convert gpio irq domain to linear mapping
 
  The commit does not anymore revert cleanly, and I haven't yet tried
  crafting a manual revert, so any fix proposals/ideas are welcome...
 
  Hmm this might be a bit trickier to fix. Obviously the real solution
  is to convert omap1 to SPARSE_IRQ like we did for omap2+.
 
  For the -rc cycle, it might be possible to fix this by adding a
  different irq_to_gpio() and gpio_to_irq() functions for omap1.
 
  The commit reverts cleanly if we also revert
  3513cdeccc647d41c4a9ff923af17deaaac04a66 (gpio/omap: optimise interrupt
  service routine), which seems to be just some minor optimization. The
  result is below, and with it 770 works again.
 
  Hmm in this case it seems that we should just fix it rather than go back
  to the old code, so let's take a look at that first.
 
  Does the following fix it for you or do we need to fix something else
  there too?
  
  Thanks, that fixes Retu probe on 770.
 
 Sorry for not responding sooner, but I have been moving. 
 
 From looking at the code it appears that the regmap_add_irq_chip()
 is failing in the retu driver. I am not sure if this will work, 
 but have you tried making the following change to the retu driver 
 so that it also uses irq_domain_add_linear() as well? Just a thought ...

This will trigger WARNING: at drivers/base/regmap/regmap-irq.c:514.

Also other drivers report GPIO IRQ issues later in the boot, e.g.

[3.907928] genirq: Flags mismatch irq 0. 0001 (serial wakeup) vs. 
2000 (RETU)
[3.923706] No interrupt for UART wake GPIO: 37

With Tony's patch (without any Retu modifications), the boot is clean. So
I guess gpio-omap fix is needed.

A.

 diff --git a/drivers/mfd/retu-mfd.c b/drivers/mfd/retu-mfd.c
 index a183098..7ad8cd4 100644
 --- a/drivers/mfd/retu-mfd.c
 +++ b/drivers/mfd/retu-mfd.c
 @@ -267,7 +267,7 @@ static int retu_probe(struct i2c_client *i2c, const 
 struct i2c_device_id *id)
 if (ret  0)
 return ret;
  
 -   ret = regmap_add_irq_chip(rdev-regmap, i2c-irq, IRQF_ONESHOT, -1,
 +   ret = regmap_add_irq_chip(rdev-regmap, i2c-irq, IRQF_ONESHOT, 0,
   rdat-irq_chip, rdev-irq_data);
 if (ret  0)
 return ret;
 
--
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