On Mon, Mar 05, 2012 at 10:30:43AM -0800, Stephen Warren wrote: > Cousson, Benoit wrote at Monday, March 05, 2012 6:14 AM: > > Beside u32 and string, do we know what kind of parameters we can expect > > to retrieve? > > Because we can potentially reduce the scope to these two types only. > > I wondered whether different drivers would return arbitrary driver-specific > structs, so that the DT specific would encode not only the DMA request > number, but perhaps some/all of the DMA parameters like transfer size, > wrap, even DMA FIFO address, ... Right. The thing to consider here is: what information does the driver already have about the device? - physical address of the data register - size of the data register - it certainly should know the fifo depth (think - if it has to do PIO then it needs this information already.) so, there's no point putting that information into DT because it must be known by the driver for systems not using DMA. We have a standardized way to pass this information to DMA engine drivers from the peripheral device driver: struct dma_slave_config. What is outside of the scope of the driver is knowing how a peripheral device is connected to a set of DMA engines. That's a much harder problem to solve because there's many varied ways to do that in hardware, from a static mapping between the peripheral and a DMA engine request signal, to implementations which have some kind of front end MUX, to there being several choices of DMA engine for the peripheral (I believe some Samsung platforms fall into this category.) Some of those problems can be solved by redesigning the DMA engine drivers to have a clear way to handle DMA engines with multiple request inputs shared between multiple channels: you treat the individual request inputs as separate DMA engine channels, and when there is work to be done, you allocate the DMA engine channel to a physical DMA engine and physical channel. That's not going to be easy to do at the moment, because every DMA engine driver is custom written from the ground up with no commonality between them (I've mentioned this in previous email threads.) I think, before trying to design some kind of DT based representation of how to bind DMA stuff to peripheral drivers, the very first thing that needs to happen is the DMA engine drivers need sorting so that they all work in mostly the same way in terms of how channels are allocated to peripherals. Only once we have a consistent way that's done can we then start looking at what kind of representation is needed to bind the two together. Otherwise, we're going to end up with the OMAP way of binding channels, the PL08x way, the SA11x0 way, etc and its going to become very very unfunny to sort this out later. -- 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
