STM32 ADC: support prescaler from RCC #97725

gautierg-st · 2025-10-16T14:20:56Z

The goal of this PR is to add the support of the ADC prescaler located in RCC for some series (F1, F3, N6, U3).
Though already supported in F1 and F3, it was through a specific property of the RCC. To avoid increasing the complexity on this end, the prescaler is configured the same way as for a kernel clock, in the ADC clocks property in device tree.
This allows to remove the RCC specificities of F1 and F3.

This led to changes in the STM32 clock defines due to the fact that the N6 prescaler register field is 8-bit long, so the macros needed to be reworked to make it fit.

Lastly, since we can now have up to three different clocks in the clocks properties, instead of relying on ordering, the clock-names property is mandatory for all ADC instances. Names have been added in existing dtsi, dts and overlay files, but it shall be redefined if a clock source or a prescaler is added.

Reworks the way the STM32_DT_CLOCK_SELECT builds its elements. Instead of defining a mask, we define a width which is the number of bits of the register field. This allows to gain space for higher values for the fields. This larger space is necessary to add the selection of the ADC prescaler on STM32N6 because it is an 8-bit long field. The allowed width is from 1 to 8 (and internally stored as 0-7 to fit on 3 bits). STM32_DT_CLKSEL_MASK_GET keeps the same name, since we still need the mask, and returns the bitmask from the width with the BIT_MASK macro. Other STM32_DT_CLKSEL_MASK_* macros are renamed with WIDTH. All call to STM32_DT_CLOCK_SELECT are updated to reflect the change and use a width instead of a mask. Signed-off-by: Guillaume Gautier <[email protected]>

…and u3 This commit adds the RCC configurations for ADC prescaler for STM32F1, F3, N6 and U3. Signed-off-by: Guillaume Gautier <[email protected]>

To easily differentiate between the different clocks that can be configured in device tree, make their naming mandatory, and explicit what the expected names are. Add these names in all dtsi and dts files that need them. Signed-off-by: Guillaume Gautier <[email protected]>

Some series like F1, F3, N6 and U3 use an ADC prescaler defined in the RCC. Instead of adding specific properties in the RCC driver, use the secondary clock system to configure the prescaler. The ADC driver now configures the clocks depending on their presence and their name. Three clocks can be defined: - the register clock (mandatory for all series) - the kernel clock (depends on series) - the prescaler value (depends on series) Signed-off-by: Guillaume Gautier <[email protected]>

Now that the ADC prescaler are set within the driver using the clock system, the specific rcc compatibles for F1 and F3 are no longer useful. Replace them with the standard one (from which they were derived). Signed-off-by: Guillaume Gautier <[email protected]>

Now that the ADC prescaler are set within the driver using the clock system, remove the specific setting of the prescaler from the clock driver. Signed-off-by: Guillaume Gautier <[email protected]>

Update STM32 ADC binding description now that the STM32F3 ADC asynchronous prescaler is set through the clock property. Signed-off-by: Guillaume Gautier <[email protected]>

Update the 4.3 migration guide to include the change made on the STM32 ADC clocks. Signed-off-by: Guillaume Gautier <[email protected]>

sonarqubecloud · 2025-10-17T07:40:36Z

Quality Gate passed

Issues
6 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
5.4% Duplication on New Code

See analysis details on SonarQube Cloud

mathieuchopstm

Maybe the STM32_DT_CLOCK_SELECT update should be done in a separate PR. Not too blocking for me though.

mathieuchopstm · 2025-10-17T11:35:51Z

drivers/adc/adc_stm32.c

+	}
+
+	if (config->has_pclken_pre) {
+		/* Set ADC RCC prescaler */


nit:

Suggested change

/* Set ADC RCC prescaler */

/* Configure ADC prescaler (at RCC level) */

mathieuchopstm · 2025-10-17T11:37:01Z

drivers/adc/adc_stm32.c

+	.pclken = {.bus = DT_INST_CLOCKS_CELL_BY_NAME(index, adcx, bus),			\
+		   .enr = DT_INST_CLOCKS_CELL_BY_NAME(index, adcx, bits)},			\


Nit: I would make a STM32-level macro for this. Basically all drivers are "wrong" today (div field left uninitialized) because they don't use the shared macro.

This is a change for another PR. As you say, all drivers are impacted, so I'm not going to introduce such a change in this one. There are enough as it is.

mathieuchopstm · 2025-10-17T11:38:00Z

drivers/adc/adc_stm32.c

+	(.pclken_ker = {.bus = DT_INST_CLOCKS_CELL_BY_NAME(index, adc_ker, bus),		\
+			.enr = DT_INST_CLOCKS_CELL_BY_NAME(index, adc_ker, bits)},		\
+	 .has_pclken_ker = true,),								\
+	(.has_pclken_ker = false,))								\


Nit: could be IF_ENABLED() and leave has_pclken_ker not initialized => default to false.

But I don't mind the extra verbosity.

mathieuchopstm · 2025-10-17T11:43:56Z

include/zephyr/drivers/clock_control/stm32_clock_control.h

Nits on commit include: zephyr: dt-bindings: clock: stm32: use width instead of bitmask:

commit title is not very intuitive. prefer the simpler rework STM32_DT_CLOCK_SELECT details?

Since we're breaking STM32_DT_CLOCK_SELECT, I would suggest the new prototype to be instead STM32_DT_CLOCK_SELECT(val, high_bit, low_bit, reg)

[1] low_bit is merely a rename; high_bit would be the bitfield's MSB index - width would be computed internally as (high_bit - low_bit + 1). When copying RefMan, this would avoid the hurdle of computing bitfield width.

Ok with changing the commit title, but disagree with your prototype proposition. The rework was needed to gain space, make the macro more compact so that N6 prescaler could fit into it. Width is only 3-bit long, using another bit_pos would be 5-bit long. Reg would have to be reduced (not currently blocking since no reg are that long, but still, it could be needed one day).

Besides, I don't think it's a hurdle to "calculate" the width of the bitfield from RefMan (most are under 4-bit long, that's pretty easy to read).

Ok with changing the commit title, but disagree with your prototype proposition. The rework was needed to gain space, make the macro more compact so that N6 prescaler could fit into it. Width is only 3-bit long, using another bit_pos would be 5-bit long. Reg would have to be reduced (not currently blocking since no reg are that long, but still, it could be needed one day).

I am not suggesting to change the storage format but merely how the macro accepts parameters. When I said:

width would be computed internally as (high_bit - low_bit + 1)

I meant that it would be computed internally as part of the macro (storage format is unchanged and contains width)

Oh, ok, my bad, I misunderstood your proposition.
I don't have strong opinions on either choice, but I'll wait for other opinions before making any potential changes. @etienne-lms, @erwango ?

What would be the benefit of high_bit, low_bit ? Readability ?

I think having the lowest and highest bit position as macro argument make sense, but I'm quite used the GENMASK() like macros. No strong opinion here.

What would be the benefit of high_bit, low_bit ? Readability ?

Basically yes. Gives the information directly from reading RefMan:

==> ((val), 31, 30, CCIPR) instead of having to derive size (as @gautierg-st said, it is often 1/2 bits so not too much of a hurdle, but still more error-prone than copy-paste from RM, and we're starting to see more and more "large" fields)

I think having the lowest and highest bit position as macro argument make sense, but I'm quite used the GENMASK() like macros. No strong opinion here.

GENMASK() takes a high/low argument as well so I don't understand your point 🤔

zephyr/include/zephyr/sys/util.h

Lines 76 to 80 in 169fd6a

/**

* @brief Create a contiguous bitmask starting at bit position @p l

* and ending at position @p h.

*/

#define GENMASK(h, l) (((~0UL) - (1UL << (l)) + 1) & (~0UL >> (BITS_PER_LONG - 1 - (h))))

GENMASK() takes a high/low argument as well so I don't understand your point 🤔

I meant I'm fine with such API but there maybe other point of view hence no strong opinion of mine on which of high-bit/low-bit or bit-offset/bit-size couple is to be preferred as argument.

mathieuchopstm · 2025-10-17T11:52:39Z

include/zephyr/dt-bindings/clock/stm32f3_clock.h

+/* ADCxx prescaler for all F3 but F37x: division factor */
+#define ADCxx_PRE_DISABLED	0x0
+#define ADCxx_PRE_DIV_1		0x10
+#define ADCxx_PRE_DIV_2		0x11
+#define ADCxx_PRE_DIV_4		0x12
+#define ADCxx_PRE_DIV_6		0x13
+#define ADCxx_PRE_DIV_8		0x14
+#define ADCxx_PRE_DIV_10	0x15
+#define ADCxx_PRE_DIV_12	0x16
+#define ADCxx_PRE_DIV_16	0x17
+#define ADCxx_PRE_DIV_32	0x18
+#define ADCxx_PRE_DIV_64	0x19
+#define ADCxx_PRE_DIV_128	0x1A
+#define ADCxx_PRE_DIV_256	0x1B
+
+/* ADC prescaler for F37x: division factor */
+#define ADC_PRE_DIV_2		0
+#define ADC_PRE_DIV_4		1
+#define ADC_PRE_DIV_6		2
+#define ADC_PRE_DIV_8		3


Maybe a separate stm32f37x_clock.h (as done for other series) should be introduced. This would allow for more consistency across series.

The definitions in this file can be gated behind a symbol that only it defines such that it overrides them cleanly, i.e.:

+#ifndef ZEPHYR_INCLUDE_DT_BINDINGS_CLOCK_STM32F37X_CLOCK_H_ + /* STM32F37x has specific ADC prescaler definitions */ ...

mathieuchopstm · 2025-10-17T11:56:37Z

dts/bindings/adc/st,stm32-adc.yaml

+      Expected names are the following:
+      - "adcx" for the enabling the register clock (mandatory)
+      - "adc_ker" for configuring the kernel clock (if applicable)
+      - "adc_pre" for configuring the prescaler (if applicable)


It should be mentioned somewhere that one prescaler may be shared by several ADCs.

It's also the case for the kernel clock (at least sometimes, and it can even be shared with DAC), so it should be mentioned too.

mathieuchopstm · 2025-10-17T11:58:42Z

include/zephyr/dt-bindings/clock/stm32f1_clock.h

+#define MCO1_SEL(val)           STM32_DT_CLOCK_SELECT((val), 3, 24, CFGR1_REG)
 /* No MCO prescaler support on STM32F1 series. */

+/* ADC prescaler : division factor */


Suggested change

/* ADC prescaler : division factor */

/* ADC prescaler: division factor */

But IDK if columns are very useful here?

Suggested change

/* ADC prescaler : division factor */

/* ADC prescaler division factor */

ditto all

mathieuchopstm · 2025-10-17T12:04:03Z

dts/bindings/adc/st,stm32-adc.yaml

      On STM32F3x (except STM32F37x), this configures only the synchronous
-      prescaler (see properties adcXX-prescaler in st,stm32f3-rcc bindings to
-      set asynchronous prescaler).
+      prescaler (use the clock property to set asynchronous prescaler).


The STM32F37x also have a clock property for ADC_PRE, so isn't this incorrect? Or are both prescalers applied in that instance? The comment could use some additional clarification.

STM32F37x has the same ADC as STM32F1 and uses the "stm32f1-adc" compatible which removes this property and the "st,adc-clock-source" property since they are not applicable for them.
So maybe "(except STM32F37x)" is not even worth mentioning since it doesn't use this compatible anyway.

That is what I would have suggested. (removing (except STM32F37x))

zephyrbot added area: Boards/SoCs area: ADC Analog-to-Digital Converter (ADC) area: Clock Control Release Notes To be mentioned in the release notes area: Devicetree Bindings area: Tests Issues related to a particular existing or missing test platform: STM32 ST Micro STM32 labels Oct 16, 2025

zephyrbot requested review from FRASTM, GeorgeCGV, anangl, cfriedt, djiatsaf-st, erwango, etienne-lms, jhedberg, kartben, marwaiehm-st, mathieuchopstm, nashif and nordic-krch October 16, 2025 14:22

zephyrbot assigned nordic-krch Oct 16, 2025

gautierg-st added 8 commits October 17, 2025 09:32

include: dt-bindings: clock: stm32: add adc prescaler for f1, f3, n6 …

5cfa8b1

…and u3 This commit adds the RCC configurations for ADC prescaler for STM32F1, F3, N6 and U3. Signed-off-by: Guillaume Gautier <[email protected]>

drivers: clock: stm32: remove adc prescaler setting

9c5d8ea

Now that the ADC prescaler are set within the driver using the clock system, remove the specific setting of the prescaler from the clock driver. Signed-off-by: Guillaume Gautier <[email protected]>

dts: bindings: adc: update binding description

d94066c

Update STM32 ADC binding description now that the STM32F3 ADC asynchronous prescaler is set through the clock property. Signed-off-by: Guillaume Gautier <[email protected]>

doc: releases: update migration guide for stm32 adc

261b108

Update the 4.3 migration guide to include the change made on the STM32 ADC clocks. Signed-off-by: Guillaume Gautier <[email protected]>

gautierg-st force-pushed the adc_clock_names branch from 0a4bf0d to 261b108 Compare October 17, 2025 07:35

mathieuchopstm reviewed Oct 17, 2025

View reviewed changes

	/* Set ADC RCC prescaler */
	/* Configure ADC prescaler (at RCC level) */

		.pclken = {.bus = DT_INST_CLOCKS_CELL_BY_NAME(index, adcx, bus), \
		.enr = DT_INST_CLOCKS_CELL_BY_NAME(index, adcx, bits)}, \

	/**
	* @brief Create a contiguous bitmask starting at bit position @p l
	* and ending at position @p h.
	*/
	#define GENMASK(h, l) (((~0UL) - (1UL << (l)) + 1) & (~0UL >> (BITS_PER_LONG - 1 - (h))))

	/* ADC prescaler : division factor */
	/* ADC prescaler: division factor */

	/* ADC prescaler : division factor */
	/* ADC prescaler division factor */

STM32 ADC: support prescaler from RCC #97725

Are you sure you want to change the base?

STM32 ADC: support prescaler from RCC #97725

Conversation

gautierg-st commented Oct 16, 2025

Uh oh!

sonarqubecloud bot commented Oct 17, 2025

Quality Gate passed

Uh oh!

mathieuchopstm left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mathieuchopstm Oct 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

mathieuchopstm Oct 17, 2025 •

edited

Loading