Hi Deepali, On Wed, Aug 11, 2010 at 9:48 AM, Uppal, Deepali <deepali@xxxxxx> wrote: > Hello Ben, > > I am Deepali, DSPLink engineering manager from DSPLink team in TI India. I have removed the linux omap mailing list as my mailing client is not correctly setup to send mails to community. I will respond to the community mailing list later. Thank you for reading and replying. Note to the list: With his permission, I am replying on-list with Deepali's reply in-line. > To answer your questions: > 1) Specifying shared memory for DSPLink does involve setting aside memory for Linux using the mem variable in kernel bootargs. > > 2) DSPLink does not support dynamic linking and loading. All the DSP code must be available in the DSP image loaded at PROC_load API time itself. Thank you for confirming these points. > 3) There are no plans of putting DSPLink (which is currently available into mainstream kernel). However there are plans of putting the next generation of DSPLink for newer generation of devices onto the community. But this may be too late for your needs. However we do support build against the git kernels in the newer versions of DSPLink. This is good news, Deepali. Are there any current DSPLink interfaces that are guaranteed to be stable into the 'next generation' ? You also make a good point that the ARM-side DSPLink component is an out-of-tree kernel module which builds against recent kernels. This is great support for us developers that are using very recent kernels and I think that it is a valuable feature that you have provided with DSPLink. Thanks for that. > Information about DSPLink is available at http://processors.wiki.ti.com/index.php/Category:DSPLink > > DSPLink Webex trainings are at http://processors.wiki.ti.com/index.php/DSPBIOS_LINK_WebEx_Presentations > > To give a brief overview: > DSPLink provides foundation software for the inter-processor communication i.e. IPC across the GPP-DSP boundary. It differs from DSPBridge that it does not provide any framework infrastructure but focuses more on the IPC. It does provide support for Codec Engine which is a codecs management framework which sits on top of DSPLink. I think that Hari Kanigeri points it out in his later post; it sounds like I am trying to compare apples and oranges by comparing dspbrige and DSP Link. Would a more equatable comparison be between Codec Engine + DSP Link vs. dspbridge? > DSPLink provides > * PROC: Boot Loading of DSP It is this feature category where it seems that DSP Link falls short of the features afforded by dspbridge. But I'm started to see that this because DSPLink alone is not intended to be feature complete here. When combined with Code Engine is it possible to get dynamic memory management and dynamic application loading ? > * Inter-Processor Communication protocols > o Complete protocols for different types of data transfer between the processors > o Each protocol meets a different data transfer need > + MSGQ: Message Queue > + CHNL: SIO/streaming based on issue-reclaim model > + RingIO: Circular ring buffer based data streaming > * Inter-Processor Communication building blocks > o Low-level building blocks used by the protocols > o Each building block is also exposed as APIs to allow framework writers to define their own application-specific protocols > + POOL: Memory Manager: shared/non-shared > + NOTIFY: Interrupt abstraction and de-multiplexing for notification of user events > + MPCS: Multi-processor critical section for mutually exclusive access to shared objects > + MPLIST: Multi-processor doubly linked circular list > + PROC_read/PROC_write: Read from or write to DSP memory > > DSPLink is also available on different OS (WinCE and PrOS) and platforms (DM6446, DM6467 etc) combinations. This enables to you port your application to any other platform OS combination seamlessly. DSPLink+Codec Engine is also portable across all recent DaVinci and OMAP platforms correct? This is itself an attractive feature. Best Regards, Ben Gardiner --- Nanometrics Inc. http://www.nanometrics.ca -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
