[FR] SERIAL_DMA feature for STM32H7xx

[rondlh]

Is your feature request related to a problem? Please describe.

No SERIAL_DMA feature support for the STM32H7xx platform.

Are you looking for hardware support?

No

Describe the feature you want

Add SERIAL_DMA support for the STM32H7xx platform

Additional context

I've coded this FR already, including a cleanup of the existing SERIAL_DMA for the STM32xxx platform.
The code is now easier to maintain and uses more HAL function and HAL variables. Tested for STM32F0xx, STM32F1xx, STM32F2/F4, STM32F7xx and STM32H7xx (FLY D8 Pro STM32H723).

I'm not sure if I should push this code to #27547 or create another branch?

Here some input on coding for the STM32H7xx platform.
Most things are very similar to the STM32F4xx and STM32F7xx but you have to consider the MCU to be split into 3 domains. D1, D2 and D3. Most is in domain D2, which works as expected. You should check in which domain the hardware is you are working with and if it has access to the devices and memory you are addressing.
For the SERIAL_DMA case one thing tripped me up, the STM32H7xx has a LPUART1, which is a D3 device which cannot be accessed from the DMA1/2 controllers (D2 devicese) which I was programming. Only when I noticed that the USART1 clock was not running did I realize that something odd was happening. Selecting USART1 solved the issue.
The DMA1/2 controller now works with a DMAMUX1/2 devices which handles the DMA channel selection. This used to be done with the DMA selection channel Configuration Register (DMA_SxCR_CHSEL bits), and devices were limited to using a channel that matches the devices addressed. The STM32H7xx is more flexible in this way, any channel can address any device (Domain allowing) by setting it in DMAMUX1 channel configuration. The relationship between a DMA stream and DMAMUX channel is quite poorly documented.
It works like this:
DMA1 stream [x] (x=0..7) is configured by settings DMAMUX1__Channel[x]->CCR to the DMA request ID.
DMA2 stream [x] (x=0..7) is configured by settings DMAMUX1__Channel[x + 8]->CCR to the DMA request ID.
So DMA1 stream 0 relates to DMAMUX1_Channel0, DMA2 stream 0 relates to DMAMUX1_Channel8 and DMA2 stream 7 relates to DMAMUX1_Channel15. There is a long table with over 100 devices to select from.
There is no separate DMAMUX clock, the MUX is running when any of the related DMA controllers are enabled. Some users report that you need to be careful with resetting the DMA controllers, because there might be unwanted side effects for the MUX (lost configuration).