2011/9/13 Barry Song <21cn...@gmail.com>:
> 2011/9/13 Jassi Brar <jaswinder.si...@linaro.org>:
>> On 12 September 2011 21:56, Barry Song <21cn...@gmail.com> wrote:
>>>> Define a new api that could be used for doing fancy data transfers
>>>> like interleaved to contiguous copy and vice-versa.
>>>> Traditional SG_list based transfers tend to be very inefficient in
>>>> such cases as where the interleave and chunk are only a few bytes,
>>>> which call for a very condensed api to convey pattern of the transfer.
>>>>
>>>> This api supports all 4 variants of scatter-gather and contiguous transfer.
>>>> Besides, it could also represent common operations like
>>>> device_prep_dma_{cyclic, memset, memcpy}
>>>> and maybe some more that I am not sure of.
>>>>
>>>> Of course, neither can this api help transfers that don't lend to DMA by
>>>> nature, i.e, scattered tiny read/writes with no periodic pattern.
>>>>
>>>> Signed-off-by: Jassi Brar <jaswinder.si...@linaro.org>
>>>
>>> anyway, this API needs a real user to prove why it needs to exist.
>>>
>>> prima2 can be the 1st(?, 2nd if TI uses) user of this API. let's try
>>> to see what the driver will be with this api. Then we might figure out
>>> more about what it should be.
>>>
>> Did you discover any issue with the api?
>
> no until now, but i need to test as i said since there is nobody else
> has used it before. so i just hold the formal ACK for a moment.
>
>> Because only three days ago you said
>> {
>> Jassi, you might think my reply as an ACK to "[PATCH] DMAEngine:
>> Define generic transfer request api".
>> }
>
> if test pass, to the patch, and even for the moment, to the API's idea
> Acked-by: Barry Song <baohua.s...@csr.com>
one issue i noticed is with a device_prep_dma_genxfer, i don't need
device_prep_slave_sg any more, then the validation check in
dma_async_device_register():
BUG_ON(dma_has_cap(DMA_SLAVE, device->cap_mask) &&
!device->device_prep_slave_sg);
is wrong to me.
How about:
BUG_ON(dma_has_cap(DMA_MEMCPY, device->cap_mask) &&
- !device->device_prep_dma_memcpy);
+ !device->device_prep_dma_memcpy &&
+ !device->device_prep_dma_genxfer);
BUG_ON(dma_has_cap(DMA_SLAVE, device->cap_mask) &&
- !device->device_prep_slave_sg);
+ !device->device_prep_slave_sg &&
+ !device->device_prep_dma_genxfer);
>
>>
>> The api met your requirements easily not because I know them already,
>> but because I designed the api to be as generic as practically possible.
-barry
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
