stm32: clock_control: Driver overhaul #44312
Merged
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
erwango
requested review from
ABOSTM,
FRASTM,
MaureenHelm,
carlescufi,
galak and
nashif
as code owners
github-actions
bot
added
area: Devicetree
area: Devicetree Binding
erwango
force-pushed
the
dev_full_stm32_clocks_revision
branch
2 times, most recently
from
04bc953 to
3fd19e6
Compare
erwango
force-pushed
the
dev_full_stm32_clocks_revision
branch
from
3fd19e6 to
3b697af
Compare
FRASTM
reviewed
Mar 31, 2022
erwango
force-pushed
the
dev_full_stm32_clocks_revision
branch
from
0150f69 to
52de802
Compare
FRASTM
reviewed
Mar 31, 2022
erwango
force-pushed
the
dev_full_stm32_clocks_revision
branch
from
52de802 to
f567844
Compare
FRASTM
reviewed
Apr 4, 2022
Contributor
FRASTM
left a comment
FRASTM
left a comment
There was a problem hiding this comment.
Is the stm32f1 really different from the stm32f0 or stm32f3 : except the prediv which is fixed to 2 in case of pll source HSE, could both config_pll_sysclock functions clock config be factorized ?
Member
Author
There's actually one part of the F1 (!SOC_STM32F10X_DENSITY_DEVICE) which is compatible with one part of the F0/F3 (!RCC_PLLSRC_PREDIV1_SUPPORT). So putting them together will allow to factorize those, but we'll need to make 3 different configuration live in one single file. I don't see it as much more simple in the end. |
erwango
force-pushed
the
dev_full_stm32_clocks_revision
branch
from
f567844 to
601744e
Compare
FRASTM
reviewed
Apr 5, 2022
ABOSTM
suggested changes
Apr 5, 2022
FRASTM
reviewed
Apr 5, 2022
erwango
force-pushed
the
dev_full_stm32_clocks_revision
branch
from
601744e to
2b2c5be
Compare
Group fixed clocks inits in a unique set_up function. Each clock is initialized depending on its dts status. Signed-off-by: Erwan Gouriou <[email protected]>
…clocks On STM32WB HSE clock is defined with "fixed-clock" compatible. Signed-off-by: Erwan Gouriou <[email protected]>
… step Introduce a set_up_pll configuration function and make PLL configuration an elementary step of the whole system clock configuration. To implement this new, function make use of the existing series specific files which allows series specific configuration when required. Signed-off-by: Erwan Gouriou <[email protected]>
STM32_PLL_ENABLED symbol is missing on F0/F1 and L0/L1 compatibles. Fix that. Signed-off-by: Erwan Gouriou <[email protected]>
On some parts, it could be required to use steps before applying highest frequencies. This was previously done as part of LL_PLL_ConfigSystemClock_FOO utility functions which are no more used. Use device tree to mention when this is required and implement it in stm32_clock_control_init(). Additionally, fix the calls tp LL_RCC_SetAHBPrescaler, which require use of ahb_prescaler helper. Signed-off-by: Erwan Gouriou <[email protected]>
…es() Review code style in set_up_fixed_clock_sources() for better readability. Use of 'if (IS_ENABLED(STM32_MSI_ENABLED))' inside '#if STM32_MSI_ENABLED' is redundant but intentional as it is in line with remaining part of the function (HSE/HSI cases). Signed-off-by: Erwan Gouriou <[email protected]>
Add new scheme clock bindings for 'common' series: - stm32f1_clock.h > compatible with f0/f1/f3 series - stm32f4_clock.h > compatible with f2/f4/f7 series - stm32l0_clock.h > compatible with l0 series - stm32l1_clock.h > compatible with l1 series - stm32l4_clock.h > compatible with g4/l4/l5/wb series - stm32wl_clock.h > compatible with wl series Signed-off-by: Erwan Gouriou <[email protected]>
Make use of new bus clocks bindings and make subsequent code simplifications. Signed-off-by: Erwan Gouriou <[email protected]>
According to board documentation: "By default System
clock is driven by the MSI clock at 48MHz."
This is in line with rcc node dts configuration:
&rcc {
[...]
clocks = <&clk_msi>;
[...]
};
Though pll node is currently enabled, which is not in line with
current dts clocks description scheme and results to compilation
issue in clock_control driver.
Remove pll node configuration to fix this.
Signed-off-by: Erwan Gouriou <[email protected]>
"prediv" property should be required and explicitly set as part of board clock configuration. Signed-off-by: Erwan Gouriou <[email protected]>
Some specific F1 variants don't handle flash latency. Put flash latency dealing code under dedicated switch. Signed-off-by: Erwan Gouriou <[email protected]>
On STM32F series, HSI clock is 8MHz, fix test using 16MHz and a test name. Signed-off-by: Erwan Gouriou <[email protected]>
Remove L0 and L1 targets from "sysclksrc_msi_48" test case as this MSI range 11 is not an allowed value on these series. Signed-off-by: Erwan Gouriou <[email protected]>
Use enum to describe the range of allowed MSI values. This will help to detect configuration issues earlier. Signed-off-by: Erwan Gouriou <[email protected]>
Rework bindings documentation to clearly illustrate the role of ahb (and cpu1) prescaler which defines the actual core clock frequency, and not only a bus frequency. Signed-off-by: Erwan Gouriou <[email protected]>
CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC is the actual hclk freq (ie core clock); Remove use of intermediate new_hclk_freq to fix and simplify code. Signed-off-by: Erwan Gouriou <[email protected]>
Instead of testing SysClockFreq setting, we should instead check HCLK setting which is the real zephyr CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC counterpart (core clock freq) and takes AHB prescaler setting into account. Additionally, update one test configuration to explicitly verify AHB prescaler is correctly taken into account by clock driver. Signed-off-by: Erwan Gouriou <[email protected]>
Instead of computing hclk freq use for flash latency setting after setting the PLLs, do it right at the beginning of the function. Indeed, first step of PLL configuration is to switch back sysclock to HSI source (in case it was initially PLL). In that case, flash latency is theoretically set in consistency with PLL driver hclk. So we should "measure" hclk freq at that step rather than once sysclock is back on HSI. Signed-off-by: Erwan Gouriou <[email protected]>
Rework test_*_freq to test HCLK freq instead of SYSCLK one, as it is not correct to compare CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC with SYSCLK. Additionally, add a test to verify use of AHB prescaler. Signed-off-by: Erwan Gouriou <[email protected]>
STM32H7 series offer alias addresses to access some registers that could be accessed by the M4 core on dual core variants. For instance RCC_AHB3ENR could be accessed at following offsets: - 0x0D4: Accessible from both cores - 0x134: Accessible from C1 (M7) core - 0x194: Accessible from C2 (M4) core (if any) For most single core H7 variants, the two first addresses were accessible, but for some others (stm32h7ax/stm32h7bx), only the 'C1 accessible' was available. This fact used to be hidden by the use of LL API to access these registers, providing the required abstraction (an mainly using the first alias when possible to simplify implementation). Signed-off-by: Erwan Gouriou <[email protected]>
erwango
force-pushed
the
dev_full_stm32_clocks_revision
branch
from
d7ebe75 to
3de094a
Compare
FRASTM
approved these changes
Apr 21, 2022
ABOSTM
approved these changes
Apr 21, 2022
Member
|
@nordic-krch could you please take a look? |
nordic-krch
approved these changes
Apr 21, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
8 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.
In order to driver future evolutions (mainly support for alternate clocks, cf #42097), revise stm32 clock_control driver implementation.
This change is adapted from what was done initially on H7 driver (cf #41585) and extended to other series (common and U5 clock_control drivers). Only MP1 is left aside for now
Mainly, two changes are done:
Based on #44291, which allow to verify no regression is introduced.