Hi Peter,

On 02-10-20, 11:48, Peter Ujfalusi wrote:

It depends which is best for the use case.
I see the metadata useful when you need to send different
metadata/configuration with each transfer.
It can be also useful when you need it seldom, but for your use case and
setup the dma_slave_config extended with

enum dmaengine_peripheral peripheral_type;
void *peripheral_config;

would be a bit more explicit.

I would then deal with the peripheral config in this way:
when the DMA driver's device_config is called, I would take the
parameters and set a flag that the config needs to be processed as it
has changed.
In the next prep_slave_sg() then I would prepare the TREs with the
config and clear the flag that the next transfer does not need the
configuration anymore.

In this way each dmaengine_slave_config() will trigger at the next
prep_slave_sg time configuration update for the peripheral to be
included in the TREs.
The set_config would be internal to the DMA driver, clients just need to
update the configuration when they need to and everything is taken care of.

Ok I am going to drop the dmaengine_peripheral and make
peripheral_config as as you proposed.

So will add following to dma_slave_config:
        void *peripheral_config;

Driver can define the config they would like and use.

We can eventually look at common implementations and try to unify once
we have more users

-- 
~Vinod