2011/9/13 Barry Song <21cn...@gmail.com>: > 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.
and i also think xfer_template is a bad name for a structure which is an API. i'd like to add namespace for it and rename it to dma_genxfer. or have any good suggestion? i'd like to send this together with "BUG_ON(dma_has_cap(DMA_SLAVE, device->cap_mask) &&!device->device_prep_dma_genxfer)" as v2. -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
