2011/9/13 Jassi Brar <jaswinder.si...@linaro.org>:
> On 13 September 2011 13:16, Barry Song <21cn...@gmail.com> wrote:
>>> 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,
> 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.

i think it should be handled by this patch but not a new one.

>
> thanks.
>

-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

Reply via email to