[PATCH 8/8] ARM: mvebu: armada-xp: Fix 74hc595 count for Lenovo ix4-300d

[Sebastian Hesselbarth]

There is only one 74hc595 connected to GPIO but two were given
in the registers-number property. Fix it up.

Signed-off-by: Sebastian Hesselbarth <***@gmail.com>
---
Cc: Jason Cooper <***@lakedaemon.net>
Cc: Andrew Lunn <***@lunn.ch>
Cc: Gregory Clement <***@free-electrons.com>
Cc: Ezequiel Garcia <***@free-electrons.com>
Cc: Thomas Petazzoni <***@free-electrons.com>
Cc: Benoit Masson <***@perenite.com>
Cc: ***@vger.kernel.org
Cc: linux-arm-***@lists.infradead.org
Cc: linux-***@vger.kernel.org
---
arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
index cef50da88e45..90d9002923f5 100644
--- a/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
+++ b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
@@ -204,7 +204,7 @@
gpio-controller;
#gpio-cells = <2>;
reg = <0>;
- registers-number = <2>;
+ registers-number = <1>;
spi-max-frequency = <100000>;
};
};

[Sebastian Hesselbarth]

There is an I2C eeprom connected on Lenovo ix4-300d, add the
corresponding node.

Signed-off-by: Sebastian Hesselbarth <***@gmail.com>
---
IIRC, the eeprom contains some register init pairs (address, data) for
and is empty otherwise. I'll have to check the boot loader code again,
but (again) IIRC, stock u-boot already does the sequence in code and
ignores the eeprom.

Cc: Jason Cooper <***@lakedaemon.net>
Cc: Andrew Lunn <***@lunn.ch>
Cc: Gregory Clement <***@free-electrons.com>
Cc: Ezequiel Garcia <***@free-electrons.com>
Cc: Thomas Petazzoni <***@free-electrons.com>
Cc: Benoit Masson <***@perenite.com>
Cc: ***@vger.kernel.org
Cc: linux-arm-***@lists.infradead.org
Cc: linux-***@vger.kernel.org
---
arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts | 5 +++++
1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
index c5ee6c00766c..cef50da88e45 100644
--- a/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
+++ b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
@@ -98,6 +98,11 @@
reg = <0x2e>;
};

+ ***@50 {
+ compatible = "atmel,24c64";
+ reg = <0x50>;
+ };
+
***@51 {
compatible = "nxp,pcf8563";
reg = <0x51>;

[Sebastian Hesselbarth]

Post by Sebastian Hesselbarth
There is an I2C eeprom connected on Lenovo ix4-300d, add the
corresponding node.
---

..

Post by Sebastian Hesselbarth
---
arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
index c5ee6c00766c..cef50da88e45 100644
--- a/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
+++ b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
@@ -98,6 +98,11 @@
reg = <0x2e>;
};

nit: the node name should describe function, not its type.

@Jason, when you take this in, feel free to name the node ***@50
instead.

Sebastian

Post by Sebastian Hesselbarth
+ compatible = "atmel,24c64";
+ reg = <0x50>;
+ };
+
compatible = "nxp,pcf8563";
reg = <0x51>;

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Sebastian Hesselbarth]

All current Armada XP SoCs have their pin controller at 0x18000/0x38.
Move the common properties of pinctrl nodes to armada-xp.dtsi to allow
to share pinctrl settings later.

Signed-off-by: Sebastian Hesselbarth <***@gmail.com>
---
Cc: Jason Cooper <***@lakedaemon.net>
Cc: Andrew Lunn <***@lunn.ch>
Cc: Gregory Clement <***@free-electrons.com>
Cc: Ezequiel Garcia <***@free-electrons.com>
Cc: Thomas Petazzoni <***@free-electrons.com>
Cc: ***@vger.kernel.org
Cc: linux-arm-***@lists.infradead.org
Cc: linux-***@vger.kernel.org
---
arch/arm/boot/dts/armada-xp-mv78230.dtsi | 7 -------
arch/arm/boot/dts/armada-xp-mv78260.dtsi | 7 -------
arch/arm/boot/dts/armada-xp-mv78460.dtsi | 7 -------
arch/arm/boot/dts/armada-xp.dtsi | 10 ++++++++++
4 files changed, 10 insertions(+), 21 deletions(-)

diff --git a/arch/arm/boot/dts/armada-xp-mv78230.dtsi b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
index 2592e1c13560..b5933aa9ab50 100644
--- a/arch/arm/boot/dts/armada-xp-mv78230.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
@@ -169,13 +169,6 @@
internal-regs {
pinctrl {
compatible = "marvell,mv78230-pinctrl";
- reg = <0x18000 0x38>;
-
- sdio_pins: sdio-pins {
- marvell,pins = "mpp30", "mpp31", "mpp32",
- "mpp33", "mpp34", "mpp35";
- marvell,function = "sd0";
- };
};

gpio0: ***@18100 {
diff --git a/arch/arm/boot/dts/armada-xp-mv78260.dtsi b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
index 480e237a870f..5954b362180c 100644
--- a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
@@ -253,13 +253,6 @@
internal-regs {
pinctrl {
compatible = "marvell,mv78260-pinctrl";
- reg = <0x18000 0x38>;
-
- sdio_pins: sdio-pins {
- marvell,pins = "mpp30", "mpp31", "mpp32",
- "mpp33", "mpp34", "mpp35";
- marvell,function = "sd0";
- };
};

gpio0: ***@18100 {
diff --git a/arch/arm/boot/dts/armada-xp-mv78460.dtsi b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
index 2c7b1fef4703..735924d62e12 100644
--- a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
@@ -291,13 +291,6 @@
internal-regs {
pinctrl {
compatible = "marvell,mv78460-pinctrl";
- reg = <0x18000 0x38>;
-
- sdio_pins: sdio-pins {
- marvell,pins = "mpp30", "mpp31", "mpp32",
- "mpp33", "mpp34", "mpp35";
- marvell,function = "sd0";
- };
};

gpio0: ***@18100 {
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index bff9f6c18db1..75653774342a 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -71,6 +71,16 @@
status = "disabled";
};

+ pinctrl {
+ reg = <0x18000 0x38>;
+
+ sdio_pins: sdio-pins {
+ marvell,pins = "mpp30", "mpp31", "mpp32",
+ "mpp33", "mpp34", "mpp35";
+ marvell,function = "sd0";
+ };
+ };
+
system-***@18200 {
compatible = "marvell,armada-370-xp-system-controller";
reg = <0x18200 0x500>;

[Thomas Petazzoni]

Dear Sebastian Hesselbarth,

Post by Sebastian Hesselbarth
All current Armada XP SoCs have their pin controller at 0x18000/0x38.
Move the common properties of pinctrl nodes to armada-xp.dtsi to allow
to share pinctrl settings later.

Acked-by: Thomas Petazzoni <***@free-electrons.com>

Thomas

[Sebastian Hesselbarth]

There is a GMII setting for GE0, add it to the common pinctrl node.

Signed-off-by: Sebastian Hesselbarth <***@gmail.com>
---
Cc: Jason Cooper <***@lakedaemon.net>
Cc: Andrew Lunn <***@lunn.ch>
Cc: Gregory Clement <***@free-electrons.com>
Cc: Ezequiel Garcia <***@free-electrons.com>
Cc: Thomas Petazzoni <***@free-electrons.com>
Cc: ***@vger.kernel.org
Cc: linux-arm-***@lists.infradead.org
Cc: linux-***@vger.kernel.org
---
arch/arm/boot/dts/armada-xp.dtsi | 11 +++++++++++
1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index dfbcb10ad0db..327cace42242 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -74,6 +74,17 @@
pinctrl: pin-***@18000 {
reg = <0x18000 0x38>;

+ pmx_ge0_gmii: pmx-ge0-gmii {
+ marvell,pins =
+ "mpp0", "mpp1", "mpp2", "mpp3",
+ "mpp4", "mpp5", "mpp6", "mpp7",
+ "mpp8", "mpp9", "mpp10", "mpp11",
+ "mpp12", "mpp13", "mpp14", "mpp15",
+ "mpp16", "mpp17", "mpp18", "mpp19",
+ "mpp20", "mpp21", "mpp22", "mpp23";
+ marvell,function = "ge0";
+ };
+
pmx_ge0_rgmii: pmx-ge0-rgmii {
marvell,pins =
"mpp0", "mpp1", "mpp2", "mpp3",

[Sebastian Hesselbarth]

Lenovo ix4-300d has two ethernet PHYs connected via RGMII. Add the
corresponding pinctrl settings.

Signed-off-by: Sebastian Hesselbarth <***@gmail.com>
---
Cc: Jason Cooper <***@lakedaemon.net>
Cc: Andrew Lunn <***@lunn.ch>
Cc: Gregory Clement <***@free-electrons.com>
Cc: Ezequiel Garcia <***@free-electrons.com>
Cc: Thomas Petazzoni <***@free-electrons.com>
Cc: Benoit Masson <***@perenite.com>
Cc: ***@vger.kernel.org
Cc: linux-arm-***@lists.infradead.org
Cc: linux-***@vger.kernel.org
---
arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts | 4 ++++
1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
index 492cd8e3f424..c5ee6c00766c 100644
--- a/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
+++ b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
@@ -66,12 +66,16 @@
};

***@70000 {
+ pinctrl-0 = <&pmx_ge0_rgmii>;
+ pinctrl-names = "default";
status = "okay";
phy = <&phy0>;
phy-mode = "rgmii-id";
};

***@74000 {
+ pinctrl-0 = <&pmx_ge1_rgmii>;
+ pinctrl-names = "default";
status = "okay";
phy = <&phy1>;
phy-mode = "rgmii-id";

[Sebastian Hesselbarth]

Armada XP pinctrl node gained an alias, make use of it.

Signed-off-by: Sebastian Hesselbarth <***@gmail.com>
---
Cc: Jason Cooper <***@lakedaemon.net>
Cc: Andrew Lunn <***@lunn.ch>
Cc: Gregory Clement <***@free-electrons.com>
Cc: Ezequiel Garcia <***@free-electrons.com>
Cc: Thomas Petazzoni <***@free-electrons.com>
Cc: ***@vger.kernel.org
Cc: linux-arm-***@lists.infradead.org
Cc: linux-***@vger.kernel.org
---
arch/arm/boot/dts/armada-xp-axpwifiap.dts | 68 +++++-----
arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts | 62 ++++-----
arch/arm/boot/dts/armada-xp-mv78230.dtsi | 8 +-
arch/arm/boot/dts/armada-xp-mv78260.dtsi | 8 +-
arch/arm/boot/dts/armada-xp-mv78460.dtsi | 8 +-
arch/arm/boot/dts/armada-xp-netgear-rn2120.dts | 164 +++++++++++------------
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 14 +-
7 files changed, 167 insertions(+), 165 deletions(-)

diff --git a/arch/arm/boot/dts/armada-xp-axpwifiap.dts b/arch/arm/boot/dts/armada-xp-axpwifiap.dts
index 546016148283..cdab007fbaf4 100644
--- a/arch/arm/boot/dts/armada-xp-axpwifiap.dts
+++ b/arch/arm/boot/dts/armada-xp-axpwifiap.dts
@@ -60,40 +60,6 @@
};

internal-regs {
- pinctrl: pin-***@18000 {
- pinctrl-0 = <&pmx_phy_int>;
- pinctrl-names = "default";
-
- pmx_ge0: pmx-ge0 {
- marvell,pins = "mpp0", "mpp1", "mpp2", "mpp3",
- "mpp4", "mpp5", "mpp6", "mpp7",
- "mpp8", "mpp9", "mpp10", "mpp11";
- marvell,function = "ge0";
- };
-
- pmx_ge1: pmx-ge1 {
- marvell,pins = "mpp12", "mpp13", "mpp14", "mpp15",
- "mpp16", "mpp17", "mpp18", "mpp19",
- "mpp20", "mpp21", "mpp22", "mpp23";
- marvell,function = "ge1";
- };
-
- pmx_keys: pmx-keys {
- marvell,pins = "mpp33";
- marvell,function = "gpio";
- };
-
- pmx_spi: pmx-spi {
- marvell,pins = "mpp36", "mpp37", "mpp38", "mpp39";
- marvell,function = "spi";
- };
-
- pmx_phy_int: pmx-phy-int {
- marvell,pins = "mpp32";
- marvell,function = "gpio";
- };
- };
-
***@12000 {
status = "okay";
};
@@ -162,3 +128,37 @@
};
};
};
+
+&pinctrl {
+ pinctrl-0 = <&pmx_phy_int>;
+ pinctrl-names = "default";
+
+ pmx_ge0: pmx-ge0 {
+ marvell,pins = "mpp0", "mpp1", "mpp2", "mpp3",
+ "mpp4", "mpp5", "mpp6", "mpp7",
+ "mpp8", "mpp9", "mpp10", "mpp11";
+ marvell,function = "ge0";
+ };
+
+ pmx_ge1: pmx-ge1 {
+ marvell,pins = "mpp12", "mpp13", "mpp14", "mpp15",
+ "mpp16", "mpp17", "mpp18", "mpp19",
+ "mpp20", "mpp21", "mpp22", "mpp23";
+ marvell,function = "ge1";
+ };
+
+ pmx_keys: pmx-keys {
+ marvell,pins = "mpp33";
+ marvell,function = "gpio";
+ };
+
+ pmx_spi: pmx-spi {
+ marvell,pins = "mpp36", "mpp37", "mpp38", "mpp39";
+ marvell,function = "spi";
+ };
+
+ pmx_phy_int: pmx-phy-int {
+ marvell,pins = "mpp32";
+ marvell,function = "gpio";
+ };
+};
diff --git a/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
index baa43a004299..492cd8e3f424 100644
--- a/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
+++ b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
@@ -51,37 +51,6 @@
};

internal-regs {
- pinctrl: pin-***@18000 {
- poweroff_pin: poweroff-pin {
- marvell,pins = "mpp24";
- marvell,function = "gpio";
- };
-
- power_button_pin: power-button-pin {
- marvell,pins = "mpp44";
- marvell,function = "gpio";
- };
-
- reset_button_pin: reset-button-pin {
- marvell,pins = "mpp45";
- marvell,function = "gpio";
- };
- select_button_pin: select-button-pin {
- marvell,pins = "mpp41";
- marvell,function = "gpio";
- };
-
- scroll_button_pin: scroll-button-pin {
- marvell,pins = "mpp42";
- marvell,function = "gpio";
- };
-
- hdd_led_pin: hdd-led-pin {
- marvell,pins = "mpp26";
- marvell,function = "gpio";
- };
- };
-
***@12000 {
status = "okay";
};
@@ -282,3 +251,34 @@
gpios = <&gpio0 24 GPIO_ACTIVE_HIGH>;
};
};
+
+&pinctrl {
+ poweroff_pin: poweroff-pin {
+ marvell,pins = "mpp24";
+ marvell,function = "gpio";
+ };
+
+ power_button_pin: power-button-pin {
+ marvell,pins = "mpp44";
+ marvell,function = "gpio";
+ };
+
+ reset_button_pin: reset-button-pin {
+ marvell,pins = "mpp45";
+ marvell,function = "gpio";
+ };
+ select_button_pin: select-button-pin {
+ marvell,pins = "mpp41";
+ marvell,function = "gpio";
+ };
+
+ scroll_button_pin: scroll-button-pin {
+ marvell,pins = "mpp42";
+ marvell,function = "gpio";
+ };
+
+ hdd_led_pin: hdd-led-pin {
+ marvell,pins = "mpp26";
+ marvell,function = "gpio";
+ };
+};
diff --git a/arch/arm/boot/dts/armada-xp-mv78230.dtsi b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
index e24ef072b8cb..281ccd24295c 100644
--- a/arch/arm/boot/dts/armada-xp-mv78230.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
@@ -167,10 +167,6 @@
};

internal-regs {
- pinctrl: pin-***@18000 {
- compatible = "marvell,mv78230-pinctrl";
- };
-
gpio0: ***@18100 {
compatible = "marvell,orion-gpio";
reg = <0x18100 0x40>;
@@ -195,3 +191,7 @@
};
};
};
+
+&pinctrl {
+ compatible = "marvell,mv78230-pinctrl";
+};
diff --git a/arch/arm/boot/dts/armada-xp-mv78260.dtsi b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
index 53dfb157b91a..d7a8d0b0f385 100644
--- a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
@@ -251,10 +251,6 @@
};

internal-regs {
- pinctrl: pin-***@18000 {
- compatible = "marvell,mv78260-pinctrl";
- };
-
gpio0: ***@18100 {
compatible = "marvell,orion-gpio";
reg = <0x18100 0x40>;
@@ -298,3 +294,7 @@
};
};
};
+
+&pinctrl {
+ compatible = "marvell,mv78260-pinctrl";
+};
diff --git a/arch/arm/boot/dts/armada-xp-mv78460.dtsi b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
index 8b4ab0a5d620..9c40c130d11a 100644
--- a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
@@ -289,10 +289,6 @@
};

internal-regs {
- pinctrl: pin-***@18000 {
- compatible = "marvell,mv78460-pinctrl";
- };
-
gpio0: ***@18100 {
compatible = "marvell,orion-gpio";
reg = <0x18100 0x40>;
@@ -336,3 +332,7 @@
};
};
};
+
+&pinctrl {
+ compatible = "marvell,mv78460-pinctrl";
+};
diff --git a/arch/arm/boot/dts/armada-xp-netgear-rn2120.dts b/arch/arm/boot/dts/armada-xp-netgear-rn2120.dts
index b3951c39c5da..8c241d08f2a3 100644
--- a/arch/arm/boot/dts/armada-xp-netgear-rn2120.dts
+++ b/arch/arm/boot/dts/armada-xp-netgear-rn2120.dts
@@ -55,88 +55,6 @@
};

internal-regs {
- pinctrl: pin-***@18000 {
- poweroff: poweroff {
- marvell,pins = "mpp42";
- marvell,function = "gpio";
- };
-
- power_button_pin: power-button-pin {
- marvell,pins = "mpp27";
- marvell,function = "gpio";
- };
-
- reset_button_pin: reset-button-pin {
- marvell,pins = "mpp41";
- marvell,function = "gpio";
- };
-
- sata1_led_pin: sata1-led-pin {
- marvell,pins = "mpp31";
- marvell,function = "gpio";
- };
-
- sata2_led_pin: sata2-led-pin {
- marvell,pins = "mpp40";
- marvell,function = "gpio";
- };
-
- sata3_led_pin: sata3-led-pin {
- marvell,pins = "mpp44";
- marvell,function = "gpio";
- };
-
- sata4_led_pin: sata4-led-pin {
- marvell,pins = "mpp47";
- marvell,function = "gpio";
- };
-
- sata1_power_pin: sata1-power-pin {
- marvell,pins = "mpp24";
- marvell,function = "gpio";
- };
-
- sata2_power_pin: sata2-power-pin {
- marvell,pins = "mpp25";
- marvell,function = "gpio";
- };
-
- sata3_power_pin: sata3-power-pin {
- marvell,pins = "mpp26";
- marvell,function = "gpio";
- };
-
- sata4_power_pin: sata4-power-pin {
- marvell,pins = "mpp28";
- marvell,function = "gpio";
- };
-
- sata1_pres_pin: sata1-pres-pin {
- marvell,pins = "mpp32";
- marvell,function = "gpio";
- };
-
- sata2_pres_pin: sata2-pres-pin {
- marvell,pins = "mpp33";
- marvell,function = "gpio";
- };
-
- sata3_pres_pin: sata3-pres-pin {
- marvell,pins = "mpp34";
- marvell,function = "gpio";
- };
-
- sata4_pres_pin: sata4-pres-pin {
- marvell,pins = "mpp35";
- marvell,function = "gpio";
- };
-
- err_led_pin: err-led-pin {
- marvell,pins = "mpp45";
- marvell,function = "gpio";
- };
- };
-
***@12000 {
status = "okay";
};
@@ -324,3 +242,85 @@
gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
};
};
+
+&pinctrl {
+ poweroff: poweroff {
+ marvell,pins = "mpp42";
+ marvell,function = "gpio";
+ };
+
+ power_button_pin: power-button-pin {
+ marvell,pins = "mpp27";
+ marvell,function = "gpio";
+ };
+
+ reset_button_pin: reset-button-pin {
+ marvell,pins = "mpp41";
+ marvell,function = "gpio";
+ };
+
+ sata1_led_pin: sata1-led-pin {
+ marvell,pins = "mpp31";
+ marvell,function = "gpio";
+ };
+
+ sata2_led_pin: sata2-led-pin {
+ marvell,pins = "mpp40";
+ marvell,function = "gpio";
+ };
+
+ sata3_led_pin: sata3-led-pin {
+ marvell,pins = "mpp44";
+ marvell,function = "gpio";
+ };
+
+ sata4_led_pin: sata4-led-pin {
+ marvell,pins = "mpp47";
+ marvell,function = "gpio";
+ };
+
+ sata1_power_pin: sata1-power-pin {
+ marvell,pins = "mpp24";
+ marvell,function = "gpio";
+ };
+
+ sata2_power_pin: sata2-power-pin {
+ marvell,pins = "mpp25";
+ marvell,function = "gpio";
+ };
+
+ sata3_power_pin: sata3-power-pin {
+ marvell,pins = "mpp26";
+ marvell,function = "gpio";
+ };
+
+ sata4_power_pin: sata4-power-pin {
+ marvell,pins = "mpp28";
+ marvell,function = "gpio";
+ };
+
+ sata1_pres_pin: sata1-pres-pin {
+ marvell,pins = "mpp32";
+ marvell,function = "gpio";
+ };
+
+ sata2_pres_pin: sata2-pres-pin {
+ marvell,pins = "mpp33";
+ marvell,function = "gpio";
+ };
+
+ sata3_pres_pin: sata3-pres-pin {
+ marvell,pins = "mpp34";
+ marvell,function = "gpio";
+ };
+
+ sata4_pres_pin: sata4-pres-pin {
+ marvell,pins = "mpp35";
+ marvell,function = "gpio";
+ };
+
+ err_led_pin: err-led-pin {
+ marvell,pins = "mpp45";
+ marvell,function = "gpio";
+ };
+};
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index 394f085751be..6f6b0916df48 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -77,12 +77,7 @@
***@12100 {
status = "okay";
};
- pinctrl: pin-***@18000 {
- led_pins: led-pins-0 {
- marvell,pins = "mpp49", "mpp51", "mpp53";
- marvell,function = "gpio";
- };
- };
+
leds {
compatible = "gpio-leds";
pinctrl-names = "default";
@@ -187,3 +182,10 @@
};
};
};
+
+&pinctrl {
+ led_pins: led-pins-0 {
+ marvell,pins = "mpp49", "mpp51", "mpp53";
+ marvell,function = "gpio";
+ };
+};

[Thomas Petazzoni]

Dear Sebastian Hesselbarth,

Post by Sebastian Hesselbarth
Armada XP pinctrl node gained an alias, make use of it.

Acked-by: Thomas Petazzoni <***@free-electrons.com>

Thomas

[Sebastian Hesselbarth]

Pinctrl settings for GE0 and GE1 are not only usable on RD-AXPWiFiAP.
Moreover, naming the RGMII settings pmx-ge{0,1} is not precise enough
as there is also a GMII setting for GE0.

Move the pinctrl sub-nodes to the common pinctrl node and rename them
to pmx-ge{0,1}-rgmii.

Signed-off-by: Sebastian Hesselbarth <***@gmail.com>
---
Cc: Jason Cooper <***@lakedaemon.net>
Cc: Andrew Lunn <***@lunn.ch>
Cc: Gregory Clement <***@free-electrons.com>
Cc: Ezequiel Garcia <***@free-electrons.com>
Cc: Thomas Petazzoni <***@free-electrons.com>
Cc: ***@vger.kernel.org
Cc: linux-arm-***@lists.infradead.org
Cc: linux-***@vger.kernel.org
---
arch/arm/boot/dts/armada-xp-axpwifiap.dts | 18 ++----------------
arch/arm/boot/dts/armada-xp.dtsi | 16 ++++++++++++++++
2 files changed, 18 insertions(+), 16 deletions(-)

diff --git a/arch/arm/boot/dts/armada-xp-axpwifiap.dts b/arch/arm/boot/dts/armada-xp-axpwifiap.dts
index cdab007fbaf4..0e53fad111de 100644
--- a/arch/arm/boot/dts/armada-xp-axpwifiap.dts
+++ b/arch/arm/boot/dts/armada-xp-axpwifiap.dts
@@ -84,14 +84,14 @@
};

***@70000 {
- pinctrl-0 = <&pmx_ge0>;
+ pinctrl-0 = <&pmx_ge0_rgmii>;
pinctrl-names = "default";
status = "okay";
phy = <&phy0>;
phy-mode = "rgmii-id";
};
***@74000 {
- pinctrl-0 = <&pmx_ge1>;
+ pinctrl-0 = <&pmx_ge1_rgmii>;
pinctrl-names = "default";
status = "okay";
phy = <&phy1>;
@@ -133,20 +133,6 @@
pinctrl-0 = <&pmx_phy_int>;
pinctrl-names = "default";

- pmx_ge0: pmx-ge0 {
- marvell,pins = "mpp0", "mpp1", "mpp2", "mpp3",
- "mpp4", "mpp5", "mpp6", "mpp7",
- "mpp8", "mpp9", "mpp10", "mpp11";
- marvell,function = "ge0";
- };
-
- pmx_ge1: pmx-ge1 {
- marvell,pins = "mpp12", "mpp13", "mpp14", "mpp15",
- "mpp16", "mpp17", "mpp18", "mpp19",
- "mpp20", "mpp21", "mpp22", "mpp23";
- marvell,function = "ge1";
- };
-
pmx_keys: pmx-keys {
marvell,pins = "mpp33";
marvell,function = "gpio";
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index b5fd8c69dfff..dfbcb10ad0db 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -74,6 +74,22 @@
pinctrl: pin-***@18000 {
reg = <0x18000 0x38>;

+ pmx_ge0_rgmii: pmx-ge0-rgmii {
+ marvell,pins =
+ "mpp0", "mpp1", "mpp2", "mpp3",
+ "mpp4", "mpp5", "mpp6", "mpp7",
+ "mpp8", "mpp9", "mpp10", "mpp11";
+ marvell,function = "ge0";
+ };
+
+ pmx_ge1_rgmii: pmx-ge1-rgmii {
+ marvell,pins =
+ "mpp12", "mpp13", "mpp14", "mpp15",
+ "mpp16", "mpp17", "mpp18", "mpp19",
+ "mpp20", "mpp21", "mpp22", "mpp23";
+ marvell,function = "ge1";
+ };
+
sdio_pins: sdio-pins {
marvell,pins = "mpp30", "mpp31", "mpp32",
"mpp33", "mpp34", "mpp35";

[Sebastian Hesselbarth]

In other MVEBU SoCs, the pin controller node is called pin-ctrl with
its base address added. Also, we have a node alias to access the pinctrl
node easily. Fix this for Armada XP pinctrl nodes to be consistent with
other SoCs.

Signed-off-by: Sebastian Hesselbarth <***@gmail.com>
---
Cc: Jason Cooper <***@lakedaemon.net>
Cc: Andrew Lunn <***@lunn.ch>
Cc: Gregory Clement <***@free-electrons.com>
Cc: Ezequiel Garcia <***@free-electrons.com>
Cc: Thomas Petazzoni <***@free-electrons.com>
Cc: ***@vger.kernel.org
Cc: linux-arm-***@lists.infradead.org
Cc: linux-***@vger.kernel.org
---
arch/arm/boot/dts/armada-xp-axpwifiap.dts | 2 +-
arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts | 2 +-
arch/arm/boot/dts/armada-xp-mv78230.dtsi | 2 +-
arch/arm/boot/dts/armada-xp-mv78260.dtsi | 2 +-
arch/arm/boot/dts/armada-xp-mv78460.dtsi | 2 +-
arch/arm/boot/dts/armada-xp-netgear-rn2120.dts | 2 +-
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 2 +-
arch/arm/boot/dts/armada-xp.dtsi | 2 +-
8 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/armada-xp-axpwifiap.dts b/arch/arm/boot/dts/armada-xp-axpwifiap.dts
index a55a97a70505..546016148283 100644
--- a/arch/arm/boot/dts/armada-xp-axpwifiap.dts
+++ b/arch/arm/boot/dts/armada-xp-axpwifiap.dts
@@ -60,7 +60,7 @@
};

internal-regs {
- pinctrl {
+ pinctrl: pin-***@18000 {
pinctrl-0 = <&pmx_phy_int>;
pinctrl-names = "default";

diff --git a/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
index 469cf7137595..baa43a004299 100644
--- a/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
+++ b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
@@ -51,7 +51,7 @@
};

internal-regs {
- pinctrl {
+ pinctrl: pin-***@18000 {
poweroff_pin: poweroff-pin {
marvell,pins = "mpp24";
marvell,function = "gpio";
diff --git a/arch/arm/boot/dts/armada-xp-mv78230.dtsi b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
index b5933aa9ab50..e24ef072b8cb 100644
--- a/arch/arm/boot/dts/armada-xp-mv78230.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
@@ -167,7 +167,7 @@
};

internal-regs {
- pinctrl {
+ pinctrl: pin-***@18000 {
compatible = "marvell,mv78230-pinctrl";
};

diff --git a/arch/arm/boot/dts/armada-xp-mv78260.dtsi b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
index 5954b362180c..53dfb157b91a 100644
--- a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
@@ -251,7 +251,7 @@
};

internal-regs {
- pinctrl {
+ pinctrl: pin-***@18000 {
compatible = "marvell,mv78260-pinctrl";
};

diff --git a/arch/arm/boot/dts/armada-xp-mv78460.dtsi b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
index 735924d62e12..8b4ab0a5d620 100644
--- a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
@@ -289,7 +289,7 @@
};

internal-regs {
- pinctrl {
+ pinctrl: pin-***@18000 {
compatible = "marvell,mv78460-pinctrl";
};

diff --git a/arch/arm/boot/dts/armada-xp-netgear-rn2120.dts b/arch/arm/boot/dts/armada-xp-netgear-rn2120.dts
index 0cf999abc4ed..b3951c39c5da 100644
--- a/arch/arm/boot/dts/armada-xp-netgear-rn2120.dts
+++ b/arch/arm/boot/dts/armada-xp-netgear-rn2120.dts
@@ -55,7 +55,7 @@
};

internal-regs {
- pinctrl {
+ pinctrl: pin-***@18000 {
poweroff: poweroff {
marvell,pins = "mpp42";
marvell,function = "gpio";
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index 4e5a59ee1501..394f085751be 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -77,7 +77,7 @@
***@12100 {
status = "okay";
};
- pinctrl {
+ pinctrl: pin-***@18000 {
led_pins: led-pins-0 {
marvell,pins = "mpp49", "mpp51", "mpp53";
marvell,function = "gpio";
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 75653774342a..b5fd8c69dfff 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -71,7 +71,7 @@
status = "disabled";
};

- pinctrl {
+ pinctrl: pin-***@18000 {
reg = <0x18000 0x38>;

sdio_pins: sdio-pins {

[Thomas Petazzoni]

Dear Sebastian Hesselbarth,

Post by Sebastian Hesselbarth
In other MVEBU SoCs, the pin controller node is called pin-ctrl with
its base address added. Also, we have a node alias to access the pinctrl
node easily. Fix this for Armada XP pinctrl nodes to be consistent with
other SoCs.

Note sure why we're using pin-ctrl rather than pinctrl, but I don't
really care, so:

Acked-by: Thomas Petazzoni <***@free-electrons.com>

Thomas

[Benoit Masson]

Guys,

Hi

this is a patch set preparing barebox support for ix4-300d. As usual,
I stumbled upon a few nice-to-haves before actually touching ix4-300d
dts. As it is a mach-mvebu thing, I just added the related mailing
lists instead of each of the DT maintainers.
First 5 patches consolidate SoC-specific pinctrl nodes to one common
node in armada-xp.dtsi, compatible overwrites for each SoC, and node
alias usage for each board. Also, ge{0,1} pinctrl settings are moved
to the common node from one board specific node.
Last 3 patches then use that ge{0,1} pinctrl settings on ix4-300d which
is vital for bootloader init. During exploration of ix4-300d, I also
found a i2c eeprom that has not been added to the dts, yet. Finally,
there is only one 74hc595 on ix4 mainboard while dts property is set
for two.
I cannot recall in detail what is on that eeprom, but IIRC it is nothing
important. Some reg,addr pairs for some init stuff that should have
already been done by stock u-boot. Anyway, adding the node will do no
harm.
Patches are based on v3.17-rc1 and intended for v3.18 but I am not in
a hurry. I only compile tested this, so a formal Tested-by from Benoit
for the ix4 and any other Armada XP board would be great.

I'm not sure what to test since I only receive some patch from the
series of 8. Should I get all 8 or only those you sent me. I'll be
able to test during next week.

Sébastien

Thanks benoît

ARM: mvebu: armada-xp: Consolidate pinctrl node
ARM: mvebu: armada-xp: Add node alias to pinctrl and add base address
ARM: mvebu: armada-xp: Use pinctrl node alias
ARM: mvebu: armada-xp: Move GE0/1 pinctrl settings for RGMII
ARM: mvebu: armada-xp: Add GE0 pinctrl settings for GMII
ARM: mvebu: armada-xp: Add RGMII pinctrl to Lenovo ix4-300d
ARM: mvebu: armada-xp: Add I2C eeprom on Lenovo ix4-300d
ARM: mvebu: armada-xp: Fix 74hc595 count for Lenovo ix4-300d
arch/arm/boot/dts/armada-xp-axpwifiap.dts | 58 +++-----
arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts | 73 +++++-----
arch/arm/boot/dts/armada-xp-mv78230.dtsi | 15 +--
arch/arm/boot/dts/armada-xp-mv78260.dtsi | 15 +--
arch/arm/boot/dts/armada-xp-mv78460.dtsi | 15 +--
arch/arm/boot/dts/armada-xp-netgear-rn2120.dts | 164 +++++++++++------------
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 14 +-
arch/arm/boot/dts/armada-xp.dtsi | 37 +++++
8 files changed, 202 insertions(+), 189 deletions(-)
---
--
2.0.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Jason Cooper]

Benoit,

Post by Benoit Masson

this is a patch set preparing barebox support for ix4-300d. As usual,
I stumbled upon a few nice-to-haves before actually touching ix4-300d
dts. As it is a mach-mvebu thing, I just added the related mailing
lists instead of each of the DT maintainers.
First 5 patches consolidate SoC-specific pinctrl nodes to one common
node in armada-xp.dtsi, compatible overwrites for each SoC, and node
alias usage for each board. Also, ge{0,1} pinctrl settings are moved
to the common node from one board specific node.
Last 3 patches then use that ge{0,1} pinctrl settings on ix4-300d which
is vital for bootloader init. During exploration of ix4-300d, I also
found a i2c eeprom that has not been added to the dts, yet. Finally,
there is only one 74hc595 on ix4 mainboard while dts property is set
for two.
I cannot recall in detail what is on that eeprom, but IIRC it is nothing
important. Some reg,addr pairs for some init stuff that should have
already been done by stock u-boot. Anyway, adding the node will do no
harm.
Patches are based on v3.17-rc1 and intended for v3.18 but I am not in
a hurry. I only compile tested this, so a formal Tested-by from Benoit
for the ix4 and any other Armada XP board would be great.

I'm not sure what to test since I only receive some patch from the
series of 8. Should I get all 8 or only those you sent me. I'll be
able to test during next week.

Did you ever get a chance to test this series?

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Sebastian Hesselbarth]

Post by Jason Cooper

Post by Benoit Masson

this is a patch set preparing barebox support for ix4-300d. As usual,
I stumbled upon a few nice-to-haves before actually touching ix4-300d
dts. As it is a mach-mvebu thing, I just added the related mailing
lists instead of each of the DT maintainers.
First 5 patches consolidate SoC-specific pinctrl nodes to one common
node in armada-xp.dtsi, compatible overwrites for each SoC, and node
alias usage for each board. Also, ge{0,1} pinctrl settings are moved
to the common node from one board specific node.
Last 3 patches then use that ge{0,1} pinctrl settings on ix4-300d which
is vital for bootloader init. During exploration of ix4-300d, I also
found a i2c eeprom that has not been added to the dts, yet. Finally,
there is only one 74hc595 on ix4 mainboard while dts property is set
for two.
I cannot recall in detail what is on that eeprom, but IIRC it is nothing
important. Some reg,addr pairs for some init stuff that should have
already been done by stock u-boot. Anyway, adding the node will do no
harm.
Patches are based on v3.17-rc1 and intended for v3.18 but I am not in
a hurry. I only compile tested this, so a formal Tested-by from Benoit
for the ix4 and any other Armada XP board would be great.

I'm not sure what to test since I only receive some patch from the
series of 8. Should I get all 8 or only those you sent me. I'll be
able to test during next week.

Did you ever get a chance to test this series?

Uhm, I never prepared a branch for Benoit to test. I have pushed the
patches with Thomas Acked-by's and renamed eeprom node based on
v3.17-rc1 to

https://github.com/shesselba/linux-dove.git devel/mvebu-ix4

Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Benoit Masson]

Post by Sebastian Hesselbarth

Post by Jason Cooper

Post by Benoit Masson

this is a patch set preparing barebox support for ix4-300d. As usual,
I stumbled upon a few nice-to-haves before actually touching ix4-300d
dts. As it is a mach-mvebu thing, I just added the related mailing
lists instead of each of the DT maintainers.
First 5 patches consolidate SoC-specific pinctrl nodes to one common
node in armada-xp.dtsi, compatible overwrites for each SoC, and node
alias usage for each board. Also, ge{0,1} pinctrl settings are moved
to the common node from one board specific node.
Last 3 patches then use that ge{0,1} pinctrl settings on ix4-300d which
is vital for bootloader init. During exploration of ix4-300d, I also
found a i2c eeprom that has not been added to the dts, yet. Finally,
there is only one 74hc595 on ix4 mainboard while dts property is set
for two.
I cannot recall in detail what is on that eeprom, but IIRC it is nothing
important. Some reg,addr pairs for some init stuff that should have
already been done by stock u-boot. Anyway, adding the node will do no
harm.
Patches are based on v3.17-rc1 and intended for v3.18 but I am not in
a hurry. I only compile tested this, so a formal Tested-by from Benoit
for the ix4 and any other Armada XP board would be great.

I'm not sure what to test since I only receive some patch from the
series of 8. Should I get all 8 or only those you sent me. I'll be
able to test during next week.

Did you ever get a chance to test this series?

Uhm, I never prepared a branch for Benoit to test. I have pushed the
patches with Thomas Acked-by's and renamed eeprom node based on
v3.17-rc1 to
https://github.com/shesselba/linux-dove.git devel/mvebu-ix4

Hi tahnks, that was my last question, because I was lost about which to apply from the list of 8.

Also I've noted you did some other patch for Armada XP not related to ix-4-300d, are they included here or should I get them too ?

I'll test those over Sunday night.

Benoit

Post by Sebastian Hesselbarth
Sebastian

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Sebastian Hesselbarth]

[...]

Post by Benoit Masson

Post by Sebastian Hesselbarth

Post by Jason Cooper

Post by Benoit Masson

Patches are based on v3.17-rc1 and intended for v3.18 but I am not in
a hurry. I only compile tested this, so a formal Tested-by from Benoit
for the ix4 and any other Armada XP board would be great.

I'm not sure what to test since I only receive some patch from the
series of 8. Should I get all 8 or only those you sent me. I'll be
able to test during next week.

Did you ever get a chance to test this series?

Uhm, I never prepared a branch for Benoit to test. I have pushed the
patches with Thomas Acked-by's and renamed eeprom node based on
v3.17-rc1 to
https://github.com/shesselba/linux-dove.git devel/mvebu-ix4

[...]

Post by Benoit Masson
Also I've noted you did some other patch for Armada XP not related to ix-4-300d,
are they included here or should I get them too ?

No, they are neither included nor is there any need to test. They are
about pcie-lanes property but it is more or less unused on Linux.

It is too late for v3.18 anyway, so I'll resend them once v3.18-rc1
drops.

Post by Benoit Masson
I'll test those over Sunday night.

Ok, great!

Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Benoit Masson]

Post by Sebastian Hesselbarth
[...]

Post by Benoit Masson

Post by Sebastian Hesselbarth

Post by Jason Cooper

Post by Benoit Masson

Patches are based on v3.17-rc1 and intended for v3.18 but I am not in
a hurry. I only compile tested this, so a formal Tested-by from Benoit
for the ix4 and any other Armada XP board would be great.

I'm not sure what to test since I only receive some patch from the
series of 8. Should I get all 8 or only those you sent me. I'll be
able to test during next week.

Did you ever get a chance to test this series?

Uhm, I never prepared a branch for Benoit to test. I have pushed the
patches with Thomas Acked-by's and renamed eeprom node based on
v3.17-rc1 to
https://github.com/shesselba/linux-dove.git devel/mvebu-ix4

[...]

Post by Benoit Masson
Also I've noted you did some other patch for Armada XP not related to ix-4-300d,
are they included here or should I get them too ?

No, they are neither included nor is there any need to test. They are
about pcie-lanes property but it is more or less unused on Linux.
It is too late for v3.18 anyway, so I'll resend them once v3.18-rc1
drops.

Post by Benoit Masson
I'll test those over Sunday night.

Ok, great!

Hi,

No so great, so far what I've done:
- use my working config this config has worked over mainline 3.16 for weeks
- compil you branch with it using you dts file
- boot KO it get stuck on i2C pcf8563 init (at least it is the last message dsplayed.

then I turn on DEBUG_LL but I get nothing more on the serial that could help

- I've tried removing the eeprom section you added to the dts -> same results

Maybe I missed something ? is this branch you sent me a bare fork from mainline 3.17 ? does it includes the armada XP step A0 patch ?

dump of the serial output:
Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 3.17.0-rc1-42264-gb065757 (***@aaaa) (gcc version 4.6.3 (Debian 4.6.3-14) ) #3 SMP Mon Oct 6 00:42:59 CEST 2014
CPU: ARMv7 Processor [562f5842] revision 2 (ARMv7), cr=10c5387d
CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
Machine model: Lenovo Iomega ix4-300d
Memory policy: Data cache writealloc
PERCPU: Embedded 7 pages/cpu @dfbd9000 s6784 r8192 d13696 u32768
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048
Kernel command line: console=ttyS0,115200 earlyprintk=ttyS0,115200 root=/dev/md0 rw mem=512M
PID hash table entries: 2048 (order: 1, 8192 bytes)
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 512868K/524288K available (4787K kernel code, 254K rwdata, 1324K rodata, 254K init, 131K bss, 11420K reserved, 0K highmem)
Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xffc00000 - 0xffe00000 (2048 kB)
vmalloc : 0xe0800000 - 0xff000000 ( 488 MB)
lowmem : 0xc0000000 - 0xe0000000 ( 512 MB)
pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
.text : 0xc0008000 - 0xc05fffac (6112 kB)
.init : 0xc0600000 - 0xc063fa80 ( 255 kB)
.data : 0xc0640000 - 0xc067fa60 ( 255 kB)
.bss : 0xc067fa60 - 0xc06a098c ( 132 kB)
Hierarchical RCU implementation.
NR_IRQS:16 nr_irqs:16 16
L2C: device tree omits to specify unified cache
L2C: DT/platform modifies aux control register: 0x1a696b10 -> 0x1a696b12
Aurora cache controller enabled, 16 ways, 1024 kB
Aurora: CACHE_ID 0x00000100, AUX_CTRL 0x1a696b12
sched_clock: 32 bits at 25MHz, resolution 40ns, wraps every 171798691800ns
Console: colour dummy device 80x30
Calibrating delay loop... 1332.01 BogoMIPS (lpj=6660096)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
CPU: Testing write buffer coherency: ok
CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
Setting up static identity map for 0x4b2b70 - 0x4b2bc8
mvebu-soc-id: MVEBU SoC ID=0x7823, Rev=0x1
mvebu-pmsu: Initializing Power Management Service Unit
Booting CPU 1
CPU1: Booted secondary processor
CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
Brought up 2 CPUs
SMP: Total of 2 processors activated.
CPU: All CPU(s) started in SVC mode.
VFP support v0.3: implementor 56 architecture 2 part 20 variant 9 rev 6
xor: measuring software checksum speed
arm4regs : 1093.200 MB/sec
8regs : 1092.000 MB/sec
32regs : 1011.200 MB/sec
xor: using function: arm4regs (1093.200 MB/sec)
pinctrl core: initialized pinctrl subsystem
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
raid6: int32x1 123 MB/s
raid6: int32x2 188 MB/s
raid6: int32x4 264 MB/s
raid6: int32x8 307 MB/s
raid6: using algorithm int32x8 (307 MB/s)
raid6: using intx1 recovery algorithm
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Advanced Linux Sound Architecture Driver Initialized.
Switched to clocksource armada_370_xp_clocksource
NET: Registered protocol family 2
TCP established hash table entries: 4096 (order: 2, 16384 bytes)
TCP bind hash table entries: 4096 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP: reno registered
UDP hash table entries: 256 (order: 1, 8192 bytes)
UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
futex hash table entries: 512 (order: 3, 32768 bytes)
NFS: Registering the id_resolver key type
Key type id_resolver registered
Key type id_legacy registered
Installing knfsd (copyright (C) 1996 ***@monad.swb.de).
msgmni has been set to 1001
async_tx: api initialized (async)
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
armada-xp-pinctrl d0018000.pin-ctrl: registered pinctrl driver
irq: Cannot allocate irq_descs @ IRQ37, assuming pre-allocated
irq: Cannot allocate irq_descs @ IRQ69, assuming pre-allocated
mvebu-pcie soc:pcie-controller: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io 0x1000-0xfffff]
pci_bus 0000:00: root bus resource [mem 0xf8000000-0xffdfffff]
pci_bus 0000:00: root bus resource [bus 00-ff]
PCI: bus0: Fast back to back transfers disabled
pci 0000:00:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring
pci 0000:00:05.0: bridge configuration invalid ([bus 00-00]), reconfiguring
PCI: bus1: Fast back to back transfers disabled
PCI: bus2: Fast back to back transfers disabled
pci 0000:00:01.0: BAR 8: assigned [mem 0xf8000000-0xf80fffff]
pci 0000:00:05.0: BAR 8: assigned [mem 0xf8100000-0xf81fffff]
pci 0000:00:01.0: BAR 7: assigned [io 0x10000-0x10fff]
pci 0000:01:00.0: BAR 0: assigned [mem 0xf8000000-0xf80fffff 64bit]
pci 0000:01:00.0: BAR 2: assigned [io 0x10000-0x100ff]
pci 0000:00:01.0: PCI bridge to [bus 01]
pci 0000:00:01.0: bridge window [io 0x10000-0x10fff]
pci 0000:00:01.0: bridge window [mem 0xf8000000-0xf80fffff]
pci 0000:02:00.0: BAR 0: assigned [mem 0xf8100000-0xf8101fff 64bit]
pci 0000:00:05.0: PCI bridge to [bus 02]
pci 0000:00:05.0: bridge window [mem 0xf8100000-0xf81fffff]
pci 0000:00:05.0: enabling device (0140 -> 0142)
mv_xor d0060900.xor: Marvell shared XOR driver
mv_xor d0060900.xor: Marvell XOR: ( xor cpy )
mv_xor d0060900.xor: Marvell XOR: ( xor cpy )
mv_xor d00f0900.xor: Marvell shared XOR driver
mv_xor d00f0900.xor: Marvell XOR: ( xor cpy )
mv_xor d00f0900.xor: Marvell XOR: ( xor cpy )
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
console [ttyS0] disabled
d0012000.serial: ttyS0 at MMIO 0xd0012000 (irq = 19, base_baud = 15625000) is a 16550A
console [ttyS0] enabled
zram: Created 1 device(s) ...
pci 0000:00:01.0: enabling device (0140 -> 0143)
sata_mv 0000:01:00.0: Gen-IIE 32 slots 4 ports SCSI mode IRQ via INTx
scsi host0: sata_mv
scsi host1: sata_mv
scsi host2: sata_mv
scsi host3: sata_mv
ata1: SATA max UDMA/133 mmio ***@0xf8000000 port 0xf8022000 irq 86
ata2: SATA max UDMA/133 mmio ***@0xf8000000 port 0xf8024000 irq 86
ata3: SATA max UDMA/133 mmio ***@0xf8000000 port 0xf8026000 irq 86
ata4: SATA max UDMA/133 mmio ***@0xf8000000 port 0xf8028000 irq 86
pxa3xx-nand d00d0000.nand: This platform can't do DMA on this device
nand: device found, Manufacturer ID: 0xec, Chip ID: 0xd3
nand: Samsung NAND 1GiB 3,3V 8-bit
nand: 1024MiB, SLC, page size: 2048, OOB size: 64
pxa3xx-nand d00d0000.nand: ECC strength 1, ECC step size 512
Bad block table found at page 524224, version 0x01
Bad block table found at page 524160, version 0x01
nand_read_bbt: bad block at 0x00003ca60000
7 ofpart partitions found on MTD device pxa3xx_nand-0
Creating 7 MTD partitions on "pxa3xx_nand-0":
0x000000000000-0x0000000e0000 : "u-boot"
0x0000000e0000-0x000000100000 : "u-boot-env"
0x000000100000-0x000000120000 : "u-boot-env2"
0x000000120000-0x000000520000 : "zImage"
0x000000520000-0x000000920000 : "initrd"
0x000000e00000-0x000040000000 : "boot"
0x000000000000-0x000040000000 : "flash"
spi_gpio spi3: gpio-miso property not found, switching to no-rx mode
libphy: orion_mdio_bus: probed
mvneta d0070000.ethernet eth0: Using hardware mac address 00:d0:b8:25:38:4d
mvneta d0074000.ethernet eth1: Using random mac address 12:93:5b:2b:44:6e
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-pci: EHCI PCI platform driver
ehci-orion: EHCI orion driver
orion-ehci d0050000.usb: EHCI Host Controller
orion-ehci d0050000.usb: new USB bus registered, assigned bus number 1
orion-ehci d0050000.usb: irq 25, io mem 0xd0050000
orion-ehci d0050000.usb: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
orion-ehci d0051000.usb: EHCI Host Controller
orion-ehci d0051000.usb: new USB bus registered, assigned bus number 2
orion-ehci d0051000.usb: irq 26, io mem 0xd0051000
orion-ehci d0051000.usb: USB 2.0 started, EHCI 1.00
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 1 port detected
xhci_hcd 0000:02:00.0: xHCI Host Controller
xhci_hcd 0000:02:00.0: new USB bus registered, assigned bus number 3
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
xhci_hcd 0000:02:00.0: xHCI Host Controller
xhci_hcd 0000:02:00.0: new USB bus registered, assigned bus number 4
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
usbcore: registered new interface driver usb-storage
rtc-mv d0010300.rtc: rtc core: registered d0010300.rtc as rtc0
i2c /dev entries driver
rtc-pcf8563 0-0051: chip found, driver version 0.4.3

Post by Sebastian Hesselbarth
Sebastian

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Sebastian Hesselbarth]

Post by Benoit Masson

Post by Sebastian Hesselbarth
[...]

Post by Benoit Masson

Post by Sebastian Hesselbarth

Post by Jason Cooper

Patches are based on v3.17-rc1 and intended for v3.18 but I am not in
a hurry. I only compile tested this, so a formal Tested-by from Benoit
for the ix4 and any other Armada XP board would be great.

[...]

Post by Benoit Masson

Post by Sebastian Hesselbarth

Post by Benoit Masson

Post by Sebastian Hesselbarth

Post by Jason Cooper
Did you ever get a chance to test this series?

Uhm, I never prepared a branch for Benoit to test. I have pushed the
patches with Thomas Acked-by's and renamed eeprom node based on
v3.17-rc1 to
https://github.com/shesselba/linux-dove.git devel/mvebu-ix4

[...]

Post by Benoit Masson

Post by Sebastian Hesselbarth
It is too late for v3.18 anyway, so I'll resend them once v3.18-rc1
drops.

Post by Benoit Masson
I'll test those over Sunday night.

- use my working config this config has worked over mainline 3.16 for weeks
- compil you branch with it using you dts file
- boot KO it get stuck on i2C pcf8563 init (at least it is the last message dsplayed.
then I turn on DEBUG_LL but I get nothing more on the serial that could help
- I've tried removing the eeprom section you added to the dts -> same results
Maybe I missed something ? is this branch you sent me a bare fork from mainline 3.17 ? does it includes the armada XP step A0 patch ?

Benoit,

the branch is straight forked from v3.17-rc1 with the patches in
question added. If there is any fixes that got in after rc1, they
are not included. I'll rebase the series on latest next tonight.

Anyway, I doubt the series is involved in the regression you see,
can you also boot plain v3.17-rc1 and v3.17 which got just released?

Also, DEBUG_LL will not give you any more information on this one,
as you passed serial console hand-off. You only need it for early
debugging and you have to make sure that (a) you select the correct
DEBUG_LL Kconfig for MVEBU with registers located at 0xd0000000 and
(b) you should always double check the phys/virt addresses of the
early console.

Post by Benoit Masson
Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
CPU: ARMv7 Processor [562f5842] revision 2 (ARMv7), cr=10c5387d
CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
Machine model: Lenovo Iomega ix4-300d
Memory policy: Data cache writealloc
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048
Kernel command line: console=ttyS0,115200 earlyprintk=ttyS0,115200 root=/dev/md0 rw mem=512M

/dev/md0 is soft-RAID on your harddisks, isn't it?
Also, you should not need the mem= parameter but that is just a nit.

[...]

Post by Benoit Masson
NR_IRQS:16 nr_irqs:16 16
L2C: device tree omits to specify unified cache

Jason, Thomas, Gregory,

we should add a "cache-unified" to the l2cc nodes for all SoCs.

Post by Benoit Masson
L2C: DT/platform modifies aux control register: 0x1a696b10 -> 0x1a696b12
Aurora cache controller enabled, 16 ways, 1024 kB
Aurora: CACHE_ID 0x00000100, AUX_CTRL 0x1a696b12
sched_clock: 32 bits at 25MHz, resolution 40ns, wraps every 171798691800ns

[...]

Post by Benoit Masson
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
console [ttyS0] disabled
d0012000.serial: ttyS0 at MMIO 0xd0012000 (irq = 19, base_baud = 15625000) is a 16550A
console [ttyS0] enabled

Here is the serial console hand-off, i.e. if you get this far, you
don't need DEBUG_LL at all.

Post by Benoit Masson
zram: Created 1 device(s) ...
pci 0000:00:01.0: enabling device (0140 -> 0143)
sata_mv 0000:01:00.0: Gen-IIE 32 slots 4 ports SCSI mode IRQ via INTx
scsi host0: sata_mv
scsi host1: sata_mv
scsi host2: sata_mv
scsi host3: sata_mv

Shouldn't it detect your hard-disks attached here?

Sebastian

Post by Benoit Masson
pxa3xx-nand d00d0000.nand: This platform can't do DMA on this device
nand: device found, Manufacturer ID: 0xec, Chip ID: 0xd3
nand: Samsung NAND 1GiB 3,3V 8-bit
nand: 1024MiB, SLC, page size: 2048, OOB size: 64
pxa3xx-nand d00d0000.nand: ECC strength 1, ECC step size 512
Bad block table found at page 524224, version 0x01
Bad block table found at page 524160, version 0x01
nand_read_bbt: bad block at 0x00003ca60000
7 ofpart partitions found on MTD device pxa3xx_nand-0
0x000000000000-0x0000000e0000 : "u-boot"
0x0000000e0000-0x000000100000 : "u-boot-env"
0x000000100000-0x000000120000 : "u-boot-env2"
0x000000120000-0x000000520000 : "zImage"
0x000000520000-0x000000920000 : "initrd"
0x000000e00000-0x000040000000 : "boot"
0x000000000000-0x000040000000 : "flash"
spi_gpio spi3: gpio-miso property not found, switching to no-rx mode
libphy: orion_mdio_bus: probed
mvneta d0070000.ethernet eth0: Using hardware mac address 00:d0:b8:25:38:4d
mvneta d0074000.ethernet eth1: Using random mac address 12:93:5b:2b:44:6e
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-pci: EHCI PCI platform driver
ehci-orion: EHCI orion driver
orion-ehci d0050000.usb: EHCI Host Controller
orion-ehci d0050000.usb: new USB bus registered, assigned bus number 1
orion-ehci d0050000.usb: irq 25, io mem 0xd0050000
orion-ehci d0050000.usb: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
orion-ehci d0051000.usb: EHCI Host Controller
orion-ehci d0051000.usb: new USB bus registered, assigned bus number 2
orion-ehci d0051000.usb: irq 26, io mem 0xd0051000
orion-ehci d0051000.usb: USB 2.0 started, EHCI 1.00
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 1 port detected
xhci_hcd 0000:02:00.0: xHCI Host Controller
xhci_hcd 0000:02:00.0: new USB bus registered, assigned bus number 3
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
xhci_hcd 0000:02:00.0: xHCI Host Controller
xhci_hcd 0000:02:00.0: new USB bus registered, assigned bus number 4
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
usbcore: registered new interface driver usb-storage
rtc-mv d0010300.rtc: rtc core: registered d0010300.rtc as rtc0
i2c /dev entries driver
rtc-pcf8563 0-0051: chip found, driver version 0.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Gregory CLEMENT]

Hi Sebastian,

Post by Sebastian Hesselbarth
[...]

Post by Benoit Masson
NR_IRQS:16 nr_irqs:16 16
L2C: device tree omits to specify unified cache

Jason, Thomas, Gregory,
we should add a "cache-unified" to the l2cc nodes for all SoCs.

Right,
I take care of it.


Thanks,

Gregory
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Gregory CLEMENT]

Hi Benoit,

Post by Sebastian Hesselbarth

Post by Benoit Masson
NR_IRQS:16 nr_irqs:16 16
L2C: device tree omits to specify unified cache

Jason, Thomas, Gregory,
we should add a "cache-unified" to the l2cc nodes for all SoCs.

It seems all armada dtsi using marvell,aurora-system-cache doesn't have the "cache-unified" entry isn't this on purpose ?

No it was not really done in purpose. It was missing from the beginning.
As the aurora l2cc was not a real l2x0 l2cc we put the minimal configuration.
But I've just checked and the aurora l2cc is unified too, so a patch
is coming soon to update the dtsi for Armada 370 and Armada XP.
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Sebastian Hesselbarth]

Post by Benoit Masson

[...]

Post by Sebastian Hesselbarth

Post by Jason Cooper

Post by Benoit Masson

Patches are based on v3.17-rc1 and intended for v3.18 but I am not in
a hurry. I only compile tested this, so a formal Tested-by from Benoit
for the ix4 and any other Armada XP board would be great.

I'm not sure what to test since I only receive some patch from the
series of 8. Should I get all 8 or only those you sent me. I'll be
able to test during next week.

Did you ever get a chance to test this series?

Uhm, I never prepared a branch for Benoit to test. I have pushed the
patches with Thomas Acked-by's and renamed eeprom node based on
v3.17-rc1 to
https://github.com/shesselba/linux-dove.git devel/mvebu-ix4

[...]

Maybe I missed something ? is this branch you sent me a bare fork
from mainline 3.17 ? does it includes the armada XP step A0 patch ?

Benoit,

I prepared more branches with the series
- on top of v3.17 release:
https://github.com/shesselba/linux-dove.git devel/mvebu-ix4_v3.17

- on top of next-20141003 (i.e. what will become v3.18-rc1):
https://github.com/shesselba/linux-dove.git devel/mvebu-ix4_next-20141003

It would be great, if you can test in this order:
- vanilla v3.17
- mvebu-ix4_v3.17
- mvebu-ix4_next-20141003

If any branch fails, you can stop and please report back.

I also have the ix4 but I need more time for a full setup like you
already seem to have ready. Again, there is no hurry, take your time.

Thanks!

Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Benoit Masson]

Post by Jason Cooper

Post by Benoit Masson

[...]

Post by Sebastian Hesselbarth

Post by Jason Cooper

Post by Benoit Masson

Patches are based on v3.17-rc1 and intended for v3.18 but I am not in
a hurry. I only compile tested this, so a formal Tested-by from Benoit
for the ix4 and any other Armada XP board would be great.

I'm not sure what to test since I only receive some patch from the
series of 8. Should I get all 8 or only those you sent me. I'll be
able to test during next week.

Did you ever get a chance to test this series?

Uhm, I never prepared a branch for Benoit to test. I have pushed the
patches with Thomas Acked-by's and renamed eeprom node based on
v3.17-rc1 to
https://github.com/shesselba/linux-dove.git devel/mvebu-ix4

[...]

Maybe I missed something ? is this branch you sent me a bare fork
from mainline 3.17 ? does it includes the armada XP step A0 patch ?

Benoit,

Hi,

Post by Jason Cooper
I prepared more branches with the series
https://github.com/shesselba/linux-dove.git devel/mvebu-ix4_v3.17
https://github.com/shesselba/linux-dove.git devel/mvebu-ix4_next-20141003
- vanilla v3.17
- mvebu-ix4_v3.17
- mvebu-ix4_next-20141003

All the 3 branch works WHEN APPLYING A0 patch (below), with both my custom kernel config and the arch/arm/configs/mvebu_v7_defconfig

The reason why it didn't worked last time was that apparently the A0 patch (copied) below was not merged into 3.17 :(

This means that ix4-300d support is broken on 3.17 because of the A0 stepping patch not merged.

patch (from Andrew Lunn Acked-by Gregory Clement is missing:

---
arch/arm/mach-mvebu/board-v7.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-mvebu/board-v7.c b/arch/arm/mach-mvebu/board-v7.c
index b2524d6..b1e148d 100644
--- a/arch/arm/mach-mvebu/board-v7.c
+++ b/arch/arm/mach-mvebu/board-v7.c
@@ -174,7 +174,7 @@ static void __init thermal_quirk(void)

static void __init mvebu_dt_init(void)
{
- if (of_machine_is_compatible("plathome,openblocks-ax3-4"))
+ if (of_machine_is_compatible("marvell,armadaxp"))
i2c_quirk();
if (of_machine_is_compatible("marvell,a375-db")) {
external_abort_quirk();
--
1.9.1

Post by Jason Cooper
If any branch fails, you can stop and please report back.
I also have the ix4 but I need more time for a full setup like you
already seem to have ready. Again, there is no hurry, take your time.
Thanks!
Sebastian

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Andrew Lunn]

Post by Benoit Masson
All the 3 branch works WHEN APPLYING A0 patch (below), with both my custom kernel config and the arch/arm/configs/mvebu_v7_defconfig

"hwclock: select() to /dev/rtc1 to wait for clock tick timed out: Success"
where rtc1 if the i2c rtc connected to the i2C bus, can this be related to the i2c patch that would slow down i2c operation or somthing ?

Hi Benoit

It won't fix your problem, but if the built in RTC is not usable, it
would be good to disable it in the .dts file. The i2c RTC will then
become RTC0.


The actual "error" message is odd:
"hwclock: select() to /dev/rtc1 to wait for clock tick timed out: Success"

Success means it actually worked, not an error. Does the RTC contain
the correct time afterwards?

Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Benoit Masson]

Post by Gregory CLEMENT

Post by Benoit Masson
All the 3 branch works WHEN APPLYING A0 patch (below), with both my custom kernel config and the arch/arm/configs/mvebu_v7_defconfig

"hwclock: select() to /dev/rtc1 to wait for clock tick timed out: Success"
where rtc1 if the i2c rtc connected to the i2C bus, can this be related to the i2c patch that would slow down i2c operation or somthing ?

Hi Benoit
It won't fix your problem, but if the built in RTC is not usable, it
would be good to disable it in the .dts file. The i2c RTC will then
become RTC0.
"hwclock: select() to /dev/rtc1 to wait for clock tick timed out: Success"

Yes this is the wired thing is that everything works, even getting the date via "cat /sys/class/i2c-adapter/i2c-0/0-0051/rtc/rtc1/time" is ok
reading the rtc driver code it seems this message is shown when multiple resources try to access shared rtc... but why now and not before ?

So I was wondering if the i2c_quirk() applied by the batch has any effect with this ?

Anyhow I'll handle the message for now and see if there are performance impact on this...

Benoit

Post by Gregory CLEMENT
Success means it actually worked, not an error. Does the RTC contain
the correct time afterwards?
Andrew

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Jason Cooper]

Post by Benoit Masson

Post by Jason Cooper

Post by Benoit Masson

[...]

Post by Sebastian Hesselbarth

Post by Jason Cooper

Post by Benoit Masson

Patches are based on v3.17-rc1 and intended for v3.18 but I am not in
a hurry. I only compile tested this, so a formal Tested-by from Benoit
for the ix4 and any other Armada XP board would be great.

I'm not sure what to test since I only receive some patch from the
series of 8. Should I get all 8 or only those you sent me. I'll be
able to test during next week.

Did you ever get a chance to test this series?

Uhm, I never prepared a branch for Benoit to test. I have pushed the
patches with Thomas Acked-by's and renamed eeprom node based on
v3.17-rc1 to
https://github.com/shesselba/linux-dove.git devel/mvebu-ix4

[...]

Maybe I missed something ? is this branch you sent me a bare fork
from mainline 3.17 ? does it includes the armada XP step A0 patch ?

Benoit,

Hi,

Post by Jason Cooper
I prepared more branches with the series
https://github.com/shesselba/linux-dove.git devel/mvebu-ix4_v3.17
https://github.com/shesselba/linux-dove.git devel/mvebu-ix4_next-20141003
- vanilla v3.17
- mvebu-ix4_v3.17
- mvebu-ix4_next-20141003

All the 3 branch works WHEN APPLYING A0 patch (below), with both my custom kernel config and the arch/arm/configs/mvebu_v7_defconfig
The reason why it didn't worked last time was that apparently the A0 patch (copied) below was not merged into 3.17 :(
This means that ix4-300d support is broken on 3.17 because of the A0 stepping patch not merged.

Do you have a link to an email thread or the patch Subject line? I can
confirm it's missing from mvebu/fixes...

thx,

Jason.

Post by Benoit Masson
---
arch/arm/mach-mvebu/board-v7.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-mvebu/board-v7.c b/arch/arm/mach-mvebu/board-v7.c
index b2524d6..b1e148d 100644
--- a/arch/arm/mach-mvebu/board-v7.c
+++ b/arch/arm/mach-mvebu/board-v7.c
@@ -174,7 +174,7 @@ static void __init thermal_quirk(void)
static void __init mvebu_dt_init(void)
{
- if (of_machine_is_compatible("plathome,openblocks-ax3-4"))
+ if (of_machine_is_compatible("marvell,armadaxp"))
i2c_quirk();
if (of_machine_is_compatible("marvell,a375-db")) {
external_abort_quirk();
--
1.9.1

Post by Jason Cooper
If any branch fails, you can stop and please report back.
I also have the ix4 but I need more time for a full setup like you
already seem to have ready. Again, there is no hurry, take your time.
Thanks!
Sebastian

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Sebastian Hesselbarth]

Post by Jason Cooper

Post by Benoit Masson

Post by Sebastian Hesselbarth
I prepared more branches with the series
https://github.com/shesselba/linux-dove.git devel/mvebu-ix4_v3.17
https://github.com/shesselba/linux-dove.git devel/mvebu-ix4_next-20141003
- vanilla v3.17
- mvebu-ix4_v3.17
- mvebu-ix4_next-20141003

All the 3 branch works WHEN APPLYING A0 patch (below), with both my custom kernel config and the arch/arm/configs/mvebu_v7_defconfig
The reason why it didn't worked last time was that apparently the A0 patch (copied) below was not merged into 3.17 :(
This means that ix4-300d support is broken on 3.17 because of the A0 stepping patch not merged.

Do you have a link to an email thread or the patch Subject line? I can
confirm it's missing from mvebu/fixes...

http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/275487.html

But you and Andrew should check what Arnd suggested. IIRC, there
was also an appropriate follow-up patch discussion started by
Andrew.

Sebastian

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Andrew Lunn]

Post by Sebastian Hesselbarth

Post by Jason Cooper
Do you have a link to an email thread or the patch Subject line? I can
confirm it's missing from mvebu/fixes...

http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/275487.html
But you and Andrew should check what Arnd suggested. IIRC, there
was also an appropriate follow-up patch discussion started by
Andrew.

There was a lot of back and forth with Arnd. In the end, he gave up
arguing because too many voices did not like his solution. So my
original version stands.

However, the patch at the end of

http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/275528.html

is useful, and it would be nice if it could be merged as well.

Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Jason Cooper]

Post by Andrew Lunn

Post by Sebastian Hesselbarth

Post by Jason Cooper
Do you have a link to an email thread or the patch Subject line? I can
confirm it's missing from mvebu/fixes...

http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/275487.html
But you and Andrew should check what Arnd suggested. IIRC, there
was also an appropriate follow-up patch discussion started by
Andrew.

There was a lot of back and forth with Arnd. In the end, he gave up
arguing because too many voices did not like his solution. So my
original version stands.

Yes, this appears to have been a mistake on my part. In the
conversation regarding patch #2 of V2, you said you were going to work
on implementing something and would report back. I applied that to the
whole series instead of just to the second patch. At any rate, applied
to mvebu/fixes now.

Post by Andrew Lunn
However, the patch at the end of
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/275528.html
is useful, and it would be nice if it could be merged as well.

I'll take a look.

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Jason Cooper]

Post by Jason Cooper

Post by Andrew Lunn

Post by Sebastian Hesselbarth

Post by Jason Cooper
Do you have a link to an email thread or the patch Subject line? I can
confirm it's missing from mvebu/fixes...

http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/275487.html
But you and Andrew should check what Arnd suggested. IIRC, there
was also an appropriate follow-up patch discussion started by
Andrew.

There was a lot of back and forth with Arnd. In the end, he gave up
arguing because too many voices did not like his solution. So my
original version stands.

Yes, this appears to have been a mistake on my part. In the
conversation regarding patch #2 of V2, you said you were going to work
on implementing something and would report back. I applied that to the
whole series instead of just to the second patch. At any rate, applied
to mvebu/fixes now.

Post by Andrew Lunn
However, the patch at the end of
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/275528.html
is useful, and it would be nice if it could be merged as well.

I'll take a look.

I'd still like to see that note captured in the binding doc. Did I miss
another patch somewhere?

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Jason Cooper]

Post by Benoit Masson

Post by Jason Cooper

Post by Benoit Masson

[...]

Post by Sebastian Hesselbarth

Post by Jason Cooper

Post by Benoit Masson

Patches are based on v3.17-rc1 and intended for v3.18 but I am not in
a hurry. I only compile tested this, so a formal Tested-by from Benoit
for the ix4 and any other Armada XP board would be great.

I'm not sure what to test since I only receive some patch from the
series of 8. Should I get all 8 or only those you sent me. I'll be
able to test during next week.

Did you ever get a chance to test this series?

Uhm, I never prepared a branch for Benoit to test. I have pushed the
patches with Thomas Acked-by's and renamed eeprom node based on
v3.17-rc1 to
https://github.com/shesselba/linux-dove.git devel/mvebu-ix4

[...]

Maybe I missed something ? is this branch you sent me a bare fork
from mainline 3.17 ? does it includes the armada XP step A0 patch ?

Benoit,

Hi,

Post by Jason Cooper
I prepared more branches with the series
https://github.com/shesselba/linux-dove.git devel/mvebu-ix4_v3.17
https://github.com/shesselba/linux-dove.git devel/mvebu-ix4_next-20141003
- vanilla v3.17
- mvebu-ix4_v3.17
- mvebu-ix4_next-20141003

All the 3 branch works WHEN APPLYING A0 patch (below), with both my
custom kernel config and the arch/arm/configs/mvebu_v7_defconfig

Can I count this as a Tested-by?

Post by Benoit Masson
The reason why it didn't worked last time was that apparently the A0
patch (copied) below was not merged into 3.17 :(

Yep, sorry. Life got the best of me. The pull request is now sent.

Post by Benoit Masson
This means that ix4-300d support is broken on 3.17 because of the A0
stepping patch not merged.

Not a problem. It's flagged for stable v3.12 and up.

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Jason Cooper]

Sebastian,

Guys,
this is a patch set preparing barebox support for ix4-300d. As usual,
I stumbled upon a few nice-to-haves before actually touching ix4-300d
dts. As it is a mach-mvebu thing, I just added the related mailing
lists instead of each of the DT maintainers.
First 5 patches consolidate SoC-specific pinctrl nodes to one common
node in armada-xp.dtsi, compatible overwrites for each SoC, and node
alias usage for each board. Also, ge{0,1} pinctrl settings are moved
to the common node from one board specific node.
Last 3 patches then use that ge{0,1} pinctrl settings on ix4-300d which
is vital for bootloader init. During exploration of ix4-300d, I also
found a i2c eeprom that has not been added to the dts, yet. Finally,
there is only one 74hc595 on ix4 mainboard while dts property is set
for two.
I cannot recall in detail what is on that eeprom, but IIRC it is nothing
important. Some reg,addr pairs for some init stuff that should have
already been done by stock u-boot. Anyway, adding the node will do no
harm.
Patches are based on v3.17-rc1 and intended for v3.18 but I am not in
a hurry. I only compile tested this, so a formal Tested-by from Benoit
for the ix4 and any other Armada XP board would be great.

I lost track of this thread, are you resending? Did Benoit get a
successful test run?

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Sebastian Hesselbarth]

Post by Jason Cooper

this is a patch set preparing barebox support for ix4-300d. As usual,
I stumbled upon a few nice-to-haves before actually touching ix4-300d
dts. As it is a mach-mvebu thing, I just added the related mailing
lists instead of each of the DT maintainers.
First 5 patches consolidate SoC-specific pinctrl nodes to one common
node in armada-xp.dtsi, compatible overwrites for each SoC, and node
alias usage for each board. Also, ge{0,1} pinctrl settings are moved
to the common node from one board specific node.
Last 3 patches then use that ge{0,1} pinctrl settings on ix4-300d which
is vital for bootloader init. During exploration of ix4-300d, I also
found a i2c eeprom that has not been added to the dts, yet. Finally,
there is only one 74hc595 on ix4 mainboard while dts property is set
for two.
I cannot recall in detail what is on that eeprom, but IIRC it is nothing
important. Some reg,addr pairs for some init stuff that should have
already been done by stock u-boot. Anyway, adding the node will do no
harm.
Patches are based on v3.17-rc1 and intended for v3.18 but I am not in
a hurry. I only compile tested this, so a formal Tested-by from Benoit
for the ix4 and any other Armada XP board would be great.

I lost track of this thread, are you resending? Did Benoit get a
successful test run?

Looks like there was this A0 stepping thing, but basically yes

http://www.spinics.net/lists/devicetree/msg53364.html

I have just rebased it on top of v3.18-rc1, feel free to pick them
up from

git://git.infradead.org/users/hesselba/linux-berlin.git devel/mvebu/ix4-300d
git://git.infradead.org/users/hesselba/linux-berlin.git
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Jason Cooper]

Post by Sebastian Hesselbarth

Post by Jason Cooper

this is a patch set preparing barebox support for ix4-300d. As usual,
I stumbled upon a few nice-to-haves before actually touching ix4-300d
dts. As it is a mach-mvebu thing, I just added the related mailing
lists instead of each of the DT maintainers.
First 5 patches consolidate SoC-specific pinctrl nodes to one common
node in armada-xp.dtsi, compatible overwrites for each SoC, and node
alias usage for each board. Also, ge{0,1} pinctrl settings are moved
to the common node from one board specific node.
Last 3 patches then use that ge{0,1} pinctrl settings on ix4-300d which
is vital for bootloader init. During exploration of ix4-300d, I also
found a i2c eeprom that has not been added to the dts, yet. Finally,
there is only one 74hc595 on ix4 mainboard while dts property is set
for two.
I cannot recall in detail what is on that eeprom, but IIRC it is nothing
important. Some reg,addr pairs for some init stuff that should have
already been done by stock u-boot. Anyway, adding the node will do no
harm.
Patches are based on v3.17-rc1 and intended for v3.18 but I am not in
a hurry. I only compile tested this, so a formal Tested-by from Benoit
for the ix4 and any other Armada XP board would be great.

I lost track of this thread, are you resending? Did Benoit get a
successful test run?

Looks like there was this A0 stepping thing, but basically yes
http://www.spinics.net/lists/devicetree/msg53364.html
I have just rebased it on top of v3.18-rc1, feel free to pick them
up from
git://git.infradead.org/users/hesselba/linux-berlin.git devel/mvebu/ix4-300d
git://git.infradead.org/users/hesselba/linux-berlin.git

Ahh, that's right. Do you still use the github repo? I hadn't added
your infradead as a remote yet.

At any rate, I cherry-picked them and added Benoit's Tested-by's. So if
you had this branch in -next, please remove it before tonight's run.

Applied to mvebu/dt.

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Sebastian Hesselbarth]

Post by Jason Cooper

Post by Sebastian Hesselbarth

Post by Jason Cooper

this is a patch set preparing barebox support for ix4-300d. As usual,
I stumbled upon a few nice-to-haves before actually touching ix4-300d
dts. As it is a mach-mvebu thing, I just added the related mailing
lists instead of each of the DT maintainers.
First 5 patches consolidate SoC-specific pinctrl nodes to one common
node in armada-xp.dtsi, compatible overwrites for each SoC, and node
alias usage for each board. Also, ge{0,1} pinctrl settings are moved
to the common node from one board specific node.
Last 3 patches then use that ge{0,1} pinctrl settings on ix4-300d which
is vital for bootloader init. During exploration of ix4-300d, I also
found a i2c eeprom that has not been added to the dts, yet. Finally,
there is only one 74hc595 on ix4 mainboard while dts property is set
for two.
I cannot recall in detail what is on that eeprom, but IIRC it is nothing
important. Some reg,addr pairs for some init stuff that should have
already been done by stock u-boot. Anyway, adding the node will do no
harm.
Patches are based on v3.17-rc1 and intended for v3.18 but I am not in
a hurry. I only compile tested this, so a formal Tested-by from Benoit
for the ix4 and any other Armada XP board would be great.

I lost track of this thread, are you resending? Did Benoit get a
successful test run?

Looks like there was this A0 stepping thing, but basically yes
http://www.spinics.net/lists/devicetree/msg53364.html
I have just rebased it on top of v3.18-rc1, feel free to pick them
up from
git://git.infradead.org/users/hesselba/linux-berlin.git devel/mvebu/ix4-300d
git://git.infradead.org/users/hesselba/linux-berlin.git

Ahh, that's right. Do you still use the github repo? I hadn't added
your infradead as a remote yet.

Usually, I use github for mvebu and infradead for berlin. But this time
I was too lazy to either boot-up the other laptop or clone the github
repo ;)

Post by Jason Cooper
At any rate, I cherry-picked them and added Benoit's Tested-by's. So if
you had this branch in -next, please remove it before tonight's run.

I _did not_ put it into any -next branch. It's mvebu and that is your
git tree, I only put berlin patches into -next ;)

Post by Jason Cooper
Applied to mvebu/dt.

Thanks for having an eye on this patches, I almost forgot about them.

Sebastian

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/