On Thu, 25 Oct 2007, Tivy, Robert wrote:
. . .
In order to manage this memory block, CMEM performs
an ioremap() (either ioremap_nocache() or ioremap_cached()), getting a
kernel virtual pointer as a result. At some later time (as a result of
a user request) CMEM calls get_phys() on a kernel virtual address within
this block (get_phys() also is called for user mappings to the same
block). The "new" get_phys() doesn't handle this kernel translation
correctly - the returned phys addr is always some constant offset from
the correct one.
The ioremap functions obtain a virtual address block large enough for
the physical block through the kernel get_vm_area() function. This
function traverses the list 'vmlist' for an area that is large enough to
satisfy the request. The chosen virtual address is then mapped to the
requested physical address. The problem with get_phys() is that it uses
the 'virt_to_phys()' API which assumes a fixed, constant relationship
between a kernel virt addr and the corresponding phys addr, but in this
case the virt addr is some arbitrary address found to be free somewhere
between VMALLOC_START->VMALLOC_END. From what I can see, the only way
to do this translation is to traverse the 'vmlist' and find the
vm_struct for the virt addr, and return the phys_addr element of the
vm_struct. However, vmlist is not exported, and I would expect that
there is a helper function somewhere for traversing vmlist, but I can't
find anything.
. . .
Please advise on how to successfully translate these types of virtual
addresses.
Thanks in advance for any "pointers" you can provide :)
Heh. This is venturing into an area I've never been able to truly learn
The Right Way. Various thoughts:
- Given that you know the starting phys and virt addresses of the memory
block in question, why can't you just work with offsets from those?
- This is almost certainly an invalid use of virt_to_phys():
<http://www.uwsg.iu.edu/hypermail/linux/kernel/9812.1/0830.html> and
the thread starting at
<http://ozlabs.org/pipermail/linuxppc-embedded/2007-October/028668.html>.
- Be careful when surfing the net on this. Most of the discussions and in-
fo on this topic implicitly assume an Intel architecture with PCI and
so forth (one example is
<http://www.ussg.iu.edu/hypermail/linux/kernel/0007.2/0582.html>), and
are not applicable to embedded systems such DaVinci.
I've never learned of any good ARM-Linux maillist, so the 'linuxppc' ar-
chives (hosted at ozlabs.org; see above link) might be one of the bet-
ter places to learn more about this.
Tom
--
/"\ ASCII Ribbon Campaign |
\ / | Email to user 'CTZ001'
X Against HTML | at 'email.mot.com'
/ \ in e-mail & news |
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
