Skip to content

drivers: dma: stm32: avoid clear TE in case of hal_override #97741

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.

Sign up for GitHub

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

Merged
merged 2 commits into from
Oct 20, 2025
+13 −8
Merged

drivers: dma: stm32: avoid clear TE in case of hal_override #97741

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
47a8344
drivers: dma: stm32: avoid clear TE in case of hal_override
Oct 16, 2025
445302d
drivers: dma: stm32: avoid clear flags if hal_override on unexpected irq
Oct 18, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 13 additions & 5 deletions drivers/dma/dma_stm32.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -129,14 +129,22 @@ static void dma_stm32_irq_handler(const struct device *dev, uint32_t id)
}
stream->dma_callback(dev, stream->user_data, callback_arg, DMA_STATUS_COMPLETE);
} else if (stm32_dma_is_unexpected_irq_happened(dma, id)) {
LOG_ERR("Unexpected irq happened.");
/* Let HAL DMA handle flags on its own */
if (!stream->hal_override) {
LOG_ERR("Unexpected irq happened.");
stm32_dma_dump_stream_irq(dma, id);
stm32_dma_clear_stream_irq(dma, id);
}
stream->dma_callback(dev, stream->user_data,
callback_arg, -EIO);
} else {
LOG_ERR("Transfer Error.");
stream->busy = false;
dma_stm32_dump_stream_irq(dev, id);
dma_stm32_clear_stream_irq(dev, id);
/* Let HAL DMA handle flags on its own */
if (!stream->hal_override) {
LOG_ERR("Transfer Error.");
stream->busy = false;
dma_stm32_dump_stream_irq(dev, id);
dma_stm32_clear_stream_irq(dev, id);
}
Comment on lines +141 to +147
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe we should log nonetheless?

Suggested change
/* Let HAL DMA handle flags on its own */
if (!stream->hal_override) {
LOG_ERR("Transfer Error.");
stream->busy = false;
dma_stm32_dump_stream_irq(dev, id);
dma_stm32_clear_stream_irq(dev, id);
}
LOG_ERR("Transfer Error.");
if (!stream->hal_override) {
/* Let HAL DMA handle flags on its own */
stream->busy = false;
dma_stm32_dump_stream_irq(dev, id);
dma_stm32_clear_stream_irq(dev, id);
}

Copy link
Author

Choose a reason for hiding this comment

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

Hum, considering that in case of HAL_OVERRIDE is being use, the Zephyr DMA framework is mainly use for resource handling rather than DMA functionaly speaking, I do not think that in such condition we should LOG anything here. If that's the HAL which is handling the DMA control, error checking etc, let's let it fully handle (aka configure, error handling etc).

Don't misunderstand me, I am not saying that we should bypass all and forever the Zephyr DMA framework ;) however in current implementation I do not see much merit to have the Zephyr DMA log this message. At least in case of DCMI, we have the callback in place to also get notification of transfer error. I suppose that's also the same thing for other drivers relying on HAL_OVERRIDE.

Copy link
Contributor

Choose a reason for hiding this comment

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

Fine by me 🙂

stream->dma_callback(dev, stream->user_data,
callback_arg, -EIO);
}
Expand Down
3 changes: 0 additions & 3 deletions drivers/dma/dma_stm32_v1.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -306,9 +306,6 @@ bool stm32_dma_is_unexpected_irq_happened(DMA_TypeDef *dma, uint32_t id)
if (LL_DMA_IsEnabledIT_FE(dma, dma_stm32_id_to_stream(id)) &&
dma_stm32_is_fe_active(dma, id)) {
LOG_ERR("FiFo error.");
stm32_dma_dump_stream_irq(dma, id);
stm32_dma_clear_stream_irq(dma, id);

return true;
Comment on lines 308 to 309
Copy link
Contributor

Choose a reason for hiding this comment

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

Referring to your previous comment, should we really keep the LOG here?

Copy link
Author

Choose a reason for hiding this comment

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

I asked myself the same question when making the commit. Issue here is that this is done in a piece of code which doesn't know the mode HAL_OVERRIDE hence if I remove it from here this would also remove it in non HAL_OVERRIDE as well.

The split between the dma_stm32 and the dma_stm32_v1 is done in a way that, from the dma_stm32 this could be more than just FE (it depends on what is checked within the dma_stm32_v1), so I don't feel it would be fully correct to also move this LOG_ERR within the dma_stm32 (even if it'd be ok based on current code).

Any opinion ?

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not familiar enough with the DMA intricacies, so I don't have an opinion. I was just asking the question based on your answer to Mathieu. But if it works as is, it's ok for me.

}

Expand Down