ARM: OMAP2+: AM43x initial support

AM43x timer bindings.

Signed-off-by Afzal Mohammed <[email protected]>

---
 Documentation/devicetree/bindings/arm/omap/timer.txt | 2 ++
 1 file changed, 2 insertions(+)

Documentation/devicetree/bindings/arm/omap/timer.txt +0 -0

index d02e27c..70cb398 100644

AM43x 32K counter binding.

Signed-off-by Afzal Mohammed <[email protected]>

---
 Documentation/devicetree/bindings/arm/omap/counter.txt | 1 +
 1 file changed, 1 insertion(+)

Documentation/devicetree/bindings/arm/omap/counter.txt +0 -0

index 5bd8aa0..9c48dca 100644

Quoted 18 lines · Afzal Mohammed

AM43x timer bindings.

Signed-off-by Afzal Mohammed <[email protected]>

---
 Documentation/devicetree/bindings/arm/omap/timer.txt | 2 ++
 1 file changed, 2 insertions(+)

Documentation/devicetree/bindings/arm/omap/timer.txt +2 -0

index d02e27c..70cb398 100644
@@ -14,6 +14,8 @@ Required properties:
 			ti,omap5430-timer (applicable to OMAP543x devices)
 			ti,am335x-timer	(applicable to AM335x devices)
 			ti,am335x-timer-1ms (applicable to AM335x devices)
+			"ti,am4372-timer-1ms", "ti,am335x-timer-1ms" for AM43x 1ms timer
+			"ti,am4372-timer", "ti,am335x-timer" for AM43x timers other than 1ms one
 

Documentation/devicetree/bindings/arm/omap/timer.txt Required properties: · line 21

Quoted 2 lines

Documentation/devicetree/bindings/arm/omap/timer.txt +0 -0

 - reg:			Contains timer register address range (base address and
 			length).

If you are adding more compatibility strings, then this implies that the AM43x timers are not 100% compatible with any other device listed (such as am335x or any omap device). That's fine but you should state that in the changelog. If the AM43x timer registers are 100% compatible with existing devices you should not add these.

Quoted 10 lines · Jon Hunter

Documentation/devicetree/bindings/arm/omap/timer.txt Required properties: · line 18

Quoted 4 lines

Documentation/devicetree/bindings/arm/omap/timer.txt +2 -0

 			ti,am335x-timer	(applicable to AM335x devices)
 			ti,am335x-timer-1ms (applicable to AM335x devices)
+			"ti,am4372-timer-1ms", "ti,am335x-timer-1ms" for AM43x 1ms timer
+			"ti,am4372-timer", "ti,am335x-timer" for AM43x timers other than 1ms one

If you are adding more compatibility strings, then this implies that the AM43x timers are not 100% compatible with any other device listed (such as am335x or any omap device). That's fine but you should state that in the changelog. If the AM43x timer registers are 100% compatible with existing devices you should not add these.

I'm not sure that's true; .dts files should always include a compatible value that describes the most specific model of the HW, plus any baseline compatible value that the HW is compatible with. This allows any required quirks/fixes/... to be applied for the specific HW model later even if nobody knows right now they'll be needed. Hence, defining new compatible values doesn't necessarily mean incompatible HW.

Changelog should state why this is needed.

Hi Jon,

Quoted 13 lines · Stephen Warren

Quoted 10 lines · Jon Hunter

Documentation/devicetree/bindings/arm/omap/timer.txt Required properties: · line 18

Quoted 4 lines

Documentation/devicetree/bindings/arm/omap/timer.txt +2 -0

 			ti,am335x-timer	(applicable to AM335x devices)
 			ti,am335x-timer-1ms (applicable to AM335x devices)
+			"ti,am4372-timer-1ms", "ti,am335x-timer-1ms" for AM43x 1ms timer
+			"ti,am4372-timer", "ti,am335x-timer" for AM43x timers other than 1ms one

If you are adding more compatibility strings, then this implies that the AM43x timers are not 100% compatible with any other device listed (such as am335x or any omap device). That's fine but you should state that in the changelog. If the AM43x timer registers are 100% compatible with existing devices you should not add these.

Quoted 6 lines

I'm not sure that's true; .dts files should always include a compatible value that describes the most specific model of the HW, plus any baseline compatible value that the HW is compatible with. This allows any required quirks/fixes/... to be applied for the specific HW model later even if nobody knows right now they'll be needed. Hence, defining new compatible values doesn't necessarily mean incompatible HW.

Stephen took words out of my finger ;)

Some explanations,I don;t

1. first compatible should be exact device [A], followed by compatible model (if one)
2. Minor effort in getting DT right the first time may help prevent difficult effort later modifying it (if a necessity comes), considering the fact that DT sources has to move out of Kernel at some point of time. And DT is not supposed to be modified, which may cause difficulty for the users (I had been a minor victim of this during rebase).

As we both were in GPMC land earlier, an example,

If my memory is right, GPMC IP in am335x is rev 6, and IP has 8 chip select, but one is not pinned out. Now assume that same IP is integrated in another SoC (probably OMAP4 has rev 6). Here if we use same compatible for both, driver cannot handle it properly (w/o knowledge about platform). But if exact compatible is mentioned, without modifying DT (which should be considered as a firmware) just by modifying Kernel, deciding based on compatible would help achieve what is required.

DT source (minimal) for AM4372 SoC to represent AM43x SoC's. Those represented here are the minimal DT nodes necessary to get kernel booting.

In DT nodes, "ti,hwmod" property has not been added, this would be added along with PRCM support for AM43x.

Signed-off-by Ankur Kishore <[email protected]>

Signed-off-by Afzal Mohammed <[email protected]>

---

v2: Add gptimer 1ms, timer2, synctimer and remove twd local timer

 arch/arm/boot/dts/am4372.dtsi | 66 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 66 insertions(+)
 create mode 100644 arch/arm/boot/dts/am4372.dtsi

arch/arm/boot/dts/am4372.dtsi new file +1 -0

new file mode 100644
index 0000000..1d58298
@@ -0,0 +1,66 @@
+/*

arch/arm/boot/dts/am4372.dtsi new file +55 -0

+
+/ {
+	compatible = "ti,am4372", "ti,am43";
+	interrupt-parent = <&gic>;
+
+
+	aliases {
+		serial0 = &uart1;
+	};
+
+	cpus {
+		cpu at 0 {
+			compatible = "arm,cortex-a9";
+		};
+	};
+
+	gic: interrupt-controller at 48241000 {
+		compatible = "arm,cortex-a9-gic";
+		interrupt-controller;
+		#interrupt-cells = <3>;
+		reg = <0x48241000 0x1000>,
+		      <0x48240100 0x0100>;
+	};
+
+	ocp {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		uart1: serial at 44e09000 {
+			compatible = "ti,am4372-uart","ti,omap2-uart";
+			reg = <0x44e09000 0x2000>;
+			interrupts = <0 72 0x4>;
+		};
+
+		timer1: timer at 44e31000 {
+			compatible = "ti,am4372-timer-1ms","ti,am335x-timer-1ms";
+			reg = <0x44e31000 0x400>;
+			interrupts = <0 67 0x4>;
+			ti,timer-alwon;
+		};
+
+		timer2: timer at 48040000  {
+			compatible = "ti,am4372-timer","ti,am335x-timer";
+			reg = <0x48040000  0x400>;
+			interrupts = <0 68 0x4>;
+		};
+
+		counter32k: counter at 44e86000 {
+			compatible = "ti,am4372-counter32k","ti,omap-counter32k";
+			reg = <0x44e86000 0x40>;
+		};
+	};
+};

+ Florian

Hi Afzal,

Quoted 24 lines · Afzal Mohammed

DT source (minimal) for AM4372 SoC to represent AM43x SoC's. Those represented here are the minimal DT nodes necessary to get kernel booting.

In DT nodes, "ti,hwmod" property has not been added, this would be added along with PRCM support for AM43x.

Signed-off-by Ankur Kishore <[email protected]>

Signed-off-by Afzal Mohammed <[email protected]>

---

v2: Add gptimer 1ms, timer2, synctimer and remove twd local timer

  arch/arm/boot/dts/am4372.dtsi | 66 +++++++++++++++++++++++++++++++++++++++++++
  1 file changed, 66 insertions(+)

create mode 100644 arch/arm/boot/dts/am4372.dtsi

arch/arm/boot/dts/am4372.dtsi new file +1 -0

new file mode 100644
index 0000000..1d58298
@@ -0,0 +1,66 @@
+/*

arch/arm/boot/dts/am4372.dtsi line 11

Quoted 10 lines

arch/arm/boot/dts/am4372.dtsi new file +10 -0

+ * Device Tree Source for AM4372 SoC
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/include/ "skeleton.dtsi"

You can now use the C preprocessor statement instead of this one. Florian already started doing the change [1].

Beside that detail, that patch looks good to me.
I'll pull it separately of the series.

Regards,
Benoit

[1] http://thread.gmane.org/gmane.linux.ports.arm.omap/98320

Quoted 56 lines

arch/arm/boot/dts/am4372.dtsi new file +55 -0

+
+/ {
+	compatible = "ti,am4372", "ti,am43";
+	interrupt-parent = <&gic>;
+
+
+	aliases {
+		serial0 = &uart1;
+	};
+
+	cpus {
+		cpu at 0 {
+			compatible = "arm,cortex-a9";
+		};
+	};
+
+	gic: interrupt-controller at 48241000 {
+		compatible = "arm,cortex-a9-gic";
+		interrupt-controller;
+		#interrupt-cells = <3>;
+		reg = <0x48241000 0x1000>,
+		      <0x48240100 0x0100>;
+	};
+
+	ocp {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		uart1: serial at 44e09000 {
+			compatible = "ti,am4372-uart","ti,omap2-uart";
+			reg = <0x44e09000 0x2000>;
+			interrupts = <0 72 0x4>;
+		};
+
+		timer1: timer at 44e31000 {
+			compatible = "ti,am4372-timer-1ms","ti,am335x-timer-1ms";
+			reg = <0x44e31000 0x400>;
+			interrupts = <0 67 0x4>;
+			ti,timer-alwon;
+		};
+
+		timer2: timer at 48040000  {
+			compatible = "ti,am4372-timer","ti,am335x-timer";
+			reg = <0x48040000  0x400>;
+			interrupts = <0 68 0x4>;
+		};
+
+		counter32k: counter at 44e86000 {
+			compatible = "ti,am4372-counter32k","ti,omap-counter32k";
+			reg = <0x44e86000 0x40>;
+		};
+	};
+};

Hello,

Quoted 48 lines · Benoit Cousson

+ Florian

Hi Afzal,

Quoted 37 lines · Afzal Mohammed

DT source (minimal) for AM4372 SoC to represent AM43x SoC's. Those represented here are the minimal DT nodes necessary to get kernel booting.

In DT nodes, "ti,hwmod" property has not been added, this would be added along with PRCM support for AM43x.

Signed-off-by Ankur Kishore <[email protected]>

Signed-off-by Afzal Mohammed <[email protected]>

---

v2: Add gptimer 1ms, timer2, synctimer and remove twd local timer

  arch/arm/boot/dts/am4372.dtsi | 66
+++++++++++++++++++++++++++++++++++++++++++
  1 file changed, 66 insertions(+)

create mode 100644 arch/arm/boot/dts/am4372.dtsi

arch/arm/boot/dts/am4372.dtsi new file +4 -0

new file mode 100644
index 0000000..1d58298
@@ -0,0 +1,66 @@
+/*
+ * Device Tree Source for AM4372 SoC
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated -

http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */

arch/arm/boot/dts/am4372.dtsi line 11

Quoted 2 lines

arch/arm/boot/dts/am4372.dtsi new file +2 -0

+
+/include/ "skeleton.dtsi"

You can now use the C preprocessor statement instead of this one. Florian already started doing the change [1].

Quoted 3 lines

Beside that detail, that patch looks good to me.
I'll pull it separately of the series.

If you pull the patch in your branch, I can take care of the changes when I rebase
my series. This will allow me to clean the 'interrupts' statements below as well.

Regards,

Florian

Quoted 62 lines

Regards,
Benoit

[1] http://thread.gmane.org/gmane.linux.ports.arm.omap/98320

Quoted 56 lines

arch/arm/boot/dts/am4372.dtsi new file +55 -0

+
+/ {
+    compatible = "ti,am4372", "ti,am43";
+    interrupt-parent = <&gic>;
+
+
+    aliases {
+        serial0 = &uart1;
+    };
+
+    cpus {
+        cpu at 0 {
+            compatible = "arm,cortex-a9";
+        };
+    };
+
+    gic: interrupt-controller at 48241000 {
+        compatible = "arm,cortex-a9-gic";
+        interrupt-controller;
+        #interrupt-cells = <3>;
+        reg = <0x48241000 0x1000>,
+              <0x48240100 0x0100>;
+    };
+
+    ocp {
+        compatible = "simple-bus";
+        #address-cells = <1>;
+        #size-cells = <1>;
+        ranges;
+
+        uart1: serial at 44e09000 {
+            compatible = "ti,am4372-uart","ti,omap2-uart";
+            reg = <0x44e09000 0x2000>;
+            interrupts = <0 72 0x4>;
+        };
+
+        timer1: timer at 44e31000 {
+            compatible = "ti,am4372-timer-1ms","ti,am335x-timer-1ms";
+            reg = <0x44e31000 0x400>;
+            interrupts = <0 67 0x4>;
+            ti,timer-alwon;
+        };
+
+        timer2: timer at 48040000  {
+            compatible = "ti,am4372-timer","ti,am335x-timer";
+            reg = <0x48040000  0x400>;
+            interrupts = <0 68 0x4>;
+        };
+
+        counter32k: counter at 44e86000 {
+            compatible = "ti,am4372-counter32k","ti,omap-counter32k";
+            reg = <0x44e86000 0x40>;
+        };
+    };
+};

Quoted 30 lines · Afzal

Quoted 8 lines · Stephen Warren

Quoted 5 lines · Jon Hunter

If you are adding more compatibility strings, then this implies that the AM43x timers are not 100% compatible with any other device listed (such as am335x or any omap device). That's fine but you should state that in the changelog. If the AM43x timer registers are 100% compatible with existing devices you should not add these.

Quoted 6 lines

I'm not sure that's true; .dts files should always include a compatible value that describes the most specific model of the HW, plus any baseline compatible value that the HW is compatible with. This allows any required quirks/fixes/... to be applied for the specific HW model later even if nobody knows right now they'll be needed. Hence, defining new compatible values doesn't necessarily mean incompatible HW.

Stephen took words out of my finger ;)

Some explanations,I don;t

1. first compatible should be exact device [A], followed by compatible model (if one)
2. Minor effort in getting DT right the first time may help prevent difficult effort later modifying it (if a necessity comes), considering the fact that DT sources has to move out of Kernel at some point of time. And DT is not supposed to be modified, which may cause difficulty for the users (I had been a minor victim of this during rebase).

As we both were in GPMC land earlier, an example,

Quoted 7 lines

If my memory is right, GPMC IP in am335x is rev 6, and IP has 8 chip select, but one is not pinned out. Now assume that same IP is integrated in another SoC (probably OMAP4 has rev 6). Here if we use same compatible for both, driver cannot handle it properly (w/o knowledge about platform). But if exact compatible is mentioned, without modifying DT (which should be considered as a firmware) just by modifying Kernel, deciding based on compatible would help achieve what is required.

That's true for the DTS itself, but here your are changing the binding documentation which is supposed to reflect the driver "interface" in the Device Tree model description.

Since the driver does not support any new compatible string, you should not update the binding.

The driver and the binding will have to be changed the day you will have to update the driver to handle a bug / feature specific to that revision (ti,am4372-timer).

Since this series does not seems to update the driver, you should not update the bindings.

Hi Benoit,

Quoted 43 lines · Benoit

Quoted 30 lines · Afzal

Quoted 8 lines · Stephen Warren

Quoted 5 lines · Jon Hunter

If you are adding more compatibility strings, then this implies that the AM43x timers are not 100% compatible with any other device listed (such as am335x or any omap device). That's fine but you should state that in the changelog. If the AM43x timer registers are 100% compatible with existing devices you should not add these.

Quoted 6 lines

I'm not sure that's true; .dts files should always include a compatible value that describes the most specific model of the HW, plus any baseline compatible value that the HW is compatible with. This allows any required quirks/fixes/... to be applied for the specific HW model later even if nobody knows right now they'll be needed. Hence, defining new compatible values doesn't necessarily mean incompatible HW.

Stephen took words out of my finger ;)

Some explanations,I don;t

1. first compatible should be exact device [A], followed by compatible model (if one)
2. Minor effort in getting DT right the first time may help prevent difficult effort later modifying it (if a necessity comes), considering the fact that DT sources has to move out of Kernel at some point of time. And DT is not supposed to be modified, which may cause difficulty for the users (I had been a minor victim of this during rebase).

As we both were in GPMC land earlier, an example,

Quoted 7 lines

If my memory is right, GPMC IP in am335x is rev 6, and IP has 8 chip select, but one is not pinned out. Now assume that same IP is integrated in another SoC (probably OMAP4 has rev 6). Here if we use same compatible for both, driver cannot handle it properly (w/o knowledge about platform). But if exact compatible is mentioned, without modifying DT (which should be considered as a firmware) just by modifying Kernel, deciding based on compatible would help achieve what is required.

That's true for the DTS itself, but here your are changing the binding documentation which is supposed to reflect the driver "interface" in the Device Tree model description.

Quoted 2 lines

Since the driver does not support any new compatible string, you should not update the binding.

I have a different opinion: Binding documentation is to be considered an entity that is not a part of the Kernel, but currently is a part of the Kernel for want of a better place. And binding is to be considered OS agnostic being ignorant of any piece of software (driver here).

Binding has the authority to allow its usage in DT sources.

Quoted 6 lines

The driver and the binding will have to be changed the day you will have to update the driver to handle a bug / feature specific to that revision (ti,am4372-timer).

Since this series does not seems to update the driver, you should not update the bindings.

I believe that updating binding is a prerequisite for making a new DTS change, hence binding was updated first, then DTS.

Hi Afzal,

Quoted 37 lines · Afzal

Hi Jon,

Quoted 13 lines · Stephen Warren

Quoted 10 lines · Jon Hunter

Documentation/devicetree/bindings/arm/omap/timer.txt Required properties: · line 18

Quoted 4 lines

Documentation/devicetree/bindings/arm/omap/timer.txt +2 -0

 			ti,am335x-timer	(applicable to AM335x devices)
 			ti,am335x-timer-1ms (applicable to AM335x devices)
+			"ti,am4372-timer-1ms", "ti,am335x-timer-1ms" for AM43x 1ms timer
+			"ti,am4372-timer", "ti,am335x-timer" for AM43x timers other than 1ms one

If you are adding more compatibility strings, then this implies that the AM43x timers are not 100% compatible with any other device listed (such as am335x or any omap device). That's fine but you should state that in the changelog. If the AM43x timer registers are 100% compatible with existing devices you should not add these.

Quoted 6 lines

I'm not sure that's true; .dts files should always include a compatible value that describes the most specific model of the HW, plus any baseline compatible value that the HW is compatible with. This allows any required quirks/fixes/... to be applied for the specific HW model later even if nobody knows right now they'll be needed. Hence, defining new compatible values doesn't necessarily mean incompatible HW.

Stephen took words out of my finger ;)

Some explanations,I don;t

1. first compatible should be exact device [A], followed by compatible model (if one)
2. Minor effort in getting DT right the first time may help prevent difficult effort later modifying it (if a necessity comes), considering the fact that DT sources has to move out of Kernel at some point of time. And DT is not supposed to be modified, which may cause difficulty for the users (I had been a minor victim of this during rebase).

As we both were in GPMC land earlier, an example,

Quoted 7 lines

If my memory is right, GPMC IP in am335x is rev 6, and IP has 8 chip select, but one is not pinned out. Now assume that same IP is integrated in another SoC (probably OMAP4 has rev 6). Here if we use same compatible for both, driver cannot handle it properly (w/o knowledge about platform). But if exact compatible is mentioned, without modifying DT (which should be considered as a firmware) just by modifying Kernel, deciding based on compatible would help achieve what is required.

That's true for the DTS itself, but here your are changing the binding documentation which is supposed to reflect the driver "interface" in the Device Tree model description.

Since the driver does not support any new compatible string, you should not update the binding.

Quoted 20 lines · Jon Hunter

Quoted 18 lines · Afzal Mohammed

AM43x timer bindings.

Signed-off-by Afzal Mohammed <[email protected]>

---
 Documentation/devicetree/bindings/arm/omap/timer.txt | 2 ++
 1 file changed, 2 insertions(+)

Documentation/devicetree/bindings/arm/omap/timer.txt +2 -0

index d02e27c..70cb398 100644
@@ -14,6 +14,8 @@ Required properties:
 			ti,omap5430-timer (applicable to OMAP543x devices)
 			ti,am335x-timer	(applicable to AM335x devices)
 			ti,am335x-timer-1ms (applicable to AM335x devices)
+			"ti,am4372-timer-1ms", "ti,am335x-timer-1ms" for AM43x 1ms timer
+			"ti,am4372-timer", "ti,am335x-timer" for AM43x timers other than 1ms one
 

Quoted 8 lines

Documentation/devicetree/bindings/arm/omap/timer.txt Required properties: · line 21

Quoted 2 lines

Documentation/devicetree/bindings/arm/omap/timer.txt +0 -0

 - reg:			Contains timer register address range (base address and
 			length).

If you are adding more compatibility strings, then this implies that the AM43x timers are not 100% compatible with any other device listed (such as am335x or any omap device). That's fine but you should state that in the changelog. If the AM43x timer registers are 100% compatible with existing devices you should not add these.

I'm not sure that's true; .dts files should always include a compatible value that describes the most specific model of the HW, plus any baseline compatible value that the HW is compatible with. This allows any required quirks/fixes/... to be applied for the specific HW model later even if nobody knows right now they'll be needed. Hence, defining new compatible values doesn't necessarily mean incompatible HW.

Quoted 52 lines · Benoit Cousson

Hi Afzal,

Quoted 37 lines · Afzal

Hi Jon,

Quoted 13 lines · Stephen Warren

Quoted 10 lines · Jon Hunter

Documentation/devicetree/bindings/arm/omap/timer.txt Required properties: · line 18

Quoted 4 lines

Documentation/devicetree/bindings/arm/omap/timer.txt +2 -0

 			ti,am335x-timer	(applicable to AM335x devices)
 			ti,am335x-timer-1ms (applicable to AM335x devices)
+			"ti,am4372-timer-1ms", "ti,am335x-timer-1ms" for AM43x 1ms timer
+			"ti,am4372-timer", "ti,am335x-timer" for AM43x timers other than 1ms one

If you are adding more compatibility strings, then this implies that the AM43x timers are not 100% compatible with any other device listed (such as am335x or any omap device). That's fine but you should state that in the changelog. If the AM43x timer registers are 100% compatible with existing devices you should not add these.

Quoted 6 lines

I'm not sure that's true; .dts files should always include a compatible value that describes the most specific model of the HW, plus any baseline compatible value that the HW is compatible with. This allows any required quirks/fixes/... to be applied for the specific HW model later even if nobody knows right now they'll be needed. Hence, defining new compatible values doesn't necessarily mean incompatible HW.

Stephen took words out of my finger ;)

Some explanations,I don;t

1. first compatible should be exact device [A], followed by compatible model (if one)
2. Minor effort in getting DT right the first time may help prevent difficult effort later modifying it (if a necessity comes), considering the fact that DT sources has to move out of Kernel at some point of time. And DT is not supposed to be modified, which may cause difficulty for the users (I had been a minor victim of this during rebase).

As we both were in GPMC land earlier, an example,

Quoted 7 lines

If my memory is right, GPMC IP in am335x is rev 6, and IP has 8 chip select, but one is not pinned out. Now assume that same IP is integrated in another SoC (probably OMAP4 has rev 6). Here if we use same compatible for both, driver cannot handle it properly (w/o knowledge about platform). But if exact compatible is mentioned, without modifying DT (which should be considered as a firmware) just by modifying Kernel, deciding based on compatible would help achieve what is required.

That's true for the DTS itself, but here your are changing the binding documentation which is supposed to reflect the driver "interface" in the Device Tree model description.

Quoted 2 lines

Since the driver does not support any new compatible string, you should not update the binding.

I don't agree here; the DT binding should define all the required and/or allowed values that must/should/can be present in the DT - the entire legal schema. The set of all compatible values is included in that, irrespective of whether a particular value actually (currently) defines a different HW interface or not.

And in this case, you do not introduce any new revision.

There is no point to update the binding each time we add a new SoC variant that will contain the exact same IP.

I think it will mainly confuse the user that will wonder what is different in that version compare to the previous one, moreover we can end up with hundred of entries for the exact same IP for nothing.

The real problem is due to the introduction of the SoC name in the device compatible name. That does introduced a SoC level information that is mostly irrelevant at device level. I can understand why it was done for practical aspect when the IP version is not well identified, but that can lead to this proliferation of new pointless bindings.

Hi Benoit,

Quoted 9 lines · Benoit

And in this case, you do not introduce any new revision.

There is no point to update the binding each time we add a new SoC variant that will contain the exact same IP.

I think it will mainly confuse the user that will wonder what is different in that version compare to the previous one, moreover we can end up with hundred of entries for the exact same IP for nothing.

Quoted 5 lines

The real problem is due to the introduction of the SoC name in the device compatible name. That does introduced a SoC level information that is mostly irrelevant at device level. I can understand why it was done for practical aspect when the IP version is not well identified, but that can lead to this proliferation of new pointless bindings.

As opinions on $subject seems not yet to be conclusive, I plan to rebase DTS patch (14/14) over your 'for_3.11/dts' branch (that makes use of C preprocessor on OMAP DTS) and post separately dropping 11-14 patches, is that okay ?

This series adds initial support for AM43x based SoC's. To boot AM43x, in addition to these patches, PRCM support is also needed, which would be posted later as a separate series. DT sources doesn't have "ti,hwmod" entry - this would be added along with PRCM support.

AM43x SoC's are based on ARM Cortex-A9 with one core. AM43x is similar to AM335x in it's peripheral capabilities, except a few additional ones, with many of the peripheral register mapping's similar. AM43x has a sync timer, which is being used as clocksource. Clockevent used is 1ms dmtimer.

SoC has PL310 L2 cache, support for it would be added later.

soc_is_am43xx() is introduced to handle AM43x specific details and soc_is_am437x() is a subclass of it - first member of the class.

AM43x is currently in pre-silicon stage and currently there are no public documents.

This has been tested on a pre-silicon platform that emulates AM43x SoC with additional changes on top of this.

AM335x based board (AM335x EVM) has been verfied to boot as earlier with this series.

Baseline: v3.10-rc3
Dependency: "ARM: OMAP3+: am33xx id: Add new am33xx specific function to check dev_feature"
by Vaibhav Hiremath <[email protected]>

arch/arm/mach-omap2/Kconfig +2 -0

@@ -149,6 +149,16 @@ config SOC_AM33XX
 	select MULTI_IRQ_HANDLER
 	select COMMON_CLK
 
+config SOC_AM43XX
+	bool "TI AM43x"

arch/arm/mach-omap2/io.c +7 -0

@@ -586,6 +586,20 @@ void __init am33xx_init_early(void)
 }
 #endif
 
+#ifdef CONFIG_SOC_AM43XX
+void __init am43xx_init_early(void)
+{
+	omap2_set_globals_tap(AM335X_CLASS,
+			      AM33XX_L4_WK_IO_ADDRESS(AM33XX_TAP_BASE));
+	omap2_set_globals_control(AM33XX_L4_WK_IO_ADDRESS(AM33XX_CTRL_BASE),
+				  NULL);

I've updated this patch to remove the "default y" and "depends on ARCH_OMAP2PLUS" entries for the usual reasons and applied the first ten patches into omap-for-v3.11/soc.

Hi Tony,

Quoted 3 lines · Tony Lindgren

I've updated this patch to remove the "default y" and "depends on ARCH_OMAP2PLUS" entries for the usual reasons and applied the first ten patches into omap-for-v3.11/soc.

Thanks.

Patch 10 "ARM: OMAP2+: AM43x: basic dt support" is missing in omap-for-v3.11/soc branch and omap soc pull request, can you please help patch 10 also to go upstream.

Quoted 3 lines · Mohammed, Afzal

Patch 10 "ARM: OMAP2+: AM43x: basic dt support" is missing in omap-for-v3.11/soc branch and omap soc pull request, can you please help patch 10 also to go upstream.

Hmm if that's .dts changes, Benoit needs to queue that.

Hi Tony,

Quoted 6 lines · Tony Lindgren

Quoted 3 lines · Mohammed, Afzal

Patch 10 "ARM: OMAP2+: AM43x: basic dt support" is missing in omap-for-v3.11/soc branch and omap soc pull request, can you please help patch 10 also to go upstream.

Quoted 1 line

Hmm if that's .dts changes, Benoit needs to queue that.

It is not dts change.

Patch 10 patches board-generic.c for DT boot (Benoit has already picked up dts, that is patch 14).