* DSP Bridge video decode of above VGA videos
@ 2010-11-22 13:14 James Adams
2010-11-22 13:23 ` Kanigeri, Hari
0 siblings, 1 reply; 13+ messages in thread
From: James Adams @ 2010-11-22 13:14 UTC (permalink / raw)
To: linux-omap
Hi All,
We are running Android on a custom Gumstix Overo Water platform. We
have ported the 25.12 Zoom2 release to do this.
It is almost working except that when trying to decode H264 videos
with resolution above 640x480 (either horizontally or vertically, e.g.
640*544) the DSP module appears to crash. Decoding anything at VGA or
below is working fine.
DSP bridge is configured with 0x600000 memory (but larger doesn't seem
to help). Is anyone aware of other configuration options that we
should be checking (e.g. in DSP bridge, OMAP video drivers, or
android?) that might cause large video decodes to fail?
Thanks in advance,
James
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: DSP Bridge video decode of above VGA videos
2010-11-22 13:14 DSP Bridge video decode of above VGA videos James Adams
@ 2010-11-22 13:23 ` Kanigeri, Hari
2010-11-22 15:26 ` James Adams
0 siblings, 1 reply; 13+ messages in thread
From: Kanigeri, Hari @ 2010-11-22 13:23 UTC (permalink / raw)
To: James Adams; +Cc: linux-omap
James,
On Mon, Nov 22, 2010 at 7:14 AM, James Adams <james.r.adams@gmail.com> wrote:
> Hi All,
>
> We are running Android on a custom Gumstix Overo Water platform. We
> have ported the 25.12 Zoom2 release to do this.
>
> It is almost working except that when trying to decode H264 videos
> with resolution above 640x480 (either horizontally or vertically, e.g.
> 640*544) the DSP module appears to crash. Decoding anything at VGA or
> below is working fine.
>
> DSP bridge is configured with 0x600000 memory (but larger doesn't seem
> to help). Is anyone aware of other configuration options that we
> should be checking (e.g. in DSP bridge, OMAP video drivers, or
> android?) that might cause large video decodes to fail?
Can you please post any error/failure logs ?
Thank you,
Best regards,
Hari Kanigeri
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: DSP Bridge video decode of above VGA videos
2010-11-22 13:23 ` Kanigeri, Hari
@ 2010-11-22 15:26 ` James Adams
2010-11-22 16:56 ` Sapiens, Rene
0 siblings, 1 reply; 13+ messages in thread
From: James Adams @ 2010-11-22 15:26 UTC (permalink / raw)
To: Kanigeri, Hari; +Cc: linux-omap
Hi Hari,
Please see output below - hopefully there are some clues in there? many thanks,
James
I/ActivityManager( 966): Starting activity: Intent {
act=android.intent.action.
MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000
cmp=com.android.devel
opment/.Development }
I/ActivityManager( 966): Start proc com.android.development for
activity com.an
droid.development/.Development: pid=1249 uid=10016 gids={3003}
binder_open: 1249:1249
binder_mmap: 1249 44682000-44780000 (1016 K) vma 200075 pagep 30f
D/dalvikvm( 933): GC freed 281 objects / 10696 bytes in 225ms
D/dalvikvm( 933): GC freed 50 objects / 2232 bytes in 64ms
D/dalvikvm( 933): GC freed 2 objects / 48 bytes in 57ms
I/ActivityManager( 966): Displayed activity
com.android.development/.Developmen
t: 898 ms (total 898 ms)
I/ActivityManager( 966): Starting activity: Intent {
act=android.intent.action.
MAIN cat=[android.intent.category.TEST] flg=0x10000000
cmp=com.android.developme
nt/.MediaScannerActivity }
D/MediaScannerService( 1073): start scanning volume external
I/ActivityManager( 966): Displayed activity
com.android.development/.MediaScann
erActivity: 294 ms (total 294 ms)
D/dalvikvm( 1073): GC freed 6291 objects / 312432 bytes in 66ms
V/MediaProvider( 1073): we got work to do for checkThumbnail:
/sdcard/videos/wal
l_e_720p.m4v, there are still 0 tasks left in queue
D/omx_interface( 934): TIOMXInterface: creating interface
D/omx_interface( 934): Calling DLOPEN on OMX_CORE_LIBRARY
(libOMX_Core.so)
D/omx_interface( 934): DLOPEN SUCCEEDED (libOMX_Core.so)
D/omx_interface( 934): TIOMXInterface: library lookup success
D/TIOMX_CORE( 934): init count = 1
D/MediaScanner( 1073): prescan time: 189ms
D/MediaScanner( 1073): scan time: 1019ms
D/MediaScanner( 1073): postscan time: 2ms
D/MediaScanner( 1073): total time: 1210ms
D/MediaScannerService( 1073): done scanning volume external
E/MetadataDriver( 934): handleQueryTrackSelectionHelper()
I/TI_Parser_Utils( 934): iGetAVCConfigInfo:: 909:
entropy_coding_mode_flag = 0
I/TI_Parser_Utils( 934): iGetAVCConfigInfo:: 909:
entropy_coding_mode_flag = 0
I/TI_Parser_Utils( 934): iGetAVCConfigInfo:: 909:
entropy_coding_mode_flag = 0
D/TIOMX_CORE( 934): Found component OMX.TI.Video.Decoder with refCount
0
D/TI_Video_Decoder( 934): OMX_ComponentInit():296 TI Video Decoder
D/TI_Video_Decoder( 934): VIDDEC_InitDSP_H264Dec():6570 Before
Rounding: nFrame
Width = 1280, nFrameHeight = 544
D/TI_Video_Decoder( 934): VIDDEC_InitDSP_H264Dec():6573 After Rounding:
nFrameW
idth = 1280, nFrameHeight = 544
drivers/dsp/bridge/services/sync.c, line 357: Assertion (0) failed.
drivers/dsp/bridge/services/sync.c, line 357: Assertion (0) failed.
D/TI_Video_Decoder( 934): VIDDEC_InitDSP_H264Dec():6619
LCML_InitMMCodec Failed
!...80001009
D/TI_Video_Decoder( 934): VIDDEC_HandleCommand():1950 LCML Error 1
D/TI_Video_Decoder( 934): OMX_VidDec_Thread():165 Error in Select
I/DEBUG ( 930): *** *** *** *** *** *** *** *** *** *** *** *** ***
*** *** *
**
I/DEBUG ( 930): Build fingerprint:
'generic/zoom2/zoom2/zoom2:2.1/ERD79/eng.a
.20101027.181041:eng/test-keys'
I/DEBUG ( 930): pid: 934, tid: 1258 >>> /system/bin/mediaserver <<<
I/DEBUG ( 930): signal 11 (SIGSEGV), fault addr deadbaad
I/DEBUG ( 930): r0 00000000 r1 afe13329 r2 00000027 r3 00000054
I/DEBUG ( 930): r4 afe3ae08 r5 00000000 r6 00000000 r7 0000a000
I/DEBUG ( 930): r8 00100000 r9 a9d1c1d5 10 40c08000 fp 0000c8a0
I/DEBUG ( 930): ip 00002ed8 sp 40d07b28 lr deadbaad pc afe109e0
cpsr 600
00030
I/DEBUG ( 930): #00 pc 000109e0 /system/lib/libc.so
I/DEBUG ( 930): #01 pc 0000b332 /system/lib/libc.so
I/DEBUG ( 930): #02 pc 00032936
/system/lib/libOMX.TI.Video.Decode
r.so
I/DEBUG ( 930): #03 pc 0000111e /system/lib/libOMX_Core.so
I/DEBUG ( 930): #04 pc 00039f90
/system/lib/libopencore_common.so
I/DEBUG ( 930): #05 pc 000aad68
/system/lib/libopencore_common.so
I/DEBUG ( 930): #06 pc 000ad364
/system/lib/libopencore_common.so
I/DEBUG ( 930): #07 pc 000a0144
/system/lib/libopencore_common.so
I/DEBUG ( 930): #08 pc 0009e348
/system/lib/libopencore_common.so
I/DEBUG ( 930): #09 pc 0009f5ea
/system/lib/libopencore_player.so
I/DEBUG ( 930): #10 pc 000939fa
/system/lib/libopencore_player.so
I/DEBUG ( 930): #11 pc 00093a2a
/system/lib/libopencore_player.so
I/DEBUG ( 930): #12 pc 00096c42
/system/lib/libopencore_player.so
I/DEBUG ( 930): #13 pc 00089446
/system/lib/libopencore_player.so
I/DEBUG ( 930): #14 pc 0002b0cc
/system/lib/libopencore_common.so
I/DEBUG ( 930): #15 pc 0002b334
/system/lib/libopencore_common.so
I/DEBUG ( 930): #16 pc 0002b6ec
/system/lib/libopencore_common.so
I/DEBUG ( 930): #17 pc 000a3118
/system/lib/libopencore_player.so
I/DEBUG ( 930): #18 pc 000a313a
/system/lib/libopencore_player.so
I/DEBUG ( 930): #19 pc 0001c23c /system/lib/libutils.so
I/DEBUG ( 930): #20 pc 0000fd74 /system/lib/libc.so
I/DEBUG ( 930): #21 pc 0000f840 /system/lib/libc.so
I/DEBUG ( 930):
I/DEBUG ( 930): code around pc:
I/DEBUG ( 930): afe109d0 f8442001 4798000c e054f8df 26002227
I/DEBUG ( 930): afe109e0 2000f88e ef4cf7fb f7fd2106 f04fe822
I/DEBUG ( 930): afe109f0 91035180 460aa901 96012006 f7fc9602
I/DEBUG ( 930):
I/DEBUG ( 930): code around lr:
I/DEBUG ( 930): deadba9c ffffffff ffffffff ffffffff ffffffff
I/DEBUG ( 930): deadbaac ffffffff ffffffff ffffffff ffffffff
I/DEBUG ( 930): deadbabc ffffffff ffffffff ffffffff ffffffff
I/DEBUG ( 930):
I/DEBUG ( 930): stack:
I/DEBUG ( 930): 40d07ae8 000000a1
I/DEBUG ( 930): 40d07aec afe13359 /system/lib/libc.so
I/DEBUG ( 930): 40d07af0 afe3b02c /system/lib/libc.so
I/DEBUG ( 930): 40d07af4 afe3afd8 /system/lib/libc.so
I/DEBUG ( 930): 40d07af8 00000000
I/DEBUG ( 930): 40d07afc afe14373 /system/lib/libc.so
I/DEBUG ( 930): 40d07b00 afe13329 /system/lib/libc.so
I/DEBUG ( 930): 40d07b04 afe13329 /system/lib/libc.so
I/DEBUG ( 930): 40d07b08 00000054
I/DEBUG ( 930): 40d07b0c afe3ae08 /system/lib/libc.so
I/DEBUG ( 930): 40d07b10 00000000
I/DEBUG ( 930): 40d07b14 40d07b3c
I/DEBUG ( 930): 40d07b18 0000a000 [heap]
I/DEBUG ( 930): 40d07b1c afe135cb /system/lib/libc.so
I/DEBUG ( 930): 40d07b20 df002777
I/DEBUG ( 930): 40d07b24 e3a070ad
I/DEBUG ( 930): #00 40d07b28 afe3db74
I/DEBUG ( 930): 40d07b2c afe0f110 /system/lib/libc.so
I/DEBUG ( 930): 40d07b30 afe3ae08 /system/lib/libc.so
I/DEBUG ( 930): 40d07b34 00030770 [heap]
I/DEBUG ( 930): 40d07b38 4138d180
I/DEBUG ( 930): 40d07b3c fffffbdf
I/DEBUG ( 930): 40d07b40 afe3ae08 /system/lib/libc.so
I/DEBUG ( 930): 40d07b44 afe3d9bc
I/DEBUG ( 930): 40d07b48 4138d180
I/DEBUG ( 930): 40d07b4c afe0b337 /system/lib/libc.so
I/DEBUG ( 930): #01 40d07b50 00100000
I/DEBUG ( 930): 40d07b54 0006d5e0 [heap]
I/DEBUG ( 930): 40d07b58 00002bb4
I/DEBUG ( 930): 40d07b5c 00000000
I/DEBUG ( 930): 40d07b60 00000000
I/DEBUG ( 930): 40d07b64 80c3d0f8
/system/lib/libOMX.TI.Video.Decoder.s
o
I/DEBUG ( 930): 40d07b68 00030770 [heap]
I/DEBUG ( 930): 40d07b6c 0000c8a0 [heap]
I/DEBUG ( 930): 40d07b70 40d07bf4
I/DEBUG ( 930): 40d07b74 80c32939
/system/lib/libOMX.TI.Video.Decoder.s
On Mon, Nov 22, 2010 at 1:23 PM, Kanigeri, Hari <h-kanigeri2@ti.com> wrote:
> James,
>
> On Mon, Nov 22, 2010 at 7:14 AM, James Adams <james.r.adams@gmail.com> wrote:
>> Hi All,
>>
>> We are running Android on a custom Gumstix Overo Water platform. We
>> have ported the 25.12 Zoom2 release to do this.
>>
>> It is almost working except that when trying to decode H264 videos
>> with resolution above 640x480 (either horizontally or vertically, e.g.
>> 640*544) the DSP module appears to crash. Decoding anything at VGA or
>> below is working fine.
>>
>> DSP bridge is configured with 0x600000 memory (but larger doesn't seem
>> to help). Is anyone aware of other configuration options that we
>> should be checking (e.g. in DSP bridge, OMAP video drivers, or
>> android?) that might cause large video decodes to fail?
>
> Can you please post any error/failure logs ?
>
>
> Thank you,
> Best regards,
> Hari Kanigeri
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: DSP Bridge video decode of above VGA videos
2010-11-22 15:26 ` James Adams
@ 2010-11-22 16:56 ` Sapiens, Rene
2010-11-22 17:12 ` James Adams
0 siblings, 1 reply; 13+ messages in thread
From: Sapiens, Rene @ 2010-11-22 16:56 UTC (permalink / raw)
To: James Adams; +Cc: Kanigeri, Hari, linux-omap
Hi James,
On Mon, Nov 22, 2010 at 9:26 AM, James Adams <james.r.adams@gmail.com> wrote:
> D/TI_Video_Decoder( 934): VIDDEC_InitDSP_H264Dec():6573 After Rounding:
> nFrameW
> idth = 1280, nFrameHeight = 544
> drivers/dsp/bridge/services/sync.c, line 357: Assertion (0) failed.
> drivers/dsp/bridge/services/sync.c, line 357: Assertion (0) failed.
Does the version of your sync.c file points to sync_entercs() and the
the assert failed for "in_interrupt()" for the line 357?
Do your dspbridge version uses the WDT implementation?
> D/TI_Video_Decoder( 934): VIDDEC_InitDSP_H264Dec():6619
> LCML_InitMMCodec Failed
> !...80001009
> D/TI_Video_Decoder( 934): VIDDEC_HandleCommand():1950 LCML Error 1
> D/TI_Video_Decoder( 934): OMX_VidDec_Thread():165 Error in Select
Regards,
Rene Sapiens
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: DSP Bridge video decode of above VGA videos
2010-11-22 16:56 ` Sapiens, Rene
@ 2010-11-22 17:12 ` James Adams
2010-11-22 21:42 ` Sapiens, Rene
0 siblings, 1 reply; 13+ messages in thread
From: James Adams @ 2010-11-22 17:12 UTC (permalink / raw)
To: Sapiens, Rene; +Cc: Kanigeri, Hari, linux-omap
Hi Rene,
We have got the watchdog timer enabled at the moment (interval 5 seconds).
The code does indeed point to the line as you say.
I tried using dump_stack and it was getting triggered by an interrupt
calling handle_hibernation_fromDSP which then called functions
eventually triggering the SYNC_entercs (via DEV_getfirst if I remember
right)
I certainly don't understand why this should happen, but it seems to
happen quite a lot (probably every 5 seconds...) and the lower
resolution videos didn't seem to mind so I have been ignoring it.
Is it a bad idea to use WDT?
Thanks,
James
On Mon, Nov 22, 2010 at 4:56 PM, Sapiens, Rene <rene.sapiens@ti.com> wrote:
> Hi James,
>
> On Mon, Nov 22, 2010 at 9:26 AM, James Adams <james.r.adams@gmail.com> wrote:
>> D/TI_Video_Decoder( 934): VIDDEC_InitDSP_H264Dec():6573 After Rounding:
>> nFrameW
>> idth = 1280, nFrameHeight = 544
>> drivers/dsp/bridge/services/sync.c, line 357: Assertion (0) failed.
>> drivers/dsp/bridge/services/sync.c, line 357: Assertion (0) failed.
>
> Does the version of your sync.c file points to sync_entercs() and the
> the assert failed for "in_interrupt()" for the line 357?
>
> Do your dspbridge version uses the WDT implementation?
>
>> D/TI_Video_Decoder( 934): VIDDEC_InitDSP_H264Dec():6619
>> LCML_InitMMCodec Failed
>> !...80001009
>> D/TI_Video_Decoder( 934): VIDDEC_HandleCommand():1950 LCML Error 1
>> D/TI_Video_Decoder( 934): OMX_VidDec_Thread():165 Error in Select
>
> Regards,
> Rene Sapiens
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: DSP Bridge video decode of above VGA videos
2010-11-22 17:12 ` James Adams
@ 2010-11-22 21:42 ` Sapiens, Rene
2010-11-23 9:30 ` James Adams
0 siblings, 1 reply; 13+ messages in thread
From: Sapiens, Rene @ 2010-11-22 21:42 UTC (permalink / raw)
To: James Adams; +Cc: Kanigeri, Hari, linux-omap
James,
On Mon, Nov 22, 2010 at 11:12 AM, James Adams <james.r.adams@gmail.com> wrote:
> Hi Rene,
>
> We have got the watchdog timer enabled at the moment (interval 5 seconds).
> The code does indeed point to the line as you say.
> I tried using dump_stack and it was getting triggered by an interrupt
> calling handle_hibernation_fromDSP which then called functions
> eventually triggering the SYNC_entercs (via DEV_getfirst if I remember
> right)
> I certainly don't understand why this should happen, but it seems to
> happen quite a lot (probably every 5 seconds...) and the lower
> resolution videos didn't seem to mind so I have been ignoring it.
>
Looking at the drivers/dsp/bridge/wmd/tiomap3430_pwr.c file tagged
with L25.12 release at [1] I don't see feasible the path to have
handle_hibernation_fromDSP() to get to SYNC_entercs(), so probably you
have a newer or older version of the file.
Basically what i was looking with those assertions is to see if those
could be because of a DSP WDT overflow. Also those assertions can
fail because of the calling of IO_DispatchMsg by io_dpc(), if that's
the case there should not be a problem. On the other hand if there is
a WDT overflow those assertions could also fail.
Can you double check by printing the call stack again when the
assertion fails, just to see why for your case
handle_hibernation_fromDSP() is failing in the assertion?
> Is it a bad idea to use WDT?
No, it is ok to use it.
Regards,
Rene Sapiens
--
[1] http://git.omapzoom.org/?p=kernel/omap.git;a=blob;f=drivers/dsp/bridge/wmd/tiomap3430_pwr.c;h=f698b4475584e92467e03ecec96bc887948275f9;hb=64b404e9f457f19537972e7f2424f4c73a8a7789#l116
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: DSP Bridge video decode of above VGA videos
2010-11-22 21:42 ` Sapiens, Rene
@ 2010-11-23 9:30 ` James Adams
2010-11-23 14:34 ` James Adams
2010-11-24 0:38 ` Sapiens, Rene
0 siblings, 2 replies; 13+ messages in thread
From: James Adams @ 2010-11-23 9:30 UTC (permalink / raw)
To: Sapiens, Rene; +Cc: Kanigeri, Hari, linux-omap
Hi Rene,
This email contains 2 error logs. The first comes from trying to switch
to using the software decoder.
Is there something else I need to do to revert to software codecs
perhaps?
The second error log is the stack trace when the watchdog timer calls
SYNC_EnterCS.
I am sorry for troubling you with all these newbie questions, I've done
quite a lot of Linux driver work before and have written my own embedded
H264 and MPEG4 codecs, but I have only been looking at Android for a
couple of weeks and am finding it rather overwhelming how much there is
to learn!
If I try to switch back to software codecs by commenting out the
OMX.TI.Video.Decoder line in
hardware/ti/omx/system/src/openmax_il/omx_core/src/OMX_Core.c then I get
the following errors:
D/omx_interface( 934): TIOMXInterface: creating interface
D/omx_interface( 934): Calling DLOPEN on OMX_CORE_LIBRARY
(libOMX_Core.so)
D/omx_interface( 934): DLOPEN SUCCEEDED (libOMX_Core.so)
D/omx_interface( 934): TIOMXInterface: library lookup success
D/TIOMX_CORE( 934): init count = 1
I/ActivityManager( 966): Displayed activity
com.android.gallery/com.android.cam
era.MovieView: 540 ms (total 540 ms)
V/MovieView( 1145): hasFocus
D/VideoMio34xx( 934): Vendor(34xx) Specific CloseFrameBuf
D/VideoMio34xx( 934): AndroidSurfaceOutputOmap34xx::setParametersSync()
Video F
ormat Key, Value X-YUV-420
D/VideoMio34xx( 934): AndroidSurfaceOutputOmap34xx::setParametersSync()
Error,
unrecognized key x-pvmf/mediaxfer/output/rate;type=rel;valtype=int32
D/VideoMio34xx( 934): AndroidSurfaceOutputOmap34xx::setParametersSync()
Error,
unrecognized key x-pvmf/port/formattype;valtype=int32
D/VideoMio34xx( 934): AndroidSurfaceOutputOmap34xx::setParametersSync()
Video W
idth, Value 320
D/VideoMio34xx( 934): AndroidSurfaceOutputOmap34xx::setParametersSync()
Video H
eight, Value 240
D/VideoMio34xx( 934): AndroidSurfaceOutputOmap34xx::setParametersSync()
Video D
isplay Height, Value 240
D/VideoMio34xx( 934): AndroidSurfaceOutputOmap34xx::setParametersSync()
Video D
isplay Width, Value 320
D/VideoMio34xx( 934): AndroidSurfaceOutputOmap34xx::setParametersSync()
Number
of Buffer, Value 2
D/VideoMio34xx( 934): AndroidSurfaceOutputOmap34xx::setParametersSync()
Buffer
Size, Value 115200
D/VideoMio34xx( 934): Calling Vendor(34xx) Specific initCheck
D/TIOverlay( 966): overlay_createOverlay:IN w=320 h=240 format=22
D/TIOverlay( 966): hardware/ti/omap3/liboverlay/overlay.cpp ######
Calling ove
rlay_createOverlay() ######
I/TIOverlay( 966): Opened video1/fd=60/obj=002dcf20/shm=59/size=4096
D/TIOverlay( 966): overlay_createOverlay: OUT
D/TIOverlay( 966): hardware/ti/omap3/liboverlay/overlay.cpp ######
Calling ove
rlay_setParameter() ######
D/TIOverlay( 966): hardware/ti/omap3/liboverlay/overlay.cpp ######
Calling ove
rlay_setPosition() ######
D/TIOverlay( 966): hardware/ti/omap3/liboverlay/overlay.cpp ######
Calling ove
rlay_setParameter() ######
D/TIOverlay( 966): hardware/ti/omap3/liboverlay/overlay.cpp ######
Calling ove
rlay_setParameter() ######
D/TIOverlay( 966): hardware/ti/omap3/liboverlay/overlay.cpp ######
Calling ove
rlay_setParameter() ######
D/TIOverlay( 966): hardware/ti/omap3/liboverlay/overlay.cpp ######
Calling ove
rlay_setParameter() ######
D/TIOverlay( 966): hardware/ti/omap3/liboverlay/overlay.cpp ######
Calling ove
rlay_setParameter() ######
D/TIOverlay( 966): hardware/ti/omap3/liboverlay/overlay.cpp ######
Calling ove
rlay_commit() ######
I/TIOverlay( 966): Position/X0/Y0/W240/H320
I/TIOverlay( 966): Adjusted Position/X0/Y0/W320/H240
I/TIOverlay( 966): Rotation/90
I/TIOverlay( 966): ColorKey/0
I/TIOverlay( 966): shared->dispH = 320, shared->dispW = 240
I/Overlay-V4L2( 966): dumping driver state:
I/Overlay-V4L2( 966): output pixfmt:
I/Overlay-V4L2( 966): w: 320
I/Overlay-V4L2( 966): h: 240
I/Overlay-V4L2( 966): color: 7
I/Overlay-V4L2( 966): UYVY
I/Overlay-V4L2( 966): v4l2_overlay window:
I/Overlay-V4L2( 966): window l: 0
I/Overlay-V4L2( 966): window t: 0
I/Overlay-V4L2( 966): window w: 320
I/Overlay-V4L2( 966): window h: 240
I/Overlay-V4L2( 966): output crop:
I/Overlay-V4L2( 966): crop l: 0
I/Overlay-V4L2( 966): crop t: 0
I/Overlay-V4L2( 966): crop w: 320
I/Overlay-V4L2( 966): crop h: 240
D/TIOverlay( 934): hardware/ti/omap3/liboverlay/overlay.cpp ######
Calling ove
rlay_device_open() ######
D/TIOverlay( 934): hardware/ti/omap3/liboverlay/overlay.cpp ######
Calling ove
rlay_initialize() ######
D/TIOverlay( 934): hardware/ti/omap3/liboverlay/overlay.cpp ######
Calling ove
rlay_data_setParameter() ######
I/VideoMio34xx( 934): Actual resolution: 320x240
I/VideoMio34xx( 934): Video resolution: 320x240
D/TIOverlay( 934): hardware/ti/omap3/liboverlay/overlay.cpp ######
Calling ove
rlay_getBufferCount() ######
D/VideoMio34xx( 934): number of buffers = 6
D/TIOverlay( 934): hardware/ti/omap3/liboverlay/overlay.cpp ######
Calling ove
rlay_getBufferAddress() ######
I/TIOverlay( 934): Buffer/0/addr=40eb9000/len=155648
D/VideoMio34xx( 934): buffer = 0 allocated addr=0x40eb9000
D/TIOverlay( 934): hardware/ti/omap3/liboverlay/overlay.cpp ######
Calling ove
rlay_getBufferAddress() ######
I/TIOverlay( 934): Buffer/1/addr=40edf000/len=155648
D/VideoMio34xx( 934): buffer = 1 allocated addr=0x40edf000
D/TIOverlay( 934): hardware/ti/omap3/liboverlay/overlay.cpp ######
Calling ove
rlay_getBufferAddress() ######
I/TIOverlay( 934): Buffer/2/addr=40f05000/len=155648
D/VideoMio34xx( 934): buffer = 2 allocated addr=0x40f05000
D/TIOverlay( 934): hardware/ti/omap3/liboverlay/overlay.cpp ######
Calling ove
rlay_getBufferAddress() ######
I/TIOverlay( 934): Buffer/3/addr=40f2b000/len=155648
D/VideoMio34xx( 934): buffer = 3 allocated addr=0x40f2b000
D/TIOverlay( 934): hardware/ti/omap3/liboverlay/overlay.cpp ######
Calling ove
rlay_getBufferAddress() ######
I/TIOverlay( 934): Buffer/4/addr=40f51000/len=155648
D/VideoMio34xx( 934): buffer = 4 allocated addr=0x40f51000
D/TIOverlay( 934): hardware/ti/omap3/liboverlay/overlay.cpp ######
Calling ove
rlay_getBufferAddress() ######
I/TIOverlay( 934): Buffer/5/addr=40f77000/len=155648
D/VideoMio34xx( 934): buffer = 5 allocated addr=0x40f77000
I/VideoMio34xx( 934): Ln 598 iVideoSubFormat X-YUV-420-PLANAR. do NOT
allocate
decoder buffer from overlay
W/MediaPlayer( 1145): info/warning (1, 44)
I/MediaPlayer( 1145): Info (1,44)
D/MediaPlayer( 1145): getMetadata
D/Omap3ALSA( 934): open called for devices 00000000 in mode 0...
E/VideoMio34xx( 934): AndroidSurfaceOutputOmap34xx::writeAsync: aData
does not
match any v4l buffer address
I/Omap3ALSA( 934): Initialized ALSA PLAYBACK device default
E/AudioHardwareALSA( 934): RE-OPEN AFTER STANDBY:: took 79 msecs
W/AudioFlinger( 934): write blocked for 79 msecs, 2 delayed writes,
thread 0x25
1a8
E/VideoMio34xx( 934): AndroidSurfaceOutputOmap34xx::writeAsync: aData
does not
match any v4l buffer address
E/VideoMio34xx( 934): AndroidSurfaceOutputOmap34xx::writeAsync: aData
does not
match any v4l buffer address
E/VideoMio34xx( 934): AndroidSurfaceOutputOmap34xx::writeAsync: aData
does not
match any v4l buffer address
The stack trace is shown below.
[<c0412864>] (dump_stack+0x0/0x14) from [<c0278c18>]
(SYNC_EnterCS+0x48/0xe4)
[<c0278bd0>] (SYNC_EnterCS+0x0/0xe4) from [<c0279e24>]
(REG_GetValue+0x60/0xa0)
r5:c05ba390 r4:c04f092c
[<c0279dc4>] (REG_GetValue+0x0/0xa0) from [<c027987c>]
(CFG_GetObject+0x60/0xe0)
r7:cfa87a80 r6:00000002 r5:cf98fe94 r4:00000002
[<c027981c>] (CFG_GetObject+0x0/0xe0) from [<c02913c0>]
(DRV_GetFirstDevObject+0
x1c/0x4c)
r5:c05ba3c0 r4:00000000
[<c02913a4>] (DRV_GetFirstDevObject+0x0/0x4c) from [<c02858e4>]
(DEV_GetFirst+0x
10/0x44)
[<c02858d4>] (DEV_GetFirst+0x0/0x44) from [<c027d430>]
(dsp_wdt_enable+0x44/0xe0
)
r5:c05ba3c0 r4:00000000
[<c027d3ec>] (dsp_wdt_enable+0x0/0xe0) from [<c02820fc>]
(handle_hibernation_fro
mDSP+0x148/0x1ec)
r5:cfaa0000 r4:00008000
[<c0281fb4>] (handle_hibernation_fromDSP+0x0/0x1ec) from [<c02810c0>]
(WMD_DEV_C
trl+0xfc/0x130)
r7:cf98e000 r6:cf98ff34 r5:cc5f6a88 r4:cfb89e00
[<c0280fc4>] (WMD_DEV_Ctrl+0x0/0x130) from [<c027dc24>]
(io_mbox_msg+0x70/0x1d8)
r7:cf98e000 r6:c05496c4 r5:cc5f6a88 r4:cfb89e00
[<c027dbb4>] (io_mbox_msg+0x0/0x1d8) from [<c0059308>]
(mbox_rx_work+0xf4/0x100)
r5:cc5f6a88 r4:0000200a
[<c0059214>] (mbox_rx_work+0x0/0x100) from [<c007ebb0>]
(run_workqueue+0xc8/0x18
4)
[<c007eae8>] (run_workqueue+0x0/0x184) from [<c007f2dc>]
(worker_thread+0x104/0x
118)
r9:00000000 r8:00000000 r7:cf811040 r6:cf94e140 r5:cf94e148
r4:cf98e000
[<c007f1d8>] (worker_thread+0x0/0x118) from [<c0082cb4>]
(kthread+0x54/0x80)
r7:00000000 r6:00000000 r5:c007f1d8 r4:cf94e140
[<c0082c60>] (kthread+0x0/0x80) from [<c0070b1c>] (do_exit+0x0/0x7bc)
r5:00000000 r4:00000000
drivers/dsp/bridge/services/sync.c, line 358: Assertion (0) failed.
On Mon, Nov 22, 2010 at 9:42 PM, Sapiens, Rene <rene.sapiens@ti.com> wrote:
> James,
>
> On Mon, Nov 22, 2010 at 11:12 AM, James Adams <james.r.adams@gmail.com> wrote:
>> Hi Rene,
>>
>> We have got the watchdog timer enabled at the moment (interval 5 seconds).
>> The code does indeed point to the line as you say.
>> I tried using dump_stack and it was getting triggered by an interrupt
>> calling handle_hibernation_fromDSP which then called functions
>> eventually triggering the SYNC_entercs (via DEV_getfirst if I remember
>> right)
>> I certainly don't understand why this should happen, but it seems to
>> happen quite a lot (probably every 5 seconds...) and the lower
>> resolution videos didn't seem to mind so I have been ignoring it.
>>
>
> Looking at the drivers/dsp/bridge/wmd/tiomap3430_pwr.c file tagged
> with L25.12 release at [1] I don't see feasible the path to have
> handle_hibernation_fromDSP() to get to SYNC_entercs(), so probably you
> have a newer or older version of the file.
>
> Basically what i was looking with those assertions is to see if those
> could be because of a DSP WDT overflow. Also those assertions can
> fail because of the calling of IO_DispatchMsg by io_dpc(), if that's
> the case there should not be a problem. On the other hand if there is
> a WDT overflow those assertions could also fail.
>
> Can you double check by printing the call stack again when the
> assertion fails, just to see why for your case
> handle_hibernation_fromDSP() is failing in the assertion?
>
>> Is it a bad idea to use WDT?
>
> No, it is ok to use it.
>
> Regards,
> Rene Sapiens
> --
> [1] http://git.omapzoom.org/?p=kernel/omap.git;a=blob;f=drivers/dsp/bridge/wmd/tiomap3430_pwr.c;h=f698b4475584e92467e03ecec96bc887948275f9;hb=64b404e9f457f19537972e7f2424f4c73a8a7789#l116
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: DSP Bridge video decode of above VGA videos
2010-11-23 9:30 ` James Adams
@ 2010-11-23 14:34 ` James Adams
2010-11-24 0:17 ` Sapiens, Rene
2010-11-24 0:38 ` Sapiens, Rene
1 sibling, 1 reply; 13+ messages in thread
From: James Adams @ 2010-11-23 14:34 UTC (permalink / raw)
To: Sapiens, Rene; +Cc: Kanigeri, Hari, linux-omap
A bit more information about why videos are not playing in a port of
Zoom2 to gumstix:
1)
I can switch to use the software codec by simply removing the
/system/etc/01_Vendor_ti_omx.cfg file.
2)
If I use the OpenCORE unit tests I can successfully decode:
VGA movies with software codec
1280*544 movie with software codec
VGA movies with DSP codec
but it fails for the 1280x544 movie with DSP codec.
This is the error log:
pvplayer_engine_test -test 1 1 -source wall720p.mp4
SDK Labeled: PVDEV_CORE_RELEASE_6.506.4.1 built on 20090312
Test Program for pvPlayer engine class.
Input file name 'wall720p.mp4'
Test case range 1 to 1
Compressed output Video(No) Audio(No)
Log level 8; Log node 0 Log Text 0 Log Mem 0
Starting Test 1: Open-Play-Stop-Reset
****************LCML ERROR : DSP ************************
Error: Create the Node : Err Num = 8000800c
****************LCML ERROR : DSP ************************
3)
I can't find this 8000800c number defined anywhere in the Android tree.
Any idea what it means?
4)
Using the software codec from inside the Android Gallery application I
still get the same errors as mentioned before about missing video buffer
addresses.
Thanks for any advice people can give, I am feeling increasingly
bewildered by all the levels of OpenCore, OMX, OpenMax, DSP bridge...
On Tue, Nov 23, 2010 at 9:30 AM, James Adams <james.r.adams@gmail.com> wrote:
> Hi Rene,
>
> This email contains 2 error logs. The first comes from trying to switch
> to using the software decoder.
> Is there something else I need to do to revert to software codecs
> perhaps?
>
> The second error log is the stack trace when the watchdog timer calls
> SYNC_EnterCS.
>
> I am sorry for troubling you with all these newbie questions, I've done
> quite a lot of Linux driver work before and have written my own embedded
> H264 and MPEG4 codecs, but I have only been looking at Android for a
> couple of weeks and am finding it rather overwhelming how much there is
> to learn!
>
> If I try to switch back to software codecs by commenting out the
> OMX.TI.Video.Decoder line in
> hardware/ti/omx/system/src/openmax_il/omx_core/src/OMX_Core.c then I get
> the following errors:
>
> D/omx_interface( 934): TIOMXInterface: creating interface
> D/omx_interface( 934): Calling DLOPEN on OMX_CORE_LIBRARY
> (libOMX_Core.so)
> D/omx_interface( 934): DLOPEN SUCCEEDED (libOMX_Core.so)
> D/omx_interface( 934): TIOMXInterface: library lookup success
> D/TIOMX_CORE( 934): init count = 1
> I/ActivityManager( 966): Displayed activity
> com.android.gallery/com.android.cam
> era.MovieView: 540 ms (total 540 ms)
> V/MovieView( 1145): hasFocus
> D/VideoMio34xx( 934): Vendor(34xx) Specific CloseFrameBuf
> D/VideoMio34xx( 934): AndroidSurfaceOutputOmap34xx::setParametersSync()
> Video F
> ormat Key, Value X-YUV-420
> D/VideoMio34xx( 934): AndroidSurfaceOutputOmap34xx::setParametersSync()
> Error,
> unrecognized key x-pvmf/mediaxfer/output/rate;type=rel;valtype=int32
> D/VideoMio34xx( 934): AndroidSurfaceOutputOmap34xx::setParametersSync()
> Error,
> unrecognized key x-pvmf/port/formattype;valtype=int32
> D/VideoMio34xx( 934): AndroidSurfaceOutputOmap34xx::setParametersSync()
> Video W
> idth, Value 320
> D/VideoMio34xx( 934): AndroidSurfaceOutputOmap34xx::setParametersSync()
> Video H
> eight, Value 240
> D/VideoMio34xx( 934): AndroidSurfaceOutputOmap34xx::setParametersSync()
> Video D
> isplay Height, Value 240
> D/VideoMio34xx( 934): AndroidSurfaceOutputOmap34xx::setParametersSync()
> Video D
> isplay Width, Value 320
> D/VideoMio34xx( 934): AndroidSurfaceOutputOmap34xx::setParametersSync()
> Number
> of Buffer, Value 2
> D/VideoMio34xx( 934): AndroidSurfaceOutputOmap34xx::setParametersSync()
> Buffer
> Size, Value 115200
> D/VideoMio34xx( 934): Calling Vendor(34xx) Specific initCheck
> D/TIOverlay( 966): overlay_createOverlay:IN w=320 h=240 format=22
> D/TIOverlay( 966): hardware/ti/omap3/liboverlay/overlay.cpp ######
> Calling ove
> rlay_createOverlay() ######
> I/TIOverlay( 966): Opened video1/fd=60/obj=002dcf20/shm=59/size=4096
> D/TIOverlay( 966): overlay_createOverlay: OUT
> D/TIOverlay( 966): hardware/ti/omap3/liboverlay/overlay.cpp ######
> Calling ove
> rlay_setParameter() ######
> D/TIOverlay( 966): hardware/ti/omap3/liboverlay/overlay.cpp ######
> Calling ove
> rlay_setPosition() ######
> D/TIOverlay( 966): hardware/ti/omap3/liboverlay/overlay.cpp ######
> Calling ove
> rlay_setParameter() ######
> D/TIOverlay( 966): hardware/ti/omap3/liboverlay/overlay.cpp ######
> Calling ove
> rlay_setParameter() ######
> D/TIOverlay( 966): hardware/ti/omap3/liboverlay/overlay.cpp ######
> Calling ove
> rlay_setParameter() ######
> D/TIOverlay( 966): hardware/ti/omap3/liboverlay/overlay.cpp ######
> Calling ove
> rlay_setParameter() ######
> D/TIOverlay( 966): hardware/ti/omap3/liboverlay/overlay.cpp ######
> Calling ove
> rlay_setParameter() ######
> D/TIOverlay( 966): hardware/ti/omap3/liboverlay/overlay.cpp ######
> Calling ove
> rlay_commit() ######
> I/TIOverlay( 966): Position/X0/Y0/W240/H320
> I/TIOverlay( 966): Adjusted Position/X0/Y0/W320/H240
> I/TIOverlay( 966): Rotation/90
> I/TIOverlay( 966): ColorKey/0
> I/TIOverlay( 966): shared->dispH = 320, shared->dispW = 240
> I/Overlay-V4L2( 966): dumping driver state:
> I/Overlay-V4L2( 966): output pixfmt:
> I/Overlay-V4L2( 966): w: 320
> I/Overlay-V4L2( 966): h: 240
> I/Overlay-V4L2( 966): color: 7
> I/Overlay-V4L2( 966): UYVY
> I/Overlay-V4L2( 966): v4l2_overlay window:
> I/Overlay-V4L2( 966): window l: 0
> I/Overlay-V4L2( 966): window t: 0
> I/Overlay-V4L2( 966): window w: 320
> I/Overlay-V4L2( 966): window h: 240
> I/Overlay-V4L2( 966): output crop:
> I/Overlay-V4L2( 966): crop l: 0
> I/Overlay-V4L2( 966): crop t: 0
> I/Overlay-V4L2( 966): crop w: 320
> I/Overlay-V4L2( 966): crop h: 240
> D/TIOverlay( 934): hardware/ti/omap3/liboverlay/overlay.cpp ######
> Calling ove
> rlay_device_open() ######
> D/TIOverlay( 934): hardware/ti/omap3/liboverlay/overlay.cpp ######
> Calling ove
> rlay_initialize() ######
> D/TIOverlay( 934): hardware/ti/omap3/liboverlay/overlay.cpp ######
> Calling ove
> rlay_data_setParameter() ######
> I/VideoMio34xx( 934): Actual resolution: 320x240
> I/VideoMio34xx( 934): Video resolution: 320x240
> D/TIOverlay( 934): hardware/ti/omap3/liboverlay/overlay.cpp ######
> Calling ove
> rlay_getBufferCount() ######
> D/VideoMio34xx( 934): number of buffers = 6
> D/TIOverlay( 934): hardware/ti/omap3/liboverlay/overlay.cpp ######
> Calling ove
> rlay_getBufferAddress() ######
> I/TIOverlay( 934): Buffer/0/addr=40eb9000/len=155648
> D/VideoMio34xx( 934): buffer = 0 allocated addr=0x40eb9000
> D/TIOverlay( 934): hardware/ti/omap3/liboverlay/overlay.cpp ######
> Calling ove
> rlay_getBufferAddress() ######
> I/TIOverlay( 934): Buffer/1/addr=40edf000/len=155648
> D/VideoMio34xx( 934): buffer = 1 allocated addr=0x40edf000
> D/TIOverlay( 934): hardware/ti/omap3/liboverlay/overlay.cpp ######
> Calling ove
> rlay_getBufferAddress() ######
> I/TIOverlay( 934): Buffer/2/addr=40f05000/len=155648
> D/VideoMio34xx( 934): buffer = 2 allocated addr=0x40f05000
> D/TIOverlay( 934): hardware/ti/omap3/liboverlay/overlay.cpp ######
> Calling ove
> rlay_getBufferAddress() ######
> I/TIOverlay( 934): Buffer/3/addr=40f2b000/len=155648
> D/VideoMio34xx( 934): buffer = 3 allocated addr=0x40f2b000
> D/TIOverlay( 934): hardware/ti/omap3/liboverlay/overlay.cpp ######
> Calling ove
> rlay_getBufferAddress() ######
> I/TIOverlay( 934): Buffer/4/addr=40f51000/len=155648
> D/VideoMio34xx( 934): buffer = 4 allocated addr=0x40f51000
> D/TIOverlay( 934): hardware/ti/omap3/liboverlay/overlay.cpp ######
> Calling ove
> rlay_getBufferAddress() ######
> I/TIOverlay( 934): Buffer/5/addr=40f77000/len=155648
> D/VideoMio34xx( 934): buffer = 5 allocated addr=0x40f77000
> I/VideoMio34xx( 934): Ln 598 iVideoSubFormat X-YUV-420-PLANAR. do NOT
> allocate
> decoder buffer from overlay
> W/MediaPlayer( 1145): info/warning (1, 44)
> I/MediaPlayer( 1145): Info (1,44)
> D/MediaPlayer( 1145): getMetadata
> D/Omap3ALSA( 934): open called for devices 00000000 in mode 0...
> E/VideoMio34xx( 934): AndroidSurfaceOutputOmap34xx::writeAsync: aData
> does not
> match any v4l buffer address
> I/Omap3ALSA( 934): Initialized ALSA PLAYBACK device default
> E/AudioHardwareALSA( 934): RE-OPEN AFTER STANDBY:: took 79 msecs
> W/AudioFlinger( 934): write blocked for 79 msecs, 2 delayed writes,
> thread 0x25
> 1a8
> E/VideoMio34xx( 934): AndroidSurfaceOutputOmap34xx::writeAsync: aData
> does not
> match any v4l buffer address
> E/VideoMio34xx( 934): AndroidSurfaceOutputOmap34xx::writeAsync: aData
> does not
> match any v4l buffer address
> E/VideoMio34xx( 934): AndroidSurfaceOutputOmap34xx::writeAsync: aData
> does not
> match any v4l buffer address
>
> The stack trace is shown below.
>
> [<c0412864>] (dump_stack+0x0/0x14) from [<c0278c18>]
> (SYNC_EnterCS+0x48/0xe4)
> [<c0278bd0>] (SYNC_EnterCS+0x0/0xe4) from [<c0279e24>]
> (REG_GetValue+0x60/0xa0)
> r5:c05ba390 r4:c04f092c
> [<c0279dc4>] (REG_GetValue+0x0/0xa0) from [<c027987c>]
> (CFG_GetObject+0x60/0xe0)
> r7:cfa87a80 r6:00000002 r5:cf98fe94 r4:00000002
> [<c027981c>] (CFG_GetObject+0x0/0xe0) from [<c02913c0>]
> (DRV_GetFirstDevObject+0
> x1c/0x4c)
> r5:c05ba3c0 r4:00000000
> [<c02913a4>] (DRV_GetFirstDevObject+0x0/0x4c) from [<c02858e4>]
> (DEV_GetFirst+0x
> 10/0x44)
> [<c02858d4>] (DEV_GetFirst+0x0/0x44) from [<c027d430>]
> (dsp_wdt_enable+0x44/0xe0
> )
> r5:c05ba3c0 r4:00000000
> [<c027d3ec>] (dsp_wdt_enable+0x0/0xe0) from [<c02820fc>]
> (handle_hibernation_fro
> mDSP+0x148/0x1ec)
> r5:cfaa0000 r4:00008000
> [<c0281fb4>] (handle_hibernation_fromDSP+0x0/0x1ec) from [<c02810c0>]
> (WMD_DEV_C
> trl+0xfc/0x130)
> r7:cf98e000 r6:cf98ff34 r5:cc5f6a88 r4:cfb89e00
> [<c0280fc4>] (WMD_DEV_Ctrl+0x0/0x130) from [<c027dc24>]
> (io_mbox_msg+0x70/0x1d8)
> r7:cf98e000 r6:c05496c4 r5:cc5f6a88 r4:cfb89e00
> [<c027dbb4>] (io_mbox_msg+0x0/0x1d8) from [<c0059308>]
> (mbox_rx_work+0xf4/0x100)
> r5:cc5f6a88 r4:0000200a
> [<c0059214>] (mbox_rx_work+0x0/0x100) from [<c007ebb0>]
> (run_workqueue+0xc8/0x18
> 4)
> [<c007eae8>] (run_workqueue+0x0/0x184) from [<c007f2dc>]
> (worker_thread+0x104/0x
> 118)
> r9:00000000 r8:00000000 r7:cf811040 r6:cf94e140 r5:cf94e148
> r4:cf98e000
> [<c007f1d8>] (worker_thread+0x0/0x118) from [<c0082cb4>]
> (kthread+0x54/0x80)
> r7:00000000 r6:00000000 r5:c007f1d8 r4:cf94e140
> [<c0082c60>] (kthread+0x0/0x80) from [<c0070b1c>] (do_exit+0x0/0x7bc)
> r5:00000000 r4:00000000
> drivers/dsp/bridge/services/sync.c, line 358: Assertion (0) failed.
>
>
> On Mon, Nov 22, 2010 at 9:42 PM, Sapiens, Rene <rene.sapiens@ti.com> wrote:
>> James,
>>
>> On Mon, Nov 22, 2010 at 11:12 AM, James Adams <james.r.adams@gmail.com> wrote:
>>> Hi Rene,
>>>
>>> We have got the watchdog timer enabled at the moment (interval 5 seconds).
>>> The code does indeed point to the line as you say.
>>> I tried using dump_stack and it was getting triggered by an interrupt
>>> calling handle_hibernation_fromDSP which then called functions
>>> eventually triggering the SYNC_entercs (via DEV_getfirst if I remember
>>> right)
>>> I certainly don't understand why this should happen, but it seems to
>>> happen quite a lot (probably every 5 seconds...) and the lower
>>> resolution videos didn't seem to mind so I have been ignoring it.
>>>
>>
>> Looking at the drivers/dsp/bridge/wmd/tiomap3430_pwr.c file tagged
>> with L25.12 release at [1] I don't see feasible the path to have
>> handle_hibernation_fromDSP() to get to SYNC_entercs(), so probably you
>> have a newer or older version of the file.
>>
>> Basically what i was looking with those assertions is to see if those
>> could be because of a DSP WDT overflow. Also those assertions can
>> fail because of the calling of IO_DispatchMsg by io_dpc(), if that's
>> the case there should not be a problem. On the other hand if there is
>> a WDT overflow those assertions could also fail.
>>
>> Can you double check by printing the call stack again when the
>> assertion fails, just to see why for your case
>> handle_hibernation_fromDSP() is failing in the assertion?
>>
>>> Is it a bad idea to use WDT?
>>
>> No, it is ok to use it.
>>
>> Regards,
>> Rene Sapiens
>> --
>> [1] http://git.omapzoom.org/?p=kernel/omap.git;a=blob;f=drivers/dsp/bridge/wmd/tiomap3430_pwr.c;h=f698b4475584e92467e03ecec96bc887948275f9;hb=64b404e9f457f19537972e7f2424f4c73a8a7789#l116
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: DSP Bridge video decode of above VGA videos
2010-11-23 14:34 ` James Adams
@ 2010-11-24 0:17 ` Sapiens, Rene
0 siblings, 0 replies; 13+ messages in thread
From: Sapiens, Rene @ 2010-11-24 0:17 UTC (permalink / raw)
To: James Adams; +Cc: Kanigeri, Hari, linux-omap
Hi James,
On Tue, Nov 23, 2010 at 8:34 AM, James Adams <james.r.adams@gmail.com> wrote:
> A bit more information about why videos are not playing in a port of
> Zoom2 to gumstix:
>
> 2)
> If I use the OpenCORE unit tests I can successfully decode:
> VGA movies with software codec
> 1280*544 movie with software codec
> VGA movies with DSP codec
> but it fails for the 1280x544 movie with DSP codec.
>
> This is the error log:
> pvplayer_engine_test -test 1 1 -source wall720p.mp4
> SDK Labeled: PVDEV_CORE_RELEASE_6.506.4.1 built on 20090312
>
> Test Program for pvPlayer engine class.
> Input file name 'wall720p.mp4'
> Test case range 1 to 1
> Compressed output Video(No) Audio(No)
> Log level 8; Log node 0 Log Text 0 Log Mem 0
>
> Starting Test 1: Open-Play-Stop-Reset
>
> ****************LCML ERROR : DSP ************************
> Error: Create the Node : Err Num = 8000800c
> ****************LCML ERROR : DSP ************************
>
It looks that your system is getting ride of memory and it is failing
in the creation stage of a DSP node.
I suggest you to free all the not needed resources before trying to
decode the 1280x544 movie with the DSP decoders, There are a couple of
minor allocations done during the node create stage.
To debug it you can take a look to the bridge code:
drivers/dsp/bridge/
Basically communication with the DSP is handled by such driver[1].
The error should be coming from drivers/dsp/bridge/rmgr/node.c
in the node_create() function.
> 3)
> I can't find this 8000800c number defined anywhere in the Android tree.
> Any idea what it means?
For this version of the bridge driver 0x8000800c should mean a
"DSP_EMEMORY" error, find it in [2]. You can take a look in the driver
mentioned above for the place where you are getting that error.
Functions where you can get that error in the node's create phase are:
1) drivers/dsp/bridge/rmgr/Nldr.c
LoadLib()
2) drivers/dsp/bridge/pmgr/Dbll.c
DBLL_open()
3) drivers/dsp/bridge/rmgr/Dbdcd.c
GetDepLibInfo()
4) drivers/dsp/bridge/pmgr/Dbll.c
DBLL_load()
5) drivers/dsp/bridge/rmgr/rmm.c
RMM_alloc()
- When calling to allocBlock()
- When allocate list element for new section.
>
> 4)
> Using the software codec from inside the Android Gallery application I
> still get the same errors as mentioned before about missing video buffer
> addresses.
In general, OpenCore/Omx question should go to a different list, since
it is not kernel specific, i would suggest you to contact your vendor
to point you to the correct support team.
Regards,
Rene Sapiens
--
[1] http://omapzoom.org/wiki/DSPBridge_Project#Documents
[2] http://git.omapzoom.org/?p=kernel/omap.git;a=blob;f=arch/arm/plat-omap/include/dspbridge/errbase.h;h=f04c005c06adb253a3b2f8886ba38e4475b578b3;hb=refs/heads/p-android-omap-2.6.29-eclair#l130
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: DSP Bridge video decode of above VGA videos
2010-11-23 9:30 ` James Adams
2010-11-23 14:34 ` James Adams
@ 2010-11-24 0:38 ` Sapiens, Rene
2010-11-24 16:01 ` James Adams
1 sibling, 1 reply; 13+ messages in thread
From: Sapiens, Rene @ 2010-11-24 0:38 UTC (permalink / raw)
To: James Adams; +Cc: Kanigeri, Hari, linux-omap
Hi James,
> The second error log is the stack trace when the watchdog timer calls
> SYNC_EnterCS.
Actually is not the WDT calling the function to get into the critical
section, it is the WDT being disabled when the DSP is going to OFF
state. This should fine.
> The stack trace is shown below.
>
1) Is this trace printed after the 'if (in_interrupt())' statement?
2) Can you check under drivers/dsp/bridge/ to see where is or under
which context io_dispatchpm called?
To get the assertions failing you should be in the context of an
interrupt, the code base that i have is not that way for that reason i
ask for your io_dispatchpm function.
> [<c0412864>] (dump_stack+0x0/0x14) from [<c0278c18>]
> (SYNC_EnterCS+0x48/0xe4)
> [<c0278bd0>] (SYNC_EnterCS+0x0/0xe4) from [<c0279e24>]
> (REG_GetValue+0x60/0xa0)
> r5:c05ba390 r4:c04f092c
> [<c0279dc4>] (REG_GetValue+0x0/0xa0) from [<c027987c>]
> (CFG_GetObject+0x60/0xe0)
> r7:cfa87a80 r6:00000002 r5:cf98fe94 r4:00000002
> [<c027981c>] (CFG_GetObject+0x0/0xe0) from [<c02913c0>]
> (DRV_GetFirstDevObject+0
> x1c/0x4c)
> r5:c05ba3c0 r4:00000000
> [<c02913a4>] (DRV_GetFirstDevObject+0x0/0x4c) from [<c02858e4>]
> (DEV_GetFirst+0x
> 10/0x44)
> [<c02858d4>] (DEV_GetFirst+0x0/0x44) from [<c027d430>]
> (dsp_wdt_enable+0x44/0xe0
> )
> r5:c05ba3c0 r4:00000000
> [<c027d3ec>] (dsp_wdt_enable+0x0/0xe0) from [<c02820fc>]
> (handle_hibernation_fro
> mDSP+0x148/0x1ec)
> r5:cfaa0000 r4:00008000
> [<c0281fb4>] (handle_hibernation_fromDSP+0x0/0x1ec) from [<c02810c0>]
> (WMD_DEV_C
> trl+0xfc/0x130)
> r7:cf98e000 r6:cf98ff34 r5:cc5f6a88 r4:cfb89e00
> [<c0280fc4>] (WMD_DEV_Ctrl+0x0/0x130) from [<c027dc24>]
> (io_mbox_msg+0x70/0x1d8)
> r7:cf98e000 r6:c05496c4 r5:cc5f6a88 r4:cfb89e00
> [<c027dbb4>] (io_mbox_msg+0x0/0x1d8) from [<c0059308>]
> (mbox_rx_work+0xf4/0x100)
> r5:cc5f6a88 r4:0000200a
> [<c0059214>] (mbox_rx_work+0x0/0x100) from [<c007ebb0>]
> (run_workqueue+0xc8/0x18
> 4)
> [<c007eae8>] (run_workqueue+0x0/0x184) from [<c007f2dc>]
> (worker_thread+0x104/0x
> 118)
> r9:00000000 r8:00000000 r7:cf811040 r6:cf94e140 r5:cf94e148
> r4:cf98e000
> [<c007f1d8>] (worker_thread+0x0/0x118) from [<c0082cb4>]
> (kthread+0x54/0x80)
> r7:00000000 r6:00000000 r5:c007f1d8 r4:cf94e140
> [<c0082c60>] (kthread+0x0/0x80) from [<c0070b1c>] (do_exit+0x0/0x7bc)
> r5:00000000 r4:00000000
> drivers/dsp/bridge/services/sync.c, line 358: Assertion (0) failed.
Regards,
Rene Sapiens
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: DSP Bridge video decode of above VGA videos
2010-11-24 0:38 ` Sapiens, Rene
@ 2010-11-24 16:01 ` James Adams
2010-11-24 19:29 ` Uribe de Leon, Armando
0 siblings, 1 reply; 13+ messages in thread
From: James Adams @ 2010-11-24 16:01 UTC (permalink / raw)
To: Sapiens, Rene; +Cc: Kanigeri, Hari, linux-omap
Many thanks for the help Rene, it makes a huge difference being told
whereabouts in the gigabytes of source to start looking!
You are quite correct in that the error comes from NODE_Create.
Node_Create calls DISP_NodeCreate
DISP_NodeCreate calls SendMessage
SendMessage succeeds, but after CHNL_IsIOComplete reads back a status
code from chnlIOC.pBuf which has the error code in it.
My understanding is that this means that the dsp bridge kernel has sent
a message across to the TI DSP, but the DSP is reporting out of memory.
Unfortunately, I don't know where to go from here, any tips?
I've looked at the DSP bridge documents but I still don't really have a
handle on the memory allocation.
My understanding is that:
1) The DSP and ARM share access to the same memory chips
2) The DSP bridge allocates shm_size memory for page tables and
communications
3) The DSP bridge assigns phys_mempool_size memory at a fixed address
for the DSP to store its own data inside
I don't understand where the streaming data gets allocated.
I've tried increasing phys_mempool_size but it behaves the same.
I've added printk to the allocation routines in mem.c, but none of these
are failing. (Although I suspect they are irrelevant and it is some
memory manager running on the DSP that is failing)
Testing some other sizes I find that 800x480, 854x480, 864x480,
800x512 and 854x480 play, but
960x480, 800x528, 800x544, 880x480 do not.
Is it possible that the TI binaries will always return EMEMORY if too
high a resolution is requested?
Any advice much appreciated!
On Wed, Nov 24, 2010 at 12:38 AM, Sapiens, Rene <rene.sapiens@ti.com> wrote:
> Hi James,
>
>> The second error log is the stack trace when the watchdog timer calls
>> SYNC_EnterCS.
>
> Actually is not the WDT calling the function to get into the critical
> section, it is the WDT being disabled when the DSP is going to OFF
> state. This should fine.
>
>> The stack trace is shown below.
>>
>
> 1) Is this trace printed after the 'if (in_interrupt())' statement?
> 2) Can you check under drivers/dsp/bridge/ to see where is or under
> which context io_dispatchpm called?
>
> To get the assertions failing you should be in the context of an
> interrupt, the code base that i have is not that way for that reason i
> ask for your io_dispatchpm function.
>
>> [<c0412864>] (dump_stack+0x0/0x14) from [<c0278c18>]
>> (SYNC_EnterCS+0x48/0xe4)
>> [<c0278bd0>] (SYNC_EnterCS+0x0/0xe4) from [<c0279e24>]
>> (REG_GetValue+0x60/0xa0)
>> r5:c05ba390 r4:c04f092c
>> [<c0279dc4>] (REG_GetValue+0x0/0xa0) from [<c027987c>]
>> (CFG_GetObject+0x60/0xe0)
>> r7:cfa87a80 r6:00000002 r5:cf98fe94 r4:00000002
>> [<c027981c>] (CFG_GetObject+0x0/0xe0) from [<c02913c0>]
>> (DRV_GetFirstDevObject+0
>> x1c/0x4c)
>> r5:c05ba3c0 r4:00000000
>> [<c02913a4>] (DRV_GetFirstDevObject+0x0/0x4c) from [<c02858e4>]
>> (DEV_GetFirst+0x
>> 10/0x44)
>> [<c02858d4>] (DEV_GetFirst+0x0/0x44) from [<c027d430>]
>> (dsp_wdt_enable+0x44/0xe0
>> )
>> r5:c05ba3c0 r4:00000000
>> [<c027d3ec>] (dsp_wdt_enable+0x0/0xe0) from [<c02820fc>]
>> (handle_hibernation_fro
>> mDSP+0x148/0x1ec)
>> r5:cfaa0000 r4:00008000
>> [<c0281fb4>] (handle_hibernation_fromDSP+0x0/0x1ec) from [<c02810c0>]
>> (WMD_DEV_C
>> trl+0xfc/0x130)
>> r7:cf98e000 r6:cf98ff34 r5:cc5f6a88 r4:cfb89e00
>> [<c0280fc4>] (WMD_DEV_Ctrl+0x0/0x130) from [<c027dc24>]
>> (io_mbox_msg+0x70/0x1d8)
>> r7:cf98e000 r6:c05496c4 r5:cc5f6a88 r4:cfb89e00
>> [<c027dbb4>] (io_mbox_msg+0x0/0x1d8) from [<c0059308>]
>> (mbox_rx_work+0xf4/0x100)
>> r5:cc5f6a88 r4:0000200a
>> [<c0059214>] (mbox_rx_work+0x0/0x100) from [<c007ebb0>]
>> (run_workqueue+0xc8/0x18
>> 4)
>> [<c007eae8>] (run_workqueue+0x0/0x184) from [<c007f2dc>]
>> (worker_thread+0x104/0x
>> 118)
>> r9:00000000 r8:00000000 r7:cf811040 r6:cf94e140 r5:cf94e148
>> r4:cf98e000
>> [<c007f1d8>] (worker_thread+0x0/0x118) from [<c0082cb4>]
>> (kthread+0x54/0x80)
>> r7:00000000 r6:00000000 r5:c007f1d8 r4:cf94e140
>> [<c0082c60>] (kthread+0x0/0x80) from [<c0070b1c>] (do_exit+0x0/0x7bc)
>> r5:00000000 r4:00000000
>> drivers/dsp/bridge/services/sync.c, line 358: Assertion (0) failed.
>
> Regards,
> Rene Sapiens
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: DSP Bridge video decode of above VGA videos
2010-11-24 16:01 ` James Adams
@ 2010-11-24 19:29 ` Uribe de Leon, Armando
[not found] ` <E0D41E29EB0DAC4E9F3FF173962E9E9402EF6AD46F@dbde02.ent.ti.com>
0 siblings, 1 reply; 13+ messages in thread
From: Uribe de Leon, Armando @ 2010-11-24 19:29 UTC (permalink / raw)
To: James Adams, Rijo Thomas, Guruprasad Pawse
Cc: Sapiens, Rene, Kanigeri, Hari, linux-omap
Hi James,
It seems that this question is more intended to the TI SN team, anyway
I have taken a look at the mail chain and from your conclusions below
seems that you are facing memory allocation issues. I think it is
probably you are getting a SYS_EALLOC coming in from the call to
UTILS_allocatePrivateBuffer() where the buffer is being allocated.
Some nodes may need to allocate very large buffers, possibly larger
than any heap size configured in the base image. In order to support
these nodes, external memory requirements can be configured for up to
16 profiles of a node. This will allow the ARM OS to allocate a
private heap for a node.You can check your SN .tcf file to look at the
configured profiles, for example if you are using the h264 TI SN the
file is h264vdec_sn.tcf. You will see the 16 profiles listed there.
And you must use the profile that fits your needs.
TI H264 has two decoding modes: FRAME and STREAMING. I recall that for
FRAME mode the max resolution allowed is VGA: profile 3; although for
STREAMING there are 7 profiles, but I am not familiar with those
profiles and how STREAMING mode works.
I am looping SN folks, they might help more accurately, also I am
thinking that we can remove the linux-omap@vger.kernel.org list in
the subsequent mails.
Rijo, Guruprasad,
Do you know if it is possible decode H264 videos with resolution above 640x480?
I am copying the original James query:
We are running Android on a custom Gumstix Overo Water platform. We
have ported the 25.12 Zoom2 release to do this.
It is almost working except that when trying to decode H264 videos
with resolution above 640x480 (either horizontally or vertically, e.g.
640*544) the DSP module appears to crash. Decoding anything at VGA or
below is working fine.
DSP bridge is configured with 0x600000 memory (but larger doesn't seem
to help). Is anyone aware of other configuration options that we
should be checking (e.g. in DSP bridge, OMAP video drivers, or
android?) that might cause large video decodes to fail?
Thanks and regards,
Armando.
On Wed, Nov 24, 2010 at 10:01 AM, James Adams <james.r.adams@gmail.com> wrote:
> Many thanks for the help Rene, it makes a huge difference being told
> whereabouts in the gigabytes of source to start looking!
>
> You are quite correct in that the error comes from NODE_Create.
> Node_Create calls DISP_NodeCreate
> DISP_NodeCreate calls SendMessage
> SendMessage succeeds, but after CHNL_IsIOComplete reads back a status
> code from chnlIOC.pBuf which has the error code in it.
>
> My understanding is that this means that the dsp bridge kernel has sent
> a message across to the TI DSP, but the DSP is reporting out of memory.
>
> Unfortunately, I don't know where to go from here, any tips?
>
> I've looked at the DSP bridge documents but I still don't really have a
> handle on the memory allocation.
> My understanding is that:
> 1) The DSP and ARM share access to the same memory chips
> 2) The DSP bridge allocates shm_size memory for page tables and
> communications
> 3) The DSP bridge assigns phys_mempool_size memory at a fixed address
> for the DSP to store its own data inside
> I don't understand where the streaming data gets allocated.
>
> I've tried increasing phys_mempool_size but it behaves the same.
>
> I've added printk to the allocation routines in mem.c, but none of these
> are failing. (Although I suspect they are irrelevant and it is some
> memory manager running on the DSP that is failing)
>
> Testing some other sizes I find that 800x480, 854x480, 864x480,
> 800x512 and 854x480 play, but
> 960x480, 800x528, 800x544, 880x480 do not.
>
> Is it possible that the TI binaries will always return EMEMORY if too
> high a resolution is requested?
>
> Any advice much appreciated!
>
>
>
>
> On Wed, Nov 24, 2010 at 12:38 AM, Sapiens, Rene <rene.sapiens@ti.com> wrote:
>> Hi James,
>>
>>> The second error log is the stack trace when the watchdog timer calls
>>> SYNC_EnterCS.
>>
>> Actually is not the WDT calling the function to get into the critical
>> section, it is the WDT being disabled when the DSP is going to OFF
>> state. This should fine.
>>
>>> The stack trace is shown below.
>>>
>>
>> 1) Is this trace printed after the 'if (in_interrupt())' statement?
>> 2) Can you check under drivers/dsp/bridge/ to see where is or under
>> which context io_dispatchpm called?
>>
>> To get the assertions failing you should be in the context of an
>> interrupt, the code base that i have is not that way for that reason i
>> ask for your io_dispatchpm function.
>>
>>> [<c0412864>] (dump_stack+0x0/0x14) from [<c0278c18>]
>>> (SYNC_EnterCS+0x48/0xe4)
>>> [<c0278bd0>] (SYNC_EnterCS+0x0/0xe4) from [<c0279e24>]
>>> (REG_GetValue+0x60/0xa0)
>>> r5:c05ba390 r4:c04f092c
>>> [<c0279dc4>] (REG_GetValue+0x0/0xa0) from [<c027987c>]
>>> (CFG_GetObject+0x60/0xe0)
>>> r7:cfa87a80 r6:00000002 r5:cf98fe94 r4:00000002
>>> [<c027981c>] (CFG_GetObject+0x0/0xe0) from [<c02913c0>]
>>> (DRV_GetFirstDevObject+0
>>> x1c/0x4c)
>>> r5:c05ba3c0 r4:00000000
>>> [<c02913a4>] (DRV_GetFirstDevObject+0x0/0x4c) from [<c02858e4>]
>>> (DEV_GetFirst+0x
>>> 10/0x44)
>>> [<c02858d4>] (DEV_GetFirst+0x0/0x44) from [<c027d430>]
>>> (dsp_wdt_enable+0x44/0xe0
>>> )
>>> r5:c05ba3c0 r4:00000000
>>> [<c027d3ec>] (dsp_wdt_enable+0x0/0xe0) from [<c02820fc>]
>>> (handle_hibernation_fro
>>> mDSP+0x148/0x1ec)
>>> r5:cfaa0000 r4:00008000
>>> [<c0281fb4>] (handle_hibernation_fromDSP+0x0/0x1ec) from [<c02810c0>]
>>> (WMD_DEV_C
>>> trl+0xfc/0x130)
>>> r7:cf98e000 r6:cf98ff34 r5:cc5f6a88 r4:cfb89e00
>>> [<c0280fc4>] (WMD_DEV_Ctrl+0x0/0x130) from [<c027dc24>]
>>> (io_mbox_msg+0x70/0x1d8)
>>> r7:cf98e000 r6:c05496c4 r5:cc5f6a88 r4:cfb89e00
>>> [<c027dbb4>] (io_mbox_msg+0x0/0x1d8) from [<c0059308>]
>>> (mbox_rx_work+0xf4/0x100)
>>> r5:cc5f6a88 r4:0000200a
>>> [<c0059214>] (mbox_rx_work+0x0/0x100) from [<c007ebb0>]
>>> (run_workqueue+0xc8/0x18
>>> 4)
>>> [<c007eae8>] (run_workqueue+0x0/0x184) from [<c007f2dc>]
>>> (worker_thread+0x104/0x
>>> 118)
>>> r9:00000000 r8:00000000 r7:cf811040 r6:cf94e140 r5:cf94e148
>>> r4:cf98e000
>>> [<c007f1d8>] (worker_thread+0x0/0x118) from [<c0082cb4>]
>>> (kthread+0x54/0x80)
>>> r7:00000000 r6:00000000 r5:c007f1d8 r4:cf94e140
>>> [<c0082c60>] (kthread+0x0/0x80) from [<c0070b1c>] (do_exit+0x0/0x7bc)
>>> r5:00000000 r4:00000000
>>> drivers/dsp/bridge/services/sync.c, line 358: Assertion (0) failed.
>>
>> Regards,
>> Rene Sapiens
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: DSP Bridge video decode of above VGA videos
[not found] ` <E0D41E29EB0DAC4E9F3FF173962E9E9402EF6AD46F@dbde02.ent.ti.com>
@ 2010-11-25 10:52 ` James Adams
0 siblings, 0 replies; 13+ messages in thread
From: James Adams @ 2010-11-25 10:52 UTC (permalink / raw)
To: Pawse, Guruprasad
Cc: Uribe de Leon, Armando, Thomas, Rijo, Sapiens, Rene, Kanigeri,
Hari, linux-omap, Venkatasubbarao, Pradeep
Thanks Guru, and everyone for all your help!
I am afraid that I am unable to find the h264vdec_sn.tcf file, perhaps
it is not part of the publicly released files?
However, Guru has very clearly explained the size limitations so that
answers my original question, many thanks.
Our application needs to decode higher resolution videos (960x544) -
but at reduced framerate. Presumably given the aforementioned
limitations there is no way to make this work?
Thanks again to all for all the help,
James
On Thu, Nov 25, 2010 at 5:11 AM, Pawse, Guruprasad <guruprasadvp@ti.com> wrote:
> Hi Armando,
>
> Yes it is possible to decode H.264 videos above VGA (640x480).
>
> Below are the details of the maximum resolution supported and their
> restrictions.
>
> - Maximum resolution supported is WVGA (864x480) either portrait or
> landscape.
>
> - Width cannot be greater than 864
>
> - Number of MB’s should not be greater than 1620.(i.e. Width x Height
> should be <= 414720)
>
>
>
>> Testing some other sizes I find that 800x480, 854x480, 864x480,
>
>> 800x512 and 854x480 play, but
>
>> 960x480, 800x528, 800x544, 880x480 do not.
>
> The nonworking resolutions from the above list have either width>864 or
> number of MB’s >1620 and hence unsupported.
>
>
>
> Regards,
>
> Guru
>
>
>
> -----Original Message-----
> From: Uribe de Leon, Armando [mailto:x0095078@ti.com]
> Sent: Thursday, November 25, 2010 12:59 AM
> To: James Adams; Thomas, Rijo; Pawse, Guruprasad
> Cc: Sapiens, Rene; Kanigeri, Hari; linux-omap@vger.kernel.org
> Subject: Re: DSP Bridge video decode of above VGA videos
>
>
>
> Hi James,
>
>
>
> It seems that this question is more intended to the TI SN team, anyway
>
> I have taken a look at the mail chain and from your conclusions below
>
> seems that you are facing memory allocation issues. I think it is
>
> probably you are getting a SYS_EALLOC coming in from the call to
>
> UTILS_allocatePrivateBuffer() where the buffer is being allocated.
>
>
>
> Some nodes may need to allocate very large buffers, possibly larger
>
> than any heap size configured in the base image. In order to support
>
> these nodes, external memory requirements can be configured for up to
>
> 16 profiles of a node. This will allow the ARM OS to allocate a
>
> private heap for a node.You can check your SN .tcf file to look at the
>
> configured profiles, for example if you are using the h264 TI SN the
>
> file is h264vdec_sn.tcf. You will see the 16 profiles listed there.
>
> And you must use the profile that fits your needs.
>
>
>
> TI H264 has two decoding modes: FRAME and STREAMING. I recall that for
>
> FRAME mode the max resolution allowed is VGA: profile 3; although for
>
> STREAMING there are 7 profiles, but I am not familiar with those
>
> profiles and how STREAMING mode works.
>
>
>
> I am looping SN folks, they might help more accurately, also I am
>
> thinking that we can remove the linux-omap@vger.kernel.org list in
>
> the subsequent mails.
>
>
>
> Rijo, Guruprasad,
>
>
>
> Do you know if it is possible decode H264 videos with resolution above
> 640x480?
>
>
>
> I am copying the original James query:
>
>
>
> We are running Android on a custom Gumstix Overo Water platform. We
>
> have ported the 25.12 Zoom2 release to do this.
>
>
>
> It is almost working except that when trying to decode H264 videos
>
> with resolution above 640x480 (either horizontally or vertically, e.g.
>
> 640*544) the DSP module appears to crash. Decoding anything at VGA or
>
> below is working fine.
>
>
>
> DSP bridge is configured with 0x600000 memory (but larger doesn't seem
>
> to help). Is anyone aware of other configuration options that we
>
> should be checking (e.g. in DSP bridge, OMAP video drivers, or
>
> android?) that might cause large video decodes to fail?
>
>
>
>
>
> Thanks and regards,
>
> Armando.
>
>
>
>
>
>
>
> On Wed, Nov 24, 2010 at 10:01 AM, James Adams <james.r.adams@gmail.com>
> wrote:
>
>> Many thanks for the help Rene, it makes a huge difference being told
>
>> whereabouts in the gigabytes of source to start looking!
>
>>
>
>> You are quite correct in that the error comes from NODE_Create.
>
>> Node_Create calls DISP_NodeCreate
>
>> DISP_NodeCreate calls SendMessage
>
>> SendMessage succeeds, but after CHNL_IsIOComplete reads back a status
>
>> code from chnlIOC.pBuf which has the error code in it.
>
>>
>
>> My understanding is that this means that the dsp bridge kernel has sent
>
>> a message across to the TI DSP, but the DSP is reporting out of memory.
>
>>
>
>> Unfortunately, I don't know where to go from here, any tips?
>
>>
>
>> I've looked at the DSP bridge documents but I still don't really have a
>
>> handle on the memory allocation.
>
>> My understanding is that:
>
>> 1) The DSP and ARM share access to the same memory chips
>
>> 2) The DSP bridge allocates shm_size memory for page tables and
>
>> communications
>
>> 3) The DSP bridge assigns phys_mempool_size memory at a fixed address
>
>> for the DSP to store its own data inside
>
>> I don't understand where the streaming data gets allocated.
>
>>
>
>> I've tried increasing phys_mempool_size but it behaves the same.
>
>>
>
>> I've added printk to the allocation routines in mem.c, but none of these
>
>> are failing. (Although I suspect they are irrelevant and it is some
>
>> memory manager running on the DSP that is failing)
>
>>
>
>> Testing some other sizes I find that 800x480, 854x480, 864x480,
>
>> 800x512 and 854x480 play, but
>
>> 960x480, 800x528, 800x544, 880x480 do not.
>
>>
>
>> Is it possible that the TI binaries will always return EMEMORY if too
>
>> high a resolution is requested?
>
>>
>
>> Any advice much appreciated!
>
>>
>
>>
>
>>
>
>>
>
>> On Wed, Nov 24, 2010 at 12:38 AM, Sapiens, Rene <rene.sapiens@ti.com>
>> wrote:
>
>>> Hi James,
>
>>>
>
>>>> The second error log is the stack trace when the watchdog timer calls
>
>>>> SYNC_EnterCS.
>
>>>
>
>>> Actually is not the WDT calling the function to get into the critical
>
>>> section, it is the WDT being disabled when the DSP is going to OFF
>
>>> state. This should fine.
>
>>>
>
>>>> The stack trace is shown below.
>
>>>>
>
>>>
>
>>> 1) Is this trace printed after the 'if (in_interrupt())' statement?
>
>>> 2) Can you check under drivers/dsp/bridge/ to see where is or under
>
>>> which context io_dispatchpm called?
>
>>>
>
>>> To get the assertions failing you should be in the context of an
>
>>> interrupt, the code base that i have is not that way for that reason i
>
>>> ask for your io_dispatchpm function.
>
>>>
>
>>>> [<c0412864>] (dump_stack+0x0/0x14) from [<c0278c18>]
>
>>>> (SYNC_EnterCS+0x48/0xe4)
>
>>>> [<c0278bd0>] (SYNC_EnterCS+0x0/0xe4) from [<c0279e24>]
>
>>>> (REG_GetValue+0x60/0xa0)
>
>>>> r5:c05ba390 r4:c04f092c
>
>>>> [<c0279dc4>] (REG_GetValue+0x0/0xa0) from [<c027987c>]
>
>>>> (CFG_GetObject+0x60/0xe0)
>
>>>> r7:cfa87a80 r6:00000002 r5:cf98fe94 r4:00000002
>
>>>> [<c027981c>] (CFG_GetObject+0x0/0xe0) from [<c02913c0>]
>
>>>> (DRV_GetFirstDevObject+0
>
>>>> x1c/0x4c)
>
>>>> r5:c05ba3c0 r4:00000000
>
>>>> [<c02913a4>] (DRV_GetFirstDevObject+0x0/0x4c) from [<c02858e4>]
>
>>>> (DEV_GetFirst+0x
>
>>>> 10/0x44)
>
>>>> [<c02858d4>] (DEV_GetFirst+0x0/0x44) from [<c027d430>]
>
>>>> (dsp_wdt_enable+0x44/0xe0
>
>>>> )
>
>>>> r5:c05ba3c0 r4:00000000
>
>>>> [<c027d3ec>] (dsp_wdt_enable+0x0/0xe0) from [<c02820fc>]
>
>>>> (handle_hibernation_fro
>
>>>> mDSP+0x148/0x1ec)
>
>>>> r5:cfaa0000 r4:00008000
>
>>>> [<c0281fb4>] (handle_hibernation_fromDSP+0x0/0x1ec) from [<c02810c0>]
>
>>>> (WMD_DEV_C
>
>>>> trl+0xfc/0x130)
>
>>>> r7:cf98e000 r6:cf98ff34 r5:cc5f6a88 r4:cfb89e00
>
>>>> [<c0280fc4>] (WMD_DEV_Ctrl+0x0/0x130) from [<c027dc24>]
>
>>>> (io_mbox_msg+0x70/0x1d8)
>
>>>> r7:cf98e000 r6:c05496c4 r5:cc5f6a88 r4:cfb89e00
>
>>>> [<c027dbb4>] (io_mbox_msg+0x0/0x1d8) from [<c0059308>]
>
>>>> (mbox_rx_work+0xf4/0x100)
>
>>>> r5:cc5f6a88 r4:0000200a
>
>>>> [<c0059214>] (mbox_rx_work+0x0/0x100) from [<c007ebb0>]
>
>>>> (run_workqueue+0xc8/0x18
>
>>>> 4)
>
>>>> [<c007eae8>] (run_workqueue+0x0/0x184) from [<c007f2dc>]
>
>>>> (worker_thread+0x104/0x
>
>>>> 118)
>
>>>> r9:00000000 r8:00000000 r7:cf811040 r6:cf94e140 r5:cf94e148
>
>>>> r4:cf98e000
>
>>>> [<c007f1d8>] (worker_thread+0x0/0x118) from [<c0082cb4>]
>
>>>> (kthread+0x54/0x80)
>
>>>> r7:00000000 r6:00000000 r5:c007f1d8 r4:cf94e140
>
>>>> [<c0082c60>] (kthread+0x0/0x80) from [<c0070b1c>] (do_exit+0x0/0x7bc)
>
>>>> r5:00000000 r4:00000000
>
>>>> drivers/dsp/bridge/services/sync.c, line 358: Assertion (0) failed.
>
>>>
>
>>> Regards,
>
>>> Rene Sapiens
>
>>>
>
>> --
>
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>
>> the body of a message to majordomo@vger.kernel.org
>
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2010-11-25 10:52 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-11-22 13:14 DSP Bridge video decode of above VGA videos James Adams
2010-11-22 13:23 ` Kanigeri, Hari
2010-11-22 15:26 ` James Adams
2010-11-22 16:56 ` Sapiens, Rene
2010-11-22 17:12 ` James Adams
2010-11-22 21:42 ` Sapiens, Rene
2010-11-23 9:30 ` James Adams
2010-11-23 14:34 ` James Adams
2010-11-24 0:17 ` Sapiens, Rene
2010-11-24 0:38 ` Sapiens, Rene
2010-11-24 16:01 ` James Adams
2010-11-24 19:29 ` Uribe de Leon, Armando
[not found] ` <E0D41E29EB0DAC4E9F3FF173962E9E9402EF6AD46F@dbde02.ent.ti.com>
2010-11-25 10:52 ` James Adams
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.