2011/9/15 Jassi Brar <jaswinder.singh@xxxxxxxxxx>: > 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. sorry i can't agree that. device_prep_dma_genxfer is an API, xfer_template is a data structure which will be seen by users, client drivers. it at least needs a namespace. Otherwise, people someday maybe add another xfer. > >> 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
