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 rt...@ti.com wrote:
Shouldn't the virtqueue_kick() be called only when we
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
Subject: Re: [PATCH v9 4/6] ARM
-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 rt...@ti.com wrote:
Change virtqueue callback function rpmsg_recv_done() to process all
available messages instead of just one
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)
+{
+ struct
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 rt...@ti.com wrote:
drivers/remoteproc/Kconfig| 29 ++-
drivers/remoteproc/Makefile
-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_remoteproc.c
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 memory
-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 rt...@ti.com
---
arch/arm/mach-davinci/da850.c |9 +
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, Sekhar
Cc: Tivy, Robert; o
-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 rt...@ti.com
---
drivers/remoteproc/Kconfig |
-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; linux-...@vger.kernel.org
Subject
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.com; linux-arm-
ker
-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; Chemparathy,
Cyril
Subject: Re
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;
Grosen, Mark; r
.
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; linux-
d...@vger.kernel.org; Ring, Chris; Grosen
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...@wizery.com;
r...@landley.net; linux
-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
Hi Rob,
On 11/29/2012 7:08 AM, Tivy, Robert wrote:
Hi Sekhar
-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 a single image if the image supports overriding the
Kconfig settings
-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 add a
-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
Subject:
-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: remoteproc board support for
OMAP
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: davinci: remoteproc board
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, Chris; Grosen, Mark
Subject
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; linux-arm-
ker...@lists.infradead.org
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.davincidsp.com; 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.infradead.org; Ring
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:
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:
-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:
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
-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
-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:
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),
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-open-source
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
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 address translation when working with Codec Engine
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
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() code
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.
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 allows me to understand your
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:
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.davincidsp.com
Subject: RE: Passing buffers
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
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:
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:
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 into
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
-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:
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
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.davincidsp.com
Subject: Re: [PATCH] DaVinci: EDMA: New API edma_free_resource
Tivy, Robert rt
,
- 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: New API edma_free_resource
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.
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
To: David Brownell
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 suggest a scheme involving some sort of
driver
-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 order
of 50 EDMA_ANY-type channels.
Sounds a bit
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,
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:
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
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
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:
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
-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.
On Thursday 11 June 2009, Tivy
-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.
On Thursday 11 June 2009, Tivy
-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
Cc:
-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;
-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; David
-linux-open-source digest...
Today's Topics:
1. Re: [PATCH 3/3 v4] ARM: da830 - Add support for
DA830/OMAP-L137 EVM (Mark A. Greer)
2. RE: Problem about DSP server config of DM6446 (Tivy, Robert)
3. Re: when port a software , bus error (zhenfeng ren)
4. Re: THS8200
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
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 might cause
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
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:
Try adding the following to your .pjt file's C compiler options.
-i%XDC_INSTALL_DIR%/packages -dxdc_target_types__=ti/targets/std.h
Regards,
- Rob
From: davinci-linux-open-source-boun...@linux.davincidsp.com
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:
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
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:
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
...@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 there anything that I can do to
then to stop getting this error, I am not doing a lot
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
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
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,
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 probably
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()
Ramesh,
Your UCTOOL_PREFIX macro is commented out. This is preventing the uClibc build
of the src/interface library, and it looks like the failure is stopping the
build and therefore not even getting around to the cmemk.ko build. Your
cmemk.ko build will just use the MVTOOL_PREFIX (we don't
Anil,
It sounds like you're doing the right things with CMEM, so I can't directly
answer your problem but do have some suggestions...
First, make sure that cmemk.ko insmod's correctly, without error (errors will
go to the console, and/or retrieved with the 'dmesg' command).
Second, after
buffer's start (minus 1).
For an explanation to this, and other answers, see below...
Regards,
- Rob
From: Omkiran Sharma [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 12, 2008 11:41 PM
To: Tivy, Robert
Cc: davinci forum
Subject: Re: Mempry Cpnversion Problem
Panchy,
You need to edit the CMEM Rules.make file to reflect your GCC tools location.
In that file is the definition
MVTOOL_PREFIX=/db/toolsrc/library/vendors2005/mvl/arm/mvl4.0-new/montavista/pro/devkit/arm/v5t_le/bin/arm_v5t_le
You need to change this to match the location of your
Santosh,
This looks like a problem with the 'insmod' command to insert CMEMK into the
kernel. Usually, the insmod command is in the loadmodules.sh script.
The CMEMK insmod command specifies pools of buffers. The application is
allocating 1658880 bytes, so you need to make sure that a pool is
The message 'no version for struct_module found: kernel tainted'
occurs because the module was not built against the kernel that is
booted. It's happening for both dsplinkk and ipv6, so both these
modules need to be rebuilt pointing to the booted kernel sources.
For CMEM, you need to insmod it
Are you using CMEM? Typically, CMEM is configured (during 'insmod',
usually from the loadmodules.sh script) to use 120MB - 128 MB.
Regards,
- Rob
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
] On Behalf Of steven.zhang
Sent: Thursday, June 26, 2008 1:33 AM
This warning is produced at GT trace level 6, so it can be disabled by
not enabling 6 in CE_TRACE (but CE_DEBUG=[1|2|3] might turn it on).
The simplest solution is to pass Memory_DEFAULTALIGNMENT in the align
parameter.
I'm not sure about the DSKT2 question, perhaps the answer is IRES/RMAN?
This assertion is produced when VISA_freeMsg() is called more times than
VISA_allocMsg(). These APIs are used by the VISA codec class
'process()' and 'control()' functions, as well as asynchronous SPIs
'processAsync()' [calls VISA_allocMsg()]and 'processWait()' [calls
VISA_freeMsg()].
It's
-Original Message-
From: steven.zhang [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 11, 2008 10:21 PM
To: Tivy, Robert
Cc: davinci
Subject: RE: cmem issure of DVEVM_1_30
Yes,USE_UDEV is disable.
If I enable it, compile error arises.
class_simple_create not define.
My kernel version
Steven,
Did you use the provided Makefile (which includes ../../Rules.make)?
There is a macro USE_UDEV that needs to be set to 1 in order to get
insmod-time /dev/cmem creation. This setting of USE_UDEV is usually
done in the provided 'make' file Rules.make and is 'consumed' in the
rule to build
1 - 100 of 123 matches
Mail list logo
