Message ID | 20230719-stmmac_correct_mac_delay-v3-0-61e63427735e@pengutronix.de (mailing list archive) |
---|---|
Headers | show |
Series | net: stmmac: correct MAC propagation delay | expand |
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@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@linutronix.de> # imx8mp Thanks, Kurt
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@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@linutronix.de> # imx8mp Thank you for testing! Johannes > > 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 <lkp@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@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
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 <kuba@kernel.org>: 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!