On Thu, Sep 06, 2012 at 03:25:21PM +0200, Daniel Mack wrote: > Hi Matt, > > On 27.08.2012 17:33, Daniel Mack wrote: > > On 23.08.2012 03:09, Matt Porter wrote: > >> This series begins the conversion of the DaVinci private EDMA API > >> implementation to a DMA engine driver and converts two of the three > >> in-kernel users of the private EDMA API to DMA engine. > >> > >> The approach taken is similar to the recent OMAP DMA Engine > >> conversion. The EDMA DMA Engine driver is a wrapper around the existing > >> private EDMA implementation and registers the platform device within > >> the driver. This allows the conversion series to stand alone with just > >> the drivers and no changes to platform code. It also allows peripheral > >> drivers to continue to use the private EDMA implementation until they > >> are converted. > >> > >> The EDMA DMA Engine driver supports slave transfers only at this time. It > >> is planned to add cyclic transfers in support of audio peripherals. > >> > >> There are three users of the private EDMA API in the kernel now: > >> davinci_mmc, spi-davinci, and davinci-mcasp. This series provides DMA > >> Engine conversions for the davinci_mmc and spi-davinci drivers which > >> use the supported slave transfers. > >> > >> This series has been tested on an AM18x EVM and Hawkboard with > >> driver performance comparable to that of the private EDMA API > >> implementations. Both MMC0 and MMC1 are tested which handles the > >> DA850/OMAP-L138/AM18x specific case where MMC1 uses DMA channels on > >> a second EDMA channel controller. All other platforms have a simpler > >> design with just a single EDMA channel controller. > >> > >> For those wanting to easily test this series, I've pushed a branch for > >> each version to my github tree at https://github.com/ohporter/linux. The > >> current branch is edma-dmaengine-v3. > >> > >> After this series, the current plan is to complete the mcasp driver > >> conversion which includes adding cyclic dma support. This will then > >> enable the removal and refactoring of the private EDMA API functionality > >> into the EDMA DMA Engine driver. Since EDMA is also used on the AM33xx > >> family of parts in mach-omap2/, the plan is to enable this driver on > >> that platform as well. > > > > Once you have a patch for the McASP driver conversion, I can happily > > test this on a AM33xx board, together with Gururaja's latest McASP > > refactoring series. Let me know how I can help you here. > > Did you find some time yet to continue on this side? I don't want to > appear pushy, but as I need to finish some DT transition on a > AM33xx-based board, I would much like to help out here, in case I can do > anything to help speed things along. > > > Many thanks for your work! Hi Daniel, I'm working on porting this driver work to AM33xx right now. You can take a look at an ugly but functional WIP version at the above repo in the WIP/edma-dmaengine-am335x-v3.6-rc4-cpufreq branch. When I say ugly, I mean ugly...there's a few hacks I'm resolving before I plan to post an RFC series. However, I've been putting the slave sg transfer through a workout on hsmmc and mcspi and it is solid now. I don't expect to start on MCASP conversion until I get this AM33xx enablement series posted. There's a couple things you could help with here. First, I have done some preliminary work in understanding the various "old" platforms in mach-davinci/ that we are going to have to avoid breaking. The first big issue is that we have a split in h/w capabilities between the old platforms that have no AFIFO and our newer ones that do. Unless someone can convince me otherwise, the biggest (and possibly *only*) driver behind the need for SRAM-based ping-pong buffering. This SRAM-based ping-pong buffering is a PITA to deal with atm mostly because we need to encapsulate this behind the cyclic dma api. It's also IMHO, unneeded if you have one of the modern platforms that added the AFIFO since you aren't having to feed the serializer at an unreasonable rate...i.e. we can do fifo bursts. Now, we *can* handle SRAM ping-pong buffering within the dmaengine driver, however in the short-term it's a bit of a pain because of the way the wrapper driver is instantiated and I'd like to avoid any complication of having to feed it platform data until we absolutely have to. That is, with SRAM ping-pong buffering, we now have to have platform-specific data about the SRAM we can allocate. This is complicated by the fact that 1) the ARM SRAM consolidation series seemingly died last year...which btw, left some orphaned mcasp sram ping pong enablement patch out of tree for mach-davinci/ 2) the latest SRAM driver effort is specifically tied around DT atm which makes it short-term problematic to leverage on mach-davinci/ platforms where we really need it. My best idea at this point is to approach the McASP conversion in a couple stages. The first is to support cyclic dma in the dmaengine wrapper driver in continuous mode such that only platforms with AFIFO support (DA8xx/L138/AM180x and AM33xx/TI81xx to my knowledge) can utilize it. Also part of the first stage, of course, is the mcasp driver refactoring so that ping-pong buffering is an optional sub-config option for those old Davinci boards and continues to use the private EDMA API for now. I'm ok with this partially because those old platform seem to be unmaintained (nobody stepped up to test DM644x etc) and the SRAM ping-pong buffering code is completely unused in mainline right now. If those !AFIFO platforms were removed from the kernel then we wouldn't even have to deal with it. There's a few things you can help with: 1) testing the WIP driver 2) add cyclic dma support 3) do the sram-less mcasp conversion I'll get to #2 and #3 next, but I have no problem if you beat me to it. -Matt -- 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
