dspbridge and the omapl1x

dspbridge and the omapl1x

[Ben Gardiner]

Hello authors of staging/tidspbridge patches,

We have been watching the progress in staging/dspbridge with great
excitement.  Unfortunately we are using the OMAPL138 which is a
davinci family member which has support for DSPLink not DSPBridge.

We are attracted to DSPBridge over DSPLink because it appears to have
better dynamic resource management and it is headed for mainline
(fingers crossed).

Is omapl1x support part of the roadmap for dspbridge?

Is there anything we can do to help?

Are there interfaces to which we can program that would insulate us
from changes during a future migration from DSPLink to DSPBridge?

Best Regards,
Ben Gardiner

---
Nanometrics Inc.
http://www.nanometrics.ca

Re: dspbridge and the omapl1x

[Hari Kanigeri]

Ben,


> We are attracted to DSPBridge over DSPLink because it appears to have
> better dynamic resource management and it is headed for mainline
> (fingers crossed).

Do you mean dynamic memory management ? Can you please elaborate on
what feature you are referring to ?
>

Thank you,
Best regards,
Hari

Re: dspbridge and the omapl1x

[Ben Gardiner]

Hello Hari,

Thank you for reading and replying to our email.

On Tue, Aug 10, 2010 at 6:12 PM, Hari Kanigeri <hari.kanigeri@gmail.com> wrote:
> Do you mean dynamic memory management ? Can you please elaborate on
> what feature you are referring to ?

Yes, dynamic memory management. With DSP Link on the OMAPL138 the
memory allocated to the DSP must be specified as a 'hole' in Linux
memory at boot-time [1[2][3]. It seems (perhaps this is wishful
thinking) that dspbridge does not have this limitation.

Also dynamic application loading. With DSP Link it is possible to run
multiple linux processes concurrently communicating with DSP tasks but
the image loaded and executed on the DSP side must contain the code
for all of the tasks at load time [4]. It seems that dspbridge does
not have this limitation.

I am very interested in learning details about both dsplink and
dspbridge; please reply with more details or corrections as you see
fit.

Best Regards,
Ben Gardiner

[1] http://processors.wiki.ti.com/index.php/Changing_DSPLink_Memory_Map
[2] http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/t/29571.aspx
[3] http://code.google.com/p/rowboat/wiki/DSP

[4] http://processors.wiki.ti.com/index.php/Using_DSPLink_from_multiple_processes

---
Nanometrics Inc.
http://www.nanometrics.ca

Re: dspbridge and the omapl1x

[Felipe Contreras]

Hi,

On Wed, Aug 11, 2010 at 3:56 PM, Ben Gardiner
<bengardiner@nanometrics.ca> wrote:
> On Tue, Aug 10, 2010 at 6:12 PM, Hari Kanigeri <hari.kanigeri@gmail.com> wrote:
>> Do you mean dynamic memory management ? Can you please elaborate on
>> what feature you are referring to ?
>
> Yes, dynamic memory management. With DSP Link on the OMAPL138 the
> memory allocated to the DSP must be specified as a 'hole' in Linux
> memory at boot-time [1[2][3]. It seems (perhaps this is wishful
> thinking) that dspbridge does not have this limitation.

The dsp-bridge can map scattered user-space pages just fine.

> Also dynamic application loading. With DSP Link it is possible to run
> multiple linux processes concurrently communicating with DSP tasks but
> the image loaded and executed on the DSP side must contain the code
> for all of the tasks at load time [4]. It seems that dspbridge does
> not have this limitation.

Indeed, you can dynamically load socket-nodes.

> I am very interested in learning details about both dsplink and
> dspbridge; please reply with more details or corrections as you see
> fit.

Have you looked into dsp-gateway[1]? The code is very simple and AFAIK
it was close to getting merged upstream, but it's unmaintained
nowadays. It was used on OMAP1 and OMAP2 by Nokia, and shares code
with dsp-bridge, like mailbox and soon iommu. So it might be possible
to port the OMAP1 stuff from dsp-gateway into dsp-bridge.

Cheers.

[1] http://dspgateway.sourceforge.net/pub/index.php

-- 
Felipe Contreras

Re: dspbridge and the omapl1x

[Ben Gardiner]

Hello Felipe,

On Wed, Aug 11, 2010 at 10:01 AM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> Hi,
>
> On Wed, Aug 11, 2010 at 3:56 PM, Ben Gardiner
> <bengardiner@nanometrics.ca> wrote:
>> Yes, dynamic memory management. With DSP Link on the OMAPL138 the
>> memory allocated to the DSP must be specified as a 'hole' in Linux
>> memory at boot-time [1[2][3]. It seems (perhaps this is wishful
>> thinking) that dspbridge does not have this limitation.
>
> The dsp-bridge can map scattered user-space pages just fine.
>
>> Also dynamic application loading. With DSP Link it is possible to run
>> multiple linux processes concurrently communicating with DSP tasks but
>> the image loaded and executed on the DSP side must contain the code
>> for all of the tasks at load time [4]. It seems that dspbridge does
>> not have this limitation.
>
> Indeed, you can dynamically load socket-nodes.

Thank you kindly for the confirmations. It's good to know our
comprehension of the current state of dspbridge is correct.

>> I am very interested in learning details about both dsplink and
>> dspbridge; please reply with more details or corrections as you see
>> fit.
>
> Have you looked into dsp-gateway[1]? The code is very simple and AFAIK
> it was close to getting merged upstream, but it's unmaintained
> nowadays. It was used on OMAP1 and OMAP2 by Nokia, and shares code
> with dsp-bridge, like mailbox and soon iommu. So it might be possible
> to port the OMAP1 stuff from dsp-gateway into dsp-bridge.

That's a good suggestion, thanks. Now that you mention it the OMAP1
and OMAPL1x have similarities other than their names [1]: they both
have ARM9 cores for GPP but the OMAP1 has a C55x where the L1x has a
C67x for DSP. I must admit that I'm not sure how I could extract the
platform specific information from the files made available by the
dspgateway project [2] yet. Nevertheless, I appreciate you pointing
out this similarity and I hope I can make use of it in the future.

Best Regards,
Ben Gardiner

[1] http://en.wikipedia.org/wiki/Texas_Instruments_OMAP
[2] http://sourceforge.net/projects/dspgateway/files/

---
Nanometrics Inc.
http://www.nanometrics.ca

Re: dspbridge and the omapl1x

[Hari Kanigeri]

Ben,

> Yes, dynamic memory management. With DSP Link on the OMAPL138 the
> memory allocated to the DSP must be specified as a 'hole' in Linux
> memory at boot-time [1[2][3]. It seems (perhaps this is wishful
> thinking) that dspbridge does not have this limitation.

DSPBridge doesn't has this requirement.

>
> Also dynamic application loading. With DSP Link it is possible to run
> multiple linux processes concurrently communicating with DSP tasks but
> the image loaded and executed on the DSP side must contain the code
> for all of the tasks at load time [4]. It seems that dspbridge does
> not have this limitation.
>
> I am very interested in learning details about both dsplink and
> dspbridge; please reply with more details or corrections as you see
> fit.

DSPBridge and DSPLink IPCs are for 2 different purposes. So before you
make a switch to one of the IPC, I would recommend to you to make sure
your requirements are met.
To check the differences between DSPBridge and DSPLink, please check
this email thread contributed by Richard W.
http://linux.omap.com/pipermail/linux-omap-open-source/2007-May/009850.html.

We are working on making some of core functionalities such as DMM,
resource Management,  reset Management of co-processors generic for
any IPC to use. So if DSPLink is missing DMM functionality then it
should be just the matter of DSPLink adapting to this.

I am not aware of the official word from T.I to support dspbridge on
OMAP1, but as the community you will have the support in case you want
to go with dspbridge option.

On a high level, this is what needs to be done to provide support for OMAP1.

1. Adapt to iommu. Add support if the support is not present for OMAP1.

2. Adapt to mailbox

3. Reset and Power management adaptation for OMAP1.


Thank you,
Best regards,
Hari

>
> Best Regards,
> Ben Gardiner
>
> [1] http://processors.wiki.ti.com/index.php/Changing_DSPLink_Memory_Map
> [2] http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/t/29571.aspx
> [3] http://code.google.com/p/rowboat/wiki/DSP
>
> [4] http://processors.wiki.ti.com/index.php/Using_DSPLink_from_multiple_processes
>
> ---
> Nanometrics Inc.
> http://www.nanometrics.ca
>

Re: dspbridge and the omapl1x

[Felipe Contreras]

On Wed, Aug 11, 2010 at 7:55 PM, Hari Kanigeri <hari.kanigeri@gmail.com> wrote:
> 1. Adapt to iommu. Add support if the support is not present for OMAP1.

AFAIK iommu started for OMAP1 as it was originally developed for dsp-gateway.

-- 
Felipe Contreras

Re: dspbridge and the omapl1x

[Ben Gardiner]

Hi Deepali,

On Wed, Aug 11, 2010 at 9:48 AM, Uppal, Deepali <deepali@ti.com> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: dspbridge and the omapl1x

[Ben Gardiner]

Hello Hari,

On Wed, Aug 11, 2010 at 12:55 PM, Hari Kanigeri <hari.kanigeri@gmail.com> wrote:
> Ben,
>
>> Yes, dynamic memory management. With DSP Link on the OMAPL138 the
>> memory allocated to the DSP must be specified as a 'hole' in Linux
>> memory at boot-time [1[2][3]. It seems (perhaps this is wishful
>> thinking) that dspbridge does not have this limitation.
>
> DSPBridge doesn't has this requirement.

Thank you for confirming.

>> Also dynamic application loading. With DSP Link it is possible to run
>> multiple linux processes concurrently communicating with DSP tasks but
>> the image loaded and executed on the DSP side must contain the code
>> for all of the tasks at load time [4]. It seems that dspbridge does
>> not have this limitation.
>>
>> I am very interested in learning details about both dsplink and
>> dspbridge; please reply with more details or corrections as you see
>> fit.
>
> DSPBridge and DSPLink IPCs are for 2 different purposes. So before you
> make a switch to one of the IPC, I would recommend to you to make sure
> your requirements are met.
> To check the differences between DSPBridge and DSPLink, please check
> this email thread contributed by Richard W.
> http://linux.omap.com/pipermail/linux-omap-open-source/2007-May/009850.html.

Good point. Thank you for making that clear to me. And for the link to
the post, I'm regret that I missed that in my initial research. I'm
starting to think that maybe a direct comparison between DSPLink and
dspbridge is not a fair one.

> We are working on making some of core functionalities such as DMM,
> resource Management,  reset Management of co-processors generic for
> any IPC to use. So if DSPLink is missing DMM functionality then it
> should be just the matter of DSPLink adapting to this.

I don't get what you're trying to say here, sorry. Would DSPLink be
one of the IPCs for which the 'core functionalities' could be adapted?
Could you explain an example of how DMM being made generic for any IPC
to use could be applied to DSPLink?

> I am not aware of the official word from T.I to support dspbridge on
> OMAP1, but as the community you will have the support in case you want
> to go with dspbridge option.
>
> On a high level, this is what needs to be done to provide support for OMAP1.
>
> 1. Adapt to iommu. Add support if the support is not present for OMAP1.
>
> 2. Adapt to mailbox
>
> 3. Reset and Power management adaptation for OMAP1.

Thanks for the roadmap. This doesn't sound too daunting, but that
could be because I am ignorant of the details. :)

It is good to know that the community (at least you) would be
interested in reviewing and picking up patches that integrate
dspbridge support for the omapl1x.

I'm still not sure about the iommu features required by dspbridge, I
will need to look into this. But 2+3 sound like they could be provided
by DSPLink itself. Would it be sane to put dspbridge on top of
DSPLink? Just to sound it out, the DSP-side base image could be
DSPBios + DSPLink (DSP-side) and the ARM-side would be made of
dspbridge where the IPC is DSP Link 'compatible'. This could avoid a
rewrite of the DSP-side of dspbridge maybe?

All crazy ideas aside. We are very pleased with all the help you
(Hari), Felipe and Deepali have offered us in trying to understand
dspbridge and its relationship to DSP Link. Many thanks again and we
look forward to any more insights you have to offer.

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: dspbridge and the omapl1x

[Hari Kanigeri]

Ben,

On Wed, Aug 11, 2010 at 2:25 PM, Ben Gardiner
<bengardiner@nanometrics.ca> wrote:
> Hello Hari,
>
> On Wed, Aug 11, 2010 at 12:55 PM, Hari Kanigeri <hari.kanigeri@gmail.com> wrote:
>> Ben,
>>
>>> Yes, dynamic memory management. With DSP Link on the OMAPL138 the
>>> memory allocated to the DSP must be specified as a 'hole' in Linux
>>> memory at boot-time [1[2][3]. It seems (perhaps this is wishful
>>> thinking) that dspbridge does not have this limitation.
>>
>> DSPBridge doesn't has this requirement.
>
> Thank you for confirming.
>
>>> Also dynamic application loading. With DSP Link it is possible to run
>>> multiple linux processes concurrently communicating with DSP tasks but
>>> the image loaded and executed on the DSP side must contain the code
>>> for all of the tasks at load time [4]. It seems that dspbridge does
>>> not have this limitation.
>>>
>>> I am very interested in learning details about both dsplink and
>>> dspbridge; please reply with more details or corrections as you see
>>> fit.
>>
>> DSPBridge and DSPLink IPCs are for 2 different purposes. So before you
>> make a switch to one of the IPC, I would recommend to you to make sure
>> your requirements are met.
>> To check the differences between DSPBridge and DSPLink, please check
>> this email thread contributed by Richard W.
>> http://linux.omap.com/pipermail/linux-omap-open-source/2007-May/009850.html.
>
> Good point. Thank you for making that clear to me. And for the link to
> the post, I'm regret that I missed that in my initial research.

No problem.

> I'm
> starting to think that maybe a direct comparison between DSPLink and
> dspbridge is not a fair one.
>
Yes, as you mentioned in your earlier email it's not Apples to Apples
comparison.

>> We are working on making some of core functionalities such as DMM,
>> resource Management,  reset Management of co-processors generic for
>> any IPC to use. So if DSPLink is missing DMM functionality then it
>> should be just the matter of DSPLink adapting to this.
>
> I don't get what you're trying to say here, sorry. Would DSPLink be
> one of the IPCs for which the 'core functionalities' could be adapted?

May be let's re-visit this point when the RFC is send on my above
mentioned features.

> Could you explain an example of how DMM being made generic for any IPC
> to use could be applied to DSPLink?

Basically today the Dynamic memory management is handled by DSPBridge.
So the userspace clients talk to DSPBridge, and DSPBridge in turn
talks to IOMMU to map the user passed Buffers. DSPBridge is managing
the virtual address space of DSP in this case.
So basically where we are going is replacing DSPBridge's DMM module
with a generic Kernel module that can handle the DMM for any given
number of Co-Processors. OMAP3 has only Co-Processor, where as OMAP4
has 2 Co-Processors. The solution should be generic to handle any
number of Devices.
I will try to send an RFC of this implementation and I would love to
get feedback from you.

In case if you want to get some information on how the Dynamic memory
mapping works, you can refer pages 12-15 of this presentation
https://gforge.ti.com/gf/download/docmanfileversion/17/674/OMAP3430_Bridge_overview.pdf

>
>> I am not aware of the official word from T.I to support dspbridge on
>> OMAP1, but as the community you will have the support in case you want
>> to go with dspbridge option.
>>
>> On a high level, this is what needs to be done to provide support for OMAP1.
>>
>> 1. Adapt to iommu. Add support if the support is not present for OMAP1.
>>
>> 2. Adapt to mailbox
>>
>> 3. Reset and Power management adaptation for OMAP1.
>
> Thanks for the roadmap. This doesn't sound too daunting, but that
> could be because I am ignorant of the details. :)

I forgot to add item 4. "Surprises" :)


>
> I'm still not sure about the iommu features required by dspbridge, I
> will need to look into this. But 2+3 sound like they could be provided
> by DSPLink itself. Would it be sane to put dspbridge on top of
> DSPLink? Just to sound it out, the DSP-side base image could be
> DSPBios + DSPLink (DSP-side) and the ARM-side would be made of
> dspbridge where the IPC is DSP Link 'compatible'. This could avoid a
> rewrite of the DSP-side of dspbridge maybe?

Probably over-kill to get the features you want.

>

Thank youi,
Best regards,
Hari
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: dspbridge and the omapl1x

[Kamoolkar, Mugdha]

Ben,

One thing I would like to mention is that the DMM feature does require the slave DSP to have an MMU. The OMAPL1xx devices do not have MMU for the DSP. DMM cannot be implemented without the DSP having an MMU. Hence, even if you ported DSPBridge to OMAPL1xx devices, you could not make use of the DMM feature.

However, you are correct that dynamic linking and loading is a feature that is available in DSPBridge, and which is missing in DSPLink, which could work on OMAPL1xx if you ported DSPBridge to OMAPL1xx

Regards,
Mugdha
 
> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Hari Kanigeri
> Sent: Thursday, August 12, 2010 5:06 AM
> To: Ben Gardiner
> Cc: Ramos Falcon, Ernesto; Uribe de Leon, Armando; Menon, Nishanth;
> KulikovVasiliy; Sapiens, Rene; AndyShevchenko; FelipeContreras; Ramirez
> Luna, Omar; OhadBen-Cohen; linux-omap@vger.kernel.org; Uppal, Deepali
> Subject: Re: dspbridge and the omapl1x
> 
> Ben,
> 
> On Wed, Aug 11, 2010 at 2:25 PM, Ben Gardiner
> <bengardiner@nanometrics.ca> wrote:
> > Hello Hari,
> >
> > On Wed, Aug 11, 2010 at 12:55 PM, Hari Kanigeri
> <hari.kanigeri@gmail.com> wrote:
> >> Ben,
> >>
> >>> Yes, dynamic memory management. With DSP Link on the OMAPL138 the
> >>> memory allocated to the DSP must be specified as a 'hole' in Linux
> >>> memory at boot-time [1[2][3]. It seems (perhaps this is wishful
> >>> thinking) that dspbridge does not have this limitation.
> >>
> >> DSPBridge doesn't has this requirement.
> >
> > Thank you for confirming.
> >
> >>> Also dynamic application loading. With DSP Link it is possible to run
> >>> multiple linux processes concurrently communicating with DSP tasks but
> >>> the image loaded and executed on the DSP side must contain the code
> >>> for all of the tasks at load time [4]. It seems that dspbridge does
> >>> not have this limitation.
> >>>
> >>> I am very interested in learning details about both dsplink and
> >>> dspbridge; please reply with more details or corrections as you see
> >>> fit.
> >>
> >> DSPBridge and DSPLink IPCs are for 2 different purposes. So before you
> >> make a switch to one of the IPC, I would recommend to you to make sure
> >> your requirements are met.
> >> To check the differences between DSPBridge and DSPLink, please check
> >> this email thread contributed by Richard W.
> >> http://linux.omap.com/pipermail/linux-omap-open-source/2007-
> May/009850.html.
> >
> > Good point. Thank you for making that clear to me. And for the link to
> > the post, I'm regret that I missed that in my initial research.
> 
> No problem.
> 
> > I'm
> > starting to think that maybe a direct comparison between DSPLink and
> > dspbridge is not a fair one.
> >
> Yes, as you mentioned in your earlier email it's not Apples to Apples
> comparison.
> 
> >> We are working on making some of core functionalities such as DMM,
> >> resource Management,  reset Management of co-processors generic for
> >> any IPC to use. So if DSPLink is missing DMM functionality then it
> >> should be just the matter of DSPLink adapting to this.
> >
> > I don't get what you're trying to say here, sorry. Would DSPLink be
> > one of the IPCs for which the 'core functionalities' could be adapted?
> 
> May be let's re-visit this point when the RFC is send on my above
> mentioned features.
> 
> > Could you explain an example of how DMM being made generic for any IPC
> > to use could be applied to DSPLink?
> 
> Basically today the Dynamic memory management is handled by DSPBridge.
> So the userspace clients talk to DSPBridge, and DSPBridge in turn
> talks to IOMMU to map the user passed Buffers. DSPBridge is managing
> the virtual address space of DSP in this case.
> So basically where we are going is replacing DSPBridge's DMM module
> with a generic Kernel module that can handle the DMM for any given
> number of Co-Processors. OMAP3 has only Co-Processor, where as OMAP4
> has 2 Co-Processors. The solution should be generic to handle any
> number of Devices.
> I will try to send an RFC of this implementation and I would love to
> get feedback from you.
> 
> In case if you want to get some information on how the Dynamic memory
> mapping works, you can refer pages 12-15 of this presentation
> https://gforge.ti.com/gf/download/docmanfileversion/17/674/OMAP3430_Bridge
> _overview.pdf
> 
> >
> >> I am not aware of the official word from T.I to support dspbridge on
> >> OMAP1, but as the community you will have the support in case you want
> >> to go with dspbridge option.
> >>
> >> On a high level, this is what needs to be done to provide support for
> OMAP1.
> >>
> >> 1. Adapt to iommu. Add support if the support is not present for OMAP1.
> >>
> >> 2. Adapt to mailbox
> >>
> >> 3. Reset and Power management adaptation for OMAP1.
> >
> > Thanks for the roadmap. This doesn't sound too daunting, but that
> > could be because I am ignorant of the details. :)
> 
> I forgot to add item 4. "Surprises" :)
> 
> 
> >
> > I'm still not sure about the iommu features required by dspbridge, I
> > will need to look into this. But 2+3 sound like they could be provided
> > by DSPLink itself. Would it be sane to put dspbridge on top of
> > DSPLink? Just to sound it out, the DSP-side base image could be
> > DSPBios + DSPLink (DSP-side) and the ARM-side would be made of
> > dspbridge where the IPC is DSP Link 'compatible'. This could avoid a
> > rewrite of the DSP-side of dspbridge maybe?
> 
> Probably over-kill to get the features you want.
> 
> >
> 
> Thank youi,
> Best regards,
> Hari
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: dspbridge and the omapl1x

[Felipe Balbi]

Hi,

On Thu, Aug 12, 2010 at 08:00:05AM +0200, ext Kamoolkar, Mugdha wrote:
>One thing I would like to mention is that the DMM feature does require 
>the slave DSP to have an MMU. The OMAPL1xx devices do not have MMU for 
>the DSP. DMM cannot be implemented without the DSP having an MMU. 
>Hence, even if you ported DSPBridge to OMAPL1xx devices, you could not 
>make use of the DMM feature.
>
>However, you are correct that dynamic linking and loading is a feature 
>that is available in DSPBridge, and which is missing in DSPLink, which 
>could work on OMAPL1xx if you ported DSPBridge to OMAPL1xx

please follow the Netiquette [1]. It's really difficult to follow 
dspbridge threads.

[1] http://www.elinux.org/Netiquette

-- 
balbi

DefectiveByDesign.org

RE: dspbridge and the omapl1x

[Kamoolkar, Mugdha]

Felipe,

> -----Original Message-----
> From: Felipe Balbi [mailto:felipe.balbi@nokia.com]
> Sent: Thursday, August 12, 2010 11:33 AM
> To: Kamoolkar, Mugdha
> Cc: Hari Kanigeri; Ben Gardiner; Ramos Falcon, Ernesto; Uribe de Leon,
> Armando; Menon, Nishanth; KulikovVasiliy; Sapiens, Rene; AndyShevchenko;
> FelipeContreras; Ramirez Luna, Omar; OhadBen-Cohen; linux-
> omap@vger.kernel.org; Uppal, Deepali
> Subject: Re: dspbridge and the omapl1x
> 
> Hi,
> 
> On Thu, Aug 12, 2010 at 08:00:05AM +0200, ext Kamoolkar, Mugdha wrote:
> >One thing I would like to mention is that the DMM feature does require
> >the slave DSP to have an MMU. The OMAPL1xx devices do not have MMU for
> >the DSP. DMM cannot be implemented without the DSP having an MMU.
> >Hence, even if you ported DSPBridge to OMAPL1xx devices, you could not
> >make use of the DMM feature.
> >
> >However, you are correct that dynamic linking and loading is a feature
> >that is available in DSPBridge, and which is missing in DSPLink, which
> >could work on OMAPL1xx if you ported DSPBridge to OMAPL1xx
> 
> please follow the Netiquette [1]. It's really difficult to follow
> dspbridge threads.
> 
> [1] http://www.elinux.org/Netiquette
> 

Thanks! Live and learn ...

> --
> balbi
> 
> DefectiveByDesign.org

Regards,
Mugdha

RE: dspbridge and the omapl1x

[Kamoolkar, Mugdha]

Ben,

Re-replying with Netiquette ... I apologize for my earlier e-mail.

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Hari Kanigeri
> Sent: Thursday, August 12, 2010 5:06 AM
> To: Ben Gardiner
> Cc: Ramos Falcon, Ernesto; Uribe de Leon, Armando; Menon, Nishanth;
> KulikovVasiliy; Sapiens, Rene; AndyShevchenko; FelipeContreras; Ramirez
> Luna, Omar; OhadBen-Cohen; linux-omap@vger.kernel.org; Uppal, Deepali
> Subject: Re: dspbridge and the omapl1x
> 
> Ben,
> 
> On Wed, Aug 11, 2010 at 2:25 PM, Ben Gardiner
> <bengardiner@nanometrics.ca> wrote:
> > Hello Hari,
> >
> > On Wed, Aug 11, 2010 at 12:55 PM, Hari Kanigeri
> <hari.kanigeri@gmail.com> wrote:
> >> Ben,
> >>
> >>> Yes, dynamic memory management. With DSP Link on the OMAPL138 the
> >>> memory allocated to the DSP must be specified as a 'hole' in Linux
> >>> memory at boot-time [1[2][3]. It seems (perhaps this is wishful
> >>> thinking) that dspbridge does not have this limitation.
> >>
> >> DSPBridge doesn't has this requirement.
> >
> > Thank you for confirming.
One thing I would like to mention is that the DMM feature does require the slave DSP to have an MMU. The OMAPL1xx devices do not have MMU for the DSP. DMM cannot be implemented without the DSP having an MMU. Hence, even if you ported DSPBridge to OMAPL1xx devices, you could not make use of the DMM feature.
> >
> >>> Also dynamic application loading. With DSP Link it is possible to run
> >>> multiple linux processes concurrently communicating with DSP tasks but
> >>> the image loaded and executed on the DSP side must contain the code
> >>> for all of the tasks at load time [4]. It seems that dspbridge does
> >>> not have this limitation.
You are correct that dynamic linking and loading is a feature that is available in DSPBridge, and which is missing in DSPLink, which could work on OMAPL1xx if you ported DSPBridge to OMAPL1xx
> >>>
> >>> I am very interested in learning details about both dsplink and
> >>> dspbridge; please reply with more details or corrections as you see
> >>> fit.
> >>
> >> DSPBridge and DSPLink IPCs are for 2 different purposes. So before you
> >> make a switch to one of the IPC, I would recommend to you to make sure
> >> your requirements are met.
> >> To check the differences between DSPBridge and DSPLink, please check
> >> this email thread contributed by Richard W.
> >> http://linux.omap.com/pipermail/linux-omap-open-source/2007-
> May/009850.html.
> >
> > Good point. Thank you for making that clear to me. And for the link to
> > the post, I'm regret that I missed that in my initial research.
> 
> No problem.
> 
> > I'm
> > starting to think that maybe a direct comparison between DSPLink and
> > dspbridge is not a fair one.
> >
> Yes, as you mentioned in your earlier email it's not Apples to Apples
> comparison.
> 
> >> We are working on making some of core functionalities such as DMM,
> >> resource Management,  reset Management of co-processors generic for
> >> any IPC to use. So if DSPLink is missing DMM functionality then it
> >> should be just the matter of DSPLink adapting to this.
> >
> > I don't get what you're trying to say here, sorry. Would DSPLink be
> > one of the IPCs for which the 'core functionalities' could be adapted?
> 
> May be let's re-visit this point when the RFC is send on my above
> mentioned features.
> 
> > Could you explain an example of how DMM being made generic for any IPC
> > to use could be applied to DSPLink?
> 
> Basically today the Dynamic memory management is handled by DSPBridge.
> So the userspace clients talk to DSPBridge, and DSPBridge in turn
> talks to IOMMU to map the user passed Buffers. DSPBridge is managing
> the virtual address space of DSP in this case.
> So basically where we are going is replacing DSPBridge's DMM module
> with a generic Kernel module that can handle the DMM for any given
> number of Co-Processors. OMAP3 has only Co-Processor, where as OMAP4
> has 2 Co-Processors. The solution should be generic to handle any
> number of Devices.
> I will try to send an RFC of this implementation and I would love to
> get feedback from you.
> 
> In case if you want to get some information on how the Dynamic memory
> mapping works, you can refer pages 12-15 of this presentation
> https://gforge.ti.com/gf/download/docmanfileversion/17/674/OMAP3430_Bridge
> _overview.pdf
> 
> >
> >> I am not aware of the official word from T.I to support dspbridge on
> >> OMAP1, but as the community you will have the support in case you want
> >> to go with dspbridge option.
> >>
> >> On a high level, this is what needs to be done to provide support for
> OMAP1.
> >>
> >> 1. Adapt to iommu. Add support if the support is not present for OMAP1.
> >>
> >> 2. Adapt to mailbox
> >>
> >> 3. Reset and Power management adaptation for OMAP1.
> >
> > Thanks for the roadmap. This doesn't sound too daunting, but that
> > could be because I am ignorant of the details. :)
> 
> I forgot to add item 4. "Surprises" :)
> 
> 
> >
> > I'm still not sure about the iommu features required by dspbridge, I
> > will need to look into this. But 2+3 sound like they could be provided
> > by DSPLink itself. Would it be sane to put dspbridge on top of
> > DSPLink? Just to sound it out, the DSP-side base image could be
> > DSPBios + DSPLink (DSP-side) and the ARM-side would be made of
> > dspbridge where the IPC is DSP Link 'compatible'. This could avoid a
> > rewrite of the DSP-side of dspbridge maybe?
> 
> Probably over-kill to get the features you want.
iommu could not be adapted for OMAPL1xx since it abstracts the DSP MMU, which is non-existent on OMAPL1xx devices.

Also, OMAPL1xx devices do not use mailbox interrupts. They have a different type of IPC interrupt, which is not mailbox. So a different kind of abstraction would be required to be able to use either mailbox or this different IPC interrupt.

> 
> >
> 
> Thank youi,
> Best regards,
> Hari
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Regards,
Mugdha
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: dspbridge and the omapl1x

[Felipe Balbi]

Hi,

On Thu, Aug 12, 2010 at 08:16:23AM +0200, ext Kamoolkar, Mugdha wrote:
>One thing I would like to mention is that the DMM feature does require 
>the slave DSP to have an MMU. The OMAPL1xx devices do not have MMU for 
>the DSP. DMM cannot be implemented without the DSP having an MMU. 
>Hence, even if you ported DSPBridge to OMAPL1xx devices, you could not 
>make use of the DMM feature.

your lines are still too wide. Tell your mailer to break them on 80 
characters.

-- 
balbi

DefectiveByDesign.org

Re: dspbridge and the omapl1x

[Hari Kanigeri]

Mugdha,

On Thu, Aug 12, 2010 at 1:16 AM, Kamoolkar, Mugdha <mugdha@ti.com> wrote:
> Ben,
>
>>
>>
>> >
>> > I'm still not sure about the iommu features required by dspbridge, I
>> > will need to look into this. But 2+3 sound like they could be provided
>> > by DSPLink itself. Would it be sane to put dspbridge on top of
>> > DSPLink? Just to sound it out, the DSP-side base image could be
>> > DSPBios + DSPLink (DSP-side) and the ARM-side would be made of
>> > dspbridge where the IPC is DSP Link 'compatible'. This could avoid a
>> > rewrite of the DSP-side of dspbridge maybe?
>>
>> Probably over-kill to get the features you want.
> iommu could not be adapted for OMAPL1xx since it abstracts the DSP MMU, which is non-existent on OMAPL1xx devices.
>
> Also, OMAPL1xx devices do not use mailbox interrupts. They have a different type of IPC interrupt, which is not mailbox. So a different kind of abstraction would be required to be able to use either mailbox or this different IPC interrupt.

Thanks for providing information on OMAPL1xx devices. I wasn't aware
of OMAP1 architecture.

Thank you,
Best regards,
Hari

Re: dspbridge and the omapl1x

[Ben Gardiner]

Hari and Mugdha,

On Wed, Aug 11, 2010 at 7:35 PM, Hari Kanigeri <hari.kanigeri@gmail.com> wrote:
> On Wed, Aug 11, 2010 at 2:25 PM, Ben Gardiner
> <bengardiner@nanometrics.ca> wrote:
>> On Wed, Aug 11, 2010 at 12:55 PM, Hari Kanigeri <hari.kanigeri@gmail.com> wrote:
>>> We are working on making some of core functionalities such as DMM,
>>> resource Management,  reset Management of co-processors generic for
>>> any IPC to use. So if DSPLink is missing DMM functionality then it
>>> should be just the matter of DSPLink adapting to this.
>>
>> I don't get what you're trying to say here, sorry. Would DSPLink be
>> one of the IPCs for which the 'core functionalities' could be adapted?
>
> May be let's re-visit this point when the RFC is send on my above
> mentioned features.
>
>> Could you explain an example of how DMM being made generic for any IPC
>> to use could be applied to DSPLink?
>
> Basically today the Dynamic memory management is handled by DSPBridge.
> So the userspace clients talk to DSPBridge, and DSPBridge in turn
> talks to IOMMU to map the user passed Buffers. DSPBridge is managing
> the virtual address space of DSP in this case.
> So basically where we are going is replacing DSPBridge's DMM module
> with a generic Kernel module that can handle the DMM for any given
> number of Co-Processors. OMAP3 has only Co-Processor, where as OMAP4
> has 2 Co-Processors. The solution should be generic to handle any
> number of Devices.
> I will try to send an RFC of this implementation and I would love to
> get feedback from you.

I would be happy to review the RFC.

> In case if you want to get some information on how the Dynamic memory
> mapping works, you can refer pages 12-15 of this presentation
> https://gforge.ti.com/gf/download/docmanfileversion/17/674/OMAP3430_Bridge_overview.pdf

Thank you for the link; the diagram on page 13 was most helpful in
solidifying my understanding of the IOMMU to which your are referring
in your explanation of DMM above and in the roadmap below.

>>> On a high level, this is what needs to be done to provide support for OMAP1.
>>>
>>> 1. Adapt to iommu. Add support if the support is not present for OMAP1.

Gulp. This could be a problem. Thanks to your link above I now
understand that the iommu which is controlled by dspbridge and
facilitates the use by the DSP of scattered pages allocated on the ARM
side is an MMU _separate_ from that of the ARM.

The OMAP3430 obviously has an MMU for the DSP Side [1] but I can't
find any documentation indicating that the OMAP L138 has a DSP-side
MMU.

On Thu, Aug 12, 2010 at 2:16 AM, Kamoolkar, Mugdha <mugdha@ti.com> wrote:
> One thing I would like to mention is that the DMM feature does require the slave DSP to have an MMU. The OMAPL1xx devices do not have MMU for the DSP. DMM cannot be implemented without the DSP having an MMU. Hence, even if you ported DSPBridge to OMAPL1xx devices, you could not make use of the DMM feature.

 Thank you, Mugdha, for reading my mind and confirming that there is
no MMU on the omapL1x -- I saved a draft of this email last night and
was going to do some more research to confirm myself but you saved me
the trouble.

On Thu, Aug 12, 2010 at 2:16 AM, Kamoolkar, Mugdha <mugdha@ti.com> wrote:
> You are correct that dynamic linking and loading is a feature that is available in DSPBridge, and which is missing in DSPLink, which could work on OMAPL1xx if you ported DSPBridge to OMAPL1xx

I imagined that the lack of MMU would be a blocker in porting
dspbridge since it would be impossible to support scattered (in PAs)
pages on the DSP-side. But Mugdha makes it sound like the port could
be accomplished with DMM omitted.

Also I believe that the new Contiguous Memory Allocation (CMA)
framework was developed specifically for systems that need to allocate
physically contiguous memory because they don't have an MMU. What
would say to avoiding the IOMMU requirement and keeping DMM by using
physically contiguous dynamically allocated memory regions like those
provided by the new CMA [2]?

On Wed, Aug 11, 2010 at 7:35 PM, Hari Kanigeri <hari.kanigeri@gmail.com> wrote:
>>> 2. Adapt to mailbox
On Thu, Aug 12, 2010 at 2:16 AM, Kamoolkar, Mugdha <mugdha@ti.com> wrote:
> Also, OMAPL1xx devices do not use mailbox interrupts. They have a different type of IPC interrupt, which is not mailbox. So a different kind of abstraction would be required to be able to use either mailbox or this different IPC interrupt.

Good point. I believe that currently it is DSPLink which provides a
mailbox implemented on top of the available IPC interrupt on the L13x.
If re-using DSPLink in the dspbridge's baseimage is still overkill
then we at least have code in DSPLink from which to base the
standalone driver code.

On Wed, Aug 11, 2010 at 7:35 PM, Hari Kanigeri <hari.kanigeri@gmail.com> wrote:
>>> 3. Reset and Power management adaptation for OMAP1.
>>
>> Thanks for the roadmap. This doesn't sound too daunting, but that
>> could be because I am ignorant of the details. :)
>
> I forgot to add item 4. "Surprises" :)

:) I think we ran into a big one.

Best Regards,
Ben Gardiner

[1] http://www.ti.com/litv/pdf/sprufn0a
[2] http://mid.gmane.org/cover.1281100495.git.m.nazarewicz@samsung.com
---
Nanometrics Inc.
http://www.nanometrics.ca





>> >>>
>> >>> I am very interested in learning details about both dsplink and
>> >>> dspbridge; please reply with more details or corrections as you see
>> >>> fit.
>> >>
>> >> DSPBridge and DSPLink IPCs are for 2 different purposes. So before you
>> >> make a switch to one of the IPC, I would recommend to you to make sure
>> >> your requirements are met.
>> >> To check the differences between DSPBridge and DSPLink, please check
>> >> this email thread contributed by Richard W.
>> >> http://linux.omap.com/pipermail/linux-omap-open-source/2007-
>> May/009850.html.
>> >
>> > Good point. Thank you for making that clear to me. And for the link to
>> > the post, I'm regret that I missed that in my initial research.
>>
>> No problem.
>>
>> > I'm
>> > starting to think that maybe a direct comparison between DSPLink and
>> > dspbridge is not a fair one.
>> >
>> Yes, as you mentioned in your earlier email it's not Apples to Apples
>> comparison.
>>
>> >> We are working on making some of core functionalities such as DMM,
>> >> resource Management,  reset Management of co-processors generic for
>> >> any IPC to use. So if DSPLink is missing DMM functionality then it
>> >> should be just the matter of DSPLink adapting to this.
>> >
>> > I don't get what you're trying to say here, sorry. Would DSPLink be
>> > one of the IPCs for which the 'core functionalities' could be adapted?
>>
>> May be let's re-visit this point when the RFC is send on my above
>> mentioned features.
>>
>> > Could you explain an example of how DMM being made generic for any IPC
>> > to use could be applied to DSPLink?
>>
>> Basically today the Dynamic memory management is handled by DSPBridge.
>> So the userspace clients talk to DSPBridge, and DSPBridge in turn
>> talks to IOMMU to map the user passed Buffers. DSPBridge is managing
>> the virtual address space of DSP in this case.
>> So basically where we are going is replacing DSPBridge's DMM module
>> with a generic Kernel module that can handle the DMM for any given
>> number of Co-Processors. OMAP3 has only Co-Processor, where as OMAP4
>> has 2 Co-Processors. The solution should be generic to handle any
>> number of Devices.
>> I will try to send an RFC of this implementation and I would love to
>> get feedback from you.
>>
>> In case if you want to get some information on how the Dynamic memory
>> mapping works, you can refer pages 12-15 of this presentation
>> https://gforge.ti.com/gf/download/docmanfileversion/17/674/OMAP3430_Bridge
>> _overview.pdf
>>
>> >
>> >> I am not aware of the official word from T.I to support dspbridge on
>> >> OMAP1, but as the community you will have the support in case you want
>> >> to go with dspbridge option.
>> >>
>> >> On a high level, this is what needs to be done to provide support for
>> OMAP1.
>> >>
>> >> 1. Adapt to iommu. Add support if the support is not present for OMAP1.
>> >>
>> >> 2. Adapt to mailbox
>> >>
>> >> 3. Reset and Power management adaptation for OMAP1.
>> >
>> > Thanks for the roadmap. This doesn't sound too daunting, but that
>> > could be because I am ignorant of the details. :)
>>
>> I forgot to add item 4. "Surprises" :)
>>
>>
>> >
>> > I'm still not sure about the iommu features required by dspbridge, I
>> > will need to look into this. But 2+3 sound like they could be provided
>> > by DSPLink itself. Would it be sane to put dspbridge on top of
>> > DSPLink? Just to sound it out, the DSP-side base image could be
>> > DSPBios + DSPLink (DSP-side) and the ARM-side would be made of
>> > dspbridge where the IPC is DSP Link 'compatible'. This could avoid a
>> > rewrite of the DSP-side of dspbridge maybe?
>>
>> Probably over-kill to get the features you want.

>
>>
>> >
>>
>> Thank youi,
>> Best regards,
>> Hari
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
> Regards,
> Mugdha
>



-- 
Best Regards,
Ben Gardiner

---
Nanometrics Inc.
+1 (613) 592-6776 x239
http://www.nanometrics.ca
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: dspbridge and the omapl1x

[Hari Kanigeri]

> On Thu, Aug 12, 2010 at 2:16 AM, Kamoolkar, Mugdha <mugdha@ti.com> wrote:
>> You are correct that dynamic linking and loading is a feature that is available in DSPBridge, and which is missing in DSPLink, which could work on OMAPL1xx if you ported DSPBridge to OMAPL1xx
>
> I imagined that the lack of MMU would be a blocker in porting
> dspbridge since it would be impossible to support scattered (in PAs)
> pages on the DSP-side. But Mugdha makes it sound like the port could
> be accomplished with DMM omitted.
>
> Also I believe that the new Contiguous Memory Allocation (CMA)
> framework was developed specifically for systems that need to allocate
> physically contiguous memory because they don't have an MMU. What
> would say to avoiding the IOMMU requirement and keeping DMM by using
> physically contiguous dynamically allocated memory regions like those
> provided by the new CMA [2]?
>

Just curious as how CMA is different from Android's pmem.

>

Thank you,
Best regards,
Hari

Re: dspbridge and the omapl1x

[Ben Gardiner]

On Thu, Aug 12, 2010 at 8:28 PM, Hari Kanigeri <hari.kanigeri@gmail.com> wrote:
>> Also I believe that the new Contiguous Memory Allocation (CMA)
>> framework was developed specifically for systems that need to allocate
>> physically contiguous memory because they don't have an MMU. What
(edit) "... because they don't have an _IO_MMU."

>> would say to avoiding the IOMMU requirement and keeping DMM by using
>> physically contiguous dynamically allocated memory regions like those
>> provided by the new CMA [2]?
>>
>
> Just curious as how CMA is different from Android's pmem.

I'm not really sure, but based on the discussion in one of the pmem
patches proposed on lkml [1] they seem to provide similar
functionality.

Perhaps the difference is that pmem has made it to staging whereas CMA
is only a proposed feature so far?

Best Regards,
Ben Gardiner

[1] https://patchwork.kernel.org/patch/47513/

---
Nanometrics Inc.
http://www.nanometrics.ca