stm32l4-multi: new API for DMA on the STM32N6 #607
Conversation
Summary of ChangesHello @jmaksymowicz, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly upgrades the DMA capabilities for STM32N6 microcontrollers by introducing a new, flexible API. This enhancement allows developers to leverage advanced features of GPDMA and HPDMA controllers, such as multi-buffer transfers and explicit cache control, to optimize data movement and improve system performance. The changes also ensure backward compatibility, making the transition seamless for existing projects. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a new, more advanced DMA API (libxpdma) for the STM32N6 and refactors the existing libdma API to use it for backward compatibility. The new API adds support for multi-buffer transfers, burst transfers, and other advanced features of the GPDMA/HPDMA controllers. The changes are extensive and well-structured.
My review has identified several issues, including some critical bugs that could lead to incorrect behavior, such as hardcoded transfer directions and a copy-paste error in DMA transform logic. I've also found a bug in the SPI driver that would prevent TX DMA from functioning. Additionally, there are some minor issues like typos in comments and an ambiguous field description in a public header that led to a bug in the PWM driver. I've provided suggestions to fix these issues.
Allow transfer of multiple buffers in a single transaction. Allow access to advanced features of DMA controller (burst transfers, endianness conversion, padding and alignment). Allow explicitly setting buffers as cached or uncached. Allow allocation of uncached memory from DMA pool. Split start transfer and wait for transfer functions. Reimplement old API using new API functions. Allow infinite RX transfers on STM32N6. JIRA: RTOS-1068
New API allows the user's buffer to be transferred by DMA without modification, so an additional temporary buffer inside the driver is no longer necessary. JIRA: RTOS-1068
With new API transactions with preamble (command, address, dummy cycles) can be performed with DMA thanks to the ability to transfer multiple buffers at once. JIRA: RTOS-1068
jmaksymowicz
force-pushed
the
jmaksymowicz/stm32n6-dma-list
branch
from
448013d to
b06b0a6
Compare
Description
The new API allows access to advanced features of the GPDMA and HPDMA controllers, including transfer of multiple buffers in a single transaction, burst transfers, endianness conversion and setting data padding and alignment. It also allows for infinite RX transfers on the STM32N6, which was not possible previously.
To transfer multiple buffers or create an infinite transaction, a linked list is created in uncached memory based on buffer definitions taken from the user. Depending on how many transfer options change from one buffer to the next, between 4 and 9 buffers can be transferred in a single transaction. The controller then executes the transfer according to internal registers and the linked list in memory.
The new API allows buffers to be explicitly set as cached or uncached. Along with allocation of uncached memory, this allows more performant DMA transactions - cache operations under our OS require a syscall, which is very time consuming.
"Start transfer" and "wait for transfer" functions were split - the previous API only allowed transaction start and waiting at once. This is more fitting for certain peripherals like SPI, where (according to documentation) SPI transaction should only start after the DMA transfer has been started.
For backwards compatibility with existing code, the old API was reimplemented using new API functions.
Motivation and Context
Types of changes
How Has This Been Tested?
Checklist:
Special treatment