Received-SPF: pass (google.com: domain of linux-kernel+bounces-773-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Message-ID: <7bae46fd-63fd-4b86-9a56-73052cf0ea95@quicinc.com>
Date: Fri, 15 Dec 2023 18:40:54 +0800
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 5/5] dt-bindings: net: ipq4019-mdio: Document ipq5332
 platform
Content-Language: en-US
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
        Conor Dooley
	<conor@kernel.org>
CC: <agross@kernel.org>, <andersson@kernel.org>, <konrad.dybcio@linaro.org>,
        <davem@davemloft.net>, <edumazet@google.com>, <kuba@kernel.org>,
        <pabeni@redhat.com>, <robh+dt@kernel.org>,
        <krzysztof.kozlowski+dt@linaro.org>, <conor+dt@kernel.org>,
        <andrew@lunn.ch>, <hkallweit1@gmail.com>, <linux@armlinux.org.uk>,
        <robert.marko@sartura.hr>, <linux-arm-msm@vger.kernel.org>,
        <netdev@vger.kernel.org>, <devicetree@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>, <quic_srichara@quicinc.com>
References: <20231212115151.20016-1-quic_luoj@quicinc.com>
 <20231212115151.20016-6-quic_luoj@quicinc.com>
 <20231212-caution-improvise-ed3cc6a1d305@spud>
 <11ffc985-3f2b-46b9-ae0b-911f7abe98d1@quicinc.com>
 <20231214-outshine-shush-8a11c68607cd@spud>
 <c5123ce7-6fdc-43c7-ac07-251c39196e66@quicinc.com>
 <a1e5ffec-a20d-4389-83f9-ee09bd9d733d@linaro.org>
 <a84a36af-69f8-46af-967e-b06d028597a3@quicinc.com>
 <26c8b0b1-5ea9-45cc-adf3-0d0b03a1284d@linaro.org>
 <4b9c56b8-3b29-4861-a3d5-2da26fbc14b4@quicinc.com>
 <2e77e3b1-00b6-46b9-bfed-7cae3ffa15e9@linaro.org>
From: Jie Luo <quic_luoj@quicinc.com>
In-Reply-To: <2e77e3b1-00b6-46b9-bfed-7cae3ffa15e9@linaro.org>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit


On 12/15/2023 6:37 PM, Krzysztof Kozlowski wrote:
> On 15/12/2023 11:33, Jie Luo wrote:
>>>>>>>>>> +  cmn-reference-clock:
>>>>>>>>>> +    oneOf:
>>>>>>>>>> +      - items:
>>>>>>>>>> +          - enum:
>>>>>>>>>> +              - 0   # CMN PLL reference internal 48MHZ
>>>>>>>>>> +              - 1   # CMN PLL reference external 25MHZ
>>>>>>>>>> +              - 2   # CMN PLL reference external 31250KHZ
>>>>>>>>>> +              - 3   # CMN PLL reference external 40MHZ
>>>>>>>>>> +              - 4   # CMN PLL reference external 48MHZ
>>>>>>>>>> +              - 5   # CMN PLL reference external 50MHZ
>>>>>>>>>> +              - 6   # CMN PLL reference internal 96MHZ
>>>>>>>>>
>>>>>>>>> Why is this not represented by an element of the clocks property?
>>>>>>>>
>>>>>>>> This property is for the reference clock source selection of CMN PLL,
>>>>>>>> CMN PLL generates the different clock rates for the different Ethernet
>>>>>>>> blocks, this CMN PLL configuration is not located in the GCC, so the
>>>>>>>> clock framework can't be used, which is the general hardware register
>>>>>>>> instead of RCG register for GCC.
>>>>>>>
>>>>>>> I don't see how the clock being provided by the "GCC" (whatever that is)
>>>>>>> or by some other clock controller or fixed clock makes a difference.
>>>>>>> Why can't the other clock provider be represented in the devicetree?
>>>>>>>
>>>>>>
>>>>>> cmn-reference-clock is for selecting the reference clock source for the
>>>>>> whole Ethernet block, which is just the standalone configure register.
>>>>>
>>>>> Sure, you are aware though that all clocks are just configure registers?
>>>>>
>>>>> Which clocks are these mentioned in the property? From where do they come?
>>>>>
>>>>> Anyway, property is in existing form is not correct - this is not a
>>>>> generic property.
>>>>>
>>>>
>>>> This property cmn-reference-clock is just the hardware register
>>>> configuration, since the different IPQ platform needs to select
>>>> the different reference clock source for the CMN PLL block that
>>>> provides the various clock outputs to the all kinds of Ethernet
>>>> devices, which is not from GCC provider.
>>>
>>> AGAIN: where do the clocks come from? Which device generates them?
>>
>> Oh, OK, the reference clock is from wifi that provides 48MHZ to
>> Ethernet block.
> 
> Then WiFi should be providing you the clock and this device should be
> clock consumer, right?

Yes, wifi provides 48MHz clock to CMM PLL block, there is no GCC
for this 48MHZ clock output, it is the hardware PIN connection.
> 
> 
> 
> Best regards,
> Krzysztof
>