Thanks for the reply, please see below... Regards,
- Rob > -----Original Message----- > From: David Brownell [mailto:davi...@pacbell.net] > Sent: Friday, August 28, 2009 2:37 PM > > On Friday 28 August 2009, Tivy, Robert wrote: > > > > > 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. > > I think the suggestion I made was a lot simpler, and less > error prone. The very *notion* of locking/unlocking things > is asking for trouble. Why expose such a concept when it's > clearly not needed? Perhaps "locking/unlocking" was a poor choice of terminology, but essentially my scheme is the same as your's - transfer a set of unused channels to the "free" list late in the game, after you already have a good idea of specific need. I was just trying to avoid implementation-specific terminology, whereby the current implementation uses wording for the bitmasks such as "reserved" and "no_event". > > Before exploring different solutions ... how about giving my > previous suggestion a fair shake first?? Sure, and to be honest, I didn't much notice your original suggestion, it got "buried" at the end of a back-and-forth discussion about what should go in the static bitmasks, and at that point I was thinking your suggestion was more "static" in nature. In no way did I intend to supercede your suggestion. > > A simple implementation would be just scanning all the > platform devices at some point (say, the first EDMA_ANY > allocation) to construct that mask of "potentially used on > this board" EDMA channels ... making the rest available for > EDMA_ANY usage. Completely transparent to callers, and no > need for SOC-specific hackery. That sounds good, better than having a driver trigger this action explicitly (as per my original suggestion). > > And a fairly trivial thing to implement too ... just a driver > model call to walk the platform_bus devices, then an array > iteration to find the DMA resources. Is this something that can be implemented today, with the current driver model, or would it need some new information to be added to every DMA-using driver? (sorry for asking you to educate me, but I'm just not that familiar with all the driver specifics) > > > > > The > > > LinuxUtils EDMA driver has a strong need for EDMA_ANY type of > > > allocation, to support memory-to-memory transfers by > codecs, mostly. > > My suggestion made many such channels available. > Great. BTW, I've been told that future codecs would want on the order of 50 EDMA_ANY-type channels. > > - Dave > > _______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
