[PATCH] Fix OMAP4430 SDP Ethernet startup

[PATCH] Fix OMAP4430 SDP Ethernet startup

[Russell King - ARM Linux]

It was noticed that unbinding and rebinding the KSZ8851 ethernet
resulted in the driver reporting "failed to read device ID" at probe.
Probing the reset line with a 'scope while repeatedly attempting to
bind the driver in a shell loop revealed that the KSZ8851 RSTN pin is
constantly held at zero, meaning the device is held in reset, and
does not respond on the SPI bus.

Experimentation with the startup delay on the regulator set to 50ms
shows that the reset is positively released after 20ms.

Schematics for this board are not available, and the traces are buried
in the inner layers of the board which makes tracing where the RSTN pin
extremely difficult.  We can only guess that the RSTN pin is wired to a
reset generator chip driven off the ethernet supply, which fits the
observed behaviour.

Include this delay in the regulator startup delay - effectively
treating the reset as a "supply stable" indicator.

This can not be modelled as a delay in the KSZ8851 driver since the
reset generation is board specific - if the RSTN pin had been wired to
a GPIO, reset could be released earlier via the already provided support
in the KSZ8851 driver.

Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
 arch/arm/boot/dts/omap4-sdp.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 0831a2bf6cec..57acf3a8b8a1 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -33,6 +33,7 @@
 		gpio = <&gpio2 16 GPIO_ACTIVE_HIGH>;  /* gpio line 48 */
 		enable-active-high;
 		regulator-boot-on;
+		startup-delay-us = <25000>;
 	};
 
 	vbat: fixedregulator-vbat {

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

Re: [PATCH] Fix OMAP4430 SDP Ethernet startup

[Peter Ujfalusi]

Russell,

On 07/12/2018 14.52, Russell King - ARM Linux wrote:
> It was noticed that unbinding and rebinding the KSZ8851 ethernet
> resulted in the driver reporting "failed to read device ID" at probe.
> Probing the reset line with a 'scope while repeatedly attempting to
> bind the driver in a shell loop revealed that the KSZ8851 RSTN pin is
> constantly held at zero, meaning the device is held in reset, and
> does not respond on the SPI bus.
> 
> Experimentation with the startup delay on the regulator set to 50ms
> shows that the reset is positively released after 20ms.
> 
> Schematics for this board are not available, and the traces are buried
> in the inner layers of the board which makes tracing where the RSTN pin
> extremely difficult.  We can only guess that the RSTN pin is wired to a
> reset generator chip driven off the ethernet supply, which fits the
> observed behaviour.

Based on the schematics of the Blaze device (which should be very close
to SDP4430):

TPS22902YFPR is used as the regulator switch (gpio48 controlled)
The VOUT is routed to  TPS3808G01DBV (SCH Note: Threshold set at 90%.
Vsense: 0.405V).

According to the TPS3808 data sheet the RESET delay time when Ct is open
(this is the case in the schema): MIN/TYP/MAX: 12/20/28 ms.

The 20ms you are seeing confirms this setup.

> Include this delay in the regulator startup delay - effectively
> treating the reset as a "supply stable" indicator.
> 
> This can not be modelled as a delay in the KSZ8851 driver since the
> reset generation is board specific - if the RSTN pin had been wired to
> a GPIO, reset could be released earlier via the already provided support
> in the KSZ8851 driver.

Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>

> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
>  arch/arm/boot/dts/omap4-sdp.dts | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
> index 0831a2bf6cec..57acf3a8b8a1 100644
> --- a/arch/arm/boot/dts/omap4-sdp.dts
> +++ b/arch/arm/boot/dts/omap4-sdp.dts
> @@ -33,6 +33,7 @@
>  		gpio = <&gpio2 16 GPIO_ACTIVE_HIGH>;  /* gpio line 48 */
>  		enable-active-high;
>  		regulator-boot-on;
> +		startup-delay-us = <25000>;
>  	};
>  
>  	vbat: fixedregulator-vbat {
> 

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] Fix OMAP4430 SDP Ethernet startup

[Russell King - ARM Linux]

On Fri, Dec 07, 2018 at 03:40:13PM +0200, Peter Ujfalusi wrote:
> Russell,
> 
> On 07/12/2018 14.52, Russell King - ARM Linux wrote:
> > It was noticed that unbinding and rebinding the KSZ8851 ethernet
> > resulted in the driver reporting "failed to read device ID" at probe.
> > Probing the reset line with a 'scope while repeatedly attempting to
> > bind the driver in a shell loop revealed that the KSZ8851 RSTN pin is
> > constantly held at zero, meaning the device is held in reset, and
> > does not respond on the SPI bus.
> > 
> > Experimentation with the startup delay on the regulator set to 50ms
> > shows that the reset is positively released after 20ms.
> > 
> > Schematics for this board are not available, and the traces are buried
> > in the inner layers of the board which makes tracing where the RSTN pin
> > extremely difficult.  We can only guess that the RSTN pin is wired to a
> > reset generator chip driven off the ethernet supply, which fits the
> > observed behaviour.
> 
> Based on the schematics of the Blaze device (which should be very close
> to SDP4430):
> 
> TPS22902YFPR is used as the regulator switch (gpio48 controlled)
> The VOUT is routed to  TPS3808G01DBV (SCH Note: Threshold set at 90%.
> Vsense: 0.405V).
> 
> According to the TPS3808 data sheet the RESET delay time when Ct is open
> (this is the case in the schema): MIN/TYP/MAX: 12/20/28 ms.
> 
> The 20ms you are seeing confirms this setup.

Thanks for the confirmation and information.  The Blaze schematics
are also unavailable afaics.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

Re: [PATCH] Fix OMAP4430 SDP Ethernet startup

[Tony Lindgren]

* Russell King - ARM Linux <linux@armlinux.org.uk> [181207 13:58]:
> On Fri, Dec 07, 2018 at 03:40:13PM +0200, Peter Ujfalusi wrote:
> > Russell,
> > 
> > On 07/12/2018 14.52, Russell King - ARM Linux wrote:
> > > It was noticed that unbinding and rebinding the KSZ8851 ethernet
> > > resulted in the driver reporting "failed to read device ID" at probe.
> > > Probing the reset line with a 'scope while repeatedly attempting to
> > > bind the driver in a shell loop revealed that the KSZ8851 RSTN pin is
> > > constantly held at zero, meaning the device is held in reset, and
> > > does not respond on the SPI bus.
> > > 
> > > Experimentation with the startup delay on the regulator set to 50ms
> > > shows that the reset is positively released after 20ms.
> > > 
> > > Schematics for this board are not available, and the traces are buried
> > > in the inner layers of the board which makes tracing where the RSTN pin
> > > extremely difficult.  We can only guess that the RSTN pin is wired to a
> > > reset generator chip driven off the ethernet supply, which fits the
> > > observed behaviour.
> > 
> > Based on the schematics of the Blaze device (which should be very close
> > to SDP4430):
> > 
> > TPS22902YFPR is used as the regulator switch (gpio48 controlled)
> > The VOUT is routed to  TPS3808G01DBV (SCH Note: Threshold set at 90%.
> > Vsense: 0.405V).
> > 
> > According to the TPS3808 data sheet the RESET delay time when Ct is open
> > (this is the case in the schema): MIN/TYP/MAX: 12/20/28 ms.
> > 
> > The 20ms you are seeing confirms this setup.
> 
> Thanks for the confirmation and information.  The Blaze schematics
> are also unavailable afaics.

Thanks applying into omap-for-v4.20/fixes with updated notes
from Peter for the wiring.

Regards,

Tony

Re: [PATCH] Fix OMAP4430 SDP Ethernet startup

[santosh.shilimkar]

On 12/7/18 9:16 AM, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@armlinux.org.uk> [181207 13:58]:

[...]

>>> The 20ms you are seeing confirms this setup.
>>
>> Thanks for the confirmation and information.  The Blaze schematics
>> are also unavailable afaics.
> 
> Thanks applying into omap-for-v4.20/fixes with updated notes
> from Peter for the wiring.
> 
Thanks Tony !!

Re: [PATCH] Fix OMAP4430 SDP Ethernet startup

[Peter Ujfalusi]

Russell,

On 07/12/2018 15.57, Russell King - ARM Linux wrote:
> On Fri, Dec 07, 2018 at 03:40:13PM +0200, Peter Ujfalusi wrote:
>> Russell,
>>
>> On 07/12/2018 14.52, Russell King - ARM Linux wrote:
>>> It was noticed that unbinding and rebinding the KSZ8851 ethernet
>>> resulted in the driver reporting "failed to read device ID" at probe.
>>> Probing the reset line with a 'scope while repeatedly attempting to
>>> bind the driver in a shell loop revealed that the KSZ8851 RSTN pin is
>>> constantly held at zero, meaning the device is held in reset, and
>>> does not respond on the SPI bus.
>>>
>>> Experimentation with the startup delay on the regulator set to 50ms
>>> shows that the reset is positively released after 20ms.
>>>
>>> Schematics for this board are not available, and the traces are buried
>>> in the inner layers of the board which makes tracing where the RSTN pin
>>> extremely difficult.  We can only guess that the RSTN pin is wired to a
>>> reset generator chip driven off the ethernet supply, which fits the
>>> observed behaviour.
>>
>> Based on the schematics of the Blaze device (which should be very close
>> to SDP4430):
>>
>> TPS22902YFPR is used as the regulator switch (gpio48 controlled)
>> The VOUT is routed to  TPS3808G01DBV (SCH Note: Threshold set at 90%.
>> Vsense: 0.405V).
>>
>> According to the TPS3808 data sheet the RESET delay time when Ct is open
>> (this is the case in the schema): MIN/TYP/MAX: 12/20/28 ms.
>>
>> The 20ms you are seeing confirms this setup.
> 
> Thanks for the confirmation and information.  The Blaze schematics
> are also unavailable afaics.

Even with the delay I can not get the ethernet working on Blaze. It
supposed to be mostly the same HW as sdp (we load the same omap4-sdp.dtb).

[    2.576599] ks8851 spi0.0: spi0.0 supply vdd-io not found, using
dummy regulator
[    2.584045] ks8851 spi0.0: Linked as a consumer to regulator.0
[    2.584136] ks8851 spi0.0: Linked as a consumer to regulator.4
[    2.595916] ks8851 spi0.0: message enable is 0
[    2.602661] ks8851 spi0.0: failed to read device ID
[    2.607604] ks8851 spi0.0: Dropping the link to regulator.4
[    2.607604] ks8851 spi0.0: Dropping the link to regulator.0

I can not recall when was the last time it worked, could be years ago.

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] Fix OMAP4430 SDP Ethernet startup

[Russell King - ARM Linux]

On Wed, Dec 12, 2018 at 02:15:27PM +0200, Peter Ujfalusi wrote:
> Russell,
> 
> On 07/12/2018 15.57, Russell King - ARM Linux wrote:
> > On Fri, Dec 07, 2018 at 03:40:13PM +0200, Peter Ujfalusi wrote:
> >> Russell,
> >>
> >> On 07/12/2018 14.52, Russell King - ARM Linux wrote:
> >>> It was noticed that unbinding and rebinding the KSZ8851 ethernet
> >>> resulted in the driver reporting "failed to read device ID" at probe.
> >>> Probing the reset line with a 'scope while repeatedly attempting to
> >>> bind the driver in a shell loop revealed that the KSZ8851 RSTN pin is
> >>> constantly held at zero, meaning the device is held in reset, and
> >>> does not respond on the SPI bus.
> >>>
> >>> Experimentation with the startup delay on the regulator set to 50ms
> >>> shows that the reset is positively released after 20ms.
> >>>
> >>> Schematics for this board are not available, and the traces are buried
> >>> in the inner layers of the board which makes tracing where the RSTN pin
> >>> extremely difficult.  We can only guess that the RSTN pin is wired to a
> >>> reset generator chip driven off the ethernet supply, which fits the
> >>> observed behaviour.
> >>
> >> Based on the schematics of the Blaze device (which should be very close
> >> to SDP4430):
> >>
> >> TPS22902YFPR is used as the regulator switch (gpio48 controlled)
> >> The VOUT is routed to  TPS3808G01DBV (SCH Note: Threshold set at 90%.
> >> Vsense: 0.405V).
> >>
> >> According to the TPS3808 data sheet the RESET delay time when Ct is open
> >> (this is the case in the schema): MIN/TYP/MAX: 12/20/28 ms.
> >>
> >> The 20ms you are seeing confirms this setup.
> > 
> > Thanks for the confirmation and information.  The Blaze schematics
> > are also unavailable afaics.
> 
> Even with the delay I can not get the ethernet working on Blaze. It
> supposed to be mostly the same HW as sdp (we load the same omap4-sdp.dtb).
> 
> [    2.576599] ks8851 spi0.0: spi0.0 supply vdd-io not found, using
> dummy regulator
> [    2.584045] ks8851 spi0.0: Linked as a consumer to regulator.0
> [    2.584136] ks8851 spi0.0: Linked as a consumer to regulator.4
> [    2.595916] ks8851 spi0.0: message enable is 0
> [    2.602661] ks8851 spi0.0: failed to read device ID
> [    2.607604] ks8851 spi0.0: Dropping the link to regulator.4
> [    2.607604] ks8851 spi0.0: Dropping the link to regulator.0
> 
> I can not recall when was the last time it worked, could be years ago.

It's always been detected at boot without problem for me.  E.g.:

http://www.armlinux.org.uk/developer/build/result.php?type=boot&idx=11716

This patch fixes what happens when you try to unbind/rebind the device.
I tripped over that while experimenting with the GPIO hardware - I'd
inadvertently disabled the detection registers for the ethernet IRQ
with devmem2 on NFS, and wanted to reprobe the device to recover the
situation with the minimum of disruption.

Does a longer delay make any difference for blaze?

You could try setting it for a very long delay (5 seconds?) and check
whether you get any link lights - if not, it probably suggests either
the KS8851 is not getting power, the KS8851 has died, or there's a
difference between the SDP and Blaze in this area.

On the SDP, the power is readily identifyable from the KS8851 pinout
and the larger tracks with the ceramic decoupling capacitors, but I'm
unfamiliar with blaze to know whether it's as obvious, and therefore
whether the supplies to the KS8851 could be easily checked.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

Re: [PATCH] Fix OMAP4430 SDP Ethernet startup

[Peter Ujfalusi]

On 12/12/2018 14.50, Russell King - ARM Linux wrote:
>> Even with the delay I can not get the ethernet working on Blaze. It
>> supposed to be mostly the same HW as sdp (we load the same omap4-sdp.dtb).
>>
>> [    2.576599] ks8851 spi0.0: spi0.0 supply vdd-io not found, using
>> dummy regulator
>> [    2.584045] ks8851 spi0.0: Linked as a consumer to regulator.0
>> [    2.584136] ks8851 spi0.0: Linked as a consumer to regulator.4
>> [    2.595916] ks8851 spi0.0: message enable is 0
>> [    2.602661] ks8851 spi0.0: failed to read device ID
>> [    2.607604] ks8851 spi0.0: Dropping the link to regulator.4
>> [    2.607604] ks8851 spi0.0: Dropping the link to regulator.0
>>
>> I can not recall when was the last time it worked, could be years ago.
> 
> It's always been detected at boot without problem for me.  E.g.:
> 
> http://www.armlinux.org.uk/developer/build/result.php?type=boot&idx=11716

Thanks for the log. It looks like you have u-boot with ks8851 support,
but it is not working with mainline u-boot (eth is not supported afaik).

> This patch fixes what happens when you try to unbind/rebind the device.
> I tripped over that while experimenting with the GPIO hardware - I'd
> inadvertently disabled the detection registers for the ethernet IRQ
> with devmem2 on NFS, and wanted to reprobe the device to recover the
> situation with the minimum of disruption.
> 
> Does a longer delay make any difference for blaze?

No, it does not help.

> 
> You could try setting it for a very long delay (5 seconds?) and check
> whether you get any link lights - if not, it probably suggests either
> the KS8851 is not getting power, the KS8851 has died, or there's a
> difference between the SDP and Blaze in this area.
> 
> On the SDP, the power is readily identifyable from the KS8851 pinout
> and the larger tracks with the ceramic decoupling capacitors, but I'm
> unfamiliar with blaze to know whether it's as obvious, and therefore
> whether the supplies to the KS8851 could be easily checked.

My guess is the ethernet just dead on my board. If I have time I will
take it apart and see if I can probe the needed pins.

Thank you,
- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] Fix OMAP4430 SDP Ethernet startup

[Russell King - ARM Linux]

On Wed, Dec 12, 2018 at 03:44:08PM +0200, Peter Ujfalusi wrote:
> 
> On 12/12/2018 14.50, Russell King - ARM Linux wrote:
> >> Even with the delay I can not get the ethernet working on Blaze. It
> >> supposed to be mostly the same HW as sdp (we load the same omap4-sdp.dtb).
> >>
> >> [    2.576599] ks8851 spi0.0: spi0.0 supply vdd-io not found, using
> >> dummy regulator
> >> [    2.584045] ks8851 spi0.0: Linked as a consumer to regulator.0
> >> [    2.584136] ks8851 spi0.0: Linked as a consumer to regulator.4
> >> [    2.595916] ks8851 spi0.0: message enable is 0
> >> [    2.602661] ks8851 spi0.0: failed to read device ID
> >> [    2.607604] ks8851 spi0.0: Dropping the link to regulator.4
> >> [    2.607604] ks8851 spi0.0: Dropping the link to regulator.0
> >>
> >> I can not recall when was the last time it worked, could be years ago.
> > 
> > It's always been detected at boot without problem for me.  E.g.:
> > 
> > http://www.armlinux.org.uk/developer/build/result.php?type=boot&idx=11716
> 
> Thanks for the log. It looks like you have u-boot with ks8851 support,
> but it is not working with mainline u-boot (eth is not supported afaik).

Yep - I think it's a uboot/spl/mlo that came from TI, rather than
mainline.  Since eth is fundamental to the platform being part of
the automated boot farm, the lack of eth support in mainline
u-boot is a very good reason for me to avoid that.

Manually loading kernels onto SD cards doesn't work for automated
testing (unless you have a robot to remove the SD card from the
platform, plug it into a PC, and then transfer it back!)

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

Re: [PATCH] Fix OMAP4430 SDP Ethernet startup

[Santosh Shilimkar]

On 12/7/2018 4:52 AM, Russell King - ARM Linux wrote:
> It was noticed that unbinding and rebinding the KSZ8851 ethernet
> resulted in the driver reporting "failed to read device ID" at probe.
> Probing the reset line with a 'scope while repeatedly attempting to
> bind the driver in a shell loop revealed that the KSZ8851 RSTN pin is
> constantly held at zero, meaning the device is held in reset, and
> does not respond on the SPI bus.
> 
> Experimentation with the startup delay on the regulator set to 50ms
> shows that the reset is positively released after 20ms.
> 
> Schematics for this board are not available, and the traces are buried
> in the inner layers of the board which makes tracing where the RSTN pin
> extremely difficult.  We can only guess that the RSTN pin is wired to a
> reset generator chip driven off the ethernet supply, which fits the
> observed behaviour.
> 
> Include this delay in the regulator startup delay - effectively
> treating the reset as a "supply stable" indicator.
> 
> This can not be modelled as a delay in the KSZ8851 driver since the
> reset generation is board specific - if the RSTN pin had been wired to
> a GPIO, reset could be released earlier via the already provided support
> in the KSZ8851 driver.
> 
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
Sure. We can add this. Thanks for patch.

Regards,
Santosh