On Monday 05 January 2009, Griffis, Brad wrote: > > > B) Parameter RAMs - Generally speaking a single channel > > > will utilize multiple parameter RAM entries. One of them is > > > the "active" entry and others are utilized as "reload" entries, > > > > Or as termed in this code: "master" and "slave". I think > > that talking about "reload" would be clearer than "slave", > > although the word doesn't peer as cleanly with "master". > > Personally I do not think master/slave captures this function > correctly.
Agreed. But as I noted: these patches aren't correcting API goofage, just scrubbing out some code bloat. > 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. > > 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. > From a branding perspective the Davinci devices are geared > toward video and the OMAP devices are geared toward low > power and/or applications performance. Since OMAP-L1xx > is not geared specifically toward video, but rather toward > low power, TI decided to market the device as an OMAP device. I figured it was something like that. Though it doesn't seem to be quite as low-power a target as OMAP3. > > > Furthermore, some devices actually allow you to map > > > the "active" entry to any channel you want, i.e. it is programmable. > > > > Presumably you're thinking about QDMA "devices" there. > > I don't see that otherwise, on dm355 or dm6446... > > 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. > > Actually, your comments seem to be more on the "why those > > things are in the hardware" side of things... > > Yes, you're right. I know the EDMA3 hardware a heck of a > lot better than I know Linux drivers. :) I got that impression. :) > > I hope I've reassured you somewhat. The hardware capabilities > > can still be accessed, as well as before. It's just that the > > code doing so has had a *LOT* of needless cruft removed. > > Thanks for all your work on the driver (and not just this one!). > I come from the "DSP World" not the Linux world, so my perspective > tends to have a very low-level slant to it. That said, getting > rid of all the unused cruft certainly makes it easier to see > what's going on. It's an important concern for maintaining the code too, and getting it into mainline. Once this is in mainline, several other drivers that rely on DMA (like MMC, ASP) will be usable from mainline kernels. - Dave > > Brad > > _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
