De-duplicate peripheral DMA APIs

[Dominaezzz]

Similar to #1550 I also want to de-duplicate the peripheral APIs that initiate DMA transfers.

Something along the lines of converting this

let transfer = i2s_dma.read_dma(...);
let transfer = i2s_dma.read_dma_circular(...);

to become this

let prepared_transfer = rx_channel.prepare(....);
let prepared_transfer = rx_channel.prepare_circular(....);

let transfer = i2s.read_dma(prepared_transfer, ...);

The concept of "one shot" and "circular" transfers belongs to the DMA hardware/driver. All peripherals really care about is if it should use DMA or CPU.

This does mean that drivers will no longer own DMA channels, but the transfer object will.
Of course, for convenience wrappers that hold on to both the driver and the DMA channel can be made.

There are a couple reasons why I think this is beneficial:

• All drivers get the same uniform DMA APIs and there's no need to duplicate the dma/dma_circular stuff on all drivers.
• Changes like Remove 'static bound requirement on DMA buffers? #1245 would be easier to make since only the channel APIs would be affected.
• Introducing more transfer variants like read_double_buffered would be much easier.
• Custom/3rd party drivers would also be able to make use of these as well.
• On chips that have a limited number of GDMA channels, this makes sharing sharing DMA channels between different peripherals much easier as each driver isn't holding on to the channel for its existence.

A downside to this is some simplicity and ease of use is lost (which is often the price of flexibility), as some more steps are required to perform a DMA transfer. This can mostly be solved with some wrappers where it makes sense.

[bjoernQ]

I see the benefits (and share the opinion it will somewhat degrade ease-of-use)

One thing I wonder about: while currently code looks somewhat duplicated, different drivers do some "special-massaging" to get DMA to work reliably. I guess supporting that depends a bit on how much of the code we want/can to move to the prepare step

[Dominaezzz]

I guess supporting that depends a bit on how much of the code we want/can to move to the prepare step

Exactly! Stuff to research.
At the moment I'm mostly thinking of the existing Channel::prepare_transfer method.

The one thing I'm not sure about yet is how to expose the length (if available) of the transfer to the peripheral. For example spi wants to know upfront how long the transfer is. I'm thinking the user while have to explicit specify it in addition to the prepared transfer when starting an spi transfer.