[PATCH v2 5/9] dt-bindings: clk: mpfs: add defines for two new clocks
Conor Dooley
mail at conchuod.ie
Tue Apr 12 11:29:31 PDT 2022
On 12/04/2022 18:10, Krzysztof Kozlowski wrote:
> On 12/04/2022 14:26, Conor.Dooley at microchip.com wrote:
>>>> Additionally MSSPLL is the source for CLK_{CPI,AXI,AHB} so I put it at
>>>> the top. I have no particular preference, so if you want them reordered
>>>> so that MSSPLL is under RTCREF just say the word :)
>>>
>>> Hm, are these in the same clock controller (device, not driver)? If yes,
>>> then please order them numerically. Pretty often one binding header have
>>> IDs for several clock controllers, so then it's a different case.
>>
>> Not *quite* sure what you mean by device. There is only one SoC that
>> this header applies to, but in the actual design the MSSPLL is in one
>> block, the RTC divider in another and CLK_CPU -> CLK_CFM in a third.
>
> By device I meant here part of Soc responsible for clocks which could be
> called a self-containing block. Pretty often such block maps to a Linux
> "struct device" or some wrapper around it (e.g. clock-controller
> device). For example such "self-containing block" has device node in DTS.
>
> Judging by your description, these will be different blocks / device
> nodes in DTS?
The way it's implemented is a bit interconnected and none of the three
blocks would satisfy a "self contained" constraint. Eg. The rtcref
divider's control reg sits between two registers responsible for the
CLK_CPU -> CLK_CFM clocks but it's input clock mux is in the same
sub-block as the MSSPLL.
I guess its better put that each of the three are sub-blocks of a self
contained clock controller for the mss core complex. There are several
other clock domains on the chip which would have distinct clock
controllers & may be added to this header in the future, if letting
Linux control them makes any sense. For example, clocks in (and used for
the clocking of) the fpga fabric.
This controller is a single node in the device tree. Sounds like
reordering it numerically makes the most sense then - I'll resend
tomorrow if that's okay.
Thanks,
Conor.
More information about the linux-riscv
mailing list