[Top] [All Lists]

Re: ioremap() broken?

Subject: Re: ioremap() broken?
From: Ralf Baechle <>
Date: Tue, 15 Feb 2000 03:10:48 +0100
In-reply-to: <>
References: <>
On Mon, Feb 14, 2000 at 10:40:12AM -0800, wrote:

> in asm-mips/io.h we have:
>     extern inline void * ioremap(unsigned long offset, unsigned long size)
>     {
>           return (void *) KSEG1ADDR(offset);
>     }
>     #define readb(addr) (*(volatile unsigned char *) (0xa0000000 + (unsigned 
> long)(addr)))
> and in asm-mips/addrspace.h:
>     #define KSEG1                   0xa0000000
>     #define KSEG1ADDR(a)            ((__typeof__(a))(((unsigned long)(a) & 
> 0x1fffffff) | KSEG1))
> Hence if I map physical address range 0x1fa00300-0x1fa0033f and read from it:
>      mapped = ioremap(0x1fa00300, 0x40);      /* returns 0xbfa00300 */
>      data = readb(mapped+0x20);
> then this fails miserably with
>     Unable to handle kernel paging request at virtual address 5fa00320
> My questions:
>  1. Is it really necessary to add anything to the addr in the readb() et al.
>     macros? ioremap() already takes care of that.
>  2. If yes, isn't it better to or (`|') instead of add ('+') 0xa0000000 in the
>     readb() et al. macros (or to use the macro KSEG1ADDR())?
> FYI, I'm trying to make the UART in the NEC Vrc-5074 hosty bridge work cleanly
> with serial.c. And serial.c first ioremap()s it.
> Furthermore I see problems with
>     #define isa_readb(a) readb(a)
> since ISA I/O space is not at 0xa0000000 but at 0xa6000000 on the NEC DDB
> Vrc-5074. Don't we need an offset mips_io_mem_base, like is done on most other
> non-ia32 architectures (cfr. mips_io_port_base for inb() and friends)?

This is mostly historical garbage.  Looong time ago we didn't have well
defined semantics for ioremap() and readb() etc.  As the result we had a
wild mix of drivers some of which were feeding physical addresses, others
virtual addresses as the arguments to readb - and some did a even wilder
things.  Only few of the drivers we're commonly using with the supported
platforms rely on these functions so the way they are represents something
that is made up to get those few drivers working.

Time to get those things into the shape they're suppose to be, these days
pretty much every new MIPS system is also PCI based.

(I'll try to fix the RM200 support sometime soon.  That should fix all
the (E)ISA and PCI related things in one go.)


<Prev in Thread] Current Thread [Next in Thread>