> -----Original Message----- > From: Tivy, Robert [mailto:[email protected]] > Sent: Tuesday, June 09, 2009 6:00 PM > To: Ryan Talbot; Vladimir Pantelic; > [email protected] > Cc: [email protected] > Subject: RE: CMEM and mmap'd buffers in 2.6.28rc6 > > > -----Original Message----- > > From: [email protected] > > [mailto:[email protected] > > ] On Behalf Of Ryan Talbot > > Sent: Tuesday, June 09, 2009 2:29 PM > > To: Vladimir Pantelic; > [email protected] > > Cc: [email protected] > > Subject: RE: CMEM and mmap'd buffers in 2.6.28rc6 > > > > Hi Vladimir, > > > > > Ryan Talbot wrote: > > > > > > > CMEM Error: getPhys: Failed to get physical address of > > > 0x4015c000 CMEM > > > > Error: getPhys: Failed to get physical address of 0x40226fff > > > > > > > Those addresses correspond to the virtual addresses of > the first > > > > capture buffer, and the second capture buffer -1, > > > respectively. Those > > > > were allocated via kzalloc(), which should yield physically > > > contiguous > > > > memory, so we don't know what the problem would be. > > > > It was suggested by our codec vendor that the issue might > > > be the CMEM > > > > pool configuration. We find this confusing since the > > > capture buffers > > > > come from Linux memory, not the CMEM pools. CMEM merely does the > > > > virt->phys address translation to hand to the DSP in that > > > case, right? > > > > Additionally, when recording from file and CMEM actually is > > > in charge > > > > of allocating the input buffers, things work fine. > > > > > > > It would seem, then, > > > > that CMEM is having trouble translating an address for > > > memory that it > > > > didn't allocate. > > > > > > Yes, as seen by the above error. why don't you allocate the > > mem from > > > CMEM? > > > > > > > > > Well, it was my understanding that CMEM should be able to translate > > any virtual address to a physical address. These buffers are > > internally allocated by the vpfe_capture driver and mmap'd to user > > space. This was the way it worked in 2.6.10, anyhow. Furthermore, > > looking at the code for the CMEM module, it just uses > get_user() and > > get_phys() system calls to do the translation, so it should > not care > > who originally allocated the memory. > > > > Am I mistaken in this? > > > > Ryan > > Sometime after 2.6.10 the CMEM get_phys() function stopped > working for kernel addresses. Kevin Hillman provided a new > one to work with newer kernels (unverified), but I discovered > that this new one didn't correctly translate > non-direct-mapped kernel addresses, so I added code to CMEM > to save the lower/upper bounds of the CMEM blocks' kernel > addresses, and manually look for those in get_phys() before > trying more general methods of translation. > > So, in short, CMEM's get_phys() doesn't handle > non-direct-mapped kernel addresses except the ones that > correspond to CMEM's managed memory block(s). > > Regards, > > - Rob >
Ah, OK, thanks for the explanation, Rob. I don't know how I missed your discussion with Kevin when I searched earlier; sorry for the repeat question. I guess the current solution is to use user buffers allocated with CMEM, then, and pass those into the VPFE driver? Is that what all of the CodecEngine examples for MVPro5.0 do? I noticed for example that the encodedecode demo had a switch to use kernel buffers or user buffers for DM6446. DM6467 didn't appear to be able to use user buffers, though, so I'm curious how users of this chip would get around the problem. Is this still an issue in the latest git kernel? Thanks and regards, Ryan _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
