Forums » Software Development »
remaining DSPLINK_DPC_x processes after running the HelloWorldDSP example
Added by Stéphane Peter almost 13 years ago
Hi,
When I execute the DSP HelloWorld example provided in topic http://support.criticallink.com/redmine/boards/10/topics/543, a process called DSPLINK_DPC_x remains active (I observe the same behavior with the own compiled code):
cat /proc/1224/status Name: DSPLINK_DPC_3 State: S (sleeping) Tgid: 1224 Pid: 1224 PPid: 2 TracerPid: 0 Uid: 0 0 0 0 Gid: 0 0 0 0 FDSize: 32 Groups: Threads: 1 SigQ: 0/723 SigPnd: 0000000000000000 ShdPnd: 0000000000000000 SigBlk: 0000000000000000 SigIgn: ffffffffffffffff SigCgt: 0000000000000000 CapInh: 0000000000000000 CapPrm: ffffffffffffffff CapEff: fffffffffffffeff CapBnd: ffffffffffffffff Cpus_allowed: 1 Cpus_allowed_list: 0 voluntary_ctxt_switches: 9 nonvoluntary_ctxt_switches: 0
Unloading (rmmod) the dsplinkk module terminates the sleeping process.
Is there a bug in the dsplinkk.ko (taken from MDK_2011-12-05) or is the clean up functionality in the HelloWorld example incomplete?
best regards
Stéphane
Replies (1)
RE: remaining DSPLINK_DPC_x processes after running the HelloWorldDSP example - Added by Michael Williamson almost 13 years ago
Hello Stéphane,
Obligatory disclaimer: The DSPLINK code is really TI's, we just include it with our BSP because our code/examples sit on top of it, it is GPL'd (or LGPL'd, I don't remember off hand). That latest revision of the DSPLINK (1.65.00.03) is (I believe) unmodified from TI's revision with the exception of moving the start of the DSPLINK memory regions up to 96 MBytes instead the lower offsets.
The thread you are looking at appears to be the ARM side interrupt handler for the IPS module. I say "appears" as I am crawling through the DSPLINK code at the moment and haven't had to look at this level of detail before today. This module handles interrupts from the DSP to the ARM for message notifications. The thread sits idle until an interrupt is taken (from the DSP) and then has some vectoring logic to dispatch registered callbacks on the ARM. If the DSP is shut down, the IRQ shouldn't fire and the thread should stay IDLE.
I'm not sure when the IPS module and it's ISR handler gets installed. I suspect that it might happen after the dsplink.ko module is loaded, not when the DSP application is loaded, which would mean the behavior you are seeing is correct (the ISR is installed / removed during module initialization and exit, not DSP).
I took a quick look at the HelloWorld example, and I don't think we are missing any DSPLINK cleanup calls, but I could be wrong. I don't think this is a problem as we are able to load and unload DSP applications repeatedly here and there does not appear to be a problem with the IPS communication layer.
This might be worth a post to the TI E2E pages. If I get a chance to investigate it further I'll do that and update this thread. Thanks for the head's up.
-Mike
