mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: "Kiran Kumar C.S.K" <quic_kkumarcs@quicinc.com>
Cc: "Russell King (Oracle)" <linux@armlinux.org.uk>,
	netdev@vger.kernel.org, Andy Gross <agross@kernel.org>,
	Bjorn Andersson <andersson@kernel.org>,
	Konrad Dybcio <konrad.dybcio@linaro.org>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Jacob Keller <jacob.e.keller@intel.com>,
	Bhupesh Sharma <bhupesh.sharma@linaro.org>,
	linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, vsmuthu@qti.qualcomm.com,
	arastogi@qti.qualcomm.com, linchen@qti.qualcomm.com,
	john@phrozen.org, Luo Jie <quic_luoj@quicinc.com>,
	Pavithra R <quic_pavir@quicinc.com>,
	"Suruchi Agarwal (QUIC)" <quic_suruchia@quicinc.com>,
	"Lei Wei (QUIC)" <quic_leiwei@quicinc.com>
Subject: Re: RFC: Advice on adding support for Qualcomm IPQ9574 SoC Ethernet
Date: Tue, 22 Oct 2024 15:37:36 +0200	[thread overview]
Message-ID: <7b5227fc-0114-40be-ba5d-7616cebb4bf9@lunn.ch> (raw)
In-Reply-To: <ba1bf2a6-76b7-4e82-b192-86de9a8b8012@quicinc.com>

> Apologies for the delay in response. I understand that the PCS<->PHY
> clocks may be out of the scope of PCS DT due to the reasons you mention.
> However would like to clarify that the MII clocks referred to here, are
> part of the connection between the MAC and PCS and not between PCS and PHY.
> 
> Below is a diagram that shows the sub-blocks inside the 'UNIPHY' block
> of IPQ9574 which houses the PCS and the serdes, along with the clock
> connectivity. The MII Rx/Tx clocks are supplied from the NSS CC, to the
> GMII channels between PCS and MAC. So, it seemed appropriate to have
> these clocks described as part of the PCS DT node.
> 
>               +-------+ +---------+  +-------------------------+
>    -----------|CMN PLL| |  GCC    |  |   NSSCC (Divider)       |
>    |25/50mhz  +----+--+ +----+----+  +--+-------+--------------+
>    |clk            |         |          ^       |
>    |       31.25M  |  SYS/AHB|clk  RX/TX|clk    +------------+
>    |       ref clk |         |          |       |            |
>    |               |         v          | MII RX|TX clk   MAC| RX/TX clk
>    |            +--+---------+----------+-------+---+      +-+---------+
>    |            |  |   +----------------+       |   |      | |     PPE |
>    v            |  |   |     UNIPHY0            V   |      | V         |
>   +-------+     |  v   |       +-----------+ (X)GMII|      |           |
>   |       |     |  +---+---+   |           |--------|------|-- MAC0    |
>   |       |     |  |       |   |           | (X)GMII|      |           |
>   |  Quad |     |  |SerDes |   |  (X)PCS   |--------|------|-- MAC1    |
>   |       +<----+  |       |   |           | (X)GMII|      |           |
>   |(X)GPHY|     |  |       |   |           |--------|------|-- MAC2    |
>   |       |     |  |       |   |           | (X)GMII|      |           |
>   |       |     |  +-------+   |           |--------|------|-- MAC3    |
>   +-------+     |              |           |        |      |           |
>                 |              +-----------+        |      |           |
>                 +-----------------------------------+      |           |

Thanks for the detailed diagram. That always helps get things
straight.

Im i correct in says that MII RX|TX is identical to MAC RX|TX? These
two clocks are used by the MAC and XPCS to clock data from one to the
other? If they are the exact same clocks, i would suggest you use the
same name, just to avoid confusion.

Both XPCS and PPE are clock consumers, so both will have a phandle
pointing to the NSSCC clock provider?

> We had one other question on the approach used in the driver for PCS
> clocks, could you please provide your comments.
> 
> As we can see from the above diagram, each serdes in the UNIPHY block
> provides the clocks to the NSSCC, and the PCS block consumes the MII
> Rx/Tx clocks. In our current design, the PCS/UNIPHY driver registers a
> provider driver for the clocks that the serdes supplies to the NSS CC.

That sounds reasonable.

> It also enables the MII Rx/Tx clocks which are supplied to the PCS from
> the NSS CC. Would this be an acceptable design to have the PCS driver
> register the clock provider driver and also consume the MII Rx/Tx
> clocks? It may be worth noting that the serdes and PCS are part of the
> same UNIPHY block and also share same register region.

Does the SERDES consume the MII Rx/Tx? Your diagram indicates it does
not. I'm just wondering if you have circular dependencies at runtime?

Where you will need to be careful is probe time vs runtime. Since you
have circular phandles you need to first create all the clock
providers, and only then start the clock consumers. Otherwise you
might get into an endless EPROBE_DEFER loop.

	Andrew

  reply	other threads:[~2024-10-22 13:37 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <f0f0c065-bf7c-4106-b5e2-bfafc6b52101@quicinc.com>
2024-10-02 20:37 ` Kiran Kumar C.S.K
2024-10-02 21:28   ` Andrew Lunn
2024-10-03 17:50     ` Kiran Kumar C.S.K
2024-10-03 18:42       ` Andrew Lunn
2024-10-04 13:06         ` Kiran Kumar C.S.K
2024-10-04 13:31           ` Andrew Lunn
2024-10-04 14:03           ` Krzysztof Kozlowski
2024-10-04 14:02         ` Krzysztof Kozlowski
2024-10-03 19:20       ` Bjorn Andersson
2024-10-04 14:17         ` Kiran Kumar C.S.K
2024-10-04 14:50           ` Andrew Lunn
2024-10-08 19:31             ` Kiran Kumar C.S.K
2024-10-05 18:30           ` Bjorn Andersson
2024-10-08 19:33             ` Kiran Kumar C.S.K
2024-10-04 14:24       ` Russell King (Oracle)
2024-10-22  9:59         ` Kiran Kumar C.S.K
2024-10-22 13:37           ` Andrew Lunn [this message]
2024-10-24 13:25             ` Kiran Kumar C.S.K
2024-10-24 14:27               ` Andrew Lunn
2024-10-25 13:03                 ` Kiran Kumar C.S.K

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=7b5227fc-0114-40be-ba5d-7616cebb4bf9@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=agross@kernel.org \
    --cc=andersson@kernel.org \
    --cc=arastogi@qti.qualcomm.com \
    --cc=bhupesh.sharma@linaro.org \
    --cc=conor+dt@kernel.org \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=edumazet@google.com \
    --cc=jacob.e.keller@intel.com \
    --cc=john@phrozen.org \
    --cc=konrad.dybcio@linaro.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=kuba@kernel.org \
    --cc=linchen@qti.qualcomm.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=p.zabel@pengutronix.de \
    --cc=pabeni@redhat.com \
    --cc=quic_kkumarcs@quicinc.com \
    --cc=quic_leiwei@quicinc.com \
    --cc=quic_luoj@quicinc.com \
    --cc=quic_pavir@quicinc.com \
    --cc=quic_suruchia@quicinc.com \
    --cc=robh+dt@kernel.org \
    --cc=vsmuthu@qti.qualcomm.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

all inboxes | Powered by JetHome®