> Shared using the "shadow regions" in some cases. Does the > DSP software use region 1? I'd hope it does...
Generally speaking each core should use its own unique shadow region. > (Unrelated: why do people call ASP modules "McBSP" modules?? > Just carrying forward obsolete terminology? It's confusing, > and needlessly so...) For years and years TI has put the McBSP on its devices. If you look at the register set inside the ASP and compare it the register set of a McBSP, you'll immediately recognize that it's the same thing -- mostly. The McBSP was originally geared toward telecom applications and so it had a lot of features geared toward TDM communications. That's the "Mc" (multi-channel) in McBSP. In order to make the McBSP a little smaller, and the device a little cheaper, TI ripped out the pieces that were for TDM and renamed the new peripheral the "ASP". So basically the two are identical when it comes to interfacing to an audio codec. I think that in general most of the TIers forget that we actually renamed the peripheral the ASP and so we keep on calling it the McBSP because we've done it for years and years! > > > > 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. 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. > 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). 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. > > 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. > 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 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. Brad _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
