Message-ID: <c4831e26-5ff0-40b1-98d4-addfdc1ee5a8@linaro.org>
Date: Thu, 4 Jan 2024 08:47:12 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Jie Luo <quic_luoj@...cinc.com>, agross@...nel.org, andersson@...nel.org,
 konrad.dybcio@...aro.org, 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, andrew@...n.ch,
 hkallweit1@...il.com, linux@...linux.org.uk, robert.marko@...tura.hr
Cc: linux-arm-msm@...r.kernel.org, netdev@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 quic_srichara@...cinc.com
Subject: Re: [PATCH v4 5/5] dt-bindings: net: ipq4019-mdio: Document ipq5332
 platform

On 28/12/2023 08:38, Jie Luo wrote:
>>> Sorry for this confusion.
>>> Rob said the internal reference source can be decided by the absence of
>>> the property combined with compatible string, because i said the
>>
>> So all your three DT maintainers agree that lack of property for
>> choosing clock, defines the usage of interrupt source.
> 
> This is the reference clock source selection of CMN block, which
> generates the clocks for the Ethernet devices.
> 
>>
>> Now we had huge amount of arguments that you do not represent properly
>> the clock relationships. Still.
> 
> here is the clock topology.
> reference clock sources ---> CMN PLL ---> various output clocks

How do you guarantee that these clocks are enabled without proper
relationships described in DT? In current and future designs?

> 
> the output clocks are provided to the Ethernet devices(such as the
> qca808x PHY devices).
> 
> These information is also provided the commit message of the patch
> <net: mdio: ipq4019: configure CMN PLL clock for ipq5332>.
> 
>>
>>> internal 96MHZ is used on ipq5018 currently in the previous message.
>>>
>>> per double checked the current IPQ platforms, the internal 96MHZ is also
>>> possible on ipq9574, and the reference clock source should be kept as
>>> configurable instead of limited by the compatible string, maybe the
>>> different reference clock source is acquired in the future, even
>>> currently it is not used on the special platform for now.
>>>
>>> so i update the solution with a little bit of changes.
>>
>> You still do not want to implement our suggestions and I don't
>> understand your arguments. Nothing in above paragraph explains me why
>> you cannot use clock provider/consumer relationships.
> 
> Hi Krzysztof,
> 
> The reference clock source can be registered as the fix clock provider,
>  From the current fix clock provider, the clock rate is useful for the
> clock consumer, the fix clock rate is used to generate the output clocks
> by the divider or multiplier.
> 
> For the CMN block to select reference clock, which is configuring the
> clock source, we don't know the formula to get the output clock value
> based on the reference clock value.

I don't understand what does it mean. You do not know how to program CMN
block?

> 
> i also see there is an example in the upstream code, which is same as
> the CMN block to select the reference clock source.

Oh, the old argument. So if there is a bug in the code, you are going
for example to implement it as well?

> 
> the property "ref-clock-frequency" is defined in the yaml file below.
> Documentation/devicetree/bindings/net/wireless/ti,wlcore.yaml.

And how does the hardware look like there? It's TI, so how do you even know?



Best regards,
Krzysztof

Powered by blists - more mailing lists