From: Kiran Kumar C.S.K <quic_kkumarcs@quicinc.com>
To: "Russell King (Oracle)" <linux@armlinux.org.uk>
Cc: Andrew Lunn <andrew@lunn.ch>, <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:29:53 +0530 [thread overview]
Message-ID: <ba1bf2a6-76b7-4e82-b192-86de9a8b8012@quicinc.com> (raw)
In-Reply-To: <Zv_6mf3uYcqtHC2j@shell.armlinux.org.uk>
On 10/4/2024 7:54 PM, Russell King (Oracle) wrote:
> On Thu, Oct 03, 2024 at 11:20:03PM +0530, Kiran Kumar C.S.K wrote:
>>>> +---------+
>>>> | 48MHZ |
>>>> +----+----+
>>>> |(clock)
>>>> v
>>>> +----+----+
>>>> +------| CMN PLL |
>>>> | +----+----+
>>>> | |(clock)
>>>> | v
>>>> | +----+----+ +----+----+ clock +----+----+
>>>> | +---| NSSCC | | GCC |--------->| MDIO |
>>>> | | +----+----+ +----+----+ +----+----+
>>>> | | |(clock & reset) |(clock & reset)
>>>> | | v v
>>>> | | +-----------------------------+----------+----------+---------+
>>>> | | | +-----+ |EDMA FIFO | | EIP FIFO|
>>>> | | | | SCH | +----------+ +---------+
>>>> | | | +-----+ | | |
>>>> | | | +------+ +------+ +-------------------+ |
>>>> | | | | BM | | QM | | L2/L3 Switch Core | |
>>>> | | | +------+ +------+ +-------------------+ |
>>>> | | | | |
>>>> | | | +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ |
>>>> | | | | MAC0 | | MAC1 | | MAC2 | | MAC3 | | XGMAC4| |XGMAC5 | |
>>>> | | | +---+---+ +---+---+ +---+---+ +---+---+ +---+---+ +---+---+ |
>>>> | | | | | | | | | |
>>>> | | +-----+---------+---------+---------+---------+---------+-----+
>>>> | | | | | | | |
>>>> | | +---+---------+---------+---------+---+ +---+---+ +---+---+
>>>> +--+---->| PCS0 | | PCS1 | | PCS2 |
>>>> | clock +---+---------+---------+---------+---+ +---+---+ +---+---+
>>>> | | | | | | |
>>>> | +---+---------+---------+---------+---+ +---+---+ +---+---+
>>>> | clock +----------------+ | | | | |
>>>> +------->|Clock Controller| 4-port Eth PHY | | PHY4 | | PHY5 |
>>>> +----------------+--------------------+ +-------+ +-------+
> ...
>>>> 3) PCS driver patch series:
>>>> Driver for the PCS block in IPQ9574. New IPQ PCS driver will
>>>> be enabled in drivers/net/pcs/
>>>> Dependent on NSS CC patch series (2).
>>>
>>> I assume this dependency is pure at runtime? So the code will build
>>> without the NSS CC patch series?
>>
>> The MII Rx/Tx clocks are supplied from the NSS clock controller to the
>> PCS's MII channels. To represent this in the DTS, the PCS node in the
>> DTS is configured with the MII Rx/Tx clock that it consumes, using
>> macros for clocks which are exported from the NSS CC driver in a header
>> file. So, there will be a compile-time dependency for the dtbindings/DTS
>> on the NSS CC patch series. We will clearly call out this dependency in
>> the cover letter of the PCS driver. Hope that this approach is ok.
>
> Please distinguish between the clocks that are part of the connection
> between the PCS and PHY and additional clocks.
>
> For example, RGMII has its own clocks that are part of the RGMII
> interface. Despite DT having a way to describe clocks, these clocks
> are fundamental to the RGMII interface and are outside of the scope
> of DT to describe. Their description is implicit in the relationship
> between the PHY and network driver.
>
> Also, the PCS itself is a subset of the network driver, and we do
> not (as far as I know) ever describe any kind of connection between
> a PCS and PHY. That would be madness when we have situations where
> the PHY can change its serdes mode, causing the MAC to switch
> between several PCS - which PCS would one associate the PHY with in
> DT when the "mux" is embedded in the ethernet driver and may be
> effectively transparent?
>
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 |
+-------+ | | | | | |
| +-----------+ | | |
+-----------------------------------+ | |
+--+---------+----------+-------+---+ | |
+-------+ | UNIPHY1 | | |
| | | +-----------+ | | |
|(X)GPHY| | +-------+ | | (X)GMII| | |
| +<----+ |SerDes | | (X)PCS |--------|------|- MAC4 |
| | | | | | | | | |
+-------+ | +-------+ | | | | |
| +-----------+ | | |
+-----------------------------------+ | |
+--+--------+-----------+-------+---+ | |
+-------+ | UNIPHY2 | | |
| | | +-----------+ | | |
|(X)GPHY| | +-------+ | | (X)GMII| | |
| +<----+ |SerDes | | (X)PCS |--------|------|- MAC5 |
| | | | | | | | | |
+-------+ | +-------+ | | | | |
| +-----------+ | | |
+-----------------------------------+ +-----------+
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.
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.
Thank you.
next prev parent reply other threads:[~2024-10-22 10:00 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 [this message]
2024-10-22 13:37 ` Andrew Lunn
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=ba1bf2a6-76b7-4e82-b192-86de9a8b8012@quicinc.com \
--to=quic_kkumarcs@quicinc.com \
--cc=agross@kernel.org \
--cc=andersson@kernel.org \
--cc=andrew@lunn.ch \
--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_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®