ARM: dts: imx6ul-14x14-evk: Fix SPI chipselect polarity

Currently the 74LV595PW GPIO expander is not functional because its OE pin is not driven low.

Make it funcional by passing the 'enable-gpios' property inside the GPIO expander node.

After putting the OE pin in low state, the outputs of the 74LV595PW all go low.

The two KSZ8081 Ethernet PHYs reset lines are driven from the the GPIO expander and as they remain low, this causes the Ethernet PHYs not to be detected.

There is one solution to this problem as suggested by Andrew Lunn:

"Some devices will respond to MDIO while held in reset, some don't. If your PHYs don't you need to add a compatible of the form ethernet-phy-id[a-f0-9]{4}\\.[a-f0-9]{4}$ with the PHY ID. The PHY will then be probed, independent of if it can be found on the bus or not, and that probing will enable the GPIO."

So pass the "ethernet-phy-id0022.1560" for the KSZ8081 PHYs so that they both can be functional after 74LV595PW is activated.

Suggested-by Andrew Lunn <[email protected]>

Signed-off-by Fabio Estevam <[email protected]>

Currently the 74LV595PW GPIO expander is not functional because its OE pin is not driven low.

Make it funcional by passing the 'enable-gpios' property inside the GPIO expander node.

After putting the OE pin in low state, the outputs of the 74LV595PW all go low.

The two KSZ8081 Ethernet PHYs reset lines are driven from the the GPIO expander and as they remain low, this causes the Ethernet PHYs not to be detected.

There is one solution to this problem as suggested by Andrew Lunn:

"Some devices will respond to MDIO while held in reset, some don't. If your PHYs don't you need to add a compatible of the form ethernet-phy-id[a-f0-9]{4}\\.[a-f0-9]{4}$ with the PHY ID. The PHY will then be probed, independent of if it can be found on the bus or not, and that probing will enable the GPIO."

So pass the "ethernet-phy-id0022.1560" for the KSZ8081 PHYs so that they both can be functional after 74LV595PW is activated.

Suggested-by Andrew Lunn <[email protected]>

Signed-off-by Fabio Estevam <[email protected]>

There are two KSZ8081 on the imx6ul-14x14-evk: one has the reset line controlled by the Q1 output of the 74LV595PW expander, and the other by the Q2 output.

The KSZ8081 datasheet states that the tsr parameter (Stable supply voltage (VDDIO, VDDA_3.3) to reset high) to be 10ms minimum and "After the de-assertion of reset, wait a minimum of 100 µs before starting programming on the MIIM (MDC/MDIO) interface."

Describe these parameters in the devicetree.

Signed-off-by Fabio Estevam <[email protected]>

There are two KSZ8081 on the imx6ul-14x14-evk: one has the reset line controlled by the Q1 output of the 74LV595PW expander, and the other by the Q2 output.

The KSZ8081 datasheet states that the tsr parameter (Stable supply voltage (VDDIO, VDDA_3.3) to reset high) to be 10ms minimum and "After the de-assertion of reset, wait a minimum of 100 µs before starting programming on the MIIM (MDC/MDIO) interface."

Describe these parameters in the devicetree.

Signed-off-by Fabio Estevam <[email protected]>

-----Original Message-----
From: Fabio Estevam <[email protected]>
Sent: 2021年1月8日 7:51
To: [email protected]
Cc: [email protected]; dl-linux-imx <[email protected]>; [email protected]; [email protected]; Fabio Estevam <[email protected]>
Subject: [PATCH 3/4] ARM: dts: imx6ul-14x14-evk: Describe the KSZ8081 reset

There are two KSZ8081 on the imx6ul-14x14-evk: one has the reset line controlled by the Q1 output of the 74LV595PW expander, and the other by the Q2 output.

The KSZ8081 datasheet states that the tsr parameter (Stable supply voltage (VDDIO, VDDA_3.3) to reset high) to be 10ms minimum and "After the de-assertion of reset, wait a minimum of 100 µs before starting programming on the MIIM (MDC/MDIO) interface."

Describe these parameters in the devicetree.

Signed-off-by Fabio Estevam <[email protected]>

---
 arch/arm/boot/dts/imx6ul-14x14-evk.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

arch/arm/boot/dts/imx6ul-14x14-evk.dtsi +7 -1

index 8bf845afd166..ac2ec96f54e7 100644
@@ -175,6 +175,10 @@
 			micrel,led-mode = <1>;
 			clocks = <&clks IMX6UL_CLK_ENET_REF>;
 			clock-names = "rmii-ref";
+			reset-gpios = <&gpio_spi 1 GPIO_ACTIVE_LOW>;
+			reset-assert-us = <10000>;
+			reset-deassert-us = <100>;
+
 		};
 
 		ethphy1: ethernet-phy@1 {

@@ -183,6 +187,9 @@
 			micrel,led-mode = <1>;
 			clocks = <&clks IMX6UL_CLK_ENET2_REF>;
 			clock-names = "rmii-ref";
+			reset-gpios = <&gpio_spi 2 GPIO_ACTIVE_LOW>;
+			reset-assert-us = <10000>;
+			reset-deassert-us = <100>;
 		};
 	};
 };
--

2.17.1

-----Original Message-----
From: Joakim Zhang
Sent: 2021年3月10日 19:04
To: Fabio Estevam <[email protected]>; [email protected]
Cc: [email protected]; [email protected]; [email protected]
Subject: RE: [PATCH 3/4] ARM: dts: imx6ul-14x14-evk: Describe the KSZ8081 reset

Hi Fabio, Andrew,

After applying Fabio's patch to support PHY hardware reset. I found i.MX6UL 14x14 EVK board is broken in latest upstream kernel.

	ARM: dts: imx6ul-14x14-evk: Enable the GPIO expander
	ARM: dts: imx6ul-14x14-evk: Describe the KSZ8081 reset

Case 1:

root@imx6ul7d:~# ifconfig eth0 down
root@imx6ul7d:~# [  279.386551] fec 2188000.ethernet eth1: Link is Down
After down eth0, eth1 would down, then eth1 can't be used any more.

The same behavior for another ethernet,

root@imx6ul7d:~# ifconfig eth1 down
root@imx6ul7d:~# [  118.106726] fec 20b4000.ethernet eth0: Link is Down
After down eth1, eth0 would down, then eth0 can't be used any more.

Case 2:

[    9.182109] Micrel KSZ8081 or KSZ8091 20b4000.ethernet-1:01: attached
PHY driver (mii_bus:phy_addr=20b4000.ethernet-1:01, irq=POLL)
[    9.309462] Micrel KSZ8081 or KSZ8091 20b4000.ethernet-1:02: attached
PHY driver (mii_bus:phy_addr=20b4000.ethernet-1:02, irq=POLL)
[   11.397952] fec 2188000.ethernet eth1: Link is Up - 100Mbps/Full - flow
control rx/tx
[   11.414343] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[   11.429546] Sending DHCP requests ., OK
[   11.596850] IP-Config: Got DHCP answer from 10.193.102.252, my address
is 10.193.102.87
[   11.605689] IP-Config: Complete:
[   11.609595]      device=eth1, hwaddr=00:04:9f:04:3e:92,
ipaddr=10.193.102.87, mask=255.255.255.0, gw=10.193.102.254
[   11.620621]      host=10.193.102.87, domain=ap.freescale.net,
nis-domain=(none)
[   11.628118]      bootserver=0.0.0.0, rootserver=10.193.108.176,
rootpath=
[   11.628230]      nameserver0=165.114.89.4,
nameserver1=134.27.184.42
[   11.697259] cfg80211: Loading compiled-in X.509 certificates for regulatory
database
[   11.731941] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[   11.742445] platform regulatory.0: Direct firmware load for regulatory.db
failed with error -2
[   11.751605] platform regulatory.0: Falling back to sysfs fallback for:
regulatory.db
[   11.762730] ALSA device list:
[   11.765818]   #0: mx6ul-wm8960
[   12.433430] fec 2188000.ethernet eth1: Link is Down

It is broken when mounting NFS, per the log, we can see that eth0 and eth1 is up, and when it down the eth0, eth1 would link down too.

The root cause should be down one ethernet would affect another ethernet when it calling mdio_device_reset to pull Q1 or Q2 to low. After the ethernet down, I check Q1 and Q2 is 1.2V.
I also check the code, each PHY has one phy_device, containing it's own mdio_device. So each PHY should be independent, when do mdio device level hw reset, it should not affect others.
Could you give some hints? There is no any process after one debugging. Thanks a lot.

Best Regards,
Joakim Zhang

Quoted 42 lines

-----Original Message-----
From: Fabio Estevam <[email protected]>
Sent: 2021年1月8日 7:51
To: [email protected]
Cc: [email protected]; dl-linux-imx <[email protected]>; [email protected]; [email protected]; Fabio Estevam <[email protected]>
Subject: [PATCH 3/4] ARM: dts: imx6ul-14x14-evk: Describe the KSZ8081 reset

There are two KSZ8081 on the imx6ul-14x14-evk: one has the reset line controlled by the Q1 output of the 74LV595PW expander, and the other by the
Q2 output.

The KSZ8081 datasheet states that the tsr parameter (Stable supply voltage (VDDIO, VDDA_3.3) to reset high) to be 10ms minimum and "After the de-assertion of reset, wait a minimum of 100 µs before starting programming on the MIIM (MDC/MDIO) interface."

Describe these parameters in the devicetree.

Signed-off-by Fabio Estevam <[email protected]>

---
 arch/arm/boot/dts/imx6ul-14x14-evk.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

arch/arm/boot/dts/imx6ul-14x14-evk.dtsi +4 -0

index 8bf845afd166..ac2ec96f54e7 100644
@@ -175,6 +175,10 @@
 			micrel,led-mode = <1>;
 			clocks = <&clks IMX6UL_CLK_ENET_REF>;
 			clock-names = "rmii-ref";
+			reset-gpios = <&gpio_spi 1 GPIO_ACTIVE_LOW>;
+			reset-assert-us = <10000>;
+			reset-deassert-us = <100>;
+
 		};
 

Quoted 12 lines

arch/arm/boot/dts/imx6ul-14x14-evk.dtsi +3 -1

 		ethphy1: ethernet-phy@1 {

@@ -183,6 +187,9 @@
 			micrel,led-mode = <1>;
 			clocks = <&clks IMX6UL_CLK_ENET2_REF>;
 			clock-names = "rmii-ref";
+			reset-gpios = <&gpio_spi 2 GPIO_ACTIVE_LOW>;
+			reset-assert-us = <10000>;
+			reset-deassert-us = <100>;
 		};
 	};
 };
--

Quoted 1 line

2.17.1

Hi Fabio, Shawn, Andrew,

I found the root cause is the schematic diagram defect, both ENET1_nRST and ENET2_nRST are connect to ENET_nRST, which means PHY0 and PHY1 can't be hardware reset independently.

-----Original Message-----
From: Andrew Lunn <[email protected]>
Sent: 2021年3月11日 22:18
To: Joakim Zhang <[email protected]>
Cc: Fabio Estevam <[email protected]>; [email protected]; [email protected]; [email protected]
Subject: Re: [PATCH 3/4] ARM: dts: imx6ul-14x14-evk: Describe the KSZ8081 reset

Quoted 3 lines · Joakim Zhang

Hi Fabio, Shawn, Andrew,

Quoted 3 lines

I found the root cause is the schematic diagram defect, both ENET1_nRST and ENET2_nRST are connect to ENET_nRST, which means PHY0 and PHY1 can't be hardware reset independently.

You can move the reset-gpio up into the MDIO node. It then becomes an MDIO bus reset, resetting all PHYs on the bus before they are probed.

Andrew

Hi Fabio, Shawn, Andrew,

I found the root cause is the schematic diagram defect, both ENET1_nRST and ENET2_nRST are connect to ENET_nRST, which means PHY0 and PHY1 can't be hardware reset independently. Revert the patch
"ARM: dts: imx6ul-14x14-evk: Describe the KSZ8081 reset" is not enough, after IO expander probing, Q1/Q2 default is low level, PHY attached would fail. At our local side, give IO expander a default value, but I don't know if it is a common method. If you think it is ok, I can try to upstream that patch.

Add support for the OV5640 parallel camera module.

Signed-off-by Fabio Estevam <[email protected]>

---
 arch/arm/boot/dts/imx6ul-14x14-evk.dtsi | 43 ++++++++++++++++++++++++-
 1 file changed, 42 insertions(+), 1 deletion(-)

arch/arm/boot/dts/imx6ul-14x14-evk.dtsi +35 -0

index ac2ec96f54e7..ad039821a767 100644
@@ -146,6 +146,41 @@
 		reg = <0x1a>;
 		wlf,shared-lrclk;
 	};
+
+	camera@3c {
+		compatible = "ovti,ov5640";
+		reg = <0x3c>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_camera_clock>;
+		clocks = <&clks IMX6UL_CLK_CSI>;
+		clock-names = "xclk";
+		powerdown-gpios = <&gpio_spi 6 GPIO_ACTIVE_HIGH>;
+		reset-gpios = <&gpio_spi 5 GPIO_ACTIVE_LOW>;
+
+		port {
+			ov5640_to_parallel: endpoint {
+				remote-endpoint = <&parallel_from_ov5640>;
+				bus-width = <8>;
+				data-shift = <2>; /* lines 9:2 are used */
+				hsync-active = <0>;
+				vsync-active = <0>;
+				pclk-sample = <1>;
+			};
+		};
+	};
+};
+
+&csi {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_csi1>;
+	status = "okay";
+
+	port {
+		parallel_from_ov5640: endpoint {
+			remote-endpoint = <&ov5640_to_parallel>;
+			bus-type = <5>; /* Parallel bus */
+		};
+	};
 };
 
 &fec1 {

@@ -353,9 +388,15 @@
 &iomuxc {
 	pinctrl-names = "default";
 

arch/arm/boot/dts/imx6ul-14x14-evk.dtsi +0 -0

 			MX6UL_PAD_CSI_PIXCLK__CSI_PIXCLK	0x1b088
 			MX6UL_PAD_CSI_VSYNC__CSI_VSYNC		0x1b088
 			MX6UL_PAD_CSI_HSYNC__CSI_HSYNC		0x1b088

Signature · 1 line

2.17.1

The GPIO expander SPI chipselect is active low. Mark it as such to avoid the following warning:

[    6.839213] gpio@0 enforce active low on chipselect handle

Signed-off-by Fabio Estevam <[email protected]>