| Message ID | 20181207125224.GW6920@n2100.armlinux.org.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Fix OMAP4430 SDP Ethernet startup | expand |
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
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.
* 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
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
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 !!
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
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.
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
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!)
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 {
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(+)