On 13 September 2011 13:16, Barry Song <[email protected]> wrote:
>> if test pass, to the patch, and even for the moment, to the API's idea
>> Acked-by: Barry Song <[email protected]>
>
> one issue i noticed is with a device_prep_dma_genxfer, i don't need
> device_prep_slave_sg any more,
Yeah, the damengine would need to adapt to the fact that these
interleaved tranfers could be Mem->Mem as well as Mem<->Dev
(even though yours could be only one type, but some dmacs could
do both).

> 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);
>
Seems ok, but please modify in a way you think is best and submit a patch
on top of this new api. Then it'll be easier to evaluate everything.

thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to