Clock Management Implementation for MAX32657 UART0#6
Conversation
Two clock management drivers are added: - max32 clock source driver - max32 clock divider driver The clock source driver enables and disables various clock sources used by the max32 family of devices. The clock divider driver controls the system clock prescaler that generates the clock for the CPU complex and the peripherals. Signed-off-by: Eric Hay <Eric.Hay@analog.com>
Have the max32657 soc use the clock management framework instead of the clock control drivers to manage the clock tree. Signed-off-by: Eric Hay <Eric.Hay@analog.com>
Decompose the clock tree into basic entities, outputs, and states for use by the clock management framework. Signed-off-by: Eric Hay <Eric.Hay@analog.com>
The UART controller can receive and set its clock information from the clock management subsystem if the SoC supports using the management subsystem over the clock control subsystem. Signed-off-by: Eric Hay <Eric.Hay@analog.com>
Typically, a clock gate is enabled by setting a bit to 1 to allow the input signal to pass. Some systems though may invert this logic. An option is added to the generic clock gate driver to allow for inverted gates where setting a bit to 0 allows the input clock to pass. Signed-off-by: Eric Hay <Eric.Hay@analog.com>
Add appropriate muxes, gates, and clock states for proper operation of the UART controller when the clock management subsystem is used. Signed-off-by: Eric Hay <Eric.Hay@analog.com>
|
I'd rephrase the PR title as "Clock Management Implementation for MAX32657 UART0". |
| bclk_uart0: bclk_uart0 { | ||
| #clock-cells = <0>; | ||
| compatible = "clock-output"; | ||
|
|
||
| /* | ||
| * Since the sys_clk is what feeds the pclk, the following states | ||
| * must only be enabled when the corresponding sys_clk state is | ||
| * active. If there's a mismatch, the actual frequency will be | ||
| * different than what the state specifies. | ||
| */ | ||
|
|
||
| /* Depends on sys_clk_erfo_32 */ | ||
| bclk_uart0_16: bclk_uart0_16 { | ||
| compatible = "clock-state"; | ||
| clocks = <&clk_mgmt_uart_pclk 1 &bclk_src 0>; | ||
| clock-frequency = <DT_FREQ_M(16)>; | ||
| }; | ||
|
|
||
| /* Depends on sys_clk_erfo_16 */ | ||
| bclk_uart0_8: bclk_uart0_8 { | ||
| compatible = "clock-state"; | ||
| clocks = <&clk_mgmt_uart_pclk 1 &bclk_src 0>; | ||
| clock-frequency = <DT_FREQ_M(8)>; | ||
| }; | ||
|
|
||
| /* Depends on sys_clk_erfo_8 */ | ||
| bclk_uart0_4: bclk_uart0_4 { | ||
| compatible = "clock-state"; | ||
| clocks = <&clk_mgmt_uart_pclk 1 &bclk_src 0>; | ||
| clock-frequency = <DT_FREQ_M(4)>; | ||
| }; | ||
|
|
||
| /* Depends on sys_clk_ipo */ | ||
| bclk_uart0_ipo: bclk_uart0_ipo { | ||
| compatible = "clock-state"; | ||
| clocks = <&clk_mgmt_uart_pclk 1 &bclk_src 0>; | ||
| clock-frequency = <DT_FREQ_M(25)>; | ||
| }; | ||
|
|
||
| /* Depends on sys_clk_32k */ | ||
| bclk_uart0_16k: bclk_uart0_16k { | ||
| compatible = "clock-state"; | ||
| clocks = <&clk_mgmt_uart_pclk 1 &bclk_src 0>; | ||
| clock-frequency = <16384>; | ||
| }; | ||
|
|
||
| /* When using ibro, sys_clk is not a parent clock, so only the ibro source is used to determine the frequency. */ | ||
| bclk_uart0_ibro: bclk_uart0_ibro { | ||
| compatible = "clock-state"; | ||
| clocks = <&clk_mgmt_ibro 1 &clk_mgmt_uart_pclk 1 &bclk_src 1>; | ||
| clock-frequency = <7372800>; | ||
| }; | ||
|
|
||
| bclk_uart0_off: bclk_uart0_off { | ||
| compatible = "clock-state"; | ||
| clocks = <&clk_mgmt_uart_pclk 0>; | ||
| clock-frequency = <0>; | ||
| }; |
There was a problem hiding this comment.
This is huge for a single node. Fortunately there is only one UART on this SoC.
Question: Is that complete ? Or are there other clocks configuration (rates for instance) possible that are not described here ?
There was a problem hiding this comment.
It's possible to have more nodes. On the MAX32657, sys_clk feeds clk_mgmt_pclk which in turn feeds the UART. So the number of states here really depends on the number of states defined for sys_clk, which in turn is the matrix of the mux_sysclk_sel multiplexer and the scale_sysclk_div prescaler.
I've only gone as far as writing out a list of commonly used sys_clk states, but more are definitely possible because of the prescaler. In a more complete implementation, I would not define so many nodes. I would rather define one or two "base" sets at the SoC level here that are guaranteed to work, then let users define their own in an overlay if they would like to customize the tree. I put more than what is necessary here, and in this top level file, only to demonstrate the structure. I should have clarified this in the description.
I don't think we want to write out all possible combinations of clocks which is why the states are meant to be defined at the application level.
There was a problem hiding this comment.
Ok, so this is really a user configuration in the end. Thanks for the confirmation
ehay64
changed the title
2 participants
This moves the MAX32657 chip away from clock control to clock management. The major additions are: