On Sat, Feb 02, 2013 at 10:16:43AM -0800, Tony Lindgren wrote: > * Matt Porter <mporter@xxxxxx> [130202 10:10]: > > If it doesn't work, work with Vinod to fix the api. It's expected, > > I'm working on dmaengine API changes right now to deal with a > > limitation of EDMA that needs to be abstracted. > > Regarding the DMA API limitations, I'm only aware of lack of capability > to configure autoincrement at the device end. And that keeps us from > converting all GPMC related devices using omap SDMA to use the DMA API. > > Are there other limitations currently known with the DMA API? Yes, I called one out when this was first posted as an RFC and was working it in parallel with this support. This one blocks AM33XX support in mmc and is the reason I split all of the mmc support out of the base edma dmaengine for am33xx series. Independent of the blockage, whatever we finally settle on to address this API need will also cleanup the use of magic values in the davinci mmc driver (that's part of the second thread below). RFC posting: https://patchwork.kernel.org/patch/1583531/ Posting with initial attempt at a caps api: http://www.spinics.net/lists/linux-mmc/msg18351.html Also, I haven't fully vetted the situation with cyclic transfers and EDMA, however, I'm pretty sure that we'll need some API changes there. The reason is that some Davinci platforms have no FIFO on their McASP implementation (that was a new feature added on DA8xx and also AM33xx). As such they have audio support implemented using ping-pong buffering via an SRAM buffer. There's been a number of patches ahead of all this that myself and others have worked upstream to get the SRAM stuff to be Davinci-independent (genalloc). But, at the end of all of this, there's no notion in a cyclic transfer of doing synchronized ping-pong buffering using two chain channels. This is how it is implemented (and documented in EDMA docs going back to the DSPs this IP first showed up on) using the private API. I'll be looking at this soon, but, I'm more interested in 1) getting the base support in 2) then the mmc stuff blocking DT populated platforms using omap_hsmmc (split out and posted) 3) v3 of the caps api w/ vinod's concerns address (working it not) Normally, I'm not going to bring up the cyclic transfer issue until I have some code to show or reference for discussion...but it's worth being aware. But, in any case, I'm confident that will gate having the mcasp driver that am33xx also uses converted to dmaengine. Except for the gpmc limitation you menationed, that's the last in kernel user of the privat edma api needed to be converted such that we can kill off arch/arm/common/edma.c once it's taken in. -Matt -- 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
