[PATCH v3 0/2] net: stmmac: correct MAC propagation delay

Kurt Kanzenbach kurt at linutronix.de
Thu Aug 3 03:12:04 PDT 2023


On Wed Aug 02 2023, Johannes Zink wrote:
> Hi Kurt,
>
> On 8/2/23 12:10, Kurt Kanzenbach wrote:
>> On Tue Aug 01 2023, Johannes Zink wrote:
>>> ---
>>> Changes in v3:
>>> - work in Richard's review feedback. Thank you for reviewing my patch:
>>>    - as some of the hardware may have no or invalid correction value
>>>      registers: introduce feature switch which can be enabled in the glue
>>>      code drivers depending on the actual hardware support
>>>    - only enable the feature on the i.MX8MP for the time being, as the patch
>>>      improves timing accuracy and is tested for this hardware
>>> - Link to v2: https://lore.kernel.org/r/20230719-stmmac_correct_mac_delay-v2-1-3366f38ee9a6@pengutronix.de
>>>
>>> Changes in v2:
>>> - fix builds for 32bit, this was found by the kernel build bot
>>> 	Reported-by: kernel test robot <lkp at intel.com>
>>> 	Closes: https://lore.kernel.org/oe-kbuild-all/202307200225.B8rmKQPN-lkp@intel.com/
>>> - while at it also fix an overflow by shifting a u32 constant from macro by 10bits
>>>    by casting the constant to u64
>>> - Link to v1: https://lore.kernel.org/r/20230719-stmmac_correct_mac_delay-v1-1-768aa4d09334@pengutronix.de
>>>
>>> ---
>>> Johannes Zink (2):
>>>        net: stmmac: correct MAC propagation delay
>>>        net: stmmac: dwmac-imx: enable MAC propagation delay correction for i.MX8MP
>> 
>> Tested on imx8mp <-> TSN Switch <-> x86 with i225:
>> 
>> Before your patch:
>> 
>> |ptp4l -i eth0 -f configs/gPTP.cfg --summary_interval=5 -m
>> |ptp4l[139.274]: rms    9 max   27 freq +29264 +/-  13 delay   347 +/-   2
>> |ptp4l[171.279]: rms   10 max   24 freq +29257 +/-  13 delay   344 +/-   2
>> |ptp4l[203.283]: rms   10 max   24 freq +29254 +/-  13 delay   347 +/-   2
>> |ptp4l[235.288]: rms    9 max   24 freq +29255 +/-  13 delay   346 +/-   1
>> |ptp4l[267.292]: rms    9 max   28 freq +29257 +/-  13 delay   347 +/-   2
>> 
>> After:
>> 
>> |ptp4l -i eth0 -f configs/gPTP.cfg --summary_interval=5 -m
>> |ptp4l[214.186]: rms    9 max   29 freq +28868 +/-  16 delay   326 +/-   2
>> |ptp4l[246.190]: rms    8 max   22 freq +28902 +/-  15 delay   329 +/-   2
>> |ptp4l[278.194]: rms    9 max   24 freq +28930 +/-  15 delay   325 +/-   1
>> |ptp4l[310.199]: rms    9 max   25 freq +28956 +/-  15 delay   327 +/-   3
>> |ptp4l[342.203]: rms    9 max   27 freq +28977 +/-  14 delay   327 +/-   1
>> 
>> And the derived register values:
>> 
>> |[   15.864016] KURT: PTP_TS_INGR_CORR_NS: 3147483248 PTP_TS_INGR_CORR_SNS: 0
>> |[   15.870862] KURT: PTP_TS_EGR_CORR_NS: 400 PTP_TS_EGR_CORR_SNS: 0
>> |[   20.000962] KURT: PTP_TS_INGR_CORR_NS: 3147483636 PTP_TS_INGR_CORR_SNS: 0
>> |[   20.007809] KURT: PTP_TS_EGR_CORR_NS: 12 PTP_TS_EGR_CORR_SNS: 0
>> 
>> So, seems to work:
>> 
>> Tested-by: Kurt Kanzenbach <kurt at linutronix.de> # imx8mp
>
> Thank you for testing!
> Johannes

AFAICT from the manuals the MAC propagation delay should be corrected
for the Intel TSN NIC(s) as well. I'll follow up with testing and a
patch when this set is merged.

Thanks,
Kurt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 861 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20230803/08fc3597/attachment.sig>


More information about the linux-arm-kernel mailing list