Re: [PATCH] ARM: dts: imx6qdl-sr-som: Increase the PHY reset duration to 10ms

["Russell King (Oracle)" <linux@armlinux.org.uk>]

On Fri, Jun 25, 2021 at 11:35:50AM +0200, Maxime Chevallier wrote:
> Hi Russell,
> 
> On Fri, 25 Jun 2021 09:38:40 +0100
> "Russell King (Oracle)" <linux@armlinux.org.uk> wrote:
> 
> >On Fri, Jun 25, 2021 at 10:30:51AM +0200, Maxime Chevallier wrote:
> >> The datasheet for the AR803x PHY present on this SoM recommends that the
> >> reset line is asserted low for 10ms, so that the PHY has time to
> >> properly reset the internal blocks.
> >> 
> >> The previous value of 2ms was found to be problematic on some setups,
> >> causing intermittent issues where the PHY would be unresponsive
> >> every once in a while on some sytems, with a low occurence (it typically
> >> took around 30 consecutive reboots to encounter the issue).
> >> 
> >> Bumping the delay to the 10ms recommended value makes the issue
> >> dissapear, with more than 2500 consecutive reboots performed without the
> >> issue showing-up.  
> >
> >This isn't actually what the datasheet says, which is:
> >
> >  Input clock including the crystal and external input clock should be
> >  stable for at least 1ms before RESET can be deasserted.
> >
> >  When using crystal, the clock is generated internally after power is
> >  stable. For a reliable power on reset, suggest to keep asserting the
> >  reset low long enough (10ms) to ensure the clock is stable and
> >  clock-to-reset 1ms requirement is satisfied.
> >
> >The 10ms duration you quote is the _power on reset_ duration, and in
> >those circumstances, there is a delay before the required clocks will
> >be stable.
> >
> >This is not a power on reset scenario - the power was applied long ago
> >by the time the kernel starts booting, and XI clock would have been
> >running.
> >
> >So, I think the commit message which seems to be claiming that the reset
> >line always needs to be asserted for 10ms is not entirely accurate.
> 
> You're correct, indeed, I guess we read that a bit too fast.
> 
> However, we do see that bumping the reset duration fixes the issue that
> was encountered.
> 
> To give you more details about this issue, in that scenario the PHY
> would fail the autoneg process, no matter how many times we
> enable/disable the link and restart autoneg.
> 
> The low duration of the reset might put the internal blocks in an
> unknown state, but I don't actually have the real hardware-side
> explanation for what is actually happening.
> 
> Further testing showed, for example, that decreasing the time of reset
> assertion to 1ms made the issue appear everytime, whereas bumping it to
> 10 ms fixed it entirely.
> 
> In the absence of any other indication about how long should that reset
> be asserted, and after thourough testing, 10ms seems like a good enough
> value.
> 
> I'll send a V2 with the commit log fixed.
> 
> Thanks for the quick review,

Thanks. For the record, I don't have an issue with bumping it to 10ms,
only that the above would be useful information in the commit long.

I wonder if we should be recording these kinds of behaviours somewhere,
so e.g. we recommend that all AR803x should use a reset duration of
10ms with the above explanation. Just a thought to save others needing
to do the same research.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

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