|
Hi Bhavin, I think funtion for resetting processor through watchdog in mvl401 kernel (/arch/arm/mach-davinci/time.c/ - davinci_watchdog_reset()) is absolutely fine. In our case, I think it is not able to complete it's power state transition for resuming once control from last function davinci_watchdog_reset() goes to actual hardware.U can try this by putting printk debug messages in the function. I am able to reboot successfully for all boards which have TMS320DM64XX chip. I have noticed that on TMX versions of davinci chip, reboot sometimes work & sometimes doesn't work. So the behaviour is unpredictable. If any one knows the reason, Please let me know. Thanks, Sweta [EMAIL PROTECTED] wrote: Send Davinci-linux-open-source mailing list submissions to [email protected]To subscribe or unsubscribe via the World Wide Web, visit http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than "Re: Contents of Davinci-linux-open-source digest..." Today's Topics: 1. Watchdog Timer Reset (Bhavin Kharadi) 2. Re: Watchdog Timer Reset (Andy Ngo) 3. RE: DMA channels sharing between multiple algorithms (X. Zhou) ---------------------------------------------------------------------- Message: 1 Date: Thu, 15 Feb 2007 18:29:11 -0600 From: "Bhavin Kharadi" <[EMAIL PROTECTED]> Subject: Watchdog Timer Reset To: <[email protected]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="us-ascii" Hi All, Have anybody tried rebooting the system using software reboot. I tried rebooting the system using software reboot but it hangs after some time. I noticed that there is a silicon bug about the watchdog reset which reboots the system. I tried using the new UBOOT from TI's website but it did not work. I am running a script by which at every 2 minutes I am giving the reboot command. But it hangs after 2 to 4 hours in reboot and does not come up. Have anybody really been able to perform software reboot consistently and for more number of times? Regards, Bhavin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://linux.omap.com/pipermail/davinci-linux-open-source/attachments/20070215/c6b67cd9/attachment-0001.htm ------------------------------ Message: 2 Date: Thu, 15 Feb 2007 16:59:03 -0800 (PST) From: Andy Ngo <[EMAIL PROTECTED]> Subject: Re: Watchdog Timer Reset To: [EMAIL PROTECTED], [email protected] Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="iso-8859-1" Bhavin, If you have the DVSDK, you can register with Montavista support and get their latest patches for the kernel. I just patched mine and the reboot works great now. I believe the patch that fixes this is: mvl_patches_pro-0785-pro_arm_davinci_reboot_fix.mvlpatch I believe the latest DVSDK target LSP DVD has the patch in it already. Regards, Andy ----- Original Message ---- From: Bhavin Kharadi <[EMAIL PROTECTED]> To: [email protected] Sent: Thursday, February 15, 2007 4:29:11 PM Subject: Watchdog Timer Reset Hi All, Have anybody tried rebooting the system using software reboot. I tried rebooting the system using software reboot but it hangs after some time. I noticed that there is a silicon bug about the watchdog reset which reboots the system. I tried using the new UBOOT from TI’s website but it did not work. I am running a script by which at every 2 minutes I am giving the reboot command. But it hangs after 2 to 4 hours in reboot and does not come up. Have anybody really been able to perform software reboot consistently and for more number of times? Regards, Bhavin _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source -------------- next part -------------- An HTML attachment was scrubbed... URL: http://linux.omap.com/pipermail/davinci-linux-open-source/attachments/20070215/a38f77aa/attachment-0001.htm ------------------------------ Message: 3 Date: Fri, 16 Feb 2007 09:21:14 +0800 From: "X. Zhou" <[EMAIL PROTECTED]> Subject: RE: DMA channels sharing between multiple algorithms To: "Ring, Chris" <[EMAIL PROTECTED]>, <[email protected]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="us-ascii" Yeah, the group ID of these 2 algorithms are both configured into the same value. The below gives a snapshot of my server.cfg file: /* set up OSAL */ var osalGlobal = xdc.useModule('ti.sdo.ce.osal.Global'); osalGlobal.runtimeEnv = osalGlobal.DSPLINK_BIOS; /* activate BIOS logging module */ var LogServer = xdc.useModule('ti.sdo.ce.bioslog.LogServer'); /* get various codec modules; i.e., implementation of codecs */ var videoEncDspAlg = xdc.useModule("zx.h264videocodec.codecs.video_encode.VIDEOENC"); var videoDecDspAlg = xdc.useModule('zx.h264videocodec.codecs.video_decode.VIDEODEC'); /* * ======== Server Configuration ======== */ var Server = xdc.useModule('ti.sdo.ce.Server'); Server.threadAttrs.stackSize = 0x800; Server.threadAttrs.stackMemId = 4; //corresponding to L1DSRAM Server.threadAttrs.priority = Server.MINPRI+2; Server.algs = [ {name: "H264VIDEOENC_DSPALG", mod:videoEncDspAlg, threadAttrs: { stackSize: 0x1000, stackMemId: 4, priority: Server.MINPRI + 3}, groupId : 0, }, {name: "H264VIDEODEC_DSPALG", mod:videoDecDspAlg, threadAttrs: { stackSize: 0x1000, stackMemId: 4, priority: Server.MINPRI + 3}, groupId : 0, }, ]; /* * Note that we presume this server runs on a system with DSKT2 and DMAN3, * so we configure those modules here. */ /* we can use DMA in certain codecs! */ videoEncDspAlg.useDMA = true; videoDecDspAlg.useDMA = true; /* * ======== DSKT2 (XDAIS Alg. memory alocation ) configuration ======== */ var DSKT2 = xdc.useModule('ti.sdo.fc.dskt2.DSKT2'); DSKT2.DARAM0 = "L1DSRAM"; DSKT2.DARAM1 = "L1DSRAM"; DSKT2.DARAM2 = "L2DSRAM"; DSKT2.SARAM0 = "DDRALG_CACHEABLE"; DSKT2.SARAM1 = "DDRALG_CACHEABLE"; DSKT2.SARAM2 = "DDRALG_NONCACHEABLE"; DSKT2.ESDATA = "DDR"; DSKT2.IPROG = "DDR"; DSKT2.EPROG = "DDR"; DSKT2.DSKT2_HEAP = "DDR"; DSKT2.DARAM_SCRATCH_SIZES = [ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]; DSKT2.SARAM_SCRATCH_SIZES = [ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]; /* * ======== DMAN3 (DMA manager) configuration ======== * We assume PaRams 0..95 are taken by the Arm drivers. We reserve * all the rest, up to 127 (there are 128 PaRam sets on DM6446). * DMAN3 takes TCC's 32 through 63 (hence the High TCC mask is 0xFFFFFFFF * and the Low TCC mask is 0). */ var DMAN3 = xdc.useModule('ti.sdo.fc.dman3.DMAN3'); DMAN3.qdmaPaRamBase = 0x01C04000; DMAN3.maxPaRamEntries = 128; DMAN3.paRamBaseIndex = 64; DMAN3.numPaRamEntries = 64; DMAN3.maxQdmaChannels = 8; DMAN3.numQdmaChannels = 8; DMAN3.qdmaChannels = [0,1,2,3,4,5,6,7]; DMAN3.numTccGroup[0] = 8; DMAN3.numPaRamGroup[0] = 64; DMAN3.tccAllocationMaskH = 0xffffffff; DMAN3.tccAllocationMaskL = 0x00000000; DMAN3.heapInternal = "L1DSRAM_HEAPLABEL"; DMAN3.heapExternal = "DDR_HEAPLABEL"; DMAN3.idma3Internal = true; Program.main = Program.system = null; And at encoder side, the requirement for all the dma channels is just like this: Uns H264VIDEOENC_dmaGetChannels(IALG_Handle handle, IDMA3_ChannelRec dmaTab[]) { int i; dmaTab[0].handle = encInst->dmaHandle_0; dmaTab[0].numTransfers = 3; dmaTab[0].numWaits = 1; dmaTab[0].priority = IDMA3_PRIORITY_HIGH; dmaTab[1].handle = encInst->dmaHandle_1; dmaTab[1].numTransfers = 1; dmaTab[1].numWaits = 1; dmaTab[1].priority = IDMA3_PRIORITY_HIGH; dmaTab[2].handle = encInst->dmaHandle_2; dmaTab[2].numTransfers = 2; dmaTab[2].numWaits = 1; dmaTab[2].priority = IDMA3_PRIORITY_LOW; dmaTab[3].handle = encInst->dmaHandle_3; dmaTab[3].numTransfers = 3; dmaTab[3].numWaits = 1; dmaTab[3].priority = IDMA3_PRIORITY_LOW; dmaTab[4].handle = encInst->dmaHandle_4; dmaTab[4].numTransfers = 2; dmaTab[4].numWaits = 1; dmaTab[4].priority = IDMA3_PRIORITY_LOW; dmaTab[5].handle = encInst->dmaHandle_5; dmaTab[5].numTransfers = 1; dmaTab[5].numWaits = 1; dmaTab[5].priority = IDMA3_PRIORITY_LOW; dmaTab[6].handle = encInst->dmaHandle_6; dmaTab[6].numTransfers = 6; dmaTab[6].numWaits = 1; dmaTab[6].priority = IDMA3_PRIORITY_LOW; dmaTab[7].handle = encInst->dmaHandle_7; dmaTab[7].numTransfers = 12; dmaTab[7].numWaits = 1; dmaTab[7].priority = IDMA3_PRIORITY_LOW; for (i=0; i<8; i++) { dmaTab[i].persistent = TRUE; dmaTab[i].protocol = &ACPY3_PROTOCOL; } return 8; } And at decoder side, the requirement for all the dma channels is just like this: Uns H264VIDEODEC_dmaGetChannels(IALG_Handle handle, IDMA3_ChannelRec dmaTab[]) { dmaTab[0].handle = decInst->dmaHandle0; dmaTab[0].numTransfers = 1; dmaTab[0].numWaits = 1; dmaTab[0].priority = IDMA3_PRIORITY_HIGH; dmaTab[0].persistent = TRUE; dmaTab[0].protocol = &ACPY3_PROTOCOL; dmaTab[1].handle = decInst->dmaHandle1; dmaTab[1].numTransfers = 1; dmaTab[1].numWaits = 1; dmaTab[1].priority = IDMA3_PRIORITY_HIGH; dmaTab[1].persistent = TRUE; dmaTab[1].protocol = &ACPY3_PROTOCOL; dmaTab[2].handle = decInst->dmaHandle2; dmaTab[2].numTransfers = 1; dmaTab[2].numWaits = 1; dmaTab[2].priority = IDMA3_PRIORITY_LOW; dmaTab[2].persistent = TRUE; dmaTab[2].protocol = &ACPY3_PROTOCOL; dmaTab[3].handle = decInst->dmaHandle3; dmaTab[3].numTransfers = 3; dmaTab[3].numWaits = 1; dmaTab[3].priority = IDMA3_PRIORITY_HIGH; dmaTab[3].persistent = TRUE; dmaTab[3].protocol = &ACPY3_PROTOCOL; dmaTab[4].handle = decInst->dmaHandle4; dmaTab[4].numTransfers = 3; dmaTab[4].numWaits = 1; dmaTab[4].priority = IDMA3_PRIORITY_LOW; dmaTab[4].persistent = TRUE; dmaTab[4].protocol = &ACPY3_PROTOCOL; dmaTab[5].handle = decInst->dmaHandle5; dmaTab[5].numTransfers = 1; dmaTab[5].numWaits = 1; dmaTab[5].priority = IDMA3_PRIORITY_HIGH; dmaTab[5].persistent = TRUE; dmaTab[5].protocol = &ACPY3_PROTOCOL; dmaTab[6].handle = decInst->dmaHandle6; dmaTab[6].numTransfers = 3; dmaTab[6].numWaits = 1; dmaTab[6].priority = IDMA3_PRIORITY_HIGH; dmaTab[6].persistent = TRUE; dmaTab[6].protocol = &ACPY3_PROTOCOL; dmaTab[7].handle = decInst->dmaHandle7; dmaTab[7].numTransfers = 3; dmaTab[7].numWaits = 1; dmaTab[7].priority = IDMA3_PRIORITY_LOW; dmaTab[7].persistent = TRUE; dmaTab[7].protocol = &ACPY3_PROTOCOL; return 8; } Any further clue? ZhouX -----Original Message----- From: Ring, Chris [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 15, 2007 11:17 PM To: X. Zhou; [email protected] Subject: RE: DMA channels sharing between multiple algorithms When codecs share resources, they must be configured into the same 'group', like this: Server.algs = [ {name: "viddec_copy", mod: VIDDEC_COPY, threadAttrs: { stackMemId: 0, priority: Server.MINPRI + 2}, groupId : 0, }, {name: "videnc_copy", mod: VIDENC_COPY, threadAttrs: { stackMemId: 0, priority: Server.MINPRI + 2}, groupId : 0, } ]; You might consider posting the entire server config script so we can sanity check it, and see if anything else jumps out. Chris ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]. com] On Behalf Of X. Zhou Sent: Thursday, February 15, 2007 5:37 AM To: [email protected] Subject: DMA channels sharing between multiple algorithms Hi, everyone, I encounterer a very weird problem related to DMA which needs your help. I use the DVSDK software architecure to develop a H.264 video codec on the EVM6446 board. At dsp side, there are 2 algorithms, one is encoder, which use 8 QDMA channels and totally 30 param entryes during each process loop, the other is decoder, which use also 8 QDMA channels and totally 16 param entryes) during each process loop, And I configure the server just like the following: ............. DMAN3.qdmaPaRamBase = 0x01C04000; DMAN3.maxPaRamEntries = 128; DMAN3.paRamBaseIndex = 64; DMAN3.numPaRamEntries = 64; DMAN3.maxQdmaChannels = 8; DMAN3.numQdmaChannels = 8; DMAN3.qdmaChannels = [0,1,2,3,4,5,6,7]; DMAN3.numTccGroup[0] = 8; DMAN3.numPaRamGroup[0] = 64; DMAN3.tccAllocationMaskH = 0xffffffff; DMAN3.tccAllocationMaskL = 0x00000000; DMAN3.heapInternal = "L1DSRAM_HEAPLABEL"; DMAN3.heapExternal = "DDR_HEAPLABEL"; DMAN3.idma3Internal = true; ............. The main loop of my application is just like the following: henc = VIDENC_create(hCE, encoder_name, &encparams); hdec = VIDENC_create(hCE, decoder_name, &decparams); while ( i < frameNum ) { ....... if ( encoder_enable_flag ) { status = VIDENC_process(henc, &enc_inbuf_desc, &enc_outbuf_desc, &enc_inargs, &enc_outargs); } ....... if ( decoder_enable_flag ) { status = VIDDEC_process(hdec, &dec_inbuf_desc, &dec_outbuf_desc, &dec_inargs, &dec_outargs); } ....... } Now the problem is: (1) If I enable both encoder and decoder(i.e., set encoder_enable_flag and decoder_enable_flag to be 1), sometimes decoder's decoded frames is not consistent to the standard decoded frames. But if i only enable decoder only (i.e., encoder_enable_flag = 1 and decoder_enable_flag = 1), the decoder works perfectly always. (2) I replace all the DMA transfer opeations in decoder with memcpy() functions, and then repeat the steps in (1), the decoder does work . So i doubt this problem maybe is caused by the DMA configuration and DMA channels sharing between 2 algorithms. I have checked all the DMA configurations in both my encoder and decoder, for example, at the entry point and exit point of each process call, make sure all the QDMA channels has been in done status, and activate ( at the entry point) / deacitivate ( at the exit point) them. And I am sure that the DMA configuration is correct, and no memory out-of-range accesses exit. have i missed something about DMA channels sharing between multiple algorithms? Who can give me any clue about it? ZhouX This message (including any attachments) is for the named addressee(s)'s use only. It may contain sensitive, confidential, private proprietary or legally privileged information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. Any use, disclosure, copying, or distribution of this message and/or any attachments is strictly prohibited. This message (including any attachments) is for the named addressee(s)'s use only. It may contain sensitive, confidential, private proprietary or legally privileged information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. Any use, disclosure, copying, or distribution of this message and/or any attachments is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://linux.omap.com/pipermail/davinci-linux-open-source/attachments/20070216/ce5e4407/attachment.htm ------------------------------ _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source End of Davinci-linux-open-source Digest, Vol 14, Issue 37 ********************************************************* - This message has been scanned for viruses, spam and dangerous content by www.CleanMailGateway.com, and is believed to be clean. eInfochips Business Disclaimer: This message may contain confidential, proprietary or legally Privileged information. In case you are not the original intended Recipient of the message, you must not, directly or indirectly, use, Disclose, distribute, print, or copy any part of this message and you are requested to delete it and inform the sender. Any views expressed in this message are those of the individual sender unless otherwise stated. Nothing contained in this message shall be construed as an offer or acceptance of any offer by eInfochips Limited and/or eInfochips Inc("eInfochips") unless sent with that express intent and with due authority of eInfochips. eInfochips has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. eInfochips Business Disclaimer: This message may contain confidential, proprietary or legally Privileged information. In case you are not the original intended Recipient of the message, you must not, directly or indirectly, use, Disclose, distribute, print, or copy any part of this message and you are requested to delete it and inform the sender. Any views expressed in this message are those of the individual sender unless otherwise stated. Nothing contained in this message shall be construed as an offer or acceptance of any offer by eInfochips Limited and/or eInfochips Inc("eInfochips") unless sent with that express intent and with due authority of eInfochips. eInfochips has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. |
_______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
