SARA, For your PROC & CHNL failures, I think you need to look into your OSAL PRCS module implementation (/gpp/src/osal/prcs.c). Specifically, are your PRCS_IsSameContext and PRCS_IsEqual functions returning the correct information? Expected behavior is: If you have multiple threads within the same process calling these functions: PRCS_IsSameContext -> isSame = TRUE PRCS_IsEqual -> isEqual = FALSE For different processes calling these functions: PRCS_IsSameContext -> isSame = FALSE PRCS_IsEqual -> isEqual = FALSE I don't think the 1.40.05 test-suite correctly supported POOL test-suite. Subsequently, the DSPLink test-suite has become a separate product, and is no longer released with DSPLink. Siddharth (cc'ed) can help you further here. Regards, Mugdha
________________________________ From: Saravanan S [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 19, 2008 8:12 PM To: Kamoolkar, Mugdha; [email protected] Subject: RE: DSP Link 1.40.05 Test suite failure Mugdha, Thanks. When I use bios_5_31_06 I'm not getting DSP delay issue and I could reclaim the CHNL after the specified delay. Now I could execute most of the test cases given under test suite in DRA44x platform except few tests in the following components, POOL: * gppdsp: When I'm using POOL ID as "1" then the test case running for long time(probably hanging somewhere) o Example : ./testsuite.out single LINKPOOLTEST GPPDSP /opt/dsplink/test/gppdsp/POOL0255.dat I executed only one test case with pool id as "1". Please refer the attached debug file pool_debug.txt PROC : * behavior: All test cases with "multi thread open" are failing. o Example: ./testsuite.out single LinkProcBvrTest BVR_MultithreadOpen /opt/dsplink/test/behavior/bvr_multithreadopen.dat I executed only one test case to create 2 threads. Please refer the attached debug file proc_multithread_debug.txt CHNL: * stress : all test cases are failing o Example: ./testsuite.out single LinkChnlStsTest STS_SingleThread /opt/dsplink/test/stress/sts_singlethread.dat I executed only one test case with debug enabled. Please refer the attached debug file chnl_stress_debug.txt Any valuable comments will help me to solve/understand the above issues clearly. Regards, SARA -----Original Message----- From: Kamoolkar, Mugdha [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 12, 2008 7:03 PM To: Saravanan S; [email protected] Subject: RE: DSP Link 1.40.05 Test suite failure Saravanan, In TCF file, it can be configured as: bios.GBL.CLKOUT = 360.0000; Through code, it can be configured through the GBL_setFrequency API. Make sure you follow all steps detailed in the BIOS documentation for this (frequency is to be specified in KHz, some other APIs need to be called, e.g. CLK_reconfig). >From DSPLink 1.50 onwards, this setting can also be done through DSPLink GPP-side configuration: CPUFREQ field in LINKCFG_Dsp object. If specified as -1, default value in BIOS is used, and if a new value is specified, it overrides the default BIOS value. For future reference, the BIOS documentation for c64x is at: $(BIOS install path)\bios_5_32_01\packages\ti\bios\help\doc\c6xbios.hlp Regards, Mugdha ________________________________ From: Saravanan S [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 12, 2008 5:30 PM To: Kamoolkar, Mugdha; [email protected] Subject: RE: DSP Link 1.40.05 Test suite failure Mugdha, Thanks. Basically I'm trying GPP OS as Linux in DRA44x platform and I could compile DSP/BIOS 1.40.05 and execute all sample applications successfully. When I execute the test suite I'm getting errors as I mentioned earlier. Coming to the point, we are setting DSP clock frequency as 360 MHz and 336 for ARM in uboot. I couldn't proper DSP/BIOS documentation for reference. Could you plz help me to get doc or information? Regards, SARA -----Original Message----- From: Kamoolkar, Mugdha [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 11, 2008 11:17 PM To: Saravanan S; [email protected] Subject: RE: DSP Link 1.40.05 Test suite failure SARA, This usually happens if the GBL.CLKOUT value in DSP-side is not correct, and does not match the actual frequency at which the DSP is running. In such case, the timeout calculation will not be correct. You can confirm the DSP frequency and then set this in DSP/BIOS accordingly. You can refer to DSP/BIOS documentation for how this is to be done. Regards, Mugdha ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Saravanan S Sent: Tuesday, March 11, 2008 8:50 PM To: [email protected] Subject: RE: DSP Link 1.40.05 Test suite failure Hi, We could fond the problem for test case failure, 1. We are setting 500 milliseconds as finite delay time in DSP side for CHNL_Reclaim. But it seems it is not waiting for 500 ms and immediately it issue the buffer to GPP side. 2. If we are manually change the following delay time in DSP side source file: dsp/src/test/CHNL/ reclaimtimeout/reclaimtimeout.c function : ReclaimTimeout_execute value : ticksForSleeping DSP is waiting for that much time and then issues the buffer to GPP side. We guess that calculation of ticks in DSP side is not correct at ticksForSleeping = ((CLK_countspms () / CLK_getprd ()) * delayForSleep) in the same file. So where could be the problem? Any information will be helpful for us. Thanks, SARA -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Saravanan S Sent: Monday, March 10, 2008 3:58 PM To: [email protected] Subject: DSP Link 1.40.05 Test suite failure Hi, We are trying to execute the test cases under test suites in dsplink 1.40.05. We could execute the API tests (for CHNL, PROC and MSGQ components) successfully, but we are getting the following error while executing Basic Functionality Tests of CHNL component. Suite : LinkChnlBvrTest Test : BVR_ReclaimTimeout DSP_SOK DSP_SOK DSP_ETIMEOUT DSP_SOK 0 /opt/dsplink/test/dsp/bin/reclaimtimeout.out 0 200 400 500 16384 ERROR : First Reclaim ended with unexpected status. Status = [0x8000] INFO : Status: Expected [0x8000] INFO : Status: Got [0x80008008] Status : Failed 0x80008008 We are getting this failure for all reclaim timeout tests. Can we get the root cause for the above issue? Thanks, SARA
_______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
