[parisc-linux] request_region()

[parisc-linux] request_region()

[Richard Hirst]

My 715/old, with a cvs head kernel, has no entries in /proc/ioports.
If I change our IO_SPACE_LIMIT in io.h from 0x00ffffff to 0xfffffff,
I get

apollo:~# cat /proc/ioports 
f0800000-f08fffff : ASP
  f0800000-f0800013 : reserved
  f0800020-f0800020 : led_data
  f0824800-f0824802 : parport0
  f0826000-f0826010 : i82596
apollo:~# 


(others won't see the i82596 entry, that is local to my tree)


So, normally they don't show up because their addresses are above
IO_SPACE_LIMIT, and luckily none of them check for error returns
from request_region().

I also have:

apollo:~# cat /proc/iomem 
f0825100-f082513f : sim700


Should all that ASP related stuff be doing a request_mem_region()
so they show up in /proc/iomem rather than /proc/ioports?

If so, does that have implications for EISA devices which will appear
under ASP, where we might want to use exisiting drivers that do
request_region()?

from io.h:

/* IO Port space is :      BBiiii   where BB is HBA number. */
#define IO_SPACE_LIMIT 0x00ffffff


Richard

Re: [parisc-linux] request_region()

[Grant Grundler]

Richard Hirst wrote:
> My 715/old, with a cvs head kernel, has no entries in /proc/ioports.
> If I change our IO_SPACE_LIMIT in io.h from 0x00ffffff to 0xfffffff,
> I get
> 
> apollo:~# cat /proc/ioports 
> f0800000-f08fffff : ASP
>   f0800000-f0800013 : reserved
>   f0800020-f0800020 : led_data
>   f0824800-f0824802 : parport0
>   f0826000-f0826010 : i82596
...
> Should all that ASP related stuff be doing a request_mem_region()
> so they show up in /proc/iomem rather than /proc/ioports?

Yes. I think so.
Ideally, /proc/ioports should be empty for systems without PCI or EISA.


> If so, does that have implications for EISA devices which will appear
> under ASP, where we might want to use exisiting drivers that do
> request_region()?

The plan was EISA devices under ASP should use request_region()
and inb/outb. I have no clue how EISA "bus walk" works or how EISA
drivers will find/claim their devices.

The EISA HBA needs to register it's "pci_ops".
See arch/parisc/kernel/pci.c:PCI_PORT_OUT macro.

> from io.h:
> 
> /* IO Port space is :      BBiiii   where BB is HBA number. */
> #define IO_SPACE_LIMIT 0x00ffffff

Yup - that's correct. It means the "offending" drivers above aren't
using inb/outb since "BB" value would index beyond the end
of the HBA array and crash the box.

grant

Grant Grundler
parisc-linux {PCI|IOMMU|SMP} hacker
+1.408.447.7253

Re: [parisc-linux] request_region()

[Richard Hirst]

On Mon, Apr 02, 2001 at 09:06:10PM -0600, Grant Grundler wrote:
> The plan was EISA devices under ASP should use request_region()
> and inb/outb. I have no clue how EISA "bus walk" works or how EISA
> drivers will find/claim their devices.
> 
> The EISA HBA needs to register it's "pci_ops".
> See arch/parisc/kernel/pci.c:PCI_PORT_OUT macro.

Yep, that make sense.  Does mean sim700.c will have to make runtime
decisions whether to use raw_read (for the on-board 53c700) or inb
(for one on an EISA card), on my 715, but that is no big deal.
EISA allocates 0x1000 bytes per slot, with a four (?) byte signature
at offset 0xc80 (IIRC) to identify the cards.  At least, that is
how my old Compaq works, with first slot at 0x1000.  Seems to tie
up address-wise, at least:

10. Scorpio Sr. EISA BA (11) at 0xfc000000, versions 0x19, 0x0, 0x76, 0x0, 0x0
11. Unknown device (10) at 0xfc001000, versions 0x0, 0x0, 0xfff, 0x0, 0x0

Again, IIRC, last time I played with the EISA slot on my 715 I
found the EISA 53c700 couldn't access main memory, and EISA interrupts
were not routed to the CPU.  The driver could access the chip registers
though.  But that was all a long time ago, so things may be different
now.

Richard

Re: [parisc-linux] request_region()

[Matthew Wilcox]

On Tue, Apr 03, 2001 at 10:05:02AM +0100, Richard Hirst wrote:
> Yep, that make sense.  Does mean sim700.c will have to make runtime
> decisions whether to use raw_read (for the on-board 53c700) or inb
> (for one on an EISA card), on my 715, but that is no big deal.

i think sim700.c should be using ioremap / readX / writeX instead
of raw_read.  Is the EISA scsi really only accessible via port io?
I would have throught that it would be memory mapped, in which case
there's no need to have a macro to access it.

> EISA allocates 0x1000 bytes per slot, with a four (?) byte signature
> at offset 0xc80 (IIRC) to identify the cards.  At least, that is
> how my old Compaq works, with first slot at 0x1000.  Seems to tie
> up address-wise, at least:
> 
> 10. Scorpio Sr. EISA BA (11) at 0xfc000000, versions 0x19, 0x0, 0x76, 0x0, 0x0
> 11. Unknown device (10) at 0xfc001000, versions 0x0, 0x0, 0xfff, 0x0, 0x0

That seems to indicate memory mapped IO...

> Again, IIRC, last time I played with the EISA slot on my 715 I
> found the EISA 53c700 couldn't access main memory, and EISA interrupts
> were not routed to the CPU.  The driver could access the chip registers
> though.  But that was all a long time ago, so things may be different
> now.

How BugFree(TM) do we think the Wax driver is?

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] request_region()

[Grant Grundler]

Matthew Wilcox wrote:
> i think sim700.c should be using ioremap / readX / writeX instead
> of raw_read.  Is the EISA scsi really only accessible via port io?

Yes.

> I would have throught that it would be memory mapped, in which case
> there's no need to have a macro to access it.

IO Port space is memory mapped but not in a linear fashion (afaik).
My understanding is the IO port space is mapped 4 bytes per MMIO page.

grant

Grant Grundler
parisc-linux {PCI|IOMMU|SMP} hacker
+1.408.447.7253

Re: [parisc-linux] request_region()

[Grant Grundler]

Richard Hirst wrote:
> Yep, that make sense.  Does mean sim700.c will have to make runtime
> decisions whether to use raw_read (for the on-board 53c700) or inb
> (for one on an EISA card), on my 715, but that is no big deal.

Someone (willy or prumpf?) told me Linus (and/or perhaps others)
have rejected such "automagic" redirection of IO space access functions.
IIRC, the reason was complexity and extra CPU cycles.
But it seems any multibus driver ends up doing it on its own anyway.

I was thinking perhaps the sim700 driver could be compiled
*twice* to produce two binaries from the same source. One flavor
to access devices which use MMIO and the other flavor would claim
devices which only use IO port space. Thoughts?

> EISA allocates 0x1000 bytes per slot, with a four (?) byte signature
> at offset 0xc80 (IIRC) to identify the cards.  At least, that is
> how my old Compaq works, with first slot at 0x1000.  Seems to tie
> up address-wise, at least:
> 
> 10. Scorpio Sr. EISA BA (11) at 0xfc000000, versions 0x19, 0x0, 0x76, 0x0, 0x
>   0
> 11. Unknown device (10) at 0xfc001000, versions 0x0, 0x0, 0xfff, 0x0, 0x0

Interesting the SCSI device is reported at 0xfc... address.
If that's an IO port space address, it would be nice if the
EISA bus code could mask off the upper 16 bits so the drivers only
see "0x1000". (HBA # is 0 unless more than one EISA BA needs to be
supported).

> Again, IIRC, last time I played with the EISA slot on my 715 I
> found the EISA 53c700 couldn't access main memory, and EISA interrupts
> were not routed to the CPU.  The driver could access the chip registers
> though.  But that was all a long time ago, so things may be different
> now.

EISA 53c700 should be able to access main memory but I don't think
the interrupt routing stuff has been resolved yet. Poke Alex DeVries
some more.  :^)

later,
grant

Grant Grundler
parisc-linux {PCI|IOMMU|SMP} hacker
+1.408.447.7253

Re: [parisc-linux] request_region()

[Alan Cox]

> Someone (willy or prumpf?) told me Linus (and/or perhaps others)
> have rejected such "automagic" redirection of IO space access functions.
> IIRC, the reason was complexity and extra CPU cycles.
> But it seems any multibus driver ends up doing it on its own anyway.

Some drivers do this andit works out fine. The real reason for suggesting
people generally avoid it is the cost of all the conditions and stuff.

If its done intelligently its not a problem because driver authors write

	if(dev->bus==GSC)
	{
		for(i=0;i<256;i++)
			*b++=raw_readl(foo+i);
	}
	else
	{
	}

not

	for(i=0;i<256;i++)
		*b++=magic_readl(foo+i);

The latter produces pretty hideous efficiency as you can imagine

> I was thinking perhaps the sim700 driver could be compiled
> *twice* to produce two binaries from the same source. One flavor
> to access devices which use MMIO and the other flavor would claim
> devices which only use IO port space. Thoughts?

In some cases that may be appropriate, eg if both devices are almost never
found in the same box.

One final comment. Every rule Linus makes you can get him to ignore if you have
a good case for it.

Alan