netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
Cc: Alexandre Torgue <alexandre.torgue@foss.st.com>,
	Giuseppe Cavallaro <peppe.cavallaro@st.com>,
	Jose Abreu <joabreu@synopsys.com>,
	netdev <netdev@vger.kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Subject: Re: [QUERY] : STMMAC Clocks
Date: Sat, 1 Mar 2025 10:35:45 +0000	[thread overview]
Message-ID: <Z8LjAbz5QmaMeHbO@shell.armlinux.org.uk> (raw)
In-Reply-To: <CA+V-a8u04AskomiOqBKLkTzq3uJnFas6sitF6wbNi=md6DtZbw@mail.gmail.com>

On Fri, Feb 28, 2025 at 09:51:15PM +0000, Lad, Prabhakar wrote:
> Hi All,
> 
> I am bit confused related clocks naming in with respect to STMMAC driver,
> 
> We have the below clocks in the binding doc:
> - stmmaceth
> - pclk
> - ptp_ref
> 
> But there isn't any description for this. Based on this patch [0]
> which isn't in mainline we have,
> - stmmaceth - system clock
> - pclk - CSR clock
> - ptp_ref - PTP reference clock.
> 
> [0] https://patches.linaro.org/project/netdev/patch/20210208135609.7685-23-Sergey.Semin@baikalelectronics.ru/
> 
> Can somebody please clarify on the above as I am planning to add a
> platform which supports the below clocks:
> - CSR clock
> - AXI system clock
> - Tx & Tx-180
> - Rx & Rx-180

I'm afraid the stmmac driver is a mess when it comes to clocks.

According to the databook, the DW GMAC IP has several clocks:

clk_tx_i - 0° transmit clock
clk_tx_180_i - 180° transmit clock (synchronous to the above)

I've recently added generic support for clk_tx_i that platforms can
re-use rather than implementing the same thing over and over. You can
find that in net-next as of yesterday.

clk_rx_i - 0° receive clock
clk_rx_180_i - 180° of above

These are synchronous to the datastream from the PHY, and generally
come from the PHY's RXC or from the PCS block integrated with the
GMAC. Normally these require no configuration, and thus generally
don't need mentioning in firmware.

The host specific interface clocks in your case are:

- clock for AXI (for AXI DMA interface)
- clock for CSR (for register access and MDC)

There are several different possible synthesis options for these
clocks, so there will be quite a bit of variability in these. I haven't
yet reviewed the driver for these, but I would like there to be
something more generic rather than each platform implementing basically
the same thing but differently.

snps,dwc-qos-ethernet.txt lists alternative names for these clocks:

"tx" - clk_tx_i (even mentions the official name in the description!)
"rx" - clk_rx_i (ditto)
"slave_bus" - says this is the CSR clock - however depending on
   synthesis options, could be one of several clocks
"master_bus" - AHB or AXI clock (which have different hardware names)
"ptp_ref" - clk_ptp_ref_i

I would encourage a new platform to either use the DW GMAC naming for
these clocks so we can start to have some uniformity, or maybe we could
standardise on the list in dwc-qos-ethernet.

However, I would like some standardisation around this. The names used
in snps,dwmac with the exception of ptp_ref make no sense as they don't
correspond with documentation, and convey no meaning.

If we want to go fully with the documentation, then I would suggest:

	hclk_i, aclk_i, clk_app_i - optional (depends on interface)
	clk_csr_i - optional (if not one of the above should be supplied
			      as CSR clock may be the same as one of the
			      above.)
	clk_tx_i - transmit clock
	clk_rx_i - receive clock

As there is a configuration where aclk_i and hclk_i could be present
(where aclk_i is used for the interface and hclk_i is used for the CSR)
it may be better to deviate for clk_csr_i and use "csr" - which would
always point at the same clock as one of hclk_i, aclk_i, clk_app_i or
the separate clk_csr_i.

Essentially, this needs discussion before settling on something saner
than what we currently have.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

  parent reply	other threads:[~2025-03-01 10:36 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-28 21:51 [QUERY] : STMMAC Clocks Lad, Prabhakar
2025-02-28 23:38 ` Andrew Lunn
2025-03-01 10:41   ` Russell King (Oracle)
2025-03-01 15:15     ` Andrew Lunn
2025-03-01 15:51       ` Russell King (Oracle)
2025-03-02 16:51   ` Lad, Prabhakar
2025-03-01 10:35 ` Russell King (Oracle) [this message]
2025-03-02 17:37   ` Lad, Prabhakar
2025-03-02 19:06     ` Russell King (Oracle)

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=Z8LjAbz5QmaMeHbO@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=alexandre.torgue@foss.st.com \
    --cc=joabreu@synopsys.com \
    --cc=krzysztof.kozlowski@linaro.org \
    --cc=netdev@vger.kernel.org \
    --cc=peppe.cavallaro@st.com \
    --cc=prabhakar.csengg@gmail.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;
as well as URLs for NNTP newsgroup(s).