Subject: ioremap() broken?

From: [email-masked]
Date: Mon, 14 Feb 2000 10:40:12 -0800

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)?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE)
[email-masked] ------------------- Sint-Stevens-Woluwestraat 55
Voice +32-2-7248632 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 15 Feb 2000 03:10:48 +0100

> 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.)

  Ralf