On 15 September 2011 12:01, Barry Song <21cnbao@xxxxxxxxx> wrote: > 2011/9/13 Barry Song <21cnbao@xxxxxxxxx>: >> 2011/9/13 Jassi Brar <jaswinder.singh@xxxxxxxxxx>: >>> 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. >> >> 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 think xfer_template is better - which stresses the usage as having prepared templates of transfers and only change src/dst address before submitting. 'device_prep_dma_genxfer' is the API which is already named so. > 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. Is there no change other than skipping check for SLAVE when using this api ? -- 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
