On Fri, Jan 08, 2010 at 00:59:28, Kevin Hilman wrote: > Kevin Hilman <khil...@deeprootsystems.com> writes: > > > Sudhakar Rajashekhara <sudhakar....@ti.com> writes: > > > >> This patch set corrects some issues with the existing EDMA > >> driver and also adds support for EDMA resource (channel/slots) > >> sharing between two processors (say ARM and DSP). > >> > >> The patch set has been tested on DM646x, OMAP-L137 and OMAP-L138 > >> EVM boards. First 6 patches of this set are same as the previous > >> patches. The last 3 patches are different. > > > > Thanks for the updated comments. > > > > Applying to master and queing for 2.6.34 in davinci-next. > > > > After more discussions on reserving EMDA channels, I'm dropping > patches 5 and 7-9 from the master branch and davinci-next. > > The DSP driver should be allocating channels it expects to > be reserved using existing APIs.
Kevin, I am still not sure if having a notion of resource reservation in EDMA driver is such a bad idea. EDMA as a peripheral is built to be shared across cores and I think the driver should expose some construct to enable resource reservation instead of assuming that it can arbitrate resources for all cores every time. Example, the DA830 is a DSP boot device and there exists a use case where DSP boots simultaneously with the ARM. Here the DSP is not just codecs, but has a bunch of peripheral drivers running on it. Here, dsplink will not be able to play a role. Simultaneous boot-up of DSP is used to achieve fast boot-up and quick power on response. Having DSP control peripherals helps avoid data transfer latency. Thanks, Sekhar PS: The use case above also requires that the kernel be instructed not to re-initialize the EDMA common registers, but that would be another patch. _______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
