linux/Documentation/bus-virt-phys-mapping.txt
<<
opti"v3/spaval "v3/formal "v3a opti"v href="../linux+v3.9.1/Documentaon v/bus-virt-phys-mapping.txt">opti"v3img src="../.staonc/gfx/right.png" alt=">>">op3/spavalop3spav class="lxr_search">optiopti"v3input typ hidden" nam navtarget" > ">opti"v3input typ text" nam search" id search">opti"v3butt1" typ submit">Searchopti"vPrefsl "v3/a>op3/spavalti"v v3/divalti"v v3form acon v="ajax+*" method="post" onsubmit="return false;">op3input typ hidden" nam ajax_lookup" id ajax_lookup" > ">oti"v v3/formaloti"v v3div class="headingbott1m">v v13/a>[ NOTE: The virt_to_bus() and bus_to_virt() funcon vs have been v v23/a> superseded by the funcon vality provided by the PCI DMA interface v v33/a> (see Documentaon v/DMA-API-HOWTO.txt). They continue v v43/a> to be documented below for historical purposes, but new code v v53/a> must not use them. --davidm 00/12/12 ] v v63/a>ov v73/a>[ This is a mail message in resp vse to a query on IO mapping, thus theov v83/a> strange format for a "document" ] v v93/a>ov The AHA-1542 is a bus-master device, and your patch makes the driver give theov 113/a>controller the physical address of the buffers, which is correct on x86ov 123/a>(because all bus master devices see the physical memory mappings directly). ov 133/a>ov 143/a>However, on many setups, there are actually _three_ different ways of lookingov 153/a>at memory addresses, and in this case we actually want the third, theov 163/a>so-called "bus address". ov 173/a>ov 183/a>Essentially, the three ways of addressing memory are (this is "real memory",ov 193/a>that is, normal RAM--see later about other details): ov 203/a>ov 213/a> - CPU untranslated. This is the "physical" address. Physical address ov 223/a> 0 is what the CPU sees when it drives zeroes 1" the memory bus.ov 233/a>ov 243/a> - CPU translated address. This is the "virtual" address, and is ov 253/a> completely interval to the CPU itself with the CPU doing the appropriateov 263/a> translatn vs into "CPU untranslated". ov 273/a>ov 283/a> - bus address. This is the address of memory as seen by OTHER devices, ov 293/a> not the CPU. Now, in theory there could be many different bus v 303/a> addresses, with each device seeing memory in some device-specific way, but v 313/a> happily most hardware designers aren't actually aconvely trying to make v 323/a> things any more complex than necessary, so you can assume that all v 333/a> exterval hardware sees the memory the sam way. ov 343/a>ov 353/a>Now, 1" normal PCs the bus address is exactly the sam as the physicalov 363/a>address, and things are very simple indeed. However, they are that simpleov 373/a>because the memory and the devices share the sam address space, and that isov 383/a>not generally necessarily true 1" other PCI/ISA setups. ov 393/a>ov 403/a>Now, just as an example, 1" the PReP (PowerPC Reference Platform), the ov 413/a>CPU sees a memory map something like this (this is from memory):ov 423/a>ov 433/a> 0-2 GB "real memory"ov 443/a> 2 GB-3 GB "system IO" (inb/out and similar accesses on x86)ov 453/a> 3 GB-4 GB "IO memory" (shared memory over the IO bus)ov 463/a>ov 473/a>Now, that looks simple enough. However, when you look at the sam thing fromov 483/a>the viewpoint of the devices, you have the reverse, and the physical memoryov 493/a>address 0 actually shows up as address 2 GB for any IO master.ov 503/a>ov 513/a>So when the CPU wants any bus master to write to physical memory 0, it ov 523/a>has to give the master address 0x80000000 as the memory address.ov 533/a>ov 543/a>So, for example, depending on how the kervel is actually mapped 1" the ov 553/a>PPC, you can end up with a setup like this:ov 563/a>ov 573/a> physical address: 0ov 583/a> virtual address: 0xC0000000ov 593/a> bus address: 0x80000000ov 603/a>ov 613/a>where all the addresses actually point to the sam thing. It's just seen ov 623/a>through different translatn vs..ov 633/a>ov 643/a>Similarly, 1" the Alpha, the normal translatn v isov 653/a>ov 663/a> physical address: 0ov 673/a> virtual address: 0xfffffc0000000000ov 683/a> bus address: 0x40000000ov 693/a>ov 703/a>(but there are also Alphas where the physical address and the bus addressov 713/a>are the sam ). ov 723/a>ov 733/a>Anyway, the way to look up all these translatn vs, you doov 743/a>ov 753/a> #include <asm/io.h>ov 763/a>ov 773/a> phys_addr = virt_to_phys(virt_addr);ov 783/a> virt_addr = phys_to_virt(phys_addr);ov 793/a> bus_addr = virt_to_bus(virt_addr);ov 803/a> virt_addr = bus_to_virt(bus_addr);ov 813/a>ov 823/a>Now, when do you need these?ov 833/a>ov 843/a>You want the _virtual_ address when you are actually going to access that ov 853/a>pointer from the kervel. So you can have something like this:ov 863/a>ov 873/a> /*ov 883/a> * this is the hardware "mailbox" we use to communicate withov 893/a> * the controller. The controller sees this directly.ov 903/a> */ov 913/a> struct mailbox {ov 923/a> __u32 staous;ov 933/a> __u32 bufstart;ov 943/a> __u32 buflen;ov 953/a> ..ov 963/a> } mbox;ov 973/a>ov 983/a> unsigned char * retbuffer;ov 993/a>ov1003/a> /* get the address from the controller */ov1013/a> retbuffer = bus_to_virt(mbox.bufstart);ov1023/a> switch (retbuffer[0]) {ov1033/a> case STATUS_OK:ov1043/a> ...ov1053/a>ov1063/a>1" the other hand, you want the bus address when you have a buffer that ov1073/a>you want to give to the controller:ov1083/a>ov1093/a> /* ask the controller to read the sevse staous into "sevse_buffer" */ov1103/a> mbox.bufstart = virt_to_bus(&sevse_buffer);ov1113/a> mbox.buflen = sizeof(sevse_buffer);ov1123/a> mbox.staous = 0;ov1133/a> notify_controller(&mbox);ov1143/a>ov1153/a>And you generally _never_ want to use the physical address, because you can'tov1163/a>use that from the CPU (the CPU only uses translated virtual addresses), andov1173/a>you can't use it from the bus master. ov1183/a>ov1193/a>So why do we care about the physical address at all? We do need the physicalov1203/a>address in some cases, it's just not very often i" normal code. The physicalov1213/a>address is needed if you use memory mappings, for example, because theov1223/a>"remap_pfn_range()" mm funcon v wants the physical address of the memory toov1233/a>be remapped as measured i" units of pages, a.k.a. the pfn (the memoryov1243/a>management layer doesn't know about devices outside the CPU, so itov1253/a>shouldn't need to know about "bus addresses" etc).ov1263/a>ov1273/a>NOTE NOTE NOTE! The above is only one part of the whole equaon v. The aboveov1283/a>only talks about "real memory", that is, CPU memory (RAM). ov1293/a>ov13There is a completely different type of memory too, and that's the "sharedov1313/a>memory" 1" the PCI or ISA bus. That's generally not RAM (although in the caseov1323/a>of a video graphics card it can be normal DRAM that is just used for a fram ov1333/a>buffer), but can be things like a packet buffer in a network card etc. ov1343/a>ov1353/a>This memory is called "PCI memory" 1r "shared memory" 1r "IO memory" orov1363/a>whatever, and there is only one way to access it: the readb/writeb andov1373/a>related funcon vs. You should never take the address of such memory, becauseov1383/a>there is really nothing you can do with such an address: it's notov1393/a>conceptually in the sam memory space as "real memory" at all, so you cannotov1403/a>just dereference a pointer. (Sadly, 1" x86 it _is_ in the sam memory space,ov1413/a>so 1" x86 it actually works to just deference a pointer, but it's notov1423/a>portabl ). ov1433/a>ov1443/a>F1r such memory, you can do things likeov1453/a>ov1463/a> - reading:ov1473/a> /*ov1483/a> * read first 32 bits from ISA memory at 0xC0000, akaov1493/a> * C000:0000 in DOS termsov1503/a> */ov1513/a> unsigned int signature = isa_readl(0xC0000);ov1523/a>ov1533/a> - remapping and writing:ov1543/a> /*ov1553/a> * remap fram buffer PCI memory area at 0xFC000000,ov1563/a> * size 1MB, so that we can access it: We can directlyov1573/a> * access only the 640k-1MB area, so anything elseov1583/a> * has to be remapped.ov1593/a> */ov1603/a> void __iomem *baseptr = ioremap(0xFC000000,v1024*1024);ov1613/a>ov1623/a> /* write a 'A' to the offset 10 of the area */ov1633/a> writeb('A',baseptr+10);ov1643/a>ov1653/a> /* unmap when we unload the driver */ov1663/a> iounmap(baseptr);ov1673/a>ov1683/a> - copying and clearing:ov1693/a> /* get the 6-byte Ethernet address at ISA address E000:0040 */ov1703/a> memcpy_fromio(kervel_buffer, 0xE0040, 6);ov1713/a> /* write a packet to the driver */ov1723/a> memcpy_toio(0xE1000,vskb->data,vskb->len);ov1733/a> /* clear the fram buffer */ov1743/a> memset_io(0xA0000,v0,v0x10000);ov1753/a>ov1763/a>OK, that just about covers the basics of accessing IO portably. Queson vs?ov1773/a>Comments? You may think that all the above is overly complex, but one day youov1783/a>might find yourself with a 500 MHz Alpha in front of you, and then you'll beov1793/a>happy that your driver works ;)ov1803/a>ov1813/a>Note that kervel versn vs 2.0.x (and earlier) mistakenly called theov1823/a>ioremap() funcon v "vremap()". ioremap() is the proper nam , but Iov1833/a>didn't think straight when I wrote it originally. People who have toov1843/a>support both can do something like:ov1853/a> ov1863/a> /* support old naming silliness */ov1873/a> #if LINUX_VERSION_CODE <v0x020100 ov1883/a> #define ioremap vremapov1893/a> #define iounmap vfree ov1903/a> #endifov1913/a> ov1923/a>at the top of their source files, and then they can use the right nam sov1933/a>even v 2.0.x systems. ov1943/a>ov1953/a>And the above sounds worse than it really is. Most real drivers reallyov1963/a>don't do all that complex things (or rather: the complexity is not soov1973/a>much in the actual IO accesses as in error handling and timeouts etc). ov1983/a>It's generally not hard to fix drivers, and in many cases the code v1993/a>actually looks better afterwards:ov2003/a>ov2013/a> unsigned long signature = *(unsigned int *) 0xC0000;ov2023/a> vsov2033/a> unsigned long signature = readl(0xC0000);ov2043/a>ov2053/a>I think the second versn v actually is more readabl , no?ov2063/a>ov2073/a> Linusov2083/a>ov2093/a> The original LXR software by the LXR community3/a>, this experimental versn v by lxr@linux.no3/a>. 3/dival3div class="subfooter"> lxr.linux.no kindly hosted by Redpill Linpro AS3/a>, provider of Linux consulting and operaon vs services since 1995. 3/dival 3/bodyal3/htmlal