Re: Codec engine hangs when during TraceUtil_start function
Hello Anand,
I set the CE_DEBUG parametr to 2 and 3 value which must basically
enable all the traces from teh ARM and DSP side. Still I am unable to
see the DSP side traces.
Bhushan
On Tue, May 5, 2009 at 11:02 AM, Balagopalakrishnan, Anand
ana...@ti.com wrote:
What are the attributes configured for TraceUtil in the XDC cfg file? By
default, the CE traces will be redirected to /tmp/cearmlog.txt. It looks like
you have set the environment variables CE_TRACEFILE so it gets redirected to
trace/cearmlog.txt. If the directory trace doesn't exist, there would be
errors.
If you don't *need* TraceUtil specifically - if you just want to observe the
DSP side traces for debugging, a better (and easier) option would be to use
CE_DEBUG:
http://tiexpressdsp.com/index.php?title=CE_DEBUG
When using CE_DEBUG, the traces will automatically come to the console. There
is no need to change the ARM application code.
Best Regards,
Anand Balagopalakrishnan
Texas Instruments
India
-Original Message-
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of
bhushan
Sent: Monday, May 04, 2009 5:07 PM
To: davinci-linux-open-source@linux.davincidsp.com
Subject: Codec engine hangs when during TraceUtil_start function
Hi,
I am developing an application based on the codec_engine. For the
same I want to see the DSP side traces for the various codecs used. So
I have added TraceUtil_start(EngineName) function after Engine_open
api.
But the application hangs because of TraceUtil_start.
Following are the logs:
# ./vs_appd -f ../test_vectors/ws_uyvy.yuv
# TraceUtil Warning: Failed to open local log file
trace/cearmlog.txt, using stdout
TraceUtil Warning: Failed to open dsp CE log file
trace/cedsp0log.txt, using stdout
TraceUtil Warning: Failed to open dsp/bios log file
trace/bioslog.dat, disabling log
@0x0002c12e:[T:0x4002] OP - daemon thread created.
@0x000447be:[T:0x8003] OM - Memory_getPhysicalAddress
Enter(virtAddr=0x40556000)
@0x000448ee:[T:0x8003] OM - Memory__getPhysicalAddress
Enter(virtAddr=0x40556000, size=1)
@0x000449e4:[T:0x8003] OM - Memory__getPhysicalAddress returning
physAddr=0x0
@0x00044aad:[T:0x8003] OM - Memory_getPhysicalAddress return (0x8280)
@0x0004ae67:[T:0x8003] OM - Memory_getPhysicalAddress
Enter(virtAddr=0x40655000)
@0x0004af56:[T:0x8003] OM - Memory__getPhysicalAddress
Enter(virtAddr=0x40655000, size=1)
@0x0004b01c:[T:0x8003] OM - Memory__getPhysicalAddress returning
physAddr=0x0
@0x0004b0db:[T:0x8003] OM - Memory_getPhysicalAddress return (0x828ff000)
@0x000514b1:[T:0x8003] OM - Memory_getPhysicalAddress
Enter(virtAddr=0x40754000)
@0x0005159c:[T:0x8003] OM - Memory__getPhysicalAddress
Enter(virtAddr=0x40754000, size=1)
@0x00051662:[T:0x8003] OM - Memory__getPhysicalAddress returning
physAddr=0x0
@0x0005173e:[T:0x8003] OM - Memory_getPhysicalAddress return (0x829fe000)
7792:junk2009
NT:No passwd file available, taking factory passwd
REQCFG
REQCFG
7792:junk2009
NT:No passwd file available, taking factory passwd
SETCFG
SETCFG
Rszcopy Debug: Configuring resizer job to copy image of resolution 320x240
@0x00595d34:[T:0x8003] OM - Memory_getPhysicalAddress
Enter(virtAddr=0x408ed000)
@0x00595e64:[T:0x8003] OM - Memory__getPhysicalAddress
Enter(virtAddr=0x408ed000, size=1)
@0x00595f56:[T:0x8003] OM - Memory__getPhysicalAddress returning
physAddr=0x0
@0x00596023:[T:0x8003] OM - Memory_getPhysicalAddress return (0x8280)
@0x0059c413:[T:0x8003] OM - Memory_getPhysicalAddress
Enter(virtAddr=0x409ec000)
@0x0059c4fd:[T:0x8003] OM - Memory__getPhysicalAddress
Enter(virtAddr=0x409ec000, size=1)
@0x0059c5bd:[T:0x8003] OM - Memory__getPhysicalAddress returning
physAddr=0x0
@0x0059c677:[T:0x8003] OM - Memory_getPhysicalAddress return (0x828ff000)
@0x005a2a2a:[T:0x8003] OM - Memory_getPhysicalAddress
Enter(virtAddr=0x40aeb000)
@0x005a2b14:[T:0x8003] OM - Memory__getPhysicalAddress
Enter(virtAddr=0x40aeb000, size=1)
@0x005a2bd7:[T:0x8003] OM - Memory__getPhysicalAddress returning
physAddr=0x0
@0x005a2caa:[T:0x8003] OM - Memory_getPhysicalAddress return (0x829fe000)
@0x005a4d85:[T:0x00010005] CE - Engine_open('scale', 0x0, 0xbe1ffa3c)
@0x005a4eb6:[T:0x00010005] CE - rserverOpen('./all.x64P'), count = 0
@0x005a4f7f:[T:0x00010005] OP - Process_create
Enter(imageName='./all.x64P', attrs=0xbe1ffa40)
Project Name : INCCM and Version : inccm 0.1
@0x005f5364:[T:0x4002] OP - Process_create_d Enter(proc=0x4fb38)
@0x005f54ef:[T:0x4002] OP - Process_create_d Initializing DSP PROC...
@0x005f5a52:[T:0x4002] OP - Process_create_d Attaching to DSP PROC...
@0x005f759c:[T:0x4002] OP - Process_create_d Opening MSGQ pool...
@0x005f7821:[T:0x4002] OP - Process_create_d Loading ./all.x64P
on DSP (2 args)...
RE: Codec engine hangs when during TraceUtil_start function
Sorry if I missed it... what version of Codec Engine are you using? Seems like it's been there forever, but CE_DEBUG was only added in CE 2.x and later. Chris -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com ] On Behalf Of bhushan Sent: Monday, May 04, 2009 11:17 PM To: Balagopalakrishnan, Anand Cc: davinci-linux-open-source@linux.davincidsp.com Subject: Re: Codec engine hangs when during TraceUtil_start function Hello Anand, I set the CE_DEBUG parametr to 2 and 3 value which must basically enable all the traces from teh ARM and DSP side. Still I am unable to see the DSP side traces. Bhushan On Tue, May 5, 2009 at 11:02 AM, Balagopalakrishnan, Anand ana...@ti.com wrote: What are the attributes configured for TraceUtil in the XDC cfg file? By default, the CE traces will be redirected to /tmp/cearmlog.txt. It looks like you have set the environment variables CE_TRACEFILE so it gets redirected to trace/cearmlog.txt. If the directory trace doesn't exist, there would be errors. If you don't *need* TraceUtil specifically - if you just want to observe the DSP side traces for debugging, a better (and easier) option would be to use CE_DEBUG: http://tiexpressdsp.com/index.php?title=CE_DEBUG When using CE_DEBUG, the traces will automatically come to the console. There is no need to change the ARM application code. Best Regards, Anand Balagopalakrishnan Texas Instruments India -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com ] On Behalf Of bhushan Sent: Monday, May 04, 2009 5:07 PM To: davinci-linux-open-source@linux.davincidsp.com Subject: Codec engine hangs when during TraceUtil_start function Hi, I am developing an application based on the codec_engine. For the same I want to see the DSP side traces for the various codecs used. So I have added TraceUtil_start(EngineName) function after Engine_open api. But the application hangs because of TraceUtil_start. Following are the logs: # ./vs_appd -f ../test_vectors/ws_uyvy.yuv # TraceUtil Warning: Failed to open local log file trace/cearmlog.txt, using stdout TraceUtil Warning: Failed to open dsp CE log file trace/cedsp0log.txt, using stdout TraceUtil Warning: Failed to open dsp/bios log file trace/bioslog.dat, disabling log @0x0002c12e:[T:0x4002] OP - daemon thread created. @0x000447be:[T:0x8003] OM - Memory_getPhysicalAddress Enter(virtAddr=0x40556000) @0x000448ee:[T:0x8003] OM - Memory__getPhysicalAddress Enter(virtAddr=0x40556000, size=1) @0x000449e4:[T:0x8003] OM - Memory__getPhysicalAddress returning physAddr=0x0 @0x00044aad:[T:0x8003] OM - Memory_getPhysicalAddress return (0x8280) @0x0004ae67:[T:0x8003] OM - Memory_getPhysicalAddress Enter(virtAddr=0x40655000) @0x0004af56:[T:0x8003] OM - Memory__getPhysicalAddress Enter(virtAddr=0x40655000, size=1) @0x0004b01c:[T:0x8003] OM - Memory__getPhysicalAddress returning physAddr=0x0 @0x0004b0db:[T:0x8003] OM - Memory_getPhysicalAddress return (0x828ff000) @0x000514b1:[T:0x8003] OM - Memory_getPhysicalAddress Enter(virtAddr=0x40754000) @0x0005159c:[T:0x8003] OM - Memory__getPhysicalAddress Enter(virtAddr=0x40754000, size=1) @0x00051662:[T:0x8003] OM - Memory__getPhysicalAddress returning physAddr=0x0 @0x0005173e:[T:0x8003] OM - Memory_getPhysicalAddress return (0x829fe000) 7792:junk2009 NT:No passwd file available, taking factory passwd REQCFG REQCFG 7792:junk2009 NT:No passwd file available, taking factory passwd SETCFG SETCFG Rszcopy Debug: Configuring resizer job to copy image of resolution 320x240 @0x00595d34:[T:0x8003] OM - Memory_getPhysicalAddress Enter(virtAddr=0x408ed000) @0x00595e64:[T:0x8003] OM - Memory__getPhysicalAddress Enter(virtAddr=0x408ed000, size=1) @0x00595f56:[T:0x8003] OM - Memory__getPhysicalAddress returning physAddr=0x0 @0x00596023:[T:0x8003] OM - Memory_getPhysicalAddress return (0x8280) @0x0059c413:[T:0x8003] OM - Memory_getPhysicalAddress Enter(virtAddr=0x409ec000) @0x0059c4fd:[T:0x8003] OM - Memory__getPhysicalAddress Enter(virtAddr=0x409ec000, size=1) @0x0059c5bd:[T:0x8003] OM - Memory__getPhysicalAddress returning physAddr=0x0 @0x0059c677:[T:0x8003] OM - Memory_getPhysicalAddress return (0x828ff000) @0x005a2a2a:[T:0x8003] OM - Memory_getPhysicalAddress Enter(virtAddr=0x40aeb000) @0x005a2b14:[T:0x8003] OM - Memory__getPhysicalAddress Enter(virtAddr=0x40aeb000, size=1) @0x005a2bd7:[T:0x8003] OM - Memory__getPhysicalAddress returning physAddr=0x0 @0x005a2caa:[T:0x8003] OM - Memory_getPhysicalAddress return (0x829fe000)
RE: difficulty in VDEC2 interface in dm6467
Another runtime sanity check - you might use Engine_getNumAlgs()/Engine_getAlgInfo() to enumerate the algorithms in a given Engine, including their name and attributes (e.g. whether they're local or remote, etc). In this case, the lookup is failing on the ARM-side... are you using Engine.createFromServer() to create the Engine in your app's .cfg script? Another common mistake, if the _name_ is a match, is that the _type_ of the codec doesn't match. E.g., if your codec doesn't correctly identify itself as a IVIDDEC2 type (via it's CODEC.xdc file), attempts to VIDDEC2_create() it will fail. Chris From: davinci-linux-open-source-bounces+cring=ti@linux.davincidsp.com [mailto:davinci-linux-open-source-bounces+cring=ti@linux.davincidsp.com] On Behalf Of JayaKumar, PremKumar Sent: Monday, May 04, 2009 11:06 PM To: kirthika varadarajan; Davinci-linux-open-source@linux.davincidsp.com Subject: RE: difficulty in VDEC2 interface in dm6467 Unable to locate alg error might be due to a mismatch between the names defined in multiple places. Check out consistency of the alg names used: 1. Algorithm module name (+package path) matches with the algorithm module path mentioned in useModules( ) in the server's cfg file. 2. Algorithm name defined under the Server.algs in the server's cfg file matches with the name defined in the server creation call in the app's cfg file. Regards, Prem Texas Instruments India From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of kirthika varadarajan Sent: Monday, May 04, 2009 6:39 PM To: Davinci-linux-open-source@linux.davincidsp.com Subject: difficulty in VDEC2 interface in dm6467 I used VDEC2 interface for our own decoder. But somehow i am not able to open the VDEC2 interface But the decode demo that comes along with TI works with VDEC2 interface, here with i am sending the debug message which i get when i use the vdec2 interface. Suggest me what is the problem with VDEC2 interface with our decoder implementation Decode demo started. @0,734,311us: [+4 T:0x40018528] OG - Global_init This program was built with the following packages: @0,734,667us: [+4 T:0x40018528] OG - package gnu.targets.rts470MV (/home/Vina/dvsdk_1_40_00_28/xdc_3_00_06/packages/gnu/targets/rts470MV/) [1,0,0,0,1203621000516] @0,734,823us: [+4 T:0x40018528] OG - package ti.xdais.dmhttp://ti.xdais.dm (/home/Vina/dvsdk_1_40_00_28/xdais_6_10_01/packages/ti/xdais/dm/) [1,0,4,1210262746529] @0,734,902us: [+4 T:0x40018528] OG - package ti.xdais (/home/Vina/dvsdk_1_40_00_28/xdais_6_10_01/packages/ti/xdais/) [1,2,1,1210262742149] @0,734,971us: [+4 T:0x40018528] OG - package ti.sdo.utils.trace (/home/Vina/dvsdk_1_40_00_28/framework_components_2_10_01/packages/ti/sdo/utils/trace/) [1,0,0,1210378728605] @0,735,041us: [+4 T:0x40018528] OG - package ti.sdo.ce.utils.xdm (/home/Vina/dvsdk_1_40_00_28/codec_engine_2_10_01/packages/ti/sdo/ce/utils/xdm/) [1,0,1,1210912978675] @0,735,167us: [+4 T:0x40018528] OG - package ti.sdo.fc.dman3 (/home/Vina/dvsdk_1_40_00_28/framework_components_2_10_01/packages/ti/sdo/fc/dman3/) [1,0,3,1210378548029] @0,735,238us: [+4 T:0x40018528] OG - package ti.sdo.fc.acpy3 (/home/Vina/dvsdk_1_40_00_28/framework_components_2_10_01/packages/ti/sdo/fc/acpy3/) [1,0,2,1210378523580] @0,735,308us: [+4 T:0x40018528] OG - package dsplink.gpp (/home/Vina/dvsdk_1_40_00_28/dsplink-davinci-v1.50-prebuilt/packages/dsplink/gpp/) [3,0,0] @0,735,520us: [+4 T:0x40018528] OG - package ti.sdo.linuxutils.cmem (/home/Vina/dvsdk_1_40_00_28/cmem_2_10/packages/ti/sdo/linuxutils/cmem/) [2,0,1,1204929560755] @0,735,598us: [+4 T:0x40018528] OG - package ti.catalog.c470 (/home/Vina/dvsdk_1_40_00_28/xdc_3_00_06/packages/ti/catalog/c470/) [1,0,1,0,1203561761475] @0,735,670us: [+4 T:0x40018528] OG - package ti.catalog.c6000 (/home/Vina/dvsdk_1_40_00_28/xdc_3_00_06/packages/ti/catalog/c6000/) [1,0,0,0,1203561781695] @0,735,738us: [+4 T:0x40018528] OG - package ti.platforms.evmDM6467 (/home/Vina/dvsdk_1_40_00_28/xdc_3_00_06/packages/ti/platforms/evmDM6467/) [1,0,0,0,1203562062227] @0,735,806us: [+4 T:0x40018528] OG - package ti.sdo.ce.osal (/home/Vina/dvsdk_1_40_00_28/codec_engine_2_10_01/packages/ti/sdo/ce/osal/) [2,0,2,1210912758604] @0,735,874us: [+4 T:0x40018528] OG - package ti.sdo.ce.ipc (/home/Vina/dvsdk_1_40_00_28/codec_engine_2_10_01/packages/ti/sdo/ce/ipc/) [2,0,1,1210912707081] @0,735,940us: [+4 T:0x40018528] OG - package ti.sdo.ce.osal.linux (/home/Vina/dvsdk_1_40_00_28/codec_engine_2_10_01/packages/ti/sdo/ce/osal/linux/) [2,0,1,1210912772730] @0,736,008us: [+4 T:0x40018528] OG - package ti.sdo.ce.ipc.dsplink (/home/Vina/dvsdk_1_40_00_28/codec_engine_2_10_01/packages/ti/sdo/ce/ipc/dsplink/) [2,0,1,1210912721394] @0,736,077us: [+4 T:0x40018528] OG
RE: difficulty in VDEC2 interface in dm6467
Unable to locate alg error might be due to a mismatch between the names defined in multiple places. Check out consistency of the alg names used: 1. Algorithm module name (+package path) matches with the algorithm module path mentioned in useModules( ) in the server's cfg file. 2. Algorithm name defined under the Server.algs in the server's cfg file matches with the name defined in the server creation call in the app's cfg file. Regards, Prem Texas Instruments India From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of kirthika varadarajan Sent: Monday, May 04, 2009 6:39 PM To: Davinci-linux-open-source@linux.davincidsp.com Subject: difficulty in VDEC2 interface in dm6467 I used VDEC2 interface for our own decoder. But somehow i am not able to open the VDEC2 interface But the decode demo that comes along with TI works with VDEC2 interface, here with i am sending the debug message which i get when i use the vdec2 interface. Suggest me what is the problem with VDEC2 interface with our decoder implementation Decode demo started. @0,734,311us: [+4 T:0x40018528] OG - Global_init This program was built with the following packages: @0,734,667us: [+4 T:0x40018528] OG - package gnu.targets.rts470MV (/home/Vina/dvsdk_1_40_00_28/xdc_3_00_06/packages/gnu/targets/rts470MV/) [1,0,0,0,1203621000516] @0,734,823us: [+4 T:0x40018528] OG - package ti.xdais.dmhttp://ti.xdais.dm (/home/Vina/dvsdk_1_40_00_28/xdais_6_10_01/packages/ti/xdais/dm/) [1,0,4,1210262746529] @0,734,902us: [+4 T:0x40018528] OG - package ti.xdais (/home/Vina/dvsdk_1_40_00_28/xdais_6_10_01/packages/ti/xdais/) [1,2,1,1210262742149] @0,734,971us: [+4 T:0x40018528] OG - package ti.sdo.utils.trace (/home/Vina/dvsdk_1_40_00_28/framework_components_2_10_01/packages/ti/sdo/utils/trace/) [1,0,0,1210378728605] @0,735,041us: [+4 T:0x40018528] OG - package ti.sdo.ce.utils.xdm (/home/Vina/dvsdk_1_40_00_28/codec_engine_2_10_01/packages/ti/sdo/ce/utils/xdm/) [1,0,1,1210912978675] @0,735,167us: [+4 T:0x40018528] OG - package ti.sdo.fc.dman3 (/home/Vina/dvsdk_1_40_00_28/framework_components_2_10_01/packages/ti/sdo/fc/dman3/) [1,0,3,1210378548029] @0,735,238us: [+4 T:0x40018528] OG - package ti.sdo.fc.acpy3 (/home/Vina/dvsdk_1_40_00_28/framework_components_2_10_01/packages/ti/sdo/fc/acpy3/) [1,0,2,1210378523580] @0,735,308us: [+4 T:0x40018528] OG - package dsplink.gpp (/home/Vina/dvsdk_1_40_00_28/dsplink-davinci-v1.50-prebuilt/packages/dsplink/gpp/) [3,0,0] @0,735,520us: [+4 T:0x40018528] OG - package ti.sdo.linuxutils.cmem (/home/Vina/dvsdk_1_40_00_28/cmem_2_10/packages/ti/sdo/linuxutils/cmem/) [2,0,1,1204929560755] @0,735,598us: [+4 T:0x40018528] OG - package ti.catalog.c470 (/home/Vina/dvsdk_1_40_00_28/xdc_3_00_06/packages/ti/catalog/c470/) [1,0,1,0,1203561761475] @0,735,670us: [+4 T:0x40018528] OG - package ti.catalog.c6000 (/home/Vina/dvsdk_1_40_00_28/xdc_3_00_06/packages/ti/catalog/c6000/) [1,0,0,0,1203561781695] @0,735,738us: [+4 T:0x40018528] OG - package ti.platforms.evmDM6467 (/home/Vina/dvsdk_1_40_00_28/xdc_3_00_06/packages/ti/platforms/evmDM6467/) [1,0,0,0,1203562062227] @0,735,806us: [+4 T:0x40018528] OG - package ti.sdo.ce.osal (/home/Vina/dvsdk_1_40_00_28/codec_engine_2_10_01/packages/ti/sdo/ce/osal/) [2,0,2,1210912758604] @0,735,874us: [+4 T:0x40018528] OG - package ti.sdo.ce.ipc (/home/Vina/dvsdk_1_40_00_28/codec_engine_2_10_01/packages/ti/sdo/ce/ipc/) [2,0,1,1210912707081] @0,735,940us: [+4 T:0x40018528] OG - package ti.sdo.ce.osal.linux (/home/Vina/dvsdk_1_40_00_28/codec_engine_2_10_01/packages/ti/sdo/ce/osal/linux/) [2,0,1,1210912772730] @0,736,008us: [+4 T:0x40018528] OG - package ti.sdo.ce.ipc.dsplink (/home/Vina/dvsdk_1_40_00_28/codec_engine_2_10_01/packages/ti/sdo/ce/ipc/dsplink/) [2,0,1,1210912721394] @0,736,077us: [+4 T:0x40018528] OG - package ti.sdo.ce.alg (/home/Vina/dvsdk_1_40_00_28/codec_engine_2_10_01/packages/ti/sdo/ce/alg/) [1,0,1,1210912389491] @0,736,146us: [+4 T:0x40018528] OG - package ti.sdo.ce (/home/Vina/dvsdk_1_40_00_28/codec_engine_2_10_01/packages/ti/sdo/ce/) [1,0,6,1210912375058] @0,736,212us: [+4 T:0x40018528] OG - package ti.sdo.ce.speech (/home/Vina/dvsdk_1_40_00_28/codec_engine_2_10_01/packages/ti/sdo/ce/speech/) [1,0,2,1210912797352] @0,736,279us: [+4 T:0x40018528] OG - package ti.sdo.ce.speech1 (/home/Vina/dvsdk_1_40_00_28/codec_engine_2_10_01/packages/ti/sdo/ce/speech1/) [1,0,1,1210912803800] @0,736,345us: [+4 T:0x40018528] OG - package ti.sdo.ce.audio (/home/Vina/dvsdk_1_40_00_28/codec_engine_2_10_01/packages/ti/sdo/ce/audio/) [1,0,2,1210912396869] @0,736,412us: [+4 T:0x40018528] OG - package ti.sdo.ce.video (/home/Vina/dvsdk_1_40_00_28/codec_engine_2_10_01/packages/ti/sdo/ce/video/) [1,0,3,1210912990552] @0,736,477us: [+4 T:0x40018528] OG -
Re: Codec engine hangs when during TraceUtil_start function
Codec_engine_1_10_01 On Tue, May 5, 2009 at 11:58 AM, Ring, Chris cr...@ti.com wrote: Sorry if I missed it... what version of Codec Engine are you using? Seems like it's been there forever, but CE_DEBUG was only added in CE 2.x and later. Chris -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com ] On Behalf Of bhushan Sent: Monday, May 04, 2009 11:17 PM To: Balagopalakrishnan, Anand Cc: davinci-linux-open-source@linux.davincidsp.com Subject: Re: Codec engine hangs when during TraceUtil_start function Hello Anand, I set the CE_DEBUG parametr to 2 and 3 value which must basically enable all the traces from teh ARM and DSP side. Still I am unable to see the DSP side traces. Bhushan On Tue, May 5, 2009 at 11:02 AM, Balagopalakrishnan, Anand ana...@ti.com wrote: What are the attributes configured for TraceUtil in the XDC cfg file? By default, the CE traces will be redirected to /tmp/cearmlog.txt. It looks like you have set the environment variables CE_TRACEFILE so it gets redirected to trace/cearmlog.txt. If the directory trace doesn't exist, there would be errors. If you don't *need* TraceUtil specifically - if you just want to observe the DSP side traces for debugging, a better (and easier) option would be to use CE_DEBUG: http://tiexpressdsp.com/index.php?title=CE_DEBUG When using CE_DEBUG, the traces will automatically come to the console. There is no need to change the ARM application code. Best Regards, Anand Balagopalakrishnan Texas Instruments India -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com ] On Behalf Of bhushan Sent: Monday, May 04, 2009 5:07 PM To: davinci-linux-open-source@linux.davincidsp.com Subject: Codec engine hangs when during TraceUtil_start function Hi, I am developing an application based on the codec_engine. For the same I want to see the DSP side traces for the various codecs used. So I have added TraceUtil_start(EngineName) function after Engine_open api. But the application hangs because of TraceUtil_start. Following are the logs: # ./vs_appd -f ../test_vectors/ws_uyvy.yuv # TraceUtil Warning: Failed to open local log file trace/cearmlog.txt, using stdout TraceUtil Warning: Failed to open dsp CE log file trace/cedsp0log.txt, using stdout TraceUtil Warning: Failed to open dsp/bios log file trace/bioslog.dat, disabling log @0x0002c12e:[T:0x4002] OP - daemon thread created. @0x000447be:[T:0x8003] OM - Memory_getPhysicalAddress Enter(virtAddr=0x40556000) @0x000448ee:[T:0x8003] OM - Memory__getPhysicalAddress Enter(virtAddr=0x40556000, size=1) @0x000449e4:[T:0x8003] OM - Memory__getPhysicalAddress returning physAddr=0x0 @0x00044aad:[T:0x8003] OM - Memory_getPhysicalAddress return (0x8280) @0x0004ae67:[T:0x8003] OM - Memory_getPhysicalAddress Enter(virtAddr=0x40655000) @0x0004af56:[T:0x8003] OM - Memory__getPhysicalAddress Enter(virtAddr=0x40655000, size=1) @0x0004b01c:[T:0x8003] OM - Memory__getPhysicalAddress returning physAddr=0x0 @0x0004b0db:[T:0x8003] OM - Memory_getPhysicalAddress return (0x828ff000) @0x000514b1:[T:0x8003] OM - Memory_getPhysicalAddress Enter(virtAddr=0x40754000) @0x0005159c:[T:0x8003] OM - Memory__getPhysicalAddress Enter(virtAddr=0x40754000, size=1) @0x00051662:[T:0x8003] OM - Memory__getPhysicalAddress returning physAddr=0x0 @0x0005173e:[T:0x8003] OM - Memory_getPhysicalAddress return (0x829fe000) 7792:junk2009 NT:No passwd file available, taking factory passwd REQCFG REQCFG 7792:junk2009 NT:No passwd file available, taking factory passwd SETCFG SETCFG Rszcopy Debug: Configuring resizer job to copy image of resolution 320x240 @0x00595d34:[T:0x8003] OM - Memory_getPhysicalAddress Enter(virtAddr=0x408ed000) @0x00595e64:[T:0x8003] OM - Memory__getPhysicalAddress Enter(virtAddr=0x408ed000, size=1) @0x00595f56:[T:0x8003] OM - Memory__getPhysicalAddress returning physAddr=0x0 @0x00596023:[T:0x8003] OM - Memory_getPhysicalAddress return (0x8280) @0x0059c413:[T:0x8003] OM - Memory_getPhysicalAddress Enter(virtAddr=0x409ec000) @0x0059c4fd:[T:0x8003] OM - Memory__getPhysicalAddress Enter(virtAddr=0x409ec000, size=1) @0x0059c5bd:[T:0x8003] OM - Memory__getPhysicalAddress returning physAddr=0x0 @0x0059c677:[T:0x8003] OM - Memory_getPhysicalAddress return (0x828ff000) @0x005a2a2a:[T:0x8003] OM - Memory_getPhysicalAddress Enter(virtAddr=0x40aeb000) @0x005a2b14:[T:0x8003] OM - Memory__getPhysicalAddress Enter(virtAddr=0x40aeb000, size=1) @0x005a2bd7:[T:0x8003] OM - Memory__getPhysicalAddress returning physAddr=0x0
Re: [patch/rfc davinci-git 2/3] soc-specific SRAM setup
On Friday 01 May 2009, Troy Kisky wrote: Can you try this again?? It doesn't apply for me. Worked for me earlier today ... maybe you weren't using the latest GIT code? I kind of presume that given your patch #3 worked for me post of this afternoon, you got past this. :) - Dave ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
how to use semaphores
Hi I have been studying how to use threads. I have successful made one application, with two threads. I have tied to make something like semaphore. Now I need to make application with 3 or 4 threads 1. will do capture, 2. preview, 3. resize and 4. display. I have no idea how to synchronize this all. I know that it should be something with semaphores. Could some one send me some example created for davinci, or other hints. Thanks Ondrej Pindroch SoftHard Technology ltd. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: how to use semaphores
Hi Ondrej,
Conditional variables are one of the most powerful mechanisms for
synchronization of pthreads.
Below is the code for the usage of condition variables for a typical
Producer-Consumer problem. You may google it for complete understanding.
pthread_cond_t cond_queue_empty, cond_queue_full;
pthread_mutex_t task_queue_cond_lock;
int task_available;
/* other data structures here */
main() {
/* declarations and initializations */
task_available = 0;
pthread_init();
pthread_cond_init(cond_queue_empty, NULL);
pthread_cond_init(cond_queue_full, NULL);
pthread_mutex_init(task_queue_cond_lock, NULL);
/* create and join producer and consumer threads */
}
void *producer(void *producer_thread_data) {
int inserted;
while (!done()) {
create_task();
pthread_mutex_lock(task_queue_cond_lock);
while (task_available == 1)
pthread_cond_wait(cond_queue_empty,
task_queue_cond_lock);
insert_into_queue();
task_available = 1;
pthread_cond_signal(cond_queue_full);
pthread_mutex_unlock(task_queue_cond_lock);
}
}
void *consumer(void *consumer_thread_data) {
while (!done()) {
pthread_mutex_lock(task_queue_cond_lock);
while (task_available == 0)
pthread_cond_wait(cond_queue_full,
task_queue_cond_lock);
my_task = extract_from_queue();
task_available = 0;
pthread_cond_signal(cond_queue_empty);
pthread_mutex_unlock(task_queue_cond_lock);
process_task(my_task);
}
}
By the way, are you using POSIX threads?
~ Gopal Sukumar.
Ondrej Pindroch wrote:
Hi
I have been studying how to use threads. I have successful made one
application, with two threads. I have tied to make something like semaphore.
Now I need to make application with 3 or 4 threads 1. will do capture, 2.
preview, 3. resize and 4. display. I have no idea how to synchronize this all.
I know that it should be something with semaphores. Could some one send me some
example created for davinci, or other hints.
Thanks
Ondrej Pindroch
SoftHard Technology ltd.
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.commailto:Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
http://www.mindtree.com/email/disclaimer.html
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
TI's DaVinci JPEG encoder: where's the JFIF header ?
Hi All, From TI's website (http://focus.ti.com/docs/toolsw/folders/print/tmdjpege.html http://focus.ti.com/docs/toolsw/folders/print/tmdjpege.html ): Features: ... JPEG File Interchange Format (JFIF) header is skipped From JPEG Baseline Profile Encoder on C64x+ User's Guide (http://focus.ti.com/general/docs/lit/getliterature.tsp?literatureNumber =sprueh4fileType=pdf), section 1.3, Supported Services and Features: Includes a standard JPEG header and also supports JFIF style header Now, in the encoded frames I get there's no JFIF header (0xFF 0xE0), nor can I find anywhere in the encoder's API a way to turn this feature on (if it's supported, which is unclear). Anyone has any insight on this ? Thanx, Avishai Hendel Software Engineer MangoDSP Ltd. E-mail: avish...@mangodsp.com mailto:avish...@mangodsp.com Work: +972 2 588 5037 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
status of Video Capture in git kernel?
Can you please tell me the status of video capture for the git kernel? I'd like to used it, but in http://wiki.davincidsp.com/index.php?title=DaVinci_GIT_Linux_Kernel it is said not to be available. Thank you, Ottavio -- Non c'è più forza nella normalità, c'è solo monotonia. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
DM355 boot time
I am trying to reduce boot time on the DM355, with the goal of being able to capture jpeg image 3 sec after power up. I am currently at 7 second from U-boot to userspace. Currently, i achieve a read transfer rate on the NAND of roughly 3 MBytes/s. Do you think it can be improved ? I am using TI UBL from the 1.50 Serial boot utils, and the EMIF setup looks fine. I also modified the nand read_buf method in u-boot, to read 32 bit word from the nand location, because the emif will automatically translate this to byte access. Given the nand transfer rate, transferring data is faster than uncompressing them, so I think I will go with the following arch : uncompressed kernel image + uncompressed initramfs based on a uclibc. What do you think of my boot time target, is it realistic ? ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
about DVB-S on DM355.
All, Does anyone know how to make DVB-S system based on DM355 chip? I need to decode MPEG4-TS/encode MPEG4-TS stream from/to satellite broadcast on DM355. Much help is appreciated. Thanks. BR, Jeff ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
SPI driver about Davinci DM6446
Hello! I am doing a project which involes in the use of Davinci DM6446. I need the SPI device of DM6446 to finish the communication with other devices. But I have poor knowledge about the SPI driver under the DM6446. How can I get any help from the community? Thanks a lot! yours zwj 2009.5.5 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: SPI driver about Davinci DM6446
邹卫军 wrote:
Hello!
I am doing a project which involes in the use of Davinci DM6446. I
need the SPI device of DM6446
to finish the communication with other devices. But I have poor
knowledge about the SPI driver under
the DM6446. How can I get any help from the community?
I haven't tested this on anything later than 2.6.28, and it is missing a
few different read/write widths. Supposedly TI was going to be releasing
a SPI driver for DM6446, DM355 and DM6467 back in March, so I stopped
adding support which I did not require.
/*
* drivers/spi/spi_davinci.c
*
* Copyright (C) Advanced Communication Design
*
* Based on code from spi_bfin5xx.c and atmel_spi.c
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
//#define DEBUG
#include linux/kernel.h
#include linux/init.h
#include linux/clk.h
#include linux/module.h
#include linux/platform_device.h
#include linux/delay.h
#include linux/err.h
#include linux/interrupt.h
#include linux/spi/spi.h
#include linux/sched.h
#include linux/workqueue.h
#include linux/device.h
#include linux/completion.h
#include asm/arch/clock.h
#include asm/arch/gpio.h
#include asm/arch/hardware.h
#include asm/arch/io.h
#include asm/arch/mux.h
#define START_STATE ((void *)0)
#define RUNNING_STATE ((void *)1)
#define DONE_STATE ((void *)2)
#define ERROR_STATE ((void *)-1)
#define QUEUE_RUNNING 0
#define QUEUE_STOPPED 1
struct davinci_spi {
struct platform_device *pdev;
struct spi_master *master;
void __iomem *regs_base;
int irq;
u16 *pin_req;
struct clk *clk;
struct workqueue_struct *workqueue;
struct work_struct pump_messages;
spinlock_t lock;
struct list_head queue;
int busy;
int run;
struct tasklet_struct pump_transfers;
struct completion rx_done;
struct spi_message *cur_msg;
struct spi_transfer *cur_transfer;
size_t len_in_bytes;
size_t len;
void *tx;
void *tx_end;
void *rx;
void *rx_end;
void (*wr) (struct davinci_spi *);
void (*rd) (struct davinci_spi *);
void (*duplex) (struct davinci_spi *);
};
/* SPI Register Addresses */
#define SPIGCR0 (0x00) /** SPI General Control Register 0 */
#define SPIGCR1 (0x04) /** SPI General Control Register 1 */
#define SPIINT (0x08) /** SPI Interrupt Register */
#define SPILVL (0x0c) /** SPI Pin Level Register */
#define SPIFLG (0x10) /** SPI Flag Status Register */
#define SPIPC0 (0x14) /** SPI Pin Control Register 0 */
#define SPIPC2 (0x1c) /** SPI Pin Control Register 2 */
#define SPIDAT1 (0x3c) /** SPI Shift Register 1 */
#define SPIBUF (0x40) /** SPI Buffer Register */
#define SPIEMU (0x44) /** SPI Emulation Register */
#define SPIDELAY(0x48) /** SPI Delay Register */
#define SPIDEF (0x4c) /** SPI Default Chip Select Register */
#define SPIFMT0 (0x50) /** SPI Data Format Register 0 */
#define SPIFMT1 (0x54) /** SPI Data Format Register 1 */
#define SPIFMT2 (0x58) /** SPI Data Format Register 2 */
#define SPIFMT3 (0x5c) /** SPI Data Format Register 3 */
#define INTVEC0 (0x60) /** SPI Interrupt Vector Register 0 */
#define INTVEC1 (0x64) /** SPI Interrupt Vector Register 1 */
/* SPI Register bit definitions */
#define SPIGCR0_RESET (1 0)
#define SPIGCR1_SPIEN (1 24)
#define SPIGCR1_CLKMOD (1 1)
#define SPIGCR1_MASTER (1 0)
#define SPIINT_DMAREQEN (1 16)
#define SPIINT_RXINTEN (1 8)
#define SPIINT_OVRNINTEN(1 6)
#define SPIINT_BITERRENA(1 4)
#define SPIFMTX_POLARITY(1 17)
#define SPIFMTX_PHASE (1 16)
#define SPIFMTX_PRESCALE_VAL(7 8)
#define SPIFLG_RXINTFLG (1 8)
#define SPIFLG_OVRNINTFLG (1 6)
#define SPIFLG_BITERRFLG(1 4)
#define SPIPC0_DIFUN(1 11)
#define SPIPC0_DOFUN(1 10)
#define SPIPC0_CLKFUN (1 9)
#define SPIPC0_EN1FUN (1 1)
#define SPIPC0_EN0FUN (1 0)
#define SPIDAT1_CSHOLD (1 28)
#define SPIDAT1_CSNR1 (1 16)
#define SPIDAT1_CSNR0 (2 16)
#define SPIDELAY_C2TDELAY_VAL (6 24)
#define SPIDELAY_T2CDELAY_VAL (3 16)
#define SPIDEF_EN1DEF (1 1)
#define SPIDEF_EN0DEF (1 0)
#define MODEBITS (SPI_CPOL | SPI_CPHA)
static void u16_duplex(struct davinci_spi *dvspi)
{
while (dvspi-tx dvspi-tx_end) {
iowrite32(SPIDAT1_CSHOLD | SPIDAT1_CSNR0 |
(*(u16 *)
Re: SPI driver about Davinci DM6446
On Tue, 2009-05-05 at 09:13 -0500, Brian Rhodes wrote: 邹卫军 wrote: Hello! I am doing a project which involes in the use of Davinci DM6446. I need the SPI device of DM6446 to finish the communication with other devices. But I have poor knowledge about the SPI driver under the DM6446. How can I get any help from the community? I haven't tested this on anything later than 2.6.28, and it is missing a few different read/write widths. Supposedly TI was going to be releasing a SPI driver for DM6446, DM355 and DM6467 back in March, so I stopped adding support which I did not require. As far as I know, TI does not officially support SPI for dm6446. SPI is officially supported for dm355 and dm6467. Regards, Steve ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: SPI driver about Davinci DM6446
Steve Chen wrote: As far as I know, TI does not officially support SPI for dm6446. SPI is officially supported for dm355 and dm6467. Certainly might be the case since there are no SPI devices on the 6446 EVM, however I was referring to... Brian, The intent is to get the SPI driver for DM6446, DM6467 and DM355 into the git by mid march. On the Dm355 and DM6467 EVM an instance of SPI is connected to EEPROM. This makes it possible to test the SPI driver. On the DM6446 EVM SPI is not exposed. in other words it is not connected to anything. We will test it on the DM355 and DM6467. Since the IP is similar it should work on the DM6446 as well Thanks, Sandeep I'm not nagging TI at all. Just was mentioning it. ;) ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 1/7] VPFE capture driver for DM355 and DM6446
Hi, On Saturday 02 May 2009 00:18:46 Karicheri, Muralidharan wrote: Laurent, Thanks once again for your support. Please see below my response with [MK] prefix. If some more outstanding issues are to be discussed, will it be possible to talk to you over phone? Sure. Contact me by private e-mail if you want to arrange a phone meeting. [snip] The driver uses ccdc_hw_device interface to configure CCDC based on the interface requirement of the slave decoder device. If I'm not mistaken, the vpfe_capture.ko module depends on either ccdc_dm355.ko or ccdc_davinci.ko (which should really be named ccdc_dm6446.ko, but you've already been told about that) but not both, as those modules conflict. Is there a reason not to combine both the vpfe and the ccdc drivers into a single module ? [MK] The reason they are developed as independent module is to help in re-use it across other OS if needed. I am not sure why you want to combine them. Could you elaborate? See below. You should also probably call ccdc functions directly instead of going through the ccdc_hw_dev structure, and pass them a pointer to a ccdc data structure instead of storing everything as global variables in theccdc_dm355.c and ccdc_davinci.c source files. [MK] As I see it, vpfe_capture bridge driver needs to use different CCDC modules on each of the different SoCs that we support. Using function ptrs help us to assign NULL to function ptrs on some SoCs where the specific function is not required to be implemented. But we could consider functions that are called from interrupt context available as global inline function to make it more efficient. Alternately using the functions as global, how do I call a function from bridge driver if that is applicable only to one SoC and not applicable for others? I thought following is not acceptable #ifdef CONFIG_ARCH_DAVINCI_DM644x (config variable for DM6446 SoC) call specific function #endif You're right. I overlooked the fact that some functions were not mandatory. A simple solution, that would allow the VPFE code not to test for NULL function pointers, would be to implement dummy functions (basically just returning a fixed value) for operations not supported by a given CCDC module. I'll let you decide if this is acceptable and desirable. [MK]. I am more inclined to check for null in the code rather than implementing dummy functions. I like how similar thing is done in videobuf-core.c where the code checks for mandatory functions by calling BUG_ON(!q-ops-buf_queue) Do you think this is a good choice? Given that function pointers can not change after initialization, checking them in the registration function is enough. BUG_ON() will ensure the developer notices potential issues, I think that's a good solution. I can think of two ways to support different CCDC modules in the VPFE driver. The first one is what you've implemented so far. Only a single CCDC module can be loaded as they all export identically named symbols. This make it impossible to build VPFE support directly in a kernel (as opposed to dynamically loaded modules) that needs to run on both a DM355 and a DM6446. The second way is to have the CCDC modules register their ccdc_hw_device (btw, the function pointers might be split into a second structure called ccdc_hw_ops to be consistent with names in the rest of the kernel) with the [MK] Ok. VPFE driver. This would allow different CCDC modules to be compiled in the same kernel. Platform device data passed by board-specific code would be used to select the right CCDC module at runtime. [MK] If I understand correctly, what you are suggesting is to have the ccdc module register with vpfe driver. So vpfe driver implements a register function which all available ccdc modules call to register with the vpfe. vpfe driver platform data indicate the board type. Based on that vpfe_drivers select the correct ccdc and rejects the rest. Is it what you mean here ? Yes that's right. Association between the VPFE and CCDC drivers will be dynamically handled at runtime. I think the direction currently followed by most architectures is to enable building of kernels supporting different boards/devices. This would make the second solution preferable. I have no strong opinion on this though. [MK] I feel the same way. +static int debug; +static char *ch0_decoder = TVP514X; +static u32 ch0_numbuffers = 3; +static u32 ch0_bufsize = (720 * 576 * 2); The buffer size and the number of buffers should be controlled by the userspace application. You can restrict the value to a driver-specific range, but don't use module parameters to select them. I think this is used across all our drivers (including the dm6467 driver that is being reviewed in the list now) The reason for these
RE: SPI driver about Davinci DM6446
-Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Brian Rhodes Sent: Tuesday, May 05, 2009 10:13 AM To: 邹卫军 Cc: davinci-linux-open-source Subject: Re: SPI driver about Davinci DM6446 邹卫军 wrote: Hello! I am doing a project which involes in the use of Davinci DM6446. I need the SPI device of DM6446 to finish the communication with other devices. But I have poor knowledge about the SPI driver under the DM6446. How can I get any help from the community? I haven't tested this on anything later than 2.6.28, and it is missing a few different read/write widths. Supposedly TI was going to be releasing a SPI driver for DM6446, DM355 and DM6467 back in March, so I stopped adding support which I did not require. Initial patch set was sent back in March - http://linux.omap.com/pipermail/davinci-linux-open-source/2009-March/012210.html This was tested on DM355, but the same driver should work on DM6446, but requires some device to be connected to SPI. There were some review comments to be addressed on this patch set, but the main discussion was about the EEPROM driver - should we have a MTD based EEPROM driver or just the raw EEPROM driver (already part of misc drivers) was enough to test SPI. Thanks Sneha ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 1/7] VPFE capture driver for DM355 and DM6446
Laurent,
See my response below. I think we are closing in on most of the comments.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
Phone : 301-515-3736
email: m-kariche...@ti.com
+static int debug;
+static char *ch0_decoder = TVP514X;
+static u32 ch0_numbuffers = 3;
+static u32 ch0_bufsize = (720 * 576 * 2);
The buffer size and the number of buffers should be controlled by
the
userspace application. You can restrict the value to a driver-
specific
range, but don't use module parameters to select them.
I think this is used across all our drivers (including the dm6467
driver that is being reviewed in the list now)
The reason for these variables as module parameter is as follows:-
Our drivers supports capture resolutions that varies from D1 to
HD (1920x1080). On image sensor capture, we may support capture of
even higher resolution. We support both MMAP and PTR based IO.
If MMAP is used, we would like to pre-allocate buffers for
application
since allocating it on the fly result in fragmentation. So setting
number of buffers as a module parameters make sense. Also if a
particular implementation doesn't want to use these pre-allocated
buffers (use ptr IO instead), the parameter can be set to zero to
force the driver not allocate any buffers and thereby reduce system
memory usage. I have currently removed PTR based IO in this patch
since our implementation was a hack based on an older version of the
kernel. If more buffers than pre-allocated are requested, then
driver tries to allocate more and free it when device
is closed (This is how we do it in our internal driver which will
get ported to open source later. Proriority now is to get the driver
in the open source with minimum set of features and add more features
later). Similar reasoning applies to buffer size. If user application
is using max D1 resolution capture, there is no need to pre-allocate
big size buffers and can be controlled at boot/insmode time.
So the buffer count and size parameters are only used to preallocate
the
buffers ? In that case maybe you could use a single parameter to set
the
preallocated memory size.
[MK] Are you saying allocate a single big buffer? How do we then handle
individual buffers as required by v4l2 driver?. Also there is more chance
to fail the allocation if we are requesting a single large buffer. In our
implementation, we allocate 3 or more separate buffers. I don't quite get
what you are saying here.
The single buffer could be split into smaller buffers when needed. You're
right, this will put more pressure on the memory subsystem. On the other
hand,
allocating 'numbuffers' buffers of 'bufsize' bytes will make it impossible
to
use the preallocated memory if the user requests 'numbuffers / 2' buffers
of
'bufsize * 2' bytes. There's a trade-off here, I don't have a strong
opinion
on this, feel free to use your favorite solution.
[MK]. Anyway I don't have pre-allocation in the driver as of now. So this will
be re-visited later when pre-allocation is done. Right now, I will not change
it. May be I will add a comment in the code to indicate so.
[snip]
+static void vpfe_videobuf_release(struct videobuf_queue *vq,
+struct videobuf_buffer *vb)
+{
+v4l2_dbg(1, debug, vpfe_dev-driver,
vpfe_videobuf_release\n); +videobuf_dma_contig_free(vq,
vb);
+vb-state = VIDEOBUF_NEEDS_INIT;
I'm not sure about this, but aren't you supposed to remove the
buffer
from the dma_queue here ?
[MK] I believe when REQUEST_BUF is called the second time,
INIT_LIST_HEAD will re-initialize the queue.
The buf_release callback is not necessarily followed by a
VIDIOC_REQBUFS.
For instance, if the user calls VIDIOC_STREAMOFF, vpfe_videobuf_release
will be called. It would be perfectly valid to call VIDIOC_STREAMON
after
that with any VIDIOC_REQBUFS in between.
[MK]. What you are saying is the following scenario will create problem
since I don't remove the buffer from the dma queue resulting in driver
using an invalid buffer (already released by videobuf_dma_contig_free) if
STREAMON is called again
VIDIOC_STREAMON
VIDIOC_STREAMOFF
VIDIOC_STREAMON.
Yes that's right.
So I guess I can call INIT_LIST_HEAD() to remove the buffer so that
STREAMON will fail gracefully if application calls STREAMON immediately
after that, it will fail.
You should instead remove the buffer from the DMA queue when the
buf_release
callback is invoked. In addition to releasing the buffer itself,
buf_release()
must release all resources associated with the buffer. This means it must
remove the buffer from any list it sits on (using appropriate locking of
course).
[MK] Ok.
Can I assume, after STREAMOFF, to successfully start streaming again,
application needs to call a)
REQBUF -(optional QUERYBUF -
Re: SPI driver about Davinci DM6446
On Tuesday 05 May 2009, Narnakaje, Snehaprabha wrote: Initial patch set was sent back in March - http://linux.omap.com/pipermail/davinci-linux-open-source/2009-March/012210.html This was tested on DM355, but the same driver should work on DM6446, but requires some device to be connected to SPI. Which can be done through one of the expansion connectors. I think I saw some protyping boards available, which make it easier to access those signals. There were some review comments to be addressed on this patch set, Still not addressed ... though that wiki status page says target end-of-week 5/1. I hope it didn't slip too far. ;) but the main discussion was about the EEPROM driver - should we have a MTD based EEPROM driver or just the raw EEPROM driver (already part of misc drivers) was enough to test SPI. And I think the conclusion was to use the standard EEPROM driver, like everyone else is doing. (For a part with only a couple pages of memory, MTD wouldn't be very usable anyway.) Another aspect of this is that writing a new driver that's only ever tested with a DaVinci SPI driver, and preventing use of the standard and well tested EEPROM driver, gives no assurance that the spi_master interface has been properly implemented. Bugs in one could easily cover up bugs in the other. Having it work with the standard EEPROM driver is a weak sort of conformance test, but it's better than nothing. - Dave ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [patch/rfc davinci-git 2/3] soc-specific SRAM setup
David Brownell wrote: On Friday 01 May 2009, Troy Kisky wrote: Can you try this again?? It doesn't apply for me. Worked for me earlier today ... maybe you weren't using the latest GIT code? I kind of presume that given your patch #3 worked for me post of this afternoon, you got past this. :) - Dave Yeah, sorry for the noise. I thought I was on the latest, but I wasn't. Troy ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: SPI driver about Davinci DM6446
David Brownell wrote: On Tuesday 05 May 2009, Narnakaje, Snehaprabha wrote: Initial patch set was sent back in March - http://linux.omap.com/pipermail/davinci-linux-open-source/2009-March/012210.html This was tested on DM355, but the same driver should work on DM6446, but requires some device to be connected to SPI. I must have missed this patch. Sorry for the confusion. I'll test it on my dm6446 board later this week. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
about dm355 decoding limitation.
All, I want to make a tool to get arount the DM355 decoding limitation working on PC using FFMPEG( or other open source free tool, not Arcsoft tool), could anyone tell me how to do it? Thanks. BR, Jeff ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: about dm355 decoding limitation.
Jeff, If you want to decode mpeg4 content generated by DM355. Change the file extension to m4v instead of mpeg4 and you will be able to play it with VLC (ffmpeg). Yair -- Yair Hougui yair_hou...@ti.commailto:yair_hou...@ti.com P Please consider the environment before printing this e-mail From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Jeff Sent: Wednesday, May 06, 2009 5:36 AM To: Davinci-Linux-Source Subject: about dm355 decoding limitation. All, I want to make a tool to get arount the DM355 decoding limitation working on PC using FFMPEG( or other open source free tool, not Arcsoft tool), could anyone tell me how to do it? Thanks. BR, Jeff ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Some questions about MontaVista Linux
Hi, Daniel, I am facing some probelms when I use the MontaVista Linux on my DM6446 EVM. 1. I am use the LargePage Nand Flash (ST's NAND01GR3B2B NAND Flash ) on my DM6446 EVM, When I use the MVL4.0 kernel on my board, I found that the kernel would scan all the blocks of the whole nand flash as bad blocks. However, When I use the MVL 5.0 Kernel on my board, the kernel would find no bad blocks of the whole nand flash. So I want to know how to update the MTD drivers for the nand flash from MVL 4.0 to MVL 5.0? could you give me some advies about that situation? 2. If the above problem would not be sovled correctly, I have to change my kernel from MVL 4.0 to MVL 5.0. While I found that the MVL 5.0 kernel could not mount the NFS correctly, the kernel would halt mounting the NFS for ever, the following is the messages: *===* *IP-Config: Complete: device=eth0, addr=192.168.0.125, mask=255.255.255.0, gw=192.168.0.1, host=XJTUIPCEVM, domain=, nis-domain=(none), bootserver=192.168.0.238, rootserver=192.168.0.238, rootpath= Looking up port of RPC 13/2 on 192.168.0.238 portmap: server 192.168.0.238 not responding, timed out Root-NFS: Unable to get nfsd port number from server, using default Looking up port of RPC 15/1 on 192.168.0.238* ** But When I use the MVL 4.0 kernel, I found that the kernel woud correctly mount the NFS with no errors. Between the two situations my u-boot ENV is the same configurations: *bootargs=mem=120M console=ttyS0,115200n8 root=/dev/nfs noinitrd rw ip=192.168.0.125:192.168.0.238:192.168.0.1:255.255.255.0:XJTUIPCEVM nfsroot=192.168.0.238:/home/workdir/rootfs,nolock video=dm64xxfb:output=pal* So I want to know whether there are some necessary differences about the kernel configurations between the MVL 4.0 and MVL 5.0 or not. Such as make menuconfig, u-boot env setting (bootargs, etc.) Thand you, Hope for your reply. Zhang * *** ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Some questions about MontaVista Linux
Hi, Can you try with the following environment, setenv bootargs console=ttyS0,115200n8 root=nfs rw mem=120M ip=192.168.0.125 nfsroot=192.168.0.238:/home/workdir/rootfs Regards, Madhu. On Wed, 2009-05-06 at 10:58 +0800, shaofeng zhang wrote: Hi, Daniel, I am facing some probelms when I use the MontaVista Linux on my DM6446 EVM. 1. I am use the LargePage Nand Flash (ST's NAND01GR3B2B NAND Flash ) on my DM6446 EVM, When I use the MVL4.0 kernel on my board, I found that the kernel would scan all the blocks of the whole nand flash as bad blocks. However, When I use the MVL 5.0 Kernel on my board, the kernel would find no bad blocks of the whole nand flash. So I want to know how to update the MTD drivers for the nand flash from MVL 4.0 to MVL 5.0? could you give me some advies about that situation? 2. If the above problem would not be sovled correctly, I have to change my kernel from MVL 4.0 to MVL 5.0. While I found that the MVL 5.0 kernel could not mount the NFS correctly, the kernel would halt mounting the NFS for ever, the following is the messages: === IP-Config: Complete: device=eth0, addr=192.168.0.125, mask=255.255.255.0, gw=192.168.0.1, host=XJTUIPCEVM, domain=, nis-domain=(none), bootserver=192.168.0.238, rootserver=192.168.0.238, rootpath= Looking up port of RPC 13/2 on 192.168.0.238 portmap: server 192.168.0.238 not responding, timed out Root-NFS: Unable to get nfsd port number from server, using default Looking up port of RPC 15/1 on 192.168.0.238 But When I use the MVL 4.0 kernel, I found that the kernel woud correctly mount the NFS with no errors. Between the two situations my u-boot ENV is the same configurations: bootargs=mem=120M console=ttyS0,115200n8 root=/dev/nfs noinitrd rw ip=192.168.0.125:192.168.0.238:192.168.0.1:255.255.255.0:XJTUIPCEVM nfsroot=192.168.0.238:/home/workdir/rootfs,nolock video=dm64xxfb:output=pal So I want to know whether there are some necessary differences about the kernel configurations between the MVL 4.0 and MVL 5.0 or not. Such as make menuconfig, u-boot env setting (bootargs, etc.) Thand you, Hope for your reply. Zhang ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
