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? Before exploring different solutions ... how about giving my previous suggestion a fair shake first?? 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. 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. > > 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. > > 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). The /dev/mem (and /dev/kmem etc) drivers embed no policy. If you want policy, you'd need to write a new driver. - Dave _______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
