Update the Keymile kirkwood DTS files
cover Update the Keymile kirkwood DTS files
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
Signature · 1 line
1.8.0.1
PATCH 1/3 ARM: dts: kirkwood: resynch 98dx4122 dtsi
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.
---
arch/arm/boot/dts/kirkwood-98dx4122.dtsi | 43 ++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+)
arch/arm/boot/dts/kirkwood-98dx4122.dtsi +43 -0
@@ -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"; +};
Signature · 1 line
1.8.0.1
PATCH 1/3 ARM: dts: kirkwood: resynch 98dx4122 dtsi
Quoted 2 lines · Valentin Longchamp
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.
Quoted 3 lines
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
to make KM boot again.
Sebastian
Quoted 63 lines
Signed-off-by Valentin Longchamp <[email protected]>---
arch/arm/boot/dts/kirkwood-98dx4122.dtsi | 43 ++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+)arch/arm/boot/dts/kirkwood-98dx4122.dtsi +43
-0@@ -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
Quoted 23 lines · Sebastian Hesselbarth
Quoted 2 lines · Valentin Longchamp
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.dtsiand kirkwood-<soc>.dtsi as I feel there may be more issues with "common" IP that was removed in 98dx4122.Quoted 3 lines
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.dtsithat are not available in one of the SoCs and rather put them into the SoC-specific include.
Quoted 6 lines
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 tokirkwood.dtsiand 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 ;-)).
Quoted 10 lines
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
to make KM boot again.
Thanks.
Quoted 67 lines
Sebastian
Quoted 63 lines
Signed-off-by Valentin Longchamp <[email protected]>---
arch/arm/boot/dts/kirkwood-98dx4122.dtsi | 43 ++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+)arch/arm/boot/dts/kirkwood-98dx4122.dtsi +43
-0@@ -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
Quoted 27 lines · Valentin Longchamp
Quoted 26 lines · Sebastian Hesselbarth
Quoted 2 lines · Valentin Longchamp
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.dtsiand kirkwood-<soc>.dtsi as I feel there may be more issues with "common" IP that was removed in 98dx4122.Quoted 3 lines
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.dtsithat 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.
Quoted 8 lines
Quoted 3 lines
To be consitent, we should either duplicate the sata-phy nodes in
kirkwood-6foo.dtsi- or what I prefer - move most of it back tokirkwood.dtsiand 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
In reply to Valentin LongchampThe PCIe controller is used on the KM kirkwood reference design. This enables it.
---
arch/arm/boot/dts/kirkwood-km_kirkwood.dts | 10 ++++++++++ 1 file changed, 10 insertions(+)
arch/arm/boot/dts/kirkwood-km_kirkwood.dts +10 -0
@@ -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 >;
Signature · 1 line
1.8.0.1
PATCH 3/3 ARM: dts: kirkwood: add kirkwood-km_fixedeth DTS file
In reply to Valentin LongchampBesides 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.
---
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
arch/arm/boot/dts/kirkwood-km_fixedeth.dts new file +70 -0
@@ -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>; +}; + +ð0 { + status = "okay"; + ethernet0-port at 0 { + phy-handle = <>; + speed = <1000>; /* <SPEED_1000> */ + duplex = <0x01>; /* <DUPLEX_FULL> */ + }; +};
Signature · 1 line
1.8.0.1
PATCH 3/3 ARM: dts: kirkwood: add kirkwood-km_fixedeth DTS file
Quoted 2 lines · 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
s/swtich/switch/
Quoted 5 lines
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.dtsAndrew did some great series for the various NAS vendor boards, where you can look at.
Quoted 70 lines
Signed-off-by Valentin Longchamp <[email protected]>---
arch/arm/boot/dts/kirkwood-km_fixedeth.dts | 70 ++++++++++++++++++++++++++++++ 1 file changed, 70 insertions(+)create mode 100644
arch/arm/boot/dts/kirkwood-km_fixedeth.dtsarch/arm/boot/dts/kirkwood-km_fixedeth.dts new file +56
-0@@ -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 */ + }; +};
arch/arm/boot/dts/kirkwood-km_fixedeth.dts line 66
Quoted 10 lines
arch/arm/boot/dts/kirkwood-km_fixedeth.dts new file +10
-0+ +&nand { + status = "okay"; + chip-delay = <25>; +}; + +ð0 { + 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.
arch/arm/boot/dts/kirkwood-km_fixedeth.dts line 68
Quoted 2 lines
arch/arm/boot/dts/kirkwood-km_fixedeth.dts new file +2
-0+ speed = <1000>; /* <SPEED_1000> */ + duplex = <0x01>; /* <DUPLEX_FULL> */
s/0x01/1/
Sebastian
Quoted 3 lines
arch/arm/boot/dts/kirkwood-km_fixedeth.dts new file +2
-0+ }; +};
PATCH 3/3 ARM: dts: kirkwood: add kirkwood-km_fixedeth DTS file
Quoted 15 lines · Sebastian Hesselbarth
Quoted 2 lines · 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
s/swtich/switch/
Quoted 5 lines
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:
Quoted 8 lines
+
kirkwood.dtsi
+kirkwood-98dx4122.dtsi+--> kirkwood_km_common.dtsi +--> kirkwood_km_kirkwood.dts +--> kirkwood_km_fixedeth.dtsAndrew 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.
Quoted 76 lines
Quoted 76 lines
Signed-off-by Valentin Longchamp <[email protected]>---
arch/arm/boot/dts/kirkwood-km_fixedeth.dts | 70 ++++++++++++++++++++++++++++++ 1 file changed, 70 insertions(+)create mode 100644
arch/arm/boot/dts/kirkwood-km_fixedeth.dtsarch/arm/boot/dts/kirkwood-km_fixedeth.dts new file +61
-0@@ -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>; +};
Quoted 8 lines
arch/arm/boot/dts/kirkwood-km_fixedeth.dts line 66
Quoted 5 lines
arch/arm/boot/dts/kirkwood-km_fixedeth.dts new file +5
-0+ +ð0 { + status = "okay"; + ethernet0-port at 0 { + phy-handle = <>;Is that empty phy-handle required? If so, we should probably fix it in
mv643xx_ethinstead.
Good question. I will try without it and drop it if possible.
Quoted 6 lines
arch/arm/boot/dts/kirkwood-km_fixedeth.dts line 68
Quoted 3 lines
arch/arm/boot/dts/kirkwood-km_fixedeth.dts new file +2
-0+ speed = <1000>; /* <SPEED_1000> */ + duplex = <0x01>; /* <DUPLEX_FULL> */s/0x01/1/
OK.
PATCH 3/3 ARM: dts: kirkwood: add kirkwood-km_fixedeth DTS file
In reply to Valentin Longchamparch/arm/boot/dts/kirkwood-km_fixedeth.dts line 55
Quoted 6 lines
arch/arm/boot/dts/kirkwood-km_fixedeth.dts new file +6
-0+ 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
Quoted 10 lines · Andrew Lunn
arch/arm/boot/dts/kirkwood-km_fixedeth.dts line 55
Quoted 6 lines
arch/arm/boot/dts/kirkwood-km_fixedeth.dts new file +6
-0+ 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.
Quoted 4 lines
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