lkml.org 
[lkml]   [2023]   [Jul]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v2] net: stmmac: correct MAC propagation delay
From
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 |

\
 
 \ /
  Last update: 2023-07-27 08:41    [W:0.051 / U:1.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site