--- Ribamar Santarosa de Sousa <ribamar@xxxxxxxxxxx> wrote: > > An empty region of memory is where there exist no > physical ram / io memory. > > I can quote a real life example. > > I had a pci bridge and some devices on the > secondary side of the bridge. > > I configured 1 MB > > starting from 0x8000_0000 for the bridge. i.e, any > access to this > > address will fetch data from the pci devices > > then I do a request_mem_region (0x80000000, > 0x00100000, "pci_non_trans"); > > An ioremap () on the returned address will give a > virtual address which > > can be used for accessing it. > > ioremap on the returned address??: > addr = request_mem_region ( physical, ...); > ioremap( addr, ... ) ???... > first I thought the correct was the inverse: > addr = ioremap(physical, ..); > request_mem_region( addr, ...), > but Thekkedath (if i understood him correctly; > thanks Thekkedath) > alerted me i must request_mem_region( physical, > ...); but i am still > thinking i must ioremap( physical, ...) ... Am I > wrong (again?) ? > > - Riba > > As per LDD Chapter 8 http://www.xml.com/ldd/chapter/book/ch08.html Using I/O Memory --------------- <snip> ........ According to the computer platform and bus being used, I/O memory may or may not be accessed through page tables. When access passes though page tables, the kernel must first arrange for the physical address to be visible from your driver (this usually means that you must call ioremap before doing any I/O). If no page tables are needed, then I/O memory locations look pretty much like I/O ports, and you can just read and write to them using proper wrapper functions. Whether or not ioremap is required to access I/O memory, direct use of pointers to I/O memory is a discouraged practice. Even though (as introduced in "I/O Ports and I/O Memory") I/O memory is addressed like normal RAM at hardware level, the extra care outlined in "I/O Registers and Conventional Memory" suggests avoiding normal pointers. The wrapper functions used to access I/O memory are both safe on all platforms and optimized away whenever straight pointer dereferencing can perform the operation. Therefore, even though dereferencing a pointer works (for now) on the x86, failure to use the proper macros will hinder the portability and readability of the driver. Remember from Chapter 2, "Building and Running Modules" that device memory regions must be allocated prior to use. This is similar to how I/O ports are registered and is accomplished by the following functions: int check_mem_region(unsigned long start, unsigned long len); void request_mem_region(unsigned long start, unsigned long len, char *name); void release_mem_region(unsigned long start, unsigned long len); The start argument to pass to the functions is the physical address of the memory region, before any remapping takes place. The functions would normally be used in a manner such as the following: if (check_mem_region(mem_addr, mem_size)) { printk("drivername: memory already in use\n"); return -EBUSY; } request_mem_region(mem_addr, mem_size, "drivername"); [...] release_mem_region(mem_addr, mem_size); <snip> ........ > > -- > Kernelnewbies: Help each other learn about the Linux > kernel. > Archive: > http://mail.nl.linux.org/kernelnewbies/ > FAQ: http://kernelnewbies.org/faq/ > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
