Does anyone have any feedback/thoughts on my suggestion below? We at TI need to know, and hopefully have some say in, the availability of EDMA channel allocations.
Regards, - Rob > -----Original Message----- > From: Tivy, Robert > Sent: Wednesday, August 26, 2009 8:25 PM > To: David Brownell; Paulraj, Sandeep > Cc: davinci-linux-open-source@linux.davincidsp.com > Subject: RE: Problem with the current EDMA driver in the > DaVinci GIT kernel > > It seems that arriving at a consensus for reserved channels > isn't going to be easy. > > I'd like to suggest a scheme involving some sort of > driver-controlled unlocking of reserved channels, intended to > be used late in the EDMA acquisition timeline. The > LinuxUtils EDMA driver has a strong need for EDMA_ANY type of > allocation, to support memory-to-memory transfers by codecs, > mostly. It could call a kernel API when it's first > open()'ed, that tells the EDMA driver to transfer all > unallocated reserved channels over to the EDMA_ANY bitmask. > Most EDMA allocations will have already happened at that > point, and even if more fixed-channel request are coming, > there's more than a small chance that it will still be > available (not picked for an EDMA_ANY request). There could > be a "priority" to the EDMA_ANY acquisition, whereby certain > reserved channels are deemed to be more or less likely to be > requested later on, affecting how soon a channel is chosen > for EDMA_ANY. > > There could also be an API for a driver to request that a > certain channel not be allowed to be transferred to the > EDMA_ANY list, or some sort of a notification of future usage. > > It would be nice to also solve the issue of "raw" EDMA usage > through mmap()'ing the EDMA register set and directly writing > registers. Perhaps the /dev/mem driver can intercept these > requests and somehow negotiate or control access to those > registers (I'm just tossing this out there with not much idea > of how to solve it). > > Regards, > > - Rob > > ________________________________________ > From: > davinci-linux-open-source-bounces+rtivy=ti....@linux.davincids > p.com > [davinci-linux-open-source-bounces+rtivy=ti....@linux.davincid > sp.com] On Behalf Of David Brownell [davi...@pacbell.net] > Sent: Wednesday, August 26, 2009 12:00 PM > To: Paulraj, Sandeep > Cc: davinci-linux-open-source@linux.davincidsp.com > Subject: Re: Problem with the current EDMA driver in the > DaVinci GIT kernel > > On Wednesday 26 August 2009, Paulraj, Sandeep wrote: > > > > > > > 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 > > No; that's not maintainable. Each time a new driver starts > to use a channel, someone has to remember to update that > table. That's why it's just a hack. People WILL forget to > update that stuff, and then things WILL break. > > Plus, notice that your static updates won't accomodate > board-specific differences either ... like a board not using > one peripheral, and thereby making its DMA channels available > for other use. > > > > > 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. > > If those components don't say that they use those DMA > channels, then something other than IMCOP will be able to > allocate them... > trouble. So you'd better *find out* how it allocates those > resources, if you're trying to redefine the semantics of the > mechanism you identified. Or at least, you need to make sure > they use the right allocation scheme. > > > > > 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. > > If they want a channel they need to use the allocation calls. > > The "how they use them" is irrelevant ... but if as you said > some of them (IMCOP etc) need *specific* channels, usually > because they're hard-wired to some peripheral but maybe just > because some firmware doesn't understand dynamic allocation, > it's got to request those specific channels. > > The reason to use CHANNEL_ANY is because you don't have a > requirement for a specific channel. > > - Dave > > > > _______________________________________________ > Davinci-linux-open-source mailing list > Davinci-linux-open-source@linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-ope > n-source_______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
