> > So why not just fix that "Linuxutils" stuff?? > [Sandeep] That's done by other teams within TI and we want > to re use as much as possible.
Fine, but from what you said, their stuff basically does not work today. So there's nothing to reuse. > If features need to be added it has to be in the EDMA kernel driver And "adding" features means working with that team so everyone agrees on the interface. > > > In DM355 very few channels can be acquired using the EDMA_CHANNEL_ANY > > > and in DM365 0 channels can be acquired with this option. > > > > Right; there are only so many EDMA channels that aren't wired up to any > > hardware, and that's what CHANNEL_ANY provides. > > [Sandeep] NO. I know for DM355 you are referring to pages 36-37 in > http://focus.ti.com/lit/ug/spruee4a/spruee4a.pdf > > which says that channels 12, 13, 24, 56-63 are "reserved". > These do have hardware events associated with them and are > used by the IMCOP in DM355. Sounds like a doc bug to me. It should at least say which channels are used by IMCOP, vs which are free for use by software triggering (or chaining), vs being e.g. broken. > So the name "dma_chan_dm355_no_event" which suggest that > there is no hardware event associated with the channels > (in that structure) is not true. It's as accurate as possible given that doc bug... > Maybe just add a comment what we are trying to achieve > should serve the purpose. There already *is* a description of what CHANNEL_ANY is supposed to deliver... if you're going to redefine those semantics, do it properly. My default assumption is, FWIW, that new semantics need a new EDMA_CHANNEL_* symbol. In this case one might argue that we don't want the old semantics, just the new ones. Which still requires updating the interface spec. > > What's unclear is just why you chose those numbers. I suspect > > the issue is that you just want to avoid channels which are > > (a) used by Linux drivers, and (b) the board uses the relevant > > driver. > [Sandeep] yes > Suggesting a name like EDMA_CHANNEL_HW_UNUSED. > [Sandeep] I don't think this is needed Maybe not. If all devices associated with DMA drivers can be relied on to (i) register by a certain point in the init sequence, and (ii) properly list the DMA channels they use in their platform resources, then it's obviously possible to construct a set of all DMA channels "potentially in use" by drivers on that particular board. And the list of channels available for use with software triggering, or chaining, or whatever this LinuxUtils thing is ... would be the inverse of that set. At that point in the init sequence -- and before drivers are expected to make CHANNEL_<whatever> allocations -- feed the set of "free" channels to the EDMA infrastructure. IMCOP and similar codec drivers would of course need to claim the channels they need; same deal. That would maximize the number of channels available for dynamic use by triggering and chaining. - Dave > > So if for example the UART driver doesn't use EDMA the UART > > channels could be candidates ... as could GPIO banks in most > > cases, and "direct" GPIOs on a more board-specific basis. > [Sandeep] that's correct > > > > - Dave > > > > _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
