BCM2836 (Raspberry Pi 2) port

BCM2836 (Raspberry Pi 2) port

[Eric Anholt]

This is my first submission of a Raspberry Pi 2 port.  It can be found
at https://github.com/anholt/linux/tree/bcm2836

I'm using the 2835 interrupt controller support, without adding the
checks for ARM local interrupts first.  That means no support for IPIs
(and thus no SMP), no PMU events, and no local timer (I'm using the
same 2835 peripheral one).

It supports a similar featureset to Pi 1 at this point.  Serial and SD
cards work.  Just one CPU supported.  USB (ethernet) works if you use
U-Boot, or my mailbox series
(https://github.com/anholt/linux/tree/bcm2836-mbox).

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

BCM2836 (Raspberry Pi 2) port

[Eric Anholt]

This is my first submission of a Raspberry Pi 2 port.  It can be found
at https://github.com/anholt/linux/tree/bcm2836

I'm using the 2835 interrupt controller support, without adding the
checks for ARM local interrupts first.  That means no support for IPIs
(and thus no SMP), no PMU events, and no local timer (I'm using the
same 2835 peripheral one).

It supports a similar featureset to Pi 1 at this point.  Serial and SD
cards work.  Just one CPU supported.  USB (ethernet) works if you use
U-Boot, or my mailbox series
(https://github.com/anholt/linux/tree/bcm2836-mbox).

[PATCH 1/9] dt-bindings: Add root properties for Raspberry Pi 2.

[Eric Anholt]

Signed-off-by: Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
---
 Documentation/devicetree/bindings/arm/bcm2836.txt | 10 ++++++++++
 1 file changed, 10 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/bcm2836.txt

diff --git a/Documentation/devicetree/bindings/arm/bcm2836.txt b/Documentation/devicetree/bindings/arm/bcm2836.txt
new file mode 100644
index 0000000..5e255ec
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/bcm2836.txt
@@ -0,0 +1,10 @@
+Broadcom BCM2836 device tree bindings
+-------------------------------------------
+
+Raspberry Pi 2 Model B
+Required root node properties:
+compatible = "raspberrypi,2-model-b", "brcm,bcm2836";
+
+Generic BCM2836 board
+Required root node properties:
+compatible = "brcm,bcm2836";
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/9] dt-bindings: Add root properties for Raspberry Pi 2.

[Eric Anholt]

Signed-off-by: Eric Anholt <eric@anholt.net>
---
 Documentation/devicetree/bindings/arm/bcm2836.txt | 10 ++++++++++
 1 file changed, 10 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/bcm2836.txt

diff --git a/Documentation/devicetree/bindings/arm/bcm2836.txt b/Documentation/devicetree/bindings/arm/bcm2836.txt
new file mode 100644
index 0000000..5e255ec
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/bcm2836.txt
@@ -0,0 +1,10 @@
+Broadcom BCM2836 device tree bindings
+-------------------------------------------
+
+Raspberry Pi 2 Model B
+Required root node properties:
+compatible = "raspberrypi,2-model-b", "brcm,bcm2836";
+
+Generic BCM2836 board
+Required root node properties:
+compatible = "brcm,bcm2836";
-- 
2.1.4

Re: [PATCH 1/9] dt-bindings: Add root properties for Raspberry Pi 2.

[Stephen Warren]

On 04/21/2015 12:09 PM, Eric Anholt wrote:
> Signed-off-by: Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
> ---
>  Documentation/devicetree/bindings/arm/bcm2836.txt | 10 ++++++++++

In next-20150423 at least, the bcm2835 equivalent of this file is:
Documentation/devicetree/bindings/arm/bcm/brcm,bcm2835.txt

The file added by this patch should be named consistently. I might be
tempted to put the new values into the existing file?
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/9] dt-bindings: Add root properties for Raspberry Pi 2.

[Stephen Warren]

On 04/21/2015 12:09 PM, Eric Anholt wrote:
> Signed-off-by: Eric Anholt <eric@anholt.net>
> ---
>  Documentation/devicetree/bindings/arm/bcm2836.txt | 10 ++++++++++

In next-20150423 at least, the bcm2835 equivalent of this file is:
Documentation/devicetree/bindings/arm/bcm/brcm,bcm2835.txt

The file added by this patch should be named consistently. I might be
tempted to put the new values into the existing file?

[PATCH 2/9] ARM: BCM2835: Split peripheral definitions off to a common include.

[Eric Anholt]

The 2836 dts will inherit all of this, because it shares the same
peripherals as 2835.

Signed-off-by: Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
---
 arch/arm/boot/dts/bcm2835.dtsi        | 155 +--------------------------------
 arch/arm/boot/dts/bcm283x-common.dtsi | 159 ++++++++++++++++++++++++++++++++++
 2 files changed, 160 insertions(+), 154 deletions(-)
 create mode 100644 arch/arm/boot/dts/bcm283x-common.dtsi

diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
index 4d4c129..bdf9993 100644
--- a/arch/arm/boot/dts/bcm2835.dtsi
+++ b/arch/arm/boot/dts/bcm2835.dtsi
@@ -1,5 +1,6 @@
 #include <dt-bindings/pinctrl/bcm2835.h>
 #include "skeleton.dtsi"
+#include "bcm283x-common.dtsi"
 
 / {
 	compatible = "brcm,bcm2835";
@@ -23,162 +24,8 @@
 			clock-frequency = <1000000>;
 		};
 
-		dma: dma@7e007000 {
-			compatible = "brcm,bcm2835-dma";
-			reg = <0x7e007000 0xf00>;
-			interrupts = <1 16>,
-				     <1 17>,
-				     <1 18>,
-				     <1 19>,
-				     <1 20>,
-				     <1 21>,
-				     <1 22>,
-				     <1 23>,
-				     <1 24>,
-				     <1 25>,
-				     <1 26>,
-				     <1 27>,
-				     <1 28>;
-
-			#dma-cells = <1>;
-			brcm,dma-channel-mask = <0x7f35>;
-		};
-
-		intc: interrupt-controller@7e00b200 {
-			compatible = "brcm,bcm2835-armctrl-ic";
-			reg = <0x7e00b200 0x200>;
-			interrupt-controller;
-			#interrupt-cells = <2>;
-		};
-
-		watchdog@7e100000 {
-			compatible = "brcm,bcm2835-pm-wdt";
-			reg = <0x7e100000 0x28>;
-		};
-
-		rng@7e104000 {
-			compatible = "brcm,bcm2835-rng";
-			reg = <0x7e104000 0x10>;
-		};
-
-		gpio: gpio@7e200000 {
-			compatible = "brcm,bcm2835-gpio";
-			reg = <0x7e200000 0xb4>;
-			/*
-			 * The GPIO IP block is designed for 3 banks of GPIOs.
-			 * Each bank has a GPIO interrupt for itself.
-			 * There is an overall "any bank" interrupt.
-			 * In order, these are GIC interrupts 17, 18, 19, 20.
-			 * Since the BCM2835 only has 2 banks, the 2nd bank
-			 * interrupt output appears to be mirrored onto the
-			 * 3rd bank's interrupt signal.
-			 * So, a bank0 interrupt shows up on 17, 20, and
-			 * a bank1 interrupt shows up on 18, 19, 20!
-			 */
-			interrupts = <2 17>, <2 18>, <2 19>, <2 20>;
-
-			gpio-controller;
-			#gpio-cells = <2>;
-
-			interrupt-controller;
-			#interrupt-cells = <2>;
-		};
-
-		uart@7e201000 {
-			compatible = "brcm,bcm2835-pl011", "arm,pl011", "arm,primecell";
-			reg = <0x7e201000 0x1000>;
-			interrupts = <2 25>;
-			clock-frequency = <3000000>;
-			arm,primecell-periphid = <0x00241011>;
-		};
-
-		i2s: i2s@7e203000 {
-			compatible = "brcm,bcm2835-i2s";
-			reg = <0x7e203000 0x20>,
-			      <0x7e101098 0x02>;
-
-			dmas = <&dma 2>,
-			       <&dma 3>;
-			dma-names = "tx", "rx";
-			status = "disabled";
-		};
-
-		spi: spi@7e204000 {
-			compatible = "brcm,bcm2835-spi";
-			reg = <0x7e204000 0x1000>;
-			interrupts = <2 22>;
-			clocks = <&clk_spi>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			status = "disabled";
-		};
-
-		i2c0: i2c@7e205000 {
-			compatible = "brcm,bcm2835-i2c";
-			reg = <0x7e205000 0x1000>;
-			interrupts = <2 21>;
-			clocks = <&clk_i2c>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			status = "disabled";
-		};
-
-		sdhci: sdhci@7e300000 {
-			compatible = "brcm,bcm2835-sdhci";
-			reg = <0x7e300000 0x100>;
-			interrupts = <2 30>;
-			clocks = <&clk_mmc>;
-			status = "disabled";
-		};
-
-		i2c1: i2c@7e804000 {
-			compatible = "brcm,bcm2835-i2c";
-			reg = <0x7e804000 0x1000>;
-			interrupts = <2 21>;
-			clocks = <&clk_i2c>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			status = "disabled";
-		};
-
-		usb@7e980000 {
-			compatible = "brcm,bcm2835-usb";
-			reg = <0x7e980000 0x10000>;
-			interrupts = <1 9>;
-		};
-
 		arm-pmu {
 			compatible = "arm,arm1176-pmu";
 		};
 	};
-
-	clocks {
-		compatible = "simple-bus";
-		#address-cells = <1>;
-		#size-cells = <0>;
-
-		clk_mmc: clock@0 {
-			compatible = "fixed-clock";
-			reg = <0>;
-			#clock-cells = <0>;
-			clock-output-names = "mmc";
-			clock-frequency = <100000000>;
-		};
-
-		clk_i2c: clock@1 {
-			compatible = "fixed-clock";
-			reg = <1>;
-			#clock-cells = <0>;
-			clock-output-names = "i2c";
-			clock-frequency = <250000000>;
-		};
-
-		clk_spi: clock@2 {
-			compatible = "fixed-clock";
-			reg = <2>;
-			#clock-cells = <0>;
-			clock-output-names = "spi";
-			clock-frequency = <250000000>;
-		};
-	};
 };
diff --git a/arch/arm/boot/dts/bcm283x-common.dtsi b/arch/arm/boot/dts/bcm283x-common.dtsi
new file mode 100644
index 0000000..c15e309
--- /dev/null
+++ b/arch/arm/boot/dts/bcm283x-common.dtsi
@@ -0,0 +1,159 @@
+/include/ "skeleton.dtsi"
+
+/ {
+	soc {
+		dma: dma@7e007000 {
+			compatible = "brcm,bcm2835-dma";
+			reg = <0x7e007000 0xf00>;
+			interrupts = <1 16>,
+				     <1 17>,
+				     <1 18>,
+				     <1 19>,
+				     <1 20>,
+				     <1 21>,
+				     <1 22>,
+				     <1 23>,
+				     <1 24>,
+				     <1 25>,
+				     <1 26>,
+				     <1 27>,
+				     <1 28>;
+
+			#dma-cells = <1>;
+			brcm,dma-channel-mask = <0x7f35>;
+		};
+
+		intc: interrupt-controller@7e00b200 {
+			compatible = "brcm,bcm2835-armctrl-ic";
+			reg = <0x7e00b200 0x200>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+		};
+
+		watchdog@7e100000 {
+			compatible = "brcm,bcm2835-pm-wdt";
+			reg = <0x7e100000 0x28>;
+		};
+
+		rng@7e104000 {
+			compatible = "brcm,bcm2835-rng";
+			reg = <0x7e104000 0x10>;
+		};
+
+		gpio: gpio@7e200000 {
+			compatible = "brcm,bcm2835-gpio";
+			reg = <0x7e200000 0xb4>;
+			/*
+			 * The GPIO IP block is designed for 3 banks of GPIOs.
+			 * Each bank has a GPIO interrupt for itself.
+			 * There is an overall "any bank" interrupt.
+			 * In order, these are GIC interrupts 17, 18, 19, 20.
+			 * Since the BCM2835 only has 2 banks, the 2nd bank
+			 * interrupt output appears to be mirrored onto the
+			 * 3rd bank's interrupt signal.
+			 * So, a bank0 interrupt shows up on 17, 20, and
+			 * a bank1 interrupt shows up on 18, 19, 20!
+			 */
+			interrupts = <2 17>, <2 18>, <2 19>, <2 20>;
+
+			gpio-controller;
+			#gpio-cells = <2>;
+
+			interrupt-controller;
+			#interrupt-cells = <2>;
+		};
+
+		uart@7e201000 {
+			compatible = "brcm,bcm2835-pl011", "arm,pl011", "arm,primecell";
+			reg = <0x7e201000 0x1000>;
+			interrupts = <2 25>;
+			clock-frequency = <3000000>;
+			arm,primecell-periphid = <0x00241011>;
+		};
+
+		i2s: i2s@7e203000 {
+			compatible = "brcm,bcm2835-i2s";
+			reg = <0x7e203000 0x20>,
+			      <0x7e101098 0x02>;
+
+			dmas = <&dma 2>,
+			       <&dma 3>;
+			dma-names = "tx", "rx";
+			status = "disabled";
+		};
+
+		spi: spi@7e204000 {
+			compatible = "brcm,bcm2835-spi";
+			reg = <0x7e204000 0x1000>;
+			interrupts = <2 22>;
+			clocks = <&clk_spi>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			status = "disabled";
+		};
+
+		i2c0: i2c@7e205000 {
+			compatible = "brcm,bcm2835-i2c";
+			reg = <0x7e205000 0x1000>;
+			interrupts = <2 21>;
+			clocks = <&clk_i2c>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			status = "disabled";
+		};
+
+		sdhci: sdhci@7e300000 {
+			compatible = "brcm,bcm2835-sdhci";
+			reg = <0x7e300000 0x100>;
+			interrupts = <2 30>;
+			clocks = <&clk_mmc>;
+			status = "disabled";
+		};
+
+		i2c1: i2c@7e804000 {
+			compatible = "brcm,bcm2835-i2c";
+			reg = <0x7e804000 0x1000>;
+			interrupts = <2 21>;
+			clocks = <&clk_i2c>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			status = "disabled";
+		};
+
+		usb@7e980000 {
+			compatible = "brcm,bcm2835-usb";
+			reg = <0x7e980000 0x10000>;
+			interrupts = <1 9>;
+		};
+	};
+
+	clocks {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		clk_mmc: clock@0 {
+			compatible = "fixed-clock";
+			reg = <0>;
+			#clock-cells = <0>;
+			clock-output-names = "mmc";
+			clock-frequency = <100000000>;
+		};
+
+		clk_i2c: clock@1 {
+			compatible = "fixed-clock";
+			reg = <1>;
+			#clock-cells = <0>;
+			clock-output-names = "i2c";
+			clock-frequency = <250000000>;
+		};
+
+		clk_spi: clock@2 {
+			compatible = "fixed-clock";
+			reg = <2>;
+			#clock-cells = <0>;
+			clock-output-names = "spi";
+			clock-frequency = <250000000>;
+		};
+	};
+};
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/9] ARM: BCM2835: Split peripheral definitions off to a common include.

[Eric Anholt]

The 2836 dts will inherit all of this, because it shares the same
peripherals as 2835.

Signed-off-by: Eric Anholt <eric@anholt.net>
---
 arch/arm/boot/dts/bcm2835.dtsi        | 155 +--------------------------------
 arch/arm/boot/dts/bcm283x-common.dtsi | 159 ++++++++++++++++++++++++++++++++++
 2 files changed, 160 insertions(+), 154 deletions(-)
 create mode 100644 arch/arm/boot/dts/bcm283x-common.dtsi

diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
index 4d4c129..bdf9993 100644
--- a/arch/arm/boot/dts/bcm2835.dtsi
+++ b/arch/arm/boot/dts/bcm2835.dtsi
@@ -1,5 +1,6 @@
 #include <dt-bindings/pinctrl/bcm2835.h>
 #include "skeleton.dtsi"
+#include "bcm283x-common.dtsi"
 
 / {
 	compatible = "brcm,bcm2835";
@@ -23,162 +24,8 @@
 			clock-frequency = <1000000>;
 		};
 
-		dma: dma at 7e007000 {
-			compatible = "brcm,bcm2835-dma";
-			reg = <0x7e007000 0xf00>;
-			interrupts = <1 16>,
-				     <1 17>,
-				     <1 18>,
-				     <1 19>,
-				     <1 20>,
-				     <1 21>,
-				     <1 22>,
-				     <1 23>,
-				     <1 24>,
-				     <1 25>,
-				     <1 26>,
-				     <1 27>,
-				     <1 28>;
-
-			#dma-cells = <1>;
-			brcm,dma-channel-mask = <0x7f35>;
-		};
-
-		intc: interrupt-controller at 7e00b200 {
-			compatible = "brcm,bcm2835-armctrl-ic";
-			reg = <0x7e00b200 0x200>;
-			interrupt-controller;
-			#interrupt-cells = <2>;
-		};
-
-		watchdog at 7e100000 {
-			compatible = "brcm,bcm2835-pm-wdt";
-			reg = <0x7e100000 0x28>;
-		};
-
-		rng at 7e104000 {
-			compatible = "brcm,bcm2835-rng";
-			reg = <0x7e104000 0x10>;
-		};
-
-		gpio: gpio at 7e200000 {
-			compatible = "brcm,bcm2835-gpio";
-			reg = <0x7e200000 0xb4>;
-			/*
-			 * The GPIO IP block is designed for 3 banks of GPIOs.
-			 * Each bank has a GPIO interrupt for itself.
-			 * There is an overall "any bank" interrupt.
-			 * In order, these are GIC interrupts 17, 18, 19, 20.
-			 * Since the BCM2835 only has 2 banks, the 2nd bank
-			 * interrupt output appears to be mirrored onto the
-			 * 3rd bank's interrupt signal.
-			 * So, a bank0 interrupt shows up on 17, 20, and
-			 * a bank1 interrupt shows up on 18, 19, 20!
-			 */
-			interrupts = <2 17>, <2 18>, <2 19>, <2 20>;
-
-			gpio-controller;
-			#gpio-cells = <2>;
-
-			interrupt-controller;
-			#interrupt-cells = <2>;
-		};
-
-		uart at 7e201000 {
-			compatible = "brcm,bcm2835-pl011", "arm,pl011", "arm,primecell";
-			reg = <0x7e201000 0x1000>;
-			interrupts = <2 25>;
-			clock-frequency = <3000000>;
-			arm,primecell-periphid = <0x00241011>;
-		};
-
-		i2s: i2s at 7e203000 {
-			compatible = "brcm,bcm2835-i2s";
-			reg = <0x7e203000 0x20>,
-			      <0x7e101098 0x02>;
-
-			dmas = <&dma 2>,
-			       <&dma 3>;
-			dma-names = "tx", "rx";
-			status = "disabled";
-		};
-
-		spi: spi at 7e204000 {
-			compatible = "brcm,bcm2835-spi";
-			reg = <0x7e204000 0x1000>;
-			interrupts = <2 22>;
-			clocks = <&clk_spi>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			status = "disabled";
-		};
-
-		i2c0: i2c at 7e205000 {
-			compatible = "brcm,bcm2835-i2c";
-			reg = <0x7e205000 0x1000>;
-			interrupts = <2 21>;
-			clocks = <&clk_i2c>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			status = "disabled";
-		};
-
-		sdhci: sdhci at 7e300000 {
-			compatible = "brcm,bcm2835-sdhci";
-			reg = <0x7e300000 0x100>;
-			interrupts = <2 30>;
-			clocks = <&clk_mmc>;
-			status = "disabled";
-		};
-
-		i2c1: i2c at 7e804000 {
-			compatible = "brcm,bcm2835-i2c";
-			reg = <0x7e804000 0x1000>;
-			interrupts = <2 21>;
-			clocks = <&clk_i2c>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			status = "disabled";
-		};
-
-		usb at 7e980000 {
-			compatible = "brcm,bcm2835-usb";
-			reg = <0x7e980000 0x10000>;
-			interrupts = <1 9>;
-		};
-
 		arm-pmu {
 			compatible = "arm,arm1176-pmu";
 		};
 	};
-
-	clocks {
-		compatible = "simple-bus";
-		#address-cells = <1>;
-		#size-cells = <0>;
-
-		clk_mmc: clock at 0 {
-			compatible = "fixed-clock";
-			reg = <0>;
-			#clock-cells = <0>;
-			clock-output-names = "mmc";
-			clock-frequency = <100000000>;
-		};
-
-		clk_i2c: clock at 1 {
-			compatible = "fixed-clock";
-			reg = <1>;
-			#clock-cells = <0>;
-			clock-output-names = "i2c";
-			clock-frequency = <250000000>;
-		};
-
-		clk_spi: clock at 2 {
-			compatible = "fixed-clock";
-			reg = <2>;
-			#clock-cells = <0>;
-			clock-output-names = "spi";
-			clock-frequency = <250000000>;
-		};
-	};
 };
diff --git a/arch/arm/boot/dts/bcm283x-common.dtsi b/arch/arm/boot/dts/bcm283x-common.dtsi
new file mode 100644
index 0000000..c15e309
--- /dev/null
+++ b/arch/arm/boot/dts/bcm283x-common.dtsi
@@ -0,0 +1,159 @@
+/include/ "skeleton.dtsi"
+
+/ {
+	soc {
+		dma: dma at 7e007000 {
+			compatible = "brcm,bcm2835-dma";
+			reg = <0x7e007000 0xf00>;
+			interrupts = <1 16>,
+				     <1 17>,
+				     <1 18>,
+				     <1 19>,
+				     <1 20>,
+				     <1 21>,
+				     <1 22>,
+				     <1 23>,
+				     <1 24>,
+				     <1 25>,
+				     <1 26>,
+				     <1 27>,
+				     <1 28>;
+
+			#dma-cells = <1>;
+			brcm,dma-channel-mask = <0x7f35>;
+		};
+
+		intc: interrupt-controller at 7e00b200 {
+			compatible = "brcm,bcm2835-armctrl-ic";
+			reg = <0x7e00b200 0x200>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+		};
+
+		watchdog at 7e100000 {
+			compatible = "brcm,bcm2835-pm-wdt";
+			reg = <0x7e100000 0x28>;
+		};
+
+		rng at 7e104000 {
+			compatible = "brcm,bcm2835-rng";
+			reg = <0x7e104000 0x10>;
+		};
+
+		gpio: gpio at 7e200000 {
+			compatible = "brcm,bcm2835-gpio";
+			reg = <0x7e200000 0xb4>;
+			/*
+			 * The GPIO IP block is designed for 3 banks of GPIOs.
+			 * Each bank has a GPIO interrupt for itself.
+			 * There is an overall "any bank" interrupt.
+			 * In order, these are GIC interrupts 17, 18, 19, 20.
+			 * Since the BCM2835 only has 2 banks, the 2nd bank
+			 * interrupt output appears to be mirrored onto the
+			 * 3rd bank's interrupt signal.
+			 * So, a bank0 interrupt shows up on 17, 20, and
+			 * a bank1 interrupt shows up on 18, 19, 20!
+			 */
+			interrupts = <2 17>, <2 18>, <2 19>, <2 20>;
+
+			gpio-controller;
+			#gpio-cells = <2>;
+
+			interrupt-controller;
+			#interrupt-cells = <2>;
+		};
+
+		uart at 7e201000 {
+			compatible = "brcm,bcm2835-pl011", "arm,pl011", "arm,primecell";
+			reg = <0x7e201000 0x1000>;
+			interrupts = <2 25>;
+			clock-frequency = <3000000>;
+			arm,primecell-periphid = <0x00241011>;
+		};
+
+		i2s: i2s at 7e203000 {
+			compatible = "brcm,bcm2835-i2s";
+			reg = <0x7e203000 0x20>,
+			      <0x7e101098 0x02>;
+
+			dmas = <&dma 2>,
+			       <&dma 3>;
+			dma-names = "tx", "rx";
+			status = "disabled";
+		};
+
+		spi: spi at 7e204000 {
+			compatible = "brcm,bcm2835-spi";
+			reg = <0x7e204000 0x1000>;
+			interrupts = <2 22>;
+			clocks = <&clk_spi>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			status = "disabled";
+		};
+
+		i2c0: i2c at 7e205000 {
+			compatible = "brcm,bcm2835-i2c";
+			reg = <0x7e205000 0x1000>;
+			interrupts = <2 21>;
+			clocks = <&clk_i2c>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			status = "disabled";
+		};
+
+		sdhci: sdhci at 7e300000 {
+			compatible = "brcm,bcm2835-sdhci";
+			reg = <0x7e300000 0x100>;
+			interrupts = <2 30>;
+			clocks = <&clk_mmc>;
+			status = "disabled";
+		};
+
+		i2c1: i2c at 7e804000 {
+			compatible = "brcm,bcm2835-i2c";
+			reg = <0x7e804000 0x1000>;
+			interrupts = <2 21>;
+			clocks = <&clk_i2c>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			status = "disabled";
+		};
+
+		usb at 7e980000 {
+			compatible = "brcm,bcm2835-usb";
+			reg = <0x7e980000 0x10000>;
+			interrupts = <1 9>;
+		};
+	};
+
+	clocks {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		clk_mmc: clock at 0 {
+			compatible = "fixed-clock";
+			reg = <0>;
+			#clock-cells = <0>;
+			clock-output-names = "mmc";
+			clock-frequency = <100000000>;
+		};
+
+		clk_i2c: clock at 1 {
+			compatible = "fixed-clock";
+			reg = <1>;
+			#clock-cells = <0>;
+			clock-output-names = "i2c";
+			clock-frequency = <250000000>;
+		};
+
+		clk_spi: clock at 2 {
+			compatible = "fixed-clock";
+			reg = <2>;
+			#clock-cells = <0>;
+			clock-output-names = "spi";
+			clock-frequency = <250000000>;
+		};
+	};
+};
-- 
2.1.4

Re: [PATCH 2/9] ARM: BCM2835: Split peripheral definitions off to a common include.

[Stephen Warren]

On 04/21/2015 12:09 PM, Eric Anholt wrote:
> The 2836 dts will inherit all of this, because it shares the same
> peripherals as 2835.

> diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi

>  #include <dt-bindings/pinctrl/bcm2835.h>
>  #include "skeleton.dtsi"
> +#include "bcm283x-common.dtsi"

skeleton is included there.

> diff --git a/arch/arm/boot/dts/bcm283x-common.dtsi b/arch/arm/boot/dts/bcm283x-common.dtsi

> +/include/ "skeleton.dtsi"

So there's no need to include it here.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/9] ARM: BCM2835: Split peripheral definitions off to a common include.

[Stephen Warren]

On 04/21/2015 12:09 PM, Eric Anholt wrote:
> The 2836 dts will inherit all of this, because it shares the same
> peripherals as 2835.

> diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi

>  #include <dt-bindings/pinctrl/bcm2835.h>
>  #include "skeleton.dtsi"
> +#include "bcm283x-common.dtsi"

skeleton is included there.

> diff --git a/arch/arm/boot/dts/bcm283x-common.dtsi b/arch/arm/boot/dts/bcm283x-common.dtsi

> +/include/ "skeleton.dtsi"

So there's no need to include it here.

[PATCH 3/9] ARM: Make a copy of the 2835 dts for the 2836.

[Eric Anholt]

This is not hooked up to anything yet, but it means that our later
2836-specific changes will be more obvious.  The bcm2836-rpi-2-b.dts
actually comes from bcm2835-rpi-2-b-plus, which apparently is the
closest.

Signed-off-by: Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
---
 arch/arm/boot/dts/bcm2836-rpi-2-b.dts | 30 +++++++++++++++++++++
 arch/arm/boot/dts/bcm2836-rpi.dtsi    | 51 +++++++++++++++++++++++++++++++++++
 arch/arm/boot/dts/bcm2836.dtsi        | 31 +++++++++++++++++++++
 3 files changed, 112 insertions(+)
 create mode 100644 arch/arm/boot/dts/bcm2836-rpi-2-b.dts
 create mode 100644 arch/arm/boot/dts/bcm2836-rpi.dtsi
 create mode 100644 arch/arm/boot/dts/bcm2836.dtsi

diff --git a/arch/arm/boot/dts/bcm2836-rpi-2-b.dts b/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
new file mode 100644
index 0000000..668442b
--- /dev/null
+++ b/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
@@ -0,0 +1,30 @@
+/dts-v1/;
+#include "bcm2835-rpi.dtsi"
+
+/ {
+	compatible = "raspberrypi,model-b-plus", "brcm,bcm2835";
+	model = "Raspberry Pi Model B+";
+
+	leds {
+		act {
+			gpios = <&gpio 47 0>;
+		};
+
+		pwr {
+			label = "PWR";
+			gpios = <&gpio 35 0>;
+			default-state = "keep";
+			linux,default-trigger = "default-on";
+		};
+	};
+};
+
+&gpio {
+	pinctrl-0 = <&gpioout &alt0 &i2s_alt0 &alt3>;
+
+	/* I2S interface */
+	i2s_alt0: i2s_alt0 {
+		brcm,pins = <18 19 20 21>;
+		brcm,function = <BCM2835_FSEL_ALT0>;
+	};
+};
diff --git a/arch/arm/boot/dts/bcm2836-rpi.dtsi b/arch/arm/boot/dts/bcm2836-rpi.dtsi
new file mode 100644
index 0000000..46780bb
--- /dev/null
+++ b/arch/arm/boot/dts/bcm2836-rpi.dtsi
@@ -0,0 +1,51 @@
+#include "bcm2835.dtsi"
+
+/ {
+	memory {
+		reg = <0 0x10000000>;
+	};
+
+	leds {
+		compatible = "gpio-leds";
+
+		act {
+			label = "ACT";
+			default-state = "keep";
+			linux,default-trigger = "heartbeat";
+		};
+	};
+};
+
+&gpio {
+	pinctrl-names = "default";
+
+	gpioout: gpioout {
+		brcm,pins = <6>;
+		brcm,function = <BCM2835_FSEL_GPIO_OUT>;
+	};
+
+	alt0: alt0 {
+		brcm,pins = <0 1 2 3 4 5 7 8 9 10 11 14 15 40 45>;
+		brcm,function = <BCM2835_FSEL_ALT0>;
+	};
+
+	alt3: alt3 {
+		brcm,pins = <48 49 50 51 52 53>;
+		brcm,function = <BCM2835_FSEL_ALT3>;
+	};
+};
+
+&i2c0 {
+	status = "okay";
+	clock-frequency = <100000>;
+};
+
+&i2c1 {
+	status = "okay";
+	clock-frequency = <100000>;
+};
+
+&sdhci {
+	status = "okay";
+	bus-width = <4>;
+};
diff --git a/arch/arm/boot/dts/bcm2836.dtsi b/arch/arm/boot/dts/bcm2836.dtsi
new file mode 100644
index 0000000..bdf9993
--- /dev/null
+++ b/arch/arm/boot/dts/bcm2836.dtsi
@@ -0,0 +1,31 @@
+#include <dt-bindings/pinctrl/bcm2835.h>
+#include "skeleton.dtsi"
+#include "bcm283x-common.dtsi"
+
+/ {
+	compatible = "brcm,bcm2835";
+	model = "BCM2835";
+	interrupt-parent = <&intc>;
+
+	chosen {
+		bootargs = "earlyprintk console=ttyAMA0";
+	};
+
+	soc {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges = <0x7e000000 0x20000000 0x02000000>;
+
+		timer@7e003000 {
+			compatible = "brcm,bcm2835-system-timer";
+			reg = <0x7e003000 0x1000>;
+			interrupts = <1 0>, <1 1>, <1 2>, <1 3>;
+			clock-frequency = <1000000>;
+		};
+
+		arm-pmu {
+			compatible = "arm,arm1176-pmu";
+		};
+	};
+};
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/9] ARM: Make a copy of the 2835 dts for the 2836.

[Eric Anholt]

This is not hooked up to anything yet, but it means that our later
2836-specific changes will be more obvious.  The bcm2836-rpi-2-b.dts
actually comes from bcm2835-rpi-2-b-plus, which apparently is the
closest.

Signed-off-by: Eric Anholt <eric@anholt.net>
---
 arch/arm/boot/dts/bcm2836-rpi-2-b.dts | 30 +++++++++++++++++++++
 arch/arm/boot/dts/bcm2836-rpi.dtsi    | 51 +++++++++++++++++++++++++++++++++++
 arch/arm/boot/dts/bcm2836.dtsi        | 31 +++++++++++++++++++++
 3 files changed, 112 insertions(+)
 create mode 100644 arch/arm/boot/dts/bcm2836-rpi-2-b.dts
 create mode 100644 arch/arm/boot/dts/bcm2836-rpi.dtsi
 create mode 100644 arch/arm/boot/dts/bcm2836.dtsi

diff --git a/arch/arm/boot/dts/bcm2836-rpi-2-b.dts b/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
new file mode 100644
index 0000000..668442b
--- /dev/null
+++ b/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
@@ -0,0 +1,30 @@
+/dts-v1/;
+#include "bcm2835-rpi.dtsi"
+
+/ {
+	compatible = "raspberrypi,model-b-plus", "brcm,bcm2835";
+	model = "Raspberry Pi Model B+";
+
+	leds {
+		act {
+			gpios = <&gpio 47 0>;
+		};
+
+		pwr {
+			label = "PWR";
+			gpios = <&gpio 35 0>;
+			default-state = "keep";
+			linux,default-trigger = "default-on";
+		};
+	};
+};
+
+&gpio {
+	pinctrl-0 = <&gpioout &alt0 &i2s_alt0 &alt3>;
+
+	/* I2S interface */
+	i2s_alt0: i2s_alt0 {
+		brcm,pins = <18 19 20 21>;
+		brcm,function = <BCM2835_FSEL_ALT0>;
+	};
+};
diff --git a/arch/arm/boot/dts/bcm2836-rpi.dtsi b/arch/arm/boot/dts/bcm2836-rpi.dtsi
new file mode 100644
index 0000000..46780bb
--- /dev/null
+++ b/arch/arm/boot/dts/bcm2836-rpi.dtsi
@@ -0,0 +1,51 @@
+#include "bcm2835.dtsi"
+
+/ {
+	memory {
+		reg = <0 0x10000000>;
+	};
+
+	leds {
+		compatible = "gpio-leds";
+
+		act {
+			label = "ACT";
+			default-state = "keep";
+			linux,default-trigger = "heartbeat";
+		};
+	};
+};
+
+&gpio {
+	pinctrl-names = "default";
+
+	gpioout: gpioout {
+		brcm,pins = <6>;
+		brcm,function = <BCM2835_FSEL_GPIO_OUT>;
+	};
+
+	alt0: alt0 {
+		brcm,pins = <0 1 2 3 4 5 7 8 9 10 11 14 15 40 45>;
+		brcm,function = <BCM2835_FSEL_ALT0>;
+	};
+
+	alt3: alt3 {
+		brcm,pins = <48 49 50 51 52 53>;
+		brcm,function = <BCM2835_FSEL_ALT3>;
+	};
+};
+
+&i2c0 {
+	status = "okay";
+	clock-frequency = <100000>;
+};
+
+&i2c1 {
+	status = "okay";
+	clock-frequency = <100000>;
+};
+
+&sdhci {
+	status = "okay";
+	bus-width = <4>;
+};
diff --git a/arch/arm/boot/dts/bcm2836.dtsi b/arch/arm/boot/dts/bcm2836.dtsi
new file mode 100644
index 0000000..bdf9993
--- /dev/null
+++ b/arch/arm/boot/dts/bcm2836.dtsi
@@ -0,0 +1,31 @@
+#include <dt-bindings/pinctrl/bcm2835.h>
+#include "skeleton.dtsi"
+#include "bcm283x-common.dtsi"
+
+/ {
+	compatible = "brcm,bcm2835";
+	model = "BCM2835";
+	interrupt-parent = <&intc>;
+
+	chosen {
+		bootargs = "earlyprintk console=ttyAMA0";
+	};
+
+	soc {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges = <0x7e000000 0x20000000 0x02000000>;
+
+		timer at 7e003000 {
+			compatible = "brcm,bcm2835-system-timer";
+			reg = <0x7e003000 0x1000>;
+			interrupts = <1 0>, <1 1>, <1 2>, <1 3>;
+			clock-frequency = <1000000>;
+		};
+
+		arm-pmu {
+			compatible = "arm,arm1176-pmu";
+		};
+	};
+};
-- 
2.1.4

Re: [PATCH 3/9] ARM: Make a copy of the 2835 dts for the 2836.

[Stephen Warren]

On 04/21/2015 12:09 PM, Eric Anholt wrote:
> This is not hooked up to anything yet, but it means that our later
> 2836-specific changes will be more obvious.  The bcm2836-rpi-2-b.dts
> actually comes from bcm2835-rpi-2-b-plus, which apparently is the
> closest.

>  arch/arm/boot/dts/bcm2836-rpi-2-b.dts | 30 +++++++++++++++++++++
>  arch/arm/boot/dts/bcm2836-rpi.dtsi    | 51 +++++++++++++++++++++++++++++++++++
>  arch/arm/boot/dts/bcm2836.dtsi        | 31 +++++++++++++++++++++

So we obviously need a new top-level bcm2836-rpi-2-b.dts for the new
board, and a new bcm2836.dtsi for the new SoC. However, do we really
need to duplicate bcm2836-rpi.dtsi? It should be identical between the
bcm2835/6 RPis, so I'd expect to just rename it to bcm283x-rpi.dtsi and
share it? The include of the SoC .dtsi file could be moved one level up
since that's the one difference?

Eventually, I'd like to get around to revamping the bcm283x DTs so
there's a DT for each separate board model, which would match the DT
filenames that U-Boot is looking for. Still, that's separate from these
patches.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/9] ARM: Make a copy of the 2835 dts for the 2836.

[Stephen Warren]

On 04/21/2015 12:09 PM, Eric Anholt wrote:
> This is not hooked up to anything yet, but it means that our later
> 2836-specific changes will be more obvious.  The bcm2836-rpi-2-b.dts
> actually comes from bcm2835-rpi-2-b-plus, which apparently is the
> closest.

>  arch/arm/boot/dts/bcm2836-rpi-2-b.dts | 30 +++++++++++++++++++++
>  arch/arm/boot/dts/bcm2836-rpi.dtsi    | 51 +++++++++++++++++++++++++++++++++++
>  arch/arm/boot/dts/bcm2836.dtsi        | 31 +++++++++++++++++++++

So we obviously need a new top-level bcm2836-rpi-2-b.dts for the new
board, and a new bcm2836.dtsi for the new SoC. However, do we really
need to duplicate bcm2836-rpi.dtsi? It should be identical between the
bcm2835/6 RPis, so I'd expect to just rename it to bcm283x-rpi.dtsi and
share it? The include of the SoC .dtsi file could be moved one level up
since that's the one difference?

Eventually, I'd like to get around to revamping the bcm283x DTs so
there's a DT for each separate board model, which would match the DT
filenames that U-Boot is looking for. Still, that's separate from these
patches.

[PATCH 4/9] ARM: Update the device trees for 2836.

[Eric Anholt]

The bus address for peripherals comes from the platform.h diff between
2708 and 2709, and the CPU's DT definition is based on the 2709 DT.

Signed-off-by: Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
---
 arch/arm/boot/dts/bcm2836-rpi-2-b.dts |  6 +++---
 arch/arm/boot/dts/bcm2836-rpi.dtsi    |  2 +-
 arch/arm/boot/dts/bcm2836.dtsi        | 22 +++++++++++++++++-----
 3 files changed, 21 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/bcm2836-rpi-2-b.dts b/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
index 668442b..006d9c9 100644
--- a/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
+++ b/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
@@ -1,9 +1,9 @@
 /dts-v1/;
-#include "bcm2835-rpi.dtsi"
+#include "bcm2836-rpi.dtsi"
 
 / {
-	compatible = "raspberrypi,model-b-plus", "brcm,bcm2835";
-	model = "Raspberry Pi Model B+";
+	compatible = "raspberrypi,2-model-b", "brcm,bcm2836";
+	model = "Raspberry Pi 2 Model B";
 
 	leds {
 		act {
diff --git a/arch/arm/boot/dts/bcm2836-rpi.dtsi b/arch/arm/boot/dts/bcm2836-rpi.dtsi
index 46780bb..b866911 100644
--- a/arch/arm/boot/dts/bcm2836-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2836-rpi.dtsi
@@ -1,4 +1,4 @@
-#include "bcm2835.dtsi"
+#include "bcm2836.dtsi"
 
 / {
 	memory {
diff --git a/arch/arm/boot/dts/bcm2836.dtsi b/arch/arm/boot/dts/bcm2836.dtsi
index bdf9993..2e88138 100644
--- a/arch/arm/boot/dts/bcm2836.dtsi
+++ b/arch/arm/boot/dts/bcm2836.dtsi
@@ -3,8 +3,8 @@
 #include "bcm283x-common.dtsi"
 
 / {
-	compatible = "brcm,bcm2835";
-	model = "BCM2835";
+	compatible = "brcm,bcm2836";
+	model = "BCM2836";
 	interrupt-parent = <&intc>;
 
 	chosen {
@@ -15,7 +15,7 @@
 		compatible = "simple-bus";
 		#address-cells = <1>;
 		#size-cells = <1>;
-		ranges = <0x7e000000 0x20000000 0x02000000>;
+		ranges = <0x7e000000 0x3f000000 0x01000000>;
 
 		timer@7e003000 {
 			compatible = "brcm,bcm2835-system-timer";
@@ -23,9 +23,21 @@
 			interrupts = <1 0>, <1 1>, <1 2>, <1 3>;
 			clock-frequency = <1000000>;
 		};
+	};
+
+	cpus: cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
 
-		arm-pmu {
-			compatible = "arm,arm1176-pmu";
+		v7_cpu0: cpu@0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a7";
+			reg = <0xf00>;
+			clock-frequency = <800000000>;
 		};
 	};
+
+	__overrides__ {
+		arm_freq = <&v7_cpu0>, "clock-frequency:0";
+	};
 };
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/9] ARM: Update the device trees for 2836.

[Eric Anholt]

The bus address for peripherals comes from the platform.h diff between
2708 and 2709, and the CPU's DT definition is based on the 2709 DT.

Signed-off-by: Eric Anholt <eric@anholt.net>
---
 arch/arm/boot/dts/bcm2836-rpi-2-b.dts |  6 +++---
 arch/arm/boot/dts/bcm2836-rpi.dtsi    |  2 +-
 arch/arm/boot/dts/bcm2836.dtsi        | 22 +++++++++++++++++-----
 3 files changed, 21 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/bcm2836-rpi-2-b.dts b/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
index 668442b..006d9c9 100644
--- a/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
+++ b/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
@@ -1,9 +1,9 @@
 /dts-v1/;
-#include "bcm2835-rpi.dtsi"
+#include "bcm2836-rpi.dtsi"
 
 / {
-	compatible = "raspberrypi,model-b-plus", "brcm,bcm2835";
-	model = "Raspberry Pi Model B+";
+	compatible = "raspberrypi,2-model-b", "brcm,bcm2836";
+	model = "Raspberry Pi 2 Model B";
 
 	leds {
 		act {
diff --git a/arch/arm/boot/dts/bcm2836-rpi.dtsi b/arch/arm/boot/dts/bcm2836-rpi.dtsi
index 46780bb..b866911 100644
--- a/arch/arm/boot/dts/bcm2836-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2836-rpi.dtsi
@@ -1,4 +1,4 @@
-#include "bcm2835.dtsi"
+#include "bcm2836.dtsi"
 
 / {
 	memory {
diff --git a/arch/arm/boot/dts/bcm2836.dtsi b/arch/arm/boot/dts/bcm2836.dtsi
index bdf9993..2e88138 100644
--- a/arch/arm/boot/dts/bcm2836.dtsi
+++ b/arch/arm/boot/dts/bcm2836.dtsi
@@ -3,8 +3,8 @@
 #include "bcm283x-common.dtsi"
 
 / {
-	compatible = "brcm,bcm2835";
-	model = "BCM2835";
+	compatible = "brcm,bcm2836";
+	model = "BCM2836";
 	interrupt-parent = <&intc>;
 
 	chosen {
@@ -15,7 +15,7 @@
 		compatible = "simple-bus";
 		#address-cells = <1>;
 		#size-cells = <1>;
-		ranges = <0x7e000000 0x20000000 0x02000000>;
+		ranges = <0x7e000000 0x3f000000 0x01000000>;
 
 		timer at 7e003000 {
 			compatible = "brcm,bcm2835-system-timer";
@@ -23,9 +23,21 @@
 			interrupts = <1 0>, <1 1>, <1 2>, <1 3>;
 			clock-frequency = <1000000>;
 		};
+	};
+
+	cpus: cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
 
-		arm-pmu {
-			compatible = "arm,arm1176-pmu";
+		v7_cpu0: cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a7";
+			reg = <0xf00>;
+			clock-frequency = <800000000>;
 		};
 	};
+
+	__overrides__ {
+		arm_freq = <&v7_cpu0>, "clock-frequency:0";
+	};
 };
-- 
2.1.4

Re: [PATCH 4/9] ARM: Update the device trees for 2836.

[Stephen Warren]

On 04/21/2015 12:09 PM, Eric Anholt wrote:
> The bus address for peripherals comes from the platform.h diff between
> 2708 and 2709, and the CPU's DT definition is based on the 2709 DT.

I would suggest squashing this with the previous commit. I was puzzled
why patch 3 added bcm2836-rpi.dtsi, yet in that patch,
bcm2836-rpi-2-b.dts included bcm2835-rpi.dtsi instead.

git should still show that patch as a copy+edit assuming the files are
similar enough.

> diff --git a/arch/arm/boot/dts/bcm2836.dtsi b/arch/arm/boot/dts/bcm2836.dtsi

> +	__overrides__ {
> +		arm_freq = <&v7_cpu0>, "clock-frequency:0";
> +	};
>  };

We don't have any DT override/overlay/... support in the bcm2835 files
yet. Does it make sense not to only add it to bcm2836 files when we add
the equivalent everywhere?

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/9] ARM: Update the device trees for 2836.

[Stephen Warren]

On 04/21/2015 12:09 PM, Eric Anholt wrote:
> The bus address for peripherals comes from the platform.h diff between
> 2708 and 2709, and the CPU's DT definition is based on the 2709 DT.

I would suggest squashing this with the previous commit. I was puzzled
why patch 3 added bcm2836-rpi.dtsi, yet in that patch,
bcm2836-rpi-2-b.dts included bcm2835-rpi.dtsi instead.

git should still show that patch as a copy+edit assuming the files are
similar enough.

> diff --git a/arch/arm/boot/dts/bcm2836.dtsi b/arch/arm/boot/dts/bcm2836.dtsi

> +	__overrides__ {
> +		arm_freq = <&v7_cpu0>, "clock-frequency:0";
> +	};
>  };

We don't have any DT override/overlay/... support in the bcm2835 files
yet. Does it make sense not to only add it to bcm2836 files when we add
the equivalent everywhere?

[PATCH 5/9] ARM: BCM2836: Add io map initialization for bcm2836.

[Eric Anholt]

---
 arch/arm/mach-bcm/board_bcm2835.c | 30 ++++++++++++++++++++++++++++--
 1 file changed, 28 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-bcm/board_bcm2835.c b/arch/arm/mach-bcm/board_bcm2835.c
index 70f2f39..69f5821 100644
--- a/arch/arm/mach-bcm/board_bcm2835.c
+++ b/arch/arm/mach-bcm/board_bcm2835.c
@@ -32,6 +32,7 @@
 #define PM_RSTS_HADWRH_SET		0x00000040
 
 #define BCM2835_PERIPH_PHYS	0x20000000
+#define BCM2836_PERIPH_PHYS	0x3f000000
 #define BCM2835_PERIPH_VIRT	0xf0000000
 #define BCM2835_PERIPH_SIZE	SZ_16M
 
@@ -93,16 +94,28 @@ static void bcm2835_power_off(void)
 	bcm2835_restart(REBOOT_HARD, "");
 }
 
-static struct map_desc io_map __initdata = {
+static struct map_desc bcm2835_io_map __initdata = {
 	.virtual = BCM2835_PERIPH_VIRT,
 	.pfn = __phys_to_pfn(BCM2835_PERIPH_PHYS),
 	.length = BCM2835_PERIPH_SIZE,
 	.type = MT_DEVICE
 };
 
+static struct map_desc bcm2836_io_map __initdata = {
+	.virtual = BCM2835_PERIPH_VIRT,
+	.pfn = __phys_to_pfn(BCM2836_PERIPH_PHYS),
+	.length = BCM2835_PERIPH_SIZE,
+	.type = MT_DEVICE
+};
+
 static void __init bcm2835_map_io(void)
 {
-	iotable_init(&io_map, 1);
+	iotable_init(&bcm2835_io_map, 1);
+}
+
+static void __init bcm2836_map_io(void)
+{
+	iotable_init(&bcm2836_io_map, 1);
 }
 
 static void __init bcm2835_init(void)
@@ -128,6 +141,11 @@ static const char * const bcm2835_compat[] = {
 	NULL
 };
 
+static const char * const bcm2836_compat[] = {
+	"brcm,bcm2836",
+	NULL
+};
+
 DT_MACHINE_START(BCM2835, "BCM2835")
 	.map_io = bcm2835_map_io,
 	.init_irq = irqchip_init,
@@ -135,3 +153,11 @@ DT_MACHINE_START(BCM2835, "BCM2835")
 	.restart = bcm2835_restart,
 	.dt_compat = bcm2835_compat
 MACHINE_END
+
+DT_MACHINE_START(BCM2836, "BCM2836")
+	.map_io = bcm2836_map_io,
+	.init_irq = irqchip_init,
+	.init_machine = bcm2835_init,
+	.restart = bcm2835_restart,
+	.dt_compat = bcm2836_compat
+MACHINE_END
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 5/9] ARM: BCM2836: Add io map initialization for bcm2836.

[Eric Anholt]

---
 arch/arm/mach-bcm/board_bcm2835.c | 30 ++++++++++++++++++++++++++++--
 1 file changed, 28 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-bcm/board_bcm2835.c b/arch/arm/mach-bcm/board_bcm2835.c
index 70f2f39..69f5821 100644
--- a/arch/arm/mach-bcm/board_bcm2835.c
+++ b/arch/arm/mach-bcm/board_bcm2835.c
@@ -32,6 +32,7 @@
 #define PM_RSTS_HADWRH_SET		0x00000040
 
 #define BCM2835_PERIPH_PHYS	0x20000000
+#define BCM2836_PERIPH_PHYS	0x3f000000
 #define BCM2835_PERIPH_VIRT	0xf0000000
 #define BCM2835_PERIPH_SIZE	SZ_16M
 
@@ -93,16 +94,28 @@ static void bcm2835_power_off(void)
 	bcm2835_restart(REBOOT_HARD, "");
 }
 
-static struct map_desc io_map __initdata = {
+static struct map_desc bcm2835_io_map __initdata = {
 	.virtual = BCM2835_PERIPH_VIRT,
 	.pfn = __phys_to_pfn(BCM2835_PERIPH_PHYS),
 	.length = BCM2835_PERIPH_SIZE,
 	.type = MT_DEVICE
 };
 
+static struct map_desc bcm2836_io_map __initdata = {
+	.virtual = BCM2835_PERIPH_VIRT,
+	.pfn = __phys_to_pfn(BCM2836_PERIPH_PHYS),
+	.length = BCM2835_PERIPH_SIZE,
+	.type = MT_DEVICE
+};
+
 static void __init bcm2835_map_io(void)
 {
-	iotable_init(&io_map, 1);
+	iotable_init(&bcm2835_io_map, 1);
+}
+
+static void __init bcm2836_map_io(void)
+{
+	iotable_init(&bcm2836_io_map, 1);
 }
 
 static void __init bcm2835_init(void)
@@ -128,6 +141,11 @@ static const char * const bcm2835_compat[] = {
 	NULL
 };
 
+static const char * const bcm2836_compat[] = {
+	"brcm,bcm2836",
+	NULL
+};
+
 DT_MACHINE_START(BCM2835, "BCM2835")
 	.map_io = bcm2835_map_io,
 	.init_irq = irqchip_init,
@@ -135,3 +153,11 @@ DT_MACHINE_START(BCM2835, "BCM2835")
 	.restart = bcm2835_restart,
 	.dt_compat = bcm2835_compat
 MACHINE_END
+
+DT_MACHINE_START(BCM2836, "BCM2836")
+	.map_io = bcm2836_map_io,
+	.init_irq = irqchip_init,
+	.init_machine = bcm2835_init,
+	.restart = bcm2835_restart,
+	.dt_compat = bcm2836_compat
+MACHINE_END
-- 
2.1.4

Re: [PATCH 5/9] ARM: BCM2836: Add io map initialization for bcm2836.

[Arnd Bergmann]

On Tuesday 21 April 2015 11:09:52 Eric Anholt wrote:
> +static struct map_desc bcm2836_io_map __initdata = {
> +       .virtual = BCM2835_PERIPH_VIRT,
> +       .pfn = __phys_to_pfn(BCM2836_PERIPH_PHYS),
> +       .length = BCM2835_PERIPH_SIZE,
> +       .type = MT_DEVICE
> +};
> +
>  static void __init bcm2835_map_io(void)
>  {
> -       iotable_init(&io_map, 1);
> +       iotable_init(&bcm2835_io_map, 1);
> +}
> +
> +static void __init bcm2836_map_io(void)
> +{
> +       iotable_init(&bcm2836_io_map, 1);
>  }
> 

Can you explain what this is needed for? Most platform ports don't
do this any more.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 5/9] ARM: BCM2836: Add io map initialization for bcm2836.

[Arnd Bergmann]

On Tuesday 21 April 2015 11:09:52 Eric Anholt wrote:
> +static struct map_desc bcm2836_io_map __initdata = {
> +       .virtual = BCM2835_PERIPH_VIRT,
> +       .pfn = __phys_to_pfn(BCM2836_PERIPH_PHYS),
> +       .length = BCM2835_PERIPH_SIZE,
> +       .type = MT_DEVICE
> +};
> +
>  static void __init bcm2835_map_io(void)
>  {
> -       iotable_init(&io_map, 1);
> +       iotable_init(&bcm2835_io_map, 1);
> +}
> +
> +static void __init bcm2836_map_io(void)
> +{
> +       iotable_init(&bcm2836_io_map, 1);
>  }
> 

Can you explain what this is needed for? Most platform ports don't
do this any more.

	Arnd

Re: [PATCH 5/9] ARM: BCM2836: Add io map initialization for bcm2836.

[Eric Anholt]

[-- Attachment #1: Type: text/plain, Size: 863 bytes --]

Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> writes:

> On Tuesday 21 April 2015 11:09:52 Eric Anholt wrote:
>> +static struct map_desc bcm2836_io_map __initdata = {
>> +       .virtual = BCM2835_PERIPH_VIRT,
>> +       .pfn = __phys_to_pfn(BCM2836_PERIPH_PHYS),
>> +       .length = BCM2835_PERIPH_SIZE,
>> +       .type = MT_DEVICE
>> +};
>> +
>>  static void __init bcm2835_map_io(void)
>>  {
>> -       iotable_init(&io_map, 1);
>> +       iotable_init(&bcm2835_io_map, 1);
>> +}
>> +
>> +static void __init bcm2836_map_io(void)
>> +{
>> +       iotable_init(&bcm2836_io_map, 1);
>>  }
>> 
>
> Can you explain what this is needed for? Most platform ports don't
> do this any more.

Nope, I can't!  I'm not sure what the bcm2835 side of it does, and I was
just replicating that for 2836.

Should it be removed from 2835, too?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

[PATCH 5/9] ARM: BCM2836: Add io map initialization for bcm2836.

[Eric Anholt]

Arnd Bergmann <arnd@arndb.de> writes:

> On Tuesday 21 April 2015 11:09:52 Eric Anholt wrote:
>> +static struct map_desc bcm2836_io_map __initdata = {
>> +       .virtual = BCM2835_PERIPH_VIRT,
>> +       .pfn = __phys_to_pfn(BCM2836_PERIPH_PHYS),
>> +       .length = BCM2835_PERIPH_SIZE,
>> +       .type = MT_DEVICE
>> +};
>> +
>>  static void __init bcm2835_map_io(void)
>>  {
>> -       iotable_init(&io_map, 1);
>> +       iotable_init(&bcm2835_io_map, 1);
>> +}
>> +
>> +static void __init bcm2836_map_io(void)
>> +{
>> +       iotable_init(&bcm2836_io_map, 1);
>>  }
>> 
>
> Can you explain what this is needed for? Most platform ports don't
> do this any more.

Nope, I can't!  I'm not sure what the bcm2835 side of it does, and I was
just replicating that for 2836.

Should it be removed from 2835, too?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150421/d95075d0/attachment.sig>

Re: [PATCH 5/9] ARM: BCM2836: Add io map initialization for bcm2836.

[Arnd Bergmann]

On Tuesday 21 April 2015 13:37:13 Eric Anholt wrote:
> Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> writes:
> 
> > On Tuesday 21 April 2015 11:09:52 Eric Anholt wrote:
> >> +static struct map_desc bcm2836_io_map __initdata = {
> >> +       .virtual = BCM2835_PERIPH_VIRT,
> >> +       .pfn = __phys_to_pfn(BCM2836_PERIPH_PHYS),
> >> +       .length = BCM2835_PERIPH_SIZE,
> >> +       .type = MT_DEVICE
> >> +};
> >> +
> >>  static void __init bcm2835_map_io(void)
> >>  {
> >> -       iotable_init(&io_map, 1);
> >> +       iotable_init(&bcm2835_io_map, 1);
> >> +}
> >> +
> >> +static void __init bcm2836_map_io(void)
> >> +{
> >> +       iotable_init(&bcm2836_io_map, 1);
> >>  }
> >> 
> >
> > Can you explain what this is needed for? Most platform ports don't
> > do this any more.
> 
> Nope, I can't!  I'm not sure what the bcm2835 side of it does, and I was
> just replicating that for 2836.
> 
> Should it be removed from 2835, too?
> 

Hard to know. Does anything reference BCM2835_PERIPH_VIRT? Does it work
if you remove it?

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 5/9] ARM: BCM2836: Add io map initialization for bcm2836.

[Arnd Bergmann]

On Tuesday 21 April 2015 13:37:13 Eric Anholt wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
> 
> > On Tuesday 21 April 2015 11:09:52 Eric Anholt wrote:
> >> +static struct map_desc bcm2836_io_map __initdata = {
> >> +       .virtual = BCM2835_PERIPH_VIRT,
> >> +       .pfn = __phys_to_pfn(BCM2836_PERIPH_PHYS),
> >> +       .length = BCM2835_PERIPH_SIZE,
> >> +       .type = MT_DEVICE
> >> +};
> >> +
> >>  static void __init bcm2835_map_io(void)
> >>  {
> >> -       iotable_init(&io_map, 1);
> >> +       iotable_init(&bcm2835_io_map, 1);
> >> +}
> >> +
> >> +static void __init bcm2836_map_io(void)
> >> +{
> >> +       iotable_init(&bcm2836_io_map, 1);
> >>  }
> >> 
> >
> > Can you explain what this is needed for? Most platform ports don't
> > do this any more.
> 
> Nope, I can't!  I'm not sure what the bcm2835 side of it does, and I was
> just replicating that for 2836.
> 
> Should it be removed from 2835, too?
> 

Hard to know. Does anything reference BCM2835_PERIPH_VIRT? Does it work
if you remove it?

	Arnd

Re: [PATCH 5/9] ARM: BCM2836: Add io map initialization for bcm2836.

[Eric Anholt]

[-- Attachment #1: Type: text/plain, Size: 2043 bytes --]

Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> writes:

> On Tuesday 21 April 2015 13:37:13 Eric Anholt wrote:
>> Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> writes:
>> 
>> > On Tuesday 21 April 2015 11:09:52 Eric Anholt wrote:
>> >> +static struct map_desc bcm2836_io_map __initdata = {
>> >> +       .virtual = BCM2835_PERIPH_VIRT,
>> >> +       .pfn = __phys_to_pfn(BCM2836_PERIPH_PHYS),
>> >> +       .length = BCM2835_PERIPH_SIZE,
>> >> +       .type = MT_DEVICE
>> >> +};
>> >> +
>> >>  static void __init bcm2835_map_io(void)
>> >>  {
>> >> -       iotable_init(&io_map, 1);
>> >> +       iotable_init(&bcm2835_io_map, 1);
>> >> +}
>> >> +
>> >> +static void __init bcm2836_map_io(void)
>> >> +{
>> >> +       iotable_init(&bcm2836_io_map, 1);
>> >>  }
>> >> 
>> >
>> > Can you explain what this is needed for? Most platform ports don't
>> > do this any more.
>> 
>> Nope, I can't!  I'm not sure what the bcm2835 side of it does, and I was
>> just replicating that for 2836.
>> 
>> Should it be removed from 2835, too?
>> 
>
> Hard to know. Does anything reference BCM2835_PERIPH_VIRT? Does it work
> if you remove it?

Well, that's clear enough. It dies early with:

Uncompressing Linux... done, booting the kernel.
[    0.000000] Booting Linux on physical CPU 0xf00
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 4.0.0-rc1-v7+ (anholt@eliezer) (gcc version 4.9.2 ( 4.9.2-10) ) #487 SMP PREEMPT Tue Apr 21 15:58:29 PDT 2015
[    0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] Machine model: Raspberry Pi 2 Model B+
[    0.000000] bootconsole [earlycon0] enabled
[    0.000000] cma: Reserved 64 MiB at 0x37000000
[    0.000000] Memory policy: Data cache writealloc

(hung)

The only thing I see using this 0xf0000000 range is DEBUG_BCM2836's
serial stuff, though.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

[PATCH 5/9] ARM: BCM2836: Add io map initialization for bcm2836.

[Eric Anholt]

Arnd Bergmann <arnd@arndb.de> writes:

> On Tuesday 21 April 2015 13:37:13 Eric Anholt wrote:
>> Arnd Bergmann <arnd@arndb.de> writes:
>> 
>> > On Tuesday 21 April 2015 11:09:52 Eric Anholt wrote:
>> >> +static struct map_desc bcm2836_io_map __initdata = {
>> >> +       .virtual = BCM2835_PERIPH_VIRT,
>> >> +       .pfn = __phys_to_pfn(BCM2836_PERIPH_PHYS),
>> >> +       .length = BCM2835_PERIPH_SIZE,
>> >> +       .type = MT_DEVICE
>> >> +};
>> >> +
>> >>  static void __init bcm2835_map_io(void)
>> >>  {
>> >> -       iotable_init(&io_map, 1);
>> >> +       iotable_init(&bcm2835_io_map, 1);
>> >> +}
>> >> +
>> >> +static void __init bcm2836_map_io(void)
>> >> +{
>> >> +       iotable_init(&bcm2836_io_map, 1);
>> >>  }
>> >> 
>> >
>> > Can you explain what this is needed for? Most platform ports don't
>> > do this any more.
>> 
>> Nope, I can't!  I'm not sure what the bcm2835 side of it does, and I was
>> just replicating that for 2836.
>> 
>> Should it be removed from 2835, too?
>> 
>
> Hard to know. Does anything reference BCM2835_PERIPH_VIRT? Does it work
> if you remove it?

Well, that's clear enough. It dies early with:

Uncompressing Linux... done, booting the kernel.
[    0.000000] Booting Linux on physical CPU 0xf00
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 4.0.0-rc1-v7+ (anholt at eliezer) (gcc version 4.9.2 ( 4.9.2-10) ) #487 SMP PREEMPT Tue Apr 21 15:58:29 PDT 2015
[    0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] Machine model: Raspberry Pi 2 Model B+
[    0.000000] bootconsole [earlycon0] enabled
[    0.000000] cma: Reserved 64 MiB at 0x37000000
[    0.000000] Memory policy: Data cache writealloc

(hung)

The only thing I see using this 0xf0000000 range is DEBUG_BCM2836's
serial stuff, though.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150421/ed1c6e77/attachment.sig>

Re: [PATCH 5/9] ARM: BCM2836: Add io map initialization for bcm2836.

[Arnd Bergmann]

On Tuesday 21 April 2015 16:02:19 Eric Anholt wrote:
> > Hard to know. Does anything reference BCM2835_PERIPH_VIRT? Does it work
> > if you remove it?
> Well, that's clear enough. It dies early with:
> 
> Uncompressing Linux... done, booting the kernel.
> [    0.000000] Booting Linux on physical CPU 0xf00
> [    0.000000] Initializing cgroup subsys cpu
> [    0.000000] Initializing cgroup subsys cpuacct
> [    0.000000] Linux version 4.0.0-rc1-v7+ (anholt@eliezer) (gcc version 4.9.2 ( 4.9.2-10) ) #487 SMP PREEMPT Tue Apr 21 15:58:29 PDT 2015
> [    0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> [    0.000000] Machine model: Raspberry Pi 2 Model B+
> [    0.000000] bootconsole [earlycon0] enabled
> [    0.000000] cma: Reserved 64 MiB at 0x37000000
> [    0.000000] Memory policy: Data cache writealloc
> 
> (hung)
> 
> The only thing I see using this 0xf0000000 range is DEBUG_BCM2836's
> serial stuff, though.
> 

Ok. Just to be clear: by removing that mapping, I meant removing the
".map_io = bcm2835_map_io" line as well, so the default debug_ll_io_init()
function gets called. If you have a map_io function that does not call
debug_ll_io_init() or something equivalent, you cannot use DEBUG_LL.

It's possible that this mapping was just added for supporting DEBUG_LL,
using the default debug_ll_io_init() is a better way to do that.

	Arnd

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 5/9] ARM: BCM2836: Add io map initialization for bcm2836.

[Arnd Bergmann]

On Tuesday 21 April 2015 16:02:19 Eric Anholt wrote:
> > Hard to know. Does anything reference BCM2835_PERIPH_VIRT? Does it work
> > if you remove it?
> Well, that's clear enough. It dies early with:
> 
> Uncompressing Linux... done, booting the kernel.
> [    0.000000] Booting Linux on physical CPU 0xf00
> [    0.000000] Initializing cgroup subsys cpu
> [    0.000000] Initializing cgroup subsys cpuacct
> [    0.000000] Linux version 4.0.0-rc1-v7+ (anholt at eliezer) (gcc version 4.9.2 ( 4.9.2-10) ) #487 SMP PREEMPT Tue Apr 21 15:58:29 PDT 2015
> [    0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> [    0.000000] Machine model: Raspberry Pi 2 Model B+
> [    0.000000] bootconsole [earlycon0] enabled
> [    0.000000] cma: Reserved 64 MiB at 0x37000000
> [    0.000000] Memory policy: Data cache writealloc
> 
> (hung)
> 
> The only thing I see using this 0xf0000000 range is DEBUG_BCM2836's
> serial stuff, though.
> 

Ok. Just to be clear: by removing that mapping, I meant removing the
".map_io = bcm2835_map_io" line as well, so the default debug_ll_io_init()
function gets called. If you have a map_io function that does not call
debug_ll_io_init() or something equivalent, you cannot use DEBUG_LL.

It's possible that this mapping was just added for supporting DEBUG_LL,
using the default debug_ll_io_init() is a better way to do that.

	Arnd

Re: [PATCH 5/9] ARM: BCM2836: Add io map initialization for bcm2836.

[Arnd Bergmann]

On Tuesday 21 April 2015 11:09:52 Eric Anholt wrote:
> +
> +DT_MACHINE_START(BCM2836, "BCM2836")
> +       .map_io = bcm2836_map_io,
> +       .init_irq = irqchip_init,
> +       .init_machine = bcm2835_init,
> +       .restart = bcm2835_restart,
> +       .dt_compat = bcm2836_compat
> +MACHINE_END

I've just looked at the other callbacks you have here, and I think
it would be easy enough to remove them as well:

- .init_irq is already pointless, you can just remove the line here
  without any effect

- bcm2835_restart can be moved to the drivers/watchdog/bcm2835_wdt.c
  driver, which already knows the registers. Just use
  register_restart_handler() in its probe function, and perhaps add
  a 'select' statement to ensure that the driver is included in kernel
  builds

- I'm not completely sure about the plans for the clock handler, but
  no proper clock driver has surfaced so far, and the clocks could just
  all be declared in DT as fixed rate clocks.

  Is anyone working on a proper clk driver here?

- once bcm2835_restart is gone from bcm2835.c and the clocks are handled
  in DT, the bcm2835_init() function can be removed as well.

	Arnd

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 5/9] ARM: BCM2836: Add io map initialization for bcm2836.

[Arnd Bergmann]

On Tuesday 21 April 2015 11:09:52 Eric Anholt wrote:
> +
> +DT_MACHINE_START(BCM2836, "BCM2836")
> +       .map_io = bcm2836_map_io,
> +       .init_irq = irqchip_init,
> +       .init_machine = bcm2835_init,
> +       .restart = bcm2835_restart,
> +       .dt_compat = bcm2836_compat
> +MACHINE_END

I've just looked at the other callbacks you have here, and I think
it would be easy enough to remove them as well:

- .init_irq is already pointless, you can just remove the line here
  without any effect

- bcm2835_restart can be moved to the drivers/watchdog/bcm2835_wdt.c
  driver, which already knows the registers. Just use
  register_restart_handler() in its probe function, and perhaps add
  a 'select' statement to ensure that the driver is included in kernel
  builds

- I'm not completely sure about the plans for the clock handler, but
  no proper clock driver has surfaced so far, and the clocks could just
  all be declared in DT as fixed rate clocks.

  Is anyone working on a proper clk driver here?

- once bcm2835_restart is gone from bcm2835.c and the clocks are handled
  in DT, the bcm2835_init() function can be removed as well.

	Arnd

[PATCH 6/9] ARM: Make a Kconfig option for shared BCM2835/BCM2836 code.

[Eric Anholt]

The 2836 in the Raspberry Pi 2 is the same as the 2835 in terms of
peripherals, it's just the CPU implementation that has changed.  We
need a new ARCH_BCM2836 to handle the CPU change, so make a hidden
ARCH_BCM283X Kconfig option for the peripherals to depend on.

Signed-off-by: Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
---
 arch/arm/mach-bcm/Kconfig      | 7 +++++++
 arch/arm/mach-bcm/Makefile     | 4 ++--
 drivers/char/hw_random/Kconfig | 6 +++---
 drivers/clk/Makefile           | 2 +-
 drivers/clocksource/Makefile   | 2 +-
 drivers/dma/Kconfig            | 4 ++--
 drivers/i2c/busses/Kconfig     | 6 +++---
 drivers/irqchip/Makefile       | 2 +-
 drivers/mmc/host/Kconfig       | 6 +++---
 drivers/pwm/Kconfig            | 6 +++---
 drivers/spi/Kconfig            | 6 +++---
 drivers/watchdog/Kconfig       | 4 ++--
 sound/soc/bcm/Kconfig          | 6 +++---
 13 files changed, 34 insertions(+), 27 deletions(-)

diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index 8b11f44..7c438b2 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -107,8 +107,15 @@ config ARCH_BCM_MOBILE_SMP
 
 comment "Other Architectures"
 
+config ARCH_BCM283X
+	bool
+	help
+	  This option should be selected by the 2835 and 2836 chips to
+	  enable common platform features.
+
 config ARCH_BCM2835
 	bool "Broadcom BCM2835 family" if ARCH_MULTI_V6
+	select ARCH_BCM283X
 	select ARCH_REQUIRE_GPIOLIB
 	select ARM_AMBA
 	select ARM_ERRATA_411920
diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
index 4c38674..40f9dc1 100644
--- a/arch/arm/mach-bcm/Makefile
+++ b/arch/arm/mach-bcm/Makefile
@@ -31,8 +31,8 @@ ifeq ($(call as-instr,.arch_extension sec,as_has_sec),as_has_sec)
 CFLAGS_bcm_kona_smc.o		+= -Wa,-march=armv7-a+sec -DREQUIRES_SEC
 endif
 
-# BCM2835
-obj-$(CONFIG_ARCH_BCM2835)	+= board_bcm2835.o
+# BCM283x
+obj-$(CONFIG_ARCH_BCM283X)	+= board_bcm2835.o
 
 # BCM5301X
 obj-$(CONFIG_ARCH_BCM_5301X)	+= bcm_5301x.o
diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index de57b38..bfde6cf 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -89,12 +89,12 @@ config HW_RANDOM_BCM63XX
 	  If unusure, say Y.
 
 config HW_RANDOM_BCM2835
-	tristate "Broadcom BCM2835 Random Number Generator support"
-	depends on ARCH_BCM2835
+	tristate "Broadcom BCM283x Random Number Generator support"
+	depends on ARCH_BCM283X
 	default HW_RANDOM
 	---help---
 	  This driver provides kernel-side support for the Random Number
-	  Generator hardware found on the Broadcom BCM2835 SoCs.
+	  Generator hardware found on the Broadcom BCM283x SoCs.
 
 	  To compile this driver as a module, choose M here: the
 	  module will be called bcm2835-rng
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index d478ceb..8b8bd41 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -19,7 +19,7 @@ endif
 obj-$(CONFIG_MACH_ASM9260)		+= clk-asm9260.o
 obj-$(CONFIG_COMMON_CLK_AXI_CLKGEN)	+= clk-axi-clkgen.o
 obj-$(CONFIG_ARCH_AXXIA)		+= clk-axm5516.o
-obj-$(CONFIG_ARCH_BCM2835)		+= clk-bcm2835.o
+obj-$(CONFIG_ARCH_BCM283X)		+= clk-bcm2835.o
 obj-$(CONFIG_COMMON_CLK_CDCE706)	+= clk-cdce706.o
 obj-$(CONFIG_ARCH_CLPS711X)		+= clk-clps711x.o
 obj-$(CONFIG_ARCH_EFM32)		+= clk-efm32gg.o
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 752d5c7..e38a82d 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -18,7 +18,7 @@ obj-$(CONFIG_CLKSRC_NOMADIK_MTU)	+= nomadik-mtu.o
 obj-$(CONFIG_CLKSRC_DBX500_PRCMU)	+= clksrc-dbx500-prcmu.o
 obj-$(CONFIG_ARMADA_370_XP_TIMER)	+= time-armada-370-xp.o
 obj-$(CONFIG_ORION_TIMER)	+= time-orion.o
-obj-$(CONFIG_ARCH_BCM2835)	+= bcm2835_timer.o
+obj-$(CONFIG_ARCH_BCM283X)	+= bcm2835_timer.o
 obj-$(CONFIG_ARCH_CLPS711X)	+= clps711x-timer.o
 obj-$(CONFIG_ARCH_ATLAS7)	+= timer-atlas7.o
 obj-$(CONFIG_ARCH_MOXART)	+= moxart_timer.o
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index a874b6e..07d07db 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -332,8 +332,8 @@ config DMA_OMAP
 	select DMA_VIRTUAL_CHANNELS
 
 config DMA_BCM2835
-	tristate "BCM2835 DMA engine support"
-	depends on ARCH_BCM2835
+	tristate "BCM283x DMA engine support"
+	depends on ARCH_BCM283X
 	select DMA_ENGINE
 	select DMA_VIRTUAL_CHANNELS
 
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 22da9c2..215fe36 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -361,11 +361,11 @@ config I2C_AXXIA
 	  an error.
 
 config I2C_BCM2835
-	tristate "Broadcom BCM2835 I2C controller"
-	depends on ARCH_BCM2835
+	tristate "Broadcom BCM283x I2C controller"
+	depends on ARCH_BCM283X
 	help
 	  If you say yes to this option, support will be included for the
-	  BCM2835 I2C controller.
+	  BCM283x I2C controller.
 
 	  If you don't know what to do here, say N.
 
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 42965d2..b067923 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -1,6 +1,6 @@
 obj-$(CONFIG_IRQCHIP)			+= irqchip.o
 
-obj-$(CONFIG_ARCH_BCM2835)		+= irq-bcm2835.o
+obj-$(CONFIG_ARCH_BCM283X)		+= irq-bcm2835.o
 obj-$(CONFIG_ARCH_EXYNOS)		+= exynos-combiner.o
 obj-$(CONFIG_ARCH_HIP04)		+= irq-hip04.o
 obj-$(CONFIG_ARCH_MMP)			+= irq-mmp.o
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 61ac63a..fe7f879 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -286,12 +286,12 @@ config MMC_SDHCI_BCM_KONA
 	  If you have a controller with this interface, say Y or M here.
 
 config MMC_SDHCI_BCM2835
-	tristate "SDHCI platform support for the BCM2835 SD/MMC Controller"
-	depends on ARCH_BCM2835
+	tristate "SDHCI platform support for the BCM283x SD/MMC Controller"
+	depends on ARCH_BCM283X
 	depends on MMC_SDHCI_PLTFM
 	select MMC_SDHCI_IO_ACCESSORS
 	help
-	  This selects the BCM2835 SD/MMC controller. If you have a BCM2835
+	  This selects the BCM283x SD/MMC controller. If you have a BCM283x
 	  platform with SD or MMC devices, say Y or M here.
 
 	  If unsure, say N.
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index b1541f4..4989430 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -84,10 +84,10 @@ config PWM_BCM_KONA
 	  will be called pwm-bcm-kona.
 
 config PWM_BCM2835
-	tristate "BCM2835 PWM support"
-	depends on ARCH_BCM2835
+	tristate "BCM283x PWM support"
+	depends on ARCH_BCM283X
 	help
-	  PWM framework driver for BCM2835 controller (Raspberry Pi)
+	  PWM framework driver for BCM283x controller (Raspberry Pi)
 
 	  To compile this driver as a module, choose M here: the module
 	  will be called pwm-bcm2835.
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index ab8dfbe..3c26c6a 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -76,12 +76,12 @@ config SPI_ATMEL
 	  many AT32 (AVR32) and AT91 (ARM) chips.
 
 config SPI_BCM2835
-	tristate "BCM2835 SPI controller"
-	depends on ARCH_BCM2835 || COMPILE_TEST
+	tristate "BCM283x SPI controller"
+	depends on ARCH_BCM283X || COMPILE_TEST
 	help
 	  This selects a driver for the Broadcom BCM2835 SPI master.
 
-	  The BCM2835 contains two types of SPI master controller; the
+	  The BCM283x contains two types of SPI master controller; the
 	  "universal SPI master", and the regular SPI controller. This driver
 	  is for the regular SPI controller. Slave mode operation is not also
 	  not supported.
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 16f2023..5811dd6 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1216,11 +1216,11 @@ config BCM63XX_WDT
 
 config BCM2835_WDT
 	tristate "Broadcom BCM2835 hardware watchdog"
-	depends on ARCH_BCM2835
+	depends on ARCH_BCM283X
 	select WATCHDOG_CORE
 	help
 	  Watchdog driver for the built in watchdog hardware in Broadcom
-	  BCM2835 SoC.
+	  BCM283x SoC.
 
 	  To compile this driver as a loadable module, choose M here.
 	  The module will be called bcm2835_wdt.
diff --git a/sound/soc/bcm/Kconfig b/sound/soc/bcm/Kconfig
index 6a834e1..1d5d3c6 100644
--- a/sound/soc/bcm/Kconfig
+++ b/sound/soc/bcm/Kconfig
@@ -1,9 +1,9 @@
 config SND_BCM2835_SOC_I2S
-	tristate "SoC Audio support for the Broadcom BCM2835 I2S module"
-	depends on ARCH_BCM2835 || COMPILE_TEST
+	tristate "SoC Audio support for the Broadcom BCM283x I2S module"
+	depends on ARCH_BCM283X || COMPILE_TEST
 	select SND_SOC_GENERIC_DMAENGINE_PCM
 	select REGMAP_MMIO
 	help
 	  Say Y or M if you want to add support for codecs attached to
-	  the BCM2835 I2S interface. You will also need
+	  the BCM283x I2S interface. You will also need
 	  to select the audio interfaces to support below.
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 6/9] ARM: Make a Kconfig option for shared BCM2835/BCM2836 code.

[Eric Anholt]

The 2836 in the Raspberry Pi 2 is the same as the 2835 in terms of
peripherals, it's just the CPU implementation that has changed.  We
need a new ARCH_BCM2836 to handle the CPU change, so make a hidden
ARCH_BCM283X Kconfig option for the peripherals to depend on.

Signed-off-by: Eric Anholt <eric@anholt.net>
---
 arch/arm/mach-bcm/Kconfig      | 7 +++++++
 arch/arm/mach-bcm/Makefile     | 4 ++--
 drivers/char/hw_random/Kconfig | 6 +++---
 drivers/clk/Makefile           | 2 +-
 drivers/clocksource/Makefile   | 2 +-
 drivers/dma/Kconfig            | 4 ++--
 drivers/i2c/busses/Kconfig     | 6 +++---
 drivers/irqchip/Makefile       | 2 +-
 drivers/mmc/host/Kconfig       | 6 +++---
 drivers/pwm/Kconfig            | 6 +++---
 drivers/spi/Kconfig            | 6 +++---
 drivers/watchdog/Kconfig       | 4 ++--
 sound/soc/bcm/Kconfig          | 6 +++---
 13 files changed, 34 insertions(+), 27 deletions(-)

diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index 8b11f44..7c438b2 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -107,8 +107,15 @@ config ARCH_BCM_MOBILE_SMP
 
 comment "Other Architectures"
 
+config ARCH_BCM283X
+	bool
+	help
+	  This option should be selected by the 2835 and 2836 chips to
+	  enable common platform features.
+
 config ARCH_BCM2835
 	bool "Broadcom BCM2835 family" if ARCH_MULTI_V6
+	select ARCH_BCM283X
 	select ARCH_REQUIRE_GPIOLIB
 	select ARM_AMBA
 	select ARM_ERRATA_411920
diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
index 4c38674..40f9dc1 100644
--- a/arch/arm/mach-bcm/Makefile
+++ b/arch/arm/mach-bcm/Makefile
@@ -31,8 +31,8 @@ ifeq ($(call as-instr,.arch_extension sec,as_has_sec),as_has_sec)
 CFLAGS_bcm_kona_smc.o		+= -Wa,-march=armv7-a+sec -DREQUIRES_SEC
 endif
 
-# BCM2835
-obj-$(CONFIG_ARCH_BCM2835)	+= board_bcm2835.o
+# BCM283x
+obj-$(CONFIG_ARCH_BCM283X)	+= board_bcm2835.o
 
 # BCM5301X
 obj-$(CONFIG_ARCH_BCM_5301X)	+= bcm_5301x.o
diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index de57b38..bfde6cf 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -89,12 +89,12 @@ config HW_RANDOM_BCM63XX
 	  If unusure, say Y.
 
 config HW_RANDOM_BCM2835
-	tristate "Broadcom BCM2835 Random Number Generator support"
-	depends on ARCH_BCM2835
+	tristate "Broadcom BCM283x Random Number Generator support"
+	depends on ARCH_BCM283X
 	default HW_RANDOM
 	---help---
 	  This driver provides kernel-side support for the Random Number
-	  Generator hardware found on the Broadcom BCM2835 SoCs.
+	  Generator hardware found on the Broadcom BCM283x SoCs.
 
 	  To compile this driver as a module, choose M here: the
 	  module will be called bcm2835-rng
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index d478ceb..8b8bd41 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -19,7 +19,7 @@ endif
 obj-$(CONFIG_MACH_ASM9260)		+= clk-asm9260.o
 obj-$(CONFIG_COMMON_CLK_AXI_CLKGEN)	+= clk-axi-clkgen.o
 obj-$(CONFIG_ARCH_AXXIA)		+= clk-axm5516.o
-obj-$(CONFIG_ARCH_BCM2835)		+= clk-bcm2835.o
+obj-$(CONFIG_ARCH_BCM283X)		+= clk-bcm2835.o
 obj-$(CONFIG_COMMON_CLK_CDCE706)	+= clk-cdce706.o
 obj-$(CONFIG_ARCH_CLPS711X)		+= clk-clps711x.o
 obj-$(CONFIG_ARCH_EFM32)		+= clk-efm32gg.o
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 752d5c7..e38a82d 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -18,7 +18,7 @@ obj-$(CONFIG_CLKSRC_NOMADIK_MTU)	+= nomadik-mtu.o
 obj-$(CONFIG_CLKSRC_DBX500_PRCMU)	+= clksrc-dbx500-prcmu.o
 obj-$(CONFIG_ARMADA_370_XP_TIMER)	+= time-armada-370-xp.o
 obj-$(CONFIG_ORION_TIMER)	+= time-orion.o
-obj-$(CONFIG_ARCH_BCM2835)	+= bcm2835_timer.o
+obj-$(CONFIG_ARCH_BCM283X)	+= bcm2835_timer.o
 obj-$(CONFIG_ARCH_CLPS711X)	+= clps711x-timer.o
 obj-$(CONFIG_ARCH_ATLAS7)	+= timer-atlas7.o
 obj-$(CONFIG_ARCH_MOXART)	+= moxart_timer.o
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index a874b6e..07d07db 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -332,8 +332,8 @@ config DMA_OMAP
 	select DMA_VIRTUAL_CHANNELS
 
 config DMA_BCM2835
-	tristate "BCM2835 DMA engine support"
-	depends on ARCH_BCM2835
+	tristate "BCM283x DMA engine support"
+	depends on ARCH_BCM283X
 	select DMA_ENGINE
 	select DMA_VIRTUAL_CHANNELS
 
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 22da9c2..215fe36 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -361,11 +361,11 @@ config I2C_AXXIA
 	  an error.
 
 config I2C_BCM2835
-	tristate "Broadcom BCM2835 I2C controller"
-	depends on ARCH_BCM2835
+	tristate "Broadcom BCM283x I2C controller"
+	depends on ARCH_BCM283X
 	help
 	  If you say yes to this option, support will be included for the
-	  BCM2835 I2C controller.
+	  BCM283x I2C controller.
 
 	  If you don't know what to do here, say N.
 
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 42965d2..b067923 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -1,6 +1,6 @@
 obj-$(CONFIG_IRQCHIP)			+= irqchip.o
 
-obj-$(CONFIG_ARCH_BCM2835)		+= irq-bcm2835.o
+obj-$(CONFIG_ARCH_BCM283X)		+= irq-bcm2835.o
 obj-$(CONFIG_ARCH_EXYNOS)		+= exynos-combiner.o
 obj-$(CONFIG_ARCH_HIP04)		+= irq-hip04.o
 obj-$(CONFIG_ARCH_MMP)			+= irq-mmp.o
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 61ac63a..fe7f879 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -286,12 +286,12 @@ config MMC_SDHCI_BCM_KONA
 	  If you have a controller with this interface, say Y or M here.
 
 config MMC_SDHCI_BCM2835
-	tristate "SDHCI platform support for the BCM2835 SD/MMC Controller"
-	depends on ARCH_BCM2835
+	tristate "SDHCI platform support for the BCM283x SD/MMC Controller"
+	depends on ARCH_BCM283X
 	depends on MMC_SDHCI_PLTFM
 	select MMC_SDHCI_IO_ACCESSORS
 	help
-	  This selects the BCM2835 SD/MMC controller. If you have a BCM2835
+	  This selects the BCM283x SD/MMC controller. If you have a BCM283x
 	  platform with SD or MMC devices, say Y or M here.
 
 	  If unsure, say N.
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index b1541f4..4989430 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -84,10 +84,10 @@ config PWM_BCM_KONA
 	  will be called pwm-bcm-kona.
 
 config PWM_BCM2835
-	tristate "BCM2835 PWM support"
-	depends on ARCH_BCM2835
+	tristate "BCM283x PWM support"
+	depends on ARCH_BCM283X
 	help
-	  PWM framework driver for BCM2835 controller (Raspberry Pi)
+	  PWM framework driver for BCM283x controller (Raspberry Pi)
 
 	  To compile this driver as a module, choose M here: the module
 	  will be called pwm-bcm2835.
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index ab8dfbe..3c26c6a 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -76,12 +76,12 @@ config SPI_ATMEL
 	  many AT32 (AVR32) and AT91 (ARM) chips.
 
 config SPI_BCM2835
-	tristate "BCM2835 SPI controller"
-	depends on ARCH_BCM2835 || COMPILE_TEST
+	tristate "BCM283x SPI controller"
+	depends on ARCH_BCM283X || COMPILE_TEST
 	help
 	  This selects a driver for the Broadcom BCM2835 SPI master.
 
-	  The BCM2835 contains two types of SPI master controller; the
+	  The BCM283x contains two types of SPI master controller; the
 	  "universal SPI master", and the regular SPI controller. This driver
 	  is for the regular SPI controller. Slave mode operation is not also
 	  not supported.
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 16f2023..5811dd6 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1216,11 +1216,11 @@ config BCM63XX_WDT
 
 config BCM2835_WDT
 	tristate "Broadcom BCM2835 hardware watchdog"
-	depends on ARCH_BCM2835
+	depends on ARCH_BCM283X
 	select WATCHDOG_CORE
 	help
 	  Watchdog driver for the built in watchdog hardware in Broadcom
-	  BCM2835 SoC.
+	  BCM283x SoC.
 
 	  To compile this driver as a loadable module, choose M here.
 	  The module will be called bcm2835_wdt.
diff --git a/sound/soc/bcm/Kconfig b/sound/soc/bcm/Kconfig
index 6a834e1..1d5d3c6 100644
--- a/sound/soc/bcm/Kconfig
+++ b/sound/soc/bcm/Kconfig
@@ -1,9 +1,9 @@
 config SND_BCM2835_SOC_I2S
-	tristate "SoC Audio support for the Broadcom BCM2835 I2S module"
-	depends on ARCH_BCM2835 || COMPILE_TEST
+	tristate "SoC Audio support for the Broadcom BCM283x I2S module"
+	depends on ARCH_BCM283X || COMPILE_TEST
 	select SND_SOC_GENERIC_DMAENGINE_PCM
 	select REGMAP_MMIO
 	help
 	  Say Y or M if you want to add support for codecs attached to
-	  the BCM2835 I2S interface. You will also need
+	  the BCM283x I2S interface. You will also need
 	  to select the audio interfaces to support below.
-- 
2.1.4

[PATCH 7/9] ARM: Add Kconfig support for bcm2836.

[Eric Anholt]

This port to the Raspberry Pi 2 comes up with SD card and network
working.  It doesn't yet support SMP, the ARM local timer, or PMU
events, and serial is fixed in a follow-on patch.

Signed-off-by: Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
---
 arch/arm/Kconfig.debug     |  8 +++++++-
 arch/arm/boot/dts/Makefile |  2 ++
 arch/arm/mach-bcm/Kconfig  | 18 +++++++++++++-----
 3 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 970de75..7da2061 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -137,6 +137,11 @@ choice
 		depends on ARCH_BCM2835
 		select DEBUG_UART_PL01X
 
+	config DEBUG_BCM2836
+		bool "Kernel low-level debugging on BCM2836 PL011 UART"
+		depends on ARCH_BCM2836
+		select DEBUG_UART_PL01X
+
 	config DEBUG_BCM_5301X
 		bool "Kernel low-level debugging on BCM5301X UART1"
 		depends on ARCH_BCM_5301X
@@ -1369,6 +1374,7 @@ config DEBUG_UART_PHYS
 	default 0x20064000 if DEBUG_RK29_UART1 || DEBUG_RK3X_UART2
 	default 0x20068000 if DEBUG_RK29_UART2 || DEBUG_RK3X_UART3
 	default 0x20201000 if DEBUG_BCM2835
+	default 0x3f201000 if DEBUG_BCM2836
 	default 0x3e000000 if DEBUG_BCM_KONA_UART
 	default 0x4000e400 if DEBUG_LL_UART_EFM32
 	default 0x40090000 if ARCH_LPC32XX
@@ -1450,7 +1456,7 @@ config DEBUG_UART_VIRT
 	default 0xf0000be0 if ARCH_EBSA110
 	default 0xf0010000 if DEBUG_ASM9260_UART
 	default 0xf01fb000 if DEBUG_NOMADIK_UART
-	default 0xf0201000 if DEBUG_BCM2835
+	default 0xf0201000 if DEBUG_BCM2835 || DEBUG_BCM2836
 	default 0xf1000300 if DEBUG_BCM_5301X
 	default 0xf1002000 if DEBUG_MT8127_UART0
 	default 0xf1006000 if DEBUG_MT6589_UART0
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index a1c776b..72b476d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -52,6 +52,8 @@ dtb-$(CONFIG_ARCH_AXXIA) += \
 dtb-$(CONFIG_ARCH_BCM2835) += \
 	bcm2835-rpi-b.dtb \
 	bcm2835-rpi-b-plus.dtb
+dtb-$(CONFIG_ARCH_BCM2836) += \
+	bcm2836-rpi-2-b.dtb
 dtb-$(CONFIG_ARCH_BCM_5301X) += \
 	bcm4708-buffalo-wzr-1750dhp.dtb \
 	bcm4708-luxul-xwc-1000.dtb \
diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index 7c438b2..751ea08 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -109,6 +109,12 @@ comment "Other Architectures"
 
 config ARCH_BCM283X
 	bool
+	select ARCH_REQUIRE_GPIOLIB
+	select ARM_AMBA
+	select PINCTRL
+	select PINCTRL_BCM2835
+	select CLKSRC_OF
+	select CLKSRC_MMIO
 	help
 	  This option should be selected by the 2835 and 2836 chips to
 	  enable common platform features.
@@ -116,17 +122,19 @@ config ARCH_BCM283X
 config ARCH_BCM2835
 	bool "Broadcom BCM2835 family" if ARCH_MULTI_V6
 	select ARCH_BCM283X
-	select ARCH_REQUIRE_GPIOLIB
-	select ARM_AMBA
 	select ARM_ERRATA_411920
 	select ARM_TIMER_SP804
-	select CLKSRC_OF
-	select PINCTRL
-	select PINCTRL_BCM2835
 	help
 	  This enables support for the Broadcom BCM2835 SoC. This SoC is
 	  used in the Raspberry Pi and Roku 2 devices.
 
+config ARCH_BCM2836
+	bool "Broadcom BCM2836 family" if ARCH_MULTI_V7
+	select ARCH_BCM283X
+	help
+	  This enables support for the Broadcom BCM2836 SoC. This SoC is
+	  used in the Raspberry Pi 2
+
 config ARCH_BCM_63XX
 	bool "Broadcom BCM63xx DSL SoC" if ARCH_MULTI_V7
 	depends on MMU
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 7/9] ARM: Add Kconfig support for bcm2836.

[Eric Anholt]

This port to the Raspberry Pi 2 comes up with SD card and network
working.  It doesn't yet support SMP, the ARM local timer, or PMU
events, and serial is fixed in a follow-on patch.

Signed-off-by: Eric Anholt <eric@anholt.net>
---
 arch/arm/Kconfig.debug     |  8 +++++++-
 arch/arm/boot/dts/Makefile |  2 ++
 arch/arm/mach-bcm/Kconfig  | 18 +++++++++++++-----
 3 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 970de75..7da2061 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -137,6 +137,11 @@ choice
 		depends on ARCH_BCM2835
 		select DEBUG_UART_PL01X
 
+	config DEBUG_BCM2836
+		bool "Kernel low-level debugging on BCM2836 PL011 UART"
+		depends on ARCH_BCM2836
+		select DEBUG_UART_PL01X
+
 	config DEBUG_BCM_5301X
 		bool "Kernel low-level debugging on BCM5301X UART1"
 		depends on ARCH_BCM_5301X
@@ -1369,6 +1374,7 @@ config DEBUG_UART_PHYS
 	default 0x20064000 if DEBUG_RK29_UART1 || DEBUG_RK3X_UART2
 	default 0x20068000 if DEBUG_RK29_UART2 || DEBUG_RK3X_UART3
 	default 0x20201000 if DEBUG_BCM2835
+	default 0x3f201000 if DEBUG_BCM2836
 	default 0x3e000000 if DEBUG_BCM_KONA_UART
 	default 0x4000e400 if DEBUG_LL_UART_EFM32
 	default 0x40090000 if ARCH_LPC32XX
@@ -1450,7 +1456,7 @@ config DEBUG_UART_VIRT
 	default 0xf0000be0 if ARCH_EBSA110
 	default 0xf0010000 if DEBUG_ASM9260_UART
 	default 0xf01fb000 if DEBUG_NOMADIK_UART
-	default 0xf0201000 if DEBUG_BCM2835
+	default 0xf0201000 if DEBUG_BCM2835 || DEBUG_BCM2836
 	default 0xf1000300 if DEBUG_BCM_5301X
 	default 0xf1002000 if DEBUG_MT8127_UART0
 	default 0xf1006000 if DEBUG_MT6589_UART0
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index a1c776b..72b476d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -52,6 +52,8 @@ dtb-$(CONFIG_ARCH_AXXIA) += \
 dtb-$(CONFIG_ARCH_BCM2835) += \
 	bcm2835-rpi-b.dtb \
 	bcm2835-rpi-b-plus.dtb
+dtb-$(CONFIG_ARCH_BCM2836) += \
+	bcm2836-rpi-2-b.dtb
 dtb-$(CONFIG_ARCH_BCM_5301X) += \
 	bcm4708-buffalo-wzr-1750dhp.dtb \
 	bcm4708-luxul-xwc-1000.dtb \
diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index 7c438b2..751ea08 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -109,6 +109,12 @@ comment "Other Architectures"
 
 config ARCH_BCM283X
 	bool
+	select ARCH_REQUIRE_GPIOLIB
+	select ARM_AMBA
+	select PINCTRL
+	select PINCTRL_BCM2835
+	select CLKSRC_OF
+	select CLKSRC_MMIO
 	help
 	  This option should be selected by the 2835 and 2836 chips to
 	  enable common platform features.
@@ -116,17 +122,19 @@ config ARCH_BCM283X
 config ARCH_BCM2835
 	bool "Broadcom BCM2835 family" if ARCH_MULTI_V6
 	select ARCH_BCM283X
-	select ARCH_REQUIRE_GPIOLIB
-	select ARM_AMBA
 	select ARM_ERRATA_411920
 	select ARM_TIMER_SP804
-	select CLKSRC_OF
-	select PINCTRL
-	select PINCTRL_BCM2835
 	help
 	  This enables support for the Broadcom BCM2835 SoC. This SoC is
 	  used in the Raspberry Pi and Roku 2 devices.
 
+config ARCH_BCM2836
+	bool "Broadcom BCM2836 family" if ARCH_MULTI_V7
+	select ARCH_BCM283X
+	help
+	  This enables support for the Broadcom BCM2836 SoC. This SoC is
+	  used in the Raspberry Pi 2
+
 config ARCH_BCM_63XX
 	bool "Broadcom BCM63xx DSL SoC" if ARCH_MULTI_V7
 	depends on MMU
-- 
2.1.4

Re: [PATCH 7/9] ARM: Add Kconfig support for bcm2836.

[Arnd Bergmann]

On Tuesday 21 April 2015 11:09:54 Eric Anholt wrote:
> @@ -116,17 +122,19 @@ config ARCH_BCM283X
>  config ARCH_BCM2835
>         bool "Broadcom BCM2835 family" if ARCH_MULTI_V6
>         select ARCH_BCM283X
> -       select ARCH_REQUIRE_GPIOLIB
> -       select ARM_AMBA
>         select ARM_ERRATA_411920
>         select ARM_TIMER_SP804
> -       select CLKSRC_OF
> -       select PINCTRL
> -       select PINCTRL_BCM2835
>         help
>           This enables support for the Broadcom BCM2835 SoC. This SoC is
>           used in the Raspberry Pi and Roku 2 devices.
>  
> +config ARCH_BCM2836
> +       bool "Broadcom BCM2836 family" if ARCH_MULTI_V7
> +       select ARCH_BCM283X
> +       help
> +         This enables support for the Broadcom BCM2836 SoC. This SoC is
> +         used in the Raspberry Pi 2
> +

The description for the first one says "Broadcom BCM2835 family", and I
guess they are both in the same family. How about leaving the
CONFIG_BCM2835 symbol to mean one of them, and just duplicating the
DEBUG_LL symbols?

You could do something like

config ARCH_BCM2835
        bool "Broadcom BCM2835 family" if ARCH_MULTI_V6 || ARCH_MULTI_V7
        select ARCH_BCM283X
        select ARCH_REQUIRE_GPIOLIB
        select ARM_AMBA
        select ARM_ERRATA_411920 if ARCH_MULTI_V6
        select ARM_TIMER_SP804 if ARCH_MULTI_V6
        select CLKSRC_OF
        select PINCTRL
        select PINCTRL_BCM2835
        help
          This enables support for the Broadcom BCM2835 and BCM2836 SoCs.
	  These SoCs is used in the Raspberry Pi and Roku 2 devices.

That should make it less confusing to the user, because they don't have
to know which specific SoC they are building for, other than enabling
the right architecture level.

	Arnd

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 7/9] ARM: Add Kconfig support for bcm2836.

[Arnd Bergmann]

On Tuesday 21 April 2015 11:09:54 Eric Anholt wrote:
> @@ -116,17 +122,19 @@ config ARCH_BCM283X
>  config ARCH_BCM2835
>         bool "Broadcom BCM2835 family" if ARCH_MULTI_V6
>         select ARCH_BCM283X
> -       select ARCH_REQUIRE_GPIOLIB
> -       select ARM_AMBA
>         select ARM_ERRATA_411920
>         select ARM_TIMER_SP804
> -       select CLKSRC_OF
> -       select PINCTRL
> -       select PINCTRL_BCM2835
>         help
>           This enables support for the Broadcom BCM2835 SoC. This SoC is
>           used in the Raspberry Pi and Roku 2 devices.
>  
> +config ARCH_BCM2836
> +       bool "Broadcom BCM2836 family" if ARCH_MULTI_V7
> +       select ARCH_BCM283X
> +       help
> +         This enables support for the Broadcom BCM2836 SoC. This SoC is
> +         used in the Raspberry Pi 2
> +

The description for the first one says "Broadcom BCM2835 family", and I
guess they are both in the same family. How about leaving the
CONFIG_BCM2835 symbol to mean one of them, and just duplicating the
DEBUG_LL symbols?

You could do something like

config ARCH_BCM2835
        bool "Broadcom BCM2835 family" if ARCH_MULTI_V6 || ARCH_MULTI_V7
        select ARCH_BCM283X
        select ARCH_REQUIRE_GPIOLIB
        select ARM_AMBA
        select ARM_ERRATA_411920 if ARCH_MULTI_V6
        select ARM_TIMER_SP804 if ARCH_MULTI_V6
        select CLKSRC_OF
        select PINCTRL
        select PINCTRL_BCM2835
        help
          This enables support for the Broadcom BCM2835 and BCM2836 SoCs.
	  These SoCs is used in the Raspberry Pi and Roku 2 devices.

That should make it less confusing to the user, because they don't have
to know which specific SoC they are building for, other than enabling
the right architecture level.

	Arnd

Re: [PATCH 7/9] ARM: Add Kconfig support for bcm2836.

[Eric Anholt]

[-- Attachment #1: Type: text/plain, Size: 1994 bytes --]

Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> writes:

> On Tuesday 21 April 2015 11:09:54 Eric Anholt wrote:
>> @@ -116,17 +122,19 @@ config ARCH_BCM283X
>>  config ARCH_BCM2835
>>         bool "Broadcom BCM2835 family" if ARCH_MULTI_V6
>>         select ARCH_BCM283X
>> -       select ARCH_REQUIRE_GPIOLIB
>> -       select ARM_AMBA
>>         select ARM_ERRATA_411920
>>         select ARM_TIMER_SP804
>> -       select CLKSRC_OF
>> -       select PINCTRL
>> -       select PINCTRL_BCM2835
>>         help
>>           This enables support for the Broadcom BCM2835 SoC. This SoC is
>>           used in the Raspberry Pi and Roku 2 devices.
>>  
>> +config ARCH_BCM2836
>> +       bool "Broadcom BCM2836 family" if ARCH_MULTI_V7
>> +       select ARCH_BCM283X
>> +       help
>> +         This enables support for the Broadcom BCM2836 SoC. This SoC is
>> +         used in the Raspberry Pi 2
>> +
>
> The description for the first one says "Broadcom BCM2835 family", and I
> guess they are both in the same family. How about leaving the
> CONFIG_BCM2835 symbol to mean one of them, and just duplicating the
> DEBUG_LL symbols?
>
> You could do something like
>
> config ARCH_BCM2835
>         bool "Broadcom BCM2835 family" if ARCH_MULTI_V6 || ARCH_MULTI_V7
>         select ARCH_BCM283X
>         select ARCH_REQUIRE_GPIOLIB
>         select ARM_AMBA
>         select ARM_ERRATA_411920 if ARCH_MULTI_V6
>         select ARM_TIMER_SP804 if ARCH_MULTI_V6
>         select CLKSRC_OF
>         select PINCTRL
>         select PINCTRL_BCM2835
>         help
>           This enables support for the Broadcom BCM2835 and BCM2836 SoCs.
> 	  These SoCs is used in the Raspberry Pi and Roku 2 devices.
>
> That should make it less confusing to the user, because they don't have
> to know which specific SoC they are building for, other than enabling
> the right architecture level.

Seems reasonable to me.  What do the 2835 maintainers think?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

[PATCH 7/9] ARM: Add Kconfig support for bcm2836.

[Eric Anholt]

Arnd Bergmann <arnd@arndb.de> writes:

> On Tuesday 21 April 2015 11:09:54 Eric Anholt wrote:
>> @@ -116,17 +122,19 @@ config ARCH_BCM283X
>>  config ARCH_BCM2835
>>         bool "Broadcom BCM2835 family" if ARCH_MULTI_V6
>>         select ARCH_BCM283X
>> -       select ARCH_REQUIRE_GPIOLIB
>> -       select ARM_AMBA
>>         select ARM_ERRATA_411920
>>         select ARM_TIMER_SP804
>> -       select CLKSRC_OF
>> -       select PINCTRL
>> -       select PINCTRL_BCM2835
>>         help
>>           This enables support for the Broadcom BCM2835 SoC. This SoC is
>>           used in the Raspberry Pi and Roku 2 devices.
>>  
>> +config ARCH_BCM2836
>> +       bool "Broadcom BCM2836 family" if ARCH_MULTI_V7
>> +       select ARCH_BCM283X
>> +       help
>> +         This enables support for the Broadcom BCM2836 SoC. This SoC is
>> +         used in the Raspberry Pi 2
>> +
>
> The description for the first one says "Broadcom BCM2835 family", and I
> guess they are both in the same family. How about leaving the
> CONFIG_BCM2835 symbol to mean one of them, and just duplicating the
> DEBUG_LL symbols?
>
> You could do something like
>
> config ARCH_BCM2835
>         bool "Broadcom BCM2835 family" if ARCH_MULTI_V6 || ARCH_MULTI_V7
>         select ARCH_BCM283X
>         select ARCH_REQUIRE_GPIOLIB
>         select ARM_AMBA
>         select ARM_ERRATA_411920 if ARCH_MULTI_V6
>         select ARM_TIMER_SP804 if ARCH_MULTI_V6
>         select CLKSRC_OF
>         select PINCTRL
>         select PINCTRL_BCM2835
>         help
>           This enables support for the Broadcom BCM2835 and BCM2836 SoCs.
> 	  These SoCs is used in the Raspberry Pi and Roku 2 devices.
>
> That should make it less confusing to the user, because they don't have
> to know which specific SoC they are building for, other than enabling
> the right architecture level.

Seems reasonable to me.  What do the 2835 maintainers think?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150421/aaf0eb6e/attachment.sig>

Re: [PATCH 7/9] ARM: Add Kconfig support for bcm2836.

[Stephen Warren]

On 04/21/2015 02:38 PM, Eric Anholt wrote:
> Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> writes:
>> On Tuesday 21 April 2015 11:09:54 Eric Anholt wrote:
>>> @@ -116,17 +122,19 @@ config ARCH_BCM283X config ARCH_BCM2835 
>>> bool "Broadcom BCM2835 family" if ARCH_MULTI_V6 select
>>> ARCH_BCM283X -       select ARCH_REQUIRE_GPIOLIB -       select
>>> ARM_AMBA select ARM_ERRATA_411920 select ARM_TIMER_SP804 -
>>> select CLKSRC_OF -       select PINCTRL -       select
>>> PINCTRL_BCM2835 help This enables support for the Broadcom
>>> BCM2835 SoC. This SoC is used in the Raspberry Pi and Roku 2
>>> devices.
>>> 
>>> +config ARCH_BCM2836 +       bool "Broadcom BCM2836 family" if
>>> ARCH_MULTI_V7 +       select ARCH_BCM283X +       help +
>>> This enables support for the Broadcom BCM2836 SoC. This SoC is 
>>> +         used in the Raspberry Pi 2 +
>> 
>> The description for the first one says "Broadcom BCM2835 family",
>> and I guess they are both in the same family. How about leaving
>> the CONFIG_BCM2835 symbol to mean one of them, and just
>> duplicating the DEBUG_LL symbols?
>> 
>> You could do something like
>> 
>> config ARCH_BCM2835 bool "Broadcom BCM2835 family" if
>> ARCH_MULTI_V6 || ARCH_MULTI_V7 select ARCH_BCM283X select
>> ARCH_REQUIRE_GPIOLIB select ARM_AMBA select ARM_ERRATA_411920 if
>> ARCH_MULTI_V6 select ARM_TIMER_SP804 if ARCH_MULTI_V6 select
>> CLKSRC_OF select PINCTRL select PINCTRL_BCM2835 help This enables
>> support for the Broadcom BCM2835 and BCM2836 SoCs. These SoCs is
>> used in the Raspberry Pi and Roku 2 devices.
>> 
>> That should make it less confusing to the user, because they
>> don't have to know which specific SoC they are building for,
>> other than enabling the right architecture level.
> 
> Seems reasonable to me.  What do the 2835 maintainers think?

Yes, sounds reasonable to me.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 7/9] ARM: Add Kconfig support for bcm2836.

[Stephen Warren]

On 04/21/2015 02:38 PM, Eric Anholt wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
>> On Tuesday 21 April 2015 11:09:54 Eric Anholt wrote:
>>> @@ -116,17 +122,19 @@ config ARCH_BCM283X config ARCH_BCM2835 
>>> bool "Broadcom BCM2835 family" if ARCH_MULTI_V6 select
>>> ARCH_BCM283X -       select ARCH_REQUIRE_GPIOLIB -       select
>>> ARM_AMBA select ARM_ERRATA_411920 select ARM_TIMER_SP804 -
>>> select CLKSRC_OF -       select PINCTRL -       select
>>> PINCTRL_BCM2835 help This enables support for the Broadcom
>>> BCM2835 SoC. This SoC is used in the Raspberry Pi and Roku 2
>>> devices.
>>> 
>>> +config ARCH_BCM2836 +       bool "Broadcom BCM2836 family" if
>>> ARCH_MULTI_V7 +       select ARCH_BCM283X +       help +
>>> This enables support for the Broadcom BCM2836 SoC. This SoC is 
>>> +         used in the Raspberry Pi 2 +
>> 
>> The description for the first one says "Broadcom BCM2835 family",
>> and I guess they are both in the same family. How about leaving
>> the CONFIG_BCM2835 symbol to mean one of them, and just
>> duplicating the DEBUG_LL symbols?
>> 
>> You could do something like
>> 
>> config ARCH_BCM2835 bool "Broadcom BCM2835 family" if
>> ARCH_MULTI_V6 || ARCH_MULTI_V7 select ARCH_BCM283X select
>> ARCH_REQUIRE_GPIOLIB select ARM_AMBA select ARM_ERRATA_411920 if
>> ARCH_MULTI_V6 select ARM_TIMER_SP804 if ARCH_MULTI_V6 select
>> CLKSRC_OF select PINCTRL select PINCTRL_BCM2835 help This enables
>> support for the Broadcom BCM2835 and BCM2836 SoCs. These SoCs is
>> used in the Raspberry Pi and Roku 2 devices.
>> 
>> That should make it less confusing to the user, because they
>> don't have to know which specific SoC they are building for,
>> other than enabling the right architecture level.
> 
> Seems reasonable to me.  What do the 2835 maintainers think?

Yes, sounds reasonable to me.

[PATCH 8/9] ARM: Add MAINTAINERS for 2836.

[Eric Anholt]

Signed-off-by: Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
---
 MAINTAINERS | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index ddc5a8c..1e3f1f1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2128,6 +2128,13 @@ T:	git git://git.kernel.org/pub/scm/linux/kernel/git/rpi/linux-rpi.git
 S:	Maintained
 N:	bcm2835
 
+BROADCOM BCM2836 ARM ARCHITECTURE
+M:	Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
+L:	linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org (moderated for non-subscribers)
+T:	git git://git.kernel.org/pub/scm/linux/kernel/git/rpi/linux-rpi.git
+S:	Maintained
+N:	bcm2836
+
 BROADCOM BCM33XX MIPS ARCHITECTURE
 M:	Kevin Cernekee <cernekee-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
 L:	linux-mips-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 8/9] ARM: Add MAINTAINERS for 2836.

[Eric Anholt]

Signed-off-by: Eric Anholt <eric@anholt.net>
---
 MAINTAINERS | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index ddc5a8c..1e3f1f1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2128,6 +2128,13 @@ T:	git git://git.kernel.org/pub/scm/linux/kernel/git/rpi/linux-rpi.git
 S:	Maintained
 N:	bcm2835
 
+BROADCOM BCM2836 ARM ARCHITECTURE
+M:	Eric Anholt <eric@anholt.net>
+L:	linux-rpi-kernel at lists.infradead.org (moderated for non-subscribers)
+T:	git git://git.kernel.org/pub/scm/linux/kernel/git/rpi/linux-rpi.git
+S:	Maintained
+N:	bcm2836
+
 BROADCOM BCM33XX MIPS ARCHITECTURE
 M:	Kevin Cernekee <cernekee@gmail.com>
 L:	linux-mips at linux-mips.org
-- 
2.1.4

Re: [PATCH 8/9] ARM: Add MAINTAINERS for 2836.

[Stephen Warren]

On 04/21/2015 12:09 PM, Eric Anholt wrote:

> diff --git a/MAINTAINERS b/MAINTAINERS

> +BROADCOM BCM2836 ARM ARCHITECTURE
> +M:	Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
> +L:	linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org (moderated for non-subscribers)
> +T:	git git://git.kernel.org/pub/scm/linux/kernel/git/rpi/linux-rpi.git
> +S:	Maintained
> +N:	bcm2836

I'm tempted to suggest just adding this to the existing bcm2835 entry,
since they're almost the same SoC.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 8/9] ARM: Add MAINTAINERS for 2836.

[Stephen Warren]

On 04/21/2015 12:09 PM, Eric Anholt wrote:

> diff --git a/MAINTAINERS b/MAINTAINERS

> +BROADCOM BCM2836 ARM ARCHITECTURE
> +M:	Eric Anholt <eric@anholt.net>
> +L:	linux-rpi-kernel at lists.infradead.org (moderated for non-subscribers)
> +T:	git git://git.kernel.org/pub/scm/linux/kernel/git/rpi/linux-rpi.git
> +S:	Maintained
> +N:	bcm2836

I'm tempted to suggest just adding this to the existing bcm2835 entry,
since they're almost the same SoC.

Re: [PATCH 8/9] ARM: Add MAINTAINERS for 2836.

[Eric Anholt]

[-- Attachment #1: Type: text/plain, Size: 725 bytes --]

Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> writes:

> On 04/21/2015 12:09 PM, Eric Anholt wrote:
>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>
>> +BROADCOM BCM2836 ARM ARCHITECTURE
>> +M:	Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
>> +L:	linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org (moderated for non-subscribers)
>> +T:	git git://git.kernel.org/pub/scm/linux/kernel/git/rpi/linux-rpi.git
>> +S:	Maintained
>> +N:	bcm2836
>
> I'm tempted to suggest just adding this to the existing bcm2835 entry,
> since they're almost the same SoC.

Yeah, I'd started out with more changes and as the diff has kept
getting, I actually dropped the patch from my series yesterday.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

[PATCH 8/9] ARM: Add MAINTAINERS for 2836.

[Eric Anholt]

Stephen Warren <swarren@wwwdotorg.org> writes:

> On 04/21/2015 12:09 PM, Eric Anholt wrote:
>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>
>> +BROADCOM BCM2836 ARM ARCHITECTURE
>> +M:	Eric Anholt <eric@anholt.net>
>> +L:	linux-rpi-kernel at lists.infradead.org (moderated for non-subscribers)
>> +T:	git git://git.kernel.org/pub/scm/linux/kernel/git/rpi/linux-rpi.git
>> +S:	Maintained
>> +N:	bcm2836
>
> I'm tempted to suggest just adding this to the existing bcm2835 entry,
> since they're almost the same SoC.

Yeah, I'd started out with more changes and as the diff has kept
getting, I actually dropped the patch from my series yesterday.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150424/7521f899/attachment.sig>

[PATCH 9/9] ARM: BCM283x: Register fixed clocks for uart in the DT.

[Eric Anholt]

We were previously relying on the fixed clock registration in
clk-bcm2835, but there doesn't seem to be any real reason to not just
define it in the DT (and for the 2836 port, I would have needed to
change the clock's physical address in clk-bcm2835.c).  Also, because
we weren't registering the apb_pclk in clk-bcm2835 as a clock device,
we were picking up the uart clock node as apb_pclk by accident.

This gets serial working on 2836.

Signed-off-by: Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
---
 arch/arm/boot/dts/bcm283x-common.dtsi | 17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/bcm283x-common.dtsi b/arch/arm/boot/dts/bcm283x-common.dtsi
index c15e309..2ce6661 100644
--- a/arch/arm/boot/dts/bcm283x-common.dtsi
+++ b/arch/arm/boot/dts/bcm283x-common.dtsi
@@ -67,8 +67,9 @@
 			compatible = "brcm,bcm2835-pl011", "arm,pl011", "arm,primecell";
 			reg = <0x7e201000 0x1000>;
 			interrupts = <2 25>;
-			clock-frequency = <3000000>;
 			arm,primecell-periphid = <0x00241011>;
+			clocks = <&uart0_clk>, <&apb_pclk>;
+			clock-names = "uartclk", "apb_pclk";
 		};
 
 		i2s: i2s@7e203000 {
@@ -155,5 +156,19 @@
 			clock-output-names = "spi";
 			clock-frequency = <250000000>;
 		};
+
+		apb_pclk: apb_pclk {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-output-names = "apb_pclk";
+			clock-frequency = <126000000>;
+		};
+
+		uart0_clk: uart0_clk {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-output-names = "uart0_clk";
+			clock-frequency = <3000000>;
+		};
 	};
 };
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 9/9] ARM: BCM283x: Register fixed clocks for uart in the DT.

[Eric Anholt]

We were previously relying on the fixed clock registration in
clk-bcm2835, but there doesn't seem to be any real reason to not just
define it in the DT (and for the 2836 port, I would have needed to
change the clock's physical address in clk-bcm2835.c).  Also, because
we weren't registering the apb_pclk in clk-bcm2835 as a clock device,
we were picking up the uart clock node as apb_pclk by accident.

This gets serial working on 2836.

Signed-off-by: Eric Anholt <eric@anholt.net>
---
 arch/arm/boot/dts/bcm283x-common.dtsi | 17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/bcm283x-common.dtsi b/arch/arm/boot/dts/bcm283x-common.dtsi
index c15e309..2ce6661 100644
--- a/arch/arm/boot/dts/bcm283x-common.dtsi
+++ b/arch/arm/boot/dts/bcm283x-common.dtsi
@@ -67,8 +67,9 @@
 			compatible = "brcm,bcm2835-pl011", "arm,pl011", "arm,primecell";
 			reg = <0x7e201000 0x1000>;
 			interrupts = <2 25>;
-			clock-frequency = <3000000>;
 			arm,primecell-periphid = <0x00241011>;
+			clocks = <&uart0_clk>, <&apb_pclk>;
+			clock-names = "uartclk", "apb_pclk";
 		};
 
 		i2s: i2s at 7e203000 {
@@ -155,5 +156,19 @@
 			clock-output-names = "spi";
 			clock-frequency = <250000000>;
 		};
+
+		apb_pclk: apb_pclk {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-output-names = "apb_pclk";
+			clock-frequency = <126000000>;
+		};
+
+		uart0_clk: uart0_clk {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-output-names = "uart0_clk";
+			clock-frequency = <3000000>;
+		};
 	};
 };
-- 
2.1.4

Re: [PATCH 9/9] ARM: BCM283x: Register fixed clocks for uart in the DT.

[Stephen Warren]

On 04/21/2015 12:09 PM, Eric Anholt wrote:
> We were previously relying on the fixed clock registration in
> clk-bcm2835, but there doesn't seem to be any real reason to not just
> define it in the DT (and for the 2836 port, I would have needed to
> change the clock's physical address in clk-bcm2835.c).  Also, because
> we weren't registering the apb_pclk in clk-bcm2835 as a clock device,
> we were picking up the uart clock node as apb_pclk by accident.

Doesn't the following do just that?

clk = clk_register_fixed_rate(NULL, "apb_pclk", NULL, CLK_IS_ROOT,
                              126000000);

Anyway, with this patch, shouldn't we fix drivers/clk/clk-bcm2835.c not
to register clocks that match those that are added to DT in this patch?
Actually, to maintain DT ABI (new kernels working with old or new DT),
we probably need to keep the code in clk-bcm2835.c, but make it
conditional upon whether there's a clock node in the DT file.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 9/9] ARM: BCM283x: Register fixed clocks for uart in the DT.

[Stephen Warren]

On 04/21/2015 12:09 PM, Eric Anholt wrote:
> We were previously relying on the fixed clock registration in
> clk-bcm2835, but there doesn't seem to be any real reason to not just
> define it in the DT (and for the 2836 port, I would have needed to
> change the clock's physical address in clk-bcm2835.c).  Also, because
> we weren't registering the apb_pclk in clk-bcm2835 as a clock device,
> we were picking up the uart clock node as apb_pclk by accident.

Doesn't the following do just that?

clk = clk_register_fixed_rate(NULL, "apb_pclk", NULL, CLK_IS_ROOT,
                              126000000);

Anyway, with this patch, shouldn't we fix drivers/clk/clk-bcm2835.c not
to register clocks that match those that are added to DT in this patch?
Actually, to maintain DT ABI (new kernels working with old or new DT),
we probably need to keep the code in clk-bcm2835.c, but make it
conditional upon whether there's a clock node in the DT file.

Re: [PATCH 9/9] ARM: BCM283x: Register fixed clocks for uart in the DT.

[Eric Anholt]

[-- Attachment #1: Type: text/plain, Size: 1201 bytes --]

Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> writes:

> On 04/21/2015 12:09 PM, Eric Anholt wrote:
>> We were previously relying on the fixed clock registration in
>> clk-bcm2835, but there doesn't seem to be any real reason to not just
>> define it in the DT (and for the 2836 port, I would have needed to
>> change the clock's physical address in clk-bcm2835.c).  Also, because
>> we weren't registering the apb_pclk in clk-bcm2835 as a clock device,
>> we were picking up the uart clock node as apb_pclk by accident.
>
> Doesn't the following do just that?
>
> clk = clk_register_fixed_rate(NULL, "apb_pclk", NULL, CLK_IS_ROOT,
>                               126000000);

Nope!  You also need the clk_register_clkdev for the type of lookup
being done by APB to find it.

> Anyway, with this patch, shouldn't we fix drivers/clk/clk-bcm2835.c not
> to register clocks that match those that are added to DT in this patch?
> Actually, to maintain DT ABI (new kernels working with old or new DT),
> we probably need to keep the code in clk-bcm2835.c, but make it
> conditional upon whether there's a clock node in the DT file.

Yeah, I hadn't modified the .c code because of DT ABI

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

[PATCH 9/9] ARM: BCM283x: Register fixed clocks for uart in the DT.

[Eric Anholt]

Stephen Warren <swarren@wwwdotorg.org> writes:

> On 04/21/2015 12:09 PM, Eric Anholt wrote:
>> We were previously relying on the fixed clock registration in
>> clk-bcm2835, but there doesn't seem to be any real reason to not just
>> define it in the DT (and for the 2836 port, I would have needed to
>> change the clock's physical address in clk-bcm2835.c).  Also, because
>> we weren't registering the apb_pclk in clk-bcm2835 as a clock device,
>> we were picking up the uart clock node as apb_pclk by accident.
>
> Doesn't the following do just that?
>
> clk = clk_register_fixed_rate(NULL, "apb_pclk", NULL, CLK_IS_ROOT,
>                               126000000);

Nope!  You also need the clk_register_clkdev for the type of lookup
being done by APB to find it.

> Anyway, with this patch, shouldn't we fix drivers/clk/clk-bcm2835.c not
> to register clocks that match those that are added to DT in this patch?
> Actually, to maintain DT ABI (new kernels working with old or new DT),
> we probably need to keep the code in clk-bcm2835.c, but make it
> conditional upon whether there's a clock node in the DT file.

Yeah, I hadn't modified the .c code because of DT ABI
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150424/388d1819/attachment.sig>

Re: [PATCH 9/9] ARM: BCM283x: Register fixed clocks for uart in the DT.

[Stephen Warren]

On 04/24/2015 11:06 AM, Eric Anholt wrote:
> Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> writes:
> 
>> On 04/21/2015 12:09 PM, Eric Anholt wrote:
>>> We were previously relying on the fixed clock registration in 
>>> clk-bcm2835, but there doesn't seem to be any real reason to
>>> not just define it in the DT (and for the 2836 port, I would
>>> have needed to change the clock's physical address in
>>> clk-bcm2835.c).  Also, because we weren't registering the
>>> apb_pclk in clk-bcm2835 as a clock device, we were picking up
>>> the uart clock node as apb_pclk by accident.
>> 
>> Doesn't the following do just that?
>> 
>> clk = clk_register_fixed_rate(NULL, "apb_pclk", NULL,
>> CLK_IS_ROOT, 126000000);
> 
> Nope!  You also need the clk_register_clkdev for the type of
> lookup being done by APB to find it.

Oh right, that just creates a clock object without registering it in
the lookup table?

>> Anyway, with this patch, shouldn't we fix
>> drivers/clk/clk-bcm2835.c not to register clocks that match those
>> that are added to DT in this patch? Actually, to maintain DT ABI
>> (new kernels working with old or new DT), we probably need to
>> keep the code in clk-bcm2835.c, but make it conditional upon
>> whether there's a clock node in the DT file.
> 
> Yeah, I hadn't modified the .c code because of DT ABI

Should the C file be modified not the create those clock objects if
the DT contains them?

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 9/9] ARM: BCM283x: Register fixed clocks for uart in the DT.

[Stephen Warren]

On 04/24/2015 11:06 AM, Eric Anholt wrote:
> Stephen Warren <swarren@wwwdotorg.org> writes:
> 
>> On 04/21/2015 12:09 PM, Eric Anholt wrote:
>>> We were previously relying on the fixed clock registration in 
>>> clk-bcm2835, but there doesn't seem to be any real reason to
>>> not just define it in the DT (and for the 2836 port, I would
>>> have needed to change the clock's physical address in
>>> clk-bcm2835.c).  Also, because we weren't registering the
>>> apb_pclk in clk-bcm2835 as a clock device, we were picking up
>>> the uart clock node as apb_pclk by accident.
>> 
>> Doesn't the following do just that?
>> 
>> clk = clk_register_fixed_rate(NULL, "apb_pclk", NULL,
>> CLK_IS_ROOT, 126000000);
> 
> Nope!  You also need the clk_register_clkdev for the type of
> lookup being done by APB to find it.

Oh right, that just creates a clock object without registering it in
the lookup table?

>> Anyway, with this patch, shouldn't we fix
>> drivers/clk/clk-bcm2835.c not to register clocks that match those
>> that are added to DT in this patch? Actually, to maintain DT ABI
>> (new kernels working with old or new DT), we probably need to
>> keep the code in clk-bcm2835.c, but make it conditional upon
>> whether there's a clock node in the DT file.
> 
> Yeah, I hadn't modified the .c code because of DT ABI

Should the C file be modified not the create those clock objects if
the DT contains them?

Re: BCM2836 (Raspberry Pi 2) port

[Stephen Warren]

On 04/21/2015 12:09 PM, Eric Anholt wrote:
> This is my first submission of a Raspberry Pi 2 port.  It can be found
> at https://github.com/anholt/linux/tree/bcm2836
> 
> I'm using the 2835 interrupt controller support, without adding the
> checks for ARM local interrupts first.  That means no support for IPIs
> (and thus no SMP), no PMU events, and no local timer (I'm using the
> same 2835 peripheral one).
> 
> It supports a similar featureset to Pi 1 at this point.  Serial and SD
> cards work.  Just one CPU supported.  USB (ethernet) works if you use
> U-Boot, or my mailbox series
> (https://github.com/anholt/linux/tree/bcm2836-mbox).

I can't quite get this to work. I think what's happening is that U-Boot
is over-writing the location of the code/data that the CPU1..3 pin loop
uses. Do you know what that address is so I can confirm that?

I suspect this because when I load the kernel/DT in U-Boot, or when I
jump to the kernel to boot it, I see lots of extra duplicated characters
on the UART, like all 4 CPUs are booting Linux. For example:

> Hit any key to stop autoboot:  0 
> U-Boot> setenv fdt_high fffffff
> U-Boot> boot
> switch to partitions #0, OK
> mmc0 is current device
> Scanning mmc 0:1...
> Found /extlinux/extlinux.conf
> Retrieving file: /extlinux/extlinux.conf
> reading /extlinux/extlinux.conf
> 429 bytes read in 18 ms (22.5 KiB/s)
> Boot menu
> 1:	Default kernel
> 2:	Backup kernel
> Enter choice: 1
> 1:	Default kernel
> Retrieving file: /extlinux/../zImage
> reading /extlinux/../zImage
> 3467376 bytes read in 1996 ms (1.7 MiB/s)
> append: earlyprintk loglevel=8 console=ttyAMA0 console=tty1 verbose rootwait root=/dev/mmcblk0p2 rw
> Retrieving file: /extlinux/../bcm2836-rpi-2-b.dtb
> reading /extlinux/../bcm2836-rpi-2-b.dtb  LLLiiinnnuuuxxx.........
> 
> 
> 
> 
> 
> 
> OOOuuuttt   ooofff   mmmeeemmmooorrryyy   wwwhhhiiillleee   aaallllllooocccaaatttiiinnnggg   ooouuutttpppuuuttt   bbbuuuffffffeeerrr
> 
>  -- System halted4572 bytes read in 33 ms (134.8 KiB/s)
> Kernel image @ 0x1000000 [ 0x000000 - 0x34e870 ]
> ## Flattened Device Tree blob at 02000000
>    Booting using the fdt blob at 0x2000000
>    Loading Device Tree to 0fffb000, end 0ffff1db ... OK
> 
> Starting kernel ...

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

BCM2836 (Raspberry Pi 2) port

[Stephen Warren]

On 04/21/2015 12:09 PM, Eric Anholt wrote:
> This is my first submission of a Raspberry Pi 2 port.  It can be found
> at https://github.com/anholt/linux/tree/bcm2836
> 
> I'm using the 2835 interrupt controller support, without adding the
> checks for ARM local interrupts first.  That means no support for IPIs
> (and thus no SMP), no PMU events, and no local timer (I'm using the
> same 2835 peripheral one).
> 
> It supports a similar featureset to Pi 1 at this point.  Serial and SD
> cards work.  Just one CPU supported.  USB (ethernet) works if you use
> U-Boot, or my mailbox series
> (https://github.com/anholt/linux/tree/bcm2836-mbox).

I can't quite get this to work. I think what's happening is that U-Boot
is over-writing the location of the code/data that the CPU1..3 pin loop
uses. Do you know what that address is so I can confirm that?

I suspect this because when I load the kernel/DT in U-Boot, or when I
jump to the kernel to boot it, I see lots of extra duplicated characters
on the UART, like all 4 CPUs are booting Linux. For example:

> Hit any key to stop autoboot:  0 
> U-Boot> setenv fdt_high fffffff
> U-Boot> boot
> switch to partitions #0, OK
> mmc0 is current device
> Scanning mmc 0:1...
> Found /extlinux/extlinux.conf
> Retrieving file: /extlinux/extlinux.conf
> reading /extlinux/extlinux.conf
> 429 bytes read in 18 ms (22.5 KiB/s)
> Boot menu
> 1:	Default kernel
> 2:	Backup kernel
> Enter choice: 1
> 1:	Default kernel
> Retrieving file: /extlinux/../zImage
> reading /extlinux/../zImage
> 3467376 bytes read in 1996 ms (1.7 MiB/s)
> append: earlyprintk loglevel=8 console=ttyAMA0 console=tty1 verbose rootwait root=/dev/mmcblk0p2 rw
> Retrieving file: /extlinux/../bcm2836-rpi-2-b.dtb
> reading /extlinux/../bcm2836-rpi-2-b.dtb  LLLiiinnnuuuxxx.........
> 
> 
> 
> 
> 
> 
> OOOuuuttt   ooofff   mmmeeemmmooorrryyy   wwwhhhiiillleee   aaallllllooocccaaatttiiinnnggg   ooouuutttpppuuuttt   bbbuuuffffffeeerrr
> 
>  -- System halted4572 bytes read in 33 ms (134.8 KiB/s)
> Kernel image @ 0x1000000 [ 0x000000 - 0x34e870 ]
> ## Flattened Device Tree blob at 02000000
>    Booting using the fdt blob at 0x2000000
>    Loading Device Tree to 0fffb000, end 0ffff1db ... OK
> 
> Starting kernel ...

Re: BCM2836 (Raspberry Pi 2) port

[Eric Anholt]

[-- Attachment #1: Type: text/plain, Size: 1623 bytes --]

Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> writes:

> On 04/21/2015 12:09 PM, Eric Anholt wrote:
>> This is my first submission of a Raspberry Pi 2 port.  It can be found
>> at https://github.com/anholt/linux/tree/bcm2836
>> 
>> I'm using the 2835 interrupt controller support, without adding the
>> checks for ARM local interrupts first.  That means no support for IPIs
>> (and thus no SMP), no PMU events, and no local timer (I'm using the
>> same 2835 peripheral one).
>> 
>> It supports a similar featureset to Pi 1 at this point.  Serial and SD
>> cards work.  Just one CPU supported.  USB (ethernet) works if you use
>> U-Boot, or my mailbox series
>> (https://github.com/anholt/linux/tree/bcm2836-mbox).
>
> I can't quite get this to work. I think what's happening is that U-Boot
> is over-writing the location of the code/data that the CPU1..3 pin loop
> uses. Do you know what that address is so I can confirm that?
>
> I suspect this because when I load the kernel/DT in U-Boot, or when I
> jump to the kernel to boot it, I see lots of extra duplicated characters
> on the UART, like all 4 CPUs are booting Linux. For example:

Oops, I was just extrapolating that U-Boot would work.  I've quit using
it because of the extra configuration work (particularly the compiled
text files for the boot scripts).

I haven't looked into how SMP works, because I don't have the interrupt
support necessary yet (bcm2836-irq branch for hacks in that direction).

And in further testing, the USB is actually not working and I'm not sure
what gave me the idea that it was.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

BCM2836 (Raspberry Pi 2) port

[Eric Anholt]

Stephen Warren <swarren@wwwdotorg.org> writes:

> On 04/21/2015 12:09 PM, Eric Anholt wrote:
>> This is my first submission of a Raspberry Pi 2 port.  It can be found
>> at https://github.com/anholt/linux/tree/bcm2836
>> 
>> I'm using the 2835 interrupt controller support, without adding the
>> checks for ARM local interrupts first.  That means no support for IPIs
>> (and thus no SMP), no PMU events, and no local timer (I'm using the
>> same 2835 peripheral one).
>> 
>> It supports a similar featureset to Pi 1 at this point.  Serial and SD
>> cards work.  Just one CPU supported.  USB (ethernet) works if you use
>> U-Boot, or my mailbox series
>> (https://github.com/anholt/linux/tree/bcm2836-mbox).
>
> I can't quite get this to work. I think what's happening is that U-Boot
> is over-writing the location of the code/data that the CPU1..3 pin loop
> uses. Do you know what that address is so I can confirm that?
>
> I suspect this because when I load the kernel/DT in U-Boot, or when I
> jump to the kernel to boot it, I see lots of extra duplicated characters
> on the UART, like all 4 CPUs are booting Linux. For example:

Oops, I was just extrapolating that U-Boot would work.  I've quit using
it because of the extra configuration work (particularly the compiled
text files for the boot scripts).

I haven't looked into how SMP works, because I don't have the interrupt
support necessary yet (bcm2836-irq branch for hacks in that direction).

And in further testing, the USB is actually not working and I'm not sure
what gave me the idea that it was.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150424/00df303a/attachment.sig>

Re: BCM2836 (Raspberry Pi 2) port

[Stephen Warren]

On 04/24/2015 12:41 PM, Eric Anholt wrote:
> Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> writes:
>
>> On 04/21/2015 12:09 PM, Eric Anholt wrote:
>>> This is my first submission of a Raspberry Pi 2 port.  It can be found
>>> at https://github.com/anholt/linux/tree/bcm2836
>>>
>>> I'm using the 2835 interrupt controller support, without adding the
>>> checks for ARM local interrupts first.  That means no support for IPIs
>>> (and thus no SMP), no PMU events, and no local timer (I'm using the
>>> same 2835 peripheral one).
>>>
>>> It supports a similar featureset to Pi 1 at this point.  Serial and SD
>>> cards work.  Just one CPU supported.  USB (ethernet) works if you use
>>> U-Boot, or my mailbox series
>>> (https://github.com/anholt/linux/tree/bcm2836-mbox).
>>
>> I can't quite get this to work. I think what's happening is that U-Boot
>> is over-writing the location of the code/data that the CPU1..3 pin loop
>> uses. Do you know what that address is so I can confirm that?
>>
>> I suspect this because when I load the kernel/DT in U-Boot, or when I
>> jump to the kernel to boot it, I see lots of extra duplicated characters
>> on the UART, like all 4 CPUs are booting Linux. For example:
>
> Oops, I was just extrapolating that U-Boot would work.  I've quit using
> it because of the extra configuration work (particularly the compiled
> text files for the boot scripts).

You don't need any compiled text files if you create an extlinux.conf 
rather than a boot.scr. extlinux.conf is plain text.

To boot without U-Boot: Could you say what's in your config.txt? I 
assume I can just copy the kernel zImage as kernel.img, and the DTB from 
the kernel build tree without renaming it?

> I haven't looked into how SMP works, because I don't have the interrupt
> support necessary yet (bcm2836-irq branch for hacks in that direction).
>
> And in further testing, the USB is actually not working and I'm not sure
> what gave me the idea that it was.

It might be intermittent depending on (GPU) cache content. We need to 
fix the kernel in a similar fashion to the following U-Boot commits:

> http://git.denx.de/?p=u-boot.git;a=commit;h=79340db7f1f676b8eb5911f4993ebedf27009c0b
ARM: bcm2835: implement phys_to_bus/bus_to_phys

> http://git.denx.de/?p=u-boot.git;a=commit;h=5c0beb5c58c86d2a6d12dee6330dc85554de5c60
usb: dwc2: use phys_to_bus/bus_to_phys

> http://git.denx.de/?p=u-boot.git;a=commit;h=122426d46e31391480c4b83b1003e4feca24d491
ARM: bcm2835: use phys_to_bus() for mbox
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

BCM2836 (Raspberry Pi 2) port

[Stephen Warren]

On 04/24/2015 12:41 PM, Eric Anholt wrote:
> Stephen Warren <swarren@wwwdotorg.org> writes:
>
>> On 04/21/2015 12:09 PM, Eric Anholt wrote:
>>> This is my first submission of a Raspberry Pi 2 port.  It can be found
>>> at https://github.com/anholt/linux/tree/bcm2836
>>>
>>> I'm using the 2835 interrupt controller support, without adding the
>>> checks for ARM local interrupts first.  That means no support for IPIs
>>> (and thus no SMP), no PMU events, and no local timer (I'm using the
>>> same 2835 peripheral one).
>>>
>>> It supports a similar featureset to Pi 1 at this point.  Serial and SD
>>> cards work.  Just one CPU supported.  USB (ethernet) works if you use
>>> U-Boot, or my mailbox series
>>> (https://github.com/anholt/linux/tree/bcm2836-mbox).
>>
>> I can't quite get this to work. I think what's happening is that U-Boot
>> is over-writing the location of the code/data that the CPU1..3 pin loop
>> uses. Do you know what that address is so I can confirm that?
>>
>> I suspect this because when I load the kernel/DT in U-Boot, or when I
>> jump to the kernel to boot it, I see lots of extra duplicated characters
>> on the UART, like all 4 CPUs are booting Linux. For example:
>
> Oops, I was just extrapolating that U-Boot would work.  I've quit using
> it because of the extra configuration work (particularly the compiled
> text files for the boot scripts).

You don't need any compiled text files if you create an extlinux.conf 
rather than a boot.scr. extlinux.conf is plain text.

To boot without U-Boot: Could you say what's in your config.txt? I 
assume I can just copy the kernel zImage as kernel.img, and the DTB from 
the kernel build tree without renaming it?

> I haven't looked into how SMP works, because I don't have the interrupt
> support necessary yet (bcm2836-irq branch for hacks in that direction).
>
> And in further testing, the USB is actually not working and I'm not sure
> what gave me the idea that it was.

It might be intermittent depending on (GPU) cache content. We need to 
fix the kernel in a similar fashion to the following U-Boot commits:

> http://git.denx.de/?p=u-boot.git;a=commit;h=79340db7f1f676b8eb5911f4993ebedf27009c0b
ARM: bcm2835: implement phys_to_bus/bus_to_phys

> http://git.denx.de/?p=u-boot.git;a=commit;h=5c0beb5c58c86d2a6d12dee6330dc85554de5c60
usb: dwc2: use phys_to_bus/bus_to_phys

> http://git.denx.de/?p=u-boot.git;a=commit;h=122426d46e31391480c4b83b1003e4feca24d491
ARM: bcm2835: use phys_to_bus() for mbox

Re: BCM2836 (Raspberry Pi 2) port

[Eric Anholt]

[-- Attachment #1: Type: text/plain, Size: 1951 bytes --]

Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> writes:

> On 04/24/2015 12:41 PM, Eric Anholt wrote:
>> Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> writes:
>>
>>> On 04/21/2015 12:09 PM, Eric Anholt wrote:
>>>> This is my first submission of a Raspberry Pi 2 port.  It can be found
>>>> at https://github.com/anholt/linux/tree/bcm2836
>>>>
>>>> I'm using the 2835 interrupt controller support, without adding the
>>>> checks for ARM local interrupts first.  That means no support for IPIs
>>>> (and thus no SMP), no PMU events, and no local timer (I'm using the
>>>> same 2835 peripheral one).
>>>>
>>>> It supports a similar featureset to Pi 1 at this point.  Serial and SD
>>>> cards work.  Just one CPU supported.  USB (ethernet) works if you use
>>>> U-Boot, or my mailbox series
>>>> (https://github.com/anholt/linux/tree/bcm2836-mbox).
>>>
>>> I can't quite get this to work. I think what's happening is that U-Boot
>>> is over-writing the location of the code/data that the CPU1..3 pin loop
>>> uses. Do you know what that address is so I can confirm that?
>>>
>>> I suspect this because when I load the kernel/DT in U-Boot, or when I
>>> jump to the kernel to boot it, I see lots of extra duplicated characters
>>> on the UART, like all 4 CPUs are booting Linux. For example:
>>
>> Oops, I was just extrapolating that U-Boot would work.  I've quit using
>> it because of the extra configuration work (particularly the compiled
>> text files for the boot scripts).
>
> You don't need any compiled text files if you create an extlinux.conf 
> rather than a boot.scr. extlinux.conf is plain text.
>
> To boot without U-Boot: Could you say what's in your config.txt? I 
> assume I can just copy the kernel zImage as kernel.img, and the DTB from 
> the kernel build tree without renaming it?

I've been explicitly naming the DTB in config.txt, haven't tested otherwise.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

BCM2836 (Raspberry Pi 2) port

[Eric Anholt]

Stephen Warren <swarren@wwwdotorg.org> writes:

> On 04/24/2015 12:41 PM, Eric Anholt wrote:
>> Stephen Warren <swarren@wwwdotorg.org> writes:
>>
>>> On 04/21/2015 12:09 PM, Eric Anholt wrote:
>>>> This is my first submission of a Raspberry Pi 2 port.  It can be found
>>>> at https://github.com/anholt/linux/tree/bcm2836
>>>>
>>>> I'm using the 2835 interrupt controller support, without adding the
>>>> checks for ARM local interrupts first.  That means no support for IPIs
>>>> (and thus no SMP), no PMU events, and no local timer (I'm using the
>>>> same 2835 peripheral one).
>>>>
>>>> It supports a similar featureset to Pi 1 at this point.  Serial and SD
>>>> cards work.  Just one CPU supported.  USB (ethernet) works if you use
>>>> U-Boot, or my mailbox series
>>>> (https://github.com/anholt/linux/tree/bcm2836-mbox).
>>>
>>> I can't quite get this to work. I think what's happening is that U-Boot
>>> is over-writing the location of the code/data that the CPU1..3 pin loop
>>> uses. Do you know what that address is so I can confirm that?
>>>
>>> I suspect this because when I load the kernel/DT in U-Boot, or when I
>>> jump to the kernel to boot it, I see lots of extra duplicated characters
>>> on the UART, like all 4 CPUs are booting Linux. For example:
>>
>> Oops, I was just extrapolating that U-Boot would work.  I've quit using
>> it because of the extra configuration work (particularly the compiled
>> text files for the boot scripts).
>
> You don't need any compiled text files if you create an extlinux.conf 
> rather than a boot.scr. extlinux.conf is plain text.
>
> To boot without U-Boot: Could you say what's in your config.txt? I 
> assume I can just copy the kernel zImage as kernel.img, and the DTB from 
> the kernel build tree without renaming it?

I've been explicitly naming the DTB in config.txt, haven't tested otherwise.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150427/e94deb73/attachment.sig>

Re: Re: BCM2836 (Raspberry Pi 2) port

[Alexander Stein]

On Thursday 23 April 2015, 22:25:08 wrote Stephen Warren:
> > Hit any key to stop autoboot:  0 
> > U-Boot> setenv fdt_high fffffff

Any specific reason to set fdt_high to fffffff?

Best regards,
Alexander

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

BCM2836 (Raspberry Pi 2) port

[Alexander Stein]

On Thursday 23 April 2015, 22:25:08 wrote Stephen Warren:
> > Hit any key to stop autoboot:  0 
> > U-Boot> setenv fdt_high fffffff

Any specific reason to set fdt_high to fffffff?

Best regards,
Alexander

Re: BCM2836 (Raspberry Pi 2) port

[Stephen Warren]

On 05/08/2015 10:14 AM, Alexander Stein wrote:
> On Thursday 23 April 2015, 22:25:08 wrote Stephen Warren:
>>> Hit any key to stop autoboot:  0 
>>> U-Boot> setenv fdt_high fffffff
> 
> Any specific reason to set fdt_high to fffffff?

Yes, it prevents U-Boot's annoying habit of moving the DTB from where it
was loaded to some other place. This was especially important in this
case since I was trying to find out exactly which piece of RAM being
over-written caused the issues I was seeing.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

BCM2836 (Raspberry Pi 2) port

[Stephen Warren]

On 05/08/2015 10:14 AM, Alexander Stein wrote:
> On Thursday 23 April 2015, 22:25:08 wrote Stephen Warren:
>>> Hit any key to stop autoboot:  0 
>>> U-Boot> setenv fdt_high fffffff
> 
> Any specific reason to set fdt_high to fffffff?

Yes, it prevents U-Boot's annoying habit of moving the DTB from where it
was loaded to some other place. This was especially important in this
case since I was trying to find out exactly which piece of RAM being
over-written caused the issues I was seeing.

Re: Re: BCM2836 (Raspberry Pi 2) port

[Alexander Stein]

On Monday 11 May 2015, 20:36:40 wrote Stephen Warren:
> On 05/08/2015 10:14 AM, Alexander Stein wrote:
> > On Thursday 23 April 2015, 22:25:08 wrote Stephen Warren:
> >>> Hit any key to stop autoboot:  0 
> >>> U-Boot> setenv fdt_high fffffff
> > 
> > Any specific reason to set fdt_high to fffffff?
> 
> Yes, it prevents U-Boot's annoying habit of moving the DTB from where it
> was loaded to some other place. This was especially important in this
> case since I was trying to find out exactly which piece of RAM being
> over-written caused the issues I was seeing.

Shouldn't this then be part of the default raspberry (2 only?) environment?

Regards,
Alexander

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

BCM2836 (Raspberry Pi 2) port

[Alexander Stein]

On Monday 11 May 2015, 20:36:40 wrote Stephen Warren:
> On 05/08/2015 10:14 AM, Alexander Stein wrote:
> > On Thursday 23 April 2015, 22:25:08 wrote Stephen Warren:
> >>> Hit any key to stop autoboot:  0 
> >>> U-Boot> setenv fdt_high fffffff
> > 
> > Any specific reason to set fdt_high to fffffff?
> 
> Yes, it prevents U-Boot's annoying habit of moving the DTB from where it
> was loaded to some other place. This was especially important in this
> case since I was trying to find out exactly which piece of RAM being
> over-written caused the issues I was seeing.

Shouldn't this then be part of the default raspberry (2 only?) environment?

Regards,
Alexander

Re: BCM2836 (Raspberry Pi 2) port

[Stephen Warren]

On 05/12/2015 09:39 AM, Alexander Stein wrote:
> On Monday 11 May 2015, 20:36:40 wrote Stephen Warren:
>> On 05/08/2015 10:14 AM, Alexander Stein wrote:
>>> On Thursday 23 April 2015, 22:25:08 wrote Stephen Warren:
>>>>> Hit any key to stop autoboot:  0
>>>>> U-Boot> setenv fdt_high fffffff
>>>
>>> Any specific reason to set fdt_high to fffffff?
>>
>> Yes, it prevents U-Boot's annoying habit of moving the DTB from where it
>> was loaded to some other place. This was especially important in this
>> case since I was trying to find out exactly which piece of RAM being
>> over-written caused the issues I was seeing.
>
> Shouldn't this then be part of the default raspberry (2 only?) environment?

Eventually yes. So far, nobody seems to know which areas of RAM are 
off-limits (presumably since the RAM is used as a CPU1..3 pen), so I was 
experimenting to try and find that out.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

BCM2836 (Raspberry Pi 2) port

[Stephen Warren]

On 05/12/2015 09:39 AM, Alexander Stein wrote:
> On Monday 11 May 2015, 20:36:40 wrote Stephen Warren:
>> On 05/08/2015 10:14 AM, Alexander Stein wrote:
>>> On Thursday 23 April 2015, 22:25:08 wrote Stephen Warren:
>>>>> Hit any key to stop autoboot:  0
>>>>> U-Boot> setenv fdt_high fffffff
>>>
>>> Any specific reason to set fdt_high to fffffff?
>>
>> Yes, it prevents U-Boot's annoying habit of moving the DTB from where it
>> was loaded to some other place. This was especially important in this
>> case since I was trying to find out exactly which piece of RAM being
>> over-written caused the issues I was seeing.
>
> Shouldn't this then be part of the default raspberry (2 only?) environment?

Eventually yes. So far, nobody seems to know which areas of RAM are 
off-limits (presumably since the RAM is used as a CPU1..3 pen), so I was 
experimenting to try and find that out.

Re: BCM2836 (Raspberry Pi 2) port

[Eric Anholt]

[-- Attachment #1: Type: text/plain, Size: 1108 bytes --]

Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> writes:

> On 05/12/2015 09:39 AM, Alexander Stein wrote:
>> On Monday 11 May 2015, 20:36:40 wrote Stephen Warren:
>>> On 05/08/2015 10:14 AM, Alexander Stein wrote:
>>>> On Thursday 23 April 2015, 22:25:08 wrote Stephen Warren:
>>>>>> Hit any key to stop autoboot:  0
>>>>>> U-Boot> setenv fdt_high fffffff
>>>>
>>>> Any specific reason to set fdt_high to fffffff?
>>>
>>> Yes, it prevents U-Boot's annoying habit of moving the DTB from where it
>>> was loaded to some other place. This was especially important in this
>>> case since I was trying to find out exactly which piece of RAM being
>>> over-written caused the issues I was seeing.
>>
>> Shouldn't this then be part of the default raspberry (2 only?) environment?
>
> Eventually yes. So far, nobody seems to know which areas of RAM are 
> off-limits (presumably since the RAM is used as a CPU1..3 pen), so I was 
> experimenting to try and find that out.

If I'm reading this right, the CPU1-3 pen is in the bottom 8k of memory
(actually much less than 8k).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

BCM2836 (Raspberry Pi 2) port

[Eric Anholt]

Stephen Warren <swarren@wwwdotorg.org> writes:

> On 05/12/2015 09:39 AM, Alexander Stein wrote:
>> On Monday 11 May 2015, 20:36:40 wrote Stephen Warren:
>>> On 05/08/2015 10:14 AM, Alexander Stein wrote:
>>>> On Thursday 23 April 2015, 22:25:08 wrote Stephen Warren:
>>>>>> Hit any key to stop autoboot:  0
>>>>>> U-Boot> setenv fdt_high fffffff
>>>>
>>>> Any specific reason to set fdt_high to fffffff?
>>>
>>> Yes, it prevents U-Boot's annoying habit of moving the DTB from where it
>>> was loaded to some other place. This was especially important in this
>>> case since I was trying to find out exactly which piece of RAM being
>>> over-written caused the issues I was seeing.
>>
>> Shouldn't this then be part of the default raspberry (2 only?) environment?
>
> Eventually yes. So far, nobody seems to know which areas of RAM are 
> off-limits (presumably since the RAM is used as a CPU1..3 pen), so I was 
> experimenting to try and find that out.

If I'm reading this right, the CPU1-3 pen is in the bottom 8k of memory
(actually much less than 8k).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150512/29738094/attachment.sig>

Re: BCM2836 (Raspberry Pi 2) port

[Stephen Warren]

On 05/12/2015 11:32 AM, Eric Anholt wrote:
> Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> writes:
>
>> On 05/12/2015 09:39 AM, Alexander Stein wrote:
>>> On Monday 11 May 2015, 20:36:40 wrote Stephen Warren:
>>>> On 05/08/2015 10:14 AM, Alexander Stein wrote:
>>>>> On Thursday 23 April 2015, 22:25:08 wrote Stephen Warren:
>>>>>>> Hit any key to stop autoboot:  0
>>>>>>> U-Boot> setenv fdt_high fffffff
>>>>>
>>>>> Any specific reason to set fdt_high to fffffff?
>>>>
>>>> Yes, it prevents U-Boot's annoying habit of moving the DTB from where it
>>>> was loaded to some other place. This was especially important in this
>>>> case since I was trying to find out exactly which piece of RAM being
>>>> over-written caused the issues I was seeing.
>>>
>>> Shouldn't this then be part of the default raspberry (2 only?) environment?
>>
>> Eventually yes. So far, nobody seems to know which areas of RAM are
>> off-limits (presumably since the RAM is used as a CPU1..3 pen), so I was
>> experimenting to try and find that out.
>
> If I'm reading this right, the CPU1-3 pen is in the bottom 8k of memory
> (actually much less than 8k).

Hmm. I wondered if that was the case. I don't think anything I was doing 
in U-Boot /should/ touch those pages, but there have been bugs before 
where some pointer was left at NULL, and some DM (U-Boot Device Model) 
code ended up putting structures in page 0 by mistake. Perhaps something 
like that has resurfaced. I'll try to find time to diff page 0 
before/after various U-Boot operations, and see if it's getting modified...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

BCM2836 (Raspberry Pi 2) port

[Stephen Warren]

On 05/12/2015 11:32 AM, Eric Anholt wrote:
> Stephen Warren <swarren@wwwdotorg.org> writes:
>
>> On 05/12/2015 09:39 AM, Alexander Stein wrote:
>>> On Monday 11 May 2015, 20:36:40 wrote Stephen Warren:
>>>> On 05/08/2015 10:14 AM, Alexander Stein wrote:
>>>>> On Thursday 23 April 2015, 22:25:08 wrote Stephen Warren:
>>>>>>> Hit any key to stop autoboot:  0
>>>>>>> U-Boot> setenv fdt_high fffffff
>>>>>
>>>>> Any specific reason to set fdt_high to fffffff?
>>>>
>>>> Yes, it prevents U-Boot's annoying habit of moving the DTB from where it
>>>> was loaded to some other place. This was especially important in this
>>>> case since I was trying to find out exactly which piece of RAM being
>>>> over-written caused the issues I was seeing.
>>>
>>> Shouldn't this then be part of the default raspberry (2 only?) environment?
>>
>> Eventually yes. So far, nobody seems to know which areas of RAM are
>> off-limits (presumably since the RAM is used as a CPU1..3 pen), so I was
>> experimenting to try and find that out.
>
> If I'm reading this right, the CPU1-3 pen is in the bottom 8k of memory
> (actually much less than 8k).

Hmm. I wondered if that was the case. I don't think anything I was doing 
in U-Boot /should/ touch those pages, but there have been bugs before 
where some pointer was left at NULL, and some DM (U-Boot Device Model) 
code ended up putting structures in page 0 by mistake. Perhaps something 
like that has resurfaced. I'll try to find time to diff page 0 
before/after various U-Boot operations, and see if it's getting modified...

Re: BCM2836 (Raspberry Pi 2) port

[Eric Anholt]

[-- Attachment #1: Type: text/plain, Size: 2040 bytes --]

Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> writes:

> On 05/12/2015 11:32 AM, Eric Anholt wrote:
>> Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> writes:
>>
>>> On 05/12/2015 09:39 AM, Alexander Stein wrote:
>>>> On Monday 11 May 2015, 20:36:40 wrote Stephen Warren:
>>>>> On 05/08/2015 10:14 AM, Alexander Stein wrote:
>>>>>> On Thursday 23 April 2015, 22:25:08 wrote Stephen Warren:
>>>>>>>> Hit any key to stop autoboot:  0
>>>>>>>> U-Boot> setenv fdt_high fffffff
>>>>>>
>>>>>> Any specific reason to set fdt_high to fffffff?
>>>>>
>>>>> Yes, it prevents U-Boot's annoying habit of moving the DTB from where it
>>>>> was loaded to some other place. This was especially important in this
>>>>> case since I was trying to find out exactly which piece of RAM being
>>>>> over-written caused the issues I was seeing.
>>>>
>>>> Shouldn't this then be part of the default raspberry (2 only?) environment?
>>>
>>> Eventually yes. So far, nobody seems to know which areas of RAM are
>>> off-limits (presumably since the RAM is used as a CPU1..3 pen), so I was
>>> experimenting to try and find that out.
>>
>> If I'm reading this right, the CPU1-3 pen is in the bottom 8k of memory
>> (actually much less than 8k).
>
> Hmm. I wondered if that was the case. I don't think anything I was doing 
> in U-Boot /should/ touch those pages, but there have been bugs before 
> where some pointer was left at NULL, and some DM (U-Boot Device Model) 
> code ended up putting structures in page 0 by mistake. Perhaps something 
> like that has resurfaced. I'll try to find time to diff page 0 
> before/after various U-Boot operations, and see if it's getting modified...

How about on the Linux side?  What's reserving that memory for us, if
anything?  Weird things happen if I put "ARM: bcm2836: Add a DT binding
for the ARM local registers." and "ARM: bcm2835: Use a syscon regmap to
set up timer frequency." before the SMP support in the bcm2836-smp tree
(init crashes).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

BCM2836 (Raspberry Pi 2) port

[Eric Anholt]

Stephen Warren <swarren@wwwdotorg.org> writes:

> On 05/12/2015 11:32 AM, Eric Anholt wrote:
>> Stephen Warren <swarren@wwwdotorg.org> writes:
>>
>>> On 05/12/2015 09:39 AM, Alexander Stein wrote:
>>>> On Monday 11 May 2015, 20:36:40 wrote Stephen Warren:
>>>>> On 05/08/2015 10:14 AM, Alexander Stein wrote:
>>>>>> On Thursday 23 April 2015, 22:25:08 wrote Stephen Warren:
>>>>>>>> Hit any key to stop autoboot:  0
>>>>>>>> U-Boot> setenv fdt_high fffffff
>>>>>>
>>>>>> Any specific reason to set fdt_high to fffffff?
>>>>>
>>>>> Yes, it prevents U-Boot's annoying habit of moving the DTB from where it
>>>>> was loaded to some other place. This was especially important in this
>>>>> case since I was trying to find out exactly which piece of RAM being
>>>>> over-written caused the issues I was seeing.
>>>>
>>>> Shouldn't this then be part of the default raspberry (2 only?) environment?
>>>
>>> Eventually yes. So far, nobody seems to know which areas of RAM are
>>> off-limits (presumably since the RAM is used as a CPU1..3 pen), so I was
>>> experimenting to try and find that out.
>>
>> If I'm reading this right, the CPU1-3 pen is in the bottom 8k of memory
>> (actually much less than 8k).
>
> Hmm. I wondered if that was the case. I don't think anything I was doing 
> in U-Boot /should/ touch those pages, but there have been bugs before 
> where some pointer was left at NULL, and some DM (U-Boot Device Model) 
> code ended up putting structures in page 0 by mistake. Perhaps something 
> like that has resurfaced. I'll try to find time to diff page 0 
> before/after various U-Boot operations, and see if it's getting modified...

How about on the Linux side?  What's reserving that memory for us, if
anything?  Weird things happen if I put "ARM: bcm2836: Add a DT binding
for the ARM local registers." and "ARM: bcm2835: Use a syscon regmap to
set up timer frequency." before the SMP support in the bcm2836-smp tree
(init crashes).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150513/fde762c7/attachment.sig>

Re: BCM2836 (Raspberry Pi 2) port

[Stephen Warren]

On 05/13/2015 11:46 AM, Eric Anholt wrote:
> Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> writes:
>
>> On 05/12/2015 11:32 AM, Eric Anholt wrote:
>>> Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> writes:
>>>
>>>> On 05/12/2015 09:39 AM, Alexander Stein wrote:
>>>>> On Monday 11 May 2015, 20:36:40 wrote Stephen Warren:
>>>>>> On 05/08/2015 10:14 AM, Alexander Stein wrote:
>>>>>>> On Thursday 23 April 2015, 22:25:08 wrote Stephen Warren:
>>>>>>>>> Hit any key to stop autoboot:  0
>>>>>>>>> U-Boot> setenv fdt_high fffffff
>>>>>>>
>>>>>>> Any specific reason to set fdt_high to fffffff?
>>>>>>
>>>>>> Yes, it prevents U-Boot's annoying habit of moving the DTB from where it
>>>>>> was loaded to some other place. This was especially important in this
>>>>>> case since I was trying to find out exactly which piece of RAM being
>>>>>> over-written caused the issues I was seeing.
>>>>>
>>>>> Shouldn't this then be part of the default raspberry (2 only?) environment?
>>>>
>>>> Eventually yes. So far, nobody seems to know which areas of RAM are
>>>> off-limits (presumably since the RAM is used as a CPU1..3 pen), so I was
>>>> experimenting to try and find that out.
>>>
>>> If I'm reading this right, the CPU1-3 pen is in the bottom 8k of memory
>>> (actually much less than 8k).
>>
>> Hmm. I wondered if that was the case. I don't think anything I was doing
>> in U-Boot /should/ touch those pages, but there have been bugs before
>> where some pointer was left at NULL, and some DM (U-Boot Device Model)
>> code ended up putting structures in page 0 by mistake. Perhaps something
>> like that has resurfaced. I'll try to find time to diff page 0
>> before/after various U-Boot operations, and see if it's getting modified...
>
> How about on the Linux side?  What's reserving that memory for us, if
> anything?

Likely nothing at present. I was starting to see what looked like 
SMP-pen-related issues just in U-Boot, before even attempting to boot a 
kernel at all. So, I didn't put any though into how to communicate this 
to the kernel.

>  Weird things happen if I put "ARM: bcm2836: Add a DT binding
> for the ARM local registers." and "ARM: bcm2835: Use a syscon regmap to
> set up timer frequency." before the SMP support in the bcm2836-smp tree
> (init crashes).

This issue would probably explain that; if the kernel just happens to 
allocate a physical page of RAM that overlaps the SMP pen memory.

A /memreserve/ in the DT would probably solve this. Adjusting the 
content of the /memory/reg property to remove the SMP pen would likely 
work too.

Is there no way to disable CPU1..n other than using an SMP pen in 
memory? If the CPUs simply weren't executing anything at all, but could 
be unblocked/powered-up/... later, that'd simplify life.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

BCM2836 (Raspberry Pi 2) port

[Stephen Warren]

On 05/13/2015 11:46 AM, Eric Anholt wrote:
> Stephen Warren <swarren@wwwdotorg.org> writes:
>
>> On 05/12/2015 11:32 AM, Eric Anholt wrote:
>>> Stephen Warren <swarren@wwwdotorg.org> writes:
>>>
>>>> On 05/12/2015 09:39 AM, Alexander Stein wrote:
>>>>> On Monday 11 May 2015, 20:36:40 wrote Stephen Warren:
>>>>>> On 05/08/2015 10:14 AM, Alexander Stein wrote:
>>>>>>> On Thursday 23 April 2015, 22:25:08 wrote Stephen Warren:
>>>>>>>>> Hit any key to stop autoboot:  0
>>>>>>>>> U-Boot> setenv fdt_high fffffff
>>>>>>>
>>>>>>> Any specific reason to set fdt_high to fffffff?
>>>>>>
>>>>>> Yes, it prevents U-Boot's annoying habit of moving the DTB from where it
>>>>>> was loaded to some other place. This was especially important in this
>>>>>> case since I was trying to find out exactly which piece of RAM being
>>>>>> over-written caused the issues I was seeing.
>>>>>
>>>>> Shouldn't this then be part of the default raspberry (2 only?) environment?
>>>>
>>>> Eventually yes. So far, nobody seems to know which areas of RAM are
>>>> off-limits (presumably since the RAM is used as a CPU1..3 pen), so I was
>>>> experimenting to try and find that out.
>>>
>>> If I'm reading this right, the CPU1-3 pen is in the bottom 8k of memory
>>> (actually much less than 8k).
>>
>> Hmm. I wondered if that was the case. I don't think anything I was doing
>> in U-Boot /should/ touch those pages, but there have been bugs before
>> where some pointer was left at NULL, and some DM (U-Boot Device Model)
>> code ended up putting structures in page 0 by mistake. Perhaps something
>> like that has resurfaced. I'll try to find time to diff page 0
>> before/after various U-Boot operations, and see if it's getting modified...
>
> How about on the Linux side?  What's reserving that memory for us, if
> anything?

Likely nothing at present. I was starting to see what looked like 
SMP-pen-related issues just in U-Boot, before even attempting to boot a 
kernel at all. So, I didn't put any though into how to communicate this 
to the kernel.

>  Weird things happen if I put "ARM: bcm2836: Add a DT binding
> for the ARM local registers." and "ARM: bcm2835: Use a syscon regmap to
> set up timer frequency." before the SMP support in the bcm2836-smp tree
> (init crashes).

This issue would probably explain that; if the kernel just happens to 
allocate a physical page of RAM that overlaps the SMP pen memory.

A /memreserve/ in the DT would probably solve this. Adjusting the 
content of the /memory/reg property to remove the SMP pen would likely 
work too.

Is there no way to disable CPU1..n other than using an SMP pen in 
memory? If the CPUs simply weren't executing anything at all, but could 
be unblocked/powered-up/... later, that'd simplify life.

Re: BCM2836 (Raspberry Pi 2) port

[Eric Anholt]

[-- Attachment #1: Type: text/plain, Size: 3149 bytes --]

Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> writes:

> On 05/13/2015 11:46 AM, Eric Anholt wrote:
>> Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> writes:
>>
>>> On 05/12/2015 11:32 AM, Eric Anholt wrote:
>>>> Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> writes:
>>>>
>>>>> On 05/12/2015 09:39 AM, Alexander Stein wrote:
>>>>>> On Monday 11 May 2015, 20:36:40 wrote Stephen Warren:
>>>>>>> On 05/08/2015 10:14 AM, Alexander Stein wrote:
>>>>>>>> On Thursday 23 April 2015, 22:25:08 wrote Stephen Warren:
>>>>>>>>>> Hit any key to stop autoboot:  0
>>>>>>>>>> U-Boot> setenv fdt_high fffffff
>>>>>>>>
>>>>>>>> Any specific reason to set fdt_high to fffffff?
>>>>>>>
>>>>>>> Yes, it prevents U-Boot's annoying habit of moving the DTB from where it
>>>>>>> was loaded to some other place. This was especially important in this
>>>>>>> case since I was trying to find out exactly which piece of RAM being
>>>>>>> over-written caused the issues I was seeing.
>>>>>>
>>>>>> Shouldn't this then be part of the default raspberry (2 only?) environment?
>>>>>
>>>>> Eventually yes. So far, nobody seems to know which areas of RAM are
>>>>> off-limits (presumably since the RAM is used as a CPU1..3 pen), so I was
>>>>> experimenting to try and find that out.
>>>>
>>>> If I'm reading this right, the CPU1-3 pen is in the bottom 8k of memory
>>>> (actually much less than 8k).
>>>
>>> Hmm. I wondered if that was the case. I don't think anything I was doing
>>> in U-Boot /should/ touch those pages, but there have been bugs before
>>> where some pointer was left at NULL, and some DM (U-Boot Device Model)
>>> code ended up putting structures in page 0 by mistake. Perhaps something
>>> like that has resurfaced. I'll try to find time to diff page 0
>>> before/after various U-Boot operations, and see if it's getting modified...
>>
>> How about on the Linux side?  What's reserving that memory for us, if
>> anything?
>
> Likely nothing at present. I was starting to see what looked like 
> SMP-pen-related issues just in U-Boot, before even attempting to boot a 
> kernel at all. So, I didn't put any though into how to communicate this 
> to the kernel.
>
>>  Weird things happen if I put "ARM: bcm2836: Add a DT binding
>> for the ARM local registers." and "ARM: bcm2835: Use a syscon regmap to
>> set up timer frequency." before the SMP support in the bcm2836-smp tree
>> (init crashes).
>
> This issue would probably explain that; if the kernel just happens to 
> allocate a physical page of RAM that overlaps the SMP pen memory.
>
> A /memreserve/ in the DT would probably solve this. Adjusting the 
> content of the /memory/reg property to remove the SMP pen would likely 
> work too.
>
> Is there no way to disable CPU1..n other than using an SMP pen in 
> memory? If the CPUs simply weren't executing anything at all, but could 
> be unblocked/powered-up/... later, that'd simplify life.

Not that I can see -- looks like they all come up the same way, then 1-3
fall into the pen and 0 continues on to do interesting things.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

BCM2836 (Raspberry Pi 2) port

[Eric Anholt]

Stephen Warren <swarren@wwwdotorg.org> writes:

> On 05/13/2015 11:46 AM, Eric Anholt wrote:
>> Stephen Warren <swarren@wwwdotorg.org> writes:
>>
>>> On 05/12/2015 11:32 AM, Eric Anholt wrote:
>>>> Stephen Warren <swarren@wwwdotorg.org> writes:
>>>>
>>>>> On 05/12/2015 09:39 AM, Alexander Stein wrote:
>>>>>> On Monday 11 May 2015, 20:36:40 wrote Stephen Warren:
>>>>>>> On 05/08/2015 10:14 AM, Alexander Stein wrote:
>>>>>>>> On Thursday 23 April 2015, 22:25:08 wrote Stephen Warren:
>>>>>>>>>> Hit any key to stop autoboot:  0
>>>>>>>>>> U-Boot> setenv fdt_high fffffff
>>>>>>>>
>>>>>>>> Any specific reason to set fdt_high to fffffff?
>>>>>>>
>>>>>>> Yes, it prevents U-Boot's annoying habit of moving the DTB from where it
>>>>>>> was loaded to some other place. This was especially important in this
>>>>>>> case since I was trying to find out exactly which piece of RAM being
>>>>>>> over-written caused the issues I was seeing.
>>>>>>
>>>>>> Shouldn't this then be part of the default raspberry (2 only?) environment?
>>>>>
>>>>> Eventually yes. So far, nobody seems to know which areas of RAM are
>>>>> off-limits (presumably since the RAM is used as a CPU1..3 pen), so I was
>>>>> experimenting to try and find that out.
>>>>
>>>> If I'm reading this right, the CPU1-3 pen is in the bottom 8k of memory
>>>> (actually much less than 8k).
>>>
>>> Hmm. I wondered if that was the case. I don't think anything I was doing
>>> in U-Boot /should/ touch those pages, but there have been bugs before
>>> where some pointer was left at NULL, and some DM (U-Boot Device Model)
>>> code ended up putting structures in page 0 by mistake. Perhaps something
>>> like that has resurfaced. I'll try to find time to diff page 0
>>> before/after various U-Boot operations, and see if it's getting modified...
>>
>> How about on the Linux side?  What's reserving that memory for us, if
>> anything?
>
> Likely nothing at present. I was starting to see what looked like 
> SMP-pen-related issues just in U-Boot, before even attempting to boot a 
> kernel at all. So, I didn't put any though into how to communicate this 
> to the kernel.
>
>>  Weird things happen if I put "ARM: bcm2836: Add a DT binding
>> for the ARM local registers." and "ARM: bcm2835: Use a syscon regmap to
>> set up timer frequency." before the SMP support in the bcm2836-smp tree
>> (init crashes).
>
> This issue would probably explain that; if the kernel just happens to 
> allocate a physical page of RAM that overlaps the SMP pen memory.
>
> A /memreserve/ in the DT would probably solve this. Adjusting the 
> content of the /memory/reg property to remove the SMP pen would likely 
> work too.
>
> Is there no way to disable CPU1..n other than using an SMP pen in 
> memory? If the CPUs simply weren't executing anything at all, but could 
> be unblocked/powered-up/... later, that'd simplify life.

Not that I can see -- looks like they all come up the same way, then 1-3
fall into the pen and 0 continues on to do interesting things.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150513/0840e7d8/attachment.sig>

Re: BCM2836 (Raspberry Pi 2) port

[Stephen Warren]

On 04/21/2015 12:09 PM, Eric Anholt wrote:
> This is my first submission of a Raspberry Pi 2 port.  It can be found
> at https://github.com/anholt/linux/tree/bcm2836
> 
> I'm using the 2835 interrupt controller support, without adding the
> checks for ARM local interrupts first.  That means no support for IPIs
> (and thus no SMP), no PMU events, and no local timer (I'm using the
> same 2835 peripheral one).
> 
> It supports a similar featureset to Pi 1 at this point.  Serial and SD
> cards work.  Just one CPU supported.  USB (ethernet) works if you use
> U-Boot, or my mailbox series
> (https://github.com/anholt/linux/tree/bcm2836-mbox).

Tested-by: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>

I applied the patches on top of korg's linux-rpi.git for-rpi-next,
resolved the io_map conflicts, and tested without U-Boot.

I'll try to work out why it doesn't work with U-Boot. I can't
immediately see anything in /proc/device-tree that indicates the RPi
firmware is modifying the DT that's passed to the kernel to exclude any
CPU1..3 spin tables, so either the kernel isn't hitting those purely by
luck, or I'm guessing wrong re: the issue with U-Boot.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

BCM2836 (Raspberry Pi 2) port

[Stephen Warren]

On 04/21/2015 12:09 PM, Eric Anholt wrote:
> This is my first submission of a Raspberry Pi 2 port.  It can be found
> at https://github.com/anholt/linux/tree/bcm2836
> 
> I'm using the 2835 interrupt controller support, without adding the
> checks for ARM local interrupts first.  That means no support for IPIs
> (and thus no SMP), no PMU events, and no local timer (I'm using the
> same 2835 peripheral one).
> 
> It supports a similar featureset to Pi 1 at this point.  Serial and SD
> cards work.  Just one CPU supported.  USB (ethernet) works if you use
> U-Boot, or my mailbox series
> (https://github.com/anholt/linux/tree/bcm2836-mbox).

Tested-by: Stephen Warren <swarren@wwwdotorg.org>

I applied the patches on top of korg's linux-rpi.git for-rpi-next,
resolved the io_map conflicts, and tested without U-Boot.

I'll try to work out why it doesn't work with U-Boot. I can't
immediately see anything in /proc/device-tree that indicates the RPi
firmware is modifying the DT that's passed to the kernel to exclude any
CPU1..3 spin tables, so either the kernel isn't hitting those purely by
luck, or I'm guessing wrong re: the issue with U-Boot.

Re: BCM2836 (Raspberry Pi 2) port

[Florian Fainelli]

Le 04/28/15 19:38, Stephen Warren a écrit :
> On 04/21/2015 12:09 PM, Eric Anholt wrote:
>> This is my first submission of a Raspberry Pi 2 port.  It can be found
>> at https://github.com/anholt/linux/tree/bcm2836
>>
>> I'm using the 2835 interrupt controller support, without adding the
>> checks for ARM local interrupts first.  That means no support for IPIs
>> (and thus no SMP), no PMU events, and no local timer (I'm using the
>> same 2835 peripheral one).
>>
>> It supports a similar featureset to Pi 1 at this point.  Serial and SD
>> cards work.  Just one CPU supported.  USB (ethernet) works if you use
>> U-Boot, or my mailbox series
>> (https://github.com/anholt/linux/tree/bcm2836-mbox).
> 
> Tested-by: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
> 
> I applied the patches on top of korg's linux-rpi.git for-rpi-next,
> resolved the io_map conflicts, and tested without U-Boot.

Should we start thinking about routing bcm2835/36 changes through the
same Broadcom pull request as we do for the every other SoCs within
mach-bcm: 63xx, 53xx/47xx, brcmstb, cygnus at some point?

I don't have any strong feelings either way, just curious if this is
something remotely desireable from an arm-soc maintainer role perspective.

Thanks!
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

BCM2836 (Raspberry Pi 2) port

[Florian Fainelli]

Le 04/28/15 19:38, Stephen Warren a ?crit :
> On 04/21/2015 12:09 PM, Eric Anholt wrote:
>> This is my first submission of a Raspberry Pi 2 port.  It can be found
>> at https://github.com/anholt/linux/tree/bcm2836
>>
>> I'm using the 2835 interrupt controller support, without adding the
>> checks for ARM local interrupts first.  That means no support for IPIs
>> (and thus no SMP), no PMU events, and no local timer (I'm using the
>> same 2835 peripheral one).
>>
>> It supports a similar featureset to Pi 1 at this point.  Serial and SD
>> cards work.  Just one CPU supported.  USB (ethernet) works if you use
>> U-Boot, or my mailbox series
>> (https://github.com/anholt/linux/tree/bcm2836-mbox).
> 
> Tested-by: Stephen Warren <swarren@wwwdotorg.org>
> 
> I applied the patches on top of korg's linux-rpi.git for-rpi-next,
> resolved the io_map conflicts, and tested without U-Boot.

Should we start thinking about routing bcm2835/36 changes through the
same Broadcom pull request as we do for the every other SoCs within
mach-bcm: 63xx, 53xx/47xx, brcmstb, cygnus at some point?

I don't have any strong feelings either way, just curious if this is
something remotely desireable from an arm-soc maintainer role perspective.

Thanks!
--
Florian

Re: BCM2836 (Raspberry Pi 2) port

[Eric Anholt]

[-- Attachment #1: Type: text/plain, Size: 2598 bytes --]

Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> writes:

> On 04/21/2015 12:09 PM, Eric Anholt wrote:
>> This is my first submission of a Raspberry Pi 2 port.  It can be found
>> at https://github.com/anholt/linux/tree/bcm2836
>> 
>> I'm using the 2835 interrupt controller support, without adding the
>> checks for ARM local interrupts first.  That means no support for IPIs
>> (and thus no SMP), no PMU events, and no local timer (I'm using the
>> same 2835 peripheral one).
>> 
>> It supports a similar featureset to Pi 1 at this point.  Serial and SD
>> cards work.  Just one CPU supported.  USB (ethernet) works if you use
>> U-Boot, or my mailbox series
>> (https://github.com/anholt/linux/tree/bcm2836-mbox).
>
> Tested-by: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
>
> I applied the patches on top of korg's linux-rpi.git for-rpi-next,
> resolved the io_map conflicts, and tested without U-Boot.
>
> I'll try to work out why it doesn't work with U-Boot. I can't
> immediately see anything in /proc/device-tree that indicates the RPi
> firmware is modifying the DT that's passed to the kernel to exclude any
> CPU1..3 spin tables, so either the kernel isn't hitting those purely by
> luck, or I'm guessing wrong re: the issue with U-Boot.

2836 SMP is now booting on my branch.  Big thanks to Andrea Merello for
doing most of the work on it.  Not-cleaned-up series is available at:

https://github.com/anholt/linux/tree/bcm2836-smp

There's a bunch of stuff in here I'm not sure about:

How do we like the way I'm inheriting 2835 stuff with the includes now?
(It's been a lot less merging work than my initial post had been, but
the /delete-node/ lines for 2386's changes are gross).

How do people feel about putting the 2386 local IRQ handling in the 2835
irqchip code?  Do we like the code sharing for GPU IRQs, or would we
rather have a separate driver?  Could we separate the 2836 local irqs
From 2835, and have it just call into 2835 for GPU IRQ handling?

Where do people think the arch timer frequency initialization should go
(commit "ARM: BCM2835: Set up the local timer frequency on 2836.")?  On
2709 it's in init_time(), but I hear we've been trying to move away from
these hooks.

Is there a sensible way to share our mapping of the local regs between
the driver and platform bits that need to access them?  (see
arch/arm/mach-bcm/bcm2836_platsmp.c for what we're doing currently)

Is there anything we would want to merge before getting a full working
implementation ready to merge?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

BCM2836 (Raspberry Pi 2) port

[Eric Anholt]

Stephen Warren <swarren@wwwdotorg.org> writes:

> On 04/21/2015 12:09 PM, Eric Anholt wrote:
>> This is my first submission of a Raspberry Pi 2 port.  It can be found
>> at https://github.com/anholt/linux/tree/bcm2836
>> 
>> I'm using the 2835 interrupt controller support, without adding the
>> checks for ARM local interrupts first.  That means no support for IPIs
>> (and thus no SMP), no PMU events, and no local timer (I'm using the
>> same 2835 peripheral one).
>> 
>> It supports a similar featureset to Pi 1 at this point.  Serial and SD
>> cards work.  Just one CPU supported.  USB (ethernet) works if you use
>> U-Boot, or my mailbox series
>> (https://github.com/anholt/linux/tree/bcm2836-mbox).
>
> Tested-by: Stephen Warren <swarren@wwwdotorg.org>
>
> I applied the patches on top of korg's linux-rpi.git for-rpi-next,
> resolved the io_map conflicts, and tested without U-Boot.
>
> I'll try to work out why it doesn't work with U-Boot. I can't
> immediately see anything in /proc/device-tree that indicates the RPi
> firmware is modifying the DT that's passed to the kernel to exclude any
> CPU1..3 spin tables, so either the kernel isn't hitting those purely by
> luck, or I'm guessing wrong re: the issue with U-Boot.

2836 SMP is now booting on my branch.  Big thanks to Andrea Merello for
doing most of the work on it.  Not-cleaned-up series is available at:

https://github.com/anholt/linux/tree/bcm2836-smp

There's a bunch of stuff in here I'm not sure about:

How do we like the way I'm inheriting 2835 stuff with the includes now?
(It's been a lot less merging work than my initial post had been, but
the /delete-node/ lines for 2386's changes are gross).

How do people feel about putting the 2386 local IRQ handling in the 2835
irqchip code?  Do we like the code sharing for GPU IRQs, or would we
rather have a separate driver?  Could we separate the 2836 local irqs
>From 2835, and have it just call into 2835 for GPU IRQ handling?

Where do people think the arch timer frequency initialization should go
(commit "ARM: BCM2835: Set up the local timer frequency on 2836.")?  On
2709 it's in init_time(), but I hear we've been trying to move away from
these hooks.

Is there a sensible way to share our mapping of the local regs between
the driver and platform bits that need to access them?  (see
arch/arm/mach-bcm/bcm2836_platsmp.c for what we're doing currently)

Is there anything we would want to merge before getting a full working
implementation ready to merge?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150506/f167457b/attachment-0001.sig>

Re: BCM2836 (Raspberry Pi 2) port

[Arnd Bergmann]

On Wednesday 06 May 2015 11:51:33 Eric Anholt wrote:
> 2836 SMP is now booting on my branch.  Big thanks to Andrea Merello for
> doing most of the work on it.  Not-cleaned-up series is available at:
> 
> https://github.com/anholt/linux/tree/bcm2836-smp
> 
> There's a bunch of stuff in here I'm not sure about:
> 
> How do we like the way I'm inheriting 2835 stuff with the includes now?
> (It's been a lot less merging work than my initial post had been, but
> the /delete-node/ lines for 2386's changes are gross).

It's probably better to rename the original dtsi file to bcm283x.dtsi
then and move the parts that are different into bcm2835.dts and bcm2836.dtsi.

> How do people feel about putting the 2386 local IRQ handling in the 2835
> irqchip code?  Do we like the code sharing for GPU IRQs, or would we
> rather have a separate driver?  Could we separate the 2836 local irqs
> From 2835, and have it just call into 2835 for GPU IRQ handling?

I haven't looked in too much detail, but unless the file grows too
large, having all the code in one file is probably best. I'm guessing
that most users will want to enable both at the same time anyway.
 
> Where do people think the arch timer frequency initialization should go
> (commit "ARM: BCM2835: Set up the local timer frequency on 2836.")?  On
> 2709 it's in init_time(), but I hear we've been trying to move away from
> these hooks.

My first intuition would be to have the clk driver handle setting up
the registers, as long as the arch_timer_of_init() requests the clock
correctly, that should do the right thing.

> Is there a sensible way to share our mapping of the local regs between
> the driver and platform bits that need to access them?  (see
> arch/arm/mach-bcm/bcm2836_platsmp.c for what we're doing currently)

What is the split between those registers? If you have multiple drivers
that all want just a few registers from one shared area, a "syscon"
node would work best.

If the registers are all owned by a single driver, but you need to access
a few of the registers during early boot, it may be better to do an
ad-hoc mapping in the smp code by finding the device node manually.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

BCM2836 (Raspberry Pi 2) port

[Arnd Bergmann]

On Wednesday 06 May 2015 11:51:33 Eric Anholt wrote:
> 2836 SMP is now booting on my branch.  Big thanks to Andrea Merello for
> doing most of the work on it.  Not-cleaned-up series is available at:
> 
> https://github.com/anholt/linux/tree/bcm2836-smp
> 
> There's a bunch of stuff in here I'm not sure about:
> 
> How do we like the way I'm inheriting 2835 stuff with the includes now?
> (It's been a lot less merging work than my initial post had been, but
> the /delete-node/ lines for 2386's changes are gross).

It's probably better to rename the original dtsi file to bcm283x.dtsi
then and move the parts that are different into bcm2835.dts and bcm2836.dtsi.

> How do people feel about putting the 2386 local IRQ handling in the 2835
> irqchip code?  Do we like the code sharing for GPU IRQs, or would we
> rather have a separate driver?  Could we separate the 2836 local irqs
> From 2835, and have it just call into 2835 for GPU IRQ handling?

I haven't looked in too much detail, but unless the file grows too
large, having all the code in one file is probably best. I'm guessing
that most users will want to enable both at the same time anyway.
 
> Where do people think the arch timer frequency initialization should go
> (commit "ARM: BCM2835: Set up the local timer frequency on 2836.")?  On
> 2709 it's in init_time(), but I hear we've been trying to move away from
> these hooks.

My first intuition would be to have the clk driver handle setting up
the registers, as long as the arch_timer_of_init() requests the clock
correctly, that should do the right thing.

> Is there a sensible way to share our mapping of the local regs between
> the driver and platform bits that need to access them?  (see
> arch/arm/mach-bcm/bcm2836_platsmp.c for what we're doing currently)

What is the split between those registers? If you have multiple drivers
that all want just a few registers from one shared area, a "syscon"
node would work best.

If the registers are all owned by a single driver, but you need to access
a few of the registers during early boot, it may be better to do an
ad-hoc mapping in the smp code by finding the device node manually.

	Arnd