public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: Maxime Chevallier <maxime.chevallier@bootlin.com>
To: Alexandre Torgue <alexandre.torgue@foss.st.com>,
	Jose Abreu <joabreu@synopsys.com>,
	Andrew Lunn <andrew+netdev@lunn.ch>,
	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>
Cc: "Maxime Chevallier" <maxime.chevallier@bootlin.com>,
	"Alexis Lothoré" <alexis.lothore@bootlin.com>,
	"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>,
	netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH net-next 0/7] Support external snapshots on dwmac1000
Date: Tue, 29 Oct 2024 12:54:08 +0100	[thread overview]
Message-ID: <20241029115419.1160201-1-maxime.chevallier@bootlin.com> (raw)

Hi,

This series is another take on the pervious work [1] done by
Alexis Lothoré, that fixes the support for external snapshots
timestamping in GMAC3-based devices.

The registers that are used to configure this don't have the same layout
in the dwmac1000 compared to dwmac4 and others.

One example would be the TS seconds/nanoseconds registet for snapshots,
which aren't mapped at the 0x48/0x4c but rather at 0x30/0x34.

Another example is the was the snapshots are enabled. DWMAC4 has a
dedicated auxiliary control register (PTP_ACR at 0x40) while on
DWMAC1000, this is controled through the PTP Timestamp Control Reg using
fields maked as reserved on DWMAC4.

Interrupts are also not handled the same way, as on dwmac1000 they are
cleared by reading the Auxiliary Status Reg, which simply doesn't exist
on dwmac4.

All of this means that with the current state of the code, auxiliary
timestamps simply don't work on dwmac1000.

Besides that, there are some limitations in the number of external
snapshot channels. It was also found that the PPS out configuration is
also not done the same way, but fixing PPS out isn't in the scope of
this series.

To address that hardware difference, we introduce dedicated
ptp_clock_info ops and parameters as well as dedicated hwtstamp_ops for
the dwmac100/dwmac1000. This allows simplifying the code for these
platforms, and avoids the introduction of other sets of stmmac internal
callbacks.

The naming for the non-dwmac1000 ops wasn't changed, so we have :
 - dwmac1000_ptp & stmmac_ptp
 - dwmac1000_ptp_clock_ops & stmmac_ptp_clock_ops

where the "stmmac_*" ops use the dwmac4-or-later behaviour.

I have converted dwmac100 along the way to these ops, however that's
hasn't been tested nor fully confirmed that this is correct, as I don't
have datasheets for devices that uses dwmac100.

I've converted dwmac100 just on the hypothesis that the GMAC3_X PTP offset
being used in both dwmac1000 and dwmac100 means that they share these same
register layouts as well.

Patch 1 prepares the use of per-hw interface ptp_clock_info by avoiding
the modification of the global parameters. This allows making the
stmmac_ptp_clock_ops const.

Patch 2 adds the ptp_clock_info as an hwif parameter.

Patch 3 addresses the autodiscovery of the timestamping features, as
dwmac1000 doesn't provide these parameters

Patch 4 introduces the ptp_clock_info specific to dwmac1000 platforms,
and Patch 5 the hwtstamping info.

Patch 6 enables the timestamping interrupt for external snapshot

Patch 7 removes a non-necessary include from stmmac_ptp.c.

This was tested on dwmac_socfpga, however this wasn't tested on a
dwmac4-based platform.

[1]: https://lore.kernel.org/netdev/20230616100409.164583-1-alexis.lothore@bootlin.com/

Thanks Alexis for laying the groundwork for this,

Best regards,

Maxime

Maxime Chevallier (7):
  net: stmmac: Don't modify the global ptp ops directly
  net: stmmac: Use per-hw ptp clock ops
  net: stmmac: Only update the auto-discovered PTP clock features
  net: stmmac: Introduce dwmac1000 ptp_clock_info and operations
  net: stmmac: Introduce dwmac1000 timestamping operations
  net: stmmac: Enable timestamping interrupt on dwmac1000
  net: stmmac: Don't include dwmac4 definitions in stmmac_ptp

 drivers/net/ethernet/stmicro/stmmac/common.h  |  4 +
 .../net/ethernet/stmicro/stmmac/dwmac1000.h   | 15 +++-
 .../ethernet/stmicro/stmmac/dwmac1000_core.c  | 85 +++++++++++++++++++
 drivers/net/ethernet/stmicro/stmmac/hwif.c    | 14 ++-
 .../ethernet/stmicro/stmmac/stmmac_hwtstamp.c | 11 +++
 .../net/ethernet/stmicro/stmmac/stmmac_ptp.c  | 38 +++++++--
 .../net/ethernet/stmicro/stmmac/stmmac_ptp.h  | 10 +++
 7 files changed, 165 insertions(+), 12 deletions(-)

-- 
2.47.0



             reply	other threads:[~2024-10-29 12:21 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-29 11:54 Maxime Chevallier [this message]
2024-10-29 11:54 ` [PATCH net-next 1/7] net: stmmac: Don't modify the global ptp ops directly Maxime Chevallier
2024-10-29 11:54 ` [PATCH net-next 2/7] net: stmmac: Use per-hw ptp clock ops Maxime Chevallier
2024-10-29 11:54 ` [PATCH net-next 3/7] net: stmmac: Only update the auto-discovered PTP clock features Maxime Chevallier
2024-10-29 12:50   ` Alexis Lothoré
2024-10-29 11:54 ` [PATCH net-next 4/7] net: stmmac: Introduce dwmac1000 ptp_clock_info and operations Maxime Chevallier
2024-10-29 11:54 ` [PATCH net-next 5/7] net: stmmac: Introduce dwmac1000 timestamping operations Maxime Chevallier
2024-10-29 11:54 ` [PATCH net-next 6/7] net: stmmac: Enable timestamping interrupt on dwmac1000 Maxime Chevallier
2024-10-29 11:54 ` [PATCH net-next 7/7] net: stmmac: Don't include dwmac4 definitions in stmmac_ptp Maxime Chevallier
2024-10-29 14:45 ` [PATCH net-next 0/7] Support external snapshots on dwmac1000 Alexis Lothoré
2024-10-29 14:49   ` Maxime Chevallier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20241029115419.1160201-1-maxime.chevallier@bootlin.com \
    --to=maxime.chevallier@bootlin.com \
    --cc=alexandre.torgue@foss.st.com \
    --cc=alexis.lothore@bootlin.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=joabreu@synopsys.com \
    --cc=kuba@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=richardcochran@gmail.com \
    --cc=thomas.petazzoni@bootlin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox