Re: [PATCH] net: stmmac: Fix PTP ref clock for Tegra234

[Jon Hunter <jonathanh@nvidia.com>]

On 25/06/2025 17:24, Andrew Lunn wrote:
>>> Now, lets consider the case some devices do actually work. How are
>>> they working? Must it be the fallback? The ptp-ref clock is actually
>>> turned on, and if the ptp-ref clock and the main clock tick at the
>>> same rate, ptp would work. I _guess_, if the main clock and the
>>> ptp-ref clock tick at different rates, you get something from the ptp
>>> hardware, but it probably does not get sync with a grand master, or if
>>> it does, the jitter is high etc. So in effect it is still broken.
>>>
>>> Can somebody with the datasheet actually determine where ptp-ref clock
>>> comes from? Is it just a gated main clock? Is it from a pin?
>>
>> Looking at the datasheet, this is a pin to the controller and sourced from
>> an external clock.
> 
> So the fallback of the main clock is not likely to help, unless by
> chance the external clock and the main clock happen to be the same
> frequency.

Actually the fallback to the main clock is not applicable here for this 
Tegra device because we don't have a clock called 'stmmaceth'. In fact, 
that is something else we should fix because for Tegra234, I see ...

  tegra-mgbe 6800000.ethernet: Cannot get CSR clock

However, this is expected because there is no 'stmmaceth'. The fallback 
to the main clock is only applicable to !snps,dwc-qos-ethernet-4.10 
devices but this should also be applicable to 'nvidia,tegra234-mgbe' as 
well.

>> AFAIK we have never tested PTP with this driver on this device. So the risk
>> of breaking something is low for this device.
> 
> So it seems like the simple fix is to list both ptp-ref and ptp_ref,
> pointing to the same clock, along with a comment explaining why you
> have this odd construction.
> 
> Please could you test that?

I am sure it will work and yes I can test. I am a bit concerned that the 
device-tree maintainers will not want this because strictly device-tree 
should describe the hardware and adding workarounds is not ideal. Don't 
get me wrong this is a massive oversight on our behalf to begin with. 
Ideally we would handle this somewhere in the dwmac-tegra.c driver.

Jon

-- 
nvpublic