[PATCH 0/3] Update the Keymile kirkwood DTS files

[PATCH 0/3] Update the Keymile kirkwood DTS files

[Valentin Longchamp]

This series resynchs the Keymile Kirkwood DTS files with mainline since
the boards do not boot anymore with the 3.15 rc kernels (to be honest, I
have not tested the last 2-3 releases).

The changes are the addition of the PCIe controller for the 98dx4122
SoC, the explicit disabling of the SATA phys for this same SoC and
finally the enabling of the PCIe controller on the Keymile Reference
design.

The series also adds a new DTS for another Keymile generic design where
the mv64xxx eth interace is configured with fixed parameters to no phy
but a switch (for board internal communication).

The series applies and was tested on top of Jason's mvebu/dt branch
(mvebu-dt-3.16 tag).


Valentin Longchamp (3):
  ARM: dts: kirkwood: resynch 98dx4122 dtsi
  ARM: dts: kirkwood: enable the PCIe for km_kirkwood
  ARM: dts: kirkwood: add kirkwood-km_fixedeth DTS file

 arch/arm/boot/dts/kirkwood-98dx4122.dtsi   | 43 ++++++++++++++++++
 arch/arm/boot/dts/kirkwood-km_fixedeth.dts | 70 ++++++++++++++++++++++++++++++
 arch/arm/boot/dts/kirkwood-km_kirkwood.dts | 10 +++++
 3 files changed, 123 insertions(+)
 create mode 100644 arch/arm/boot/dts/kirkwood-km_fixedeth.dts

-- 
1.8.0.1

[PATCH 1/3] ARM: dts: kirkwood: resynch 98dx4122 dtsi

[Valentin Longchamp]

The 98DX4122 dtsi file lacks the defintion of the PCIe controller which
is present on this SoC.

The SATA phys must also be explicitely disabled since they are not
present on this SoC. If they remain enabled, a hardlock occures when
their clock gates are enabled.

Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
---

 arch/arm/boot/dts/kirkwood-98dx4122.dtsi | 43 ++++++++++++++++++++++++++++++++
 1 file changed, 43 insertions(+)

diff --git a/arch/arm/boot/dts/kirkwood-98dx4122.dtsi b/arch/arm/boot/dts/kirkwood-98dx4122.dtsi
index 2e8e412..9e1f741 100644
--- a/arch/arm/boot/dts/kirkwood-98dx4122.dtsi
+++ b/arch/arm/boot/dts/kirkwood-98dx4122.dtsi
@@ -1,4 +1,39 @@
 / {
+	mbus {
+		pciec: pcie-controller {
+			compatible = "marvell,kirkwood-pcie";
+			status = "disabled";
+			device_type = "pci";
+
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			bus-range = <0x00 0xff>;
+
+			ranges =
+			       <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000
+				0x82000000 0x1 0     MBUS_ID(0x04, 0xe8) 0       1 0 /* Port 0.0 MEM */
+				0x81000000 0x1 0     MBUS_ID(0x04, 0xe0) 0       1 0 /* Port 0.0 IO  */>;
+
+			pcie0: pcie at 1,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x00040000 0 0x2000>;
+				reg = <0x0800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0
+					  0x81000000 0 0 0x81000000 0x1 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &intc 9>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gate_clk 2>;
+				status = "disabled";
+			};
+		};
+	};
+
 	ocp at f1000000 {
 		pinctrl: pin-controller at 10000 {
 			compatible = "marvell,98dx4122-pinctrl";
@@ -6,3 +41,11 @@
 		};
 	};
 };
+
+&sata_phy0 {
+	status = "disabled";
+};
+
+&sata_phy1 {
+	status = "disabled";
+};
-- 
1.8.0.1

[PATCH 1/3] ARM: dts: kirkwood: resynch 98dx4122 dtsi

[Sebastian Hesselbarth]

On 05/15/2014 11:48 AM, Valentin Longchamp wrote:
> The 98DX4122 dtsi file lacks the defintion of the PCIe controller which
> is present on this SoC.

Valentin,

good to have you back on 98dx4122. I was already thinking about
reworking the current kirkwood.dtsi and kirkwood-<soc>.dtsi as I
feel there may be more issues with "common" IP that was removed
in 98dx4122.

> The SATA phys must also be explicitely disabled since they are not
> present on this SoC. If they remain enabled, a hardlock occures when
> their clock gates are enabled.

While I am ok with disabling now, we should really rethink the
current SoC-specific includes as we are already facing some issues
that cause headaches.

Actually, the initial idea was to remove all nodes from kirkwood.dtsi
that are not available in one of the SoCs and rather put them into
the SoC-specific include.

But over time we end up with a mix of both, SoC-specific nodes like
pcie below _and_ SoC-specific fixes like sata-phy below.

To be consitent, we should either duplicate the sata-phy nodes in
kirkwood-6foo.dtsi - or what I prefer - move most of it back to
kirkwood.dtsi and use "disabled" in the SoC-specific ones.

Although, it would be nice to have a common include and SoC-specific
include on top, I have the strong feeling we may never be able to
cleanly separate them.

For the patch itself, you get a tentative

Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>

to make KM boot again.

Sebastian

> Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
> ---
>
>   arch/arm/boot/dts/kirkwood-98dx4122.dtsi | 43 ++++++++++++++++++++++++++++++++
>   1 file changed, 43 insertions(+)
>
> diff --git a/arch/arm/boot/dts/kirkwood-98dx4122.dtsi b/arch/arm/boot/dts/kirkwood-98dx4122.dtsi
> index 2e8e412..9e1f741 100644
> --- a/arch/arm/boot/dts/kirkwood-98dx4122.dtsi
> +++ b/arch/arm/boot/dts/kirkwood-98dx4122.dtsi
> @@ -1,4 +1,39 @@
>   / {
> +	mbus {
> +		pciec: pcie-controller {
> +			compatible = "marvell,kirkwood-pcie";
> +			status = "disabled";
> +			device_type = "pci";
> +
> +			#address-cells = <3>;
> +			#size-cells = <2>;
> +
> +			bus-range = <0x00 0xff>;
> +
> +			ranges =
> +			       <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000
> +				0x82000000 0x1 0     MBUS_ID(0x04, 0xe8) 0       1 0 /* Port 0.0 MEM */
> +				0x81000000 0x1 0     MBUS_ID(0x04, 0xe0) 0       1 0 /* Port 0.0 IO  */>;
> +
> +			pcie0: pcie at 1,0 {
> +				device_type = "pci";
> +				assigned-addresses = <0x82000800 0 0x00040000 0 0x2000>;
> +				reg = <0x0800 0 0 0 0>;
> +				#address-cells = <3>;
> +				#size-cells = <2>;
> +				#interrupt-cells = <1>;
> +				ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0
> +					  0x81000000 0 0 0x81000000 0x1 0 1 0>;
> +				interrupt-map-mask = <0 0 0 0>;
> +				interrupt-map = <0 0 0 0 &intc 9>;
> +				marvell,pcie-port = <0>;
> +				marvell,pcie-lane = <0>;
> +				clocks = <&gate_clk 2>;
> +				status = "disabled";
> +			};
> +		};
> +	};
> +
>   	ocp at f1000000 {
>   		pinctrl: pin-controller at 10000 {
>   			compatible = "marvell,98dx4122-pinctrl";
> @@ -6,3 +41,11 @@
>   		};
>   	};
>   };
> +
> +&sata_phy0 {
> +	status = "disabled";
> +};
> +
> +&sata_phy1 {
> +	status = "disabled";
> +};
>

[PATCH 1/3] ARM: dts: kirkwood: resynch 98dx4122 dtsi

[Valentin Longchamp]

On 05/15/2014 12:35 PM, Sebastian Hesselbarth wrote:
> On 05/15/2014 11:48 AM, Valentin Longchamp wrote:
>> The 98DX4122 dtsi file lacks the defintion of the PCIe controller which
>> is present on this SoC.
> 
> Valentin,
> 
> good to have you back on 98dx4122. I was already thinking about
> reworking the current kirkwood.dtsi and kirkwood-<soc>.dtsi as I
> feel there may be more issues with "common" IP that was removed
> in 98dx4122.
> 
>> The SATA phys must also be explicitely disabled since they are not
>> present on this SoC. If they remain enabled, a hardlock occures when
>> their clock gates are enabled.
> 
> While I am ok with disabling now, we should really rethink the
> current SoC-specific includes as we are already facing some issues
> that cause headaches.
> 
> Actually, the initial idea was to remove all nodes from kirkwood.dtsi
> that are not available in one of the SoCs and rather put them into
> the SoC-specific include.
> 
> But over time we end up with a mix of both, SoC-specific nodes like
> pcie below _and_ SoC-specific fixes like sata-phy below.
> 
> To be consitent, we should either duplicate the sata-phy nodes in
> kirkwood-6foo.dtsi - or what I prefer - move most of it back to
> kirkwood.dtsi and use "disabled" in the SoC-specific ones.

For the sake of the disscussion, we also have some powerPC boards here at
Keymile and there the approach is exactly the one you prefer above. First I was
a bit confused but now I think this approach is "cleaner" (or makes more sense
to me ;-)).

> 
> Although, it would be nice to have a common include and SoC-specific
> include on top, I have the strong feeling we may never be able to
> cleanly separate them.
> 
> For the patch itself, you get a tentative
> 
> Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> 
> to make KM boot again.

Thanks.

> 
> Sebastian
> 
>> Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
>> ---
>>
>>   arch/arm/boot/dts/kirkwood-98dx4122.dtsi | 43 ++++++++++++++++++++++++++++++++
>>   1 file changed, 43 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/kirkwood-98dx4122.dtsi b/arch/arm/boot/dts/kirkwood-98dx4122.dtsi
>> index 2e8e412..9e1f741 100644
>> --- a/arch/arm/boot/dts/kirkwood-98dx4122.dtsi
>> +++ b/arch/arm/boot/dts/kirkwood-98dx4122.dtsi
>> @@ -1,4 +1,39 @@
>>   / {
>> +	mbus {
>> +		pciec: pcie-controller {
>> +			compatible = "marvell,kirkwood-pcie";
>> +			status = "disabled";
>> +			device_type = "pci";
>> +
>> +			#address-cells = <3>;
>> +			#size-cells = <2>;
>> +
>> +			bus-range = <0x00 0xff>;
>> +
>> +			ranges =
>> +			       <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000
>> +				0x82000000 0x1 0     MBUS_ID(0x04, 0xe8) 0       1 0 /* Port 0.0 MEM */
>> +				0x81000000 0x1 0     MBUS_ID(0x04, 0xe0) 0       1 0 /* Port 0.0 IO  */>;
>> +
>> +			pcie0: pcie at 1,0 {
>> +				device_type = "pci";
>> +				assigned-addresses = <0x82000800 0 0x00040000 0 0x2000>;
>> +				reg = <0x0800 0 0 0 0>;
>> +				#address-cells = <3>;
>> +				#size-cells = <2>;
>> +				#interrupt-cells = <1>;
>> +				ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0
>> +					  0x81000000 0 0 0x81000000 0x1 0 1 0>;
>> +				interrupt-map-mask = <0 0 0 0>;
>> +				interrupt-map = <0 0 0 0 &intc 9>;
>> +				marvell,pcie-port = <0>;
>> +				marvell,pcie-lane = <0>;
>> +				clocks = <&gate_clk 2>;
>> +				status = "disabled";
>> +			};
>> +		};
>> +	};
>> +
>>   	ocp at f1000000 {
>>   		pinctrl: pin-controller at 10000 {
>>   			compatible = "marvell,98dx4122-pinctrl";
>> @@ -6,3 +41,11 @@
>>   		};
>>   	};
>>   };
>> +
>> +&sata_phy0 {
>> +	status = "disabled";
>> +};
>> +
>> +&sata_phy1 {
>> +	status = "disabled";
>> +};
>>
> 

[PATCH 1/3] ARM: dts: kirkwood: resynch 98dx4122 dtsi

[Jason Cooper]

On Thu, May 15, 2014 at 01:11:40PM +0200, Valentin Longchamp wrote:
> On 05/15/2014 12:35 PM, Sebastian Hesselbarth wrote:
> > On 05/15/2014 11:48 AM, Valentin Longchamp wrote:
> >> The 98DX4122 dtsi file lacks the defintion of the PCIe controller which
> >> is present on this SoC.
> > 
> > Valentin,
> > 
> > good to have you back on 98dx4122. I was already thinking about
> > reworking the current kirkwood.dtsi and kirkwood-<soc>.dtsi as I
> > feel there may be more issues with "common" IP that was removed
> > in 98dx4122.
> > 
> >> The SATA phys must also be explicitely disabled since they are not
> >> present on this SoC. If they remain enabled, a hardlock occures when
> >> their clock gates are enabled.
> > 
> > While I am ok with disabling now, we should really rethink the
> > current SoC-specific includes as we are already facing some issues
> > that cause headaches.
> > 
> > Actually, the initial idea was to remove all nodes from kirkwood.dtsi
> > that are not available in one of the SoCs and rather put them into
> > the SoC-specific include.
> > 
> > But over time we end up with a mix of both, SoC-specific nodes like
> > pcie below _and_ SoC-specific fixes like sata-phy below.
> > 
> > To be consitent, we should either duplicate the sata-phy nodes in
> > kirkwood-6foo.dtsi - or what I prefer - move most of it back to
> > kirkwood.dtsi and use "disabled" in the SoC-specific ones.
> 
> For the sake of the disscussion, we also have some powerPC boards here at
> Keymile and there the approach is exactly the one you prefer above. First I was
> a bit confused but now I think this approach is "cleaner" (or makes more sense
> to me ;-)).

No complaints here either. :)

thx,

Jason.

[PATCH 2/3] ARM: dts: kirkwood: enable the PCIe for km_kirkwood

[Valentin Longchamp]

The PCIe controller is used on the KM kirkwood reference design.
This enables it.

Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
---

 arch/arm/boot/dts/kirkwood-km_kirkwood.dts | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/kirkwood-km_kirkwood.dts b/arch/arm/boot/dts/kirkwood-km_kirkwood.dts
index 61139bf..9f57796 100644
--- a/arch/arm/boot/dts/kirkwood-km_kirkwood.dts
+++ b/arch/arm/boot/dts/kirkwood-km_kirkwood.dts
@@ -17,6 +17,16 @@
 		stdout-path = &uart0;
 	};
 
+	mbus {
+		pcie-controller {
+			status = "okay";
+
+			pcie at 1,0 {
+				status = "okay";
+			};
+		};
+	};
+
 	ocp at f1000000 {
 		pinctrl: pin-controller at 10000 {
 			pinctrl-0 = < &pmx_i2c_gpio_sda &pmx_i2c_gpio_scl >;
-- 
1.8.0.1

[PATCH 3/3] ARM: dts: kirkwood: add kirkwood-km_fixedeth DTS file

[Valentin Longchamp]

Besides our Kirkwood Reference design, there is another group of board
on which the eth interface is not connected to a phy but to a swtich for
some board internal communication.

The configuration of the switch is handled by an EEPROM or by the
bootloader, but on the kirkwood side, the port is always configured as
1000 Mbits, full duplex.

Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>

---

 arch/arm/boot/dts/kirkwood-km_fixedeth.dts | 70 ++++++++++++++++++++++++++++++
 1 file changed, 70 insertions(+)
 create mode 100644 arch/arm/boot/dts/kirkwood-km_fixedeth.dts

diff --git a/arch/arm/boot/dts/kirkwood-km_fixedeth.dts b/arch/arm/boot/dts/kirkwood-km_fixedeth.dts
new file mode 100644
index 0000000..3d54d9b
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-km_fixedeth.dts
@@ -0,0 +1,70 @@
+/dts-v1/;
+
+#include "kirkwood.dtsi"
+#include "kirkwood-98dx4122.dtsi"
+
+/ {
+	model = "Keymile Kirkwood Fixed Eth";
+	compatible = "keymile,km_fixedeth", "marvell,kirkwood-98DX4122", "marvell,kirkwood";
+
+	memory {
+		device_type = "memory";
+		reg = <0x00000000 0x08000000>;
+	};
+
+	chosen {
+		bootargs = "console=ttyS0,115200n8 earlyprintk";
+		stdout-path = &uart0;
+	};
+
+	mbus {
+		pcie-controller {
+			status = "okay";
+
+			pcie at 1,0 {
+				status = "okay";
+			};
+		};
+	};
+
+	ocp at f1000000 {
+		pinctrl: pin-controller at 10000 {
+			pinctrl-0 = < &pmx_i2c_gpio_sda &pmx_i2c_gpio_scl >;
+			pinctrl-names = "default";
+
+			pmx_i2c_gpio_sda: pmx-gpio-sda {
+				marvell,pins = "mpp8";
+				marvell,function = "gpio";
+			};
+			pmx_i2c_gpio_scl: pmx-gpio-scl {
+				marvell,pins = "mpp9";
+				marvell,function = "gpio";
+			};
+		};
+
+		serial at 12000 {
+			status = "ok";
+		};
+	};
+
+	i2c at 0 {
+		compatible = "i2c-gpio";
+		gpios = < &gpio0 8 GPIO_ACTIVE_HIGH		/* sda */
+			  &gpio0 9 GPIO_ACTIVE_HIGH>;		/* scl */
+		i2c-gpio,delay-us = <2>;	/* ~100 kHz */
+	};
+};
+
+&nand {
+	status = "okay";
+	chip-delay = <25>;
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <>;
+		speed = <1000>;  /* <SPEED_1000> */
+		duplex = <0x01>; /* <DUPLEX_FULL> */
+	};
+};
-- 
1.8.0.1

[PATCH 3/3] ARM: dts: kirkwood: add kirkwood-km_fixedeth DTS file

[Sebastian Hesselbarth]

On 05/15/2014 11:48 AM, Valentin Longchamp wrote:
> Besides our Kirkwood Reference design, there is another group of board
> on which the eth interface is not connected to a phy but to a swtich for

s/swtich/switch/

> some board internal communication.
>
> The configuration of the switch is handled by an EEPROM or by the
> bootloader, but on the kirkwood side, the port is always configured as
> 1000 Mbits, full duplex.

Hmm, if it is another variant of the Keymile board we already have,
it should probably go like this:

+ kirkwood.dtsi
+ kirkwood-98dx4122.dtsi
+--> kirkwood_km_common.dtsi
      +--> kirkwood_km_kirkwood.dts
      +--> kirkwood_km_fixedeth.dts

Andrew did some great series for the various NAS vendor boards, where
you can look at.

> Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
>
> ---
>
>   arch/arm/boot/dts/kirkwood-km_fixedeth.dts | 70 ++++++++++++++++++++++++++++++
>   1 file changed, 70 insertions(+)
>   create mode 100644 arch/arm/boot/dts/kirkwood-km_fixedeth.dts
>
> diff --git a/arch/arm/boot/dts/kirkwood-km_fixedeth.dts b/arch/arm/boot/dts/kirkwood-km_fixedeth.dts
> new file mode 100644
> index 0000000..3d54d9b
> --- /dev/null
> +++ b/arch/arm/boot/dts/kirkwood-km_fixedeth.dts
> @@ -0,0 +1,70 @@
> +/dts-v1/;
> +
> +#include "kirkwood.dtsi"
> +#include "kirkwood-98dx4122.dtsi"
> +
> +/ {
> +	model = "Keymile Kirkwood Fixed Eth";
> +	compatible = "keymile,km_fixedeth", "marvell,kirkwood-98DX4122", "marvell,kirkwood";
> +
> +	memory {
> +		device_type = "memory";
> +		reg = <0x00000000 0x08000000>;
> +	};
> +
> +	chosen {
> +		bootargs = "console=ttyS0,115200n8 earlyprintk";
> +		stdout-path = &uart0;
> +	};
> +
> +	mbus {
> +		pcie-controller {
> +			status = "okay";
> +
> +			pcie at 1,0 {
> +				status = "okay";
> +			};
> +		};
> +	};
> +
> +	ocp at f1000000 {
> +		pinctrl: pin-controller at 10000 {
> +			pinctrl-0 = < &pmx_i2c_gpio_sda &pmx_i2c_gpio_scl >;
> +			pinctrl-names = "default";
> +
> +			pmx_i2c_gpio_sda: pmx-gpio-sda {
> +				marvell,pins = "mpp8";
> +				marvell,function = "gpio";
> +			};
> +			pmx_i2c_gpio_scl: pmx-gpio-scl {
> +				marvell,pins = "mpp9";
> +				marvell,function = "gpio";
> +			};
> +		};
> +
> +		serial at 12000 {
> +			status = "ok";
> +		};
> +	};
> +
> +	i2c at 0 {
> +		compatible = "i2c-gpio";
> +		gpios = < &gpio0 8 GPIO_ACTIVE_HIGH		/* sda */
> +			  &gpio0 9 GPIO_ACTIVE_HIGH>;		/* scl */
> +		i2c-gpio,delay-us = <2>;	/* ~100 kHz */
> +	};
> +};
> +
> +&nand {
> +	status = "okay";
> +	chip-delay = <25>;
> +};
> +
> +&eth0 {
> +	status = "okay";
> +	ethernet0-port at 0 {
> +		phy-handle = <>;

Is that empty phy-handle required? If so, we should probably fix
it in mv643xx_eth instead.

> +		speed = <1000>;  /* <SPEED_1000> */
> +		duplex = <0x01>; /* <DUPLEX_FULL> */

s/0x01/1/

Sebastian

> +	};
> +};
>

[PATCH 3/3] ARM: dts: kirkwood: add kirkwood-km_fixedeth DTS file

[Valentin Longchamp]

On 05/15/2014 12:43 PM, Sebastian Hesselbarth wrote:
> On 05/15/2014 11:48 AM, Valentin Longchamp wrote:
>> Besides our Kirkwood Reference design, there is another group of board
>> on which the eth interface is not connected to a phy but to a swtich for
> 
> s/swtich/switch/
> 
>> some board internal communication.
>>
>> The configuration of the switch is handled by an EEPROM or by the
>> bootloader, but on the kirkwood side, the port is always configured as
>> 1000 Mbits, full duplex.
> 
> Hmm, if it is another variant of the Keymile board we already have,
> it should probably go like this:
> 
> + kirkwood.dtsi
> + kirkwood-98dx4122.dtsi
> +--> kirkwood_km_common.dtsi
>       +--> kirkwood_km_kirkwood.dts
>       +--> kirkwood_km_fixedeth.dts
> 
> Andrew did some great series for the various NAS vendor boards, where
> you can look at.

Yes that is a variant and I agree, your proposal of having a common.dtsi makes
sense. I had seen Andrew's synology.dtsi and I hesitated to do something similar
in the first place.

> 
>> Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
>>
>> ---
>>
>>   arch/arm/boot/dts/kirkwood-km_fixedeth.dts | 70 ++++++++++++++++++++++++++++++
>>   1 file changed, 70 insertions(+)
>>   create mode 100644 arch/arm/boot/dts/kirkwood-km_fixedeth.dts
>>
>> diff --git a/arch/arm/boot/dts/kirkwood-km_fixedeth.dts b/arch/arm/boot/dts/kirkwood-km_fixedeth.dts
>> new file mode 100644
>> index 0000000..3d54d9b
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/kirkwood-km_fixedeth.dts
>> @@ -0,0 +1,70 @@
>> +/dts-v1/;
>> +
>> +#include "kirkwood.dtsi"
>> +#include "kirkwood-98dx4122.dtsi"
>> +
>> +/ {
>> +	model = "Keymile Kirkwood Fixed Eth";
>> +	compatible = "keymile,km_fixedeth", "marvell,kirkwood-98DX4122", "marvell,kirkwood";
>> +
>> +	memory {
>> +		device_type = "memory";
>> +		reg = <0x00000000 0x08000000>;
>> +	};
>> +
>> +	chosen {
>> +		bootargs = "console=ttyS0,115200n8 earlyprintk";
>> +		stdout-path = &uart0;
>> +	};
>> +
>> +	mbus {
>> +		pcie-controller {
>> +			status = "okay";
>> +
>> +			pcie at 1,0 {
>> +				status = "okay";
>> +			};
>> +		};
>> +	};
>> +
>> +	ocp at f1000000 {
>> +		pinctrl: pin-controller at 10000 {
>> +			pinctrl-0 = < &pmx_i2c_gpio_sda &pmx_i2c_gpio_scl >;
>> +			pinctrl-names = "default";
>> +
>> +			pmx_i2c_gpio_sda: pmx-gpio-sda {
>> +				marvell,pins = "mpp8";
>> +				marvell,function = "gpio";
>> +			};
>> +			pmx_i2c_gpio_scl: pmx-gpio-scl {
>> +				marvell,pins = "mpp9";
>> +				marvell,function = "gpio";
>> +			};
>> +		};
>> +
>> +		serial at 12000 {
>> +			status = "ok";
>> +		};
>> +	};
>> +
>> +	i2c at 0 {
>> +		compatible = "i2c-gpio";
>> +		gpios = < &gpio0 8 GPIO_ACTIVE_HIGH		/* sda */
>> +			  &gpio0 9 GPIO_ACTIVE_HIGH>;		/* scl */
>> +		i2c-gpio,delay-us = <2>;	/* ~100 kHz */
>> +	};
>> +};
>> +
>> +&nand {
>> +	status = "okay";
>> +	chip-delay = <25>;
>> +};
>> +
>> +&eth0 {
>> +	status = "okay";
>> +	ethernet0-port at 0 {
>> +		phy-handle = <>;
> 
> Is that empty phy-handle required? If so, we should probably fix
> it in mv643xx_eth instead.

Good question. I will try without it and drop it if possible.

> 
>> +		speed = <1000>;  /* <SPEED_1000> */
>> +		duplex = <0x01>; /* <DUPLEX_FULL> */
> 
> s/0x01/1/
> 

OK.

[PATCH 3/3] ARM: dts: kirkwood: add kirkwood-km_fixedeth DTS file

[Andrew Lunn]

> +	i2c at 0 {
> +		compatible = "i2c-gpio";
> +		gpios = < &gpio0 8 GPIO_ACTIVE_HIGH		/* sda */
> +			  &gpio0 9 GPIO_ACTIVE_HIGH>;		/* scl */
> +		i2c-gpio,delay-us = <2>;	/* ~100 kHz */
> +	};

Hi Valentin

Anything interesting on the i2c bus?

Does this SoC not have the hardware i2c? I don't see a node for it
here.

Thanks
	Andrew

[PATCH 3/3] ARM: dts: kirkwood: add kirkwood-km_fixedeth DTS file

[Valentin Longchamp]

On 05/15/2014 03:08 PM, Andrew Lunn wrote:
>> +	i2c at 0 {
>> +		compatible = "i2c-gpio";
>> +		gpios = < &gpio0 8 GPIO_ACTIVE_HIGH		/* sda */
>> +			  &gpio0 9 GPIO_ACTIVE_HIGH>;		/* scl */
>> +		i2c-gpio,delay-us = <2>;	/* ~100 kHz */
>> +	};
> 
> Hi Valentin
> 
> Anything interesting on the i2c bus?

Well yes, but this is then board specific (for all the Keymile variants of the
reference design). Since all these variants are not mainlined, I have added
nothing yet, but this may come later since we are currently reworking our I2C
bus support/topology.

> 
> Does this SoC not have the hardware i2c? I don't see a node for it
> here.
> 

The SoC does have the hardware I2C, but we don't use it and use the above
bitbang one instead. I was not in the company when this was chosen/designed. The
main reason is that the Kirkwood's one is not fast enough (clk < 96 kHz) for our
usage (we have A LOT of different things on this BUS, some must be quick - the
bus speed gets changed from (uuuurrghhh) userpace - and this is a NIGHTMARE,
believe me).

Valentin