On 09/12/16 07:59, Vinod Koul wrote: > On Thu, Dec 08, 2016 at 04:48:18PM +0000, Måns Rullgård wrote: >> Vinod Koul <vinod.koul@xxxxxxxxx> writes: >> >>> To make it efficient, disregarding your Sbox HW issue, the solution is >>> virtual channels. You can delink physical channels and virtual channels. If >>> one has SW controlled MUX then a channel can service any client. For few >>> controllers request lines are hard wired so they cant use any channel. But >>> if you dont have this restriction then driver can queue up many transactions >>> from different controllers. >> >> Have you been paying attention at all? This exactly what the driver >> ALREADY DOES. > > And have you read what the question was? > I think many people appreciate the quick turn around time and responsiveness of knowledgeable people making constructive remarks in this thread, but it looks we are slowly drifting away from the main problem. If we had to sum up the discussion, the current DMA API/framework in Linux seems to lack a way to properly handle this HW (or if it has a way, the information got lost somewhere). What concrete solution do you propose? Alternatively, one can think of the current issue (i.e.: the fact that the IRQ arrives "too soon") in a different way. Instead of thinking the IRQ indicates "transfer complete", it is indicating "ready to accept another command", which in practice (and with proper API support) can translate into efficient queuing of DMA operations. -- 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
