Re: [PATCHv2] DMAEngine: Define generic transfer request api

[Jassi Brar <jaswinder.singh@linaro.org>]

On 16 September 2011 12:47, Barry Song <21cnbao@gmail.com> wrote:
> 2011/9/15 Jassi Brar <jaswinder.singh@linaro.org>:
>> --- a/drivers/dma/dmaengine.c
>> +++ b/drivers/dma/dmaengine.c
>> @@ -699,6 +699,8 @@ int dma_async_device_register(struct dma_device *device)
>>                !device->device_prep_dma_cyclic);
>>        BUG_ON(dma_has_cap(DMA_SLAVE, device->cap_mask) &&
>>                !device->device_control);
>> +       BUG_ON(dma_has_cap(DMA_GENXFER, device->cap_mask) &&
>> +               !device->device_prep_dma_genxfer);
>
> i don't think it is what i want here. device_prep_dma_genxfer should
> be able to cover memcpy, slave or other modes, but not parallel with
> them.

ATM this api is indeed parallel to others like memcpy, slave_sg etc.
because I have dropped the 'op' member in v2. The idea is to merge
other prepares one at a time and ultimately have this api consume
those that it can. So the 'op' would be restored when we merge
the first 'prepare' into this.


> For example, if i use genxfer, but my devices are slave. i might not
> need a device_prep_slave_sg since i have already prep_dma_genxfer, but
> anyway, i need a DMA_SLAVE_CONFIG to set burst size or others. then
> i'd like to have DMA_SLAVE flag but without device_prep_slave_sg
> callback.

As I already said, this api could be used for interleaved Mem->Mem
as well as Mem<->Dev
If your channels are Slave, please set the DMA_SLAVE flag and provide the
'device_control' callback.

I think I should have simply removed the check
    BUG_ON(dma_has_cap(DMA_SLAVE, device->cap_mask) &&
                   !device->device_prep_slave_sg);
Because obviously we now have a _valid_ case of SLAVE channel but
supporting a different prepare - device_prep_dma_genxfer.  Will do that in v3.