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

Message ID	20230719-stmmac_correct_mac_delay-v3-0-61e63427735e@pengutronix.de (mailing list archive)
Headers	show Return-Path: <linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org> From: Johannes Zink <j.zink@pengutronix.de> Subject: [PATCH v3 0/2] net: stmmac: correct MAC propagation delay Date: Tue, 01 Aug 2023 17:44:28 +0200 Message-Id: <20230719-stmmac_correct_mac_delay-v3-0-61e63427735e@pengutronix.de> MIME-Version: 1.0 To: Giuseppe Cavallaro <peppe.cavallaro@st.com>, Alexandre Torgue <alexandre.torgue@foss.st.com>, Jose Abreu <joabreu@synopsys.com>, "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, Maxime Coquelin <mcoquelin.stm32@gmail.com>, Richard Cochran <richardcochran@gmail.com>, Russell King <linux@armlinux.org.uk> Cc: patchwork-jzi@pengutronix.de, netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kernel@pengutronix.de, Kurt Kanzenbach <kurt@linutronix.de>, kernel test robot <lkp@intel.com>, Johannes Zink <j.zink@pengutronix.de> Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" <linux-arm-kernel-bounces@lists.infradead.org> Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org
Series	net: stmmac: correct MAC propagation delay \| expand [v3,0/2] net: stmmac: correct MAC propagation delay [v3,1/2] net: stmmac: correct MAC propagation delay [v3,2/2] net: stmmac: dwmac-imx: enable MAC propagation delay correction for i.MX8MP

Johannes Zink Aug. 1, 2023, 3:44 p.m. UTC

---
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

 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,

Kurt Kanzenbach Aug. 2, 2023, 10:10 a.m. UTC | #1

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

Johannes Zink Aug. 2, 2023, 10:16 a.m. UTC | #2

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

Kurt Kanzenbach Aug. 3, 2023, 10:12 a.m. UTC | #3

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

Jakub Kicinski Aug. 4, 2023, 8:24 p.m. UTC | #4

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 ;)

Richard Cochran Aug. 5, 2023, 3:04 p.m. UTC | #5

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

patchwork-bot+netdevbpf@kernel.org Aug. 7, 2023, 7:30 p.m. UTC | #6

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!

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

Message

Comments