Hi Robert, On 02/18/2015 07:12 PM, Robert Jarzmik wrote: > I have resumed my work on marvell dma engine support, in order to have > pxa_camera working with it. > > For reference, it is described in Documentation/video4linux/pxa_camera.txt, and > was already discussed in [1]. > > What I'll need to do is have a dma driver which : > - upon tx_submit tries to "hot chain" the transmission > And doesn't attemp to queue a new tx in the tasklet. > > - upon dma completion interrupt calls each terminated tx->complete() function, > and not only the first tx's one Would it not be possible to change the finite state machine logic in a way that it uses cyclic DMA transfers? They should work just fine with mmp-pdma, at least they do for audio. But you dug deeper here than I did, so I might miss something, of course. > - can tell me if a channel is still running or is stopped The residue information returned by mmp_pdma_tx_status() does not suffice here, I take it? > As I have these constraints, I have 2 choices : > 1) develop a new pxa_dma.c, which will have some common code with mmp_pdma.c As that new driver would expose its function via the common slave-dma API interface, I really see no benefit in this code duplication. After all, the idea behind the common interface is that DMA controller implementations should behave in a way that makes them exchangeable, right? > 2) amend mmp_pdma I'd clearly vote for that option. > The issue with (2) is that it might break existing drivers using the paradigm > that "only the first tx is signaled". But with a new driver for pxa_dma, we'd need to make all existing peripheral drivers compatible to both pxa_dma and mmp_pdma, as they're used on both platforms. If there are significant differences in the behavior of the two, that really misses the point of API unification. So, I'd first look into which functionality is needed, and why that's impossible to achieve with cyclic DMA descriptors. We can, if needed, introduce a new flag in struct dma_slave_config and support that in mmp-pdma. Thanks, Daniel -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
