RE: Cmem address translation when working with Codec Engine
Hello Rob, I'm working with Amit on the same problem. Thank you very much for your quick answer and willing to help. We take the buffers directly from Cmem pool. We have a pool of 3x258048 in cmem (three buffers with size 258048), and we take one of the buffers from CMEM directly using CMEM_alloc. We do it only once for the speech codec, and this buffer is the only buffer used by us as for output buffer. After we close the codec (SPHENC_delete), we release the buffer back to CMEM directly using CMEM_free. All the CMEM allocation and free is done directly with CMEM and NOT via CodecEngine. In our case, after closing the codec and releasing the buffer, we want to reopen the codec. What we do is getting a new buffer from CMEM directly using CMEM_alloc, and then opening the codec using SPHENC_create. Another issue that is important is that in the second time, we get from CMEM a buffer with the same virtual address as the first buffer, just with different physical address. It seems like CMEM changed the virtual to physical mapping. However, when calling the DSP, it seems like CE is using the same mapping as in the first time which is no longer valid, and the DSP codec is getting a pointer to the physical buffer used in the first time. Is it possible that CMEM is changing the address translation mapping and CE is not synchronized with it and is using its old virt-to-phy mapping. Our main question: === What action should we do in order to synchronize the virt-to-phys cache in CE's Memory module with the CMEM virtual to physical mapping? Is there any CE command that tells CE to invalidate its virt-to-phys cache and take the updated values from CMEM? Thanks, Erez From: Tivy, Robert [mailto:rt...@ti.com] Sent: Tuesday, December 29, 2009 7:52 PM To: Amit Klir; Davinci-linux-open-source@linux.davincidsp.com Cc: Erez Kinarti Subject: RE: Cmem address translation when working with Codec Engine How are you "returning CMEM buf to the pool" for each codec thread? CE contains a virt-to-phys cache in CE's Memory module, and a CE codec class stubs file will use the Memory module to translate the virt addr to a phys addr. If CMEM buffer allocation is happening through the Memory module but CMEM buffer freeing is done through just CMEM then this situation can happen. There is no known problem in CMEM 2.10 of this sort, however CMEM 2.10 is older and I believe you could upgrade to LinuxUtils 2.25 which contains a later CMEM. There is also a CE 2.25 that you could upgrade to. In order for me to tell more of what's going on I would need to see some trace output from your application. Later CE releases contain support for an environment variable called CE_DEBUG that can be set to 1|2|3. Setting it to 3 will generate lots of useful output (and lots of "noise" too, unfortunately). I don't recall if 2.10 supports CE_DEBUG or if that came after 2.10, if not then you would have to use CE_TRACE instead (which is documented). If you can run your app with this trace output enabled and send it to me I can take a look. Regards, - Rob From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Amit Klir Sent: Tuesday, December 29, 2009 7:26 AM To: Davinci-linux-open-source@linux.davincidsp.com Cc: Erez Kinarti Subject: Cmem address translation when working with Codec Engine Hello, I'm working with DaVinci DM6467, using ARM running linux, and CodecEngine as the interface between ARM and DSP. My application is doing audio and video encoding in parallel in two different threads. I'm also using CMEM version 2.10 for continuous buffers allocation. The problem is that, in some situation, the CMEM buffer physical address viewed by ARM (using CMEM_getPhys()) is different than the physical address sent to DSP (translated by CodecEngine). Scenario where ArmPhyAddr != DspPhyAddr: === In my application, I open CodecEngine and then open two codecs on the DSP: VIDENC1 and SPHENC1. In the beginning both codecs are running in two different threads, and for each of them we keep a CMEM buffers pool in ARM for their IO buffers. When the app starts running, for each Codec it take a single buffer from the relevant Cmem pool, and use only this buffer for all the run. In the beginning the physical addresses viewed by ARM and DSP are equal. After a while, we do the following sequence of closing and opening the codecs: 1. Close and open the video codec - VIDENC1_delete() - Return the CMEM buf of VIDENC to the pool. - Take a new CMEM buffer from the pool to be used for VIDENC. - VIDENC_create() -
nfs rootfs login is failing
Hi All, I have compiled the latest kernel ( i.e 2.6.18_pro500-davinci_evm-arm_v5t_le) for the TI DM6467 with davinci_dm6467_defconfig and flashed on NAND. Now I am trying to mount the NFS rootfs for that I made proper changes in the bootargs and mounted to NFS rootfs successfully. But when the login prompt comes I entered login as * root* but my login is failing. Can you please help me how to login. I have attached my boot log pls find with this mail. Thanks, Anil.V Loading from NAND 128MiB 3,3V 8-bit, offset 0xa Image Name: Linux-2.6.18_pro500-davinci_evm- Image Type: ARM Linux Kernel Image (uncompressed) Data Size:1988164 Bytes = 1.9 MB Load Address: 80008000 Entry Point: 80008000 ## Booting image at 8070 ... Image Name: Linux-2.6.18_pro500-davinci_evm- Image Type: ARM Linux Kernel Image (uncompressed) Data Size:1988164 Bytes = 1.9 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. Linux version 2.6.18_pro500-davinci_evm-arm_v5t_le (ga...@gaian-laptop) (gcc version 4.2.0 (MontaVista 4.2.0-16.0.32.0801914 2008-08-30)) #1 PREEMPT Tue Dec 29 15:49:15 IST 2009 CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177 Machine: DaVinci DM6467 EVM Memory policy: ECC disabled, Data cache writeback DaVinci DM6467 variant 0x0 CPU0: D VIVT write-back cache CPU0: I cache: 16384 bytes, associativity 4, 32 byte lines, 128 sets CPU0: D cache: 8192 bytes, associativity 4, 32 byte lines, 64 sets Built 1 zonelists. Total pages: 30720 Kernel command line: console=ttyS0,115200n8 noinitrd rw ip=dhcp root=/dev/nfs nfsroot=192.168.0.120:/home/gaian/workdir/filesys,nolock mem=120M PID hash table entries: 512 (order: 9, 2048 bytes) Clock event device timer0_0 configured with caps set: 03 Console: colour dummy device 80x30 Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 120MB = 120MB total Memory: 117504KB available (3401K code, 684K data, 172K init) Security Framework v1.0.0 initialized Capability LSM initialized Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok NET: Registered protocol family 16 DaVinci: 48 gpio irqs ch0 default output "COMPOSITE", mode "NTSC" ch1 default output "", mode "" SCSI subsystem initialized usbcore: registered new driver usbfs usbcore: registered new driver hub NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 4096 (order: 2, 16384 bytes) TCP bind hash table entries: 2048 (order: 1, 8192 bytes) TCP: Hash tables configured (established 4096 bind 2048) TCP reno registered VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) squashfs: version 3.1 (2006/08/19) Phillip Lougher JFFS2 version 2.2. (NAND) (C) 2001-2006 Red Hat, Inc. yaffs Dec 29 2009 15:43:21 Installing. SGI XFS with no debug enabled Initializing Cryptographic API io scheduler noop registered io scheduler anticipatory registered (default) LTT : ltt-facilities init LTT : ltt-facility-core init in kernel DAVINCI-WDT: DaVinci Watchdog Timer: heartbeat 60 sec CIR device registered successfully (Major = 252, Minor = 0) Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing disabled serial8250.0: ttyS0 at MMIO map 0x1c2 mem 0xfec2 (irq = 40) is a ST16654 serial8250.0: ttyS1 at MMIO map 0x1c20400 mem 0xfec20400 (irq = 41) is a ST16650V2 serial8250 serial8250.0: unable to register port at index 2 (IO0 MEM1c20800 IRQ42): -28 RAMDISK driver initialized: 1 RAM disks of 32768K size 1024 blocksize netconsole: not configured, aborting TI DaVinci EMAC: MAC address is 00:0e:99:02:b3:34 TI DaVinci EMAC Linux version updated 4.0 TI DaVinci EMAC: Installed 1 instances. Linux video capture interface: v2.00 i2c /dev entries driver Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx MUX: initialized ATAEN ide0: MMIO-DMA , BIOS settings: hda:pio, hdb:pio hda: TOSHIBA MK4032GAX, ATA DISK drive ide0 at 0xfec661f0-0xfec661f7,0xfec663f6 on irq 22 hda: max request size: 512KiB hda: 78140160 sectors (40007 MB), CHS=16383/255/63, UDMA(66) hda: cache flushes supported hda: hda1 hda2 Initializing USB Mass Storage driver... usbcore: registered new driver usb-storage USB Mass Storage support registered. usbcore: registered new driver usbhid drivers/usb/input/hid-core.c: v2.6:USB HID core driver musb_hdrc: version 6.0, cppi-dma, host, debug=0 musb_hdrc: USB Host mode controller at c805c000 using DMA, IRQ 13 musb_hdrc musb_hdrc: MUSB HDRC host driver musb_hdrc musb_hdrc: new USB bus registered, assigned bus number 1 usb usb1: configuration #1 chosen from
Re: CERuntime_* and shared objects
On Wednesday 24 June 2009 01:11:05 am Ryan Talbot wrote: > Hey folks, > > I'm having some mysterious behavior occur when shutting down my > application. It seems to be tied with shutting down CodecEngine 2.21, > and we did not have this problem when using CodecEngine 1.10. > > We have a modular, multi-platform application that collects video, among > other things, and its behavior is defined at startup with a list of > shared objects to load to give it the functionality we need for any > particular scenario. The video recording capability on our DM6446-based > hardware is encapsulated in a shared object that utilizes the > CodecEngine API. > > Things go well while the application is running, and we are able to > record video without any problems. The problem surfaces when the > application closes: when Engine_close() gets called from within the > shared object, I get a "terminate called without an active exception. > Aborted." > > The identical code worked flawlessly when using CodecEngine 1.10 on this > same hardware. The fact that the CE API calls were encapsulated in a > shared object didn't seem to bother it. Standalone, monolithic code > using CodecEngine 2.21 runs fine. It would seem to indicate that > something in Engine_close() in this version of the API doesn't play well > inside a shared object context. > > I eventually ended up building a test object to track down what was > going wrong. It simply calls CERuntime_init() when the object opens and > then CERuntime_exit() when the object closes. When CERuntime_exit() is > called, the same error happens as when Engine_close() was called before > (according to the output with CE_DEBUG=3). If I don't call > CERuntime_exit(), the application hangs after return-from-main and never > closes. > > Below is the relevant snippet from my test object code and an output > snippet from the application. Has anybody tried using CodecEngine API's > from within a shared object and run into this? Any insight would be > greatly appreciated. > > Ryan > Sorry to bring-up this very old thread but I faced the same problem lately. I couldn't find the root cause of the problem but I have a workaround. I wonder if you had find the root cause of this problem? My Codec Engine version is the same but either shared library or stand alone application it doesn't matter. If I mix codec engine application with C++ and external libraries(Qt4 in my case) application terminates with the same error. If no external libraries are linked, then program works as expected. My workaround is: * Built a shared library for codec engine related parts * Do not link this with main application but use 'dlopen' with the library and import symbols with 'dlsym'. Regards, Caglar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH] davinci: MMC: Adding support for 8bit MMC cards
Hello.
Vipin Bhandari wrote:
[Re-replying to all, as I only replied to Vipin the first time.]
This patch adds the support for 8bit MMC cards. The controller
data width is configurable depending on the wires setting in the
platform data structure.
MMC 8bit is tested on OMAPL137 and MMC 4bit is tested on OMAPL138 EVM.
Signed-off-by: Vipin Bhandari
This has been done by MV in the internal tree but as you code is
significantly differenet from that one, I'm not asking you about the
missing MV signoffs...
diff --git a/drivers/mmc/host/davinci_mmc.c
b/drivers/mmc/host/davinci_mmc.c
index dd45e7c..3bd0ba2 100644
--- a/drivers/mmc/host/davinci_mmc.c
+++ b/drivers/mmc/host/davinci_mmc.c
@@ -73,6 +73,7 @@
/* DAVINCI_MMCCTL definitions */
#define MMCCTL_DATRST (1 << 0)
#define MMCCTL_CMDRST (1 << 1)
+#define MMCCTL_WIDTH_8_BIT(1 << 8)
#define MMCCTL_WIDTH_4_BIT(1 << 2)
#define MMCCTL_DATEG_DISABLED (0 << 6)
#define MMCCTL_DATEG_RISING (1 << 6)
@@ -791,22 +792,42 @@ static void calculate_clk_divider(struct
mmc_host *mmc, struct mmc_ios *ios)
static void mmc_davinci_set_ios(struct mmc_host *mmc, struct mmc_ios
*ios)
{
-unsigned int mmc_pclk = 0;
struct mmc_davinci_host *host = mmc_priv(mmc);
-mmc_pclk = host->mmc_input_clk;
dev_dbg(mmc_dev(host->mmc),
"clock %dHz busmode %d powermode %d Vdd %04x\n",
ios->clock, ios->bus_mode, ios->power_mode,
ios->vdd);
-if (ios->bus_width == MMC_BUS_WIDTH_4) {
-dev_dbg(mmc_dev(host->mmc), "Enabling 4 bit mode\n");
-writel(readl(host->base + DAVINCI_MMCCTL) | MMCCTL_WIDTH_4_BIT,
-host->base + DAVINCI_MMCCTL);
-} else {
-dev_dbg(mmc_dev(host->mmc), "Disabling 4 bit mode\n");
-writel(readl(host->base + DAVINCI_MMCCTL) & ~MMCCTL_WIDTH_4_BIT,
+
+switch (ios->bus_width) {
+case MMC_BUS_WIDTH_8:
+dev_dbg(mmc_dev(host->mmc), "Enabling 8 bit mode\n");
+writel((readl(host->base + DAVINCI_MMCCTL) &
+~MMCCTL_WIDTH_4_BIT) | MMCCTL_WIDTH_8_BIT,
host->base + DAVINCI_MMCCTL);
+break;
+case MMC_BUS_WIDTH_4:
+dev_dbg(mmc_dev(host->mmc), "Enabling 4 bit mode\n");
+if (host->version == MMC_CTLR_VERSION_2)
+writel((readl(host->base + DAVINCI_MMCCTL) &
+~MMCCTL_WIDTH_8_BIT) | MMCCTL_WIDTH_4_BIT,
+host->base + DAVINCI_MMCCTL);
+else
+writel(readl(host->base + DAVINCI_MMCCTL) |
+MMCCTL_WIDTH_4_BIT,
+host->base + DAVINCI_MMCCTL);
I don't think it makes sense to check for host->version just to not
clear the bit which is reserved for original DaVinci. There's nothing
criminal in clearing a reserved bit, so I'm suggesting that you remove
the check.
+break;
+case MMC_BUS_WIDTH_1:
+dev_dbg(mmc_dev(host->mmc), "Enabling 1 bit mode\n");
+if (host->version == MMC_CTLR_VERSION_2)
+writel(readl(host->base + DAVINCI_MMCCTL) &
+~(MMCCTL_WIDTH_8_BIT | MMCCTL_WIDTH_4_BIT),
+host->base + DAVINCI_MMCCTL);
+else
+writel(readl(host->base + DAVINCI_MMCCTL) &
+~MMCCTL_WIDTH_4_BIT,
+host->base + DAVINCI_MMCCTL);
Same comment here...
+break;
It'll result less code if you read/write the register only once --
before/after the *switch* statement respectively.
}
calculate_clk_divider(mmc, ios);
@@ -1189,10 +1210,14 @@ static int __init davinci_mmcsd_probe(struct
platform_device *pdev)
/* REVISIT: someday, support IRQ-driven card detection. */
mmc->caps |= MMC_CAP_NEEDS_POLL;
+mmc->caps |= MMC_CAP_WAIT_WHILE_BUSY;
Does this flag have to do with the bus width at all? :-/
WBR, Sergei
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: nfs rootfs login is failing
Hi, Most probably, the etc folders are mutated. Unless you have extensively made changes to the /etc of the rootfs you can just take a copy of etc from the dvsdk and try. Cheers, Deepak From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of anil v Sent: Wednesday, December 30, 2009 3:58 PM To: davinci-linux-open-source@linux.davincidsp.com Subject: nfs rootfs login is failing Hi All, I have compiled the latest kernel ( i.e 2.6.18_pro500-davinci_evm-arm_v5t_le) for the TI DM6467 with davinci_dm6467_defconfig and flashed on NAND. Now I am trying to mount the NFS rootfs for that I made proper changes in the bootargs and mounted to NFS rootfs successfully. But when the login prompt comes I entered login as root but my login is failing. Can you please help me how to login. I have attached my boot log pls find with this mail. Thanks, Anil.V DISCLAIMER: --- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. --- ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
FW: Cmem address translation when working with Codec Engine
Oops, forgot to "Reply All"... - Rob From: Tivy, Robert Sent: Wednesday, December 30, 2009 10:57 AM To: 'Erez Kinarti' Subject: RE: Cmem address translation when working with Codec Engine Erez, Thanks for your detailed explanation, it allows me to understand your problem and the solution. The bottom line is that you should be using CE's Memory module to allocate CMEM memory. This will alleviate your wrong phys addr to the DSP. If you want to continue using CMEM_alloc/free, then you can remove CE's cached virt->phys translation with: Memory_unregisterContigBuf(virtAddr, 258048); The reason you need to use CE's Memory module is because the codec class stub file is using it to get the phys addr of a virt buffer. What happens when you allocate outside of Memory is the following: - allocate with CMEM_alloc(), which causes the kernel to create the virt-phys mapping (there is no table in CMEM). - pass this buffer to _process() - _process() calls Memory_getBufferPhysicalAddress(virtAddr) - the Memory module keeps a cache of virt->phys mappings, and since Memory hasn't seen this buffer before, it asks CMEM with CMEM_getPhys(). - CMEM returns the correct phys addr and Memory caches this mapping. - you free the buffer, which frees the kernel mapping for it, then allocate a new one, and the Linux kernel creates a new mapping - the Linux kernel decides to reuse the same virt addr from before, but this time with a different phys addr - _process() calls Memory_getBufferPhysicalAddress(virtAddr) - since Memory module didn't know about the freeing of the previous buffer, it uses its old cached translation. To allocate CMEM through Memory: Memory_AllocParams params; params.type = Memory_CONTIGPOOL; params.flags = Memory_CACHED; // or Memory_NONCACHED if so desired addr = Memory_alloc(258048, ¶ms); ... Memory_free(addr, 258048, ¶ms); Regards, - Rob From: Erez Kinarti [mailto:er...@radvision.com] Sent: Wednesday, December 30, 2009 12:10 AM To: Tivy, Robert; Amit Klir; Davinci-linux-open-source@linux.davincidsp.com Subject: RE: Cmem address translation when working with Codec Engine Hello Rob, I'm working with Amit on the same problem. Thank you very much for your quick answer and willing to help. We take the buffers directly from Cmem pool. We have a pool of 3x258048 in cmem (three buffers with size 258048), and we take one of the buffers from CMEM directly using CMEM_alloc. We do it only once for the speech codec, and this buffer is the only buffer used by us as for output buffer. After we close the codec (SPHENC_delete), we release the buffer back to CMEM directly using CMEM_free. All the CMEM allocation and free is done directly with CMEM and NOT via CodecEngine. In our case, after closing the codec and releasing the buffer, we want to reopen the codec. What we do is getting a new buffer from CMEM directly using CMEM_alloc, and then opening the codec using SPHENC_create. Another issue that is important is that in the second time, we get from CMEM a buffer with the same virtual address as the first buffer, just with different physical address. It seems like CMEM changed the virtual to physical mapping. However, when calling the DSP, it seems like CE is using the same mapping as in the first time which is no longer valid, and the DSP codec is getting a pointer to the physical buffer used in the first time. Is it possible that CMEM is changing the address translation mapping and CE is not synchronized with it and is using its old virt-to-phy mapping. Our main question: === What action should we do in order to synchronize the virt-to-phys cache in CE's Memory module with the CMEM virtual to physical mapping? Is there any CE command that tells CE to invalidate its virt-to-phys cache and take the updated values from CMEM? Thanks, Erez From: Tivy, Robert [mailto:rt...@ti.com] Sent: Tuesday, December 29, 2009 7:52 PM To: Amit Klir; Davinci-linux-open-source@linux.davincidsp.com Cc: Erez Kinarti Subject: RE: Cmem address translation when working with Codec Engine How are you "returning CMEM buf to the pool" for each codec thread? CE contains a virt-to-phys cache in CE's Memory module, and a CE codec class stubs file will use the Memory module to translate the virt addr to a phys addr. If CMEM buffer allocation is happening through the Memory module but CMEM buffer freeing is done through just CMEM then this situation can happen. There is no known problem in CMEM 2.10 of this sort, however CMEM 2.10 is older and I believe you could upgrade to LinuxUtils 2.25 which contains a later CMEM. There is also a CE 2.25 that you could upgrade to. In order for me to tell more of what's going on I would need to see some trace output from your application. Later CE releases contain support for an environment variable called CE_DEBUG that c
Who is Gaurav ?
I can see many comments like "Change by Gaurav" in the dm355 source code. And strange that who Gaurav is here?___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
