Date: Mon, 18 Dec 2023 13:22:06 +0800
From: Jie Luo <quic_luoj@...cinc.com>
To: Christian Marangi <ansuelsmth@...il.com>
CC: "Russell King (Oracle)" <linux@...linux.org.uk>,
        Andrew Lunn
	<andrew@...n.ch>, <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>
Subject: Re: [PATCH v8 14/14] dt-bindings: net: ar803x: add qca8084 PHY
 properties



On 12/17/2023 12:01 AM, Christian Marangi wrote:
> On Sat, Dec 16, 2023 at 10:41:28PM +0800, Jie Luo wrote:
>>
>>
>> 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.
> 
> Hi,
> sorry for stepping in. I guess here there is a massive confusion with
> naming and using qca8k.
> 
> Since it seems the same name is used for PHY and for Switch stuff, I
> would add PHY and MAC prefix when referring to qca8064.

Hi Christian,
Welcome to join the discussion.

Sorry for the confusion, since the switch and PHY are the different
chips, the switch chip is named as qca8386, the pure PHY chip is named
as qca8084, the pure PHY chip qca8084 is connected with the SoC by PCS
working on 10g-qxgmii, the switch chip qca8386 is connected with SoC by
PCS working on sgmii.

> 
> With the previous message I was a bit confused by the use of qca8k and
> didn't know you were actually referring to the DSA driver.
> Interesting... this is for the upcoming WiFi 7 platoform right? (ipq9574)

For qca8386, it is the switch chip and leverages the qca8k DSA driver,
it is connected on the ipq5332 platform currently.

But for qca8084, it is the pure PHY chip, which works on 10g-qxgmii for
quad-phy, which is connected on the ipq9574.

> 
> All these discussion comes for the problem of using this PHY as an
> integrated PHY in the qca8386 switch and trying to select the mode in
> the PHY driver.

Yes, for qca8386, the PHY is integrated to switch, since same PHY needs
to work with qca8386 and qca8084, so the work mode needs to be
configured to distinguish the different work mode as the patch
<[PATCH v8 13/14] net: phy: at803x: configure qca8084 work mode>.

> 
> Considering you would use the same logic of the current DSA qca8k driver
> with the integrated PHY, the problem doesn't apply or a different
> implementation should be used (and actually handled later when the
> actual DSA code will come)

qca8386 has some differences from qca8337(qca8k dsa driver), qca8337
integrated PHY can work by the general PHY, but the PHY in qca8386 needs
the extra PHY driver, and the GCC clocks introduced.

> 
> I would expect in the integrated mode, the switch to handle the PHY (as
> it's done by qca8337) with the PHY defined in the switch node and qca8k
> handling the PHY registration. With the following implementation flags
> can be passed and PHY can be configured to integrated mode. (or virtual
> PHY ID can be used for such scope with dedicated functions in the PHY
> driver)
> 
Since there is the pure PHY chip qca8084 using the same PHY, which does
not enable the DSA driver.

So the PHY driver should be standalone, and the common clocks and resets
is better to put in the PHY driver, since these are the common configs
for the qca8386 and qca8084.

> With this in mind the entire integrated problem can put on hold and
> dropped to be later reimplemented when it's time. (assuming that all the
> prereq are already here and the very same implementation of qca8k will
> be used)

For the qca8386, it is true very same implementation of qca8k, besides
the 2.5G capability and GCC clock involved.

> 
> Anyway, I'm more or less the maintainer of the qca8k.c DSA driver and I
> would be more than happy to help you guys internally or externally on
> pushing and make this proceed further. (again assuming this is ipq9574
> stuff, it would be good to finally have proper DSA driver instead of
> leaving the thing unusable as it's the current situation with ipq8074)

Yes, the pure PHY chip qca8084 is connected on ipq9574 platform,
and the switch chip qca8386 is connected on ipq5332 platform.

Many thanks Christian again, will add you when pushing the qca8386 DSA
patches for upstream review.

> 
>>
>> 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