On Fri, May 7, 2010 at 4:43 AM, Linus Walleij <linus.ml.walleij@xxxxxxxxx> wrote: > 2010/5/7 Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx>: > >> I would have thought given the concerns that I stated, merely running >> the drivers in PIO mode would not address those concerns. So no, I'm >> not satisfied. > > Sorry didn't get it, I understood it as it should be tested on the Versatile > without regressions. > > So now I understand that you want the drivers to be tested in DMA mode > on the ARM reference HW. Right? Maybe I am also misunderstanding, but I think the concern is less about "does the dma driver work" and more about exposing an api to dma clients that is not expressive enough to handle architecture specific quirks. The dma provider can always be fixed up. The "boxed in" effect happens when there is non-trivial pile of dma client device drivers using an api that is not expressive enough for a new ARM platform That being said I think the interface tweaks for device_control and channel_status were relatively painless, and the one architecture specific call we added seems like something that could never be reconciled in a cross-architecture generic api. > So in order for this to be accepted, I also have to implement > support for the DMA controller found in the reference platforms from > ARM, PL080 and PL081, since there is only this S3C-tilted driver > in the kernel so far: > arch/arm/mach-s3c64xx/dma.c > > This is hard for me to do since I have to try to lend a device to > test it on. I do not think this is a fair burden for you to carry, but it does sound like Russell will come looking for you when he finds a counter-example architecture that breaks the api assumptions. The multiplexing case seems to be the most challenging to the existing model. The idea to oversubscribe struct dma_chan's versus physical channels seems workable... Russell is this the implementation you would like to see pre-merge, or is a hand-wavy plan to address it enough to let this initial implementation through? > Anyway, I will see if I can lend the RealView machine again and > play around a bit with patching up Bens driver to work with the > DMAengine and show that it runs, in DMA mode, on the RealView, > as a proof of concept. Would that be OK then? > >> As I've said, I don't want the ARM platforms to be boxed into a corner >> such that they can never have DMA support because this stuff hasn't been >> properly thought out. > > I'm thinking all I can, I promise. Perhaps I'm not smart enough all the > time, it's a known problem, I'm working on it. > >> Or let me put it another way - if people are happy for Linux to support >> new ARM CPU architectures, but with very little attention given to DMA >> support on those architectures, then feel free to box the ARM platforms >> into a corner on DMA support - but on the understanding that _you_ will >> have to deal with the DMA API breakage on those architectures yourself. >> Because with ARM platforms not having DMA support, there's absolutely >> no way to run any checks what so ever on DMA when the CPU architecture >> support is created. > > I'm doing the best I can to meet exactly this goal. The changes done in > the DMA engine were done towards the end of making the DMA > engine support *any* DMA controller for the PrimeCells, and I've proven > it to be possible for two different architectures: U300 and U8500. These > are totally different even though they're coming out of the same > company (we *weren't* the same company when they were created!). > One is ARM9 the other is Cortex A9 dualcore. One use a DMA silicon > called COH901318 the other use a DMA silicon named DMA40. > > So now I guess I have to make it tick on the block known as PL080/PL081 > as well, and I'll have a try at it. > >> This is why people like the OMAP folk end up doing a lot of the DMA >> debugging; they tend to be the first group to pick up new architectures >> with fully functional platforms. > > Yep it seems we're going to have the same issue with Cortex A9 for > U8500. > > Right now we're doing DMA debugging and testing on U300 and > U8500 to make sure neither break as a result of these patches, > and defining the API for the DMA engine. > Very reasonable and I am not seeing a merge blocking issue from the dmaengine perspective at this point. The dma_request_channel() interface seems sufficient for all the needs to date as it basically allows architectures to develop their own dma-provider-to-client matching interface to override the generic memory-to-memory client matching interface. The 'slave' interface and the ->private parameter of dma_chan (pending Jassi's recent fix) has proven sufficient for handling association specific data. These new patches establish a model whereby once you know you are talking to your $ARCH dma driver you can make driver specific calls to pass information that would be too ugly to pass in a generic fashion. I do not pretend that this is an elegant arrangement, but it has proven to be functional. I do have concerns about mapping device-to-device dma into a generic api. That's a whole new level of platform-specific crazy, but that is not what these patches are about. At the end of the day I still need Russell's ack/acceptance of the platform_data infrastructure to move forward, but I'll get the dmaengine bits queued into -next so it's at least ready to be pulled. -- Dan -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
