All of lore.kernel.org
 help / color / mirror / Atom feed
From: Howard Chu <hyc@symas.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: TI DSP updates
Date: Thu, 03 Sep 2009 03:24:25 -0700	[thread overview]
Message-ID: <4A9F9959.5010408@symas.com> (raw)
In-Reply-To: <mailman.7.1251972002.477.openembedded-devel@lists.openembedded.org>

> Date: Thu, 03 Sep 2009 10:00:37 +0200
> From: Koen Kooi <k.kooi@student.utwente.nl>

> On 03-09-09 04:17, Howard Chu wrote:
>> > These are the changes I made to use the latest Codec engine, DSP
>> > modules, etc. for OMAP3530 to build. Tested and working with
>> > gstreamer-ti on an Always Innovating Touch Book with linux-omap_2.6.29
>> > kernel / Angstrom...
> Thank you for your work on this! Your work does seem to be based on an
> outdated OE checkout, could you try to rebase it on the current
> org.openembedded.dev branch?

Ah, I thought I had rebased with HEAD just before I posted. But sure, I'll try 
updating again.

>> > To get a working codec server on the Touch Book, which has 256MB of RAM,
>> > I had to modify the default server config:
> To move the memorymap more stuff has to get changed, but there's an
> easier way that also works with 512MiB and 1024MiB RAM:
>
> put 'mem=80M@0x80000000 mem=128M@0x88000000' in your bootargs and make
> sure your kernel has the arch-has-holes.diff applied to make that
> memoryhole work.

Interesting. I guess that's more future-proof but currently no OMAP3530 can 
have more than 256MB of RAM... Also, not sure what else you're referring to 
that needs to be changed. The dsplink driver doesn't care. The codec server 
only needs to know where the end of memory is, and it arranges the rest of the 
map itself. It chose to use only 29M of memory, and I can't complain about 
that, better than eating up 40M. Here's the datasheet it generated for this 
codec server:

http://highlandsun.com/hyc/cs.x64P.DataSheet.html

The gstreamer ticodecplugin just needs to be pointed at that server.tcf file 
to use the same config. If I'm missing the point you're making, please explain 
again, thanks.

If I had known about that memory hole trick I would probably not have bothered 
rebuilding any of this, could've just downloaded a new codec combo and run 
with it. Live and learn...
-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/



       reply	other threads:[~2009-09-03 10:43 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.7.1251972002.477.openembedded-devel@lists.openembedded.org>
2009-09-03 10:24 ` Howard Chu [this message]
2009-09-03  2:17 TI DSP updates Howard Chu
2009-09-03  8:00 ` Koen Kooi

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=4A9F9959.5010408@symas.com \
    --to=hyc@symas.com \
    --cc=openembedded-devel@lists.openembedded.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.