Just one small fix needed (see below) and it's good-to-go.
> -Original Message-
> From: Ohad Ben-Cohen [mailto:o...@wizery.com]
> Sent: Tuesday, April 09, 2013 1:26 AM
>
> On Tue, Apr 9, 2013 at 1:56 AM, Tivy, Robert wrote:
> > Shouldn't the virtqueu
Hi Sergei,
> -Original Message-
> From: Sergei Shtylyov [mailto:sergei.shtyl...@cogentembedded.com]
> Sent: Sunday, April 07, 2013 10:55 AM
>
> Hello.
>
> On 04/07/2013 05:02 PM, Ohad Ben-Cohen wrote:
>
> >
> >> +static int da8xx_rproc_probe(struct platform_device *pdev)
> >> +{
> >> +
> -Original Message-
> From: Ohad Ben-Cohen [mailto:o...@wizery.com]
> Sent: Sunday, April 07, 2013 5:51 AM
>
> On Fri, Mar 29, 2013 at 4:41 AM, Robert Tivy wrote:
> > Change virtqueue callback function rpmsg_recv_done() to process all
> > available messages instead of just one message.
>
Hi Ohad,
> -Original Message-
> From: Ohad Ben-Cohen [mailto:o...@wizery.com]
> Sent: Sunday, April 07, 2013 6:03 AM
> To: Tivy, Robert
> Cc: davinci-linux-open-source; linux-arm; Nori, Sekhar; Rob Landley;
> linux-...@vger.kernel.org; Grosen, Mark; Ring, Chris
> Sub
> -Original Message-
> From: Nori, Sekhar
> Sent: Monday, March 11, 2013 4:49 AM
>
> On 3/9/2013 4:11 AM, Robert Tivy wrote:
> > Also fix REMOTEPROC config to select FW_LOADER (instead of
> FW_CONFIG).
>
> It is preferable to have the patch description make sense standalone
> even when re
Hi Ohad,
> -Original Message-
> From: Ohad Ben-Cohen [mailto:o...@wizery.com]
> Sent: Friday, February 15, 2013 12:07 AM
>
> Hi Rob,
>
> On Fri, Feb 1, 2013 at 4:24 AM, Robert Tivy wrote:
> > drivers/remoteproc/Kconfig| 29 ++-
> > drivers/remoteproc/Makefile |
Hi Sergei,
> -Original Message-
> From: Sergei Shtylyov [mailto:sshtyl...@mvista.com]
> Sent: Saturday, January 26, 2013 6:33 AM
>
> Hello.
>
> On 26-01-2013 6:45, Robert Tivy wrote:
>
> > Adding a remoteproc driver implementation for OMAP-L138 DSP
>
> You forgot to sign off the pa
Hi Sergei,
> -Original Message-
> From: Sergei Shtylyov [mailto:sshtyl...@mvista.com]
> Sent: Saturday, January 26, 2013 6:43 AM
>
> Hello.
>
> On 26-01-2013 6:45, Robert Tivy wrote:
>
> > Added a new remoteproc platform device for DA8XX. Contains CMA-based
> > reservation of physical
> -Original Message-
> From: Sergei Shtylyov [mailto:sshtyl...@mvista.com]
> Sent: Saturday, January 26, 2013 7:22 AM
>
> Hello.
>
> On 26-01-2013 6:45, Robert Tivy wrote:
>
> > Adding a remoteproc driver implementation for OMAP-L138 DSP
>
> > diff --git a/drivers/remoteproc/da8xx_remot
> -Original Message-
> From: Nori, Sekhar
> Sent: Tuesday, January 22, 2013 4:04 AM
>
> Rob,
>
> On 1/11/2013 5:53 AM, Robert Tivy wrote:
> > Added dsp clock definition, keyed to "davinci-rproc.0".
> >
> > Signed-off-by: Robert Tivy
> > ---
> > arch/arm/mach-davinci/da850.c |9 +
> -Original Message-
> From: Nori, Sekhar
> Sent: Monday, January 21, 2013 12:34 AM
> To: Tivy, Robert
> Cc: davinci-linux-open-source@linux.davincidsp.com; linux-arm-
> ker...@lists.infradead.org; Ring, Chris; Grosen, Mark; o...@wizery.com;
> r...@landley.net; linu
> -Original Message-
> From: Nori, Sekhar
> Sent: Sunday, January 20, 2013 9:39 PM
>
> On 1/11/2013 5:53 AM, Robert Tivy wrote:
> > Adding a remoteproc driver implementation for OMAP-L138 DSP
> >
> > Signed-off-by: Robert Tivy
> > ---
> > drivers/remoteproc/Kconfig |
Russell, thankyou for the review and notice, all this will be straightened out
in the next patch submission.
Regards,
- Rob
> -Original Message-
> From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> Sent: Monday, January 21, 2013 8:41 AM
> To: Nori, Sekha
Thankyou for all your help Sekhar. I'm fine with your fixups (both commentary
and code naming).
Regards,
- Rob
> -Original Message-
> From: Nori, Sekhar
> Sent: Thursday, January 17, 2013 3:33 AM
> To: Tivy, Robert
> Cc: davinci-linux-open-source@linux.davincidsp.c
> -Original Message-
> From: Ohad Ben-Cohen [mailto:o...@wizery.com]
> Sent: Tuesday, January 15, 2013 4:49 AM
> To: Nori, Sekhar
> Cc: Tivy, Robert; davinci-linux-open-source; linux-arm; Ring, Chris;
> Grosen, Mark; r...@landley.net; linux-...@vger.kernel.org; Ch
Hi Ohad,
Glad to see you jump in the fray, please see responses below...
> -Original Message-
> From: Ohad Ben-Cohen [mailto:o...@wizery.com]
> Sent: Friday, January 11, 2013 4:26 AM
> To: Tivy, Robert
> Cc: davinci-linux-open-source; linux-arm; Nori, Sekhar; Ring, Chris;
ckages/installations.
Regards,
- Rob
> -Original Message-
> From: Nori, Sekhar
> Sent: Friday, January 04, 2013 4:11 AM
> To: Tivy, Robert
> Cc: davinci-linux-open-source@linux.davincidsp.com; linux-arm-
> ker...@lists.infradead.org; o...@wizery.com; r...@landley.net; linu
roc
This should make for an easier review of the changes.
Regards,
- Rob
> -Original Message-
> From: Tivy, Robert
> Sent: Wednesday, December 19, 2012 5:34 PM
> To: davinci-linux-open-source@linux.davincidsp.com; linux-arm-
> ker...@lists.infradead.org; Nori, Sekhar; o.
> -Original Message-
> From: Nori, Sekhar
> Sent: Wednesday, December 12, 2012 2:34 AM
> On 12/12/2012 7:06 AM, Tivy, Robert wrote:
> >> -Original Message-
> >> From: Nori, Sekhar
> >> Sent: Friday, November 30, 2012 2:51 AM
> >>
&g
> -Original Message-
> From: Nori, Sekhar
> Sent: Friday, November 30, 2012 2:51 AM
>
> Hi Rob,
>
> On 11/29/2012 7:08 AM, Tivy, Robert wrote:
> > Hi Sekhar,
> >
> > Please see comments and noob questions below...
> >
> > They can run
> -Original Message-
> From: Nori, Sekhar
> Sent: Friday, December 07, 2012 12:24 AM
> On 12/4/2012 9:43 PM, Murali Karicheri wrote:
> > On 12/04/2012 09:53 AM, Murali Karicheri wrote:
> >> I believe this is addressing the same issue. This is a DT based
> >> solution, which I believe should
> -Original Message-
> From: davinci-linux-open-source-boun...@linux.davincidsp.com
> [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On
> Behalf Of Karicheri, Muralidharan
> Sent: Tuesday, December 04, 2012 8:13 AM
> To: davinci-linux-open-source@linux.davincidsp.com
> Subj
> -Original Message-
> From: Chemparathy, Cyril
> Sent: Monday, December 03, 2012 12:13 PM
> To: Nori, Sekhar
> Cc: Tivy, Robert; davinci-linux-open-source@linux.davincidsp.com;
> linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH v3 5/6] ARM: davinci: remotep
Hi Sekhar,
> -Original Message-
> From: Nori, Sekhar
> Sent: Friday, November 30, 2012 2:51 AM
> To: Tivy, Robert
> Cc: davinci-linux-open-source@linux.davincidsp.com; linux-arm-
> ker...@lists.infradead.org; Ring, Chris; Grosen, Mark
> Subject: Re: [PATCH v3 5/6] ARM
Hi Sekhar,
Please see comments and noob questions below...
> -Original Message-
> From: Nori, Sekhar
> Sent: Tuesday, November 20, 2012 4:27 AM
> To: Tivy, Robert
> Cc: davinci-linux-open-source@linux.davincidsp.com; linux-arm-
> ker...@lists.infradead.org; Ring, C
Hi Sergei,
Thanks for your feedback, please see below...
> -Original Message-
> From: Sergei Shtylyov [mailto:sshtyl...@mvista.com]
> Sent: Wednesday, November 14, 2012 2:17 AM
> To: Tivy, Robert
> Cc: davinci-linux-open-source@linux.davincidsp.com; l
Hi Prabhakar,
Thanks for your consideration, please see my response below...
> -Original Message-
> From: Prabhakar Lad [mailto:prabhakar.cse...@gmail.com]
> Sent: Monday, November 05, 2012 9:02 PM
> To: Tivy, Robert; Ben Gardiner
> Cc: davinci-linux-open-source@linux
Thanks for your comments, Sergei. Please see below...
> -Original Message-
> From: Sergei Shtylyov [mailto:sshtyl...@mvista.com]
> Sent: Friday, October 26, 2012 2:46 AM
> To: Tivy, Robert
> Cc: davinci-linux-open-source@linux.davincidsp.com; linux-arm-
> ker...@lists.i
Hi Sekhar, thanks for reviewing this, please see below questions...
> -Original Message-
> From: Nori, Sekhar
> Sent: Friday, October 12, 2012 6:06 AM
> To: Tivy, Robert
> Cc: davinci-linux-open-source@linux.davincidsp.com; Ring, Chris;
> Grosen, Mark
> Subject
More details about the failure to open the codec engine are needed. You can
generate more info by setting the environment variable CE_DEBUG=3 and
re-running your app:
% export CE_DEBUG=3
% ./decode ...
Regards,
- Rob
From: davinci-linux-open-source-bou
From: Tharmarajan Ganeshan [mailto:tha...@e-consystems.com]
Sent: Wednesday, July 14, 2010 8:17 AM
To: Tivy, Robert
Cc: davinci-linux-open-source@linux.davincidsp.com; maharajan; dhineshkumar
Subject: RE: DM355 - 256MB RAM memory issue
Hi Robert
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of
Tharmarajan Ganeshan
Sent: Saturday, July 10, 2010 8:35 AM
To: todd.fisc...@ridgerun.com; Ring, Chris
Cc: davinci-linux-open
> -Original Message-
> From:
> davinci-linux-open-source-bounces+rtivy=ti@linux.davincids
> p.com
> [mailto:davinci-linux-open-source-bounces+rtivy=ti@linux.d
> avincidsp.com] On Behalf Of Mike Williamson
> Sent: Friday, May 28, 2010 6:46 AM
> To: davinci-linux-open-source@linux.d
I need to port CMEM to the newer 2.6.34 Linux kernel but am having trouble with
the cache functions. This is for the TI ARM, in general.
CMEM provides general capability to user programs to initiate a cache
operation, mostly for the purpose of affecting the cache contents pertaining to
the CME
-z means that every following option is for the linker, and since many compiler
options follow the expansion of usr.bld, you can't use -z in that file. Is
there not a link.cmd or linker.cmd file that can be used instead (and is
consumed by the XDC tooling)?
Regards,
- Rob
___
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of
liuyue18301
Sent: Tuesday, April 06, 2010 6:56 PM
To: davinci-linux-open-source@linux.davincidsp.com
Subject: how Codec_engi
> -Original Message-
> From: davinci-linux-open-source-boun...@linux.davincidsp.com
> [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com
> ] On Behalf Of Vladimir Pantelic
> Sent: Monday, February 15, 2010 4:27 AM
> To: davinci-linux-open-source@linux.davincidsp.com
> Cc: davin
There is a good manual here, named "Codec Engine Server Integrator User's
Guide": http://focus.ti.com/lit/ug/sprued5b/sprued5b.pdf.
It describes what you need to do to put multiple codecs in an application. You
will need to create a Codec Server that contains both your algorithms (codecs),
sin
turn, it could be either a codec
problem or a general DSP/BIOS system problem (such as not enough stack for the
codec TSK).
Regards,
- Rob
From: Albert Burbea [mailto:alber...@gmail.com]
Sent: Monday, January 04, 2010 11:55 PM
To: Tivy, Robert
Cc: davinci-linux-open-
nd, you'll see what I mean).
- Rob
> -Original Message-
> From: Erez Kinarti [mailto:er...@radvision.com]
> Sent: Tuesday, January 05, 2010 12:21 AM
> To: Tivy, Robert; Vladimir Pantelic;
> Davinci-linux-open-source@linux.davincidsp.com
> Subject: RE: Cmem addr
This sounds like an odd setup, how are you even calling the codec if not
through CE?
Since the first codec is assuming responsibility for doing "first" things, like
calling CERuntime_init(), can't it also call Memory_registerContigBuf()? From
your earlier descriptions it sounds like you might
Chris has already responded to your other issues, so please see just one
comment from me below.
Regards,
- Rob
> -Original Message-
> From: Paul Stuart [mailto:paul_stu...@seektech.com]
> Sent: Tuesday, January 05, 2010 7:26 AM
> To: Tivy, Robert; davinci-linux
Generally, user-level code doesn't care much about the kernel version, and CE
itself is all user-level code. Since CE encapsulates other packages that do
contain kernel modules (which do care about kernel version), such as CMEM in
LinuxUtils and DSPLink, the problem probably is with those.
The
Nothing comes to mind from just your description. BTW, that "really strange"
address (0xbeffc850) seems like a Linux user stack address.
Since nothing jumps out from your top-down description, I would suggest a
bottom-up investigation - debugging the DSP. Seems that the codec's
"control()" co
There is no function available to invalidate all the Memory module virt-phys
translations.
If your app structure allows it, you can call
Memory_registerContigBuf(bigCMEMBufferVirtAddr, 258048,
CMEM_getPhys(bigCMEMBufferVirtAddr));
once, and all smaller subdivided buffers will be covered by
Oops, forgot to "Reply All"...
- Rob
____
From: Tivy, Robert
Sent: Wednesday, December 30, 2009 10:57 AM
To: 'Erez Kinarti'
Subject: RE: Cmem address translation when working with Codec Engine
Erez,
Thanks for your detailed explanation, it all
How are you "returning CMEM buf to the pool" for each codec thread?
CE contains a virt-to-phys cache in CE's Memory module, and a CE codec class
stubs file will use the Memory module to translate the virt addr to a phys
addr. If CMEM buffer allocation is happening through the Memory module but
Perhaps you missed an earlier build error related to it. My (old) copy of
dm350mmap.c has:
static DECLARE_MUTEX_LOCKED (dm350mmap_reply_mutex);
You can know that it *should* be defined in dm350mmap.c because it's got the
dm350mmap perfix.
Regards,
- Rob
> -Original Message-
> From:
ent one than what you're using today could help with your cache
management.
Regards,
- Rob
From: Sriraja Yagneswaran [mailto:sriraja_yagneswa...@mindtree.com]
Sent: Tuesday, November 17, 2009 8:34 PM
To: Tivy, Robert; davinci-linux-open-source@linux.davincid
Codec Engine has mechanisms in place to manage the cache for inBufs & outBufs
being transferred between an ARM and DSP, but there is no cache management for
inArgs/outArgs. Perhaps this is your problem and you could try to manage the
cache for these buffers manually using the CE osal's Memory i
See below...
Regards,
- Rob
> -Original Message-
> From: davinci-linux-open-source-boun...@linux.davincidsp.com
> [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com
> ] On Behalf Of Steve Chen
> Sent: Tuesday, November 03, 2009 4:53 AM
> To: Shlomo Kut
> Cc: davinci-linux-
See below...
Regards,
- Rob
> -Original Message-
> From: davinci-linux-open-source-boun...@linux.davincidsp.com
> [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com
> ] On Behalf Of ???
> Sent: Sunday, November 01, 2009 9:35 PM
> To: Richard Williams
> Cc: davinci-linux-op
There is no general EDMA user interface. The EDMA APIs are in the kernel and
are called by device drivers mostly.
TI's LinuxUtils package contains a general EDMA resource manager that can be
called by user programs, but it is only for allocating/freeing channels and
waiting on the EDMA complet
A "compilation" of source code does not require any libraries, just header
files. Libraries are used only by a linker, usually for linking the final app.
You could pre-link your library of algorithms with the other libraries by doing
a "partial link", which would bring the needed library code i
That output is normal. CMEM is just showing what it did.
If you need more info about your failure try setting CE_DEBUG=1|2|3, the higher
the number the more output you get.
- Rob
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linu
> -Original Message-
> From: davinci-linux-open-source-boun...@linux.davincidsp.com
> [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com
> ] On Behalf Of david.kond...@legrandna.com
> Sent: Thursday, October 08, 2009 7:47 AM
> To: jaya.krish...@samsung.com
> Cc: davinci-linu
Hi Folks,
A colleague is trying to increase the size of his ramdisk from 16MB to 24MB,
and one of the steps he's taken is to increase the size for 'initrd' in
bootargs:
bootargs=console=ttyS0,115200n8 root=/dev/ram initrd=0x8090,24M
init=/bin/ash lpj=5000 mem=80M
bootcmd=bootm 0x8070
Wh
.
Regards,
- Rob
> -Original Message-
> From: David Brownell [mailto:davi...@pacbell.net]
> Sent: Wednesday, September 16, 2009 1:49 PM
> To: davinci-linux-open-source@linux.davincidsp.com
> Cc: Tivy, Robert; Nori, Sekhar; Paulraj, Sandeep
> Subject: Re: [PATCH] DaVinci: EDMA
resentative of the typical EDMA API client.
Regards,
- Rob
> -Original Message-
> From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
> Sent: Wednesday, September 16, 2009 8:43 AM
> To: Tivy, Robert
> Cc: Nori, Sekhar; Paulraj, Sandeep;
> davinci-linux-open-source@linux.d
Since I was the one to ask Sandeep for this API, I will offer up my reasoning...
Without this API, in order to call either edma_free_slot() or
edma_free_channel() the LinuxUtils EDMAK device driver will have to carry a
"slot-vs-channel" "flag" or "cookie" around with the EDMA allocation record.
You can simply remove the function that is referencing init_mm - show_pte() -
since it's not called by any code.
Regards,
- Rob
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behal
> -Original Message-
> From: David Brownell [mailto:davi...@pacbell.net]
> Sent: Friday, August 28, 2009 3:27 PM
>
> On Friday 28 August 2009, Tivy, Robert wrote:
> >
> > Great. BTW, I've been told that future codecs would want
> on the orde
Thanks for the reply, please see below...
Regards,
- Rob
> -Original Message-
> From: David Brownell [mailto:davi...@pacbell.net]
> Sent: Friday, August 28, 2009 2:37 PM
>
> On Friday 28 August 2009, Tivy, Robert wrote:
> >
> > > I'd like to sugg
Does anyone have any feedback/thoughts on my suggestion below?
We at TI need to know, and hopefully have some say in, the availability of EDMA
channel allocations.
Regards,
- Rob
> -Original Message-
> From: Tivy, Robert
> Sent: Wednesday, August 26, 2009 8:25 PM
&g
It seems that arriving at a consensus for reserved channels isn't going to be
easy.
I'd like to suggest a scheme involving some sort of driver-controlled unlocking
of reserved channels, intended to be used late in the EDMA acquisition
timeline. The LinuxUtils EDMA driver has a strong need for
The limit is the amount of memory in the heap that you assign for stacks.
- Rob
From: Sandeep YEDIRE [mailto:sandee...@yahoo.co.in]
Sent: Monday, August 17, 2009 5:43 AM
To: Tivy, Robert; davinci-linux-open-source@linux.davincidsp.com
Cc: Sandeep Yedire
Subject
Is this what you're looking for?:
var Server = xdc.useModule('ti.sdo.ce.Server');
Server.algs = [
{name: "viddec_copy", mod: VIDDEC_COPY, threadAttrs: {
stackSize: 0x4096, stackMemId: 0, priority: Server.MINPRI + 2}, groupId
: 0,
},
{name: "videnc_copy", mod: VIDENC_COPY, thr
See answers inline below...
Regards,
- Rob
From: davinci-linux-open-source-bounces+rtivy=ti@linux.davincidsp.com
[mailto:davinci-linux-open-source-bounces+rtivy=ti@linux.davincidsp.com] On
Behalf Of Gopal Sukumar
Sent: Thursday, August 06, 2009 12:38 AM
The next CMEM release (of which I don't know the plans) should have this fixed,
we have been informed of the issue. For now, you can comment out or "#if 0"
the function that uses it, since that function is never called.
- Rob
TI, Santa Barbara
> -Original Message-
> From: davinci-linu
You must have a bug somewhere with respect to your buffer pointers. The
virtual addresses that CMEM is complaining about are not ones that would be
returned by Memory_contigAlloc on a Linux system. However, CMEM_getPhys() (the
user front end to the kernel support) is often used for more than j
A general observation, since I don't know about the implementation...
You "memset(&video_params, 0, sizeof (IVIDENC1_Params))" and then explicitly
set some of them to real values, but what about the other possible members of
IVIDENC1_Params, which remain as 0?
Usually one would do something li
> -Original Message-
> From: David Brownell [mailto:davi...@pacbell.net]
> Sent: Thursday, June 11, 2009 3:18 PM
> To: Tivy, Robert
> Cc: davinci-linux-open-source@linux.davincidsp.com; Andrea Gasparini
> Subject: Re: EDMA with user provided virtual addresses.
>
> -Original Message-
> From: David Brownell [mailto:davi...@pacbell.net]
> Sent: Thursday, June 11, 2009 1:09 PM
> To: Tivy, Robert
> Cc: davinci-linux-open-source@linux.davincidsp.com; Andrea Gasparini
> Subject: Re: EDMA with user provided virtual addresses.
>
TI's Codec Engine Linux Utils module CMEM can do what you want, but I don't
know if it's even a possibility for you. EDMA requires physically contiguous
buffers, so in addition to needing to know the physical address, you also must
ensure that your buffers are contiguous physically, and CMEM pr
The CMEM module does not need to be loaded for the application link stage. If
you get "undefined reference to CMEM_init" then that just means that you're not
correctly referencing cmem.a in your link.
Regards,
- Rob
From: davinci-linux-open-source-boun...@linu
> -Original Message-
> From: davinci-linux-open-source-boun...@linux.davincidsp.com
> [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com
> ] On Behalf Of Ryan Talbot
> Sent: Tuesday, June 09, 2009 2:29 PM
> To: Vladimir Pantelic; davinci-linux-open-source@linux.davincidsp.com
>
> -Original Message-
> From: davinci-linux-open-source-boun...@linux.davincidsp.com
> [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com
> ] On Behalf Of Vladimir Pantelic
> Sent: Sunday, May 24, 2009 10:52 AM
> To: Troy Kisky
> Cc: Koen Kooi; davinci-linux-open-source@linux.
> -Original Message-
> From: davinci-linux-open-source-boun...@linux.davincidsp.com
> [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com
> ] On Behalf Of Kevin Hilman
> Sent: Friday, May 22, 2009 8:11 AM
> To: Ring, Chris
> Cc: davinci-linux-open-source@linux.davincidsp.com; Da
inux-open-source-requ...@linux.davincidsp.com
> >
> > You can reach the person managing the list at
> > davinci-linux-open-source-ow...@linux.davincidsp.com
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of
I'm not sure about a document, but the number of algorithm objects that you can
create depends on the size of the memory block from which the stacks are
allocated. As you've seen, cutting the stack size down allows you to create
more. You might be able to find a formula, but the real answer is
I would suggest hooking up CCS and looking at what's going on with the DSP when
this happens. The DSP server needs to get to a "handshake" point with the ARM,
and it appears that the ARM is timing out after not receiving a response from
the DSP (error code DSP_EBASE + 0x17 is a timeout error).
"-ml3" is legacy code/data model support. Before --mem_model: came along
"-ml?" was used for specifying data and code models (where ? is 0-3).
"-mv6400+" specifies C64+ DSP architecture, as available on Davinci and other
processors.
Removing "-ml3" should solve your problem. However, it migh
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of
Prabhaharan R-TLS,Chennai
Sent: Sunday, March 22, 2009 2:08 AM
To: davinci-linux-open-source
Subject: CMEM Issue in Decode D
Your C64P.rootDir needs to point to the location of your TI C6x codegen tools
(not your XDC tools). The path you set there needs to end at the CG tools base
directory (directory above 'bin', 'include', etc.).
- Rob
From: davinci-linux-open-source-bounces+rtivy=
Try adding the following to your .pjt file's C compiler options.
-i"%XDC_INSTALL_DIR%/packages" -d"xdc_target_types__=ti/targets/std.h"
Regards,
- Rob
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.d
Linux Utils 2.22 contains an update to CMEM for 2.6.28 kernels, although it
hasn't yet been validated. Here's the output of a "diff -c" with the Linux
Utils 2.21 cmemk.c:
***
*** 1694,1700
--- 1694,1704
#ifdef USE_CLASS_DEVICE
class_device_create(cmem_class, NULL
> -Original Message-
> From:
> davinci-linux-open-source-bounces+rtivy=ti@linux.davincids
> p.com
> [mailto:davinci-linux-open-source-bounces+rtivy=ti@linux.d
> avincidsp.com] On Behalf Of Troy Kisky
> Sent: Tuesday, January 06, 2009 2:07 PM
> To: David Brownell
> Cc: davinci-l
This is overly complex. The initial setting of env var EVR at the beginning of
the script does nothing, and the C program is just using the environment to
store a temp value, which isn't even needed. The usage of a file is also
unnecessary (unless you want to retain the value).
This would do
Message-
> From: Neerav Patel [mailto:neer...@ptgrey.com]
> Sent: Wednesday, December 17, 2008 11:34 AM
> To: Tivy, Robert
> Cc: Neerav Patel; davinci-linux-open-source@linux.davincidsp.com
> Subject: Re: Error with CMem
>
> Hi Robert,
>
> Thanks for the response, is the
Your insmod command looks fine. With it, you've got 3 buffers available from
pools that have large enough buffers (the first 2 entries in your 'pools'
setting). The 3rd entry configures 7 buffers of size 829440, which is a little
bit too small for satisfying requests for 8884736.
So, it comes
No, a process can't modify the environment of its parent (and the parent of a
program is typically a shell). You could have the program output the desired
environment variable contents and do
% YOURENVVAR=`yourprogramname`
- Rob
> -Original Message-
> From:
> davinci-linux-op
Either the application .cfg file or some included package would need to do:
xdc.useModule('ti.sdo.ce.image1.IIMGENC1');
to bring in the library containing IMGENC1_create().
I'm not familiar with the details of the ti.sdo.codecs.jpegenc.dm355.ce.JPEGENC
module so I can't check that out, but pe
Codec Engine comes with pre-built debug libraries that support the GT tracing
feature. To see trace prints, the easiest way is to set the env var
CE_DEBUG=[1|2|3], with 1 being the least and 3 the most.
See http://wiki.davincidsp.com/index.php?title=Codec_Engine_FAQ
- Rob
it will try the next biggest size.
4) It sounds like you will need a lot of memory for high-res processing. You
will need to reduce the amount given to Linux.
- Rob
From: ashish pareek [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 04, 2008 2:58 AM
To: Tivy
Your loadmodules.sh shows you giving 12MB to CMEM (although the insmod line
appears to be commented out). This amount will satisfy your specified needs of
My memory req are like
pool fitting a size 4147200
pool fitting a size 8294400
although enough for only one of each. However, you are partiti
I'm just speaking in general as to why one might not need to use threads on a
DM355.
- Rob
> -Original Message-
> From: bj [mailto:[EMAIL PROTECTED]
> Sent: Thursday, October 30, 2008 9:58 AM
> To: Tivy, Robert
> Cc: Panchy Rivas; davinci-linux-open-source@
One reason would be that the DM355 doesn't have a DSP so there's no other
processor to wait on. In DM6446, a thread submitting a frame to the DSP codec
will block on completion of that frame, so there are some idle ARM CPU cycles
to take advantage of while the one thread is blocked. On DM355,
I don't know about "standard library/hookup", but DSP/BIOS and DSPLink are
widely used for the ARM<->DSP communication. DSPLink is kind of low level, so
you could also use Codec Engine from TI for simplifying and/or abstracting the
interface between the DSP and ARM, and in doing so could proba
Stabbing in the dark, could it be that your XDCPATH definition has a typo?
There is no leading "/" in front of "home/albertb/albertb_tests/packages".
- Rob
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Albert Burbea
Sent: Wednesday, October 22,
Arvind,
Yes, non-blocking VISA APIs (asynchronous APIs) are available in CE 2.10
w/DM6467 and the VIDENC1/VIDDEC2 codecs.
I'm not sure what pointers you want, except to say that instead of doing
VIDENC1_process()
you would do
VIDENC1_processAsync()
...
VIDENC1_processWait()
Rega
1 - 100 of 140 matches
Mail list logo
