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
