> Fine, but from what you said, their stuff basically does > not work today. So there's nothing to reuse. [Sandeep] they can re use quite a lot. The APIs need to be changed and they have to take care of the fact that the way we acquire TCC's has chnaged > > > > 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. [Sandeep] that's true > 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. [Sandeep] all 64 channels are available for either hardware events or for us by software triggering
> > > > 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... [Sandeep] that's also true > > > > 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. [Sandeep] I can replace the EDMA_CHANNEL_ANY with EDMA_CHANNEL_HW_UNUSED. IMHO there is no point having another option especially since they will do exactly the same thing, i.e try to acquire channels that are not being used by the kernel drivers. WE can have one of the 2 mentioned but not both. > > > > > 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. [Sandeep] this can also be achieved by updating the structure appropriately as I have done in the patches whose links I had given earlier > > 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. [Sandeep] how the IMCOP deals with its channels is handled by other components of the DVSDK. I am not sure of how exactly it is handled and I don't even know if the IMCOP actually used hardware triggering. > > That would maximize the number of channels available for > dynamic use by triggering and chaining. [Sandeep] basically the objective is to atleast allow all channels not being used by the kernel to be acquired by the linuxutils/DVSDK. How they then use these channels is the responsibility of these other components. > > - 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 > > > > > > > > > - Sandeep _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
