Message-ID: <6abe5d6f-9d00-445f-8c81-9c89b9da3e0a@quicinc.com>
Date: Sat, 16 Dec 2023 22:41:28 +0800
From: Jie Luo <quic_luoj@...cinc.com>
To: "Russell King (Oracle)" <linux@...linux.org.uk>,
        Andrew Lunn
	<andrew@...n.ch>
CC: <davem@...emloft.net>, <edumazet@...gle.com>, <kuba@...nel.org>,
        <pabeni@...hat.com>, <robh+dt@...nel.org>,
        <krzysztof.kozlowski+dt@...aro.org>, <conor+dt@...nel.org>,
        <hkallweit1@...il.com>, <corbet@....net>, <p.zabel@...gutronix.de>,
        <f.fainelli@...il.com>, <netdev@...r.kernel.org>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-doc@...r.kernel.org>, Christian Marangi <ansuelsmth@...il.com>
Subject: Re: [PATCH v8 14/14] dt-bindings: net: ar803x: add qca8084 PHY
 properties



On 12/16/2023 9:51 PM, Russell King (Oracle) wrote:
> On Sat, Dec 16, 2023 at 11:21:53AM +0100, Andrew Lunn wrote:
>>> The following is the chip package, the chip can work on the switch mode
>>> like the existed upstream code qca8k, where PHY1-PHY4 is connected with
>>> MAC1-MAC4 directly;
>>
>> Ah, that is new information, and has a big effect on the design.
> 
> This QCA8084 that's being proposed in these patches is not a PHY in
> itself, but is a SoC. I came across this:
> 
>   https://www.rt-rk.com/android-tv-solution-tv-in-smartphone-pantsstb-based-on-qualcomm-soc-design/

The chip mentioned in the link you mentioned is SoC, which is not the
chip that the qca8084 driver work for.

qca8084/qca8386 is just the Ethernet CHIP, not SoC, for the switch mode 
qca8386, which is most like qca8337 the dsa drive qca8k.c is already in 
upstream.

i qca8084 chip package includes 4 PHYs, 2 PCSs and the common chip level
modules such as GCC and security control modules, all these modules are
located in the qca8084 chip package, since qca8084 works on PHY mode, so
the MACs are not used.

qca8084 is connected with the SoC CHIP such as IPQ platform by PCS1
working on 10g-qxgmii mode and the fourth PHY can also optionally
be connected with the IPQ SoC PCS by sgmii mode, there is no more
interface on qca8084 to connect the external chips.

> It's sounding like what we have here is some PHY IP that is integrated
> into a larger SoC, and the larger SoC needs to be configured so the
> PHY IP can work correctly.

qca8084 is not a SoC, it is the Ethernet chip, in this qca8084 package,
there are GCC that is driving the PHY working on the various link speed.
that is the reason we need to do these package level common clocks and
resets initialization before probing PHY correctly.

> 
> Given that this package of four PHYs seems to be rather unique, I think
> we need Jie Luo to provide sufficient information so we can understand:
> 
> 1) this package of four PHYs itself

Yes, this chip package for all 4 PHYs itself, also including the PCSes
and common package level modules such as GCC.

> 2) how this package is integrated into the SoC

the qca8084 is connected with SoC by PCSes.

> 
> Specifically, what resets and clocks are controlled from within the
> package's register space, which are external to the package
> register space (and thus are provided by other IPs in the SoC).

All clocks and resets mentioned for qca8084 drive including package
level and PCS & PHY clocks and resets from the qca8084 internal GCC
modules register space,

> 
> As I've said previously, the lack of DT example doesn't help to further
> our understanding. The lack of details of what the package encompases
> also doesn't help us understand the hardware.

Indeed, i will add the qca8084 DT example in the next patch set.
BTW, i also replied your earlier comments by providing the DTS defined
for the current qca8084 drive code.

hope you can have a better understanding with the provided DTS code in
earlier reply of this email thread.
> 
> Unless we can gain that understanding, I feel that Jie Luo's patches
> are effectively unreviewable and can't be accepted into mainline.
> 

Powered by blists - more mailing lists