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

flash: stm32_ospi: weak callbacks cannot be used by multiple octospi drivers #84647

Open
721082 opened this issue Jan 28, 2025 · 2 comments
Open
Assignees
Labels
area: Display Enhancement Changes/Updates/Additions to existing features platform: STM32 ST Micro STM32

Comments

@721082
Copy link

721082 commented Jan 28, 2025

Is your enhancement proposal related to a problem? Please describe.
On the stm32u5a9xx, if we want to use octospi1 for the zephyr/drivers/flash/flash_stm32_ospi.c and octospi2 for a display we cannot use HAL_OSPI_IRQHandler() in the octospi2 isr because some weak functions are defined in the flash driver, like HAL_OSPI_TxCpltCallback() and they would be called on octospi2 interrupts.

Describe the solution you'd like
1/ I would like to be able to call HAL_OSPI_IRQHandler() in the display driver isr because it contains a bit of logic. To do so, I think it should be possible in stm32cube hal to use callbacks instead of weak functions but it requires to enable it directly in stm32u5xx_hal_conf.h as it's not configurable using Kconfig.

Describe alternatives you've considered
2/ An alternative would be to copy paste the HAL_OSPI_IRQHandler() function into the display driver.
3/ A second alternative would be to implement a octospi driver for st,stm32-ospi and move into it the octospi related part from the flash and display drivers. Then in this driver we should be able to define the weak callbacks.

Additional context

@721082 721082 added the Enhancement Changes/Updates/Additions to existing features label Jan 28, 2025
Copy link

Hi @721082! We appreciate you submitting your first issue for our open-source project. 🌟

Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙

@erwango
Copy link
Member

erwango commented Jan 30, 2025

Using callbacks should indeed be the way to go.
However, it is preferable to void modifying directly stm32u5xx_hal_conf.h and ideally solution should be the most generic possible to easily scale through series and drivers (if it happen that callback could be useful in other cases).
What about using #undef / #define in a dedicated file and controlled by new dedicated Kconfig symbols ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: Display Enhancement Changes/Updates/Additions to existing features platform: STM32 ST Micro STM32
Projects
None yet
Development

No branches or pull requests

3 participants