But isn't that what all the complicated logic in ioremap() is for? It
looks like it checks to see if it can directly address the I/O space
via kseg1 and if not, set up a translation for it...
Matthew D. Dharm Senior Software Designer
Momentum Computer Inc. 1815 Aston Ave. Suite 107
(760) 431-8663 X-115 Carlsbad, CA 92008-7310
Momentum Works For You www.momenco.com
> -----Original Message-----
> From: email@example.com [mailto:firstname.lastname@example.org]
> Sent: Wednesday, February 20, 2002 6:27 PM
> To: Ralf Baechle
> Cc: Matthew Dharm; Linux-MIPS
> Subject: Re: set_io_port_base()?
> Ralf Baechle wrote:
> > On Wed, Feb 20, 2002 at 06:05:21PM -0800, Matthew Dharm wrote:
> > > If it works as I think it does, then is the code in
> > > linux/arch/mips/gt64120/momenco_ocelot/setup.c correct?
> > > it calls ioremap() and then calls set_io_port_base() with a very
> > > strange value -- it's the value from ioremap()
> > > modified by the I/O physical address base...
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > I was reading too fast and missed that part.
> > > That doesn't look right to me... or I just don't quite
> understand how
> > > this is supposed to work.
> > That's definately looks fishy.
> This is actually right. This way if you pass an virtual at
> + delta), you will get a physical address (GT_PCI_IO_BASE +
> delta), the
> desired place.
> Most boards don't need this funky ioremap() and base addr
> substraction trick,
> but ocelot has the IO address placed beyond normal kseg1
> addressing range.