DSPLink on Linux Kernel 3.0

Chris,

This will be fixed in DSPLink 1.65.01, due to be released in a few weeks.  The changes to drv_pmgr.c are the following, in case you want to fix your own version:

Thanks Janet!

I applied this patch, but I get an error when I call PROC_attach():

PROC_setup() OK ------------[ cut here ]------------

[0x8000]

WARNING: at arch/arm/mm/ioremap.c:207 __arm_ioremap_pfn_caller+0x158/0x168()

Modules linked in: dsplinkk

[<c0031420>] (unwind_backtrace+0x0/0xf4) from [<c004151c>] (warn_slowpath_common+0x4c/0x64)

[<c004151c>] (warn_slowpath_common+0x4c/0x64) from [<c0041550>] (warn_slowpath_null+0x1c/0x24)

[<c0041550>] (warn_slowpath_null+0x1c/0x24) from [<c00332dc>] (__arm_ioremap_pfn_caller+0x158/0x168)

[<c00332dc>] (__arm_ioremap_pfn_caller+0x158/0x168) from [<c003335c>] (__arm_ioremap_caller+0x58/0x60)

[<c003335c>] (__arm_ioremap_caller+0x58/0x60) from [<bf00ea34>] (MEM_Map+0x40/0x5c [dsplinkk])

[<bf00ea34>] (MEM_Map+0x40/0x5c [dsplinkk]) from [<bf0008f8>] (DA8XXGEM_exit+0x194/0x258 [dsplinkk])

[<bf0008f8>] (DA8XXGEM_exit+0x194/0x258 [dsplinkk]) from [<bf0000b8>] (DSP_init+0x24/0x2c [dsplinkk])

[<bf0000b8>] (DSP_init+0x24/0x2c [dsplinkk]) from [<bf00163c>] (LDRV_PROC_init+0x288/0x340 [dsplinkk])

[<bf00163c>] (LDRV_PROC_init+0x288/0x340 [dsplinkk]) from [<bf012660>] (PMGR_PROC_attach+0x214/0x378 [dsplinkk])

[<bf012660>] (PMGR_PROC_attach+0x214/0x378 [dsplinkk]) from [<bf01352c>] (DRV_Ioctl+0x718/0x920 [dsplinkk])

[<bf01352c>] (DRV_Ioctl+0x718/0x920 [dsplinkk]) from [<c00ba918>] (do_vfs_ioctl+0x7c/0x5fc)

[<c00ba918>] (do_vfs_ioctl+0x7c/0x5fc) from [<c00baed0>] (sys_ioctl+0x38/0x60)

[<c00baed0>] (sys_ioctl+0x38/0x60) from [<c002cfa0>] (ret_fast_syscall+0x0/0x2c)

---[ end trace 8b27c5b96a8f7e38 ]---

 DSP_init status [0x8000800c]

PROC_attach() FAILED [0x8000800c]

Chris,

The error code returned by PROC_attach looks like DSP_EMEMORY, according to dsplink/gpp/inc/usr/errbase.h.  Maybe you could enable DSPLink trace to get more information. To enable trace in link, you need to:

1. Re-run the perl script with --trace=1.

2.  Edit the file dsplink/gpp/src/pmgr/Linux/2.6.18/drv_pmgr.c, and uncomment these lines:

        /* TRC_ENABLE (ID_PMGR_PROC)       ; */

        /* TRC_ENABLE (ID_LDRV_PROC)       ; */

        /* TRC_SET_SEVERITY (TRC_ENTER) ; */

3.  Rebuild and insmod the dsplinkk.ko

The changes I gave before were only to support the ioctl changes.  It looks like the failure occurs during the mapping of the DSP memory.  If the trace does not give enough information, you may want to uncomment some more lines from that file, such as:

        /* TRC_ENABLE (ID_ARCH_DSP)        ; */
or

        /* TRC_ENABLE (ID_ARCH_DSP_INTF)   ; */

You can look in the source file where you would like to see trace output for a line such as

#define  COMPONENT_ID       ID_ARCH_DSP_INTF

and then uncomment the corresponding TRC_ENABLE() line in drv_pmgr.c.

Hopefully the trace will indicate the cause of the problem.

Best regards,

    Janet

Hi Janet,

We are using DSPLink with kernel 3.1, and we are having some problems.

When is DSPLink 1.65.01 going to be released? Is there any way to try the new version before it is released?

Regards,

Milos

Milos,

Have you tried applying this patch to your DSPLink?  I did so manually, and it was able to compile, but it didn't quite solve the problem, as you can see by my prior post.  I'd be curious to know what problems you're having.   We've punted on the 3.x series kernels for now, but I imagine we'll want to use this kernel at some point in the future.

Thanks,
Chris 

Chris,

I also applied the patch manually to DSPLink 1.65.00.03. It sort of works - I'm able to encode and decode video using GStreamer, but there are some problems. For example, if I test the decoder using the following command:

gst-launch -v filesrc location=davincieffect.264 ! typefind ! h264parse ! TIViddec2 padAllocOutbufs=TRUE ! queue ! fakesink

It works fine - fakesink outputs timestamps, but when I terminate the process with Ctrl+C, I get this trace:

Unable to handle kernel paging request at virtual address d3634008
pgd = cf3c0000
[d3634008] *pgd=8b221811, *pte=00000000, *ppte=00000000
Internal error: Oops: 807 [#1]
Modules linked in: sdmak lpm_omap3530 dsplinkk cmemk g_ether
CPU: 0 Not tainted (3.1.1 #87)
PC is at remove_wait_queue+0x24/0x40
LR is at SYNC_WaitSEM+0x1a4/0x24c [dsplinkk]
pc : [<c004afa8>] lr : [<bf02cbc4>] psr: 00000093
sp : cf2bbe5c ip : d3634008 fp : b435e24c
r10: 80040800 r9 : ffffffff r8 : cf2bbe64
r7 : d3634008 r6 : 00000001 r5 : cf2ba000 r4 : 00000013
r3 : 00100100 r2 : 00200200 r1 : cf2bbe64 r0 : d3634008
Flags: nzcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user
Control: 10c5387d Table: 8f3c0019 DAC: 00000015
Process filesrc0:src (pid: 686, stack limit = 0xcf2ba2f0)
Stack: (0xcf2bbe5c to 0xcf2bc000)
be40: fffffe00
be60: d0904880 00000001 cf0e6f40 c002fa10 d3634008 d3634008 00008000 00000000
be80: 00008000 bf033be0 cf2bbefc d3630000 80040800 bf022634 c018e03a b435e264
bea0: 00000008 b435e264 cf2bbee4 cf2ba000 00000000 bf030018 00000000 c048e4f0
bec0: 00000003 ca2d9fc4 0000000d c0058f3c 00000000 00000025 c048fbf4 c9b75dae
bee0: 0000000d 00008000 b2e08000 00010001 ffffffff 00000000 b2a84000 00000000
bf00: 00000000 cf3a77c0 00000008 b435e264 cf3a77c0 cf2ba000 00000000 c00a28ac
bf20: cf3470c0 00000840 00118000 cf3470c0 00000844 cf2bbf30 00000000 00118840
bf40: 04000001 00000001 00000000 00000081 00000001 00118844 00197a60 c005cedc
bf60: 00118840 00000000 b435e264 c018e03a 00000008 cf3a77c0 cf2ba000 00000000
bf80: b435e24c c00a2e00 00118840 00000001 b6a548b0 ffffffff b435e304 00000036
bfa0: c000e144 c000dfc0 b6a548b0 ffffffff 00000008 c018e03a b435e264 00000008
bfc0: b6a548b0 ffffffff b435e304 00000036 00010001 00002504 b6a55784 b435e24c
bfe0: b6a56db4 b435e138 b6a17cf0 b6c7baec 80000010 00000008 00000000 00000000
[<c004afa8>] (remove_wait_queue+0x24/0x40) from [<d0904880>] (0xd0904880)
Code: e591000c e3403010 e3002200 e3402020 (e58c0000) 
---[ end trace a66a2320342174e3 ]---

It seems to me thatDSPLink is still coping with the absence of BKL...

Regards,

Milos

Hi Milos,

Not sure if this helps, but in case you'd like more info on signal handling in DSPLINK:

http://processors.wiki.ti.com/index.php/DSPLink_FAQs#Why_does_signal_handler_registered_in_my_application_stop_working_when_I_integrate_DSPLink_.3F

More details on why a crash dump may be seen can also be found in the "DSPLink and signals" section in the release notes that are supplied in the 'doc' folder under the dsplink directory.

Best regards,

Vincent

To Christopher et al.,

NOTE: Depending on what kernel you're using you might get a build error at this step saying: Building kernel side code using kbuild $(DSPLINK)/gpp/src/../../gpp/src/pmgr/Linux/2.6.18/drv_pmgr.c:498:5: error: unknown field 'ioctl' specified in initializer $(DSPLINK)/gpp/src/../../gpp/src/pmgr/Linux/2.6.18/drv_pmgr.c:498:5: warning: initialization from incompatible pointer type make[2]: *** [$(DSPLINK)/gpp/src/../../gpp/src/pmgr/Linux/2.6.18/drv_pmgr.o] Error 1 make[1]: *** [_module$(DSPLINK)/gpp/src] Error 2 make: *** [debug] Error 2

This error only affects the recompilation of the DSPLink driver which is not necessary if you don't plan on modifying the underlying architecture of DSPLink ... but for completeness sake this is how you fix this issue [1]. There is a patch in your OE recipe directory to solve this issue in:

$(OE_HOME)/openembedded/recipes/ti/ti-dsplink/dsplink-BKL-fix.patch

and the file with the problem is in:

$(DSPLINK)/gpp/src/pmgr/Linux/2.6.18/drv_pmgr.c

you can either apply the patch to the file or just copy over the patched file from your OE temp directory as:

"patch -b $(DSPLINK)/gpp/src/pmgr/Linux/2.6.18/drv_pmgr.c  $(OE_HOME)/openembedded/recipes/ti/ti-dsplink/dsplink-BKL-fix.patch"

After you finish compiling the code here, you've successfully recompiled the DSPLink driver. The next step is to recompile the DSPLink GPP side examples ...

cd $(DSPLINK)/gpp/src/samples

make -s clean

make -s debug

make -s release

then

cd $(DSPLINK)/gpp/src

make -s clean

make -s debug

make -s release

Where Are My Executables and Newly Compiled Driver?

* GPP Executbales

>$(DSPLINK)/gpp/BUILD/EXPORT/DEBUG

>$(DSPLINK)/gpp/BUILD/EXPORT/RELEASE

* DSPLink Driver

>$(DSPLINK)/gpp/export/BIN/Linux/OMAP3530/DEBUG

>$(DSPLINK)/gpp/export/BIN/Linux/OMAP3530/RELEASE

* DSP Executables

>$(DSPLINK)/dsp/BUILD/OMAP3530_0/EXPORT/DEBUG

>$(DSPLINK)/dsp/BUILD/OMAP3530_0/EXPORT/RELEASE

Refereces [1] http://e2e.ti.com/support/embedded/f/354/p/70806/258712.aspx

Hope this help,

Gutembert.

Milos,

I'm also in the same situation.

I'm running DSPLink v1.65.02.09 on Kernel v3.0 (DM3730) but this kernel paging request bug still popup.

There are instances (relatively small chance) where Ctrl+C doesn't trigger it but mostly it does.

Is there a solution to this?

Many thanks in adv.

Regards,

James Ang