From: David Brownell [mailto:davi...@pacbell.net] Sent: Monday, March 16, 2009 10:57 PM > > On Monday 16 March 2009, Nori, Sekhar wrote: > > > > From: David Brownell > > Sent: Monday, March 16, 2009 1:50 PM > > > On Sunday 15 March 2009, nar...@ti.com wrote: > > > > @@ -167,6 +175,8 @@ enum fifo_width { > > > > enum dma_event_q { > > > > EVENTQ_0 = 0, > > > > EVENTQ_1 = 1, > > > > + EVENTQ_2 = 2, > > > > + EVENTQ_3 = 3, > > > > EVENTQ_DEFAULT = -1 > > > > }; > > > > > > > > > > It'd be good to get rid of that enum entirely ... just use the > > > TC number, except maybe for > > > > > > EVENTQ_HI_PRIORITY ... maybe higher priority than ARM > > > EVENTQ_LO_PRIORITY ... low priority, e.g. for bulk > > > EVENTQ_DEFAULT ... > > > > > > Expecting drivers to deal with TC queues in anything other than > > > generic terms is a losing game; except maybe for SoC-specific > > > code, which should be rare. > > > > Factors like FIFOSIZE may also play role in using a particular TC for > > a particular peripheral (eg. on DM648, TC 2 & 3 are optimized for > > video because of high FIFOSIZE). Not having fine grained control can > > be a problem in such cases. > > The DM648 doesn't include an ARM to run Linux. :)
Yes, wrong example :) But all the DM* SoCs containing ARM do have varying FIFOSIZEs (looks like except DM6467). DM365 has an interesting variation, the FIFO sizes for higher priority TCs is longer - so it has a requirement for high throughput high priority transfers. > > But an ARM leveraging that kind of rig would fall > into the category of SoC-specific code. > I guess I was also thinking of fine grained queue# control because of the number of times we had to play around with event queues being used by drivers to get the codecs + drivers working well together. But looking back most of those are probably related to getting the priorities right so highlighting priority as the choice term should be good. Thanks, Sekhar > > > But agreed that drivers should not be making the choice as the choice > > is not generic. I think TC to be used should be coming from platform > data? > > If it needs that type of optimization. I think most > can just use HI priority (audio, say) or LO/bulk. > (With LO/bulk being the default.) > > Yes, I had thought that video might want more choice > there ... though as I write this, the only drivers to > use EDMA are in sound/soc/davinci and drivers/mmc/host > (at least, in the DaVinci GIT tree) so there aren't > many examples to choose from. Pretty much anything > using DMA without FIFO (like SPI) seems like it should > use HI priority. > > - Dave > > > > > > Thanks, > > Sekhar > > > > > > > > - Dave > > > > > > > > > > > > _______________________________________________ > > > Davinci-linux-open-source mailing list > > > Davinci-linux-open-source@linux.davincidsp.com > > > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > > > > > > _______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
