Hi,

We have come across instances when application integrator would like to
control memory-space used for instance creation of an Algorithm. I am
looking for ways application can achieve this in codec engine.

For example let us assume that in a system two algorithms A1 and A2 are
there and both ask for internal memories (via algAlloc()) and the total
internal memory available on chip is not sufficient. A1 uses DMA so
can't work from external memory whereas A2 can work from external but
will have performance hit. In this case app would like to create A2 from
external memory although it is asking for internal (via algAlloc).

If A1 is created before A2, is it guaranteed that A1 gets memory from
internal and A2 is created from external? If not then what are the
better ways?

Best Regards,
Kumar


-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of [EMAIL PROTECTED]
Sent: Friday, February 08, 2008 3:40 AM
To: [email protected]
Subject: Davinci-linux-open-source Digest, Vol 26, Issue 18

Send Davinci-linux-open-source mailing list submissions to
        [email protected]

To subscribe or unsubscribe via the World Wide Web, visit
        
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

or, via email, send a message with subject or body 'help' to
        [EMAIL PROTECTED]

You can reach the person managing the list at
        [EMAIL PROTECTED]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Davinci-linux-open-source digest..."


Today's Topics:

   1. RE: Compiling Targets and Codecs (Ring, Chris)
   2. Re: hotplug subsytem, dm355, and gadget driver
      (Christopher Stillson)
   3. RE: Compiling Targets and Codecs (Joshua Hintze)


----------------------------------------------------------------------

Message: 1
Date: Thu, 7 Feb 2008 13:20:18 -0600
From: "Ring, Chris" <[EMAIL PROTECTED]>
Subject: RE: Compiling Targets and Codecs
To: "Joshua Hintze" <[EMAIL PROTECTED]>,
        <[email protected]>
Message-ID:
        <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="us-ascii"

Please review this thread and see if it answers your question.
http://osdir.com/ml/linux.davinci/2006-09/msg00095.html
 
In short, your codec package can just have a 64P library, but you may
have to adjust its getlibs() fxn as described at the link above.
 
Chris


________________________________

        From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Joshua Hintze
        Sent: Thursday, February 07, 2008 8:58 AM
        To: [email protected]
        Subject: Compiling Targets and Codecs
        
        

        Hello,

         

        I am running with the DM6446 processor and something that I have
not yet figured out is the compiling targets when working with the codec
engine. What I mean is if I want to have the codec running on the DSP
and the executable running on the ARM do I need to produce two different
libraries for the codec?

         

        It seems the app likes to link with .a470MV. However if I turn
off the MVArm9 build target in user.bld this file no longer gets
generated.

         

        My questions are, can I get the linux side app to link with
.a64P? The reason why I only want to generate the .a64P is because I
have a lot of cl6x (DSP) only code in my codec, that takes advantage of
DSP optimizations and the arm compiler chokes on that when compiling the
codec.

         

        I noticed in the linux app makefile there is an XDCTARGET that
is set to XDCTARGET = gnu.targets.MVArm9. I tried gnu.targets.C64P with
no luck.

         

        Thanks,

         

        Josh

         

         

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://linux.omap.com/pipermail/davinci-linux-open-source/attachments/20
080207/4236ac05/attachment-0001.htm

------------------------------

Message: 2
Date: Thu, 7 Feb 2008 13:01:28 -0800
From: "Christopher Stillson" <[EMAIL PROTECTED]>
Subject: Re: hotplug subsytem, dm355, and gadget driver
To: "Nori, Sekhar" <[EMAIL PROTECTED]>
Cc: [email protected]
Message-ID:
        <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1

The situation is I have a DM355 with an SD card. I would like the SD
card to be mounted for
used by Linux most of the time. But, on insertion of a USB cable I
want to unmount the card
and "mount" (although it's really a modprobe) the card via
g_file_storage. Then, when the cable is
unplugged I want to remount it as a linux file system.

It seems that hotplug would do that, and there seem to be calls to the
hotplug system in the gadget code. I don't remember if I found them in
the Iventra driver code or not. I decided at that point to see if
anyone had
dealt with this already.

All I really need is to have some scripts called on USB insert/remove.
If you have any ideas about how to
do that, I would be really greatful.

Chris

On Feb 6, 2008 9:44 PM, Nori, Sekhar <[EMAIL PROTECTED]> wrote:
> Chris,
>
> Hotplug in USB comes into picture in host mode, when a device plugs
into
> it. Why do you want to trap the cable insertion event?
>
> Thanks,
> Sekhar
>
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On
> Behalf
> > Of Christopher Stillson
> > Sent: Tuesday, February 05, 2008 5:43 AM
> > To: [email protected]
> > Subject: hotplug subsytem, dm355, and gadget driver
> >
> > I'm trying to determine when the USB cable is inserted, which would
> > seem to be from the hotplug subsystem, but this doesn't work for me.
> > The hotplug system (which works for the sd card) doesn't seem to
> > trigger from USB.
> >
> > I have a system the successfully runs g_file_storage. I'm pretty
sure
> > I have everything set up normally.
> >
> > Should the hotplug system work this way? If not, are there any
> > alternatives?
> >
> > Chris
> > _______________________________________________
> > Davinci-linux-open-source mailing list
> > [email protected]
> >
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>



-- 
Chris


------------------------------

Message: 3
Date: Thu, 7 Feb 2008 15:08:05 -0700
From: "Joshua Hintze" <[EMAIL PROTECTED]>
Subject: RE: Compiling Targets and Codecs
To: "'Ring, Chris'" <[EMAIL PROTECTED]>,
        <[email protected]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="us-ascii"

Thanks Chris this worked great.

 

I have another quick question. How can I change the cl6x compiler
switches
that are defaulted in the Codec Engine when using package.bld.

 

For example I want to add a couple like: -pm -op2 and change -o2 to -o3.

 

Thanks,

 

Josh

 

From: Ring, Chris [mailto:[EMAIL PROTECTED] 
Sent: Thursday, February 07, 2008 12:20 PM
To: Joshua Hintze; [email protected]
Subject: RE: Compiling Targets and Codecs

 

Please review this thread and see if it answers your question.

http://osdir.com/ml/linux.davinci/2006-09/msg00095.html

 

In short, your codec package can just have a 64P library, but you may
have
to adjust its getlibs() fxn as described at the link above.

 

Chris

 


  _____  


From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of
Joshua Hintze
Sent: Thursday, February 07, 2008 8:58 AM
To: [email protected]
Subject: Compiling Targets and Codecs

Hello,

 

I am running with the DM6446 processor and something that I have not yet
figured out is the compiling targets when working with the codec engine.
What I mean is if I want to have the codec running on the DSP and the
executable running on the ARM do I need to produce two different
libraries
for the codec?

 

It seems the app likes to link with .a470MV. However if I turn off the
MVArm9 build target in user.bld this file no longer gets generated.

 

My questions are, can I get the linux side app to link with .a64P? The
reason why I only want to generate the .a64P is because I have a lot of
cl6x
(DSP) only code in my codec, that takes advantage of DSP optimizations
and
the arm compiler chokes on that when compiling the codec.

 

I noticed in the linux app makefile there is an XDCTARGET that is set to
XDCTARGET = gnu.targets.MVArm9. I tried gnu.targets.C64P with no luck.

 

Thanks,

 

Josh

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://linux.omap.com/pipermail/davinci-linux-open-source/attachments/20
080207/46cb462d/attachment.htm

------------------------------

_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


End of Davinci-linux-open-source Digest, Vol 26, Issue 18
*********************************************************


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
[EMAIL PROTECTED]
**********************************************************************

_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Reply via email to