Problem with the current EDMA driver in the DaVinci GIT kernel
rtivy at ti.com
Wed Aug 26 22:24:49 CDT 2009
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).
From: davinci-linux-open-source-bounces+rtivy=ti.com at linux.davincidsp.com [davinci-linux-open-source-bounces+rtivy=ti.com at linux.davincidsp.com] On Behalf Of David Brownell [david-b at pacbell.net]
Sent: Wednesday, August 26, 2009 12:00 PM
To: Paulraj, Sandeep
Cc: davinci-linux-open-source at 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.
Davinci-linux-open-source mailing list
Davinci-linux-open-source at linux.davincidsp.com
More information about the Davinci-linux-open-source