[RFC] Add support for setpoints and callbacks to Clock Control API #66732
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Contributor
|
Perhaps adding some definitions would be good: clock state, setpoint (the example in the DT gives an idea but questions remain). |
danieldegrasse
changed the title
Add clock_control_setpoint API to clock framework. This API is used to select a clock "setpoint", which is defined as a complete configuration for an SOC clock tree. Clock setpoints are accessed via identifier values. Values are defined for run and idle mode, and additional values can be defined by the SOC implementation, provided they are greater than "CLOCK_SETPOINT_PRIV_START" Signed-off-by: Daniel DeGrasse <[email protected]>
Add clock control callback APIs. These APIs are designed to support clock notifications when a clock starts/stops, or changes rate. Clock consumers can register for clock change notifications on clock devices, so they can take specific action if needed. Signed-off-by: Daniel DeGrasse <[email protected]>
Add implementation of clock_control_setpoint for the LPC syscon clock driver. This implementation requires that the SOC provide definitions for the clock setpoints, which will expand to a function for each setpoint. The clock controller then simply calls the setpoint function to apply the selected setpoint. Signed-off-by: Daniel DeGrasse <[email protected]>
Implement support for clock callbacks in mcux_syscon clock control driver. A callback will be issued whenever a new clock setpoint is selected. Signed-off-by: Daniel DeGrasse <[email protected]>
Add support for clock control callback to mcux flexcomm driver. The driver will check its clock frequency, and if the new clock is different than the old one it will reinitialize the clock to use the new value Signed-off-by: Daniel DeGrasse <[email protected]>
Attempt to Apply clock run setpoint at boot. This will enable clock setpoints to be used for clock configuration by the user. Signed-off-by: Daniel DeGrasse <[email protected]>
Add MCUX_SYSTEM_CLK ID to lpc syscon clock driver, so that users can query the core system clock frequency. Signed-off-by: Daniel DeGrasse <[email protected]>
Add test to verify that clock setpoints function correctly. This test will select a new clock setpoint, and verify that the specified clock (set via the zephyr,user node) has changed frequency Signed-off-by: Daniel DeGrasse <[email protected]>
Add tests for NXP clock configuration. NXP clock setup is done using setpoints at boot, so these tests simply validate that the clock frequency is what we expect for a given devicetree configuration. The "external" test validates the highest frequency core clock possible with external components, and the "internal" test validates the highest frequency possible with internal oscillators only. Signed-off-by: Daniel DeGrasse <[email protected]>
danieldegrasse
changed the title
|
This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time. |
Contributor
Author
|
Closing this, as I think pursuing one of the clock management RFCs I have open currently makes more sense |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Introduction
This PR proposes two additions to the clock control API, intended to better support modifying clocks at runtime. The PR introduces the concept of "setpoints" to the clock control API. A clock setpoint is defined as a independent clock tree state.
This PR proposes an addition to the clock control API, for "setpoints". A clock setpoint is defined as a independent clock tree state. For example, on clock setpoint might enable the SOC's PLL, and clock peripherals from this PLL. Another setpoint might disable all PLLs, and only clock peripherals from a low power clock source.
Beyond setpoints, this PR adds a simple clock callback interface, loosely based on the GPIO callback API. Drivers can register for a callback when a new setpoint is selected, so that they can reconfigure their peripheral if needed.
Problem Description
Currently, Zephyr has somewhat scattered support for clock configuration, via the clock_control_set_rate and clock_control_configure APIs. These APIs can be used to implement clock control within drivers, but due to the fact that much of the clock control API is based on opaque types the clock consumer ends up tightly coupled to the underlying clock driver.
Setpoints are intended to provide a way to manage clock dependencies between peripherals- rather than managing clock dependencies in software, each setpoint encodes all required clock settings directly. This has the following advantages:
Detailed RFC
This PR proposes the following new functions for the clock control API:
clock_control_setpoint- select a new setpoint for the clock driver. Standard setpoints are the following:CLOCK_SETPOINT_RUN: run mode, typically used for full power operationCLOCK_SETPOINT_IDLE: idle mode, typically used for low power run (IE from an internal oscillator)CLOCK_SETPOINT_PRIV_START(similar to pin control)clock_control_init_callback- very similar togpio_init_callback, sets up a clock control callback structureclock_control_add_callback- adds a callback. Whenever a new setpoint is selected, this callback will be called. The callback itself is responsible for determining if the clock frequencies it is interested in have changed.clock_control_remove_callback- removes a previously added callback