On 12/7/06, Ring, Chris <[EMAIL PROTECTED]> wrote:
Haven't tried it, but for those interested, the cmem function for virt->phys translation is below. Anybody familiar with Linux know if anything's changed in recent kernels that would cause this technique to fail? Or want to offer up a better way to do this translation?Can anyone confirm this [mis-]behavior? Thanks in advance! ======================================== /* Traverses the page tables and translates a virtual adress to a physical. */ static unsigned long get_phys(unsigned long virtp) { pgd_t *pgd; pmd_t *pmd; pte_t *pte; struct mm_struct *mm = current->mm; pgd = pgd_offset(mm, virtp); if (!(pgd_none(*pgd) || pgd_bad(*pgd))) { pmd = pmd_offset(pgd, virtp); if (!(pmd_none(*pmd) || pmd_bad(*pmd))) { pte = pte_offset_kernel(pmd, virtp); if (pte_present(*pte)) { return __pa(page_address(pte_page(*pte)) + (virtp & ~PAGE_MASK)); } } } return 0; }
Ah, why don't you want to use get_user_pages(...) instead. This is my total guess. This driver takes the returned pointer from "malloc" in userspace and tries to reserve and map same memory to target processor, in this case is c64x. get_user_pages(...) pins down user pages properly and you should be able to get all pages array, which you can map it to the target address space. Above code will _never_ be portable, and advise not to touch the code like above. Just for explanation: Above code traverses the all the pgd, pmd and finally pte of ARM, to get the pages corresponding to the buffer address passed by the userspace which could probably "malloced" or "mmaped". Have fun !!! And I hope based on the log messages of pool, this driver does not use "non-scalable" very slow and traditional "list based allocator" :). That's by this driver should be open/GPLed :) -- ---Komal Shah http://komalshah.blogspot.com _______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
