Re: [PATCH v4 5/5] dt-bindings: net: ipq4019-mdio: Document ipq5332 platform

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 1/4/2024 3:47 PM, Krzysztof Kozlowski wrote:
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?

Will update the patch to add the clock relationship in the DT, thanks.



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?

The output clock value of CMN block is not related to the clock value of
the reference source clock, the output clocks of CMN block are fixed to
25M and 50M, which are provided to the different Ethernet devices, there
is no formula for the relationship of input clock value and output clock
value of 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 reference source clock can be registered as fix clock, and we can
get the clock rate of reference source clock with the external or
internal flag to distinguish the reference clock source, then program
the CMN block corresponding.


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?

According to the driver code and DT description, the example is also for
selecting the reference clock source according to the clock value of DT
properties.

Sure, we can also use the registered fix clock to identify the
reference clock source for CMN block.




Best regards,
Krzysztof





[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux