* [PATCH 1/9] ARM: OMAP2+: Prepare for device-tree PMU support
2013-03-08 17:27 [PATCH 0/9] ARM: dts: Various OMAP2+ device-tree updates Jon Hunter
@ 2013-03-08 17:27 ` Jon Hunter
2013-03-08 17:27 ` [PATCH 2/9] ARM: dts: OMAP2+: Add PMU nodes Jon Hunter
` (8 subsequent siblings)
9 siblings, 0 replies; 37+ messages in thread
From: Jon Hunter @ 2013-03-08 17:27 UTC (permalink / raw)
To: Tony Lindgren, Benoit Cousson
Cc: device-tree, linux-omap, linux-arm, Jon Hunter
If device-tree is present, then do not create the PMU device from within
the OMAP specific PMU code. This is required to allow device-tree to
create the PMU device from the PMU device-tree node.
PMU is not currently supported for OMAP4430 (due to a dependency on
having a cross-trigger interface driver) and so ensure that this
indicated on boot with or without device-tree.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap2/pmu.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/pmu.c b/arch/arm/mach-omap2/pmu.c
index 9debf82..9ace8ea 100644
--- a/arch/arm/mach-omap2/pmu.c
+++ b/arch/arm/mach-omap2/pmu.c
@@ -11,6 +11,8 @@
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*/
+#include <linux/of.h>
+
#include <asm/pmu.h>
#include "soc.h"
@@ -63,6 +65,15 @@ static int __init omap_init_pmu(void)
unsigned oh_num;
char **oh_names;
+ /* XXX Remove this check when the CTI driver is available */
+ if (cpu_is_omap443x()) {
+ pr_info("ARM PMU: not yet supported on OMAP4430 due to missing CTI driver\n");
+ return 0;
+ }
+
+ if (of_have_populated_dt())
+ return 0;
+
/*
* To create an ARM-PMU device the following HWMODs
* are required for the various OMAP2+ devices.
@@ -75,9 +86,6 @@ static int __init omap_init_pmu(void)
if (cpu_is_omap443x()) {
oh_num = ARRAY_SIZE(omap4430_pmu_oh_names);
oh_names = omap4430_pmu_oh_names;
- /* XXX Remove the next two lines when CTI driver available */
- pr_info("ARM PMU: not yet supported on OMAP4430 due to missing CTI driver\n");
- return 0;
} else if (cpu_is_omap34xx() || cpu_is_omap44xx()) {
oh_num = ARRAY_SIZE(omap3_pmu_oh_names);
oh_names = omap3_pmu_oh_names;
--
1.7.10.4
^ permalink raw reply related [flat|nested] 37+ messages in thread* [PATCH 2/9] ARM: dts: OMAP2+: Add PMU nodes
2013-03-08 17:27 [PATCH 0/9] ARM: dts: Various OMAP2+ device-tree updates Jon Hunter
2013-03-08 17:27 ` [PATCH 1/9] ARM: OMAP2+: Prepare for device-tree PMU support Jon Hunter
@ 2013-03-08 17:27 ` Jon Hunter
2013-03-08 17:27 ` [PATCH 3/9] ARM: dts: OMAP2+: Add SDMA controller bindings and nodes Jon Hunter
` (7 subsequent siblings)
9 siblings, 0 replies; 37+ messages in thread
From: Jon Hunter @ 2013-03-08 17:27 UTC (permalink / raw)
To: Tony Lindgren, Benoit Cousson
Cc: device-tree, linux-omap, linux-arm, Jon Hunter
Add PMU nodes for OMAP2, OMAP3 and OMAP4460 devices.
Please note that the node for OMAP4460 has been placed in a separate
header file for OMAP4460, because the node is not compatible with
OMAP4430. The node for OMAP4430 is not included because PMU is not
currently supported on OMAP4430 due to the absence of a cross-trigger
interface driver.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
---
arch/arm/boot/dts/omap2.dtsi | 5 +++++
arch/arm/boot/dts/omap3.dtsi | 6 ++++++
arch/arm/boot/dts/omap4-panda-es.dts | 2 ++
arch/arm/boot/dts/omap4460.dtsi | 18 ++++++++++++++++++
4 files changed, 31 insertions(+)
create mode 100644 arch/arm/boot/dts/omap4460.dtsi
diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
index 761c4b6..27f5ea1 100644
--- a/arch/arm/boot/dts/omap2.dtsi
+++ b/arch/arm/boot/dts/omap2.dtsi
@@ -26,6 +26,11 @@
};
};
+ pmu {
+ compatible = "arm,arm1136-pmu";
+ interrupts = <3>;
+ };
+
soc {
compatible = "ti,omap-infra";
mpu {
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 9f36531..2ddae38 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -26,6 +26,12 @@
};
};
+ pmu {
+ compatible = "arm,cortex-a8-pmu";
+ interrupts = <3>;
+ ti,hwmods = "debugss";
+ };
+
/*
* The soc node represents the soc top level view. It is uses for IPs
* that are not memory mapped in the MPU view or for the MPU itself.
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts b/arch/arm/boot/dts/omap4-panda-es.dts
index 73bc1a6..2a6e344 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -5,7 +5,9 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
+
/include/ "omap4-panda.dts"
+/include/ "omap4460.dtsi"
/* Audio routing is differnet between PandaBoard4430 and PandaBoardES */
&sound {
diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
new file mode 100644
index 0000000..0a1d38b
--- /dev/null
+++ b/arch/arm/boot/dts/omap4460.dtsi
@@ -0,0 +1,18 @@
+/*
+ * Device Tree Source for OMAP4460 SoC
+ *
+ * Copyright (C) 2012 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.
+ */
+
+/ {
+ pmu {
+ compatible = "arm,cortex-a9-pmu";
+ interrupts = <0 54 0x4>,
+ <0 55 0x4>;
+ ti,hwmods = "debugss";
+ };
+};
--
1.7.10.4
^ permalink raw reply related [flat|nested] 37+ messages in thread* [PATCH 3/9] ARM: dts: OMAP2+: Add SDMA controller bindings and nodes
2013-03-08 17:27 [PATCH 0/9] ARM: dts: Various OMAP2+ device-tree updates Jon Hunter
2013-03-08 17:27 ` [PATCH 1/9] ARM: OMAP2+: Prepare for device-tree PMU support Jon Hunter
2013-03-08 17:27 ` [PATCH 2/9] ARM: dts: OMAP2+: Add PMU nodes Jon Hunter
@ 2013-03-08 17:27 ` Jon Hunter
2013-03-08 17:27 ` [PATCH 4/9] ARM: dts: OMAP3: Add support for OMAP3430 SDP board Jon Hunter
` (6 subsequent siblings)
9 siblings, 0 replies; 37+ messages in thread
From: Jon Hunter @ 2013-03-08 17:27 UTC (permalink / raw)
To: Tony Lindgren, Benoit Cousson
Cc: device-tree, linux-omap, linux-arm, Jon Hunter
Add SDMA controller binding for OMAP2+ devices and populate DMA client
information for SPI and MMC periperhal on OMAP3+ devices. Please note
that OMAP24xx devices do not have SPI and MMC bindings available yet and
so DMA client information is not populated.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Reviewed-by: Felipe Balbi <balbi@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
.../devicetree/bindings/dma/omap-sdma.txt | 51 ++++++++++++++++++++
arch/arm/boot/dts/omap2.dtsi | 12 +++++
arch/arm/boot/dts/omap3.dtsi | 40 +++++++++++++++
arch/arm/boot/dts/omap4.dtsi | 41 ++++++++++++++++
arch/arm/boot/dts/omap5.dtsi | 41 ++++++++++++++++
5 files changed, 185 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/omap-sdma.txt
diff --git a/Documentation/devicetree/bindings/dma/omap-sdma.txt b/Documentation/devicetree/bindings/dma/omap-sdma.txt
new file mode 100644
index 0000000..22aab28
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/omap-sdma.txt
@@ -0,0 +1,51 @@
+* TI OMAP SDMA controller
+
+Required properties:
+- compatible: Should be set to one of the following:
+
+ ti,omap2420-sdma (omap2420)
+ ti,omap2430-sdma (omap2430)
+ ti,omap3430-sdma (omap3430)
+ ti,omap3630-sdma (omap3630)
+ ti,omap4430-sdma (omap4430 & omap4460 & omap543x)
+
+- reg: Contains DMA registers location and length.
+- interrupts: Contains DMA interrupt information.
+- #dma-cells: Must be 1.
+- #dma-channels: Contains total number of programmable DMA channels.
+- #dma-requests: Contains total number of DMA requests.
+
+Example:
+
+ sdma: dma-controller@4A056000 {
+ compatible = "ti,omap-sdma";
+ reg = <0x4A056000 0x1000>;
+ interrupts = <0 12 0x4>,
+ <0 13 0x4>,
+ <0 14 0x4>,
+ <0 15 0x4>;
+ #dma-cells = <1>;
+ #dma-channels = <32>;
+ #dma-requests = <127>;
+ };
+
+
+* TI OMAP SDMA clients
+
+Required properties:
+- dmas: List of one or more DMA specifiers, each consisting of
+ - A phandle pointing to DMA controller node
+ - The DMA request number associated with client device
+- dma-names: Contains one identifier string for each dma specifier in
+ the dmas property. The specific strings that can be used
+ are defined in the binding of the DMA client device.
+
+Example:
+
+ mmc1: mmc@4809c000 {
+ ...
+ dmas = <&sdma 61>, /* TX channel */
+ <&sdma 62>; /* RX channel */
+ dma-names = "tx", "rx";
+ ...
+ };
diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
index 27f5ea1..84183f0 100644
--- a/arch/arm/boot/dts/omap2.dtsi
+++ b/arch/arm/boot/dts/omap2.dtsi
@@ -54,6 +54,18 @@
reg = <0x480FE000 0x1000>;
};
+ sdma: dma-controller@48056000 {
+ compatible = "ti,omap2430-sdma", "ti,omap2420-sdma";
+ reg = <0x48056000 0x1000>;
+ interrupts = <12>,
+ <13>,
+ <14>,
+ <15>;
+ #dma-cells = <1>;
+ #dma-channels = <32>;
+ #dma-requests = <64>;
+ };
+
uart1: serial@4806a000 {
compatible = "ti,omap2-uart";
ti,hwmods = "uart1";
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 2ddae38..5b36de5 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -81,6 +81,18 @@
reg = <0x48200000 0x1000>;
};
+ sdma: dma-controller@48056000 {
+ compatible = "ti,omap3630-sdma", "ti,omap3430-sdma";
+ reg = <0x48056000 0x1000>;
+ interrupts = <12>,
+ <13>,
+ <14>,
+ <15>;
+ #dma-cells = <1>;
+ #dma-channels = <32>;
+ #dma-requests = <96>;
+ };
+
omap3_pmx_core: pinmux@48002030 {
compatible = "ti,omap3-padconf", "pinctrl-single";
reg = <0x48002030 0x05cc>;
@@ -198,6 +210,16 @@
#size-cells = <0>;
ti,hwmods = "mcspi1";
ti,spi-num-cs = <4>;
+ dmas = <&sdma 35>,
+ <&sdma 36>,
+ <&sdma 37>,
+ <&sdma 38>,
+ <&sdma 39>,
+ <&sdma 40>,
+ <&sdma 41>,
+ <&sdma 42>;
+ dma-names = "tx0", "rx0", "tx1", "rx1",
+ "tx2", "rx2", "tx3", "rx3";
};
mcspi2: spi@4809a000 {
@@ -206,6 +228,11 @@
#size-cells = <0>;
ti,hwmods = "mcspi2";
ti,spi-num-cs = <2>;
+ dmas = <&sdma 43>,
+ <&sdma 44>,
+ <&sdma 45>,
+ <&sdma 46>;
+ dma-names = "tx0", "rx0", "tx1", "rx1";
};
mcspi3: spi@480b8000 {
@@ -214,6 +241,11 @@
#size-cells = <0>;
ti,hwmods = "mcspi3";
ti,spi-num-cs = <2>;
+ dmas = <&sdma 15>,
+ <&sdma 16>,
+ <&sdma 23>,
+ <&sdma 24>;
+ dma-names = "tx0", "rx0", "tx1", "rx1";
};
mcspi4: spi@480ba000 {
@@ -222,22 +254,30 @@
#size-cells = <0>;
ti,hwmods = "mcspi4";
ti,spi-num-cs = <1>;
+ dmas = <&sdma 70>, <&sdma 71>;
+ dma-names = "tx0", "rx0";
};
mmc1: mmc@4809c000 {
compatible = "ti,omap3-hsmmc";
ti,hwmods = "mmc1";
ti,dual-volt;
+ dmas = <&sdma 61>, <&sdma 62>;
+ dma-names = "tx", "rx";
};
mmc2: mmc@480b4000 {
compatible = "ti,omap3-hsmmc";
ti,hwmods = "mmc2";
+ dmas = <&sdma 47>, <&sdma 48>;
+ dma-names = "tx", "rx";
};
mmc3: mmc@480ad000 {
compatible = "ti,omap3-hsmmc";
ti,hwmods = "mmc3";
+ dmas = <&sdma 77>, <&sdma 78>;
+ dma-names = "tx", "rx";
};
wdt2: wdt@48314000 {
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 739bb79..827f6f3 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -118,6 +118,18 @@
pinctrl-single,function-mask = <0x7fff>;
};
+ sdma: dma-controller@4A056000 {
+ compatible = "ti,omap4430-sdma";
+ reg = <0x4A056000 0x1000>;
+ interrupts = <0 12 0x4>,
+ <0 13 0x4>,
+ <0 14 0x4>,
+ <0 15 0x4>;
+ #dma-cells = <1>;
+ #dma-channels = <32>;
+ #dma-requests = <127>;
+ };
+
gpio1: gpio@4a310000 {
compatible = "ti,omap4-gpio";
reg = <0x4a310000 0x200>;
@@ -260,6 +272,16 @@
#size-cells = <0>;
ti,hwmods = "mcspi1";
ti,spi-num-cs = <4>;
+ dmas = <&sdma 35>,
+ <&sdma 36>,
+ <&sdma 37>,
+ <&sdma 38>,
+ <&sdma 39>,
+ <&sdma 40>,
+ <&sdma 41>,
+ <&sdma 42>;
+ dma-names = "tx0", "rx0", "tx1", "rx1",
+ "tx2", "rx2", "tx3", "rx3";
};
mcspi2: spi@4809a000 {
@@ -270,6 +292,11 @@
#size-cells = <0>;
ti,hwmods = "mcspi2";
ti,spi-num-cs = <2>;
+ dmas = <&sdma 43>,
+ <&sdma 44>,
+ <&sdma 45>,
+ <&sdma 46>;
+ dma-names = "tx0", "rx0", "tx1", "rx1";
};
mcspi3: spi@480b8000 {
@@ -280,6 +307,8 @@
#size-cells = <0>;
ti,hwmods = "mcspi3";
ti,spi-num-cs = <2>;
+ dmas = <&sdma 15>, <&sdma 16>;
+ dma-names = "tx0", "rx0";
};
mcspi4: spi@480ba000 {
@@ -290,6 +319,8 @@
#size-cells = <0>;
ti,hwmods = "mcspi4";
ti,spi-num-cs = <1>;
+ dmas = <&sdma 70>, <&sdma 71>;
+ dma-names = "tx0", "rx0";
};
mmc1: mmc@4809c000 {
@@ -299,6 +330,8 @@
ti,hwmods = "mmc1";
ti,dual-volt;
ti,needs-special-reset;
+ dmas = <&sdma 61>, <&sdma 62>;
+ dma-names = "tx", "rx";
};
mmc2: mmc@480b4000 {
@@ -307,6 +340,8 @@
interrupts = <0 86 0x4>;
ti,hwmods = "mmc2";
ti,needs-special-reset;
+ dmas = <&sdma 47>, <&sdma 48>;
+ dma-names = "tx", "rx";
};
mmc3: mmc@480ad000 {
@@ -315,6 +350,8 @@
interrupts = <0 94 0x4>;
ti,hwmods = "mmc3";
ti,needs-special-reset;
+ dmas = <&sdma 77>, <&sdma 78>;
+ dma-names = "tx", "rx";
};
mmc4: mmc@480d1000 {
@@ -323,6 +360,8 @@
interrupts = <0 96 0x4>;
ti,hwmods = "mmc4";
ti,needs-special-reset;
+ dmas = <&sdma 57>, <&sdma 58>;
+ dma-names = "tx", "rx";
};
mmc5: mmc@480d5000 {
@@ -331,6 +370,8 @@
interrupts = <0 59 0x4>;
ti,hwmods = "mmc5";
ti,needs-special-reset;
+ dmas = <&sdma 59>, <&sdma 60>;
+ dma-names = "tx", "rx";
};
wdt2: wdt@4a314000 {
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 9e182a9..06d21d6 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -108,6 +108,18 @@
<0x48212000 0x1000>;
};
+ sdma: dma-controller@4A056000 {
+ compatible = "ti,omap4430-sdma";
+ reg = <0x4A056000 0x1000>;
+ interrupts = <0 12 0x4>,
+ <0 13 0x4>,
+ <0 14 0x4>,
+ <0 15 0x4>;
+ #dma-cells = <1>;
+ #dma-channels = <32>;
+ #dma-requests = <127>;
+ };
+
gpio1: gpio@4ae10000 {
compatible = "ti,omap4-gpio";
reg = <0x4ae10000 0x200>;
@@ -249,6 +261,16 @@
#size-cells = <0>;
ti,hwmods = "mcspi1";
ti,spi-num-cs = <4>;
+ dmas = <&sdma 35>,
+ <&sdma 36>,
+ <&sdma 37>,
+ <&sdma 38>,
+ <&sdma 39>,
+ <&sdma 40>,
+ <&sdma 41>,
+ <&sdma 42>;
+ dma-names = "tx0", "rx0", "tx1", "rx1",
+ "tx2", "rx2", "tx3", "rx3";
};
mcspi2: spi@4809a000 {
@@ -259,6 +281,11 @@
#size-cells = <0>;
ti,hwmods = "mcspi2";
ti,spi-num-cs = <2>;
+ dmas = <&sdma 43>,
+ <&sdma 44>,
+ <&sdma 45>,
+ <&sdma 46>;
+ dma-names = "tx0", "rx0", "tx1", "rx1";
};
mcspi3: spi@480b8000 {
@@ -269,6 +296,8 @@
#size-cells = <0>;
ti,hwmods = "mcspi3";
ti,spi-num-cs = <2>;
+ dmas = <&sdma 15>, <&sdma 16>;
+ dma-names = "tx0", "rx0";
};
mcspi4: spi@480ba000 {
@@ -279,6 +308,8 @@
#size-cells = <0>;
ti,hwmods = "mcspi4";
ti,spi-num-cs = <1>;
+ dmas = <&sdma 70>, <&sdma 71>;
+ dma-names = "tx0", "rx0";
};
uart1: serial@4806a000 {
@@ -336,6 +367,8 @@
ti,hwmods = "mmc1";
ti,dual-volt;
ti,needs-special-reset;
+ dmas = <&sdma 61>, <&sdma 62>;
+ dma-names = "tx", "rx";
};
mmc2: mmc@480b4000 {
@@ -344,6 +377,8 @@
interrupts = <0 86 0x4>;
ti,hwmods = "mmc2";
ti,needs-special-reset;
+ dmas = <&sdma 47>, <&sdma 48>;
+ dma-names = "tx", "rx";
};
mmc3: mmc@480ad000 {
@@ -352,6 +387,8 @@
interrupts = <0 94 0x4>;
ti,hwmods = "mmc3";
ti,needs-special-reset;
+ dmas = <&sdma 77>, <&sdma 78>;
+ dma-names = "tx", "rx";
};
mmc4: mmc@480d1000 {
@@ -360,6 +397,8 @@
interrupts = <0 96 0x4>;
ti,hwmods = "mmc4";
ti,needs-special-reset;
+ dmas = <&sdma 57>, <&sdma 58>;
+ dma-names = "tx", "rx";
};
mmc5: mmc@480d5000 {
@@ -368,6 +407,8 @@
interrupts = <0 59 0x4>;
ti,hwmods = "mmc5";
ti,needs-special-reset;
+ dmas = <&sdma 59>, <&sdma 60>;
+ dma-names = "tx", "rx";
};
keypad: keypad@4ae1c000 {
--
1.7.10.4
^ permalink raw reply related [flat|nested] 37+ messages in thread* [PATCH 4/9] ARM: dts: OMAP3: Add support for OMAP3430 SDP board
2013-03-08 17:27 [PATCH 0/9] ARM: dts: Various OMAP2+ device-tree updates Jon Hunter
` (2 preceding siblings ...)
2013-03-08 17:27 ` [PATCH 3/9] ARM: dts: OMAP2+: Add SDMA controller bindings and nodes Jon Hunter
@ 2013-03-08 17:27 ` Jon Hunter
2013-03-09 2:25 ` Anil Kumar
2013-03-11 2:45 ` Anil Kumar
2013-03-08 17:27 ` [PATCH 5/9] ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5 Jon Hunter
` (5 subsequent siblings)
9 siblings, 2 replies; 37+ messages in thread
From: Jon Hunter @ 2013-03-08 17:27 UTC (permalink / raw)
To: Tony Lindgren, Benoit Cousson
Cc: device-tree, linux-omap, linux-arm, Jon Hunter
Adds basic device-tree support for OMAP3430 SDP board which has 256MB
of RAM and uses the TWL4030 power management IC.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/omap3430-sdp.dts | 46 ++++++++++++++++++++++++++++++++++++
2 files changed, 47 insertions(+)
create mode 100644 arch/arm/boot/dts/omap3430-sdp.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 9c62558..89013ed 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -119,6 +119,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap3-beagle-xm.dtb \
omap3-evm.dtb \
omap3-tobi.dtb \
+ omap3430-sdp.dtb \
omap4-panda.dtb \
omap4-panda-a4.dtb \
omap4-panda-es.dtb \
diff --git a/arch/arm/boot/dts/omap3430-sdp.dts b/arch/arm/boot/dts/omap3430-sdp.dts
new file mode 100644
index 0000000..be0650d
--- /dev/null
+++ b/arch/arm/boot/dts/omap3430-sdp.dts
@@ -0,0 +1,46 @@
+/*
+ * Copyright (C) 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.
+ */
+/dts-v1/;
+
+/include/ "omap3.dtsi"
+
+/ {
+ model = "TI OMAP3430 SDP";
+ compatible = "ti,omap3430-sdp", "ti,omap3";
+
+ memory {
+ device_type = "memory";
+ reg = <0x80000000 0x10000000>; /* 256 MB */
+ };
+};
+
+&i2c1 {
+ clock-frequency = <2600000>;
+
+ twl: twl@48 {
+ reg = <0x48>;
+ interrupts = <7>; /* SYS_NIRQ cascaded to intc */
+ interrupt-parent = <&intc>;
+ };
+};
+
+/include/ "twl4030.dtsi"
+
+&mmc1 {
+ vmmc-supply = <&vmmc1>;
+ vmmc_aux-supply = <&vsim>;
+ bus-width = <8>;
+};
+
+&mmc2 {
+ status = "disabled";
+};
+
+&mmc3 {
+ status = "disabled";
+};
--
1.7.10.4
^ permalink raw reply related [flat|nested] 37+ messages in thread* Re: [PATCH 4/9] ARM: dts: OMAP3: Add support for OMAP3430 SDP board
2013-03-08 17:27 ` [PATCH 4/9] ARM: dts: OMAP3: Add support for OMAP3430 SDP board Jon Hunter
@ 2013-03-09 2:25 ` Anil Kumar
2013-03-11 17:53 ` Jon Hunter
2013-03-11 2:45 ` Anil Kumar
1 sibling, 1 reply; 37+ messages in thread
From: Anil Kumar @ 2013-03-09 2:25 UTC (permalink / raw)
To: Jon Hunter
Cc: Tony Lindgren, Benoit Cousson, device-tree, linux-omap, linux-arm
Hi Jon,
On Fri, Mar 8, 2013 at 10:57 PM, Jon Hunter <jon-hunter@ti.com> wrote:
> Adds basic device-tree support for OMAP3430 SDP board which has 256MB
> of RAM and uses the TWL4030 power management IC.
I think this board support should be in separate patch series with
related patches.
>
> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/omap3430-sdp.dts | 46 ++++++++++++++++++++++++++++++++++++
> 2 files changed, 47 insertions(+)
> create mode 100644 arch/arm/boot/dts/omap3430-sdp.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 9c62558..89013ed 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -119,6 +119,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
> omap3-beagle-xm.dtb \
> omap3-evm.dtb \
> omap3-tobi.dtb \
> + omap3430-sdp.dtb \
> omap4-panda.dtb \
> omap4-panda-a4.dtb \
> omap4-panda-es.dtb \
> diff --git a/arch/arm/boot/dts/omap3430-sdp.dts b/arch/arm/boot/dts/omap3430-sdp.dts
> new file mode 100644
> index 0000000..be0650d
> --- /dev/null
> +++ b/arch/arm/boot/dts/omap3430-sdp.dts
> @@ -0,0 +1,46 @@
> +/*
> + * Copyright (C) 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.
> + */
> +/dts-v1/;
> +
> +/include/ "omap3.dtsi"
> +
> +/ {
> + model = "TI OMAP3430 SDP";
> + compatible = "ti,omap3430-sdp", "ti,omap3";
I have not seen any related changes in "board-generic.c" for your board.
So just wanted know, how this board is booting ?
> +
> + memory {
> + device_type = "memory";
> + reg = <0x80000000 0x10000000>; /* 256 MB */
> + };
> +};
> +
> +&i2c1 {
> + clock-frequency = <2600000>;
> +
> + twl: twl@48 {
> + reg = <0x48>;
> + interrupts = <7>; /* SYS_NIRQ cascaded to intc */
> + interrupt-parent = <&intc>;
> + };
> +};
> +
> +/include/ "twl4030.dtsi"
> +
> +&mmc1 {
> + vmmc-supply = <&vmmc1>;
> + vmmc_aux-supply = <&vsim>;
> + bus-width = <8>;
> +};
> +
> +&mmc2 {
> + status = "disabled";
> +};
> +
> +&mmc3 {
> + status = "disabled";
> +};
I think you should disable modules those are not currently used
as they are enabled by default in omap3.dtsi.
exp:-
&mcbsp2 {
status = "disabled";
};
> --
> 1.7.10.4
>
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: [PATCH 4/9] ARM: dts: OMAP3: Add support for OMAP3430 SDP board
2013-03-09 2:25 ` Anil Kumar
@ 2013-03-11 17:53 ` Jon Hunter
2013-03-12 2:42 ` Kumar, Anil
0 siblings, 1 reply; 37+ messages in thread
From: Jon Hunter @ 2013-03-11 17:53 UTC (permalink / raw)
To: Anil Kumar
Cc: Tony Lindgren, Benoit Cousson, device-tree, linux-omap, linux-arm
On 03/08/2013 08:25 PM, Anil Kumar wrote:
> Hi Jon,
>
> On Fri, Mar 8, 2013 at 10:57 PM, Jon Hunter <jon-hunter@ti.com> wrote:
>> Adds basic device-tree support for OMAP3430 SDP board which has 256MB
>> of RAM and uses the TWL4030 power management IC.
>
> I think this board support should be in separate patch series with
> related patches.
Well I wanted to keep them altogether so that I can send a pull request
to Benoit and Tony.
>>
>> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
>> ---
>> arch/arm/boot/dts/Makefile | 1 +
>> arch/arm/boot/dts/omap3430-sdp.dts | 46 ++++++++++++++++++++++++++++++++++++
>> 2 files changed, 47 insertions(+)
>> create mode 100644 arch/arm/boot/dts/omap3430-sdp.dts
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 9c62558..89013ed 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -119,6 +119,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
>> omap3-beagle-xm.dtb \
>> omap3-evm.dtb \
>> omap3-tobi.dtb \
>> + omap3430-sdp.dtb \
>> omap4-panda.dtb \
>> omap4-panda-a4.dtb \
>> omap4-panda-es.dtb \
>> diff --git a/arch/arm/boot/dts/omap3430-sdp.dts b/arch/arm/boot/dts/omap3430-sdp.dts
>> new file mode 100644
>> index 0000000..be0650d
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/omap3430-sdp.dts
>> @@ -0,0 +1,46 @@
>> +/*
>> + * Copyright (C) 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.
>> + */
>> +/dts-v1/;
>> +
>> +/include/ "omap3.dtsi"
>> +
>> +/ {
>> + model = "TI OMAP3430 SDP";
>> + compatible = "ti,omap3430-sdp", "ti,omap3";
>
> I have not seen any related changes in "board-generic.c" for your board.
> So just wanted know, how this board is booting ?
If you look at board-generic.c you will see that "ti,omap3" will match
the OMAP3 generic machine. So you don't need to modify the board-generic.c.
>> +
>> + memory {
>> + device_type = "memory";
>> + reg = <0x80000000 0x10000000>; /* 256 MB */
>> + };
>> +};
>> +
>> +&i2c1 {
>> + clock-frequency = <2600000>;
>> +
>> + twl: twl@48 {
>> + reg = <0x48>;
>> + interrupts = <7>; /* SYS_NIRQ cascaded to intc */
>> + interrupt-parent = <&intc>;
>> + };
>> +};
>> +
>> +/include/ "twl4030.dtsi"
>> +
>> +&mmc1 {
>> + vmmc-supply = <&vmmc1>;
>> + vmmc_aux-supply = <&vsim>;
>> + bus-width = <8>;
>> +};
>> +
>> +&mmc2 {
>> + status = "disabled";
>> +};
>> +
>> +&mmc3 {
>> + status = "disabled";
>> +};
>
> I think you should disable modules those are not currently used
> as they are enabled by default in omap3.dtsi.
>
> exp:-
>
> &mcbsp2 {
> status = "disabled";
> };
Well may be we could do that in a follow-up patch. If you look at other
omap3 boards we have not gone through and disabled all unused modules
either. So although I agree, right now I just want to get minimal
support added.
Jon
^ permalink raw reply [flat|nested] 37+ messages in thread* RE: [PATCH 4/9] ARM: dts: OMAP3: Add support for OMAP3430 SDP board
2013-03-11 17:53 ` Jon Hunter
@ 2013-03-12 2:42 ` Kumar, Anil
2013-03-12 8:50 ` Javier Martinez Canillas
2013-03-12 21:27 ` Jon Hunter
0 siblings, 2 replies; 37+ messages in thread
From: Kumar, Anil @ 2013-03-12 2:42 UTC (permalink / raw)
To: Hunter, Jon
Cc: Tony Lindgren, device-tree, linux-omap, Cousson, Benoit,
linux-arm, Anil Kumar
On Mon, Mar 11, 2013 at 23:23:32, Hunter, Jon wrote:
>
> On 03/08/2013 08:25 PM, Anil Kumar wrote:
> > Hi Jon,
> >
> > On Fri, Mar 8, 2013 at 10:57 PM, Jon Hunter <jon-hunter@ti.com> wrote:
> >> Adds basic device-tree support for OMAP3430 SDP board which has 256MB
> >> of RAM and uses the TWL4030 power management IC.
> >
> > I think this board support should be in separate patch series with
> > related patches.
>
> Well I wanted to keep them altogether so that I can send a pull request
> to Benoit and Tony.
Sorry, but can you please tell what makes you to think that you
can send pull request only when they are altogether ?
Is there any logical dependency with other patches except
"[PATCH 6/9] ARM: dts: Add OMAP3430 SDP flash memory bindings" is on
top of this patch ?
>
> >>
> >> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
> >> ---
> >> arch/arm/boot/dts/Makefile | 1 +
> >> arch/arm/boot/dts/omap3430-sdp.dts | 46 ++++++++++++++++++++++++++++++++++++
> >> 2 files changed, 47 insertions(+)
> >> create mode 100644 arch/arm/boot/dts/omap3430-sdp.dts
> >>
> >> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> >> index 9c62558..89013ed 100644
> >> --- a/arch/arm/boot/dts/Makefile
> >> +++ b/arch/arm/boot/dts/Makefile
> >> @@ -119,6 +119,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
> >> omap3-beagle-xm.dtb \
> >> omap3-evm.dtb \
> >> omap3-tobi.dtb \
> >> + omap3430-sdp.dtb \
> >> omap4-panda.dtb \
> >> omap4-panda-a4.dtb \
> >> omap4-panda-es.dtb \
> >> diff --git a/arch/arm/boot/dts/omap3430-sdp.dts b/arch/arm/boot/dts/omap3430-sdp.dts
> >> new file mode 100644
> >> index 0000000..be0650d
> >> --- /dev/null
> >> +++ b/arch/arm/boot/dts/omap3430-sdp.dts
> >> @@ -0,0 +1,46 @@
> >> +/*
> >> + * Copyright (C) 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.
> >> + */
> >> +/dts-v1/;
> >> +
> >> +/include/ "omap3.dtsi"
> >> +
> >> +/ {
> >> + model = "TI OMAP3430 SDP";
> >> + compatible = "ti,omap3430-sdp", "ti,omap3";
> >
> > I have not seen any related changes in "board-generic.c" for your board.
> > So just wanted know, how this board is booting ?
>
> If you look at board-generic.c you will see that "ti,omap3" will match
> the OMAP3 generic machine. So you don't need to modify the board-generic.c.
According to this omap3-beagle.dts and omap3-beagle-xm.dts are also
booting in some way. So it is not clear to me, why there two
"DT_MACHINE_START" for omap3. I have seen there is only one
different in "init_time" for the same.
>
> >> +
> >> + memory {
> >> + device_type = "memory";
> >> + reg = <0x80000000 0x10000000>; /* 256 MB */
> >> + };
> >> +};
> >> +
> >> +&i2c1 {
> >> + clock-frequency = <2600000>;
> >> +
> >> + twl: twl@48 {
> >> + reg = <0x48>;
> >> + interrupts = <7>; /* SYS_NIRQ cascaded to intc */
> >> + interrupt-parent = <&intc>;
> >> + };
> >> +};
> >> +
> >> +/include/ "twl4030.dtsi"
> >> +
> >> +&mmc1 {
> >> + vmmc-supply = <&vmmc1>;
> >> + vmmc_aux-supply = <&vsim>;
> >> + bus-width = <8>;
> >> +};
> >> +
> >> +&mmc2 {
> >> + status = "disabled";
> >> +};
> >> +
> >> +&mmc3 {
> >> + status = "disabled";
> >> +};
> >
> > I think you should disable modules those are not currently used
> > as they are enabled by default in omap3.dtsi.
> >
> > exp:-
> >
> > &mcbsp2 {
> > status = "disabled";
> > };
>
> Well may be we could do that in a follow-up patch. If you look at other
> omap3 boards we have not gone through and disabled all unused modules
> either. So although I agree, right now I just want to get minimal
> support added.
>
Hmm... But it makes the kernel to call unused driver probe and get failed
those required some platform date from DT? you can see the kernel boot logs.
Thanks,
Anil
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: [PATCH 4/9] ARM: dts: OMAP3: Add support for OMAP3430 SDP board
2013-03-12 2:42 ` Kumar, Anil
@ 2013-03-12 8:50 ` Javier Martinez Canillas
2013-03-13 2:50 ` Kumar, Anil
2013-03-12 21:27 ` Jon Hunter
1 sibling, 1 reply; 37+ messages in thread
From: Javier Martinez Canillas @ 2013-03-12 8:50 UTC (permalink / raw)
To: Kumar, Anil
Cc: Hunter, Jon, Cousson, Benoit, Tony Lindgren, device-tree,
Anil Kumar, linux-omap, linux-arm
On Tue, Mar 12, 2013 at 3:42 AM, Kumar, Anil <anilkumar.v@ti.com> wrote:
>
> On Mon, Mar 11, 2013 at 23:23:32, Hunter, Jon wrote:
>>
>> On 03/08/2013 08:25 PM, Anil Kumar wrote:
>> > Hi Jon,
>> >
>> > On Fri, Mar 8, 2013 at 10:57 PM, Jon Hunter <jon-hunter@ti.com> wrote:
>> >> Adds basic device-tree support for OMAP3430 SDP board which has 256MB
>> >> of RAM and uses the TWL4030 power management IC.
>> >
>> > I think this board support should be in separate patch series with
>> > related patches.
>>
>> Well I wanted to keep them altogether so that I can send a pull request
>> to Benoit and Tony.
>
> Sorry, but can you please tell what makes you to think that you
> can send pull request only when they are altogether ?
>
> Is there any logical dependency with other patches except
> "[PATCH 6/9] ARM: dts: Add OMAP3430 SDP flash memory bindings" is on
> top of this patch ?
>
>>
>> >>
>> >> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
>> >> ---
>> >> arch/arm/boot/dts/Makefile | 1 +
>> >> arch/arm/boot/dts/omap3430-sdp.dts | 46 ++++++++++++++++++++++++++++++++++++
>> >> 2 files changed, 47 insertions(+)
>> >> create mode 100644 arch/arm/boot/dts/omap3430-sdp.dts
>> >>
>> >> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> >> index 9c62558..89013ed 100644
>> >> --- a/arch/arm/boot/dts/Makefile
>> >> +++ b/arch/arm/boot/dts/Makefile
>> >> @@ -119,6 +119,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
>> >> omap3-beagle-xm.dtb \
>> >> omap3-evm.dtb \
>> >> omap3-tobi.dtb \
>> >> + omap3430-sdp.dtb \
>> >> omap4-panda.dtb \
>> >> omap4-panda-a4.dtb \
>> >> omap4-panda-es.dtb \
>> >> diff --git a/arch/arm/boot/dts/omap3430-sdp.dts b/arch/arm/boot/dts/omap3430-sdp.dts
>> >> new file mode 100644
>> >> index 0000000..be0650d
>> >> --- /dev/null
>> >> +++ b/arch/arm/boot/dts/omap3430-sdp.dts
>> >> @@ -0,0 +1,46 @@
>> >> +/*
>> >> + * Copyright (C) 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.
>> >> + */
>> >> +/dts-v1/;
>> >> +
>> >> +/include/ "omap3.dtsi"
>> >> +
>> >> +/ {
>> >> + model = "TI OMAP3430 SDP";
>> >> + compatible = "ti,omap3430-sdp", "ti,omap3";
>> >
>> > I have not seen any related changes in "board-generic.c" for your board.
>> > So just wanted know, how this board is booting ?
>>
>> If you look at board-generic.c you will see that "ti,omap3" will match
>> the OMAP3 generic machine. So you don't need to modify the board-generic.c.
>
> According to this omap3-beagle.dts and omap3-beagle-xm.dts are also
> booting in some way. So it is not clear to me, why there two
> "DT_MACHINE_START" for omap3. I have seen there is only one
> different in "init_time" for the same.
>
Hi Anil,
You may take a look to commit:
7dd9d50 ARM: OMAP3: Add generic machine descriptor for boards with
OMAP3 GP device
So, the second DT_MACHINE_START is meant to be used by OMAP3 boards
which use GP devices and this is not the case for "ti,omap3430-sdp"
afaiu.
I wonder if instead of adding each OMAP3 board with GP devices such as
"ti,omap3-beagle", is not better to have a "ti,omap3-gp" compatible
property.
The whole point of DT is to decouple the hardware description from the
kernel code so in general we should use the more generic compatible
string ("ti,omap3") unless the hardware has some specifics that have
to be addressed, such as these boards that use GP devices.
>>
>> >> +
>> >> + memory {
>> >> + device_type = "memory";
>> >> + reg = <0x80000000 0x10000000>; /* 256 MB */
>> >> + };
>> >> +};
>> >> +
>> >> +&i2c1 {
>> >> + clock-frequency = <2600000>;
>> >> +
>> >> + twl: twl@48 {
>> >> + reg = <0x48>;
>> >> + interrupts = <7>; /* SYS_NIRQ cascaded to intc */
>> >> + interrupt-parent = <&intc>;
>> >> + };
>> >> +};
>> >> +
>> >> +/include/ "twl4030.dtsi"
>> >> +
>> >> +&mmc1 {
>> >> + vmmc-supply = <&vmmc1>;
>> >> + vmmc_aux-supply = <&vsim>;
>> >> + bus-width = <8>;
>> >> +};
>> >> +
>> >> +&mmc2 {
>> >> + status = "disabled";
>> >> +};
>> >> +
>> >> +&mmc3 {
>> >> + status = "disabled";
>> >> +};
>> >
>> > I think you should disable modules those are not currently used
>> > as they are enabled by default in omap3.dtsi.
>> >
>> > exp:-
>> >
>> > &mcbsp2 {
>> > status = "disabled";
>> > };
>>
>> Well may be we could do that in a follow-up patch. If you look at other
>> omap3 boards we have not gone through and disabled all unused modules
>> either. So although I agree, right now I just want to get minimal
>> support added.
>>
>
> Hmm... But it makes the kernel to call unused driver probe and get failed
> those required some platform date from DT? you can see the kernel boot logs.
>
> Thanks,
> Anil
>
>
Best regards,
Javier
^ permalink raw reply [flat|nested] 37+ messages in thread* RE: [PATCH 4/9] ARM: dts: OMAP3: Add support for OMAP3430 SDP board
2013-03-12 8:50 ` Javier Martinez Canillas
@ 2013-03-13 2:50 ` Kumar, Anil
0 siblings, 0 replies; 37+ messages in thread
From: Kumar, Anil @ 2013-03-13 2:50 UTC (permalink / raw)
To: Javier Martinez Canillas, Cousson, Benoit
Cc: Hunter, Jon, Tony Lindgren, device-tree, Anil Kumar, linux-omap,
linux-arm
On Tue, Mar 12, 2013 at 14:20:48, Javier Martinez Canillas wrote:
> On Tue, Mar 12, 2013 at 3:42 AM, Kumar, Anil <anilkumar.v@ti.com> wrote:
> >
> > On Mon, Mar 11, 2013 at 23:23:32, Hunter, Jon wrote:
> >>
> >> On 03/08/2013 08:25 PM, Anil Kumar wrote:
> >> > Hi Jon,
> >> >
> >> > On Fri, Mar 8, 2013 at 10:57 PM, Jon Hunter <jon-hunter@ti.com> wrote:
> >> >> Adds basic device-tree support for OMAP3430 SDP board which has 256MB
> >> >> of RAM and uses the TWL4030 power management IC.
> >> >
> >> > I think this board support should be in separate patch series with
> >> > related patches.
> >>
> >> Well I wanted to keep them altogether so that I can send a pull request
> >> to Benoit and Tony.
> >
> > Sorry, but can you please tell what makes you to think that you
> > can send pull request only when they are altogether ?
> >
> > Is there any logical dependency with other patches except
> > "[PATCH 6/9] ARM: dts: Add OMAP3430 SDP flash memory bindings" is on
> > top of this patch ?
> >
> >>
> >> >>
> >> >> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
> >> >> ---
> >> >> arch/arm/boot/dts/Makefile | 1 +
> >> >> arch/arm/boot/dts/omap3430-sdp.dts | 46 ++++++++++++++++++++++++++++++++++++
> >> >> 2 files changed, 47 insertions(+)
> >> >> create mode 100644 arch/arm/boot/dts/omap3430-sdp.dts
> >> >>
> >> >> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> >> >> index 9c62558..89013ed 100644
> >> >> --- a/arch/arm/boot/dts/Makefile
> >> >> +++ b/arch/arm/boot/dts/Makefile
> >> >> @@ -119,6 +119,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
> >> >> omap3-beagle-xm.dtb \
> >> >> omap3-evm.dtb \
> >> >> omap3-tobi.dtb \
> >> >> + omap3430-sdp.dtb \
> >> >> omap4-panda.dtb \
> >> >> omap4-panda-a4.dtb \
> >> >> omap4-panda-es.dtb \
> >> >> diff --git a/arch/arm/boot/dts/omap3430-sdp.dts b/arch/arm/boot/dts/omap3430-sdp.dts
> >> >> new file mode 100644
> >> >> index 0000000..be0650d
> >> >> --- /dev/null
> >> >> +++ b/arch/arm/boot/dts/omap3430-sdp.dts
> >> >> @@ -0,0 +1,46 @@
> >> >> +/*
> >> >> + * Copyright (C) 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.
> >> >> + */
> >> >> +/dts-v1/;
> >> >> +
> >> >> +/include/ "omap3.dtsi"
> >> >> +
> >> >> +/ {
> >> >> + model = "TI OMAP3430 SDP";
> >> >> + compatible = "ti,omap3430-sdp", "ti,omap3";
> >> >
> >> > I have not seen any related changes in "board-generic.c" for your board.
> >> > So just wanted know, how this board is booting ?
> >>
> >> If you look at board-generic.c you will see that "ti,omap3" will match
> >> the OMAP3 generic machine. So you don't need to modify the board-generic.c.
> >
> > According to this omap3-beagle.dts and omap3-beagle-xm.dts are also
> > booting in some way. So it is not clear to me, why there two
> > "DT_MACHINE_START" for omap3. I have seen there is only one
> > different in "init_time" for the same.
> >
>
> Hi Anil,
>
> You may take a look to commit:
>
> 7dd9d50 ARM: OMAP3: Add generic machine descriptor for boards with
> OMAP3 GP device
>
> So, the second DT_MACHINE_START is meant to be used by OMAP3 boards
> which use GP devices and this is not the case for "ti,omap3430-sdp"
> afaiu.
>
> I wonder if instead of adding each OMAP3 board with GP devices such as
> "ti,omap3-beagle", is not better to have a "ti,omap3-gp" compatible
> property.
Sound good to me.
@Benoit,
Is this makes any sense for you?
>
> The whole point of DT is to decouple the hardware description from the
> kernel code so in general we should use the more generic compatible
> string ("ti,omap3") unless the hardware has some specifics that have
> to be addressed, such as these boards that use GP devices.
Thanks you very much. It really help full for me.
Thanks,
Anil
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 4/9] ARM: dts: OMAP3: Add support for OMAP3430 SDP board
2013-03-12 2:42 ` Kumar, Anil
2013-03-12 8:50 ` Javier Martinez Canillas
@ 2013-03-12 21:27 ` Jon Hunter
2013-03-13 2:59 ` Kumar, Anil
1 sibling, 1 reply; 37+ messages in thread
From: Jon Hunter @ 2013-03-12 21:27 UTC (permalink / raw)
To: Kumar, Anil
Cc: Tony Lindgren, device-tree, linux-omap, Cousson, Benoit,
linux-arm, Anil Kumar
On 03/11/2013 09:42 PM, Kumar, Anil wrote:
>
> On Mon, Mar 11, 2013 at 23:23:32, Hunter, Jon wrote:
>>
>> On 03/08/2013 08:25 PM, Anil Kumar wrote:
>>> Hi Jon,
>>>
>>> On Fri, Mar 8, 2013 at 10:57 PM, Jon Hunter <jon-hunter@ti.com> wrote:
>>>> Adds basic device-tree support for OMAP3430 SDP board which has 256MB
>>>> of RAM and uses the TWL4030 power management IC.
>>>
>>> I think this board support should be in separate patch series with
>>> related patches.
>>
>> Well I wanted to keep them altogether so that I can send a pull request
>> to Benoit and Tony.
>
> Sorry, but can you please tell what makes you to think that you
> can send pull request only when they are altogether ?
That's not the point.
> Is there any logical dependency with other patches except
> "[PATCH 6/9] ARM: dts: Add OMAP3430 SDP flash memory bindings" is on
> top of this patch ?
Per the $subject of the series these a various DT patches I have pending.
Yes I could break this series up into many separate series, one for PMU,
one for DMA, one for GPMC, one for OMAP3 SDP, but I thought it would be
easier for Tony and Benoit to pull as a single series.
If Tony or Benoit wish for me to separate these out, I will.
>>
>>>>
>>>> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
>>>> ---
>>>> arch/arm/boot/dts/Makefile | 1 +
>>>> arch/arm/boot/dts/omap3430-sdp.dts | 46 ++++++++++++++++++++++++++++++++++++
>>>> 2 files changed, 47 insertions(+)
>>>> create mode 100644 arch/arm/boot/dts/omap3430-sdp.dts
>>>>
>>>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>>>> index 9c62558..89013ed 100644
>>>> --- a/arch/arm/boot/dts/Makefile
>>>> +++ b/arch/arm/boot/dts/Makefile
>>>> @@ -119,6 +119,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
>>>> omap3-beagle-xm.dtb \
>>>> omap3-evm.dtb \
>>>> omap3-tobi.dtb \
>>>> + omap3430-sdp.dtb \
>>>> omap4-panda.dtb \
>>>> omap4-panda-a4.dtb \
>>>> omap4-panda-es.dtb \
>>>> diff --git a/arch/arm/boot/dts/omap3430-sdp.dts b/arch/arm/boot/dts/omap3430-sdp.dts
>>>> new file mode 100644
>>>> index 0000000..be0650d
>>>> --- /dev/null
>>>> +++ b/arch/arm/boot/dts/omap3430-sdp.dts
>>>> @@ -0,0 +1,46 @@
>>>> +/*
>>>> + * Copyright (C) 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.
>>>> + */
>>>> +/dts-v1/;
>>>> +
>>>> +/include/ "omap3.dtsi"
>>>> +
>>>> +/ {
>>>> + model = "TI OMAP3430 SDP";
>>>> + compatible = "ti,omap3430-sdp", "ti,omap3";
>>>
>>> I have not seen any related changes in "board-generic.c" for your board.
>>> So just wanted know, how this board is booting ?
>>
>> If you look at board-generic.c you will see that "ti,omap3" will match
>> the OMAP3 generic machine. So you don't need to modify the board-generic.c.
>
> According to this omap3-beagle.dts and omap3-beagle-xm.dts are also
> booting in some way. So it is not clear to me, why there two
> "DT_MACHINE_START" for omap3. I have seen there is only one
> different in "init_time" for the same.
OMAP3 beagle uses the machine descriptor OMAP3_GP_DT where as OMAP3
beagle-xm (and OMAP3 SDP) use the machine descriptor OMAP3_DT. The
real difference in these machine descriptors is the init_time
function pointer.
>>
>>>> +
>>>> + memory {
>>>> + device_type = "memory";
>>>> + reg = <0x80000000 0x10000000>; /* 256 MB */
>>>> + };
>>>> +};
>>>> +
>>>> +&i2c1 {
>>>> + clock-frequency = <2600000>;
>>>> +
>>>> + twl: twl@48 {
>>>> + reg = <0x48>;
>>>> + interrupts = <7>; /* SYS_NIRQ cascaded to intc */
>>>> + interrupt-parent = <&intc>;
>>>> + };
>>>> +};
>>>> +
>>>> +/include/ "twl4030.dtsi"
>>>> +
>>>> +&mmc1 {
>>>> + vmmc-supply = <&vmmc1>;
>>>> + vmmc_aux-supply = <&vsim>;
>>>> + bus-width = <8>;
>>>> +};
>>>> +
>>>> +&mmc2 {
>>>> + status = "disabled";
>>>> +};
>>>> +
>>>> +&mmc3 {
>>>> + status = "disabled";
>>>> +};
>>>
>>> I think you should disable modules those are not currently used
>>> as they are enabled by default in omap3.dtsi.
>>>
>>> exp:-
>>>
>>> &mcbsp2 {
>>> status = "disabled";
>>> };
>>
>> Well may be we could do that in a follow-up patch. If you look at other
>> omap3 boards we have not gone through and disabled all unused modules
>> either. So although I agree, right now I just want to get minimal
>> support added.
>>
>
> Hmm... But it makes the kernel to call unused driver probe and get failed
> those required some platform date from DT? you can see the kernel boot logs.
Here is the console output I see on the omap3 sdp. There are a few warnings
around pin-mux settings but nothing major AFAICT ...
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 3.9.0-rc2-39794-g1c71698 (jenkins@cfasvr1) (gcc version 4.6.1 (Sourcery CodeBench Lite 2011.09-70) ) #4 SMP Tue Mar 12 15:59:47 CDT 2013
[ 0.000000] CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c53c7d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
[ 0.000000] Machine: Generic OMAP3 (Flattened Device Tree), model: TI OMAP3430 SDP
[ 0.000000] cma: CMA: reserved 16 MiB at 8e800000
[ 0.000000] Memory policy: ECC disabled, Data cache writeback
[ 0.000000] CPU: All CPU(s) started in SVC mode.
[ 0.000000] OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp )
[ 0.000000] Clocking rate (Crystal/Core/MPU): 26.0/332/600 MHz
[ 0.000000] PERCPU: Embedded 9 pages/cpu @c14dc000 s13632 r8192 d15040 u36864
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64768
[ 0.000000] Kernel command line: console=ttyO0,115200n8 ip=dhcp earlyprintk
[ 0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[ 0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[ 0.000000] __ex_table already sorted, skipping sort
[ 0.000000] Memory: 255MB = 255MB total
[ 0.000000] Memory: 223080k/223080k available, 39064k reserved, 0K highmem
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
[ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
[ 0.000000] vmalloc : 0xd0800000 - 0xff000000 ( 744 MB)
[ 0.000000] lowmem : 0xc0000000 - 0xd0000000 ( 256 MB)
[ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
[ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
[ 0.000000] .text : 0xc0008000 - 0xc075f8dc (7519 kB)
[ 0.000000] .init : 0xc0760000 - 0xc0cda540 (5610 kB)
[ 0.000000] .data : 0xc0cdc000 - 0xc0d75820 ( 615 kB)
[ 0.000000] .bss : 0xc0d75820 - 0xc12d0a88 (5485 kB)
[ 0.000000] Hierarchical RCU implementation.
[ 0.000000] RCU restricting CPUs from NR_CPUS=2 to nr_cpu_ids=1.
[ 0.000000] NR_IRQS:16 nr_irqs:16 16
[ 0.000000] IRQ: Found an INTC at 0xfa200000 (revision 4.0) with 96 interrupts
[ 0.000000] Total of 96 interrupts on 1 active controller
[ 0.000000] OMAP clockevent source: timer1 at 32768 Hz
[ 0.000000] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms
[ 0.000000] OMAP clocksource: 32k_counter at 32768 Hz
[ 0.000000] Console: colour dummy device 80x30
[ 0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
[ 0.000000] ... MAX_LOCKDEP_SUBCLASSES: 8
[ 0.000000] ... MAX_LOCK_DEPTH: 48
[ 0.000000] ... MAX_LOCKDEP_KEYS: 8191
[ 0.000000] ... CLASSHASH_SIZE: 4096
[ 0.000000] ... MAX_LOCKDEP_ENTRIES: 16384
[ 0.000000] ... MAX_LOCKDEP_CHAINS: 32768
[ 0.000000] ... CHAINHASH_SIZE: 16384
[ 0.000000] memory used by lock dependency info: 3695 kB
[ 0.000000] per task-struct memory footprint: 1152 bytes
[ 0.001159] Calibrating delay loop... 395.67 BogoMIPS (lpj=1978368)
[ 0.109649] pid_max: default: 32768 minimum: 301
[ 0.110290] Security Framework initialized
[ 0.110473] Mount-cache hash table entries: 512
[ 0.126861] CPU: Testing write buffer coherency: ok
[ 0.128692] CPU0: thread -1, cpu 0, socket -1, mpidr 0
[ 0.128814] Setting up static identity map for 0xc055bc70 - 0xc055bce0
[ 0.132598] Brought up 1 CPUs
[ 0.132629] SMP: Total of 1 processors activated (395.67 BogoMIPS).
[ 0.132659] CPU: All CPU(s) started in SVC mode.
[ 0.136352] devtmpfs: initialized
[ 0.196838] pinctrl core: initialized pinctrl subsystem
[ 0.204345] regulator-dummy: no parameters
[ 0.208740] NET: Registered protocol family 16
[ 0.219116] DMA: preallocated 256 KiB pool for atomic coherent allocations
[ 0.239593] Reprogramming SDRC clock to 332000000 Hz
[ 0.254455] OMAP GPIO hardware version 2.5
[ 0.288085] platform 49022000.mcbsp: alias fck already exists
[ 0.289916] platform 49024000.mcbsp: alias fck already exists
[ 0.307922] omap-gpmc 6e000000.gpmc: GPMC revision 5.0
[ 0.312744] No ATAGs?
[ 0.312774] hw-breakpoint: debug architecture 0x4 unsupported.
[ 0.318359] OMAP DMA hardware revision 4.0
[ 0.320190] Serial: AMBA PL011 UART driver
[ 0.401214] bio: create slab <bio-0> at 0
[ 0.506225] omap-dma-engine 48056000.dma-controller: OMAP DMA engine driver
[ 0.517608] SCSI subsystem initialized
[ 0.520904] usbcore: registered new interface driver usbfs
[ 0.521545] usbcore: registered new interface driver hub
[ 0.522277] usbcore: registered new device driver usb
[ 0.525085] omap_i2c i2c.8: did not get pins for i2c error: -19
[ 0.527038] omap_i2c i2c.8: bus 0 rev3.3 at 2600 kHz
[ 0.542297] twl 0-0048: PIH (irq 23) chaining IRQs 338..346
[ 0.542999] twl 0-0048: power (irq 343) chaining IRQs 346..353
[ 0.550140] VDAC: 1800 mV
[ 0.554077] VPLL2: 1800 mV
[ 0.557281] VMMC1: 1850 <--> 3150 mV at 3150 mV
[ 0.560607] VUSB1V5: 1500 mV
[ 0.563232] VUSB1V8: 1800 mV
[ 0.565734] VUSB3V1: 3100 mV
[ 0.568542] VSIM: 1800 <--> 3000 mV at 1800 mV
[ 0.572418] twl4030_gpio gpio.26: gpio (irq 338) chaining IRQs 354..371
[ 0.575836] omap_i2c i2c.9: did not get pins for i2c error: -19
[ 0.577331] omap_i2c i2c.9: bus 1 rev3.3 at 100 kHz
[ 0.577636] omap_i2c i2c.10: did not get pins for i2c error: -19
[ 0.579223] omap_i2c i2c.10: bus 2 rev3.3 at 100 kHz
[ 0.589477] Switching to clocksource 32k_counter
[ 0.758361] NET: Registered protocol family 2
[ 0.761047] TCP established hash table entries: 2048 (order: 2, 16384 bytes)
[ 0.761322] TCP bind hash table entries: 2048 (order: 4, 73728 bytes)
[ 0.762481] TCP: Hash tables configured (established 2048 bind 2048)
[ 0.762786] TCP: reno registered
[ 0.762817] UDP hash table entries: 256 (order: 2, 20480 bytes)
[ 0.763153] UDP-Lite hash table entries: 256 (order: 2, 20480 bytes)
[ 0.764404] NET: Registered protocol family 1
[ 0.766204] RPC: Registered named UNIX socket transport module.
[ 0.766235] RPC: Registered udp transport module.
[ 0.766265] RPC: Registered tcp transport module.
[ 0.766265] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 0.886260] NetWinder Floating Point Emulator V0.97 (double precision)
[ 0.886749] hw perfevents: enabled with ARMv7 Cortex-A8 PMU driver, 5 counters available
[ 1.083740] VFS: Disk quotas dquot_6.5.2
[ 1.084136] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[ 1.087951] NFS: Registering the id_resolver key type
[ 1.088592] Key type id_resolver registered
[ 1.088623] Key type id_legacy registered
[ 1.088806] jffs2: version 2.2. (NAND) (SUMMARY) �� 2001-2006 Red Hat, Inc.
[ 1.089538] msgmni has been set to 467
[ 1.095092] io scheduler noop registered
[ 1.095123] io scheduler deadline registered
[ 1.095214] io scheduler cfq registered (default)
[ 1.098144] pinctrl-single 48002030.pinmux: 742 pins at pa fa002030 size 1484
[ 1.099090] pinctrl-single 48002a58.pinmux: 46 pins at pa fa002a58 size 92
[ 1.105224] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[ 1.114746] omap_uart serial.5: did not get pins for uart0 error: -19
[ 1.115478] serial.5: ttyO0 at MMIO 0x4806a000 (irq = 88) is a OMAP UART0
[ 1.825805] console [ttyO0] enabled
[ 1.832183] omap_uart serial.6: did not get pins for uart1 error: -19
[ 1.839385] serial.6: ttyO1 at MMIO 0x4806c000 (irq = 89) is a OMAP UART1
[ 1.848999] omap_uart serial.7: did not get pins for uart2 error: -19
[ 1.856353] serial.7: ttyO2 at MMIO 0x49020000 (irq = 90) is a OMAP UART2
[ 1.907745] brd: module loaded
[ 1.936614] loop: module loaded
[ 1.946990] mtdoops: mtd device (mtddev=name/number) must be supplied
[ 1.965362] intel,pf48f6000m0y1be: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer ID 0x000089 Chip ID 0x0088b1
[ 1.976928] Intel/Sharp Extended Query Table at 0x010A
[ 1.982482] Intel/Sharp Extended Query Table at 0x010A
[ 1.987915] Intel/Sharp Extended Query Table at 0x010A
[ 1.993469] Intel/Sharp Extended Query Table at 0x010A
[ 1.998901] Intel/Sharp Extended Query Table at 0x010A
[ 2.004425] Using buffer write method
[ 2.008300] Using auto-unlock on power-up/resume
[ 2.013214] cfi_cmdset_0001: Erase suspend on write enabled
[ 2.026824] 4 ofpart partitions found on MTD device intel,pf48f6000m0y1be
[ 2.034118] Creating 4 MTD partitions on "intel,pf48f6000m0y1be":
[ 2.041046] 0x000000000000-0x000000040000 : "bootloader-nor"
[ 2.055450] 0x000000040000-0x000000080000 : "params-nor"
[ 2.066467] 0x000000080000-0x000000280000 : "kernel-nor"
[ 2.077606] 0x000000240000-0x000007fc0000 : "filesystem-nor"
[ 2.100585] No NAND device found
[ 2.104187] Trying ONFI probe in 16 bits mode, aborting !
[ 2.109893] No NAND device found
[ 2.114166] OneNAND driver initializing
[ 2.118804] omap2-onenand omap2-onenand: initializing on CS2, phys base 0x20000000, virtual base d0880000, freq 0 MHz
[ 2.130218] Muxed OneNAND 256MB 1.8V 16-bit (0x40)
[ 2.135253] OneNAND version = 0x002c
[ 2.140991] Scanning device for bad blocks
[ 2.157745] OneNAND eraseblock 205 is an initial bad block
[ 2.174102] OneNAND eraseblock 390 is an initial bad block
[ 2.185363] OneNAND eraseblock 486 is an initial bad block
[ 2.194702] OneNAND eraseblock 547 is an initial bad block
[ 2.206329] OneNAND eraseblock 651 is an initial bad block
[ 2.213439] OneNAND eraseblock 674 is an initial bad block
[ 2.259613] OneNAND eraseblock 1398 is an initial bad block
[ 2.301971] 5 ofpart partitions found on MTD device omap2-onenand
[ 2.308380] Creating 5 MTD partitions on "omap2-onenand":
[ 2.314147] 0x000000000000-0x000000080000 : "xloader-onenand"
[ 2.325622] 0x000000080000-0x0000000c0000 : "bootloader-onenand"
[ 2.337219] 0x0000000c0000-0x0000000e0000 : "params-onenand"
[ 2.348480] 0x0000000e0000-0x0000002e0000 : "kernel-onenand"
[ 2.360382] 0x0000002e0000-0x000010000000 : "filesystem-onenand"
[ 2.384552] omap2_mcspi spi.11: pins are not configured from the driver
[ 2.394165] omap2_mcspi spi.12: pins are not configured from the driver
[ 2.403106] omap2_mcspi spi.13: pins are not configured from the driver
[ 2.411834] omap2_mcspi spi.14: pins are not configured from the driver
[ 2.428222] usbcore: registered new interface driver asix
[ 2.434753] usbcore: registered new interface driver ax88179_178a
[ 2.442382] usbcore: registered new interface driver cdc_ether
[ 2.449188] usbcore: registered new interface driver smsc95xx
[ 2.456024] usbcore: registered new interface driver net1080
[ 2.462707] usbcore: registered new interface driver cdc_subset
[ 2.469512] usbcore: registered new interface driver zaurus
[ 2.476379] usbcore: registered new interface driver cdc_ncm
[ 2.485351] usbcore: registered new interface driver cdc_wdm
[ 2.491485] Initializing USB Mass Storage driver...
[ 2.497375] usbcore: registered new interface driver usb-storage
[ 2.503814] USB Mass Storage support registered.
[ 2.509368] usbcore: registered new interface driver usbtest
[ 2.518371] mousedev: PS/2 mouse device common for all mice
[ 2.532562] twl_rtc rtc.17: Power up reset detected.
[ 2.538726] twl_rtc rtc.17: Enabling TWL-RTC
[ 2.548553] twl_rtc rtc.17: rtc core: registered rtc.17 as rtc0
[ 2.557189] i2c /dev entries driver
[ 2.566284] Driver for 1-wire Dallas network protocol.
[ 2.577667] omap_wdt: OMAP Watchdog Timer Rev 0x31: initial timeout 60 sec
[ 2.592773] omap-dma-engine 48056000.dma-controller: allocating channel for 62
[ 2.600738] omap-dma-engine 48056000.dma-controller: allocating channel for 61
[ 2.612396] omap_hsmmc mmc.15: pins are not configured from the driver
[ 2.667449] ledtrig-cpu: registered to indicate activity on CPUs
[ 2.676300] usbcore: registered new interface driver usbhid
[ 2.682281] usbhid: USB HID core driver
[ 2.690795] oprofile: using arm/armv7
[ 2.695739] TCP: cubic registered
[ 2.699249] Initializing XFRM netlink socket
[ 2.704162] NET: Registered protocol family 17
[ 2.708984] NET: Registered protocol family 15
[ 2.714263] Key type dns_resolver registered
[ 2.718872] VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 1
[ 2.727172] ThumbEE CPU extension supported.
[ 2.738586] VUSB3V1: disabling
[ 2.742706] VUSB1V8: disabling
[ 2.746582] VUSB1V5: disabling
[ 2.750793] VPLL2: disabling
[ 2.754699] VDAC: disabling
[ 2.764526] mmc0: SD Status: Invalid Allocation Unit size.
[ 2.772277] twl_rtc rtc.17: setting system clock to 2000-01-01 00:00:00 UTC (946684800)
[ 2.782043] mmc0: host does not support reading read-only switch. assuming write-enable.
[ 2.793182] mmc0: new high speed SD card at address b368
[ 2.802612] mmcblk0: mmc0:b368 SD1GB 952 MiB
[ 2.814208] mmcblk0: p1 p2
[ 14.917297] Freeing init memory: 5608K
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 37+ messages in thread* RE: [PATCH 4/9] ARM: dts: OMAP3: Add support for OMAP3430 SDP board
2013-03-12 21:27 ` Jon Hunter
@ 2013-03-13 2:59 ` Kumar, Anil
0 siblings, 0 replies; 37+ messages in thread
From: Kumar, Anil @ 2013-03-13 2:59 UTC (permalink / raw)
To: Hunter, Jon
Cc: Tony Lindgren, device-tree, linux-omap, Cousson, Benoit,
linux-arm, Anil Kumar
On Wed, Mar 13, 2013 at 02:57:04, Hunter, Jon wrote:
>
> On 03/11/2013 09:42 PM, Kumar, Anil wrote:
> >
> > On Mon, Mar 11, 2013 at 23:23:32, Hunter, Jon wrote:
> >>
> >> On 03/08/2013 08:25 PM, Anil Kumar wrote:
> >>> Hi Jon,
> >>>
> >>> On Fri, Mar 8, 2013 at 10:57 PM, Jon Hunter <jon-hunter@ti.com> wrote:
> >>>> Adds basic device-tree support for OMAP3430 SDP board which has 256MB
> >>>> of RAM and uses the TWL4030 power management IC.
> >>>
> >>> I think this board support should be in separate patch series with
> >>> related patches.
> >>
> >> Well I wanted to keep them altogether so that I can send a pull request
> >> to Benoit and Tony.
> >
> > Sorry, but can you please tell what makes you to think that you
> > can send pull request only when they are altogether ?
>
> That's not the point.
>
> > Is there any logical dependency with other patches except
> > "[PATCH 6/9] ARM: dts: Add OMAP3430 SDP flash memory bindings" is on
> > top of this patch ?
>
> Per the $subject of the series these a various DT patches I have pending.
> Yes I could break this series up into many separate series, one for PMU,
> one for DMA, one for GPMC, one for OMAP3 SDP, but I thought it would be
> easier for Tony and Benoit to pull as a single series.
I am really Sorry, If I said any nonsense here. I did not know that
we can do like that also.
Thanks,
Anil
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 4/9] ARM: dts: OMAP3: Add support for OMAP3430 SDP board
2013-03-08 17:27 ` [PATCH 4/9] ARM: dts: OMAP3: Add support for OMAP3430 SDP board Jon Hunter
2013-03-09 2:25 ` Anil Kumar
@ 2013-03-11 2:45 ` Anil Kumar
2013-03-11 17:54 ` Jon Hunter
1 sibling, 1 reply; 37+ messages in thread
From: Anil Kumar @ 2013-03-11 2:45 UTC (permalink / raw)
To: Jon Hunter
Cc: Tony Lindgren, Benoit Cousson, device-tree, linux-omap, linux-arm
Hi Jon,
On Fri, Mar 8, 2013 at 10:57 PM, Jon Hunter <jon-hunter@ti.com> wrote:
> Adds basic device-tree support for OMAP3430 SDP board which has 256MB
> of RAM and uses the TWL4030 power management IC.
>
> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/omap3430-sdp.dts | 46 ++++++++++++++++++++++++++++++++++++
> 2 files changed, 47 insertions(+)
> create mode 100644 arch/arm/boot/dts/omap3430-sdp.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 9c62558..89013ed 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -119,6 +119,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
> omap3-beagle-xm.dtb \
> omap3-evm.dtb \
> omap3-tobi.dtb \
> + omap3430-sdp.dtb \
> omap4-panda.dtb \
> omap4-panda-a4.dtb \
> omap4-panda-es.dtb \
> diff --git a/arch/arm/boot/dts/omap3430-sdp.dts b/arch/arm/boot/dts/omap3430-sdp.dts
> new file mode 100644
> index 0000000..be0650d
> --- /dev/null
> +++ b/arch/arm/boot/dts/omap3430-sdp.dts
> @@ -0,0 +1,46 @@
> +/*
> + * Copyright (C) 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.
> + */
> +/dts-v1/;
> +
> +/include/ "omap3.dtsi"
> +
> +/ {
> + model = "TI OMAP3430 SDP";
> + compatible = "ti,omap3430-sdp", "ti,omap3";
> +
> + memory {
> + device_type = "memory";
> + reg = <0x80000000 0x10000000>; /* 256 MB */
> + };
> +};
> +
> +&i2c1 {
> + clock-frequency = <2600000>;
> +
> + twl: twl@48 {
> + reg = <0x48>;
> + interrupts = <7>; /* SYS_NIRQ cascaded to intc */
> + interrupt-parent = <&intc>;
No need of "interrupt-parent = <&intc>" as it is with root node
already.
Thanks,
Anil
[...]
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: [PATCH 4/9] ARM: dts: OMAP3: Add support for OMAP3430 SDP board
2013-03-11 2:45 ` Anil Kumar
@ 2013-03-11 17:54 ` Jon Hunter
0 siblings, 0 replies; 37+ messages in thread
From: Jon Hunter @ 2013-03-11 17:54 UTC (permalink / raw)
To: Anil Kumar
Cc: Tony Lindgren, Benoit Cousson, device-tree, linux-omap, linux-arm
On 03/10/2013 09:45 PM, Anil Kumar wrote:
> Hi Jon,
>
> On Fri, Mar 8, 2013 at 10:57 PM, Jon Hunter <jon-hunter@ti.com> wrote:
>> Adds basic device-tree support for OMAP3430 SDP board which has 256MB
>> of RAM and uses the TWL4030 power management IC.
>>
>> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
>> ---
>> arch/arm/boot/dts/Makefile | 1 +
>> arch/arm/boot/dts/omap3430-sdp.dts | 46 ++++++++++++++++++++++++++++++++++++
>> 2 files changed, 47 insertions(+)
>> create mode 100644 arch/arm/boot/dts/omap3430-sdp.dts
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 9c62558..89013ed 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -119,6 +119,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
>> omap3-beagle-xm.dtb \
>> omap3-evm.dtb \
>> omap3-tobi.dtb \
>> + omap3430-sdp.dtb \
>> omap4-panda.dtb \
>> omap4-panda-a4.dtb \
>> omap4-panda-es.dtb \
>> diff --git a/arch/arm/boot/dts/omap3430-sdp.dts b/arch/arm/boot/dts/omap3430-sdp.dts
>> new file mode 100644
>> index 0000000..be0650d
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/omap3430-sdp.dts
>> @@ -0,0 +1,46 @@
>> +/*
>> + * Copyright (C) 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.
>> + */
>> +/dts-v1/;
>> +
>> +/include/ "omap3.dtsi"
>> +
>> +/ {
>> + model = "TI OMAP3430 SDP";
>> + compatible = "ti,omap3430-sdp", "ti,omap3";
>> +
>> + memory {
>> + device_type = "memory";
>> + reg = <0x80000000 0x10000000>; /* 256 MB */
>> + };
>> +};
>> +
>> +&i2c1 {
>> + clock-frequency = <2600000>;
>> +
>> + twl: twl@48 {
>> + reg = <0x48>;
>> + interrupts = <7>; /* SYS_NIRQ cascaded to intc */
>> + interrupt-parent = <&intc>;
>
> No need of "interrupt-parent = <&intc>" as it is with root node
> already.
Yes you are correct. Will update.
Thanks
Jon
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 5/9] ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5
2013-03-08 17:27 [PATCH 0/9] ARM: dts: Various OMAP2+ device-tree updates Jon Hunter
` (3 preceding siblings ...)
2013-03-08 17:27 ` [PATCH 4/9] ARM: dts: OMAP3: Add support for OMAP3430 SDP board Jon Hunter
@ 2013-03-08 17:27 ` Jon Hunter
2013-03-08 20:25 ` Javier Martinez Canillas
2013-03-08 17:27 ` [PATCH 6/9] ARM: dts: Add OMAP3430 SDP flash memory bindings Jon Hunter
` (4 subsequent siblings)
9 siblings, 1 reply; 37+ messages in thread
From: Jon Hunter @ 2013-03-08 17:27 UTC (permalink / raw)
To: Tony Lindgren, Benoit Cousson
Cc: device-tree, linux-omap, linux-arm, Jon Hunter
Add the device-tree node for GPMC on OMAP2, OMAP4 and OMAP5 devices.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
---
arch/arm/boot/dts/omap2420.dtsi | 11 +++++++++++
arch/arm/boot/dts/omap2430.dtsi | 11 +++++++++++
arch/arm/boot/dts/omap4.dtsi | 11 +++++++++++
arch/arm/boot/dts/omap5.dtsi | 11 +++++++++++
4 files changed, 44 insertions(+)
diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi
index af65609..d4ce6c2 100644
--- a/arch/arm/boot/dts/omap2420.dtsi
+++ b/arch/arm/boot/dts/omap2420.dtsi
@@ -29,6 +29,17 @@
pinctrl-single,function-mask = <0x3f>;
};
+ gpmc: gpmc@6800a000 {
+ compatible = "ti,omap2420-gpmc";
+ reg = <0x6800a000 0x1000>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ interrupts = <20>;
+ gpmc,num-cs = <8>;
+ gpmc,num-waitpins = <4>;
+ ti,hwmods = "gpmc";
+ };
+
mcbsp1: mcbsp@48074000 {
compatible = "ti,omap2420-mcbsp";
reg = <0x48074000 0xff>;
diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
index c392445..832f184 100644
--- a/arch/arm/boot/dts/omap2430.dtsi
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -29,6 +29,17 @@
pinctrl-single,function-mask = <0x3f>;
};
+ gpmc: gpmc@6e000000 {
+ compatible = "ti,omap2430-gpmc";
+ reg = <0x6e000000 0x1000>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ interrupts = <20>;
+ gpmc,num-cs = <8>;
+ gpmc,num-waitpins = <4>;
+ ti,hwmods = "gpmc";
+ };
+
mcbsp1: mcbsp@48074000 {
compatible = "ti,omap2430-mcbsp";
reg = <0x48074000 0xff>;
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 827f6f3..726ef11 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -196,6 +196,17 @@
#interrupt-cells = <1>;
};
+ gpmc: gpmc@50000000 {
+ compatible = "ti,omap4430-gpmc";
+ reg = <0x50000000 0x1000>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ interrupts = <0 20 0x4>;
+ gpmc,num-cs = <8>;
+ gpmc,num-waitpins = <4>;
+ ti,hwmods = "gpmc";
+ };
+
uart1: serial@4806a000 {
compatible = "ti,omap4-uart";
reg = <0x4806a000 0x100>;
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 06d21d6..34f41ad 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -208,6 +208,17 @@
#interrupt-cells = <1>;
};
+ gpmc: gpmc@50000000 {
+ compatible = "ti,omap4430-gpmc";
+ reg = <0x50000000 0x1000>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ interrupts = <0 20 0x4>;
+ gpmc,num-cs = <8>;
+ gpmc,num-waitpins = <4>;
+ ti,hwmods = "gpmc";
+ };
+
i2c1: i2c@48070000 {
compatible = "ti,omap4-i2c";
reg = <0x48070000 0x100>;
--
1.7.10.4
^ permalink raw reply related [flat|nested] 37+ messages in thread* Re: [PATCH 5/9] ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5
2013-03-08 17:27 ` [PATCH 5/9] ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5 Jon Hunter
@ 2013-03-08 20:25 ` Javier Martinez Canillas
2013-03-08 21:41 ` Jon Hunter
0 siblings, 1 reply; 37+ messages in thread
From: Javier Martinez Canillas @ 2013-03-08 20:25 UTC (permalink / raw)
To: Jon Hunter
Cc: Tony Lindgren, Benoit Cousson, device-tree, linux-omap, linux-arm
On Fri, Mar 8, 2013 at 6:27 PM, Jon Hunter <jon-hunter@ti.com> wrote:
> Add the device-tree node for GPMC on OMAP2, OMAP4 and OMAP5 devices.
>
> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
> ---
> arch/arm/boot/dts/omap2420.dtsi | 11 +++++++++++
> arch/arm/boot/dts/omap2430.dtsi | 11 +++++++++++
> arch/arm/boot/dts/omap4.dtsi | 11 +++++++++++
> arch/arm/boot/dts/omap5.dtsi | 11 +++++++++++
> 4 files changed, 44 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi
> index af65609..d4ce6c2 100644
> --- a/arch/arm/boot/dts/omap2420.dtsi
> +++ b/arch/arm/boot/dts/omap2420.dtsi
> @@ -29,6 +29,17 @@
> pinctrl-single,function-mask = <0x3f>;
> };
>
> + gpmc: gpmc@6800a000 {
> + compatible = "ti,omap2420-gpmc";
> + reg = <0x6800a000 0x1000>;
> + #address-cells = <2>;
> + #size-cells = <1>;
> + interrupts = <20>;
> + gpmc,num-cs = <8>;
> + gpmc,num-waitpins = <4>;
> + ti,hwmods = "gpmc";
> + };
> +
> mcbsp1: mcbsp@48074000 {
> compatible = "ti,omap2420-mcbsp";
> reg = <0x48074000 0xff>;
> diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
> index c392445..832f184 100644
> --- a/arch/arm/boot/dts/omap2430.dtsi
> +++ b/arch/arm/boot/dts/omap2430.dtsi
> @@ -29,6 +29,17 @@
> pinctrl-single,function-mask = <0x3f>;
> };
>
> + gpmc: gpmc@6e000000 {
> + compatible = "ti,omap2430-gpmc";
> + reg = <0x6e000000 0x1000>;
> + #address-cells = <2>;
> + #size-cells = <1>;
> + interrupts = <20>;
> + gpmc,num-cs = <8>;
> + gpmc,num-waitpins = <4>;
> + ti,hwmods = "gpmc";
> + };
> +
> mcbsp1: mcbsp@48074000 {
> compatible = "ti,omap2430-mcbsp";
> reg = <0x48074000 0xff>;
> diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
> index 827f6f3..726ef11 100644
> --- a/arch/arm/boot/dts/omap4.dtsi
> +++ b/arch/arm/boot/dts/omap4.dtsi
> @@ -196,6 +196,17 @@
> #interrupt-cells = <1>;
> };
>
> + gpmc: gpmc@50000000 {
> + compatible = "ti,omap4430-gpmc";
> + reg = <0x50000000 0x1000>;
Hi Jon,
By looking at the GPMC Register Summary from both the OMAP4460 and OMAP OMAP35x
Technical Reference Manuals I see that the GPMC register address space
is only 720 bytes length. From base address + 0x0 to base address +
0x02d0.
So shouldn't the regs property be <0x50000000 0x2d0> instead?
Of course are only a few kilobytes but still I wonder if it makes
sense to map them when they are not going to be used.
Best regards,
Javier
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: [PATCH 5/9] ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5
2013-03-08 20:25 ` Javier Martinez Canillas
@ 2013-03-08 21:41 ` Jon Hunter
2013-03-09 1:25 ` Javier Martinez Canillas
0 siblings, 1 reply; 37+ messages in thread
From: Jon Hunter @ 2013-03-08 21:41 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Tony Lindgren, Benoit Cousson, device-tree, linux-omap, linux-arm
On 03/08/2013 02:25 PM, Javier Martinez Canillas wrote:
> On Fri, Mar 8, 2013 at 6:27 PM, Jon Hunter <jon-hunter@ti.com> wrote:
>> Add the device-tree node for GPMC on OMAP2, OMAP4 and OMAP5 devices.
>>
>> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
>> ---
>> arch/arm/boot/dts/omap2420.dtsi | 11 +++++++++++
>> arch/arm/boot/dts/omap2430.dtsi | 11 +++++++++++
>> arch/arm/boot/dts/omap4.dtsi | 11 +++++++++++
>> arch/arm/boot/dts/omap5.dtsi | 11 +++++++++++
>> 4 files changed, 44 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi
>> index af65609..d4ce6c2 100644
>> --- a/arch/arm/boot/dts/omap2420.dtsi
>> +++ b/arch/arm/boot/dts/omap2420.dtsi
>> @@ -29,6 +29,17 @@
>> pinctrl-single,function-mask = <0x3f>;
>> };
>>
>> + gpmc: gpmc@6800a000 {
>> + compatible = "ti,omap2420-gpmc";
>> + reg = <0x6800a000 0x1000>;
>> + #address-cells = <2>;
>> + #size-cells = <1>;
>> + interrupts = <20>;
>> + gpmc,num-cs = <8>;
>> + gpmc,num-waitpins = <4>;
>> + ti,hwmods = "gpmc";
>> + };
>> +
>> mcbsp1: mcbsp@48074000 {
>> compatible = "ti,omap2420-mcbsp";
>> reg = <0x48074000 0xff>;
>> diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
>> index c392445..832f184 100644
>> --- a/arch/arm/boot/dts/omap2430.dtsi
>> +++ b/arch/arm/boot/dts/omap2430.dtsi
>> @@ -29,6 +29,17 @@
>> pinctrl-single,function-mask = <0x3f>;
>> };
>>
>> + gpmc: gpmc@6e000000 {
>> + compatible = "ti,omap2430-gpmc";
>> + reg = <0x6e000000 0x1000>;
>> + #address-cells = <2>;
>> + #size-cells = <1>;
>> + interrupts = <20>;
>> + gpmc,num-cs = <8>;
>> + gpmc,num-waitpins = <4>;
>> + ti,hwmods = "gpmc";
>> + };
>> +
>> mcbsp1: mcbsp@48074000 {
>> compatible = "ti,omap2430-mcbsp";
>> reg = <0x48074000 0xff>;
>> diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
>> index 827f6f3..726ef11 100644
>> --- a/arch/arm/boot/dts/omap4.dtsi
>> +++ b/arch/arm/boot/dts/omap4.dtsi
>> @@ -196,6 +196,17 @@
>> #interrupt-cells = <1>;
>> };
>>
>> + gpmc: gpmc@50000000 {
>> + compatible = "ti,omap4430-gpmc";
>> + reg = <0x50000000 0x1000>;
>
> Hi Jon,
>
> By looking at the GPMC Register Summary from both the OMAP4460 and OMAP OMAP35x
> Technical Reference Manuals I see that the GPMC register address space
> is only 720 bytes length. From base address + 0x0 to base address +
> 0x02d0.
>
> So shouldn't the regs property be <0x50000000 0x2d0> instead?
>
> Of course are only a few kilobytes but still I wonder if it makes
> sense to map them when they are not going to be used.
Yes you are correct. In general, I have been trying to stay some-what
consistent with what hwmod was doing as this was being auto-generated by
some hardware design specs and I believe they wanted to eventually get
to the point where DT files would be auto-generated too for OMAP.
Furthermore my understanding is that the smallest page that can be
mapped by the kernel for ARM is 4kB. So if you declare it as 0x2d0 or
0x1000 it will map a 4kB page (I could be wrong here).
I don't have any strong feelings here but will do what the consensus
prefers.
Cheers
Jon
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: [PATCH 5/9] ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5
2013-03-08 21:41 ` Jon Hunter
@ 2013-03-09 1:25 ` Javier Martinez Canillas
2013-03-09 12:42 ` Ezequiel Garcia
0 siblings, 1 reply; 37+ messages in thread
From: Javier Martinez Canillas @ 2013-03-09 1:25 UTC (permalink / raw)
To: Jon Hunter
Cc: Tony Lindgren, Benoit Cousson, device-tree, linux-omap, linux-arm
On Fri, Mar 8, 2013 at 10:41 PM, Jon Hunter <jon-hunter@ti.com> wrote:
>
> On 03/08/2013 02:25 PM, Javier Martinez Canillas wrote:
>> On Fri, Mar 8, 2013 at 6:27 PM, Jon Hunter <jon-hunter@ti.com> wrote:
>>> Add the device-tree node for GPMC on OMAP2, OMAP4 and OMAP5 devices.
>>>
>>> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
>>> ---
>>> arch/arm/boot/dts/omap2420.dtsi | 11 +++++++++++
>>> arch/arm/boot/dts/omap2430.dtsi | 11 +++++++++++
>>> arch/arm/boot/dts/omap4.dtsi | 11 +++++++++++
>>> arch/arm/boot/dts/omap5.dtsi | 11 +++++++++++
>>> 4 files changed, 44 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi
>>> index af65609..d4ce6c2 100644
>>> --- a/arch/arm/boot/dts/omap2420.dtsi
>>> +++ b/arch/arm/boot/dts/omap2420.dtsi
>>> @@ -29,6 +29,17 @@
>>> pinctrl-single,function-mask = <0x3f>;
>>> };
>>>
>>> + gpmc: gpmc@6800a000 {
>>> + compatible = "ti,omap2420-gpmc";
>>> + reg = <0x6800a000 0x1000>;
>>> + #address-cells = <2>;
>>> + #size-cells = <1>;
>>> + interrupts = <20>;
>>> + gpmc,num-cs = <8>;
>>> + gpmc,num-waitpins = <4>;
>>> + ti,hwmods = "gpmc";
>>> + };
>>> +
>>> mcbsp1: mcbsp@48074000 {
>>> compatible = "ti,omap2420-mcbsp";
>>> reg = <0x48074000 0xff>;
>>> diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
>>> index c392445..832f184 100644
>>> --- a/arch/arm/boot/dts/omap2430.dtsi
>>> +++ b/arch/arm/boot/dts/omap2430.dtsi
>>> @@ -29,6 +29,17 @@
>>> pinctrl-single,function-mask = <0x3f>;
>>> };
>>>
>>> + gpmc: gpmc@6e000000 {
>>> + compatible = "ti,omap2430-gpmc";
>>> + reg = <0x6e000000 0x1000>;
>>> + #address-cells = <2>;
>>> + #size-cells = <1>;
>>> + interrupts = <20>;
>>> + gpmc,num-cs = <8>;
>>> + gpmc,num-waitpins = <4>;
>>> + ti,hwmods = "gpmc";
>>> + };
>>> +
>>> mcbsp1: mcbsp@48074000 {
>>> compatible = "ti,omap2430-mcbsp";
>>> reg = <0x48074000 0xff>;
>>> diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
>>> index 827f6f3..726ef11 100644
>>> --- a/arch/arm/boot/dts/omap4.dtsi
>>> +++ b/arch/arm/boot/dts/omap4.dtsi
>>> @@ -196,6 +196,17 @@
>>> #interrupt-cells = <1>;
>>> };
>>>
>>> + gpmc: gpmc@50000000 {
>>> + compatible = "ti,omap4430-gpmc";
>>> + reg = <0x50000000 0x1000>;
>>
>> Hi Jon,
>>
>> By looking at the GPMC Register Summary from both the OMAP4460 and OMAP OMAP35x
>> Technical Reference Manuals I see that the GPMC register address space
>> is only 720 bytes length. From base address + 0x0 to base address +
>> 0x02d0.
>>
>> So shouldn't the regs property be <0x50000000 0x2d0> instead?
>>
>> Of course are only a few kilobytes but still I wonder if it makes
>> sense to map them when they are not going to be used.
>
> Yes you are correct. In general, I have been trying to stay some-what
> consistent with what hwmod was doing as this was being auto-generated by
> some hardware design specs and I believe they wanted to eventually get
> to the point where DT files would be auto-generated too for OMAP.
> Furthermore my understanding is that the smallest page that can be
> mapped by the kernel for ARM is 4kB. So if you declare it as 0x2d0 or
> 0x1000 it will map a 4kB page (I could be wrong here).
>
> I don't have any strong feelings here but will do what the consensus
> prefers.
>
Yes, you are right here.
I forget that ioremap() does a page-aligned mapping and since the
minimum page size for ARM is 4KB as you said, there is no difference
between using 0x2d0 and 0x1000. Sorry for the noise.
Reviewed-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> Cheers
> Jon
Best regards,
Javier
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: [PATCH 5/9] ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5
2013-03-09 1:25 ` Javier Martinez Canillas
@ 2013-03-09 12:42 ` Ezequiel Garcia
2013-03-11 17:56 ` Jon Hunter
0 siblings, 1 reply; 37+ messages in thread
From: Ezequiel Garcia @ 2013-03-09 12:42 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Jon Hunter, Tony Lindgren, Benoit Cousson, device-tree,
linux-omap, linux-arm
On Fri, Mar 8, 2013 at 10:25 PM, Javier Martinez Canillas
<javier@dowhile0.org> wrote:
> On Fri, Mar 8, 2013 at 10:41 PM, Jon Hunter <jon-hunter@ti.com> wrote:
>>
>> Yes you are correct. In general, I have been trying to stay some-what
>> consistent with what hwmod was doing as this was being auto-generated by
>> some hardware design specs and I believe they wanted to eventually get
>> to the point where DT files would be auto-generated too for OMAP.
>> Furthermore my understanding is that the smallest page that can be
>> mapped by the kernel for ARM is 4kB. So if you declare it as 0x2d0 or
>> 0x1000 it will map a 4kB page (I could be wrong here).
>>
>> I don't have any strong feelings here but will do what the consensus
>> prefers.
>>
>
> Yes, you are right here.
>
> I forget that ioremap() does a page-aligned mapping and since the
> minimum page size for ARM is 4KB as you said, there is no difference
> between using 0x2d0 and 0x1000. Sorry for the noise.
>
Certainly, I don't have strong feelings about this.
FWIW, mvebu maintainers imposes a "minimal" address space request
policy.
On the other side, it seems to me we shouldn't look at internal kernel
implementation (i.e. ioremap page-alignment) to make this decision.
Somehow, I feel this is almost a nitpick, so don't take this too seriously.
Regards,
--
Ezequiel
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: [PATCH 5/9] ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5
2013-03-09 12:42 ` Ezequiel Garcia
@ 2013-03-11 17:56 ` Jon Hunter
2013-03-14 15:45 ` Benoit Cousson
0 siblings, 1 reply; 37+ messages in thread
From: Jon Hunter @ 2013-03-11 17:56 UTC (permalink / raw)
To: Ezequiel Garcia
Cc: Javier Martinez Canillas, Tony Lindgren, Benoit Cousson,
device-tree, linux-omap, linux-arm
On 03/09/2013 06:42 AM, Ezequiel Garcia wrote:
> On Fri, Mar 8, 2013 at 10:25 PM, Javier Martinez Canillas
> <javier@dowhile0.org> wrote:
>> On Fri, Mar 8, 2013 at 10:41 PM, Jon Hunter <jon-hunter@ti.com> wrote:
>>>
>>> Yes you are correct. In general, I have been trying to stay some-what
>>> consistent with what hwmod was doing as this was being auto-generated by
>>> some hardware design specs and I believe they wanted to eventually get
>>> to the point where DT files would be auto-generated too for OMAP.
>>> Furthermore my understanding is that the smallest page that can be
>>> mapped by the kernel for ARM is 4kB. So if you declare it as 0x2d0 or
>>> 0x1000 it will map a 4kB page (I could be wrong here).
>>>
>>> I don't have any strong feelings here but will do what the consensus
>>> prefers.
>>>
>>
>> Yes, you are right here.
>>
>> I forget that ioremap() does a page-aligned mapping and since the
>> minimum page size for ARM is 4KB as you said, there is no difference
>> between using 0x2d0 and 0x1000. Sorry for the noise.
>>
>
> Certainly, I don't have strong feelings about this.
> FWIW, mvebu maintainers imposes a "minimal" address space request
> policy.
>
> On the other side, it seems to me we shouldn't look at internal kernel
> implementation (i.e. ioremap page-alignment) to make this decision.
I agree with that. I am not sure if Tony/Benoit have any comments on
what they would like to do here to be consistent for the omap bindings.
> Somehow, I feel this is almost a nitpick, so don't take this too seriously.
No problem. Probably good to align on something sooner rather than later.
Cheers
Jon
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 5/9] ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5
2013-03-11 17:56 ` Jon Hunter
@ 2013-03-14 15:45 ` Benoit Cousson
2013-03-14 15:50 ` Jon Hunter
0 siblings, 1 reply; 37+ messages in thread
From: Benoit Cousson @ 2013-03-14 15:45 UTC (permalink / raw)
To: Jon Hunter
Cc: Ezequiel Garcia, Javier Martinez Canillas, Tony Lindgren,
device-tree, linux-omap, linux-arm
On 03/11/2013 06:56 PM, Jon Hunter wrote:
>
> On 03/09/2013 06:42 AM, Ezequiel Garcia wrote:
>> On Fri, Mar 8, 2013 at 10:25 PM, Javier Martinez Canillas
>> <javier@dowhile0.org> wrote:
>>> On Fri, Mar 8, 2013 at 10:41 PM, Jon Hunter <jon-hunter@ti.com> wrote:
>>>>
>>>> Yes you are correct. In general, I have been trying to stay some-what
>>>> consistent with what hwmod was doing as this was being auto-generated by
>>>> some hardware design specs and I believe they wanted to eventually get
>>>> to the point where DT files would be auto-generated too for OMAP.
>>>> Furthermore my understanding is that the smallest page that can be
>>>> mapped by the kernel for ARM is 4kB. So if you declare it as 0x2d0 or
>>>> 0x1000 it will map a 4kB page (I could be wrong here).
>>>>
>>>> I don't have any strong feelings here but will do what the consensus
>>>> prefers.
>>>>
>>>
>>> Yes, you are right here.
>>>
>>> I forget that ioremap() does a page-aligned mapping and since the
>>> minimum page size for ARM is 4KB as you said, there is no difference
>>> between using 0x2d0 and 0x1000. Sorry for the noise.
>>>
>>
>> Certainly, I don't have strong feelings about this.
>> FWIW, mvebu maintainers imposes a "minimal" address space request
>> policy.
>>
>> On the other side, it seems to me we shouldn't look at internal kernel
>> implementation (i.e. ioremap page-alignment) to make this decision.
>
> I agree with that. I am not sure if Tony/Benoit have any comments on
> what they would like to do here to be consistent for the omap bindings.
Yes, I full agree with that as well. The size should be purely HW
related. So we should not take any assumption about the page size /
alignment.
Regards,
Benoit
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 5/9] ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5
2013-03-14 15:45 ` Benoit Cousson
@ 2013-03-14 15:50 ` Jon Hunter
2013-03-14 15:57 ` Ezequiel Garcia
2013-03-14 15:58 ` Benoit Cousson
0 siblings, 2 replies; 37+ messages in thread
From: Jon Hunter @ 2013-03-14 15:50 UTC (permalink / raw)
To: Benoit Cousson
Cc: Ezequiel Garcia, Javier Martinez Canillas, Tony Lindgren,
device-tree, linux-omap, linux-arm
On 03/14/2013 10:45 AM, Benoit Cousson wrote:
> On 03/11/2013 06:56 PM, Jon Hunter wrote:
>>
>> On 03/09/2013 06:42 AM, Ezequiel Garcia wrote:
>>> On Fri, Mar 8, 2013 at 10:25 PM, Javier Martinez Canillas
>>> <javier@dowhile0.org> wrote:
>>>> On Fri, Mar 8, 2013 at 10:41 PM, Jon Hunter <jon-hunter@ti.com> wrote:
>>>>>
>>>>> Yes you are correct. In general, I have been trying to stay some-what
>>>>> consistent with what hwmod was doing as this was being auto-generated by
>>>>> some hardware design specs and I believe they wanted to eventually get
>>>>> to the point where DT files would be auto-generated too for OMAP.
>>>>> Furthermore my understanding is that the smallest page that can be
>>>>> mapped by the kernel for ARM is 4kB. So if you declare it as 0x2d0 or
>>>>> 0x1000 it will map a 4kB page (I could be wrong here).
>>>>>
>>>>> I don't have any strong feelings here but will do what the consensus
>>>>> prefers.
>>>>>
>>>>
>>>> Yes, you are right here.
>>>>
>>>> I forget that ioremap() does a page-aligned mapping and since the
>>>> minimum page size for ARM is 4KB as you said, there is no difference
>>>> between using 0x2d0 and 0x1000. Sorry for the noise.
>>>>
>>>
>>> Certainly, I don't have strong feelings about this.
>>> FWIW, mvebu maintainers imposes a "minimal" address space request
>>> policy.
>>>
>>> On the other side, it seems to me we shouldn't look at internal kernel
>>> implementation (i.e. ioremap page-alignment) to make this decision.
>>
>> I agree with that. I am not sure if Tony/Benoit have any comments on
>> what they would like to do here to be consistent for the omap bindings.
>
> Yes, I full agree with that as well. The size should be purely HW
> related. So we should not take any assumption about the page size /
> alignment.
Ok, what is best to use? The size from hwmod structures or the size from
the documentation?
Cheers
Jon
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 5/9] ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5
2013-03-14 15:50 ` Jon Hunter
@ 2013-03-14 15:57 ` Ezequiel Garcia
2013-03-14 15:58 ` Benoit Cousson
1 sibling, 0 replies; 37+ messages in thread
From: Ezequiel Garcia @ 2013-03-14 15:57 UTC (permalink / raw)
To: Jon Hunter
Cc: Benoit Cousson, Javier Martinez Canillas, Tony Lindgren,
device-tree, linux-omap, linux-arm
On Thu, Mar 14, 2013 at 12:50 PM, Jon Hunter <jon-hunter@ti.com> wrote:
>> Yes, I full agree with that as well. The size should be purely HW
>> related. So we should not take any assumption about the page size /
>> alignment.
>
> Ok, what is best to use? The size from hwmod structures or the size from
> the documentation?
>
My personal vote is: according to hardware documentation is the right thing,
and it's what we're doing in mvebu.
--
Ezequiel
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: [PATCH 5/9] ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5
2013-03-14 15:50 ` Jon Hunter
2013-03-14 15:57 ` Ezequiel Garcia
@ 2013-03-14 15:58 ` Benoit Cousson
2013-03-14 16:00 ` Jon Hunter
1 sibling, 1 reply; 37+ messages in thread
From: Benoit Cousson @ 2013-03-14 15:58 UTC (permalink / raw)
To: Jon Hunter
Cc: Ezequiel Garcia, Javier Martinez Canillas, Tony Lindgren,
device-tree, linux-omap, linux-arm
On 03/14/2013 04:50 PM, Jon Hunter wrote:
>
> On 03/14/2013 10:45 AM, Benoit Cousson wrote:
>> On 03/11/2013 06:56 PM, Jon Hunter wrote:
>>>
>>> On 03/09/2013 06:42 AM, Ezequiel Garcia wrote:
>>>> On Fri, Mar 8, 2013 at 10:25 PM, Javier Martinez Canillas
>>>> <javier@dowhile0.org> wrote:
>>>>> On Fri, Mar 8, 2013 at 10:41 PM, Jon Hunter <jon-hunter@ti.com> wrote:
>>>>>>
>>>>>> Yes you are correct. In general, I have been trying to stay some-what
>>>>>> consistent with what hwmod was doing as this was being auto-generated by
>>>>>> some hardware design specs and I believe they wanted to eventually get
>>>>>> to the point where DT files would be auto-generated too for OMAP.
>>>>>> Furthermore my understanding is that the smallest page that can be
>>>>>> mapped by the kernel for ARM is 4kB. So if you declare it as 0x2d0 or
>>>>>> 0x1000 it will map a 4kB page (I could be wrong here).
>>>>>>
>>>>>> I don't have any strong feelings here but will do what the consensus
>>>>>> prefers.
>>>>>>
>>>>>
>>>>> Yes, you are right here.
>>>>>
>>>>> I forget that ioremap() does a page-aligned mapping and since the
>>>>> minimum page size for ARM is 4KB as you said, there is no difference
>>>>> between using 0x2d0 and 0x1000. Sorry for the noise.
>>>>>
>>>>
>>>> Certainly, I don't have strong feelings about this.
>>>> FWIW, mvebu maintainers imposes a "minimal" address space request
>>>> policy.
>>>>
>>>> On the other side, it seems to me we shouldn't look at internal kernel
>>>> implementation (i.e. ioremap page-alignment) to make this decision.
>>>
>>> I agree with that. I am not sure if Tony/Benoit have any comments on
>>> what they would like to do here to be consistent for the omap bindings.
>>
>> Yes, I full agree with that as well. The size should be purely HW
>> related. So we should not take any assumption about the page size /
>> alignment.
>
> Ok, what is best to use? The size from hwmod structures or the size from
> the documentation?
Well, in theory both are supposed to be identical :-)
I'm just applying a rounding to the closet power of two, that's why it
cannot be 0x2d0.
Regards,
Benoit
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 5/9] ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5
2013-03-14 15:58 ` Benoit Cousson
@ 2013-03-14 16:00 ` Jon Hunter
2013-03-14 16:03 ` Benoit Cousson
0 siblings, 1 reply; 37+ messages in thread
From: Jon Hunter @ 2013-03-14 16:00 UTC (permalink / raw)
To: Benoit Cousson
Cc: Ezequiel Garcia, Javier Martinez Canillas, Tony Lindgren,
device-tree, linux-omap, linux-arm
On 03/14/2013 10:58 AM, Benoit Cousson wrote:
> On 03/14/2013 04:50 PM, Jon Hunter wrote:
>>
>> On 03/14/2013 10:45 AM, Benoit Cousson wrote:
>>> On 03/11/2013 06:56 PM, Jon Hunter wrote:
>>>>
>>>> On 03/09/2013 06:42 AM, Ezequiel Garcia wrote:
>>>>> On Fri, Mar 8, 2013 at 10:25 PM, Javier Martinez Canillas
>>>>> <javier@dowhile0.org> wrote:
>>>>>> On Fri, Mar 8, 2013 at 10:41 PM, Jon Hunter <jon-hunter@ti.com> wrote:
>>>>>>>
>>>>>>> Yes you are correct. In general, I have been trying to stay some-what
>>>>>>> consistent with what hwmod was doing as this was being auto-generated by
>>>>>>> some hardware design specs and I believe they wanted to eventually get
>>>>>>> to the point where DT files would be auto-generated too for OMAP.
>>>>>>> Furthermore my understanding is that the smallest page that can be
>>>>>>> mapped by the kernel for ARM is 4kB. So if you declare it as 0x2d0 or
>>>>>>> 0x1000 it will map a 4kB page (I could be wrong here).
>>>>>>>
>>>>>>> I don't have any strong feelings here but will do what the consensus
>>>>>>> prefers.
>>>>>>>
>>>>>>
>>>>>> Yes, you are right here.
>>>>>>
>>>>>> I forget that ioremap() does a page-aligned mapping and since the
>>>>>> minimum page size for ARM is 4KB as you said, there is no difference
>>>>>> between using 0x2d0 and 0x1000. Sorry for the noise.
>>>>>>
>>>>>
>>>>> Certainly, I don't have strong feelings about this.
>>>>> FWIW, mvebu maintainers imposes a "minimal" address space request
>>>>> policy.
>>>>>
>>>>> On the other side, it seems to me we shouldn't look at internal kernel
>>>>> implementation (i.e. ioremap page-alignment) to make this decision.
>>>>
>>>> I agree with that. I am not sure if Tony/Benoit have any comments on
>>>> what they would like to do here to be consistent for the omap bindings.
>>>
>>> Yes, I full agree with that as well. The size should be purely HW
>>> related. So we should not take any assumption about the page size /
>>> alignment.
>>
>> Ok, what is best to use? The size from hwmod structures or the size from
>> the documentation?
>
> Well, in theory both are supposed to be identical :-)
> I'm just applying a rounding to the closet power of two, that's why it
> cannot be 0x2d0.
Ok I understand. However, still not clear what you want me to use :-(
Jon
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 5/9] ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5
2013-03-14 16:00 ` Jon Hunter
@ 2013-03-14 16:03 ` Benoit Cousson
0 siblings, 0 replies; 37+ messages in thread
From: Benoit Cousson @ 2013-03-14 16:03 UTC (permalink / raw)
To: Jon Hunter
Cc: Ezequiel Garcia, Javier Martinez Canillas, Tony Lindgren,
device-tree, linux-omap, linux-arm
On 03/14/2013 05:00 PM, Jon Hunter wrote:
>
>
> On 03/14/2013 10:58 AM, Benoit Cousson wrote:
>> On 03/14/2013 04:50 PM, Jon Hunter wrote:
>>>
>>> On 03/14/2013 10:45 AM, Benoit Cousson wrote:
>>>> On 03/11/2013 06:56 PM, Jon Hunter wrote:
>>>>>
>>>>> On 03/09/2013 06:42 AM, Ezequiel Garcia wrote:
>>>>>> On Fri, Mar 8, 2013 at 10:25 PM, Javier Martinez Canillas
>>>>>> <javier@dowhile0.org> wrote:
>>>>>>> On Fri, Mar 8, 2013 at 10:41 PM, Jon Hunter <jon-hunter@ti.com> wrote:
>>>>>>>>
>>>>>>>> Yes you are correct. In general, I have been trying to stay some-what
>>>>>>>> consistent with what hwmod was doing as this was being auto-generated by
>>>>>>>> some hardware design specs and I believe they wanted to eventually get
>>>>>>>> to the point where DT files would be auto-generated too for OMAP.
>>>>>>>> Furthermore my understanding is that the smallest page that can be
>>>>>>>> mapped by the kernel for ARM is 4kB. So if you declare it as 0x2d0 or
>>>>>>>> 0x1000 it will map a 4kB page (I could be wrong here).
>>>>>>>>
>>>>>>>> I don't have any strong feelings here but will do what the consensus
>>>>>>>> prefers.
>>>>>>>>
>>>>>>>
>>>>>>> Yes, you are right here.
>>>>>>>
>>>>>>> I forget that ioremap() does a page-aligned mapping and since the
>>>>>>> minimum page size for ARM is 4KB as you said, there is no difference
>>>>>>> between using 0x2d0 and 0x1000. Sorry for the noise.
>>>>>>>
>>>>>>
>>>>>> Certainly, I don't have strong feelings about this.
>>>>>> FWIW, mvebu maintainers imposes a "minimal" address space request
>>>>>> policy.
>>>>>>
>>>>>> On the other side, it seems to me we shouldn't look at internal kernel
>>>>>> implementation (i.e. ioremap page-alignment) to make this decision.
>>>>>
>>>>> I agree with that. I am not sure if Tony/Benoit have any comments on
>>>>> what they would like to do here to be consistent for the omap bindings.
>>>>
>>>> Yes, I full agree with that as well. The size should be purely HW
>>>> related. So we should not take any assumption about the page size /
>>>> alignment.
>>>
>>> Ok, what is best to use? The size from hwmod structures or the size from
>>> the documentation?
>>
>> Well, in theory both are supposed to be identical :-)
>> I'm just applying a rounding to the closet power of two, that's why it
>> cannot be 0x2d0.
>
> Ok I understand. However, still not clear what you want me to use :-(
That's on purpose :-)
Take 0x2d0, we could always remove the rounding in the generation part
to stick to the HW documentation.
Regards
Benoit
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 6/9] ARM: dts: Add OMAP3430 SDP flash memory bindings
2013-03-08 17:27 [PATCH 0/9] ARM: dts: Various OMAP2+ device-tree updates Jon Hunter
` (4 preceding siblings ...)
2013-03-08 17:27 ` [PATCH 5/9] ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5 Jon Hunter
@ 2013-03-08 17:27 ` Jon Hunter
2013-03-08 17:27 ` [PATCH 7/9] ARM: dts: Add OMAP2 gpio bindings Jon Hunter
` (3 subsequent siblings)
9 siblings, 0 replies; 37+ messages in thread
From: Jon Hunter @ 2013-03-08 17:27 UTC (permalink / raw)
To: Tony Lindgren, Benoit Cousson
Cc: device-tree, linux-omap, linux-arm, Jon Hunter
Add the device-tree nodes for the 128MB ONENAND flash and 256MB NAND
flash memories found on the OMAP3430 SDP board.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
---
arch/arm/boot/dts/omap3430-sdp.dts | 95 ++++++++++++++++++++++++++++++++++++
1 file changed, 95 insertions(+)
diff --git a/arch/arm/boot/dts/omap3430-sdp.dts b/arch/arm/boot/dts/omap3430-sdp.dts
index be0650d..c313762 100644
--- a/arch/arm/boot/dts/omap3430-sdp.dts
+++ b/arch/arm/boot/dts/omap3430-sdp.dts
@@ -44,3 +44,98 @@
&mmc3 {
status = "disabled";
};
+
+&gpmc {
+ ranges = <1 0 0x28000000 0x08000000>,
+ <2 0 0x20000000 0x10000000>;
+
+ nand@1,0 {
+ linux,mtd-name= "micron,mt29f1g08abb";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <1 0 0x08000000>;
+ nand-bus-width = <8>;
+
+ gpmc,device_nand;
+ gpmc,cs-on = <0>;
+ gpmc,cs-rd-off = <36>;
+ gpmc,cs-wr-off = <36>;
+ gpmc,adv-on = <6>;
+ gpmc,adv-rd-off = <24>;
+ gpmc,adv-wr-off = <36>;
+ gpmc,oe-on = <6>;
+ gpmc,oe-off = <48>;
+ gpmc,we-on = <6>;
+ gpmc,we-off = <30>;
+ gpmc,rd-cycle = <72>;
+ gpmc,wr-cycle = <72>;
+ gpmc,access = <54>;
+ gpmc,wr-access = <30>;
+
+ partition@0 {
+ label = "xloader-nand";
+ reg = <0 0x80000>;
+ };
+ partition@0x80000 {
+ label = "bootloader-nand";
+ reg = <0x80000 0x140000>;
+ };
+ partition@0x1c0000 {
+ label = "params-nand";
+ reg = <0x1c0000 0xc0000>;
+ };
+ partition@0x280000 {
+ label = "kernel-nand";
+ reg = <0x280000 0x500000>;
+ };
+ partition@0x780000 {
+ label = "filesystem-nand";
+ reg = <0x780000 0x7880000>;
+ };
+ };
+
+ onenand@2,0 {
+ linux,mtd-name= "samsung,kfm2g16q2m-deb8";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <2 0 0x10000000>;
+
+ gpmc,device-width = <2>;
+ gpmc,mux-add-data = <2>;
+ gpmc,cs-on = <0>;
+ gpmc,cs-rd-off = <84>;
+ gpmc,cs-wr-off = <72>;
+ gpmc,adv-on = <0>;
+ gpmc,adv-rd-off = <18>;
+ gpmc,adv-wr-off = <18>;
+ gpmc,oe-on = <30>;
+ gpmc,oe-off = <84>;
+ gpmc,we-on = <0>;
+ gpmc,we-off = <42>;
+ gpmc,rd-cycle = <108>;
+ gpmc,wr-cycle = <96>;
+ gpmc,access = <78>;
+ gpmc,wr-data-mux-bus = <30>;
+
+ partition@0 {
+ label = "xloader-onenand";
+ reg = <0 0x80000>;
+ };
+ partition@0x80000 {
+ label = "bootloader-onenand";
+ reg = <0x80000 0x40000>;
+ };
+ partition@0xc0000 {
+ label = "params-onenand";
+ reg = <0xc0000 0x20000>;
+ };
+ partition@0xe0000 {
+ label = "kernel-onenand";
+ reg = <0xe0000 0x200000>;
+ };
+ partition@0x2e0000 {
+ label = "filesystem-onenand";
+ reg = <0x2e0000 0xfd20000>;
+ };
+ };
+};
--
1.7.10.4
^ permalink raw reply related [flat|nested] 37+ messages in thread* [PATCH 7/9] ARM: dts: Add OMAP2 gpio bindings
2013-03-08 17:27 [PATCH 0/9] ARM: dts: Various OMAP2+ device-tree updates Jon Hunter
` (5 preceding siblings ...)
2013-03-08 17:27 ` [PATCH 6/9] ARM: dts: Add OMAP3430 SDP flash memory bindings Jon Hunter
@ 2013-03-08 17:27 ` Jon Hunter
2013-03-08 17:27 ` [PATCH 8/9] ARM: dts: OMAP3+: Correct gpio #interrupts-cells property Jon Hunter
` (2 subsequent siblings)
9 siblings, 0 replies; 37+ messages in thread
From: Jon Hunter @ 2013-03-08 17:27 UTC (permalink / raw)
To: Tony Lindgren, Benoit Cousson
Cc: device-tree, linux-omap, linux-arm, Jon Hunter
Add gpios bindings for OMAP2420 and OMAP2430 devices.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
---
arch/arm/boot/dts/omap2420.dtsi | 44 +++++++++++++++++++++++++++++++
arch/arm/boot/dts/omap2430.dtsi | 55 +++++++++++++++++++++++++++++++++++++++
2 files changed, 99 insertions(+)
diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi
index d4ce6c2..eee902f 100644
--- a/arch/arm/boot/dts/omap2420.dtsi
+++ b/arch/arm/boot/dts/omap2420.dtsi
@@ -29,6 +29,50 @@
pinctrl-single,function-mask = <0x3f>;
};
+ gpio1: gpio@48018000 {
+ compatible = "ti,omap2-gpio";
+ reg = <0x48018000 0x200>;
+ interrupts = <29>;
+ ti,hwmods = "gpio1";
+ #gpio-cells = <2>;
+ gpio-controller;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ };
+
+ gpio2: gpio@4801a000 {
+ compatible = "ti,omap2-gpio";
+ reg = <0x4801a000 0x200>;
+ interrupts = <30>;
+ ti,hwmods = "gpio2";
+ #gpio-cells = <2>;
+ gpio-controller;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ };
+
+ gpio3: gpio@4801c000 {
+ compatible = "ti,omap2-gpio";
+ reg = <0x4801c000 0x200>;
+ interrupts = <31>;
+ ti,hwmods = "gpio3";
+ #gpio-cells = <2>;
+ gpio-controller;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ };
+
+ gpio4: gpio@4801e000 {
+ compatible = "ti,omap2-gpio";
+ reg = <0x4801e000 0x200>;
+ interrupts = <32>;
+ ti,hwmods = "gpio4";
+ #gpio-cells = <2>;
+ gpio-controller;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ };
+
gpmc: gpmc@6800a000 {
compatible = "ti,omap2420-gpmc";
reg = <0x6800a000 0x1000>;
diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
index 832f184..fb74382 100644
--- a/arch/arm/boot/dts/omap2430.dtsi
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -29,6 +29,61 @@
pinctrl-single,function-mask = <0x3f>;
};
+ gpio1: gpio@4900c000 {
+ compatible = "ti,omap2-gpio";
+ reg = <0x4900c000 0x200>;
+ interrupts = <29>;
+ ti,hwmods = "gpio1";
+ #gpio-cells = <2>;
+ gpio-controller;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ };
+
+ gpio2: gpio@4900e000 {
+ compatible = "ti,omap2-gpio";
+ reg = <0x4900e000 0x200>;
+ interrupts = <30>;
+ ti,hwmods = "gpio2";
+ #gpio-cells = <2>;
+ gpio-controller;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ };
+
+ gpio3: gpio@49010000 {
+ compatible = "ti,omap2-gpio";
+ reg = <0x49010000 0x200>;
+ interrupts = <31>;
+ ti,hwmods = "gpio3";
+ #gpio-cells = <2>;
+ gpio-controller;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ };
+
+ gpio4: gpio@49012000 {
+ compatible = "ti,omap2-gpio";
+ reg = <0x49012000 0x200>;
+ interrupts = <32>;
+ ti,hwmods = "gpio4";
+ #gpio-cells = <2>;
+ gpio-controller;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ };
+
+ gpio5: gpio@480b6000 {
+ compatible = "ti,omap2-gpio";
+ reg = <0x480b6000 0x200>;
+ interrupts = <33>;
+ ti,hwmods = "gpio5";
+ #gpio-cells = <2>;
+ gpio-controller;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ };
+
gpmc: gpmc@6e000000 {
compatible = "ti,omap2430-gpmc";
reg = <0x6e000000 0x1000>;
--
1.7.10.4
^ permalink raw reply related [flat|nested] 37+ messages in thread* [PATCH 8/9] ARM: dts: OMAP3+: Correct gpio #interrupts-cells property
2013-03-08 17:27 [PATCH 0/9] ARM: dts: Various OMAP2+ device-tree updates Jon Hunter
` (6 preceding siblings ...)
2013-03-08 17:27 ` [PATCH 7/9] ARM: dts: Add OMAP2 gpio bindings Jon Hunter
@ 2013-03-08 17:27 ` Jon Hunter
2013-03-08 17:27 ` [PATCH 9/9] ARM: dts: OMAP3: Add reg and interrupt properties for gpio Jon Hunter
2013-03-14 14:57 ` [PATCH 0/9] ARM: dts: Various OMAP2+ device-tree updates Benoit Cousson
9 siblings, 0 replies; 37+ messages in thread
From: Jon Hunter @ 2013-03-08 17:27 UTC (permalink / raw)
To: Tony Lindgren, Benoit Cousson
Cc: device-tree, linux-omap, linux-arm, Jon Hunter
The OMAP gpio binding documention [1] states that the #interrupts-cells
property for gpio controllers should be 2. Currently, for OMAP3+ devices
the #interrupt-cells is set to 1. By setting this property to 2, it
allows clients to pass a 2nd parameter indicating the sensitivity (level
or edge) and polarity (high or low) of the interrupt. The OMAP gpio
controllers support these options and so update the #interrupt-cells
property for OMAP3+ devices to 2.
[1] Documentation/devicetree/bindings/gpio/gpio-omap.txt
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
---
arch/arm/boot/dts/omap3.dtsi | 12 ++++++------
arch/arm/boot/dts/omap4.dtsi | 12 ++++++------
arch/arm/boot/dts/omap5.dtsi | 16 ++++++++--------
3 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 5b36de5..c9bedf7 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -117,7 +117,7 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
- #interrupt-cells = <1>;
+ #interrupt-cells = <2>;
};
gpio2: gpio@49050000 {
@@ -126,7 +126,7 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
- #interrupt-cells = <1>;
+ #interrupt-cells = <2>;
};
gpio3: gpio@49052000 {
@@ -135,7 +135,7 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
- #interrupt-cells = <1>;
+ #interrupt-cells = <2>;
};
gpio4: gpio@49054000 {
@@ -144,7 +144,7 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
- #interrupt-cells = <1>;
+ #interrupt-cells = <2>;
};
gpio5: gpio@49056000 {
@@ -153,7 +153,7 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
- #interrupt-cells = <1>;
+ #interrupt-cells = <2>;
};
gpio6: gpio@49058000 {
@@ -162,7 +162,7 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
- #interrupt-cells = <1>;
+ #interrupt-cells = <2>;
};
uart1: serial@4806a000 {
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 726ef11..544be06 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -138,7 +138,7 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
- #interrupt-cells = <1>;
+ #interrupt-cells = <2>;
};
gpio2: gpio@48055000 {
@@ -149,7 +149,7 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
- #interrupt-cells = <1>;
+ #interrupt-cells = <2>;
};
gpio3: gpio@48057000 {
@@ -160,7 +160,7 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
- #interrupt-cells = <1>;
+ #interrupt-cells = <2>;
};
gpio4: gpio@48059000 {
@@ -171,7 +171,7 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
- #interrupt-cells = <1>;
+ #interrupt-cells = <2>;
};
gpio5: gpio@4805b000 {
@@ -182,7 +182,7 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
- #interrupt-cells = <1>;
+ #interrupt-cells = <2>;
};
gpio6: gpio@4805d000 {
@@ -193,7 +193,7 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
- #interrupt-cells = <1>;
+ #interrupt-cells = <2>;
};
gpmc: gpmc@50000000 {
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 34f41ad..93feb50 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -128,7 +128,7 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
- #interrupt-cells = <1>;
+ #interrupt-cells = <2>;
};
gpio2: gpio@48055000 {
@@ -139,7 +139,7 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
- #interrupt-cells = <1>;
+ #interrupt-cells = <2>;
};
gpio3: gpio@48057000 {
@@ -150,7 +150,7 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
- #interrupt-cells = <1>;
+ #interrupt-cells = <2>;
};
gpio4: gpio@48059000 {
@@ -161,7 +161,7 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
- #interrupt-cells = <1>;
+ #interrupt-cells = <2>;
};
gpio5: gpio@4805b000 {
@@ -172,7 +172,7 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
- #interrupt-cells = <1>;
+ #interrupt-cells = <2>;
};
gpio6: gpio@4805d000 {
@@ -183,7 +183,7 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
- #interrupt-cells = <1>;
+ #interrupt-cells = <2>;
};
gpio7: gpio@48051000 {
@@ -194,7 +194,7 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
- #interrupt-cells = <1>;
+ #interrupt-cells = <2>;
};
gpio8: gpio@48053000 {
@@ -205,7 +205,7 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
- #interrupt-cells = <1>;
+ #interrupt-cells = <2>;
};
gpmc: gpmc@50000000 {
--
1.7.10.4
^ permalink raw reply related [flat|nested] 37+ messages in thread* [PATCH 9/9] ARM: dts: OMAP3: Add reg and interrupt properties for gpio
2013-03-08 17:27 [PATCH 0/9] ARM: dts: Various OMAP2+ device-tree updates Jon Hunter
` (7 preceding siblings ...)
2013-03-08 17:27 ` [PATCH 8/9] ARM: dts: OMAP3+: Correct gpio #interrupts-cells property Jon Hunter
@ 2013-03-08 17:27 ` Jon Hunter
2013-03-14 14:57 ` [PATCH 0/9] ARM: dts: Various OMAP2+ device-tree updates Benoit Cousson
9 siblings, 0 replies; 37+ messages in thread
From: Jon Hunter @ 2013-03-08 17:27 UTC (permalink / raw)
To: Tony Lindgren, Benoit Cousson
Cc: device-tree, linux-omap, linux-arm, Jon Hunter
The OMAP3 gpio bindings are currently missing the reg and interrupt
properties and so add these properties.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
---
arch/arm/boot/dts/omap3.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index c9bedf7..f4651af 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -113,6 +113,8 @@
gpio1: gpio@48310000 {
compatible = "ti,omap3-gpio";
+ reg = <0x48310000 0x200>;
+ interrupts = <29>;
ti,hwmods = "gpio1";
gpio-controller;
#gpio-cells = <2>;
@@ -122,6 +124,8 @@
gpio2: gpio@49050000 {
compatible = "ti,omap3-gpio";
+ reg = <0x49050000 0x200>;
+ interrupts = <30>;
ti,hwmods = "gpio2";
gpio-controller;
#gpio-cells = <2>;
@@ -131,6 +135,8 @@
gpio3: gpio@49052000 {
compatible = "ti,omap3-gpio";
+ reg = <0x49052000 0x200>;
+ interrupts = <31>;
ti,hwmods = "gpio3";
gpio-controller;
#gpio-cells = <2>;
@@ -140,6 +146,8 @@
gpio4: gpio@49054000 {
compatible = "ti,omap3-gpio";
+ reg = <0x49054000 0x200>;
+ interrupts = <32>;
ti,hwmods = "gpio4";
gpio-controller;
#gpio-cells = <2>;
@@ -149,6 +157,8 @@
gpio5: gpio@49056000 {
compatible = "ti,omap3-gpio";
+ reg = <0x49056000 0x200>;
+ interrupts = <33>;
ti,hwmods = "gpio5";
gpio-controller;
#gpio-cells = <2>;
@@ -158,6 +168,8 @@
gpio6: gpio@49058000 {
compatible = "ti,omap3-gpio";
+ reg = <0x49058000 0x200>;
+ interrupts = <34>;
ti,hwmods = "gpio6";
gpio-controller;
#gpio-cells = <2>;
--
1.7.10.4
^ permalink raw reply related [flat|nested] 37+ messages in thread* Re: [PATCH 0/9] ARM: dts: Various OMAP2+ device-tree updates
2013-03-08 17:27 [PATCH 0/9] ARM: dts: Various OMAP2+ device-tree updates Jon Hunter
` (8 preceding siblings ...)
2013-03-08 17:27 ` [PATCH 9/9] ARM: dts: OMAP3: Add reg and interrupt properties for gpio Jon Hunter
@ 2013-03-14 14:57 ` Benoit Cousson
2013-03-14 15:45 ` Florian Vaussard
2013-03-14 16:02 ` Javier Martinez Canillas
9 siblings, 2 replies; 37+ messages in thread
From: Benoit Cousson @ 2013-03-14 14:57 UTC (permalink / raw)
To: Jon Hunter; +Cc: Tony Lindgren, device-tree, linux-omap, linux-arm
Salut Jon,
On 03/08/2013 06:27 PM, Jon Hunter wrote:
> Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards.
>
> The DMA, PMU and OMAP3430 SDP board changes have been sent before
> individually but re-sending here as a complete series for v3.10.
>
> This is based upon v3.9-rc1 and the OMAP3 GPMC binding from Florian
> Vaussard [1] and OMAP5 DT SPI patch from Felipe Balbi [2].
>
> [1] https://patchwork.kernel.org/patch/2057111/
I've tried to follow the series review, and it seems that Florian was
considering sending some other patches. It is not clear if this is a new
version of the series or some additional patches.
I still did not merge this series wondering what to do with it.
Felipe's patch on this other hand is already applied in my branch.
Regards,
Benoit
> [2] https://patchwork.kernel.org/patch/2134711/
>
> Jon Hunter (9):
> ARM: OMAP2+: Prepare for device-tree PMU support
> ARM: dts: OMAP2+: Add PMU nodes
> ARM: dts: OMAP2+: Add SDMA controller bindings and nodes
> ARM: dts: OMAP3: Add support for OMAP3430 SDP board
> ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5
> ARM: dts: Add OMAP3430 SDP flash memory bindings
> ARM: dts: Add OMAP2 gpio bindings
> ARM: dts: OMAP3+: Correct gpio #interrupts-cells property
> ARM: dts: OMAP3: Add reg and interrupt properties for gpio
>
> .../devicetree/bindings/dma/omap-sdma.txt | 51 +++++++
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/omap2.dtsi | 17 +++
> arch/arm/boot/dts/omap2420.dtsi | 55 ++++++++
> arch/arm/boot/dts/omap2430.dtsi | 66 +++++++++
> arch/arm/boot/dts/omap3.dtsi | 70 +++++++++-
> arch/arm/boot/dts/omap3430-sdp.dts | 141 ++++++++++++++++++++
> arch/arm/boot/dts/omap4-panda-es.dts | 2 +
> arch/arm/boot/dts/omap4.dtsi | 64 ++++++++-
> arch/arm/boot/dts/omap4460.dtsi | 18 +++
> arch/arm/boot/dts/omap5.dtsi | 68 ++++++++--
> arch/arm/mach-omap2/pmu.c | 14 +-
> 12 files changed, 544 insertions(+), 23 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/dma/omap-sdma.txt
> create mode 100644 arch/arm/boot/dts/omap3430-sdp.dts
> create mode 100644 arch/arm/boot/dts/omap4460.dtsi
>
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: [PATCH 0/9] ARM: dts: Various OMAP2+ device-tree updates
2013-03-14 14:57 ` [PATCH 0/9] ARM: dts: Various OMAP2+ device-tree updates Benoit Cousson
@ 2013-03-14 15:45 ` Florian Vaussard
2013-03-14 15:59 ` Jon Hunter
2013-03-14 16:02 ` Javier Martinez Canillas
1 sibling, 1 reply; 37+ messages in thread
From: Florian Vaussard @ 2013-03-14 15:45 UTC (permalink / raw)
To: Benoit Cousson
Cc: Jon Hunter, Tony Lindgren, device-tree, linux-omap, linux-arm
Hi Benoit,
On 03/14/2013 03:57 PM, Benoit Cousson wrote:
> Salut Jon,
>
> On 03/08/2013 06:27 PM, Jon Hunter wrote:
>> Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards.
>>
>> The DMA, PMU and OMAP3430 SDP board changes have been sent before
>> individually but re-sending here as a complete series for v3.10.
>>
>> This is based upon v3.9-rc1 and the OMAP3 GPMC binding from Florian
>> Vaussard [1] and OMAP5 DT SPI patch from Felipe Balbi [2].
>>
>> [1] https://patchwork.kernel.org/patch/2057111/
>
> I've tried to follow the series review, and it seems that Florian was
> considering sending some other patches. It is not clear if this is a new
> version of the series or some additional patches.
>
Concerning patch [1], it can be merged to add the GPMC binding for OMAP3.
But please discard the rest of my original series, I will repost something
later.
Regards,
Florian
> I still did not merge this series wondering what to do with it.
>
> Felipe's patch on this other hand is already applied in my branch.
>
> Regards,
> Benoit
>
>> [2] https://patchwork.kernel.org/patch/2134711/
>>
>> Jon Hunter (9):
>> ARM: OMAP2+: Prepare for device-tree PMU support
>> ARM: dts: OMAP2+: Add PMU nodes
>> ARM: dts: OMAP2+: Add SDMA controller bindings and nodes
>> ARM: dts: OMAP3: Add support for OMAP3430 SDP board
>> ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5
>> ARM: dts: Add OMAP3430 SDP flash memory bindings
>> ARM: dts: Add OMAP2 gpio bindings
>> ARM: dts: OMAP3+: Correct gpio #interrupts-cells property
>> ARM: dts: OMAP3: Add reg and interrupt properties for gpio
>>
>> .../devicetree/bindings/dma/omap-sdma.txt | 51 +++++++
>> arch/arm/boot/dts/Makefile | 1 +
>> arch/arm/boot/dts/omap2.dtsi | 17 +++
>> arch/arm/boot/dts/omap2420.dtsi | 55 ++++++++
>> arch/arm/boot/dts/omap2430.dtsi | 66 +++++++++
>> arch/arm/boot/dts/omap3.dtsi | 70 +++++++++-
>> arch/arm/boot/dts/omap3430-sdp.dts | 141 ++++++++++++++++++++
>> arch/arm/boot/dts/omap4-panda-es.dts | 2 +
>> arch/arm/boot/dts/omap4.dtsi | 64 ++++++++-
>> arch/arm/boot/dts/omap4460.dtsi | 18 +++
>> arch/arm/boot/dts/omap5.dtsi | 68 ++++++++--
>> arch/arm/mach-omap2/pmu.c | 14 +-
>> 12 files changed, 544 insertions(+), 23 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/dma/omap-sdma.txt
>> create mode 100644 arch/arm/boot/dts/omap3430-sdp.dts
>> create mode 100644 arch/arm/boot/dts/omap4460.dtsi
>>
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 0/9] ARM: dts: Various OMAP2+ device-tree updates
2013-03-14 15:45 ` Florian Vaussard
@ 2013-03-14 15:59 ` Jon Hunter
2013-03-14 16:06 ` Benoit Cousson
0 siblings, 1 reply; 37+ messages in thread
From: Jon Hunter @ 2013-03-14 15:59 UTC (permalink / raw)
To: florian.vaussard
Cc: Benoit Cousson, Tony Lindgren, device-tree, linux-omap, linux-arm
On 03/14/2013 10:45 AM, Florian Vaussard wrote:
> Hi Benoit,
>
> On 03/14/2013 03:57 PM, Benoit Cousson wrote:
>> Salut Jon,
>>
>> On 03/08/2013 06:27 PM, Jon Hunter wrote:
>>> Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards.
>>>
>>> The DMA, PMU and OMAP3430 SDP board changes have been sent before
>>> individually but re-sending here as a complete series for v3.10.
>>>
>>> This is based upon v3.9-rc1 and the OMAP3 GPMC binding from Florian
>>> Vaussard [1] and OMAP5 DT SPI patch from Felipe Balbi [2].
>>>
>>> [1] https://patchwork.kernel.org/patch/2057111/
>>
>> I've tried to follow the series review, and it seems that Florian was
>> considering sending some other patches. It is not clear if this is a new
>> version of the series or some additional patches.
A bit of both. Sorry for the confusion :-)
> Concerning patch [1], it can be merged to add the GPMC binding for OMAP3.
> But please discard the rest of my original series, I will repost something
> later.
Benoit, if you pick up Florian's patch, I will re-post my remaining
patches for you to pick up.
By the way, I see that you have picked up the PMU bindings, however,
ideally we should merge the "pmu prepare" patch first. We agreed with
Tony for you to take this with his ack [1].
Let me know if you just want me to re-post that one on top of your branch.
Cheers
Jon
[1] http://comments.gmane.org/gmane.linux.ports.arm.omap/91036
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 0/9] ARM: dts: Various OMAP2+ device-tree updates
2013-03-14 15:59 ` Jon Hunter
@ 2013-03-14 16:06 ` Benoit Cousson
0 siblings, 0 replies; 37+ messages in thread
From: Benoit Cousson @ 2013-03-14 16:06 UTC (permalink / raw)
To: Jon Hunter
Cc: florian.vaussard, Tony Lindgren, device-tree, linux-omap,
linux-arm
On 03/14/2013 04:59 PM, Jon Hunter wrote:
>
> On 03/14/2013 10:45 AM, Florian Vaussard wrote:
>> Hi Benoit,
>>
>> On 03/14/2013 03:57 PM, Benoit Cousson wrote:
>>> Salut Jon,
>>>
>>> On 03/08/2013 06:27 PM, Jon Hunter wrote:
>>>> Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards.
>>>>
>>>> The DMA, PMU and OMAP3430 SDP board changes have been sent before
>>>> individually but re-sending here as a complete series for v3.10.
>>>>
>>>> This is based upon v3.9-rc1 and the OMAP3 GPMC binding from Florian
>>>> Vaussard [1] and OMAP5 DT SPI patch from Felipe Balbi [2].
>>>>
>>>> [1] https://patchwork.kernel.org/patch/2057111/
>>>
>>> I've tried to follow the series review, and it seems that Florian was
>>> considering sending some other patches. It is not clear if this is a new
>>> version of the series or some additional patches.
>
> A bit of both. Sorry for the confusion :-)
>
>> Concerning patch [1], it can be merged to add the GPMC binding for OMAP3.
>> But please discard the rest of my original series, I will repost something
>> later.
>
> Benoit, if you pick up Florian's patch, I will re-post my remaining
> patches for you to pick up.
>
> By the way, I see that you have picked up the PMU bindings, however,
> ideally we should merge the "pmu prepare" patch first. We agreed with
> Tony for you to take this with his ack [1].
OK, no problem, I'll remove it from the for_3.10/dts and get it when
I'll merge your branch.
> Let me know if you just want me to re-post that one on top of your branch.
I guess you will have to repost your branch anyway?
Thanks,
Benoit
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 0/9] ARM: dts: Various OMAP2+ device-tree updates
2013-03-14 14:57 ` [PATCH 0/9] ARM: dts: Various OMAP2+ device-tree updates Benoit Cousson
2013-03-14 15:45 ` Florian Vaussard
@ 2013-03-14 16:02 ` Javier Martinez Canillas
2013-03-14 16:04 ` Jon Hunter
2013-03-14 16:08 ` Benoit Cousson
1 sibling, 2 replies; 37+ messages in thread
From: Javier Martinez Canillas @ 2013-03-14 16:02 UTC (permalink / raw)
To: Benoit Cousson
Cc: Jon Hunter, Tony Lindgren, device-tree, linux-omap, linux-arm
On Thu, Mar 14, 2013 at 3:57 PM, Benoit Cousson <b-cousson@ti.com> wrote:
> Salut Jon,
>
> On 03/08/2013 06:27 PM, Jon Hunter wrote:
>> Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards.
>>
>> The DMA, PMU and OMAP3430 SDP board changes have been sent before
>> individually but re-sending here as a complete series for v3.10.
>>
>> This is based upon v3.9-rc1 and the OMAP3 GPMC binding from Florian
>> Vaussard [1] and OMAP5 DT SPI patch from Felipe Balbi [2].
>>
>> [1] https://patchwork.kernel.org/patch/2057111/
>
> I've tried to follow the series review, and it seems that Florian was
> considering sending some other patches. It is not clear if this is a new
> version of the series or some additional patches.
>
Hi Benoit,
According to [1] Jon suggested that it was not necessary to map all
the 16MB for the GPMC mapped register address space since in practice
is a very small fraction of that size is used.
I had the following patch but I did never post it because Jon said
that the I/O memory mapping is page-aligned and the minimum page
size for ARM is 4KB anyways, so there is no functional difference
between using 0x1000 or 0x02d0.
But now reading [2] I see that you prefer to do what the documentation
said and don't assume any the page size / alignment.
[2]: https://patchwork.kernel.org/patch/2239741/
>From 68edff5a102bb8fc81e006738baa456eb69f080a Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Date: Wed, 27 Feb 2013 02:30:51 +0100
Subject: [PATCH] ARM: dts: OMAP3: reduce GPMC mapped registers address space
Currently the OMAP General-Purpose Memory Controller (GPMC) device
node maps 16 MB of address space for its hardware registers.
This is because the OMAP Technical Reference Manual says that the
GPMC module register address space size is 16 MB. But in practice
the maximum address offset used by a GPMC register is 0x02d0.
So, there is no need to map such a big address space for GPMC regs.
This change was suggested by Jon Hunter [1].
[1]: https://patchwork.kernel.org/patch/2057111/
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
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 2ddae38..a60eaf1 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -407,7 +407,7 @@
gpmc: gpmc@6e000000 {
compatible = "ti,omap3430-gpmc";
ti,hwmods = "gpmc";
- reg = <0x6e000000 0x1000000>;
+ reg = <0x6e000000 0x02d0>;
interrupts = <20>;
gpmc,num-cs = <8>;
gpmc,num-waitpins = <4>;
--
1.7.7.6
^ permalink raw reply related [flat|nested] 37+ messages in thread* Re: [PATCH 0/9] ARM: dts: Various OMAP2+ device-tree updates
2013-03-14 16:02 ` Javier Martinez Canillas
@ 2013-03-14 16:04 ` Jon Hunter
2013-03-14 16:08 ` Benoit Cousson
1 sibling, 0 replies; 37+ messages in thread
From: Jon Hunter @ 2013-03-14 16:04 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Benoit Cousson, Tony Lindgren, device-tree, linux-omap, linux-arm
On 03/14/2013 11:02 AM, Javier Martinez Canillas wrote:
> On Thu, Mar 14, 2013 at 3:57 PM, Benoit Cousson <b-cousson@ti.com> wrote:
>> Salut Jon,
>>
>> On 03/08/2013 06:27 PM, Jon Hunter wrote:
>>> Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards.
>>>
>>> The DMA, PMU and OMAP3430 SDP board changes have been sent before
>>> individually but re-sending here as a complete series for v3.10.
>>>
>>> This is based upon v3.9-rc1 and the OMAP3 GPMC binding from Florian
>>> Vaussard [1] and OMAP5 DT SPI patch from Felipe Balbi [2].
>>>
>>> [1] https://patchwork.kernel.org/patch/2057111/
>>
>> I've tried to follow the series review, and it seems that Florian was
>> considering sending some other patches. It is not clear if this is a new
>> version of the series or some additional patches.
>>
>
> Hi Benoit,
>
> According to [1] Jon suggested that it was not necessary to map all
> the 16MB for the GPMC mapped register address space since in practice
> is a very small fraction of that size is used.
>
> I had the following patch but I did never post it because Jon said
> that the I/O memory mapping is page-aligned and the minimum page
> size for ARM is 4KB anyways, so there is no functional difference
> between using 0x1000 or 0x02d0.
>
> But now reading [2] I see that you prefer to do what the documentation
> said and don't assume any the page size / alignment.
>
> [2]: https://patchwork.kernel.org/patch/2239741/
>
> From 68edff5a102bb8fc81e006738baa456eb69f080a Mon Sep 17 00:00:00 2001
> From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> Date: Wed, 27 Feb 2013 02:30:51 +0100
> Subject: [PATCH] ARM: dts: OMAP3: reduce GPMC mapped registers address space
>
> Currently the OMAP General-Purpose Memory Controller (GPMC) device
> node maps 16 MB of address space for its hardware registers.
>
> This is because the OMAP Technical Reference Manual says that the
> GPMC module register address space size is 16 MB. But in practice
> the maximum address offset used by a GPMC register is 0x02d0.
>
> So, there is no need to map such a big address space for GPMC regs.
>
> This change was suggested by Jon Hunter [1].
>
> [1]: https://patchwork.kernel.org/patch/2057111/
>
> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> ---
> 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 2ddae38..a60eaf1 100644
> --- a/arch/arm/boot/dts/omap3.dtsi
> +++ b/arch/arm/boot/dts/omap3.dtsi
> @@ -407,7 +407,7 @@
> gpmc: gpmc@6e000000 {
> compatible = "ti,omap3430-gpmc";
> ti,hwmods = "gpmc";
> - reg = <0x6e000000 0x1000000>;
> + reg = <0x6e000000 0x02d0>;
> interrupts = <20>;
> gpmc,num-cs = <8>;
> gpmc,num-waitpins = <4>;
>
Thanks!
Acked-by: Jon Hunter <jon-hunter@ti.com>
Cheers
Jon
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: [PATCH 0/9] ARM: dts: Various OMAP2+ device-tree updates
2013-03-14 16:02 ` Javier Martinez Canillas
2013-03-14 16:04 ` Jon Hunter
@ 2013-03-14 16:08 ` Benoit Cousson
1 sibling, 0 replies; 37+ messages in thread
From: Benoit Cousson @ 2013-03-14 16:08 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Jon Hunter, Tony Lindgren, device-tree, linux-omap, linux-arm
Hi Javier,
On 03/14/2013 05:02 PM, Javier Martinez Canillas wrote:
> On Thu, Mar 14, 2013 at 3:57 PM, Benoit Cousson <b-cousson@ti.com> wrote:
>> Salut Jon,
>>
>> On 03/08/2013 06:27 PM, Jon Hunter wrote:
>>> Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards.
>>>
>>> The DMA, PMU and OMAP3430 SDP board changes have been sent before
>>> individually but re-sending here as a complete series for v3.10.
>>>
>>> This is based upon v3.9-rc1 and the OMAP3 GPMC binding from Florian
>>> Vaussard [1] and OMAP5 DT SPI patch from Felipe Balbi [2].
>>>
>>> [1] https://patchwork.kernel.org/patch/2057111/
>>
>> I've tried to follow the series review, and it seems that Florian was
>> considering sending some other patches. It is not clear if this is a new
>> version of the series or some additional patches.
>>
>
> Hi Benoit,
>
> According to [1] Jon suggested that it was not necessary to map all
> the 16MB for the GPMC mapped register address space since in practice
> is a very small fraction of that size is used.
>
> I had the following patch but I did never post it because Jon said
> that the I/O memory mapping is page-aligned and the minimum page
> size for ARM is 4KB anyways, so there is no functional difference
> between using 0x1000 or 0x02d0.
>
> But now reading [2] I see that you prefer to do what the documentation
> said and don't assume any the page size / alignment.
>
> [2]: https://patchwork.kernel.org/patch/2239741/
>
> From 68edff5a102bb8fc81e006738baa456eb69f080a Mon Sep 17 00:00:00 2001
> From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> Date: Wed, 27 Feb 2013 02:30:51 +0100
> Subject: [PATCH] ARM: dts: OMAP3: reduce GPMC mapped registers address space
>
> Currently the OMAP General-Purpose Memory Controller (GPMC) device
> node maps 16 MB of address space for its hardware registers.
>
> This is because the OMAP Technical Reference Manual says that the
> GPMC module register address space size is 16 MB. But in practice
> the maximum address offset used by a GPMC register is 0x02d0.
>
> So, there is no need to map such a big address space for GPMC regs.
>
> This change was suggested by Jon Hunter [1].
>
> [1]: https://patchwork.kernel.org/patch/2057111/
>
> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Thanks for that super fast patch :-)
Applied.
Regards,
Benoit
> ---
> 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 2ddae38..a60eaf1 100644
> --- a/arch/arm/boot/dts/omap3.dtsi
> +++ b/arch/arm/boot/dts/omap3.dtsi
> @@ -407,7 +407,7 @@
> gpmc: gpmc@6e000000 {
> compatible = "ti,omap3430-gpmc";
> ti,hwmods = "gpmc";
> - reg = <0x6e000000 0x1000000>;
> + reg = <0x6e000000 0x02d0>;
> interrupts = <20>;
> gpmc,num-cs = <8>;
> gpmc,num-waitpins = <4>;
>
^ permalink raw reply [flat|nested] 37+ messages in thread