[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <6a7d62fc-a518-4aab-bb28-9289c398b74b@quicinc.com>
Date: Mon, 8 Jan 2024 16:27:00 +0800
From: Jie Luo <quic_luoj@...cinc.com>
To: Andrew Lunn <andrew@...n.ch>
CC: Christian Marangi <ansuelsmth@...il.com>,
"Russell King (Oracle)"
<linux@...linux.org.uk>,
<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 1/5/2024 9:37 PM, Andrew Lunn wrote:
>>> O.K. Since we are getting nowhere at the moment, lets take just the
>>> pure PHY chip, and ignore the rest for the moment.
>>>
>>> For any pure PHY, there is generally one clock input, which might be a
>>> crystal, or an actual clock. If you look at other DT bindings for
>>> PHYs, it is only listed if the clock is expected to come from
>>> somewhere else, like a SoC, and it needs to be turned on before the
>>> PHY will work. And generally, a pure PHY has one defined clock
>>> frequency input. If that is true, there is no need to specify the
>>> clock. If multiple clock input frequencies are supported, then you do
>>> need to specify the clock, so its possible to work out what frequency
>>> it is using. How that clock input is then used internally in the PHY
>>> is not described in DT, but the driver can set any dividers, PLLs
>>> needed etc.
>>
>> Yes, Andrew, there is only one clock input to qca8084(same as qca8386),
>> this input clock rate is 50MHZ, which is from the output clock of CMN
>> PLL block that is configured by the MDIO bus driver patch under review.
>
> Lets concentrate on the pure PHY. All it sees is a clock. It does not
> care where it come from. All you need in the device tree for the pure
> PHY is a clock consumer.
Yes.
>
> There is one clock input, so its shared by all four instances in the
> pure PHY package. So you need to use Christians code which extends the
> PHY DT bindings to allow DT properties for a package of PHYs.
OK, will
>
> What about resets. Is there one reset pin for the pure PHY package, or
> one per PHY?
There is only one GPIO hardware reset PIN for the chip qca8084 including
all 4 PHYs.
>
> Go find Christians code, understand it, and propose a DT binding for
> the pure PHY. Include the clock provider and the reset
> provider. Forget about the MDIO controller, and the PHY integrated
> into the switch, etc. Baby steps...
Thanks Andrew for pointing me the Christians code, i will keep the
driver of qca8084 synced with Christian's code before pushing the
next patch set.
>
>> In qca8084(same as qca8386), there is a clock controller, let's call it
>> as NSSCC, the logic of NSSCC is same as qualcomm GCC(located in SoC),
>> the NSSCC provides the clocks to the quad PHYs, the initial clocks for
>> quad PHYs need to be configured before PHY to work.
>
> You said above, there is one clock input to the qca8084. Here you use
> the word clocks, plural. Is there one clock, or multiple clocks?
>
> Andrew
Yes, Andrew, it is multiple clocks.
These multiple clocks are generated(PLL, divider) and used internally by
qca8084 CHIP, these clocks are generated by the clock controller of
qca8084, let's call the clock controller of qca8084 as NSSCC provider,
which generates the clocks to the PHYs, this NSSCC is located in
qca8084.
The only one input clock of qca8084 is the clock source of the chip
qca8084, which is fixed to 50MHZ.
The NSSCC of qca8084 generates different clock rates for the different
link speed of the PHY, which is the internal block of qca8084.
Powered by blists - more mailing lists