* Russell King - ARM Linux <linux@xxxxxxxxxxxxxxx> [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
