Omkiran, It appears that there is a problem with the Memory_getBufferVirtualAddress() (and possibly Memory_getBufferPhysicalAddress()) when passing in a size of 0, as you are doing with all your calls. The problem occurs when 2 buffers are physically adjacent, i.e., one buffer ends at another buffer's start (minus 1).
For an explanation to this, and other answers, see below... Regards, - Rob ________________________________ From: Omkiran Sharma [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 12, 2008 11:41 PM To: Tivy, Robert Cc: davinci forum Subject: Re: Mempry Cpnversion Problem Rob, That raises an interesting question then: Is it then necessary that something converted from VIR (virtual address) to PHY (physical address) will convert back to the same VIR when converted back? That's not an easy question to answer. Normally, all contiguous buffers in this cache list that's used by Memory_getBufferPhysicalAddress() are added to the list by way of Memory_contigAlloc(), which gets contiguous buffers from CMEM. CMEM will never return the same physical buffer with different virtual addresses. The story is complicated by the fact that Memory_getBufferPhysicalAddress can be called for non-CMEM buffers, and the function that adds to this cache list can also be manually invoked by way of Memory_registerContigBuf(). I haven't tried this, but I can imagine doing the following: - virtAddr = Memory_contigAlloc() to get a CMEM buffer - physAddr = Memory_getBufferPhysicalAddress() - newVirtAddr = mmap(/dev/mem, physAddr) will give a different virt addr than the one returned by Memory_contigAlloc() - foo = Memory_getBufferPhysicalAddress(newVirtAddr) which translates and changes virt addr for existing phys entry in contig buffer cache list - bar = Memory_getBufferVirtualAddress(foo) will return newVirtAddr I'm just braindumping here in the hope that this will somehow answer your question, but the "meat" of my response is below in the code trace listings... Reason why I ask: For some time we have been facing a wierd issue with CE 2.00 and have given up on it with some work arounds. We are doing 1 process call on a video codec and the outBufs->bufs pointers gets changed. and some reason it does not happen if I simply use a static global buffer for outBufs. I had two suspicions: 1. Outbufs being a input structure should not have changed. But it appears it is getting updated on the way back. 2. Even if it is getting updated, ideally the same physical address (which is what the dsp is returning) should have come back to the same virtual address. (Which does not appear to be the case) I can also see in the trace some parameters like Ss=0x40ea5000, Es=0x40ea5000, PSc=0x84057000 which ofcourse I do not understand that are different. I guess the key question is Given that Memory_getBufferVirtualAddress() works only with buffers that have previously been translated with Memory_getBufferPhysicalAddress(), is it also assured that it will return the same address back even if another virtual address is mapped to the same physical address? If that alternate mapping is known by Memory APIs then I suppose it's possible that a Memory_getBufferVirtualAddress() can return different values for the same physical address, but only if something has happened in between the two calls. If you have two virt addrs mapped to the same phys addr, and you call Memory_getBufferPhysicalAddress() with both those virt addrs *and* the same size in both calls, the virt addr in the 2nd call will get recorded in the contig buffer cache list. Memory_getBufferPhysicalAddress() first checks its cache list and if not found there, asks CMEM_getPhys(), and if that returns a valid address, it adds this phys/virt address pairing to the contig buf cache list. I'm not sure if that makes sense, but see below for the reason you're seeing what you're seeing... If it helps to notice anything the trace for the videnc_process call with the culprit section highlighted in bold, but I guess simply a clarification on the previous question will also help. @45,433,549us: [+0 T:0x00014006 S:0xbdfff41c] ti.sdo.ce.video.VIDENC - VIDENC_process> Enter (handle=0xfe230, inBufs=0x4 0e774d8, outBufs=0x40e774e4, inArgs=0x40e77428, outArgs=0x40e77434) @45,433,889us: [+5 T:0x00014006 S:0xbdfff3dc] CV - VISA_allocMsg> Allocating message for messageId=0x00030a5f @45,434,122us: [+0 T:0x00014006 S:0xbdfff3ac] OM - Memory_getBufferPhysicalAddress> Enter(virtAddr=0x40f2b000, size=0) @45,434,373us: [+1 T:0x00014006 S:0xbdfff3ac] OM - Memory__getPhysicalAddress> Enter(virtAddr=0x40f2b000, size=0) @45,434,609us: [+1 T:0x00014006 S:0xbdfff3ac] OM - Memory__getPhysicalAddress> found in cb(Sc=0x40f2b000, Ec=0x40f50200, Ss=0x40f2b000, Es=0x40f2b000, PSc=0x84131000) @45,434,927us: [+1 T:0x00014006 S:0xbdfff3ac] OM - Memory__getPhysicalAddress> returning physAddr=0x84131000 @45,435,150us: [+0 T:0x00014006 S:0xbdfff3ac] OM - Memory_getBufferPhysicalAddress> return (0x84131000) @45,435,381us: [+0 T:0x00014006 S:0xbdfff3ac] OM - Memory_getBufferPhysicalAddress> Enter(virtAddr=0x40f43c00, size=0) @45,435,610us: [+1 T:0x00014006 S:0xbdfff3ac] OM - Memory__getPhysicalAddress> Enter(virtAddr=0x40f43c00, size=0) @45,435,855us: [+1 T:0x00014006 S:0xbdfff3ac] OM - Memory__getPhysicalAddress> found in cb(Sc=0x40f2b000, Ec=0x40f50200, Ss=0x40f43c00, Es=0x40f43c00, PSc=0x84131000) @45,436,155us: [+1 T:0x00014006 S:0xbdfff3ac] OM - Memory__getPhysicalAddress> returning physAddr=0x84149c00 @45,436,386us: [+0 T:0x00014006 S:0xbdfff3ac] OM - Memory_getBufferPhysicalAddress> return (0x84149c00) @45,436,608us: [+0 T:0x00014006 S:0xbdfff3ac] OM - Memory_getBufferPhysicalAddress> Enter(virtAddr=0x40f49f00, size=0) @45,436,853us: [+1 T:0x00014006 S:0xbdfff3ac] OM - Memory__getPhysicalAddress> Enter(virtAddr=0x40f49f00, size=0) @45,437,081us: [+1 T:0x00014006 S:0xbdfff3ac] OM - Memory__getPhysicalAddress> found in cb(Sc=0x40f2b000, Ec=0x40f50200, Ss=0x40f49f00, Es=0x40f49f00, PSc=0x84131000) @45,437,377us: [+1 T:0x00014006 S:0xbdfff3ac] OM - Memory__getPhysicalAddress> returning physAddr=0x8414ff00 @45,437,622us: [+0 T:0x00014006 S:0xbdfff3ac] OM - Memory_getBufferPhysicalAddress> return (0x8414ff00) @45,437,860us: [+0 T:0x00014006 S:0xbdfff3ac] OM - Memory_getBufferPhysicalAddress> Enter(virtAddr=0x40e8b000, size=0) @45,438,090us: [+1 T:0x00014006 S:0xbdfff3ac] OM - Memory__getPhysicalAddress> Enter(virtAddr=0x40e8b000, size=0) @45,438,335us: [+1 T:0x00014006 S:0xbdfff3ac] OM - Memory__getPhysicalAddress> found in cb(Sc=0x40e8b000, Ec=0x40ea3c00, Ss=0x40e8b000, Es=0x40e8b000, PSc=0x84f8e000) @45,438,629us: [+1 T:0x00014006 S:0xbdfff3ac] OM - Memory__getPhysicalAddress> returning physAddr=0x84f8e000 @45,438,860us: [+0 T:0x00014006 S:0xbdfff3ac] OM - Memory_getBufferPhysicalAddress> return (0x84f8e000) <This is on the way in> @45,439,094us: [+0 T:0x00014006 S:0xbdfff3ac] OM - Memory_getBufferPhysicalAddress> Enter(virtAddr=0x40ea5000, size=0) @45,439,337us: [+1 T:0x00014006 S:0xbdfff3ac] OM - Memory__getPhysicalAddress> Enter(virtAddr=0x40ea5000, size=0) @45,439,566us: [+1 T:0x00014006 S:0xbdfff3ac] OM - Memory__getPhysicalAddress> found in cb(Sc=0x40ea5000, Ec=0x40eab300, Ss=0x40ea5000, Es=0x40ea5000, PSc=0x84057000) @45,439,854us: [+1 T:0x00014006 S:0xbdfff3ac] OM - Memory__getPhysicalAddress> returning physAddr=0x84057000 @45,440,073us: [+0 T:0x00014006 S:0xbdfff3ac] OM - Memory_getBufferPhysicalAddress> return (0x84057000) Note Sc and Ec values above. They reflect a buffer that has been found in the contiguous buffer cache list that starts at virt addr 0x40ea5000 and ends at 0x40eab300 with a physical start address of 0x84057000. Keep that in mind as you continue reading my further response below.. @45,440,298us: [+0 T:0x00014006 S:0xbdfff3ac] OM - Memory_getBufferPhysicalAddress> Enter(virtAddr=0x40eb5000, size=0) @45,440,553us: [+1 T:0x00014006 S:0xbdfff3ac] OM - Memory__getPhysicalAddress> Enter(virtAddr=0x40eb5000, size=0) @45,440,799us: [+1 T:0x00014006 S:0xbdfff3ac] OM - Memory__getPhysicalAddress> found in cb(Sc=0x40eb5000, Ec=0x40ebb300, Ss=0x40eb5000, Es=0x40eb5000, PSc=0x84067000) @45,441,081us: [+1 T:0x00014006 S:0xbdfff3ac] OM - Memory__getPhysicalAddress> returning physAddr=0x84067000 @45,441,311us: [+0 T:0x00014006 S:0xbdfff3ac] OM - Memory_getBufferPhysicalAddress> return (0x84067000) @45,441,532us: [+0 T:0x00014006 S:0xbdfff3bc] CV - VISA_call(visa=0xfe230, msg=0x40013c80): messageId=0x00030a5f, comman d=0x0 @45,781,910us: [+0 T:0x00014006 S:0xbdfff38c] OC - Comm_put> Enter(queue=0x3, msg=0x40013c80) @45,782,251us: [+0 T:0x00014006 S:0xbdfff38c] OC - Comm_put> return (0) @45,782,467us: [+0 T:0x00014006 S:0xbdfff384] OC - Comm_get> Enter(queue=0x10002, msg=0xbdfff41c, timeout=-1) @45,795,993us: [+0 T:0x00014006 S:0xbdfff384] OC - Comm_get> return (0) @45,796,285us: [+0 T:0x00014006 S:0xbdfff30c] OC - Comm_put> Enter(queue=0x0, msg=0x40011c80) @45,796,568us: [+0 T:0x00014006 S:0xbdfff30c] OC - Comm_put> return (0) @45,796,790us: [+0 T:0x00014006 S:0xbdfff304] OC - Comm_get> Enter(queue=0x10000, msg=0xbdfff398, timeout=-1) @45,797,856us: [+0 T:0x00014006 S:0xbdfff304] OC - Comm_get> return (0) [DSP] @99,294,744tk: [+5 T:0x8524629c S:0x8624cd94] CN - NODE> 0x862441f0(iv_deint#1) call(algHandle=0x86244260, msg=0x8 6407c80); messageId=0x00030a5f [DSP] @99,296,141tk: [+0 T:0x8524629c S:0x8624cd2c] OM - Memory_cacheInv> Enter(addr=0x84131000, sizeInBytes=0) [DSP] @99,297,080tk: [+0 T:0x8524629c S:0x8624cd2c] OM - Memory_cacheInv> return [DSP] @99,297,760tk: [+0 T:0x8524629c S:0x8624cd2c] OM - Memory_cacheInv> Enter(addr=0x84149c00, sizeInBytes=0) [DSP] @99,298,796tk: [+0 T:0x8524629c S:0x8624cd2c] OM - Memory_cacheInv> return [DSP] @99,299,478tk: [+0 T:0x8524629c S:0x8624cd2c] OM - Memory_cacheInv> Enter(addr=0x8414ff00, sizeInBytes=0) [DSP] @99,300,390tk: [+0 T:0x8524629c S:0x8624cd2c] OM - Memory_cacheInv> return [DSP] @99,301,178tk: [+0 T:0x8524629c S:0x8624cd2c] OM - Memory_cacheInv> Enter(addr=0x84f8e000, sizeInBytes=0) [DSP] @99,302,090tk: [+0 T:0x8524629c S:0x8624cd2c] OM - Memory_cacheInv> return [DSP] @99,302,769tk: [+0 T:0x8524629c S:0x8624cd2c] OM - Memory_cacheInv> Enter(addr=0x84057000, sizeInBytes=0) [DSP] @99,303,807tk: [+0 T:0x8524629c S:0x8624cd2c] OM - Memory_cacheInv> return [DSP] @99,304,486tk: [+0 T:0x8524629c S:0x8624cd2c] OM - Memory_cacheInv> Enter(addr=0x84067000, sizeInBytes=0) [DSP] @99,305,498tk: [+0 T:0x8524629c S:0x8624cd2c] OM - Memory_cacheInv> return [DSP] @99,306,184tk: [+0 T:0x8524629c S:0x8624cd0c] ti.sdo.ce.video.VIDENC - VIDENC_process> Enter (handle=0x86244260, i nBufs=0x8624cdb0, outBufs=0x8624cdbc, inArgs=0x86407db8, outArgs=0x86407dc4) [DSP] @99,307,894tk: [+5 T:0x8524629c S:0x8624ccf4] CV - VISA_enter(visa=0x86244260): algHandle = 0x86244288 [DSP] @99,308,795tk: [+0 T:0x8524629c S:0x8624ccd4] ti.sdo.ce.alg.Algorithm - Algorithm_activate> Enter(handle=0x8624428 8) [DSP] @99,309,812tk: [+0 T:0x8524629c S:0x8624ccd4] ti.sdo.ce.alg.Algorithm - Algorithm_activate> return [DSP] @99,315,393tk: [+5 T:0x8524629c S:0x8624ccf4] CV - VISA_exit(visa=0x86244260): algHandle = 0x86244288 [DSP] @99,316,328tk: [+0 T:0x8524629c S:0x8624ccd4] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Enter(handle=0x86244 288) [DSP] @99,317,499tk: [+0 T:0x8524629c S:0x8624ccd4] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> return [DSP] @99,318,382tk: [+0 T:0x8524629c S:0x8624cd0c] ti.sdo.ce.video.VIDENC - VIDENC_process> Exit (handle=0x86244260, re tVal=0x0) [DSP] @99,319,539tk: [+0 T:0x8524629c S:0x8624cd2c] OM - Memory_cacheWb> Enter(addr=0x84f8e000, sizeInBytes=0) [DSP] @99,320,528tk: [+0 T:0x8524629c S:0x8624cd2c] OM - Memory_cacheWb> return [DSP] @99,321,250tk: [+0 T:0x8524629c S:0x8624cd2c] OM - Memory_cacheWb> Enter(addr=0x84057000, sizeInBytes=0) [DSP] @99,322,317tk: [+0 T:0x8524629c S:0x8624cd2c] OM - Memory_cacheWb> return [DSP] @99,322,993tk: [+0 T:0x8524629c S:0x8624cd2c] OM - Memory_cacheWb> Enter(addr=0x84067000, sizeInBytes=0) [DSP] @99,324,003tk: [+0 T:0x8524629c S:0x8624cd2c] OM - Memory_cacheWb> return [DSP] @99,324,679tk: [+5 T:0x8524629c S:0x8624cd94] CN - NODE> returned from call(algHandle=0x86244260, msg=0x86407c80); messageId=0x00030a5f [DSP] @99,327,970tk: [+0 T:0x8500006c S:0x86243ae4] CR - processRmsCmd(0x86405ca8, 4056): cmd = 5 [DSP] @99,329,014tk: [+0 T:0x8500006c S:0x86243ae4] CR - remote time = 0x0, trace buffer size = 4032 @45,810,068us: [+0 T:0x00014006 S:0xbdfff3bc] CV - VISA_call Completed: messageId=0x00030a5f, command=0x0, return(status =0) @46,151,639us: [+0 T:0x00014006 S:0xbdfff3b4] OM - Memory_getBufferVirtualAddress> Enter(physAddr=0x84f8e000, size=0) @46,151,929us: [+1 T:0x00014006 S:0xbdfff3b4] OM - Memory__getVirtualAddress> Enter(physAddr=0x84f8e000, size=0) @46,152,173us: [+1 T:0x00014006 S:0xbdfff3b4] OM - Memory__getVirtualAddress> found in cb(Sc=0x84f8e000, Ec=0x84fa6c00, Ss=0x84f8e000, Es=0x84f8e000) @46,152,455us: [+1 T:0x00014006 S:0xbdfff3b4] OM - Memory__getVirtualAddress> returning virtAddr=0x40e8b000 @46,152,676us: [+0 T:0x00014006 S:0xbdfff3b4] OM - Memory_getBufferVirtualAddress> return (0x40e8b000) @46,152,908us: [+0 T:0x00014006 S:0xbdfff3b4] OM - Memory_getBufferVirtualAddress> Enter(physAddr=0x84057000, size=0) @46,153,161us: [+1 T:0x00014006 S:0xbdfff3b4] OM - Memory__getVirtualAddress> Enter(physAddr=0x84057000, size=0) @46,153,486us: [+1 T:0x00014006 S:0xbdfff3b4] OM - Memory__getVirtualAddress> found in cb(Sc=0x84047000, Ec=0x84057000, Ss=0x84057000, Es=0x84057000) @46,153,765us: [+1 T:0x00014006 S:0xbdfff3b4] OM - Memory__getVirtualAddress> returning virtAddr=0x41609000 @46,153,984us: [+0 T:0x00014006 S:0xbdfff3b4] OM - Memory_getBufferVirtualAddress> return (0x41609000) Note the Sc and Ec values above. They reflect a buffer that has been found in the contiguous buffer cache list that starts at phys addr 0x84047000 and ends at 0x84057000 with a virtual start address of 0x415f9000 (the displayed virtAddr corresponds to the (end + 1) of the virt addr range for this buffer). You may have already noticed the problem in what I just said - undoubtedly the Ec should have been (0x80457000 - 1) = 0x84056fff. The problem with the Memory_getBufferVirtualAddress() code is that it should be calculating Ec as (Sc + size - 1), not (Sc + size) as it is doing. This causes your (physAddr + size) expressoin to match the incorrectly calculated end address, since your size is 0. If you were to pass a size of 1, I bet this would start working correctly (except for the case where you pass phys addr as exactly the end of a buffer, which you're probably not doing). It's hard to tell exactly if this is the case, since I can't see the Memory__addContigBuf() messages which track all additions to the contiguous buffer cache, but it sure seems like the problem. So, we (TI) need to either fix this or document that you can't pass in a 0 size, and I (as a TI employee) will push for the fix. @46,154,202us: [+0 T:0x00014006 S:0xbdfff3b4] OM - Memory_getBufferVirtualAddress> Enter(physAddr=0x84067000, size=0) @46,154,468us: [+1 T:0x00014006 S:0xbdfff3b4] OM - Memory__getVirtualAddress> Enter(physAddr=0x84067000, size=0) @46,154,707us: [+1 T:0x00014006 S:0xbdfff3b4] OM - Memory__getVirtualAddress> found in cb(Sc=0x84067000, Ec=0x8406d300, Ss=0x84067000, Es=0x84067000) @46,154,979us: [+1 T:0x00014006 S:0xbdfff3b4] OM - Memory__getVirtualAddress> returning virtAddr=0x40eb5000 @46,155,197us: [+0 T:0x00014006 S:0xbdfff3b4] OM - Memory_getBufferVirtualAddress> return (0x40eb5000) @46,155,432us: [+5 T:0x00014006 S:0xbdfff3d4] CV - VISA_freeMsg(0xfe230, 0x40013c80): Freeing message with messageId=0x0 0030a5f @46,155,679us: [+0 T:0x00014006 S:0xbdfff41c] ti.sdo.ce.video.VIDENC - VIDENC_process> Exit (handle=0xfe230, retVal=0x0) 2008/8/13 Tivy, Robert <[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>> I'm not aware of any buggy behaviour with those Memory functions. However, I suppose it's possible that there are 2 virtual addresses for the same physical address, and that Memory_getBufferVirtualAddress() will return the first one it finds. BTW & FYI, Memory_getBufferVirtualAddress() works only with buffers that have previously been translated with Memory_getBufferPhysicalAddress(), just thought I'd throw that tidbit out there in case it might be pertinent. Regards, - Rob ________________________________ From: [EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]> [mailto:[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>] On Behalf Of amr ali Sent: Tuesday, August 12, 2008 2:47 AM To: davinci forum Subject: Mempry Cpnversion Problem AA, I am making an application, in which I have to make address conversion on my own. To test these APIs, I made a quick test as follows: print virtual address Memory_getBufferPhysicalAddress print physical address Memory_getBufferVirtualAddress print virtual address For some buffers, virtual addresses differ before & after!! Are these APIs buggy? Can anyone hint what is the problem? BR, Amr Ali ________________________________ Explore the seven wonders of the world Learn more!<http://search.msn.com/results.aspx?q=7+wonders+world&mkt=en-US&form=QBRE> _______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com<mailto:Davinci-linux-open-source@linux.davincidsp.com> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
_______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
