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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2011/9/13 Barry Song <21cnbao@xxxxxxxxx>:
> 2011/9/13 Jassi Brar <jaswinder.singh@xxxxxxxxxx>:
>> On 12 September 2011 21:56, Barry Song <21cnbao@xxxxxxxxx> 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.singh@xxxxxxxxxx>
>>>
>>> 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.song@xxxxxxx>

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux