Hi Laurent, On 11/03/2016 05:12 PM, Laurent Pinchart wrote: >> It is a bit misleading that it used dma_request_slave_channel_compat() >> for getting the channel. >> >> I think what would be correct is: >> dma_cap_mask_t mask; >> >> dma_cap_zero(mask); >> dma_cap_set(DMA_SLAVE, mask); >> hist->dma_ch = dma_request_chan_by_mask(&mask); >> >> We will get any DMA channel capable of slave configuration, but we will >> configure no DMA request number for the channel. > > I believe that should work. It could in theory result in a different behaviour > as it could return a DMA channel not handled by the OMAP SDMA engine, but I > don't think that would be an issue. Yes, that could be the case if we would have more than one DMAs in SoCs where the omap3isp is used, but we only have sDMA. The reason why I would like to move the driver to use the generic API is that my plan is to remove the legacy sDMA support in the future so the filter_fn is not going to be available outside of the DMAengine driver. I do believe that this is safe to do in this way and if the IP shows up somewhere else where we have more than one DMAs - which is unlikely - I'm sure it can be fixed up, but w/o device it is hard to guess what needs to be done. FWIW: if omap3isp shows up where we have sDMA and eDMA we can set the mask as DMA_SLAVE | DMA_MEMCPY as eDMA does not set both for a channel - it is either slave or memcpy. >> and document this in the driver... > -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
