---
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 <[email protected]>
Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
- 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
drivers/net/ethernet/stmicro/stmmac/dwmac-imx.c | 5 +++
drivers/net/ethernet/stmicro/stmmac/hwif.h | 3 ++
.../net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c | 43 ++++++++++++++++++++++
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 6 +++
drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.h | 6 +++
include/linux/stmmac.h | 1 +
6 files changed, 64 insertions(+)
---
base-commit: 01e6f8ad8d26ced14b0cf288c42e55d03a7c5070
change-id: 20230719-stmmac_correct_mac_delay-4278cb9d9bc1
Best regards,
--
Johannes Zink <[email protected]>
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 <[email protected]>
>> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
>> - 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 <[email protected]> # imx8mp
Thank you for testing!
Johannes
>
> Thanks,
> Kurt
--
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 |
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 <[email protected]>
> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
> - 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 <[email protected]> # imx8mp
Thanks,
Kurt
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 <[email protected]>
>>> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
>>> - 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 <[email protected]> # 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
On Tue, 01 Aug 2023 17:44:28 +0200 Johannes Zink wrote:
> ---
Richard? Sure would be nice to have an official ack from you on this
one so I don't have to revert it again ;)
On Fri, Aug 04, 2023 at 01:24:03PM -0700, Jakub Kicinski wrote:
> Richard? Sure would be nice to have an official ack from you on this
> one so I don't have to revert it again ;)
No objections to this version, as the correction is behind a feature
flag that is opt-in per device flavor.
Thanks,
Richard
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <[email protected]>:
On Tue, 01 Aug 2023 17:44:28 +0200 you 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
>
> [...]
Here is the summary with links:
- [v3,1/2] net: stmmac: correct MAC propagation delay
https://git.kernel.org/netdev/net-next/c/26cfb838aa00
- [v3,2/2] net: stmmac: dwmac-imx: enable MAC propagation delay correction for i.MX8MP
https://git.kernel.org/netdev/net-next/c/6cb2e613c796
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html