On Wednesday 27 June 2012, Vinod Koul wrote: > On Tue, 2012-06-26 at 20:27 +0000, Arnd Bergmann wrote: > > On Tuesday 26 June 2012, Vinod Koul wrote: > > > On Tue, 2012-06-26 at 14:59 +0000, Arnd Bergmann wrote: > > If we instead modify the dmaengine code itself to know about DT > > rather than wrapping around it, we would not need this filter > > function, but we should still have a probe() function that is > > called by dmaengine code to interpret the data that is specific > > to one dmaengine driver. > I was hoping we can have dmaengine binding, that way dmaengine core code > knows about what to do when some client requests a channel. > > > > > IMHO dmaengine driver should *not* know anything about mapping. By > > > mapping I refer to platform information which tells me which client can > > > use which channel from which dmac. > > > > Agreed too. That information shoudd be part of the slave device-node > > in DT, as I have argued in this thread already. The slave device driver > > does not need to care about the format or the contents of it, > > but we need some code to interpret the contents. From all I can tell, > > the structure of this data cannot be completely generic because of > > all the special cases, so the code to interpret it would live in the > > probe() function I mentioned about that the dmaengine driver provides. > rather than slave driver, why dont we keep this binding within > dmaengine. That would make slave and clients completely independent. Sorry, I believe I was just using the wrong terminology, and what I named the slave here would just be the client. This may have contributed to a lot of confusion before, so let's make sure I use the right terms now: a) slave == dmac == dmaengine driver b) client == device driver, e.g. mmc c) common code == dmaengine layer Is this correct? > > > > I think encoding a description for a dma request in a single number is > > > > the last thing we want to do here. We've tried that with IRQ and GPIO > > > > numbers and it got us into a huge mess that will need a long time to > > > > get out of. > > > No i wasn't thinking of a number. The mapping shouldn't be a global > > > number at all, though that is a very easy but not very scalable > > > solution. > > > We need to take care of 1:1 mapping of client and channels as well as > > > many:1 cases as well. A single global number cannot represent that > > > properly. > > > > > > My idea is platform gives this information to dmaengine. Clients and > > > dmaengine driver do not worry about it. That also paves way for arch > > > independent clients and drivers. > > > > IMO the platform should have no part in this. I absolutely want to > > get rid of any platform-specific hardcoded tables in the kernel for > > stuff that can easily be run-time detected from the device tree. > > There are cases where hard-coding in the kernel is easier, but I don't > > think this is one of them. > > Again, you got me wrong. We don't want any hardcoded table is kernel. > The information in table should come from whatever way that platform can > give me. For your case it should be DT. Ok, good. > We can have the map of which client can use which channel as DT binding > of dmaengine core. So dmaengine can easily arbitrate about channel > requests. Again this mapping information is not some even linux > independent. Why can't it be OS independent? Do you mean there must be a global table, or are you ok with putting the information about a channel into the device that uses the channel, as we do for most other subsystems (IRQ, GPIO, pinctrl, ...). If not, what is the problem with that approach? Arnd -- 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
