request_region()

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

...

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

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.

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

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

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.

That seems to indicate memory mapped IO...

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

Revolutions do not require corporate support.

Yes.

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

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?

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

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

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

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