On 13 September 2011 13:16, Barry Song <21cnbao@xxxxxxxxx> wrote: >> 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, 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
