Hi Sriraja, I assume that you are trying to create two codec instances of same codec type from a single codec server. Also you have mentioned that you are able to run the processes individually and if they are executed together the second one fails. This looks like a Resource allocation failure. The resource could be HDVICP,DMA channals, Alg Memory. Can you give more details on this issue ? Also you can try the DVTB application which is part of the DVSDK release. With DVTB you should be able to run parallel processes with a single server. I tried out the following experiment to reproduce your problem. I ran two instances of H.264 720p encoder using DVTB, where the first process captures yuv data through Video Capture port and the second process reads a YUV file and encode the data. I'm able to run these two processes successfully. FYI since there are only 2 HDVICP resources are available in DM6467 platform and you will be able to execute upto 2 HD codecs simultaneously.
Regards Ansari -----Original Message----- ------------------------------ Message: 4 Date: Fri, 17 Apr 2009 12:15:39 +0530 From: Sriraja Yagneswaran <[email protected]> Subject: Error with CE application in 2 processes To: "[email protected]" <[email protected]> Message-ID: <[email protected]> Content-Type: text/plain; charset="us-ascii" Hello, I have a couple of CE applications that have to run as separate processes. The processes call the same server engines and are identical except that they have different input sources. I use the LAD, following the procedure described and start the applications. The processes run without any issues independently. However when both are run together, the application/process that starts first runs successfully. However the second one fails. Using CE_DEBUG=2, we find the following things, LAD_startupDSP() returns a status code of 4. Comm_create(' ) fails with status 0x80008050. I'm unable to trace the source or the reason for this failure. Please advice. We use CE 2.10.02 and DSPLINK 1.50 Regards Sriraja ________________________________ http://www.mindtree.com/email/disclaimer.html next part -------------- An HTML attachment was scrubbed... URL: http://linux.omap.com/pipermail/davinci-linux-open-source/attachments/20090417/d3982b5b/attachment-0001.htm ------------------------------ Message: 5 Date: Fri, 17 Apr 2009 12:22:02 +0530 From: "Bhandari, Vipin" <[email protected]> Subject: RE: [PATCH] ARM: DaVinci: Cleaning of DaVinci MMC driver To: David Brownell <[email protected]> Cc: "[email protected]" <[email protected]> Message-ID: <[email protected]> Content-Type: text/plain; charset="us-ascii" David, > From: David Brownell [mailto:[email protected]] > Sent: Thursday, April 16, 2009 2:39 AM > > > Vipin Bhandari <[email protected]> writes: > > > > > > > > > if (host->buffer_bytes_left == 0) { > > > - host->sg_idx++; > > > - BUG_ON(host->sg_idx == host->sg_len); > > > + host->data->sg = sg_next(host->data->sg); > > Shouldn't that be using a temp, e.g. host->sg = sg_next(host->sg)? > > Otherwise this seems like it will be clobbering the mmc_data fields, > and have no way to restore them when it completes. Not a good idea, > even if *today* it may happen not to break anything. I'll implement the same and submit the patch soon. > > > - /* Setting initialize clock */ > > > - if (cmd->opcode == 0) > > > - cmd_reg |= MMCCMD_INITCK; > > > - > > > /* Enable EDMA transfer triggers */ > > > if (host->do_dma) > > > cmd_reg |= MMCCMD_DMATRIG; > > I think the point of "don't check cmd->opcode" was either that > (a) this should be done as part of the powerup sequence, which > requires those clocks to be sent, or else (b) use the actual > opcode symbol. > > Not sending those 70-odd clocks seems, at least, unwise. Please refer to function mmc_davinci_set_ios() and inside the if statement for ios->power_mode == MMC_POWER_UP. 70 odd clocks are send here as you mentioned in point a > > > - if (!host->do_dma && (host->data_dir == DAVINCI_MMC_DATADIR_WRITE)) > > > - davinci_fifo_data_trans(host, 32); > > > + if (!host->do_dma && (host->data_dir == DAVINCI_MMC_DATADIR_WRITE) > && > > > + ((cmd->opcode == MMC_WRITE_BLOCK) || > > > + (cmd->opcode == MMC_WRITE_MULTIPLE_BLOCK))) > > > + davinci_fifo_data_trans(host, DAVINCI_MMC_FIFO_SIZE_BYTE); > > > > > > writel(cmd->arg, host->base + DAVINCI_MMCARGHL); > > > writel(cmd_reg, host->base + DAVINCI_MMCCMD); > > That confuses me, and seems like it goes against the standard "host > adapters > should not care about specific commands" policy. Won't it prevent SDIO > from > working, for example? Would a simple "host->data != NULL" address the > same > issue? Can DATADIR_WRITE even be set to that value for a non-write > command? > > There are non-MMC/non-SD write commands... Please refer to the TRM of MMCSD which states as follow xxxxxxxxxxxxxxxxxxxx When starting the write transaction, the CPU is responsible for getting the FIFO ready to start transferring data by filling up the FIFO with data prior to invoking/posting the write command to the card. Filling up the FIFO is a requirement since no interrupt/event generates at the start of the write transfer. xxxxxxxxxxxxxxxxxxxx This is required only in case of non dma based transfers and that too during write operation. > > > + if (mmc_req_freq < 400000) > > > + ns_in_one_cycle = 1000000 / ((cpu_arm_clk > > > + / (2 * (mmc_push_pull + 1)))/1000); > > > + else > > > + ns_in_one_cycle = 1000000 / ((cpu_arm_clk > > > + / (2 * (mmc_push_pull + 1)))/1000000); > > > + > > > return mmc_push_pull; > > > } > > > > > This can't be correct on systems with multiple MMC/SD controllers. > > It's updating a global to hold a card-specific value ... where it > will be used by cards that are using a different clock rate. That > value should be in the per-controller state. Point well taken. I'll implement what you suggest. > > > - /* record how much data we transferred */ > > > - temp = readl(host->base + DAVINCI_MMCNBLC); > > > - data->bytes_xfered += (data->blocks - temp) * data->blksz; > > > - > > > /* reset command and data state machines */ > > > temp = readl(host->base + DAVINCI_MMCCTL); > > > writel(temp | MMCCTL_CMDRST | MMCCTL_DATRST, > > This doesn't look right ... doesn't it introduce misbehavior > in some of the "mmctest" cases? It's at least under-reporting > the number of bytes transferred (and needlessly so). This function is an abort data call which happens during timeout or crc errors. There is no way to tell how much of the data has been transferred, as it is not acknowledged. Putting data->bytes_xfered += 0; seems to be right but as it should have been already 0 initially so not reqd. to update it again. > ------------------------------ Message: 6 Date: Fri, 17 Apr 2009 00:21:09 -0700 From: David Brownell <[email protected]> Subject: Re: [PATCH] ARM: DaVinci: Cleaning of DaVinci MMC driver To: "Bhandari, Vipin" <[email protected]> Cc: "[email protected]" <[email protected]> Message-ID: <[email protected]> Content-Type: text/plain; charset="us-ascii" On Thursday 16 April 2009, Bhandari, Vipin wrote: > > Not sending those 70-odd clocks seems, at least, unwise. > > Please refer to function mmc_davinci_set_ios() and inside > the if statement for ios->power_mode == MMC_POWER_UP. > 70 odd clocks are send here as you mentioned in point a. And so they are. Good point; ignore that comment of mine. :) > > > > - if (!host->do_dma && (host->data_dir == > > > > DAVINCI_MMC_DATADIR_WRITE)) > > > > - davinci_fifo_data_trans(host, 32); > > > > + if (!host->do_dma && (host->data_dir == > > > > DAVINCI_MMC_DATADIR_WRITE) > > && > > > > + ((cmd->opcode == MMC_WRITE_BLOCK) || > > > > + (cmd->opcode == MMC_WRITE_MULTIPLE_BLOCK))) > > > > + davinci_fifo_data_trans(host, > > > > DAVINCI_MMC_FIFO_SIZE_BYTE); > > > > > > > > writel(cmd->arg, host->base + DAVINCI_MMCARGHL); > > > > writel(cmd_reg, host->base + DAVINCI_MMCCMD); > > > > That confuses me, and seems like it goes against the standard "host > > adapters > > should not care about specific commands" policy. Won't it prevent SDIO > > from > > working, for example? Would a simple "host->data != NULL" address the > > same > > issue? Can DATADIR_WRITE even be set to that value for a non-write > > command? > > > > There are non-MMC/non-SD write commands... > > Please refer to the TRM of MMCSD which states as follow > xxxxxxxxxxxxxxxxxxxx > When starting the write transaction, the CPU is responsible for getting > the FIFO ready to start transferring data by filling up the FIFO with > data prior to invoking/posting the write command to the card. Filling > up the FIFO is a requirement since no interrupt/event generates at the > start of the write transfer. > xxxxxxxxxxxxxxxxxxxx > This is required only in case of non dma based transfers and that too > during write operation. Exactly. But there are more write transactions than those two; they just happen to be some of the most common ones. And from what I could see, the existing code already covered all of the cases: all write transactions (i.e. everything that sends a DATA stage to the card, using DAT0..DATx) was filling the fifo. Although there does seem to be a bug there ... it should never fill the fifo with more data than is being sent. > > > > > - /* record how much data we transferred */ > > > > - temp = readl(host->base + DAVINCI_MMCNBLC); > > > > - data->bytes_xfered += (data->blocks - temp) * data->blksz; > > > > - > > > > /* reset command and data state machines */ > > > > temp = readl(host->base + DAVINCI_MMCCTL); > > > > writel(temp | MMCCTL_CMDRST | MMCCTL_DATRST, > > > > This doesn't look right ... doesn't it introduce misbehavior > > in some of the "mmctest" cases? It's at least under-reporting > > the number of bytes transferred (and needlessly so). > > This function is an abort data call which happens during timeout > or crc errors. There is no way to tell how much of the data has > been transferred, as it is not acknowledged. Well, by *observation* that register gives the correct answer. Its value seems to get decremented by the ACK ... as implied by the documentation. > Putting data->bytes_xfered += 0; seems to be right but as it > should have been already 0 initially so not reqd. to update it again. Adding zero is always pointless. ;) - Dave ------------------------------ _______________________________________________ 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 40, Issue 109 ********************************************************** _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
