soc: nordic: Add driver for Nordic MVDMA peripheral

[nordic-krch]

Driver does not implement Zephyr DMA API. The reason is that it will mainly be used in the vendor specific code and translation to the Zephyr API significantly decreases the performance to a point where using DMA is no longer beneficial.

Driver offers free running transfer setup and a transfer with a callback. If free running mode is used (without a callback) then nrf_mvdma_xfer_check can be used to poll for transfer completion. It is required to poll until function returns success (transfer has finished). That is because MVDMA blocks entering S2RAM PM mode and unblocking is done only when transfer completes.

Test contains timings measurements that can be used to decide whether use of MVDMA is beneficial.

DNM as it requires #96909.

[teburd]

I'm a bit confused by this PR to be honest, it is adding the driver to the DMA drivers, but it is not in fact a DMA driver from Zephyr's perspective. I'm not sure exactly where this should go, but I do not believe it should go into drivers/dma.

To be clear, I'm not at all opposed to a vendor creating their own APIs and drivers around DMA, as noted already in the documentation the DMA API is a bit of a union of DMA peripheral capabilities. If DMA-like actions are wanted in a cross platform way we already provide this in peripheral APIs in part. But to put this driver in drivers/dma should imply it implements the dma.h interface which it does not.

[nordic-krch]

@teburd I was also not sure if that is a good location. It can as well be placed in soc/nordic. My argument for placing it in drivers/dma is that it is easier for the user to find it if dma-like operation is needed.

[github-actions]

The following west manifest projects have changed revision in this Pull Request:

Name	Old Revision	New Revision	Diff

✅ All manifest checks OK

Note: This message is automatically posted and updated by the Manifest GitHub Action.

[carlescufi]

We should not be adding drviers under soc/ that are covered by an existing Zephyr API. This requires further discussion and clarification on why this is needed and why something like this can't be implemented under drivers/ using zephyr APIs.

I think this is worth discussing in the Architecture WG meeting to ensure that @nordic-krch has a chance to explain why the common DMA API is not suitable in this case and an internal variant is required.

[teburd]

I guess the only question I have is why not have this live in hal_nrf or whatever, I guess because you’d still need some DT/Kconfig integration which would be missing?

[nordic-krch]

I guess the only question I have is why not have this live in hal_nrf or whatever, I guess because you’d still need some DT/Kconfig integration which would be missing?

yes, we keep Zephyr agnostic stuff in hal_nordic. It's Kconfig/DTS but also driver needs to use Zephyr API inside (block PM states when MVDMA is operating).

[sonarqubecloud]

Quality Gate passed

Issues
9 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[carlescufi]

I guess the only question I have is why not have this live in hal_nrf or whatever, I guess because you’d still need some DT/Kconfig integration which would be missing?

@teburd and also because this driver uses Zephyr primitives, and drivers in HALs should be OS-neutral, otherwise we have a dependency in both directions.

[nashif]

please split this into own PR including PM changes only, making this part of a driver PR does not give it the visibility and reviews it deserves.

[nordic-krch]

it is there: #96909

[teburd]

I guess the only question I have is why not have this live in hal_nrf or whatever, I guess because you’d still need some DT/Kconfig integration which would be missing?

@teburd and also because this driver uses Zephyr primitives, and drivers in HALs should be OS-neutral, otherwise we have a dependency in both directions.

Is this driver in any way accessible to an application or usable by an application?

If yes then I'd say I still have a concern here that you are going to introduce a nordic specific API for what could be a broadly useful function of asynchronous memcpy/zeroing, where "how its done" could be soc specific and still avoid the cost of dealing with the DMA APIs and its descriptors.

If no, consider doing this instead. I think it'd be a great feature, and could internally use mvdma or other soc specifics (e.g. a dedicated dma channel in other scenarios) without needing to fully expose the DMA which often has varying behavior across vendors.

[nordic-krch]

Is this driver in any way accessible to an application or usable by an application?

Currently we don't see a use case. Application operates on "fast" RAM. For memory-to-memory operations time needed to setup a MVDMA will be longer than memory operation itself. nRF54H20 SoC has "slow" RAM that is used by peripherals and main use case for MVDMA is to copy data between "fast/user" memory and "slow" which happens in drivers.

[carlescufi]

Architecture WG meeting:

• On Nordic devices, there's DMA for each peripheral that is independent of the DMA being exposed here
• The MVDMA engine instead can copy from memory to memory and from register space to memory
• The peripherals themselves can only access slow RAM, but usually buffers are populated in fast RAM, so copying is needed
• MVDMA however can access both fast and slow RAM, and so the purpose of this driver is to be able to copy from and to slow/fast RAM
• Using MVDMA only makes sense if setting up the DMA transfer is faster than actually copying memory, and using the standard DMA API would effectively negate the advantages
  • In particular, preparing the descriptors is a time-consuming task
• Why can't then just be in the HAL?
  • It's using Zephyr APIs, particularly power management and cache APIs