> > The more descriptive terms are active/reload. The "active" > > set is the one that the EDMA actually uses for transferring > > data. When the transfer is completed, if the active channel > > specifies a "link" set (i.e. the reload set), then that set > > will be copied over the "active" set. > > Agreed on reload. (Slavery is bad!) > > Not about "active" though. For one thing, they won't > always be active ... they need to be triggered first > (by hardware event, software, or chaining). > > How to present this is a bit of a puzzle. Explaining > the concepts correctly requires not just distinguishing > DMA Channels (64) from PaRAM slots (128), but also the > fact that each channel has a dedicated slot, and the > more subtle point that the contents of those dedicated > slots are updated during transfers.
Hmmm, yes, I see what you mean about "active". I didn't mean "active" as in "currently transferring", but that would be how most people would interpret the term in isolation. I think a more appropriate term would be the "mapped" PSET, because each channel is mapped to a corresponding PSET. So when a transfer is initiated for a given channel the corresponding/mapped PSET is utilized and updated. > > > The OMAP-L1xx chips seem to be DaVinci technology with > > > an OMAP brand, so I'd also think it's worth thinking > > > about how to clean up this DaVinci EDMA code so it can > > > be shared with the OMAP-L1xx support. An obvious step > > > is replacing "davinci" with "edma" in the names. > > > > You're right that OMAP-L1xx is substantially different > > than OMAP35xx and in some ways much closer to the Davinci > > products (e.g. ARM926 core and absence of the PRCM module > > that OMAP35xx contains). > > And using EDMA; and with various other controllers from > the DaVinci family, instead of their OMAP versions. OMAP35xx has both System DMA (SDMA) and EDMA. The EDMA is part of the IVA2.2 module. The IVA subsystem has an MMU between it and the rest of the device so all the EDMA transfers would go through that MMU. > > No, for example in the TMS320C6455 there is a set of registers > > called DCHMAPn that allows you to specify the mapping of > > channel n to a Param Set. Instead of the hard-coded mappings > > of channel 0 to PSET0, channel 1 to PSET1, etc. the DCHMAPn > > registers allows you to map each of the channels to any PSET > > you desire. This feature is also part of the DM648, though > > there is a documentation error that is currently being fixed > > where the register was not documented in the reference guide. > > And all of those are pure DSP chips ... they don't have (public) > Linux ports. Those incarnations of EDMA might of course show > up on chips with an ARM at some point; if they do, the code > can be updated to support this notion at that time. I'm pretty sure future SoC devices will have the mappable channels, though I have no problem with adding that functionality in the future. _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
