linux-mips
[Top] [All Lists]

Re: set_io_port_base()?

To: Matthew Dharm <mdharm@momenco.com>
Subject: Re: set_io_port_base()?
From: Jun Sun <jsun@mvista.com>
Date: Wed, 20 Feb 2002 21:35:57 -0800
Cc: Ralf Baechle <ralf@oss.sgi.com>, Linux-MIPS <linux-mips@oss.sgi.com>
In-reply-to: <NEBBLJGMNKKEEMNLHGAIKEKFCFAA.mdharm@momenco.com>; from mdharm@momenco.com on Wed, Feb 20, 2002 at 06:48:50PM -0800
References: <3C745B0B.84203D3F@mvista.com> <NEBBLJGMNKKEEMNLHGAIKEKFCFAA.mdharm@momenco.com>
Sender: owner-linux-mips@oss.sgi.com
User-agent: Mutt/1.2.5i
On Wed, Feb 20, 2002 at 06:48:50PM -0800, Matthew Dharm wrote:
> But isn't that what all the complicated logic in ioremap() is for?  

Not exactly.

Here is the whole picture:

drivers do inb(delta)/outb(delta)
  -> translated to an virtual address (mips_io_port_base + delta)
     -> mapped into (GT_IO_BASE + delta) physical addr
        -> Bingo! you got the devices.

Here your goal is to make the drivers that do inb()/outb() happy (i.e.,
be able to reuse them without modification)  If you only use drivers
that directly access memory (such as drivers/net/nec_korva.c on 
linux-mips.sf.net), then you don't even have to set mips_io_port_base at all.

The ioremap() comes into place because by default you can not
set a mips_io_port_base value in kseg1 range on ocelot (it is at 0x20000000
in physical addr space).  Therefore you do a ioremap(), blah blah as explained
above.

Someday I should finish the PCI chapter on my porting guide ...

Jun


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