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?? > 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. > 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? 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. Suggesting a name like EDMA_CHANNEL_HW_UNUSED. 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. - Dave _______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
