I have some code (not written by me) using IO_ADDRESS
#define Writeb(v,a) (*(volatile unsigned char *)IO_ADDRESS(a) = (v))
As newer kernels doesn't support IO_ADDRESS anymore I thought to
replace this by
#define Writeb omap_writeb
but system crashes with
Unable to handle kernel NULL pointer dereference at virtual address
00000001
pgd = c7a98000
Somewhere I found this
"IO_ADDRESS is dead use io_remap like the rest of the world"
but no example or hint howto do this.
Any idea?
Is there a generic io_remap function? I thought there are only io_remap_pfn_range and io_remap_page_range functions.
Here is an excerpt from LDDv3 book:
Using remap_pfn_range
The job of building new page tables to map a range of physical addresses is handled
by remap_pfn_range and io_remap_page_range, which have the following prototypes:
int remap_pfn_range(struct vm_area_struct *vma,
unsigned long virt_addr, unsigned long pfn,
unsigned long size, pgprot_t prot);
int io_remap_page_range(struct vm_area_struct *vma,
unsigned long virt_addr, unsigned long phys_addr,
unsigned long size, pgprot_t prot);
The value returned by the function is the usual 0 or a negative error code. Let’s look
at the exact meaning of the function’s arguments:
vma
The virtual memory area into which the page range is being mapped.
virt_addr
The user virtual address where remapping should begin. The function builds
page tables for the virtual address range between virt_addr and virt_addr+size.
pfn
The page frame number corresponding to the physical address to which the virtual
address should be mapped. The page frame number is simply the physical
address right-shifted by PAGE_SHIFT bits. For most uses, the vm_pgoff field of the
VMA structure contains exactly the value you need. The function affects physical
addresses from (pfn<<PAGE_SHIFT) to (pfn<<PAGE_SHIFT)+size.
size
The dimension, in bytes, of the area being remapped.
prot
The “protection” requested for the new VMA. The driver can (and should) use
the value found in vma->vm_page_prot.
The arguments to remap_pfn_range are fairly straightforward, and most of them are
already provided to you in the VMA when your mmap method is called. You may be
wondering why there are two functions, however. The first (remap_pfn_range) is
intended for situations where pfn refers to actual system RAM, while io_remap_
page_range should be used when phys_addr points to I/O memory. In practice, the
two functions are identical on every architecture except the SPARC, and you see
remap_pfn_range used in most situations. In the interest of writing portable drivers,
however, you should use the variant of remap_pfn_range that is suited to your particular
situation.
One other complication has to do with caching: usually, references to device memory
should not be cached by the processor. Often the system BIOS sets things up
properly, but it is also possible to disable caching of specific VMAs via the protection
field. Unfortunately, disabling caching at this level is highly processor dependent.
The curious reader may wish to look at the pgprot_noncached function from
drivers/char/mem.c to see what’s involved. We won’t discuss the topic further here.
See Chapter 15 for more details.
Good luck,
-Scott.
Arno,
Please discard my previous mail. I guess you meant to use ioremap and not io_remap… function.
Chapter 9 of LDDv3 is your best bet now (or ofcourse, check the source code of a good driver in the kernel code for usage patterns).
Regards,
-Scott
Something like this?
__iomem u32 * timer_values = ioremap(0x88000000, 0x100);
if (timer_values != NULL) {
printk("VIRT=0x%x PHYS=0x%x\n", timer_values, phys_to_virt(timer_values));
//Do something with the pointer
iounmap(timer_values);
}
Regards,
Caglar
It seems that the crash I've had observed had a different reason. So
it is indeed possible to use the omap_writeb/w/l and omap_readb/w/l
functions.
These are defined in io.h
I hope this has no disadvantage/side effects.