> > On Tuesday 25 August 2009, Paulraj, Sandeep wrote: > > Soon TI will support a DVSDK release based on the DaVinci GIT > > kernel for DM355 and DM365. > > > > The entire DVSDK release uses EDAM API's for some resource > > management and to acquire resources(Channels, PARAMS). > > > > But under the current implementation very few channels can be > > acquired by the "Linuxutils" component of the DVSDK which manages > > EDMA resources. > > 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. If features need to be added it has to be in the EDMA kernel driver > > > > 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. 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. Maybe just add a comment what we are trying to achieve should serve the purpose. Or we can rename the struct to "dma_chan_dm355_hw_unused" and make corresponding meaningful changes in the driver to reflect the same. > > > > Thus I propose to use 2 patches > > > > [deleted] > > > > What this will effectively do is to change the meaning of th > > e "dma_chan_dm355_no_event" structure. Other channels do have > > events associated with them but we "intentionally" add them to > > this structure so that it can be acquired by the DVSDK. > > Seems like an especially ugly hack. Why not just define some > new EDMA_CHANNEL_* selector with new semantics? [Sandeep] its not a hack at all > > 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 > > 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 Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
