Hi! (Sorry if duplicate. Trying to remove HTML content.). Wondering if somebody out there might be able to help me. I have a situation where I have a pool of physical DMA engines, with each appearing as a separate DMA device in the system, on top of which I want to create a much larger number of virtual DMA channels. So, I want to export a large number of virtual DMA channels which are serviced by a smaller pool of DMA engines. Now one way that I see how this could be addressed is that for each instance of a DMA engine in the pool I instantiate say V number of virtual DMA channels to be associated with the given instance. So, if the size of my pool of DMA engines is P, then in the end I'll end up PxV virtual DMA channels available to clients. My concern is, as clients come in and do dma_request_channel() calls, when the (virtual) DMA channels are handed out it appears that they'll be handed out sequentially (ignoring for the moment the whole cpu node thing). Thus, all the V channels of DMA engine instance 0 will be handed out before the subsystem gets around to handing out channels for the next DMA engine, instance 1, and so on. As such, I'll end up with a scenario where my allocated virtual channels are not evenly distributed across my pool of P DMA engines. Is there a mechanism to more evenly distribute the allocation of DMA channels to clients across a pool of DMA engines? So, if only P number of (virtual) DMA channels were to be allocated to clients, then the assignment to physical DMA engines would end up being 1-1, rather than P channels all being serviced by one physical DMA engine. Is there something in the Linux DMA framework that might address this? I've been digging through what documentation I can find and the source code, and not seeing anything. Do I need to "hide" the physical DMA engines into appearing as one, and then within my driver manage the round-robin allocation of them to virtual channels myself? Thanks in advance for your time and any assistance! Eric -- 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
