On 8/10/2024 7:30 PM, Krzysztof Kozlowski wrote:
On 09/08/2024 15:01, Jie Luo wrote:
+ clock-names:
+ items:
+ - const: ref
+ - const: ahb
+ - const: sys
+
+ clock-output-names:
+ items:
+ - const: ppe-353mhz
+ - const: eth0-50mhz
+ - const: eth1-50mhz
+ - const: eth2-50mhz
+ - const: eth-25mhz
Drop entire property. If the names are fixed, what's the point of having
it in DTS? There is no.
We had added the output names here for the reasons below. Can you please
let us know your suggestion whether keeping these here is fine?
1.) These output clocks are used as input reference clocks to other
consumer blocks. For example, an on-board Ethernet PHY device may be
wired to receive a specific clock from the above output clocks as
reference clock input, and hence the PHY's DTS node would need to
reference a particular index in this output clock array.
Without these output clocks being made available in this DTS, the PHY
driver in above case would not know the clock specifier to access the
handle for the desired input clock.
That's not true. clock-output-names do not have anything to do with
clock specifier.
2.) One of the suggestions from the internal code review with Linaro was
to name the output clocks specifically based on rate and destination
(Ex: 'ppe-353mhz' for fixed rate 353 MHZ output clock connected to
Packet Process Engine block), so that the dt-bindings describe the
input/output clocks clearly.
Again, that's unrelated. None of above points address my concern. It's
like you talk about some entirely different topic. Again:
clock-output-names have nothing to do with what you want to achieve here.
OK, understand. I will drop this property "clock-output-names" from the
bindings and DTS. These names will instead be defined in the driver. For
the consumer clock device DTS nodes that need to reference these output
clocks, I will export the clock specifiers for these output clocks from
a header file. Hope this approach is fine.
Best regards,
Krzysztof
