• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 562 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DSPLINK CHNL problem and questions.

Misha
Intellectual 625 points
Other Parts Discussed in Thread: OMAP-L137

On a OMAP-L137 target, running Linux 2.6.37 on ARM core and DSPBIOS 5.41.3.17 on DSP core,
an acquisition system is running, supported by DSPLINK CHNL module.
DSPLINK is 1.65 version.

The DSP application  is running a thread issuing SIO_issue/reclaim pairs for an OUTPUT channel.
The output buffer issued is mapped @ 0xC1F30880, size is 0x4FFC.
The ARM application is running a thread issuing CHNL_issue/reclaim pairs for an INPUT channel.  
The input buffer reclaimed is mapped @ 0x40126880, size is 0x4FFC.
When the input buffer is available a second thread sends it to a client application running on a PC though TCP/IP.

Question 1.
The buffers size is not an exact multiple of cache line size: is this a potential error ?

Question 2.
The ARM thread actually executes more CNL_reclaim calls if the previous call return code is DSP_ETIMEOUT:
is this allowed or a CHNL_issue must be interlaced for every CNL_reclaim call ?
Please note that DSPLINK documentation does not report tis as an exit code, but only
*  @ret    DSP_SOK
 *              Operation successfully completed.
 *          DSP_EFAIL
 *              General failure.
 *          DSP_EMEMORY
 *              Operation failed due to memory error.
 *          DSP_EINVALIDARG
 *              Invalid parameter passed.
 *          CHNL_E_NOIOC
 *              Timeout parameter was "NO_WAIT", yet no I/O completions were
 *              queued.

Question 3.
On the DSP side I note that SIO_reclaim returns 0x4FFC: this is contrary to  documentation
If a stream was created in SIO_OUTPUT mode, then SIO_reclaim returns an empty buffer, and nmadus is zero, since the buffer is empty.
However the system works: some configuration error is pending ?

Question 4.
On most of our boards the system works nicely for days.
On some board (identically configured) after some time the ARM core hangs,
i.e. the Linux operating system does not respond any more.
When this happens:
the DSP core is running safely, only a timeout was recognized for the SIO_reclaim call.
After the timeout , code prevents further SIO_issue/reaclim calls are performed, but the channel is still operational.
the ARM core is freezed just after the CHNL_reclaim call is issued: the call itself does not return.
Possible explanations ?
Can this be due to a device silicon bug ?

Question 5.
Should I enable debugging on DSPLINK, which TRC_ENABLE on drv_pmgr.c best fit the problem ?

Thank you for your attention.

 

  • 0
    Intellectual 625 points

    Too bad, nobody is daring to give some reply to my questions ....
    I believe they are very basic for anybody experienced in DSPLINK...
    Had I better ask to the DSPBIOS Forum ?

  • 0
    TI__Intellectual 2790 points

    Misha:

    > Question 1.   The buffers size is not an exact multiple of cache line size: is this a potential error ?

    http://processors.wiki.ti.com/index.php/DSPLink_POOL_FAQs#Are_there_any_alignment_restrictions_on_POOL_buffer_sizes.3F

    and the DSPLink Programmer's Guide, section 4.2.1:

    "The POOL_open () call is used to configure the shared memory requirement for the
    application. Since the pool is shared between DSP and GPP, the sizes of the buffers
    must be cache aligned. DSP/BIOS LINK provides an API DSPLINK_ALIGN which can
    be used to get the cache aligned size.
    For SMA Pool, we need to configure a parameter of type SMAPOOL_Attrs in the
    POOL_open call. The POOL_open call takes a structure of type SMAPOOL_Attrs for the
    POOL_open call. The elements in the structure are:
    · numBufPools: Number of buffer pools.
    · bufSizes: Array of sizes of the buffers in each buffer pools. The buffer sizes
    must be cache aligned."


    > Question 2a:  The ARM thread actually executes more CHNL_reclaim calls if the previous call return code is DSP_ETIMEOUT:
    is this allowed or a CHNL_issue must be interlaced for every CHNL_reclaim call ?

        It is allowed to call CHNL_reclaim() again without another SIO_issue(), if the previous reclaim timed out.  If the CHNL_reclaim() call fails due to timeout, the driver checks the list of IO completions, and if empty, resets the internal SYNC event which will be signaled when the buffer arrives.  That way, one can call CHNL_reclaim() again, and wait again for the SYNC event to be signaled.

    > Question 2b:  Please note that DSPLINK documentation does not report tis (DSP_ETIMEOUT) as an exit code, but only [...]

    Sometimes, in DSPLink, you will see other errors which come from lower levels in the stack.  When CHNL_reclaim() times out, it is because it calls SYNC_WaitOnEvent() which when it times out, returns DSP_E_TIMEOUT.   That status code is being percolated up the stack.  The documentation for CHNL_reclaim() (and probably other APIs) documents only those Error codes returned by that API at its function level.

    >Question 3: On the DSP side I note that SIO_reclaim returns 0x4FFC: this is contrary to  documentation
    If a stream was created in SIO_OUTPUT mode, then SIO_reclaim returns an empty buffer, and nmadus is zero, since the buffer is empty.
    However the system works: some configuration error is pending ?

    The caller of SIO_reclaim() for an output channel only really needs to check that the return value is negative, indicating an error.  Anything else is not actionable.  The documentation may be wrong; evidently, the code is returning the size of the buffer instead.

    > Question 4: [...] On some board (identically configured) after some time the ARM core hangs, [...]

    See answer to question #1 as a possible cause.  Otherwise, without more information....

    > Question 5.  Should I enable debugging on DSPLINK, which TRC_ENABLE on drv_pmgr.c best fit the problem?

    Yes, see:

    http://processors.wiki.ti.com/index.php/Debugging_DSPLink_using_SET_FAILURE_REASON_prints

    http://processors.wiki.ti.com/index.php/Enabling_trace_in_DSPLink

    It might be good to enable trace for the kernel CHNL and POOL modules.

    Regards,
    - Gil


  • 0 in reply to GAnthony
    Intellectual 625 points

    Many thanks for your attention and reply to my post.

    Misha.