Re: [PATCH v2] net: stmmac: correct MAC propagation delay

[Johannes Zink]

Hi Richard,

On 7/26/23 17:43, Richard Cochran wrote:
> On Wed, Jul 26, 2023 at 08:10:35AM +0200, Johannes Zink wrote:
>
> > Also on a side-note, "driver nonsense" sounds a bit harsh from someone
> > always insisting that one should not compensate for bad drivers in the
> > userspace stack and instead fixing driver and hardware issues in the kernel,
> > don't you think?
>
> Everything has its place.
>
> The proper place to account for delay asymmetries is in the user space
> configuration, for example in linuxptp you have
This is not about Delay Asymmetry, but about Additional Errors in Path Delay, 
namely MAC Ingress and Egress Delay.

>         delayAsymmetry
>                The  time  difference in nanoseconds of the transmit and receive
>                paths. This value should be positive when  the  server-to-client
>                propagation  time  is  longer  and  negative when the client-to-
>                server time is longer. The default is 0 nanoseconds.
>
>         egressLatency
>                Specifies the  difference  in  nanoseconds  between  the  actual
>                transmission time at the reference plane and the reported trans‐
>                mit time stamp. This value will be added to egress  time  stamps
>                obtained from the hardware.  The default is 0.
> >         ingressLatency
>                Specifies the difference in nanoseconds between the reported re‐
>                ceive  time  stamp  and  the  actual reception time at reference
>                plane. This value will be subtracted from  ingress  time  stamps
>                obtained from the hardware.  The default is 0.
For the PTP stack you could probably configure these in the stack, but fixing 
the delay in the driver also has the advantage of reducing phase offset error 
when doing clock revovery from the PHC.

> Trying to hard code those into the driver?  Good luck getting that
> right for everyone.
That's why we don't hardcode the values but read them from the registers 
provided by the IP core.

> BTW this driver is actually for an IP core used in many, many SoCs.
>
> How many _other_ SoCs did you test your patch on?
I don't have many available, thus as stated in the description: on the i.MX8MP 
only. That's why I am implementing my stuff in the imx glue code, you're 
welcome to help testing on other hardware if you have any at hand.

Best regards
Johannes

> Thanks,
> Richard


--
Pengutronix e.K.                | Johannes Zink                  |
Steuerwalder Str. 21            | https://www.pengutronix.de/    |
31137 Hildesheim, Germany       | Phone: +49-5121-206917-0       |
Amtsgericht Hildesheim, HRA 2686| Fax:   +49-5121-206917-5555    |