public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
From: Steve Poulsen <spoulsen@css-design.us>
To: "Woodruff, Richard" <r-woodruff2@ti.com>
Cc: linux-omap-open-source@linux.omap.com
Subject: Re: Bridge vs DSP/BIOS Link
Date: Wed, 16 May 2007 11:21:48 -0500	[thread overview]
Message-ID: <464B2F9C.8010100@css-design.us> (raw)
In-Reply-To: <3B6D69C3A9EBCA4BA5DA60D913027429FD0A30@dlee13.ent.ti.com>

Josh,

Based on experience with the two, the piece that I would add is this.

There seems to be two packages that you can go download now for the OMAP 
(5912 to be specific, but others' experience may vary). 

DSP/BIOS Link (ARM and DSP code):

I was able to download the software and for the most part get it 
going.   There were pieces missing (invalid links for components in the 
docs) and getting it to work for Linux 2.6 required several 
modifications.  In the end, it seems to be a good low-level (relatively 
speaking) method for sending messages.

DSP Bridge (ARM and DSP code):

This code is also available (DSP gateway per Richard's response) and 
seems to be a very different approach.  I did some looking into it and 
it seemed too complex for our needs.   I also had some concern as to how 
the DSP memory map was exposed, but I did not follow up through this 
much because of the first problem.

In short, I came to the conclusion that to get either one of them 
working on the board requires a substantial effort.  DSP/BIOS Link 
required changes just to get it to build and more to make it not crash.  
I expect DSP Bridge may be more up-to-date, but it still is a large 
piece of software so there should be some effort here to learn about 
it.   You could get lucky with it and have things go quickly and 
smoothly, but I would not count on it.   Finally, after much time on 
both of these, we developed our own custom messaging using the 
mailboxes.  For our single-application system, this seemed to be the 
best approach, without much overhead.

BTW, the OMAP patched kernel for 2.6 includes the bridge.   I have not 
fully tested it, but the parts that I have (init, mmu, clocks), seem to 
work well.

Steve


Woodruff, Richard wrote:
>> Curious if anyone knows what the difference is between the 
>> DSPBridge OMAP DSP driver and the DSP/BIOS Link driver.  I 
>> did see a question posted about a year ago on this mailing 
>> list but sadly there was no response.  This is what I know:
>>     
>
> Well a complete answer is to much to write and I wouldn't do it justice
> as I don't know the whole picture.  But in short:
>
> Give OMAPs ARM+DSP/s architecture TI has done reference implementations
> of bridge and link for the major operating systems as required by
> demand.
>
> Bridge came first.  The bridge framework and associated pieces go up
> high into an OS and do some media management aspects.  There are bridge
> pieces on the ARM side and the DSP side (in addition to DSP BIOS).  The
> sum of this is a large and complex package aimed at rich multimedia,
> codec's and the like all fall in here as well.  If you look at
> http://www.khronos.org/ you get the idea of what gets logically bundled
> with full solution (OpenMax, ...).
>
> For some customers bridge and upper related layers were to much given
> their needs.  For these customers a "link" was created it does many of
> the lower layers of the bridge function.  It doesn't try and integrate
> as high up and doesn't provide the same level of features.
>
> For Linux reference bridges do exist and they have evolved over time.
> Customers have used this either directly or as a reference in
> implementations of their own bridges.  Links also do exist for Linux.
> If you look inside products you likely will find a few different ones
> about.  At the bottom they are similar as you go up and they integrate
> in to multimedia they diverge.
>
> The low layer concepts between the bridges are similar.  The use of
> mailbox hardware to exchange messages, idea of a DSP at the other end
> likely running DSP BIOS, DSP-MMU usage, you need to
> init/load/create&control-xmit-recv-data-streams.  Across OMAP1-2-3 the
> DSP block's capabilities have been going up.  So you find the upper
> layers of the bridge growing.
>
> Nokia did contribute their version of bridge/link a couple years back
> (dspgateway).  This is used in their 770 and 800 products.
>
> Hope that helps.
>
> Regards,
> Richard W.
> _______________________________________________
> Linux-omap-open-source mailing list
> Linux-omap-open-source@linux.omap.com
> http://linux.omap.com/mailman/listinfo/linux-omap-open-source
>
>   

  reply	other threads:[~2007-05-16 16:21 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-16 13:32 Bridge vs DSP/BIOS Link Josh Ostrander
2007-05-16 14:55 ` Woodruff, Richard
2007-05-16 16:21   ` Steve Poulsen [this message]
2007-05-18 17:14     ` Josh Ostrander

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=464B2F9C.8010100@css-design.us \
    --to=spoulsen@css-design.us \
    --cc=linux-omap-open-source@linux.omap.com \
    --cc=r-woodruff2@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox