set_io_port_base()?

set_io_port_base()?

[Matthew Dharm]

So, what's the proper usage for set_io_port_base()?

I'm trying to bring up Linux on our newest board (the Ocelot-G -- see
www.momenco.com for more information).  I think I'm pretty far along,
but I can't get a plug-in PCI ethernet device to work.  What I get is:

eepro100.c:v1.09j-t 9/29/99 Donald Becker
http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html
eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V.
Savochkin <saw@saw.sw.com.sg> and others
PCI setting cache line size to 8 from 0
eth0: Invalid EEPROM checksum 0x0000, check settings before activating
this device!
eth0: Intel Corp. 82559ER, 00:00:00:00:00:00, IRQ 9.
  Receiver lock-up bug exists -- enabling work-around.
  Board assembly 000000-000, Physical connectors present:
  Primary interface chip None PHY #0.
  General self-test: passed.
  Serial sub-system self-test: passed.
  Internal registers self-test: passed.
  ROM checksum self-test: passed (0x1d68d8db).
  Receiver lock-up workaround activated.

Now, I'm pretty sure this has something to do with the initcall to
set_io_port_base() and ioremap(), which are in my setup.c (copied from
linux/arch/mips/gt64120/momenco_ocelot/setup.c and modified).  Without
that bit of code at the bottom of that function, I don't even get
this -- it just crashes.  So I know I need this code, but I'm just not
certain what/how I should be using it...

My initial guess is that it's used to map some virtual address space
onto the physical addresses needed to actually generate PCI I/O
transactions, but that's just a guess.  If that's right, then the code
I'm using _should_ work... I call ioremap() with the physical base and
size, and then set_io_port_base() using the result of ioremap().

Anyone have any thoughts?

Matt

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

Re: set_io_port_base()?

[Ralf Baechle]

On Wed, Feb 20, 2002 at 05:36:05PM -0800, Matthew Dharm wrote:

> Now, I'm pretty sure this has something to do with the initcall to
> set_io_port_base() and ioremap(), which are in my setup.c (copied from
> linux/arch/mips/gt64120/momenco_ocelot/setup.c and modified).  Without
> that bit of code at the bottom of that function, I don't even get
> this -- it just crashes.  So I know I need this code, but I'm just not
> certain what/how I should be using it...
> 
> My initial guess is that it's used to map some virtual address space
> onto the physical addresses needed to actually generate PCI I/O
> transactions, but that's just a guess.  If that's right, then the code
> I'm using _should_ work... I call ioremap() with the physical base and
> size, and then set_io_port_base() using the result of ioremap().

That is exactly the intended use.

  Ralf

RE: set_io_port_base()?

[Matthew Dharm]

If it works as I think it does, then is the code in
linux/arch/mips/gt64120/momenco_ocelot/setup.c correct?  Specifically,
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...

That doesn't look right to me... or I just don't quite understand how
this is supposed to work.

Matt

--
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: Ralf Baechle [mailto:ralf@oss.sgi.com]
> Sent: Wednesday, February 20, 2002 5:58 PM
> To: Matthew Dharm
> Cc: Linux-MIPS
> Subject: Re: set_io_port_base()?
>
>
> On Wed, Feb 20, 2002 at 05:36:05PM -0800, Matthew Dharm wrote:
>
> > Now, I'm pretty sure this has something to do with the initcall to
> > set_io_port_base() and ioremap(), which are in my setup.c
> (copied from
> > linux/arch/mips/gt64120/momenco_ocelot/setup.c and
> modified).  Without
> > that bit of code at the bottom of that function, I don't even get
> > this -- it just crashes.  So I know I need this code, but
> I'm just not
> > certain what/how I should be using it...
> >
> > My initial guess is that it's used to map some virtual
> address space
> > onto the physical addresses needed to actually generate PCI I/O
> > transactions, but that's just a guess.  If that's right,
> then the code
> > I'm using _should_ work... I call ioremap() with the
> physical base and
> > size, and then set_io_port_base() using the result of ioremap().
>
> That is exactly the intended use.
>
>   Ralf
>

Re: set_io_port_base()?

[Ralf Baechle]

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?  Specifically,
> 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.  Another crime people keep comitting is using
the same address space for both I/O memory and the base address of the
port space.

  Ralf

Re: set_io_port_base()?

[Jun Sun]

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?  Specifically,
> > 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 (mips_io_port_base
+ 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.

Jun

RE: set_io_port_base()?

[Matthew Dharm]

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

Matt

--
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: jsun@mvista.com [mailto:jsun@mvista.com]
> 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?
>  Specifically,
> > > 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
> (mips_io_port_base
> + 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.
>
> Jun
>

RE: set_io_port_base()?

[Matthew Dharm]

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

Matt

--
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: jsun@mvista.com [mailto:jsun@mvista.com]
> 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?
>  Specifically,
> > > 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
> (mips_io_port_base
> + 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.
>
> Jun
>

RE: set_io_port_base()?

[Jason Gunthorpe]

On Wed, 20 Feb 2002, Matthew Dharm wrote:

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

Yes, but ioremap does not remap io.. it remamps what linux dubs MMIO
regions. Look at drivers/net/8139too.c and check out the difference from
io and mmio. Linux's io* primitives expect an i386 like 64K IO port space,
which in mips land starts at the virtual address passed into
set_io_port_base().

BTW, the 'eepro100' driver seems to default to MMIO operation so it should
not care about set_io_port_base.. You might want to crank up speedo_debug
and make sure of the mode.

Jason

Re: set_io_port_base()?

[Jun Sun]

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

Re: set_io_port_base()?

[Ralf Baechle]

On Wed, Feb 20, 2002 at 06:27:23PM -0800, Jun Sun wrote:

> This is actually right.  This way if you pass an virtual at
> (mips_io_port_base + 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.

If you ever think about the value of the the address you're making
something wrong ...

  Ralf

pthread support in mipsel-linux

[Wayne Gowcher]

Could anyone tell me if the 2.4.x kernel / redhat 7.1
mipsel-linux distribution on the sgi ftp site supports
posix threads ?

In particular, I have a driver that I am trying to
port from x86 that links against the libraries "-lm
-lpthread" can anyone tell me what rpms I might find
them in ?

TIA

__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com

Re: pthread support in mipsel-linux

[H . J . Lu]

On Thu, Feb 21, 2002 at 08:34:36AM -0800, Wayne Gowcher wrote:
> Could anyone tell me if the 2.4.x kernel / redhat 7.1
> mipsel-linux distribution on the sgi ftp site supports
> posix threads ?

The threads works well with glibc compiled with -mips2. But the threads
in my RedHat 7.1 is broken when compiled with -mips2 :-(. I have fixed
it in glibc CVS.

> 
> In particular, I have a driver that I am trying to
> port from x86 that links against the libraries "-lm
> -lpthread" can anyone tell me what rpms I might find
> them in ?

It is the part of glibc.


H.J.

Re: pthread support in mipsel-linux

[Wayne Gowcher]

H.J.

Thank you for your reply.

> The threads works well with glibc compiled with
> -mips2. But the threads
> in my RedHat 7.1 is broken when compiled with -mips2
> :-(. I have fixed
> it in glibc CVS.

Just to clarify, the glibc rpm in your Redhat 7.1 is
compiled with -mips1 right ? So as it is broken yes ?

So if I REALLY wanted to use pthreads with your redhat
7.1 distribution, could I get away with checking out
the current glibc from CVS, recompiling it and
installing over the rpm glibc ? Or is that too
simplistic, and it will need recompilation of a lot of
other applications ? 
If so could you give me an idea of just how big a job
that is ?

Wayne

__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com

Re: pthread support in mipsel-linux

[H . J . Lu]

On Thu, Feb 21, 2002 at 10:12:04AM -0800, Wayne Gowcher wrote:
> H.J.
> 
> Thank you for your reply.
> 
> > The threads works well with glibc compiled with
> > -mips2. But the threads
> > in my RedHat 7.1 is broken when compiled with -mips2
> > :-(. I have fixed
> > it in glibc CVS.
> 
> Just to clarify, the glibc rpm in your Redhat 7.1 is
> compiled with -mips1 right ? So as it is broken yes ?

Yes. -mips1 doesn't work well with thread.

> 
> So if I REALLY wanted to use pthreads with your redhat
> 7.1 distribution, could I get away with checking out
> the current glibc from CVS, recompiling it and
> installing over the rpm glibc ? Or is that too
> simplistic, and it will need recompilation of a lot of
> other applications ? 

It should be mostly ok if you use gcc 2.96. But glibc in CVS lacks
a few mips change in my glibc in RedHat 7.1. At least, you may want
glibc-2.2-mmap64.patch in my glibc.



H.J.

Re: pthread support in mipsel-linux

[Wayne Gowcher]

It seems like getting pthread support for mips1 could
be a lengthy and involved process.

So I was wondering has anyone out there used pthreads
for with mips1 with any of the redhat distributions on
sgi ?

TIA

__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com

Re: pthread support in mipsel-linux

[Florian Lohoff]

[-- Attachment #1: Type: text/plain, Size: 675 bytes --]

On Thu, Feb 21, 2002 at 10:45:58AM -0800, Wayne Gowcher wrote:
> It seems like getting pthread support for mips1 could
> be a lengthy and involved process.
> 
> So I was wondering has anyone out there used pthreads
> for with mips1 with any of the redhat distributions on
> sgi ?

Its just the matter of ll/sc support - There are also some 
"mips2" which lack ll/sc. There is some kernel emulation for ll/sc and
also SYSMIPS(MIPS_ATOMIC_SET) which should be enough to get pthreads
working on mips1.

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
Nine nineth on september the 9th              Welcome to the new billenium

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: pthread support in mipsel-linux

[Maciej W. Rozycki]

On Thu, 21 Feb 2002, H . J . Lu wrote:

> > Just to clarify, the glibc rpm in your Redhat 7.1 is
> > compiled with -mips1 right ? So as it is broken yes ?
> 
> Yes. -mips1 doesn't work well with thread.

 What's wrong with -mips1 currently?  It used to be OK around glibc 2.2 --
has anything changed since then that needs -mips1 to be fixed?

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: pthread support in mipsel-linux

[Hiroyuki Machida]

From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Subject: Re: pthread support in mipsel-linux
Date: Fri, 22 Feb 2002 14:38:53 +0100 (MET)

> On Thu, 21 Feb 2002, H . J . Lu wrote:
> 
> > > Just to clarify, the glibc rpm in your Redhat 7.1 is
> > > compiled with -mips1 right ? So as it is broken yes ?
> > 
> > Yes. -mips1 doesn't work well with thread.
> 
>  What's wrong with -mips1 currently?  It used to be OK around glibc 2.2 --
> has anything changed since then that needs -mips1 to be fixed?
> 

Functions such as compre_and_swap() in sysdeps/mips/atomicity.h are
not atmoic with -mips1 option.

---
Hiroyuki Machida
Sony Corp.

Re: pthread support in mipsel-linux

[Maciej W. Rozycki]

On Fri, 22 Feb 2002, Hiroyuki Machida wrote:

> >  What's wrong with -mips1 currently?  It used to be OK around glibc 2.2 --
> > has anything changed since then that needs -mips1 to be fixed?
> 
> Functions such as compre_and_swap() in sysdeps/mips/atomicity.h are
> not atmoic with -mips1 option.

 They used not to be used for threads -- has it changed recently?  It
would make threads non-operational on the i386 as well, yet it doesn't
seem to be the case. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: pthread support in mipsel-linux

[H . J . Lu]

On Fri, Feb 22, 2002 at 02:38:53PM +0100, Maciej W. Rozycki wrote:
> On Thu, 21 Feb 2002, H . J . Lu wrote:
> 
> > > Just to clarify, the glibc rpm in your Redhat 7.1 is
> > > compiled with -mips1 right ? So as it is broken yes ?
> > 
> > Yes. -mips1 doesn't work well with thread.
> 
>  What's wrong with -mips1 currently?  It used to be OK around glibc 2.2 --
> has anything changed since then that needs -mips1 to be fixed?
> 

Mutex is now implemented with spin lock by default. BTW, how many
people have run "make check" on glibc compiled -mips1?


H.J.

Re: pthread support in mipsel-linux

[H . J . Lu]

On Fri, Feb 22, 2002 at 08:53:10AM -0800, H . J . Lu wrote:
> On Fri, Feb 22, 2002 at 02:38:53PM +0100, Maciej W. Rozycki wrote:
> > On Thu, 21 Feb 2002, H . J . Lu wrote:
> > 
> > > > Just to clarify, the glibc rpm in your Redhat 7.1 is
> > > > compiled with -mips1 right ? So as it is broken yes ?
> > > 
> > > Yes. -mips1 doesn't work well with thread.
> > 
> >  What's wrong with -mips1 currently?  It used to be OK around glibc 2.2 --
> > has anything changed since then that needs -mips1 to be fixed?
> > 
> 
> Mutex is now implemented with spin lock by default. BTW, how many
> people have run "make check" on glibc compiled -mips1?

Also, how many people have bootstrapped and run "make check" on gcc
3.1 from CVS on Linux/mips with glibc compiled with -mips1?  There are
some thread tests in libstdc++-v3.


H.J.

Re: pthread support in mipsel-linux

[Maciej W. Rozycki]

On Fri, 22 Feb 2002, H . J . Lu wrote:

> Mutex is now implemented with spin lock by default. BTW, how many

 Well, testandset() from linuxthreads/sysdeps/mips/pt-machine.h should
work fine with -mips1.  As should __pthread_spin_lock() from
linuxthreads/sysdeps/mips/pspinlock.c. 

> people have run "make check" on glibc compiled -mips1?

 No idea.  I may run `./configure && make all && make check' tonight on my
system as it's going to be idle over the weekend anyway.  It should finish
by Monday. ;-) 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: pthread support in mipsel-linux

[H . J . Lu]

On Fri, Feb 22, 2002 at 06:06:58PM +0100, Maciej W. Rozycki wrote:
> On Fri, 22 Feb 2002, H . J . Lu wrote:
> 
> > Mutex is now implemented with spin lock by default. BTW, how many
> 
>  Well, testandset() from linuxthreads/sysdeps/mips/pt-machine.h should
> work fine with -mips1.  As should __pthread_spin_lock() from
> linuxthreads/sysdeps/mips/pspinlock.c. 
> 
> > people have run "make check" on glibc compiled -mips1?
> 
>  No idea.  I may run `./configure && make all && make check' tonight on my
> system as it's going to be idle over the weekend anyway.  It should finish
> by Monday. ;-) 

You should also try "make check" on the current gcc 3.1. I found and
fixed the MIPS II ll/sc bugs by doing that.


H.J.

Equivalent of ioperm / iopl in linux mips ?

[Wayne Gowcher]

Hi,

I would like to access Io ports from a user land
application. I found a MINI HOWTO giving an exmaple
using ioperm / iopl and then outb, inb. Searching the
mips source code I see that sys_ioperm returns
"ENOSYS" function not implemented.

Does anyone know how to implement ioperm / iopl type
functionality on a mips system. Any example code would
be appreciated.

Wayne.

__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/

Re: Equivalent of ioperm / iopl in linux mips ?

[Geert Uytterhoeven]

On Fri, 19 Apr 2002, Wayne Gowcher wrote:
> I would like to access Io ports from a user land
> application. I found a MINI HOWTO giving an exmaple
> using ioperm / iopl and then outb, inb. Searching the
> mips source code I see that sys_ioperm returns
> "ENOSYS" function not implemented.
> 
> Does anyone know how to implement ioperm / iopl type
> functionality on a mips system. Any example code would
> be appreciated.

Like on most architectures that use memory mapped I/O: mmap() the relevant
portion of /dev/mem and read/write to/from the mapped area.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: Equivalent of ioperm / iopl in linux mips ?

[Maciej W. Rozycki]

On Sat, 20 Apr 2002, Geert Uytterhoeven wrote:

> > Does anyone know how to implement ioperm / iopl type
> > functionality on a mips system. Any example code would
> > be appreciated.
> 
> Like on most architectures that use memory mapped I/O: mmap() the relevant
> portion of /dev/mem and read/write to/from the mapped area.

 Hmm, I admit I haven't looked at this matter, but aren't
in/out/ioperm/iopl implemented as library functions in glibc like for
other architectures doing MMIO?  E.g. Alpha does this an it makes porting
programs like XFree86 and SVGATextMode much more straightforward and less
processor-specific.  That makes sense as they are not processor specific
but rather bus-specific.  If we don't do that, we should.  For platforms
without an (E)ISA or a PCI bus ioperm/iopl would simply return an error.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: Equivalent of ioperm / iopl in linux mips ?

[Geert Uytterhoeven]

On Mon, 22 Apr 2002, Maciej W. Rozycki wrote:
> On Sat, 20 Apr 2002, Geert Uytterhoeven wrote:
> > > Does anyone know how to implement ioperm / iopl type
> > > functionality on a mips system. Any example code would
> > > be appreciated.
> > 
> > Like on most architectures that use memory mapped I/O: mmap() the relevant
> > portion of /dev/mem and read/write to/from the mapped area.
> 
>  Hmm, I admit I haven't looked at this matter, but aren't
> in/out/ioperm/iopl implemented as library functions in glibc like for
> other architectures doing MMIO?  E.g. Alpha does this an it makes porting

Perhaps. Note that you still need some /proc magic to find out the correct
address to map. Or you can use /dev/ports.

> programs like XFree86 and SVGATextMode much more straightforward and less
> processor-specific.  That makes sense as they are not processor specific
> but rather bus-specific.  If we don't do that, we should.  For platforms
> without an (E)ISA or a PCI bus ioperm/iopl would simply return an error.

Yes indeed.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: Equivalent of ioperm / iopl in linux mips ?

[Maciej W. Rozycki]

On Mon, 22 Apr 2002, Geert Uytterhoeven wrote:

> >  Hmm, I admit I haven't looked at this matter, but aren't
> > in/out/ioperm/iopl implemented as library functions in glibc like for
> > other architectures doing MMIO?  E.g. Alpha does this an it makes porting
> 
> Perhaps. Note that you still need some /proc magic to find out the correct
> address to map. Or you can use /dev/ports.

 Well, for Alpha ioperm/iopl functions check the system type in
/proc/cpuinfo (we seem to have enough information there as well) and
failing this they check a result of readlink of /etc/alpha_systype.  Then
an appropriate region of /dev/mem is mmapped with per-page permissions set
up as requested if ioperm is used (with a worse granularity, though) and
subsequent in/out function invocations access the area as appropriate. 
See sysdeps/unix/sysv/linux/alpha/ioperm.c in glibc for details -- it's a
pretty clever solution with good performance and only a few trade-offs.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: Equivalent of ioperm / iopl in linux mips ?

[Geert Uytterhoeven]

On Mon, 22 Apr 2002, Maciej W. Rozycki wrote:
> On Mon, 22 Apr 2002, Geert Uytterhoeven wrote:
> > >  Hmm, I admit I haven't looked at this matter, but aren't
> > > in/out/ioperm/iopl implemented as library functions in glibc like for
> > > other architectures doing MMIO?  E.g. Alpha does this an it makes porting
> > 
> > Perhaps. Note that you still need some /proc magic to find out the correct
> > address to map. Or you can use /dev/ports.
> 
>  Well, for Alpha ioperm/iopl functions check the system type in
> /proc/cpuinfo (we seem to have enough information there as well) and
> failing this they check a result of readlink of /etc/alpha_systype.  Then
> an appropriate region of /dev/mem is mmapped with per-page permissions set
> up as requested if ioperm is used (with a worse granularity, though) and
> subsequent in/out function invocations access the area as appropriate. 
> See sysdeps/unix/sysv/linux/alpha/ioperm.c in glibc for details -- it's a
> pretty clever solution with good performance and only a few trade-offs.

I think PPC has syscalls to find the I/O bases, too.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: Equivalent of ioperm / iopl in linux mips ?

[Ralf Baechle]

On Mon, Apr 22, 2002 at 05:30:08PM +0200, Maciej W. Rozycki wrote:

>  Well, for Alpha ioperm/iopl functions check the system type in
> /proc/cpuinfo (we seem to have enough information there as well) and
> failing this they check a result of readlink of /etc/alpha_systype.  Then
> an appropriate region of /dev/mem is mmapped with per-page permissions set
> up as requested if ioperm is used (with a worse granularity, though) and
> subsequent in/out function invocations access the area as appropriate. 
> See sysdeps/unix/sysv/linux/alpha/ioperm.c in glibc for details -- it's a
> pretty clever solution with good performance and only a few trade-offs.

Thanks for volunteering ;)

  Ralf

Re: Equivalent of ioperm / iopl in linux mips ?

[Maciej W. Rozycki]

On Mon, 22 Apr 2002, Ralf Baechle wrote:

> >  Well, for Alpha ioperm/iopl functions check the system type in
> > /proc/cpuinfo (we seem to have enough information there as well) and
> > failing this they check a result of readlink of /etc/alpha_systype.  Then
> > an appropriate region of /dev/mem is mmapped with per-page permissions set
> > up as requested if ioperm is used (with a worse granularity, though) and
> > subsequent in/out function invocations access the area as appropriate. 
> > See sysdeps/unix/sysv/linux/alpha/ioperm.c in glibc for details -- it's a
> > pretty clever solution with good performance and only a few trade-offs.
> 
> Thanks for volunteering ;)

 Sure, but I have too many tasks on my to-do list now and no ISA/PCI MIPS
system to test code.  So anyone impatient enough, please do not hesitate
coding changes yourself.  Surely if you can afford waiting three years or
so, you probably need not worry as I shall have done it by then.  Also I'd
appreciate if someone sent me a system for testing.  This could actually
save you a year or two of waiting. ;-) 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

RE: set_io_port_base()?

[Matthew Dharm]

Also, does this have to be done only for PCI I/O, or PCI memory also?

Matt

--
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: Ralf Baechle [mailto:ralf@oss.sgi.com]
> Sent: Wednesday, February 20, 2002 5:58 PM
> To: Matthew Dharm
> Cc: Linux-MIPS
> Subject: Re: set_io_port_base()?
>
>
> On Wed, Feb 20, 2002 at 05:36:05PM -0800, Matthew Dharm wrote:
>
> > Now, I'm pretty sure this has something to do with the initcall to
> > set_io_port_base() and ioremap(), which are in my setup.c
> (copied from
> > linux/arch/mips/gt64120/momenco_ocelot/setup.c and
> modified).  Without
> > that bit of code at the bottom of that function, I don't even get
> > this -- it just crashes.  So I know I need this code, but
> I'm just not
> > certain what/how I should be using it...
> >
> > My initial guess is that it's used to map some virtual
> address space
> > onto the physical addresses needed to actually generate PCI I/O
> > transactions, but that's just a guess.  If that's right,
> then the code
> > I'm using _should_ work... I call ioremap() with the
> physical base and
> > size, and then set_io_port_base() using the result of ioremap().
>
> That is exactly the intended use.
>
>   Ralf
>

Re: set_io_port_base()?

[Ralf Baechle]

On Wed, Feb 20, 2002 at 06:08:39PM -0800, Matthew Dharm wrote:

> Also, does this have to be done only for PCI I/O, or PCI memory also?

This is just so all the inb/inw/outl etc. functions in <asm/io.h> know
how to access ioports.

  Ralf