Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

drivers: adc: stm32: Implement boost settings for STM32H7. #78047

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

bas-archembedded
Copy link
Contributor

After boost is implemented and enabled it allows for higher sampling frequencies.

@erwango
Copy link
Member

erwango commented Sep 5, 2024

Please review commit title: drivers: adc: stm32: ...

@bas-archembedded bas-archembedded force-pushed the dev/stm32_boost branch 2 times, most recently from adbec4a to df9a785 Compare September 5, 2024 10:22
@bas-archembedded bas-archembedded changed the title STM32: Implement boost settings for STM32H7. drivers: adc: stm32: Implement boost settings for STM32H7. Sep 5, 2024
decsny
decsny previously requested changes Sep 5, 2024
Copy link
Member

@decsny decsny left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do formatting changes in a separate commit

Copy link
Member

@erwango erwango left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Naive question in order to help simplifying the driver a bit (if ever possible)

drivers/adc/adc_stm32.c Outdated Show resolved Hide resolved
drivers/adc/adc_stm32.c Outdated Show resolved Hide resolved
drivers/adc/adc_stm32.c Outdated Show resolved Hide resolved
@bas-archembedded bas-archembedded force-pushed the dev/stm32_boost branch 2 times, most recently from adf7191 to 9ae95a1 Compare September 6, 2024 10:45
@decsny decsny dismissed their stale review September 6, 2024 21:01

dismiss, vendor please review first

Copy link
Contributor

@gautierg-st gautierg-st left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your PR, I wasn't aware of the boost mode for H7.
A few changes requested but otherwise looks good.

Comment on lines +1372 to +1381
/* For revision Y we have no prescaler of 2 */
if (LL_DBGMCU_GetRevisionID() <= 0x1003) {
presc = 1;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
/* For revision Y we have no prescaler of 2 */
if (LL_DBGMCU_GetRevisionID() <= 0x1003) {
presc = 1;
}
#ifdef ADC_VER_V5_X
/* For revision Y we have no prescaler of 2 */
if (LL_DBGMCU_GetRevisionID() <= 0x1003) {
presc = 1;
}
#endif

This specificity is only present on STM32H742, H743, H750 and H753. So add an #ifdef to avoid conflict with other subseries (like H72x or H73x whose revisions are 0x1000 or 0x1001)

Comment on lines 1753 to 1754
.dma_cfg = \
{ \
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: It looks strange to have the brace on a new line when just a few lines above, the brace after .dma is on the same line.
I think it would be best to keep the previous formatting (whatever clang-format may say)

Comment on lines 1351 to 1360
#if defined(CONFIG_SOC_SERIES_STM32C0X) || defined(CONFIG_SOC_SERIES_STM32G0X) || \
defined(CONFIG_SOC_SERIES_STM32L0X) || \
(defined(CONFIG_SOC_SERIES_STM32WBX) && defined(ADC_SUPPORT_2_5_MSPS)) || \
defined(CONFIG_SOC_SERIES_STM32WLX) || defined(CONFIG_SOC_SERIES_STM32H7X)
static bool adc_stm32_is_clk_sync(const struct adc_stm32_cfg *config)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't really like to have the same #if defined duplicated in two places.
I would prefer to have something like

#if defined(CONFIG_SOC_SERIES_STM32C0X) || \
	defined(CONFIG_SOC_SERIES_STM32G0X) || \
	defined(CONFIG_SOC_SERIES_STM32L0X) || \
	(defined(CONFIG_SOC_SERIES_STM32WBX) && defined(ADC_SUPPORT_2_5_MSPS)) || \
	defined(CONFIG_SOC_SERIES_STM32WLX)
	define HAS_INDIVIDUAL_CLOCK_MODE
#endif

And then use this define in the two places.
I'm not too sure about the define name though, don't hesitate to propose something else if you have ideas.
Note that keeping one SOC_SERIES per line is preferred for readability and adding potential future series.

@decsny decsny removed their request for review September 11, 2024 16:11

/* Get the input frequency */
clk_src = (clock_control_subsys_t)(adc_stm32_is_clk_sync(config) ? &config->pclken[0]
: &config->pclken[1]);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another thing I just noticed, config->pclken[1] does not necessarily exist. It is currently possible to be in ASYNC but not defining a secondary clock source. In that case, PLL2_P will be used (default one). But I agree it is not a good practice.

Maybe you could add a check (not limited to H7) to generate a compile-time error if ASYNC is defined without an explicit secondary clock.

But you still have to update this line for cases in SYNC that may not have the secondary clock.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gautierg-st I did not understand the last line.. Why does it matter if pclken[1] is not set when running in SYNC mode ? AFAICS we only need to check pclken[1] when ASYNC mode is used ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well if you add global check, then yeah, your current code should be ok.

But thinking about it, I believe a simple check like the following could suffice:

clk_src = &config->pclken[0];
if (IS_ENABLED(STM32_ADC_DOMAIN_CLOCK_SUPPORT) && (config->pclk_len > 1) && !adc_stm32_is_clk_sync(config)) {
	clk_src = &config->pclken[1];
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well if you add global check, then yeah, your current code should be ok.

But thinking about it, I believe a simple check like the following could suffice:

clk_src = &config->pclken[0];
if (IS_ENABLED(STM32_ADC_DOMAIN_CLOCK_SUPPORT) && (config->pclk_len > 1) && !adc_stm32_is_clk_sync(config)) {
	clk_src = &config->pclken[1];
}

I have chosen for a compile error check as that code is running on H7 only anyway. Please check the current version ;)

@bas-archembedded bas-archembedded force-pushed the dev/stm32_boost branch 4 times, most recently from fa9259f to aed6d67 Compare September 12, 2024 14:43
#define ADC_STM32_CHECK_DT_CLOCK(x) \
BUILD_ASSERT( \
IS_EQ(ADC_STM32_CLOCK(x), SYNC) || \
(IS_ENABLED(STM32_ADC_DOMAIN_CLOCK_SUPPORT) && DT_INST_NUM_CLOCKS(x) > 1), \
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this could be simplified with BUILD_ASSERT(IS_EQ(ADC_STM32_CLOCK(x), SYNC) || (DT_INST_NUM_CLOCKS(x) > 1)),
I don't think IS_ENABLED(STM32_ADC_DOMAIN_CLOCK_SUPPORT) brings more information than (DT_INST_NUM_CLOCKS(x) > 1)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gautierg-st Isn't that define true if any of the instances has a second clock defined ? DT_INST_NUM_CLOCKS(x) is the same as config->pclk_len for a specific instance.

Copy link
Contributor

@gautierg-st gautierg-st Sep 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Exactly, and we care only about our specific instance, either we're in SYNC and we're good, or we have a domain clock and we're also good. It isn't important to check whether other instances have a domain clock here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gautierg-st Updated.

\
static const struct adc_stm32_cfg adc_stm32_cfg_##index = { \
.base = (ADC_TypeDef *)DT_INST_REG_ADDR(index), \
ADC_STM32_IRQ_FUNC(index).pclken = pclken_##index, \
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

		ADC_STM32_IRQ_FUNC(index)                          \
		.pclken = pclken_##index,                                 \

Besides, I just noticed that clang-format has replaced all tabs before the \ by spaces. Not sure of Zephyr guideline about that. @erwango?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it is blocking but tbh I'd drop the whole second commit as it doesn't add any value.
Those clang warnings are not blocking (and sometime even not good advices at all)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gautierg-st It was done by clang-format, using the in tree .clang-format so I hope that reflects the standard :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it is blocking but tbh I'd drop the whole second commit as it doesn't add any value. Those clang warnings are not blocking (and sometime even not good advices at all)

I've removed it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gautierg-st @erwango I assume this needs to be rebased now that the check is included in the new PR?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes this will need to be rebased after #78523 is merged. Hopefully soon!

@bas-archembedded bas-archembedded force-pushed the dev/stm32_boost branch 2 times, most recently from f40e3ff to 40759e2 Compare September 13, 2024 07:23
After boost is implemented and enabled it allows for higher
sampling frequencies.

Signed-off-by: Bas van Loon <[email protected]>
Copy link
Contributor

@gautierg-st gautierg-st left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me! Thank you for your patience :)

@gautierg-st
Copy link
Contributor

Unsurprisingly, the check breaks things for several boards. I understand that it is out of scope of your initial PR, so I can take this point if you prefer. I can add the check and fix the issues in another PR. Let me know

@bas-archembedded
Copy link
Contributor Author

Unsurprisingly, the check breaks things for several boards. I understand that it is out of scope of your initial PR, so I can take this point if you prefer. I can add the check and fix the issues in another PR. Let me know

Sure, go ahead. I have limited boards to check it with so if you can bring the broken boards along it would be great.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: ADC Analog-to-Digital Converter (ADC) platform: STM32 ST Micro STM32
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants