Hi Ansari,
Thank you for your response. Here's some more details. Each of my processes is
multithreaded and has 2 instances of the H264 encoder( one at D1 and another at
CIF resolutions). So when I run two process together, I expect 4 instances of
H264 encoder to run (2 at D1 resolution and 2 at CIF resolution). I'm also
attaching a debug trace log with CE_DEBUG=2 for the application that failed.
I have been able to run all the 4 instances in multiple threads as a part of a
single process in the past, and so I don't think I run out of resources. The
difference this time is that I'm running a duplicate of the same process with a
different capture for each process.
All the same, please let me know if there are any checks that could be done to
ensure that there are sufficient resources for the encoder tasks.
I'll also try and check out the DVTB application as you suggested.
Regards
Sriraja
> -----Original Message-----
> From: davinci-linux-open-source-
> [email protected]
> [mailto:davinci-linux-open-source-
> [email protected]] On Behalf
> Of M.N.D, Ansari
> Sent: Monday, April 20, 2009 11:14 AM
> To: [email protected]
> Subject: RE: Error with CE application in 2 processes
> Importance: High
>
> Hi Sriraja,
> I assume that you are trying to create two codec instances of same codec
> type from a single codec server. Also you have mentioned that you are able
> to run the processes individually and if they are executed together the
> second one fails.
> This looks like a Resource allocation failure. The resource could be
> HDVICP,DMA channals, Alg Memory.
> Can you give more details on this issue ? Also you can try the DVTB
> application which is part of the DVSDK release.
> With DVTB you should be able to run parallel processes with a single
> server.
> I tried out the following experiment to reproduce your problem.
> I ran two instances of H.264 720p encoder using DVTB, where the first
> process captures yuv data through Video Capture port and the second
> process reads a YUV file and encode the data. I'm able to run these two
> processes successfully. FYI since there are only 2 HDVICP resources are
> available in DM6467 platform and you will be able to execute upto 2 HD
> codecs simultaneously.
>
>
> Regards
> Ansari
>
> -----Original Message-----
>
> ------------------------------
>
> Message: 4
> Date: Fri, 17 Apr 2009 12:15:39 +0530
> From: Sriraja Yagneswaran <[email protected]>
> Subject: Error with CE application in 2 processes
> To: "[email protected]"
> <[email protected]>
> Message-ID:
> <[email protected]>
> Content-Type: text/plain; charset="us-ascii"
>
> Hello,
>
> I have a couple of CE applications that have to run as separate processes.
> The processes call the same server engines and are identical except that
> they have different input sources.
>
> I use the LAD, following the procedure described and start the
> applications. The processes run without any issues independently. However
> when both are run together, the application/process that starts first runs
> successfully. However the second one fails.
>
>
>
> Using CE_DEBUG=2, we find the following things,
> LAD_startupDSP() returns a status code of 4.
> Comm_create(' ) fails with status 0x80008050.
>
> I'm unable to trace the source or the reason for this failure.
>
> Please advice.
>
> We use CE 2.10.02 and DSPLINK 1.50
>
> Regards
> Sriraja
>
> ________________________________
> http://www.mindtree.com/email/disclaimer.html
> next part --------------
> An HTML attachment was scrubbed...
> URL: http://linux.omap.com/pipermail/davinci-linux-open-
> source/attachments/20090417/d3982b5b/attachment-0001.htm
>
> ------------------------------
>
> Message: 5
> Date: Fri, 17 Apr 2009 12:22:02 +0530
> From: "Bhandari, Vipin" <[email protected]>
> Subject: RE: [PATCH] ARM: DaVinci: Cleaning of DaVinci MMC driver
> To: David Brownell <[email protected]>
> Cc: "[email protected]"
> <[email protected]>
> Message-ID:
> <[email protected]>
> Content-Type: text/plain; charset="us-ascii"
>
> David,
>
> > From: David Brownell [mailto:[email protected]]
> > Sent: Thursday, April 16, 2009 2:39 AM
> >
> > > Vipin Bhandari <[email protected]> writes:
> > >
> >
> > > >
> > > > if (host->buffer_bytes_left == 0) {
> > > > - host->sg_idx++;
> > > > - BUG_ON(host->sg_idx == host->sg_len);
> > > > + host->data->sg = sg_next(host->data->sg);
> >
> > Shouldn't that be using a temp, e.g. host->sg = sg_next(host->sg)?
> >
> > Otherwise this seems like it will be clobbering the mmc_data fields,
> > and have no way to restore them when it completes. Not a good idea,
> > even if *today* it may happen not to break anything.
>
> I'll implement the same and submit the patch soon.
>
> > > > - /* Setting initialize clock */
> > > > - if (cmd->opcode == 0)
> > > > - cmd_reg |= MMCCMD_INITCK;
> > > > -
> > > > /* Enable EDMA transfer triggers */
> > > > if (host->do_dma)
> > > > cmd_reg |= MMCCMD_DMATRIG;
> >
> > I think the point of "don't check cmd->opcode" was either that
> > (a) this should be done as part of the powerup sequence, which
> > requires those clocks to be sent, or else (b) use the actual
> > opcode symbol.
> >
> > Not sending those 70-odd clocks seems, at least, unwise.
>
> Please refer to function mmc_davinci_set_ios() and inside the if statement
> for ios->power_mode == MMC_POWER_UP. 70 odd clocks are send here as you
> mentioned in point a
>
>
> > > > - if (!host->do_dma && (host->data_dir ==
> DAVINCI_MMC_DATADIR_WRITE))
> > > > - davinci_fifo_data_trans(host, 32);
> > > > + if (!host->do_dma && (host->data_dir ==
> DAVINCI_MMC_DATADIR_WRITE)
> > &&
> > > > + ((cmd->opcode == MMC_WRITE_BLOCK) ||
> > > > + (cmd->opcode == MMC_WRITE_MULTIPLE_BLOCK)))
> > > > + davinci_fifo_data_trans(host,
> DAVINCI_MMC_FIFO_SIZE_BYTE);
> > > >
> > > > writel(cmd->arg, host->base + DAVINCI_MMCARGHL);
> > > > writel(cmd_reg, host->base + DAVINCI_MMCCMD);
> >
> > That confuses me, and seems like it goes against the standard "host
> > adapters
> > should not care about specific commands" policy. Won't it prevent SDIO
> > from
> > working, for example? Would a simple "host->data != NULL" address the
> > same
> > issue? Can DATADIR_WRITE even be set to that value for a non-write
> > command?
> >
> > There are non-MMC/non-SD write commands...
>
> Please refer to the TRM of MMCSD which states as follow
> xxxxxxxxxxxxxxxxxxxx
> When starting the write transaction, the CPU is responsible for getting
> the FIFO ready to start transferring data by filling up the FIFO with data
> prior to invoking/posting the write command to the card. Filling up the
> FIFO is a requirement since no interrupt/event generates at the start of
> the write transfer.
> xxxxxxxxxxxxxxxxxxxx
> This is required only in case of non dma based transfers and that too
> during write operation.
>
> > > > + if (mmc_req_freq < 400000)
> > > > + ns_in_one_cycle = 1000000 / ((cpu_arm_clk
> > > > + / (2 * (mmc_push_pull +
> > > > 1)))/1000);
> > > > + else
> > > > + ns_in_one_cycle = 1000000 / ((cpu_arm_clk
> > > > + / (2 * (mmc_push_pull +
> > > > 1)))/1000000);
> > > > +
> > > > return mmc_push_pull;
> > > > }
> > > >
> >
> > This can't be correct on systems with multiple MMC/SD controllers.
> >
> > It's updating a global to hold a card-specific value ... where it
> > will be used by cards that are using a different clock rate. That
> > value should be in the per-controller state.
>
> Point well taken. I'll implement what you suggest.
>
> > > > - /* record how much data we transferred */
> > > > - temp = readl(host->base + DAVINCI_MMCNBLC);
> > > > - data->bytes_xfered += (data->blocks - temp) * data->blksz;
> > > > -
> > > > /* reset command and data state machines */
> > > > temp = readl(host->base + DAVINCI_MMCCTL);
> > > > writel(temp | MMCCTL_CMDRST | MMCCTL_DATRST,
> >
> > This doesn't look right ... doesn't it introduce misbehavior
> > in some of the "mmctest" cases? It's at least under-reporting
> > the number of bytes transferred (and needlessly so).
>
> This function is an abort data call which happens during timeout or crc
> errors. There is no way to tell how much of the data has been transferred,
> as it is not acknowledged. Putting data->bytes_xfered += 0; seems to be
> right but as it should have been already 0 initially so not reqd. to
> update it again.
>
>
>
> >
>
>
>
> ------------------------------
>
> Message: 6
> Date: Fri, 17 Apr 2009 00:21:09 -0700
> From: David Brownell <[email protected]>
> Subject: Re: [PATCH] ARM: DaVinci: Cleaning of DaVinci MMC driver
> To: "Bhandari, Vipin" <[email protected]>
> Cc: "[email protected]"
> <[email protected]>
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset="us-ascii"
>
> On Thursday 16 April 2009, Bhandari, Vipin wrote:
>
> > > Not sending those 70-odd clocks seems, at least, unwise.
> >
> > Please refer to function mmc_davinci_set_ios() and inside
> > the if statement for ios->power_mode == MMC_POWER_UP.
> > 70 odd clocks are send here as you mentioned in point a.
>
> And so they are. Good point; ignore that comment of mine. :)
>
>
> > > > > - if (!host->do_dma && (host->data_dir ==
> DAVINCI_MMC_DATADIR_WRITE))
> > > > > - davinci_fifo_data_trans(host, 32);
> > > > > + if (!host->do_dma && (host->data_dir ==
> DAVINCI_MMC_DATADIR_WRITE)
> > > &&
> > > > > + ((cmd->opcode == MMC_WRITE_BLOCK) ||
> > > > > + (cmd->opcode == MMC_WRITE_MULTIPLE_BLOCK)))
> > > > > + davinci_fifo_data_trans(host,
> DAVINCI_MMC_FIFO_SIZE_BYTE);
> > > > >
> > > > > writel(cmd->arg, host->base + DAVINCI_MMCARGHL);
> > > > > writel(cmd_reg, host->base + DAVINCI_MMCCMD);
> > >
> > > That confuses me, and seems like it goes against the standard "host
> > > adapters
> > > should not care about specific commands" policy. Won't it prevent
> SDIO
> > > from
> > > working, for example? Would a simple "host->data != NULL" address the
> > > same
> > > issue? Can DATADIR_WRITE even be set to that value for a non-write
> > > command?
> > >
> > > There are non-MMC/non-SD write commands...
> >
> > Please refer to the TRM of MMCSD which states as follow
> > xxxxxxxxxxxxxxxxxxxx
> > When starting the write transaction, the CPU is responsible for getting
> > the FIFO ready to start transferring data by filling up the FIFO with
> > data prior to invoking/posting the write command to the card. Filling
> > up the FIFO is a requirement since no interrupt/event generates at the
> > start of the write transfer.
> > xxxxxxxxxxxxxxxxxxxx
> > This is required only in case of non dma based transfers and that too
> > during write operation.
>
> Exactly. But there are more write transactions than those two;
> they just happen to be some of the most common ones.
>
> And from what I could see, the existing code already covered all
> of the cases: all write transactions (i.e. everything that sends
> a DATA stage to the card, using DAT0..DATx) was filling the fifo.
>
> Although there does seem to be a bug there ... it should never
> fill the fifo with more data than is being sent.
>
>
> >
> > > > > - /* record how much data we transferred */
> > > > > - temp = readl(host->base + DAVINCI_MMCNBLC);
> > > > > - data->bytes_xfered += (data->blocks - temp) * data->blksz;
> > > > > -
> > > > > /* reset command and data state machines */
> > > > > temp = readl(host->base + DAVINCI_MMCCTL);
> > > > > writel(temp | MMCCTL_CMDRST | MMCCTL_DATRST,
> > >
> > > This doesn't look right ... doesn't it introduce misbehavior
> > > in some of the "mmctest" cases? It's at least under-reporting
> > > the number of bytes transferred (and needlessly so).
> >
> > This function is an abort data call which happens during timeout
> > or crc errors. There is no way to tell how much of the data has
> > been transferred, as it is not acknowledged.
>
> Well, by *observation* that register gives the correct answer.
> Its value seems to get decremented by the ACK ... as implied by
> the documentation.
>
>
> > Putting data->bytes_xfered += 0; seems to be right but as it
> > should have been already 0 initially so not reqd. to update it again.
>
> Adding zero is always pointless. ;)
>
> - Dave
>
>
>
>
> ------------------------------
>
> _______________________________________________
> 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 40, Issue 109
> **********************************************************
> _______________________________________________
> Davinci-linux-open-source mailing list
> [email protected]
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
http://www.mindtree.com/email/disclaimer.html
Encode demo started.
@0,142,482us: [+4 T:0x00004000] OG - Global_init> This program was built with
the following packages:
@0,143,535us: [+4 T:0x00004000] OG - package gnu.targets.rts470MV
(/home/test/dvsdk_1_40_02_33/xdc_3_00_06/packages/gnu/targets/rts470MV/)
[1,0,0,0,1203621000516]
@0,143,832us: [+4 T:0x00004000] OG - package ti.sdo.codecs.h264enc
(/home/test/dvsdk_1_40_02_33/dm6467_dvsdk_combos_1_17/packages/ti/sdo/codecs/h264enc/)
[1,0,0,1221669049000]
@0,144,010us: [+4 T:0x00004000] OG - package ti.sdo.codecs.aacenc
(/home/test/dvsdk_1_40_02_33/dm6467_dvsdk_combos_1_17/packages/ti/sdo/codecs/aacenc/)
[1,0,0,1221669048000]
@0,144,160us: [+4 T:0x00004000] OG - package ti.sdo.codecs.g711enc
(/home/test/dvsdk_1_40_02_33/dm6467_dvsdk_combos_1_17/packages/ti/sdo/codecs/g711enc/)
[1,0,0,1221669048000]
@0,144,307us: [+4 T:0x00004000] OG - package ti.xdais.dm
(/home/test/dvsdk_1_40_02_33/xdais_6_10_01/packages/ti/xdais/dm/)
[1,0,4,1210262746529]
@0,144,449us: [+4 T:0x00004000] OG - package ti.xdais
(/home/test/dvsdk_1_40_02_33/xdais_6_10_01/packages/ti/xdais/)
[1,2,1,1210262742149]
@0,144,588us: [+4 T:0x00004000] OG - package ti.sdo.utils.trace
(/home/test/dvsdk_1_40_02_33/framework_components_2_10_02/packages/ti/sdo/utils/trace/)
[1,0,0,1220943366422]
@0,144,728us: [+4 T:0x00004000] OG - package ti.sdo.ce.utils.xdm
(/home/test/dvsdk_1_40_02_33/codec_engine_2_10_02/packages/ti/sdo/ce/utils/xdm/)
[1,0,1,1220951322616]
@0,144,867us: [+4 T:0x00004000] OG - package ti.sdo.fc.dman3
(/home/test/dvsdk_1_40_02_33/framework_components_2_10_02/packages/ti/sdo/fc/dman3/)
[1,0,3,1220943053023]
@0,145,008us: [+4 T:0x00004000] OG - package ti.sdo.fc.acpy3
(/home/test/dvsdk_1_40_02_33/framework_components_2_10_02/packages/ti/sdo/fc/acpy3/)
[1,0,2,1220943014135]
@0,145,156us: [+4 T:0x00004000] OG - package dsplink.gpp
(/home/test/dvsdk_1_40_02_33/dsplink-davinci-v1.50-prebuilt/packages/dsplink/gpp/)
[3,0,0]
@0,145,301us: [+4 T:0x00004000] OG - package ti.sdo.linuxutils.cmem
(/home/test/dvsdk_1_40_02_33/cmem_2_10/packages/ti/sdo/linuxutils/cmem/)
[2,0,1,1204929560755]
@0,145,449us: [+4 T:0x00004000] OG - package ti.dsplink.utils.ladclient
(/home/test/dvsdk_1_40_02_33/codec_engine_2_10_02/packages/ti/dsplink/utils/ladclient/)
[1,0,0,1220950764382]
@0,145,603us: [+4 T:0x00004000] OG - package ti.catalog.c470
(/home/test/dvsdk_1_40_02_33/xdc_3_00_06/packages/ti/catalog/c470/)
[1,0,1,0,1203561761475]
@0,145,743us: [+4 T:0x00004000] OG - package ti.catalog.c6000
(/home/test/dvsdk_1_40_02_33/xdc_3_00_06/packages/ti/catalog/c6000/)
[1,0,0,0,1203561781695]
@0,145,889us: [+4 T:0x00004000] OG - package ti.platforms.evmDM6467
(/home/test/dvsdk_1_40_02_33/xdc_3_00_06/packages/ti/platforms/evmDM6467/)
[1,0,0,0,1203562062227]
@0,146,010us: [+4 T:0x00004000] OG - package ti.sdo.ce.osal
(/home/test/dvsdk_1_40_02_33/codec_engine_2_10_02/packages/ti/sdo/ce/osal/)
[2,0,2,1220951127739]
@0,146,124us: [+4 T:0x00004000] OG - package ti.sdo.ce.ipc
(/home/test/dvsdk_1_40_02_33/codec_engine_2_10_02/packages/ti/sdo/ce/ipc/)
[2,0,1,1220951085787]
@0,146,236us: [+4 T:0x00004000] OG - package ti.sdo.ce.osal.linux
(/home/test/dvsdk_1_40_02_33/codec_engine_2_10_02/packages/ti/sdo/ce/osal/linux/)
[2,0,1,1220951140072]
@0,146,407us: [+4 T:0x00004000] OG - package ti.sdo.ce.ipc.dsplink
(/home/test/dvsdk_1_40_02_33/codec_engine_2_10_02/packages/ti/sdo/ce/ipc/dsplink/)
[2,0,1,1220951096818]
@0,147,244us: [+4 T:0x00004000] OG - package ti.sdo.ce.alg
(/home/test/dvsdk_1_40_02_33/codec_engine_2_10_02/packages/ti/sdo/ce/alg/)
[1,0,1,1220950781938]
@0,147,428us: [+4 T:0x00004000] OG - package ti.sdo.ce
(/home/test/dvsdk_1_40_02_33/codec_engine_2_10_02/packages/ti/sdo/ce/)
[1,0,6,1220950771473]
@0,147,585us: [+4 T:0x00004000] OG - package ti.sdo.ce.video1
(/home/test/dvsdk_1_40_02_33/codec_engine_2_10_02/packages/ti/sdo/ce/video1/)
[1,0,2,1220951340734]
@0,147,742us: [+4 T:0x00004000] OG - package ti.sdo.codecs.h264enc.ce
(/home/test/dvsdk_1_40_02_33/dm6467_dvsdk_combos_1_17/packages/ti/sdo/codecs/h264enc/ce/)
[1,0,0,1221669049000]
@0,147,952us: [+4 T:0x00004000] OG - package ti.sdo.ce.audio
(/home/test/dvsdk_1_40_02_33/codec_engine_2_10_02/packages/ti/sdo/ce/audio/)
[1,0,2,1220950788137]
@0,148,121us: [+4 T:0x00004000] OG - package ti.sdo.codecs.aacenc.ce
(/home/test/dvsdk_1_40_02_33/dm6467_dvsdk_combos_1_17/packages/ti/sdo/codecs/aacenc/ce/)
[1,0,0,1221669048000]
@0,148,273us: [+4 T:0x00004000] OG - package ti.sdo.ce.speech
(/home/test/dvsdk_1_40_02_33/codec_engine_2_10_02/packages/ti/sdo/ce/speech/)
[1,0,2,1220951161404]
@0,148,427us: [+4 T:0x00004000] OG - package ti.sdo.codecs.g711enc.ce
(/home/test/dvsdk_1_40_02_33/dm6467_dvsdk_combos_1_17/packages/ti/sdo/codecs/g711enc/ce/)
[1,0,0,1221669048000]
@0,148,573us: [+4 T:0x00004000] OG - package ti.sdo.ce.speech1
(/home/test/dvsdk_1_40_02_33/codec_engine_2_10_02/packages/ti/sdo/ce/speech1/)
[1,0,1,1220951167662]
@0,148,716us: [+4 T:0x00004000] OG - package ti.sdo.ce.video
(/home/test/dvsdk_1_40_02_33/codec_engine_2_10_02/packages/ti/sdo/ce/video/)
[1,0,3,1220951334122]
@0,148,868us: [+4 T:0x00004000] OG - package ti.sdo.ce.video2
(/home/test/dvsdk_1_40_02_33/codec_engine_2_10_02/packages/ti/sdo/ce/video2/)
[1,0,2,1220951347240]
@0,149,012us: [+4 T:0x00004000] OG - package ti.sdo.dmai
(/home/test/dvsdk_1_40_02_33/dmai_1_10_00_06/packages/ti/sdo/dmai/)
[1,0,0,1227609230000]
@0,149,152us: [+4 T:0x00004000] OG - package ti.sdo.simplewidget
(/home/test/dvsdk_1_40_02_33/dvsdk_demos_1_40_00_18/packages/ti/sdo/simplewidget/)
[]
@0,149,288us: [+4 T:0x00004000] OG - package ti.sdo.ce.bioslog
(/home/test/dvsdk_1_40_02_33/codec_engine_2_10_02/packages/ti/sdo/ce/bioslog/)
[1,0,1,1220950800329]
@0,149,430us: [+4 T:0x00004000] OG - package ti.sdo.ce.utils.trace
(/home/test/dvsdk_1_40_02_33/codec_engine_2_10_02/packages/ti/sdo/ce/utils/trace/)
[1,0,1,1220951317087]
@0,149,571us: [+4 T:0x00004000] OG - package CAE_App_Dev_config
(/home/test/dvsdk_1_40_02_33/dvsdk_demos_1_40_00_18/dm6467/CAE_App_Dev/lib/CAE_App_Dev_config/)
[]
@0,154,532us: [+0 T:0x00004000] ti.sdo.ce.osal.Sem - Sem_create> count: 0
@0,154,728us: [+0 T:0x00004000] ti.sdo.ce.osal.Sem - Leaving Sem_create>
sem[0x58208]
@0,154,862us: [+0 T:0x00004000] ti.sdo.ce.osal.Sem - Sem_create> count: 0
@0,154,985us: [+0 T:0x00004000] ti.sdo.ce.osal.Sem - Leaving Sem_create>
sem[0x58220]
@0,155,115us: [+0 T:0x00004000] OT - Thread_create> Enter (fxn=0x26244,
attrs=0x0)
@0,156,643us: [+1 T:0x00004002] OP - daemon> thread created.
@0,156,806us: [+0 T:0x00004002] OP - getCmd_d> Enter (proc=0xbe7ffaec)
@0,156,932us: [+0 T:0x00004002] ti.sdo.ce.osal.Sem - Entered Sem_pend>
sem[0x58208] timeout[0xffffffff]
@0,157,143us: [+0 T:0x00004000] OT - Thread_create> Exit (task=0x58258)
@0,157,443us: [+0 T:0x00004000] ti.sdo.ce.alg - ALG_init> Enter
@0,157,594us: [+0 T:0x00004000] ti.sdo.ce.alg - ALG_init> Exit
@1,180,439us: [+6 T:0x00004000] CE - Engine_init> CE debugging on (CE_DEBUG=2;
allowed CE_DEBUG levels: 1=min, 2=good, 3=max)
@1,180,996us: [+0 T:0x00004000] CS - Server_init()
@1,181,210us: [+0 T:0x00004000] CS - Server_init> Global_useLinkArbiter = 1
TraceUtil_start> note: CE_DEBUG env. var is set, so TraceUtil is not active
(unset CE_DEBUG if you need TraceUtil)
@1,190,275us: [+2 T:0x00008003] ti.sdo.dmai - [BufTab] Allocating BufTab for 4
buffers
@1,190,683us: [+4 T:0x00008003] OM - Memory_contigAlloc> CMEM_alloc(691200) =
0x40313000.
@1,190,870us: [+4 T:0x00008003] OM - Memory_contigAlloc>
CMEM_getPhys(0x40313000) = 0x8aabf000.
@1,191,030us: [+2 T:0x00008003] ti.sdo.dmai - [Buffer] Alloc Buffer of size
691200 at 0x40313000 (0x8aabf000 phys)
@1,191,436us: [+4 T:0x00008003] OM - Memory_contigAlloc> CMEM_alloc(691200) =
0x403de000.
@1,191,616us: [+4 T:0x00008003] OM - Memory_contigAlloc>
CMEM_getPhys(0x403de000) = 0x8a9f4000.
@1,191,779us: [+2 T:0x00008003] ti.sdo.dmai - [Buffer] Alloc Buffer of size
691200 at 0x403de000 (0x8a9f4000 phys)
@1,192,102us: [+4 T:0x00008003] OM - Memory_contigAlloc> CMEM_alloc(691200) =
0x404a9000.
@1,192,277us: [+4 T:0x00008003] OM - Memory_contigAlloc>
CMEM_getPhys(0x404a9000) = 0x8a929000.
@1,192,489us: [+2 T:0x00008003] ti.sdo.dmai - [Buffer] Alloc Buffer of size
691200 at 0x404a9000 (0x8a929000 phys)
@1,192,852us: [+4 T:0x00008003] OM - Memory_contigAlloc> CMEM_alloc(691200) =
0x40574000.
@1,193,033us: [+4 T:0x00008003] OM - Memory_contigAlloc>
CMEM_getPhys(0x40574000) = 0x8a85e000.
@1,193,198us: [+2 T:0x00008003] ti.sdo.dmai - [Buffer] Alloc Buffer of size
691200 at 0x40574000 (0x8a85e000 phys)
@1,197,615us: [+0 T:0x0000c004] CE - Engine_open> Enter('encode', 0x0,
0xbe3ff7c4)
@1,197,824us: [+0 T:0x0000c004] CE - rserverOpen('encodeCombo.x64P'), count = 0
@1,197,965us: [+0 T:0x0000c004] OP - Processor_create>
Enter(imageName='encodeCombo.x64P', linkCfg='CE_default6467', attrs=0xbe3ff7c8)
@1,198,115us: [+0 T:0x0000c004] OP - doCmd> Enter (cmdId=1, proc=0x5ac50)
@1,198,238us: [+0 T:0x0000c004] ti.sdo.ce.osal.Sem - Entered Sem_post>
sem[0x58208]
@1,198,427us: [+0 T:0x0000c004] ti.sdo.ce.osal.Sem - Leaving Sem_post>
sem[0x58208]
@1,198,573us: [+0 T:0x0000c004] ti.sdo.ce.osal.Sem - Entered Sem_pend>
sem[0x58220] timeout[0xffffffff]
@1,198,862us: [+0 T:0x00004002] ti.sdo.ce.osal.Sem - Leaving Sem_pend>
sem[0x58208] status[0]
@1,199,027us: [+0 T:0x00004002] OP - getCmd_d> Exit (result=1)
@1,199,154us: [+0 T:0x00004002] OP - Processor_create_d> Enter(proc=0x5ac50)
@1,464,581us: [+2 T:0x00008003] ti.sdo.dmai - [Capture] Capture input set to
COMPOSITE
@1,464,818us: [+2 T:0x00008003] ti.sdo.dmai - [Capture] Video input connected
size 720x480 pitch 720
@1,775,590us: [+2 T:0x00004002] OP - Processor_create_d> LAD_connect status =
0, handle = 1
@1,775,764us: [+2 T:0x00004002] OP - Processor_create_d> Loading
encodeCombo.x64P on DSP, linkConfigName= CE_default6467 ...
@1,783,598us: [+2 T:0x00004002] OP - Processor_create_d> LAD_startupDsp status
= 4
@1,789,676us: [+2 T:0x00004002] OP - Processor_create_d> return (1)
@1,789,846us: [+0 T:0x00004002] ti.sdo.ce.osal.Sem - Entered Sem_post>
sem[0x58220]
@1,790,103us: [+0 T:0x0000c004] ti.sdo.ce.osal.Sem - Leaving Sem_pend>
sem[0x58220] status[0]
@1,790,263us: [+0 T:0x0000c004] OP - doCmd> Exit (result=1)
@1,790,409us: [+0 T:0x0000c004] OP - Processor_create> return (0x5ac50)
@1,790,530us: [+0 T:0x0000c004] CE - rserverOpen('encodeCombo.x64P'): 0x56678
done.
@1,790,731us: [+6 T:0x0000c004] OC - Comm_create('encode_0', ...) failed:
status 0x80008050
@1,790,974us: [+0 T:0x0000c004] CE - Engine_close(0x5ac20)
@1,791,133us: [+0 T:0x0000c004] CE - rserverClose(0x56678), count = 1
@1,791,264us: [+0 T:0x0000c004] OP - Processor_delete> Enter(proc=0x5ac50)
@1,791,388us: [+0 T:0x0000c004] OP - doCmd> Enter (cmdId=2, proc=0x5ac50)
@1,791,506us: [+0 T:0x0000c004] ti.sdo.ce.osal.Sem - Entered Sem_post>
sem[0x58208]
@1,791,619us: [+0 T:0x0000c004] ti.sdo.ce.osal.Sem - Leaving Sem_post>
sem[0x58208]
@1,791,732us: [+0 T:0x0000c004] ti.sdo.ce.osal.Sem - Entered Sem_pend>
sem[0x58220] timeout[0xffffffff]
@1,792,037us: [+0 T:0x00004002] ti.sdo.ce.osal.Sem - Leaving Sem_post>
sem[0x58220]
@1,792,196us: [+0 T:0x00004002] OP - getCmd_d> Enter (proc=0xbe7ffaec)
@1,792,319us: [+0 T:0x00004002] ti.sdo.ce.osal.Sem - Entered Sem_pend>
sem[0x58208] timeout[0xffffffff]
@1,792,442us: [+0 T:0x00004002] ti.sdo.ce.osal.Sem - Leaving Sem_pend>
sem[0x58208] status[0]
@1,792,563us: [+0 T:0x00004002] OP - getCmd_d> Exit (result=2)
@1,792,677us: [+0 T:0x00004002] OP - Processor_delete_d> Enter (proc=0x5ac50)
@1,792,794us: [+2 T:0x00004002] OP - Processor_delete_d> Closing pool...
@1,793,372us: [+2 T:0x00004002] OP - Processor_delete_d> Detaching before
LAD_releaseDsp...
@1,801,246us: [+2 T:0x00004002] OP - Processor_delete_d> Releasing DSP via
LAD_releaseDsp...
@1,801,963us: [+2 T:0x00004002] OP - Processor_delete_d> Disconnecting from
LAD...
@1,842,835us: [+0 T:0x00004002] OP - Processor_delete_d> return
@1,843,027us: [+0 T:0x00004002] ti.sdo.ce.osal.Sem - Entered Sem_post>
sem[0x58220]
@1,844,505us: [+0 T:0x0000c004] ti.sdo.ce.osal.Sem - Leaving Sem_pend>
sem[0x58220] status[0]
@1,844,739us: [+0 T:0x0000c004] OP - doCmd> Exit (result=1)
@1,844,921us: [+1 T:0x0000c004] OP - Processor_delete(0x5ac50) freeing object
...
@1,845,176us: [+0 T:0x0000c004] OP - Processor_delete> return.
@1,845,356us: [+0 T:0x0000c004] CE - rserverClose(0x56678) done.
@1,845,543us: [+0 T:0x0000c004] CE - Engine_open> return(0)
@1,846,397us: [+0 T:0x00004002] ti.sdo.ce.osal.Sem - Leaving Sem_post>
sem[0x58220]
@1,846,615us: [+0 T:0x00004002] OP - getCmd_d> Enter (proc=0xbe7ffaec)
@1,846,751us: [+0 T:0x00004002] ti.sdo.ce.osal.Sem - Entered Sem_pend>
sem[0x58208] timeout[0xffffffff]
@1,856,171us: [+2 T:0x00014005] ti.sdo.dmai - [BufTab] Allocating BufTab for 2
buffers
@1,856,606us: [+4 T:0x00014005] OM - Memory_contigAlloc> CMEM_alloc(0) =
0x4001b000.
@1,856,858us: [+4 T:0x00014005] OM - Memory_contigAlloc>
CMEM_getPhys(0x4001b000) = 0x897a5000.
@1,857,146us: [+2 T:0x00014005] ti.sdo.dmai - [Buffer] Alloc Buffer of size 0
at 0x4001b000 (0x897a5000 phys)
@1,857,535us: [+4 T:0x00014005] OM - Memory_contigAlloc> CMEM_alloc(0) =
0x40020000.
@1,857,786us: [+4 T:0x00014005] OM - Memory_contigAlloc>
CMEM_getPhys(0x40020000) = 0x897a2000.
@1,858,020us: [+2 T:0x00014005] ti.sdo.dmai - [Buffer] Alloc Buffer of size 0
at 0x40020000 (0x897a2000 phys)
@1,860,126us: [+2 T:0x00018006] ti.sdo.dmai - [BufTab] Allocating BufTab for 3
buffers
@1,860,606us: [+4 T:0x00018006] OM - Memory_contigAlloc> CMEM_alloc(202752) =
0x4063f000.
@1,861,294us: [+4 T:0x00018006] OM - Memory_contigAlloc>
CMEM_getPhys(0x4063f000) = 0x8b99a000.
@1,861,818us: [+2 T:0x00018006] ti.sdo.dmai - [Buffer] Alloc Buffer of size
202752 at 0x4063f000 (0x8b99a000 phys)
@1,862,323us: [+4 T:0x00018006] OM - Memory_contigAlloc> CMEM_alloc(202752) =
0x406a5000.
@1,862,532us: [+4 T:0x00018006] OM - Memory_contigAlloc>
CMEM_getPhys(0x406a5000) = 0x8b934000.
@1,862,845us: [+2 T:0x00018006] ti.sdo.dmai - [Buffer] Alloc Buffer of size
202752 at 0x406a5000 (0x8b934000 phys)
@1,863,267us: [+4 T:0x00018006] OM - Memory_contigAlloc> CMEM_alloc(202752) =
0x4070b000.
@1,863,567us: [+4 T:0x00018006] OM - Memory_contigAlloc>
CMEM_getPhys(0x4070b000) = 0x8b8ce000.
@1,863,836us: [+2 T:0x00018006] ti.sdo.dmai - [Buffer] Alloc Buffer of size
202752 at 0x4070b000 (0x8b8ce000 phys)
@1,874,223us: [+0 T:0x0001c007] CE - Engine_open> Enter('encode', 0x0,
0xbddff7bc)
@1,874,526us: [+0 T:0x0001c007] CE - rserverOpen('encodeCombo.x64P'), count = 0
@1,874,701us: [+0 T:0x0001c007] OP - Processor_create>
Enter(imageName='encodeCombo.x64P', linkCfg='CE_default6467', attrs=0xbddff7c0)
@1,874,903us: [+0 T:0x0001c007] OP - doCmd> Enter (cmdId=1, proc=0x5ac50)
@1,875,073us: [+0 T:0x0001c007] ti.sdo.ce.osal.Sem - Entered Sem_post>
sem[0x58208]
@1,875,295us: [+0 T:0x0001c007] ti.sdo.ce.osal.Sem - Leaving Sem_post>
sem[0x58208]
@1,875,480us: [+0 T:0x0001c007] ti.sdo.ce.osal.Sem - Entered Sem_pend>
sem[0x58220] timeout[0xffffffff]
@1,876,689us: [+0 T:0x00004002] ti.sdo.ce.osal.Sem - Leaving Sem_pend>
sem[0x58208] status[0]
@1,876,968us: [+0 T:0x00004002] OP - getCmd_d> Exit (result=1)
@1,877,155us: [+0 T:0x00004002] OP - Processor_create_d> Enter(proc=0x5ac50)
@3,711,554us: [+2 T:0x00004002] OP - Processor_create_d> LAD_connect status =
0, handle = 1
@3,711,814us: [+2 T:0x00004002] OP - Processor_create_d> Loading
encodeCombo.x64P on DSP, linkConfigName= CE_default6467 ...
@3,713,334us: [+2 T:0x00004002] OP - Processor_create_d> LAD_startupDsp status
= 4
@3,716,004us: [+2 T:0x00004002] OP - Processor_create_d> return (1)
@3,716,260us: [+0 T:0x00004002] ti.sdo.ce.osal.Sem - Entered Sem_post>
sem[0x58220]
@3,716,564us: [+0 T:0x0001c007] ti.sdo.ce.osal.Sem - Leaving Sem_pend>
sem[0x58220] status[0]
@3,716,788us: [+0 T:0x0001c007] OP - doCmd> Exit (result=1)
@3,716,957us: [+0 T:0x0001c007] OP - Processor_create> return (0x5ac50)
@3,717,130us: [+0 T:0x0001c007] CE - rserverOpen('encodeCombo.x64P'): 0x56678
done.
@3,717,430us: [+6 T:0x0001c007] OC - Comm_create('encode_1', ...) failed:
status 0x80008050
@3,717,653us: [+0 T:0x0001c007] CE - Engine_close(0x5b4d8)
@3,717,840us: [+0 T:0x0001c007] CE - rserverClose(0x56678), count = 1
@3,718,011us: [+0 T:0x0001c007] OP - Processor_delete> Enter(proc=0x5ac50)
@3,718,269us: [+0 T:0x0001c007] OP - doCmd> Enter (cmdId=2, proc=0x5ac50)
@3,718,455us: [+0 T:0x0001c007] ti.sdo.ce.osal.Sem - Entered Sem_post>
sem[0x58208]
@3,718,626us: [+0 T:0x0001c007] ti.sdo.ce.osal.Sem - Leaving Sem_post>
sem[0x58208]
@3,718,792us: [+0 T:0x0001c007] ti.sdo.ce.osal.Sem - Entered Sem_pend>
sem[0x58220] timeout[0xffffffff]
@3,719,010us: [+0 T:0x00004002] ti.sdo.ce.osal.Sem - Leaving Sem_post>
sem[0x58220]
@3,719,208us: [+0 T:0x00004002] OP - getCmd_d> Enter (proc=0xbe7ffaec)
@3,719,375us: [+0 T:0x00004002] ti.sdo.ce.osal.Sem - Entered Sem_pend>
sem[0x58208] timeout[0xffffffff]
@3,719,546us: [+0 T:0x00004002] ti.sdo.ce.osal.Sem - Leaving Sem_pend>
sem[0x58208] status[0]
@3,719,710us: [+0 T:0x00004002] OP - getCmd_d> Exit (result=2)
@3,719,874us: [+0 T:0x00004002] OP - Processor_delete_d> Enter (proc=0x5ac50)
@3,720,328us: [+2 T:0x00004002] OP - Processor_delete_d> Closing pool...
@3,721,078us: [+2 T:0x00004002] OP - Processor_delete_d> Detaching before
LAD_releaseDsp...
@3,734,889us: [+2 T:0x00004002] OP - Processor_delete_d> Releasing DSP via
LAD_releaseDsp...
@3,735,647us: [+2 T:0x00004002] OP - Processor_delete_d> Disconnecting from
LAD...
@3,740,308us: [+0 T:0x00004002] OP - Processor_delete_d> return
@3,740,562us: [+0 T:0x00004002] ti.sdo.ce.osal.Sem - Entered Sem_post>
sem[0x58220]
@3,740,875us: [+0 T:0x0001c007] ti.sdo.ce.osal.Sem - Leaving Sem_pend>
sem[0x58220] status[0]
@3,741,093us: [+0 T:0x0001c007] OP - doCmd> Exit (result=1)
@3,741,269us: [+1 T:0x0001c007] OP - Processor_delete(0x5ac50) freeing object
...
@3,741,443us: [+0 T:0x0001c007] OP - Processor_delete> return.
@3,741,604us: [+0 T:0x0001c007] CE - rserverClose(0x56678) done.
@3,741,781us: [+0 T:0x0001c007] CE - Engine_open> return(0)
@3,742,542us: [+0 T:0x00004002] ti.sdo.ce.osal.Sem - Leaving Sem_post>
sem[0x58220]
@3,742,774us: [+0 T:0x00004002] OP - getCmd_d> Enter (proc=0xbe7ffaec)
@3,742,958us: [+0 T:0x00004002] ti.sdo.ce.osal.Sem - Entered Sem_pend>
sem[0x58208] timeout[0xffffffff]
@3,799,578us: [+2 T:0x00024008] ti.sdo.dmai - [BufTab] Allocating BufTab for 2
buffers
@3,800,171us: [+4 T:0x00024008] OM - Memory_contigAlloc> CMEM_alloc(0) =
0x40023000.
@3,800,367us: [+4 T:0x00024008] OM - Memory_contigAlloc>
CMEM_getPhys(0x40023000) = 0x8979f000.
@3,800,565us: [+2 T:0x00024008] ti.sdo.dmai - [Buffer] Alloc Buffer of size 0
at 0x40023000 (0x8979f000 phys)
@3,800,850us: [+4 T:0x00024008] OM - Memory_contigAlloc> CMEM_alloc(0) =
0x40026000.
@3,801,033us: [+4 T:0x00024008] OM - Memory_contigAlloc>
CMEM_getPhys(0x40026000) = 0x8979c000.
@3,801,226us: [+2 T:0x00024008] ti.sdo.dmai - [Buffer] Alloc Buffer of size 0
at 0x40026000 (0x8979c000 phys)
@3,813,172us: [+2 T:0x00008003] ti.sdo.dmai - [Buffer] Free Buffer of size
691200 at 0x40313000 (0x8aabf000 phys)
@3,814,420us: [+2 T:0x00008003] ti.sdo.dmai - [Buffer] Free Buffer of size
691200 at 0x403de000 (0x8a9f4000 phys)
@3,815,605us: [+2 T:0x00008003] ti.sdo.dmai - [Buffer] Free Buffer of size
691200 at 0x404a9000 (0x8a929000 phys)
@3,816,814us: [+2 T:0x00008003] ti.sdo.dmai - [Buffer] Free Buffer of size
691200 at 0x40574000 (0x8a85e000 phys)
@3,819,626us: [+2 T:0x00018006] ti.sdo.dmai - [Buffer] Free Buffer of size
202752 at 0x4063f000 (0x8b99a000 phys)
@3,820,604us: [+2 T:0x00018006] ti.sdo.dmai - [Buffer] Free Buffer of size
202752 at 0x406a5000 (0x8b934000 phys)
@3,821,127us: [+2 T:0x00018006] ti.sdo.dmai - [Buffer] Free Buffer of size
202752 at 0x4070b000 (0x8b8ce000 phys)
@3,822,918us: [+2 T:0x00024008] ti.sdo.dmai - [Buffer] Free Buffer of size 0 at
0x40023000 (0x8979f000 phys)
@3,823,202us: [+2 T:0x00024008] ti.sdo.dmai - [Buffer] Free Buffer of size 0 at
0x40026000 (0x8979c000 phys)
@3,823,835us: [+2 T:0x00014005] ti.sdo.dmai - [Buffer] Free Buffer of size 0 at
0x4001b000 (0x897a5000 phys)
@3,824,117us: [+2 T:0x00014005] ti.sdo.dmai - [Buffer] Free Buffer of size 0 at
0x40020000 (0x897a2000 phys)
@3,881,646us: [+0 T:0x00004000] OP - doCmd> Enter (cmdId=3, proc=0x0)
@3,890,159us: [+0 T:0x00004000] ti.sdo.ce.osal.Sem - Entered Sem_post>
sem[0x58208]
@3,890,391us: [+0 T:0x00004000] ti.sdo.ce.osal.Sem - Leaving Sem_post>
sem[0x58208]
@3,890,649us: [+0 T:0x00004000] ti.sdo.ce.osal.Sem - Entered Sem_pend>
sem[0x58220] timeout[0xffffffff]
@3,891,606us: [+0 T:0x00004002] ti.sdo.ce.osal.Sem - Leaving Sem_pend>
sem[0x58208] status[0]
@3,891,837us: [+0 T:0x00004002] OP - getCmd_d> Exit (result=3)
@3,892,013us: [+0 T:0x00004002] ti.sdo.ce.osal.Sem - Entered Sem_post>
sem[0x58220]
@3,892,222us: [+0 T:0x00004002] ti.sdo.ce.osal.Sem - Leaving Sem_post>
sem[0x58220]
@3,892,851us: [+0 T:0x00004000] ti.sdo.ce.osal.Sem - Leaving Sem_pend>
sem[0x58220] status[0]
@3,893,095us: [+0 T:0x00004000] OP - doCmd> Exit (result=1)
@3,893,268us: [+0 T:0x00004000] OT - Thread_delete> Enter (task=0x58258)
@3,893,498us: [+4 T:0x00004000] OT - Thread_delete> pthread_cancel (0x3)
@3,905,156us: [+4 T:0x00004000] OT - Thread_delete> pthread_join (0x0)
@3,905,345us: [+0 T:0x00004000] OT - Thread_delete> Exit (task=0x58258)
@3,905,485us: [+0 T:0x00004000] ti.sdo.ce.osal.Sem - Entered Sem_delete>
sem[0x58208]
@3,905,650us: [+0 T:0x00004000] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@3,905,778us: [+0 T:0x00004000] ti.sdo.ce.osal.Sem - Entered Sem_delete>
sem[0x58220]
@3,905,910us: [+0 T:0x00004000] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
