Proposal: non-PC ISA bus support

Proposal: non-PC ISA bus support

[Geert Uytterhoeven]

The following patch fixes 2 problems related to ISA bus access on non-PC
platforms:

 1. ISA I/O space is memory mapped on many platforms (e.g. PPC and MIPS). To
    access it from user space, you cannot plainly use inb() and friends like on
    PC, but you have to mmap() the correct region of /dev/mem first. This
    region depends on the machine type and currently there's no simple way to
    find out from user space.

 2. ISA memory is not located at physical address 0 on many platforms (e.g. PPC
    and some MIPS boxes). This means you cannot e.g. use
    request_mem_region(0xa0000, 65536) to request the legacy VGA region.

Solutions:

 1. Provide /proc/bus/isa/map, which contains the ISA I/O and memory space
    mappings on machines where these are memory mapped.
    
    Example (on PPC CHRP LongTrail):
  
	callisto$ cat /proc/bus/isa/map 
	f8000000	01000000	IO
	f7000000	01000000	MEM
	callisto$

    The region marked `IO' is ISA (also PCI) I/O space, while the region marked
    `MEM' is ISA memory space. Of course on a PC the first one is not
    available because there are separate I/O and memory spaces on ia32.

 2. Provide new resource management functions for ISA memory space:

	isa_request_mem_region()
	isa_check_mem_region()
	isa_release_mem_region()

    On ia32, these are identical to the normal memory resource management
    functions.

    [ Alternatively we could add tests to the *_mem_region() functions to test
      whether the requested region is < 16 MB (and thus in ISA memory space)
      and add the required offset. But this affects the common resource code
      and may cause problems on machines where there is no ISA space in the
      first 16 MB of memory space. ]

The patch contains support for ia32, PPC and MIPS (limited to DDB Vrc-5074).
It was tested on PPC only.

Comments are welcomed!


diff -u --recursive --exclude-from=/home/geert/diff-excludes-linux --new-file alan-2.4.0-test1-ac21/Makefile geert-isa-2.4.0-test1-ac21/Makefile
--- alan-2.4.0-test1-ac21/Makefile	Sun Jun 18 21:14:12 2000
+++ geert-isa-2.4.0-test1-ac21/Makefile	Tue Jun 20 11:37:11 2000
@@ -152,6 +152,7 @@
 
 DRIVERS-$(CONFIG_SOUND) += drivers/sound/sounddrivers.o
 DRIVERS-$(CONFIG_PCI) += drivers/pci/pci.a
+DRIVERS-$(CONFIG_ISA) += drivers/isa/isa.o
 DRIVERS-$(CONFIG_PCMCIA) += drivers/pcmcia/pcmcia.o
 DRIVERS-$(CONFIG_PCMCIA_NETCARD) += drivers/net/pcmcia/pcmcia_net.o
 DRIVERS-$(CONFIG_PCMCIA_CHRDEV) += drivers/char/pcmcia/pcmcia_char.o
diff -u --recursive --exclude-from=/home/geert/diff-excludes-linux --new-file alan-2.4.0-test1-ac21/arch/ppc/config.in geert-isa-2.4.0-test1-ac21/arch/ppc/config.in
--- alan-2.4.0-test1-ac21/arch/ppc/config.in	Sun Jun 18 21:14:15 2000
+++ geert-isa-2.4.0-test1-ac21/arch/ppc/config.in	Tue Jun 20 11:30:40 2000
@@ -88,7 +88,11 @@
 mainmenu_option next_comment
 comment 'General setup'
 
-define_bool CONFIG_ISA n
+if [ "$CONFIG_ALL_PPC" ]; then
+    define_bool CONFIG_ISA y
+else
+    define_bool CONFIG_ISA n
+fi
 define_bool CONFIG_SBUS n
 
 if [ "$CONFIG_APUS" = "y" -o "$CONFIG_4xx" = "y" -o \
diff -u --recursive --exclude-from=/home/geert/diff-excludes-linux --new-file alan-2.4.0-test1-ac21/drivers/Makefile geert-isa-2.4.0-test1-ac21/drivers/Makefile
--- alan-2.4.0-test1-ac21/drivers/Makefile	Wed Mar 15 19:50:30 2000
+++ geert-isa-2.4.0-test1-ac21/drivers/Makefile	Sun Jun 18 21:35:06 2000
@@ -11,7 +11,7 @@
 MOD_SUB_DIRS := $(SUB_DIRS)
 ALL_SUB_DIRS := $(SUB_DIRS) pci sgi ide scsi sbus cdrom isdn pnp i2o \
 				ieee1394 macintosh video dio zorro fc4 \
-				usb nubus tc atm pcmcia i2c telephony
+				usb nubus tc atm pcmcia i2c telephony isa
 
 ifdef CONFIG_DIO
 SUB_DIRS += dio
@@ -20,6 +20,10 @@
 
 ifdef CONFIG_PCI
 SUB_DIRS += pci
+endif
+
+ifdef CONFIG_ISA
+SUB_DIRS += isa
 endif
 
 ifeq ($(CONFIG_PCMCIA),y)
diff -u --recursive --exclude-from=/home/geert/diff-excludes-linux --new-file alan-2.4.0-test1-ac21/drivers/isa/Makefile geert-isa-2.4.0-test1-ac21/drivers/isa/Makefile
--- alan-2.4.0-test1-ac21/drivers/isa/Makefile	Thu Jan  1 01:00:00 1970
+++ geert-isa-2.4.0-test1-ac21/drivers/isa/Makefile	Tue Jun 20 11:38:14 2000
@@ -0,0 +1,19 @@
+#
+# Makefile for the ISA bus specific drivers.
+#
+# Note! Dependencies are done automagically by 'make dep', which also
+# removes any old dependencies. DON'T put your own dependencies here
+# unless it's something special (ie not a .c file).
+#
+# Note 2! The CFLAGS definition is now inherited from the
+# parent makefile.
+#
+
+O_TARGET := isa.o
+
+ifdef CONFIG_PROC_FS
+O_OBJS   += proc.o
+endif
+
+include $(TOPDIR)/Rules.make
+
diff -u --recursive --exclude-from=/home/geert/diff-excludes-linux --new-file alan-2.4.0-test1-ac21/drivers/isa/proc.c geert-isa-2.4.0-test1-ac21/drivers/isa/proc.c
--- alan-2.4.0-test1-ac21/drivers/isa/proc.c	Thu Jan  1 01:00:00 1970
+++ geert-isa-2.4.0-test1-ac21/drivers/isa/proc.c	Tue Jun 20 11:37:11 2000
@@ -0,0 +1,42 @@
+/*
+ *	Procfs interface for the ISA bus.
+ *
+ *	Copyright (c) 2000 Geert Uytterhoeven <geert@linux-m68k.org>
+ */
+
+#include <linux/types.h>
+#include <linux/kernel.h>
+#include <linux/proc_fs.h>
+#include <linux/init.h>
+
+#include <asm/io.h>
+
+static int get_isa_map_info(char *buf, char **start, off_t pos, int count)
+{
+	int len = 0, cnt = 0;
+
+	if (proc_bus_isa_io_size)
+		len += sprintf(buf+len, "%p\t%p\tIO\n",
+			       (void *)proc_bus_isa_io_base,
+			       (void *)proc_bus_isa_io_size);
+	if (proc_bus_isa_mem_size)
+		len += sprintf(buf+len, "%p\t%p\tMEM\n",
+			       (void *)proc_bus_isa_mem_base,
+			       (void *)proc_bus_isa_mem_size);
+	if (pos <= len) {
+		*start = buf+pos;
+		cnt = len-pos;
+	}
+	return (count > cnt) ? cnt : count;
+}
+
+static struct proc_dir_entry *proc_bus_isa_dir;
+
+static int __init isa_proc_init(void)
+{
+	proc_bus_isa_dir = proc_mkdir("isa", proc_bus);
+	create_proc_info_entry("map", 0, proc_bus_isa_dir, get_isa_map_info);
+	return 0;
+}
+
+__initcall(isa_proc_init);
diff -u --recursive --exclude-from=/home/geert/diff-excludes-linux --new-file alan-2.4.0-test1-ac21/drivers/video/clgenfb.c geert-isa-2.4.0-test1-ac21/drivers/video/clgenfb.c
--- alan-2.4.0-test1-ac21/drivers/video/clgenfb.c	Sun Jun 18 21:14:44 2000
+++ geert-isa-2.4.0-test1-ac21/drivers/video/clgenfb.c	Sun Jun 18 21:33:38 2000
@@ -2541,7 +2541,7 @@
 	release_mem_region(info->fbmem_phys, info->size);
 
 #if 0 /* if system didn't claim this region, we would... */
-	release_mem_region(0xA0000, 65535);
+	isa_release_mem_region(0xA0000, 65535);
 #endif
 
 	if (release_io_ports)
@@ -2624,7 +2624,7 @@
 		return -1;
 	}
 #if 0 /* if the system didn't claim this region, we would... */
-	if (!request_mem_region(0xA0000, 65535, "clgenfb")) {
+	if (!isa_request_mem_region(0xA0000, 65535, "clgenfb")) {
 		pci_write_config_word (pdev, PCI_COMMAND, tmp16);
 		printk(KERN_ERR "clgen: cannot reserve region 0x%lx, abort\n",
 		       0xA0000L);
diff -u --recursive --exclude-from=/home/geert/diff-excludes-linux --new-file alan-2.4.0-test1-ac21/include/asm-i386/io.h geert-isa-2.4.0-test1-ac21/include/asm-i386/io.h
--- alan-2.4.0-test1-ac21/include/asm-i386/io.h	Tue Feb 15 21:49:25 2000
+++ geert-isa-2.4.0-test1-ac21/include/asm-i386/io.h	Tue Jun 20 13:10:11 2000
@@ -195,6 +195,11 @@
  */
 #define __ISA_IO_base ((char *)(PAGE_OFFSET))
 
+#define proc_bus_isa_io_base	(0)	/* no MMIO */
+#define proc_bus_isa_io_size	(0)	/* no MMIO */
+#define proc_bus_isa_mem_base	(0x00000000)
+#define proc_bus_isa_mem_size	(0x01000000)
+
 #define isa_readb(a) readb(__ISA_IO_base + (a))
 #define isa_readw(a) readw(__ISA_IO_base + (a))
 #define isa_readl(a) readl(__ISA_IO_base + (a))
@@ -204,6 +209,10 @@
 #define isa_memset_io(a,b,c)		memset_io(__ISA_IO_base + (a),(b),(c))
 #define isa_memcpy_fromio(a,b,c)	memcpy_fromio((a),__ISA_IO_base + (b),(c))
 #define isa_memcpy_toio(a,b,c)		memcpy_toio(__ISA_IO_base + (a),(b),(c))
+
+#define isa_request_mem_region	request_mem_region
+#define isa_check_mem_region	check_mem_region
+#define isa_release_mem_region	release_mem_region
 
 
 /*
diff -u --recursive --exclude-from=/home/geert/diff-excludes-linux --new-file alan-2.4.0-test1-ac21/include/asm-mips/io.h geert-isa-2.4.0-test1-ac21/include/asm-mips/io.h
--- alan-2.4.0-test1-ac21/include/asm-mips/io.h	Fri Mar  3 18:22:38 2000
+++ geert-isa-2.4.0-test1-ac21/include/asm-mips/io.h	Mon Jun 19 20:39:24 2000
@@ -16,6 +16,7 @@
  */
 #undef CONF_SLOWDOWN_IO
 
+#include <linux/config.h>
 #include <asm/addrspace.h>
 
 /*
@@ -112,6 +113,24 @@
  * for the processor.
  */
 extern unsigned long isa_slot_offset;
+
+#define proc_bus_isa_io_base	mips_io_port_base
+#define proc_bus_isa_mem_base	isa_slot_offset
+
+#if defined(CONFIG_DDB5074)	/* and a few others... */
+#define proc_bus_isa_io_size	(0x01000000)
+#define proc_bus_isa_mem_size	(0x01000000)
+#else
+#define proc_bus_isa_io_size	(0)
+#define proc_bus_isa_mem_size	(0)
+#endif
+
+#define isa_request_mem_region(start,n,name)	\
+    request_mem_region(isa_slot_offset+(start),(n),(name))
+#define isa_check_mem_region(start,n)	\
+    check_mem_region(isa_slot_offset+(start),(n))
+#define isa_release_mem_region(start,n)	\
+    release_mem_region(isa_slot_offset+(start),(n))
 
 /*
  * readX/writeX() are used to access memory mapped devices. On some
diff -u --recursive --exclude-from=/home/geert/diff-excludes-linux --new-file alan-2.4.0-test1-ac21/include/asm-ppc/io.h geert-isa-2.4.0-test1-ac21/include/asm-ppc/io.h
--- alan-2.4.0-test1-ac21/include/asm-ppc/io.h	Sun Jun 18 21:14:53 2000
+++ geert-isa-2.4.0-test1-ac21/include/asm-ppc/io.h	Mon Jun 19 20:13:07 2000
@@ -30,6 +30,10 @@
 #define _IO_BASE 0
 #define _ISA_MEM_BASE 0
 #define PCI_DRAM_OFFSET 0
+#define proc_bus_isa_io_base	(0)
+#define proc_bus_isa_io_size	(0)
+#define proc_bus_isa_mem_base	(0)
+#define proc_bus_isa_mem_size	(0)
 #else
 extern unsigned long isa_io_base;
 extern unsigned long isa_mem_base;
@@ -37,6 +41,10 @@
 #define _IO_BASE	isa_io_base
 #define _ISA_MEM_BASE	isa_mem_base
 #define PCI_DRAM_OFFSET	pci_dram_offset
+#define proc_bus_isa_io_base	isa_io_base
+#define proc_bus_isa_io_size	(0x01000000)
+#define proc_bus_isa_mem_base	isa_mem_base
+#define proc_bus_isa_mem_size	(0x01000000)
 #endif /* CONFIG_APUS */
 #endif
 
@@ -53,6 +61,23 @@
 #define writew(b,addr) out_le16((volatile u16 *)(addr),(b))
 #define writel(b,addr) out_le32((volatile u32 *)(addr),(b))
 #endif
+
+#define isa_readb(a)			readb(isa_mem_base+(a))
+#define isa_readw(a)			readw(isa_mem_base+(a))
+#define isa_readl(a)			readl(isa_mem_base+(a))
+#define isa_writeb(b,a)			writeb(b,isa_mem_base+(a))
+#define isa_writew(w,a)			writeb(w,isa_mem_base+(a))
+#define isa_writel(l,a)			writeb(l,isa_mem_base+(a))
+#define isa_memset_io(a,b,c)		memset_io(isa_mem_base+(a),(b),(c))
+#define isa_memcpy_fromio(a,b,c)	memcpy_fromio((a),isa_mem_base+(b),(c))
+#define isa_memcpy_toio(a,b,c)		memcpy_toio(isa_mem_base+(a),(b),(c))
+
+#define isa_request_mem_region(start,n,name)	\
+    request_mem_region(isa_mem_base+(start),(n),(name))
+#define isa_check_mem_region(start,n)	\
+    check_mem_region(isa_mem_base+(start),(n))
+#define isa_release_mem_region(start,n)	\
+    release_mem_region(isa_mem_base+(start),(n))
 
 /*
  * The insw/outsw/insl/outsl macros don't do byte-swapping.

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: Proposal: non-PC ISA bus support

[Benjamin Herrenschmidt]

On Tue, Jun 20, 2000, Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
wrote:


> 1. Provide /proc/bus/isa/map, which contains the ISA I/O and memory space
>    mappings on machines where these are memory mapped.
>
>    Example (on PPC CHRP LongTrail):
>
>	callisto$ cat /proc/bus/isa/map
>	f8000000	01000000	IO
>	f7000000	01000000	MEM
>	callisto$

Looks fine except for one thing: How can we handle weird HW (like Apple
Uni-N bridge) that has actually 3 different IO spaces at different
locations (all of them beeing childs of the same PCI bus).
This is more or less related since the ISA iospace can be considered as a
subset of the PCI IO space. The problem is generic (it happens with both
"pure" PCI drivers doing IOs and ISA drivers doing IOs). The problem
exist for both the kernel and userland apps like XFree wanting to do PCI
or ISA IOs. The kernel has a built-in IO-base, your patch would expose it
to userland fixing part of the problem for XFree (so userland don't have
to probe for zillion different bridges) but wouldn't solve the problem of
multiple busses.

Paul suggested mapping them one after each other in a single contiguous
region (with the appropriate fixup in the kernel PCI io resources) but
this can work only for PCI IOs (drivers using the io resource base).
Drivers hard-coding legacy IO addresses will still not work (except if
they are on the first bus).

We still can decide (and that's what I currently do in the kernel) that
IO space is only supported on one of those 3 busses (the one on which the
external PCI is). This prevents however use of IOs on the AGP slot, which
is a problem for things like XFree who may try to use VGA addresses on
the card.

I still don't have a clue about a good solution to this issue. Apple
solves it in their kernel by having an object oriented bus structure,
each device asking for mappings to their parent bridge, based on the
device tree and independently of PCI bus numbers.

Ben.

Re: Proposal: non-PC ISA bus support

[Geert Uytterhoeven]

On Tue, 20 Jun 2000, Benjamin Herrenschmidt wrote:
> On Tue, Jun 20, 2000, Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
> wrote:
> 
> > 1. Provide /proc/bus/isa/map, which contains the ISA I/O and memory space
> >    mappings on machines where these are memory mapped.
> >
> >    Example (on PPC CHRP LongTrail):
> >
> >	callisto$ cat /proc/bus/isa/map
> >	f8000000	01000000	IO
> >	f7000000	01000000	MEM
> >	callisto$
> 
> Looks fine except for one thing: How can we handle weird HW (like Apple
> Uni-N bridge) that has actually 3 different IO spaces at different
> locations (all of them beeing childs of the same PCI bus).

AFAIK this is a violation of the PCI spec. But of course that doesn't help you
much.

> This is more or less related since the ISA iospace can be considered as a
> subset of the PCI IO space. The problem is generic (it happens with both
> "pure" PCI drivers doing IOs and ISA drivers doing IOs). The problem
> exist for both the kernel and userland apps like XFree wanting to do PCI
> or ISA IOs. The kernel has a built-in IO-base, your patch would expose it
> to userland fixing part of the problem for XFree (so userland don't have
> to probe for zillion different bridges) but wouldn't solve the problem of
> multiple busses.
> 
> Paul suggested mapping them one after each other in a single contiguous
> region (with the appropriate fixup in the kernel PCI io resources) but
> this can work only for PCI IOs (drivers using the io resource base).
> Drivers hard-coding legacy IO addresses will still not work (except if
> they are on the first bus).

Concatenating the I/O spaces seems like the best solution to me as well.

> We still can decide (and that's what I currently do in the kernel) that
> IO space is only supported on one of those 3 busses (the one on which the
> external PCI is). This prevents however use of IOs on the AGP slot, which
> is a problem for things like XFree who may try to use VGA addresses on
> the card.

> I still don't have a clue about a good solution to this issue. Apple
> solves it in their kernel by having an object oriented bus structure,
> each device asking for mappings to their parent bridge, based on the
> device tree and independently of PCI bus numbers.

Hmmm... If you can live with only one video card with legacy support, what
about a kernel option to specify which of the 3 busses will be the first?

Else, we'll have to work around this in XFree86.

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: Proposal: non-PC ISA bus support

[Benjamin Herrenschmidt]

On Tue, Jun 20, 2000, Geert Uytterhoeven <geert@linux-m68k.org> wrote:

>Concatenating the I/O spaces seems like the best solution to me as well.

Would work if the ranges you are passing via /proc/bus/isa/xxxx are
kernel virtual addresses and not physical addresses (I didn't check if
this is the case).

>Hmmm... If you can live with only one video card with legacy support, what
>about a kernel option to specify which of the 3 busses will be the first?

I've been thinking about it. That would be a solution. Also, the fbdev's
we use for cards in the AGP slot (ATI Rage 128 for now) can handle this
fine, and XFree has already been more or less hacked when to handle it
too when running on top of fbdev.

>Else, we'll have to work around this in XFree86.

Well, we'll have to find a workaround one way or another. The only
solution I can see for this problem is a way for each individual card
driver to "ask" the kernel for an iobase which is specific to this card,
given in parameter as much infos as the driver can regarding the device
(like the pci_dev for a pci device). The kernel would then be able to
locate the device in the OF tree, walk the tree up to the nearest brige
and figure out the correct IO range. (It already does something similar
for config space accesses since we have the same problem of 3 different
config space access registers). For in-kernel drivers, this can be done
at the PCI fixup level provided that the driver uses the io resources
given to it "as is", but exposing this to userland may require more than
a /proc entry.

Ben.

Re: Proposal: non-PC ISA bus support

[Geert Uytterhoeven]

On Tue, 20 Jun 2000, Benjamin Herrenschmidt wrote:
> On Tue, Jun 20, 2000, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> 
> >Concatenating the I/O spaces seems like the best solution to me as well.
> 
> Would work if the ranges you are passing via /proc/bus/isa/xxxx are
> kernel virtual addresses and not physical addresses (I didn't check if
> this is the case).

Oops, /proc/bus/isa/map talks about physical addresses.

Workaround: patch the mmap() entry of /dev/mem.

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: Proposal: non-PC ISA bus support

[De Schrijver Peter]

Hi,

> We still can decide (and that's what I currently do in the kernel) that
> IO space is only supported on one of those 3 busses (the one on which the
> external PCI is). This prevents however use of IOs on the AGP slot, which
> is a problem for things like XFree who may try to use VGA addresses on
> the card.
> 

Is this really a problem ? I would expect AGP cards to be fully addresseable via 
the I/O space assigned in the PCI IO resource base ?

Peter.

Re: Proposal: non-PC ISA bus support

[Benjamin Herrenschmidt]

On Tue, Jun 20, 2000, De Schrijver Peter <schrijvp@rc.bel.alcatel.be> wrote:

>> We still can decide (and that's what I currently do in the kernel) that
>> IO space is only supported on one of those 3 busses (the one on which the
>> external PCI is). This prevents however use of IOs on the AGP slot, which
>> is a problem for things like XFree who may try to use VGA addresses on
>> the card.
>> 
>
>Is this really a problem ? I would expect AGP cards to be fully
>addresseable via 
>the I/O space assigned in the PCI IO resource base ?

But even that doesn't work. If it's a kernel driver, then we can fixup
the io resources passed by the new kernel resources mecanism to handle
the IO base of this specific card. But this won't for userland.

I mean, if you read the PCI IO resource base from the card's config
space, then you have an IO address on which you need to add an iobase
(the base at which the IO bus is mapped). The problem is how to figure
out this IO base, especially since the machine has several IO busses at
different addresses, but all of them on the same PCI bus number (it's
actually 3 separate busses with the same bus number).

The kernel can figure this out from the dev_fn since there's fortunately
no overlap of dev_fn's between those busses. But how to translate this to
userland ?

Ben.

Re: Proposal: non-PC ISA bus support

[Michel Lanners]

Hi all,

On  20 Jun, this message from Benjamin Herrenschmidt echoed through cyberspace:
> We still can decide (and that's what I currently do in the kernel) that
> IO space is only supported on one of those 3 busses (the one on which the
> external PCI is). This prevents however use of IOs on the AGP slot,

... and multiple host bridges, like on the 9x00 (bad, two separate buses
    à 3 slots) and 7x00/8x00 (no problem, second (fixed, video
    subsys) bus doesn't have IO devices).

struct pci_dev has void *sysdata. Can we use that for something
reasonable here? Like additional info (iobase per device, set by fixup
code)?

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "

Re: Proposal: non-PC ISA bus support

[Frank Rowand]

Geert Uytterhoeven wrote:
> 
> The following patch fixes 2 problems related to ISA bus access on non-PC
> platforms:
> 
>  1. ISA I/O space is memory mapped on many platforms (e.g. PPC and MIPS). To
>     access it from user space, you cannot plainly use inb() and friends like on
>     PC, but you have to mmap() the correct region of /dev/mem first. This
>     region depends on the machine type and currently there's no simple way to
>     find out from user space.
> 
>  2. ISA memory is not located at physical address 0 on many platforms (e.g. PPC
>     and some MIPS boxes). This means you cannot e.g. use
>     request_mem_region(0xa0000, 65536) to request the legacy VGA region.
> 
> Solutions:
> 
>  1. Provide /proc/bus/isa/map, which contains the ISA I/O and memory space
>     mappings on machines where these are memory mapped.
> 
>     Example (on PPC CHRP LongTrail):
> 
>         callisto$ cat /proc/bus/isa/map
>         f8000000        01000000        IO
>         f7000000        01000000        MEM
>         callisto$
> 
>     The region marked `IO' is ISA (also PCI) I/O space, while the region marked
>     `MEM' is ISA memory space. Of course on a PC the first one is not
>     available because there are separate I/O and memory spaces on ia32.
> 
>  2. Provide new resource management functions for ISA memory space:
> 
>         isa_request_mem_region()
>         isa_check_mem_region()
>         isa_release_mem_region()
> 
>     On ia32, these are identical to the normal memory resource management
>     functions.
> 
>     [ Alternatively we could add tests to the *_mem_region() functions to test
>       whether the requested region is < 16 MB (and thus in ISA memory space)
>       and add the required offset. But this affects the common resource code
>       and may cause problems on machines where there is no ISA space in the
>       first 16 MB of memory space. ]
> 
> The patch contains support for ia32, PPC and MIPS (limited to DDB Vrc-5074).
> It was tested on PPC only.
> 
> Comments are welcomed!

Would it make sense to apply the same sort of fix to the following code in
__ioremap(), so that ISA space is handled consistently?:

        /*
         * If the address lies within the first 16 MB, assume it's in ISA
         * memory space
         */
        if (p < 16*1024*1024)
            p += _ISA_MEM_BASE;


< patch deleted >


> 
> 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
> 
> ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

-Frank
-- 
Frank Rowand <frank_rowand@mvista.com>
MontaVista Software, Inc

Re: Proposal: non-PC ISA bus support

[Geert Uytterhoeven]

On Tue, 20 Jun 2000, Frank Rowand wrote:
> Geert Uytterhoeven wrote:
> > The following patch fixes 2 problems related to ISA bus access on non-PC
> > platforms:

    [...]

> Would it make sense to apply the same sort of fix to the following code in
> __ioremap(), so that ISA space is handled consistently?:
> 
>         /*
>          * If the address lies within the first 16 MB, assume it's in ISA
>          * memory space
>          */
>         if (p < 16*1024*1024)
>             p += _ISA_MEM_BASE;

Yes. I added that correction because the NVRAM driver wants to ioremap() the 
NVRAM region as reported by the OF device tree, while on CHRP boxes with PC
style NVRAM, it's in ISA memory space at 0xe0000 (`nvram@me0000', according to
OF).

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: Proposal: non-PC ISA bus support

[Russell King]

Geert Uytterhoeven writes:
>  1. ISA I/O space is memory mapped on many platforms (e.g. PPC and MIPS). To
>     access it from user space, you cannot plainly use inb() and friends like on
>     PC, but you have to mmap() the correct region of /dev/mem first. This
>     region depends on the machine type and currently there's no simple way to
>     find out from user space.

We've already solved this on ARM.  Check out arch/arm/kernel/isa.c
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |         Russell King        rmk@arm.linux.org.uk      --- ---
  | | | |   http://www.arm.linux.org.uk/~rmk/aboutme.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |

Re: Proposal: non-PC ISA bus support

[Russell King]

Geert Uytterhoeven writes:
>  1. ISA I/O space is memory mapped on many platforms (e.g. PPC and MIPS). To
>     access it from user space, you cannot plainly use inb() and friends like on
>     PC, but you have to mmap() the correct region of /dev/mem first. This
>     region depends on the machine type and currently there's no simple way to
>     find out from user space.

We've already solved this on ARM.  Check out arch/arm/kernel/isa.c
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |         Russell King        rmk@arm.linux.org.uk      --- ---
  | | | |   http://www.arm.linux.org.uk/~rmk/aboutme.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |

Re: Proposal: non-PC ISA bus support

[Richard Henderson]

On Tue, Jun 20, 2000 at 01:21:10PM +0200, Geert Uytterhoeven wrote:
>1. ISA I/O space is memory mapped on many platforms (e.g. PPC and MIPS). To
>   access it from user space, you cannot plainly use inb() and friends like on
>   PC, but you have to mmap() the correct region of /dev/mem first. This
>   region depends on the machine type and currently there's no simple way to
>   find out from user space.

You may wish to examine the pciconfig_iobase syscall used on Alpha.
It can be used to solve the multiple independant pci bus problem
as well as the ISA base address problem.

>2. ISA memory is not located at physical address 0 on many platforms (e.g. PPC
>   and some MIPS boxes). This means you cannot e.g. use
>   request_mem_region(0xa0000, 65536) to request the legacy VGA region.

This can be fiddled.  Basicly, you pretend that 0 is the base address,
then use ioremap to shift everything up into place.  This assumes that
the ISA bus is contained within exactly one PCI hose.


r~

Re: Proposal: non-PC ISA bus support

[Geert Uytterhoeven]

On Wed, 21 Jun 2000, Richard Henderson wrote:
> On Tue, Jun 20, 2000 at 01:21:10PM +0200, Geert Uytterhoeven wrote:
> >1. ISA I/O space is memory mapped on many platforms (e.g. PPC and MIPS). To
> >   access it from user space, you cannot plainly use inb() and friends like on
> >   PC, but you have to mmap() the correct region of /dev/mem first. This
> >   region depends on the machine type and currently there's no simple way to
> >   find out from user space.
> 
> You may wish to examine the pciconfig_iobase syscall used on Alpha.
> It can be used to solve the multiple independant pci bus problem
> as well as the ISA base address problem.

Thanks! I'll take a look at it...

> >2. ISA memory is not located at physical address 0 on many platforms (e.g. PPC
> >   and some MIPS boxes). This means you cannot e.g. use
> >   request_mem_region(0xa0000, 65536) to request the legacy VGA region.
> 
> This can be fiddled.  Basicly, you pretend that 0 is the base address,
> then use ioremap to shift everything up into place.  This assumes that

But with ioremap() you cannot specify where it has to be mapped, right? So
you're still stuck with an offset.

Besides, request_mem_region(0xa0000, 65536) will fail on my box anyway because
I already have some memory resources requested at address 0.

> the ISA bus is contained within exactly one PCI hose.

Which is not the case on some boxes :-(

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: Proposal: non-PC ISA bus support

[Richard Henderson]

On Thu, Jun 22, 2000 at 08:45:47AM +0200, Geert Uytterhoeven wrote:
> But with ioremap() you cannot specify where it has to be mapped, right? So
> you're still stuck with an offset.

Huh?  Who cares where it's mapped.  "Some unused space."
A pointer is a pointer.

In my case there is a direct correlation between the "base address"
and the "ioremaped address" -- the addition of a constant.  That's
the win for using 64-bit pointers.  ;-)

> > the ISA bus is contained within exactly one PCI hose.
> 
> Which is not the case on some boxes :-(

The only machines I knew about that had this were the DEC NUMA
machines.  What does your bus configuration look like?


r~

Re: Proposal: non-PC ISA bus support

[Geert Uytterhoeven]

On Thu, 22 Jun 2000, Richard Henderson wrote:
> On Thu, Jun 22, 2000 at 08:45:47AM +0200, Geert Uytterhoeven wrote:
> > But with ioremap() you cannot specify where it has to be mapped, right? So
> > you're still stuck with an offset.
> 
> Huh?  Who cares where it's mapped.  "Some unused space."
> A pointer is a pointer.
> 
> In my case there is a direct correlation between the "base address"
> and the "ioremaped address" -- the addition of a constant.  That's
> the win for using 64-bit pointers.  ;-)

I think we're talking about something different. I don't care about the pointer
nor the ioremap() neither (we explicitly map it in MMU_init()).

The problem is that drivers assume ISA memory space is at 0 and use e.g.

    request_mem_region(0xa0000, 65536)
    
to request the legacy VGA region, while it should be

    request_mem_region(isa_mem_base+0xa0000, 65536)

for compatibility with anything besides ia32.

> > > the ISA bus is contained within exactly one PCI hose.
> > 
> > Which is not the case on some boxes :-(
> 
> The only machines I knew about that had this were the DEC NUMA
> machines.  What does your bus configuration look like?

There are multiple legacy ISA regions on some PowerMacs, which have multiple
PCI buses and such.

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: Proposal: non-PC ISA bus support

[Richard Henderson]

On Thu, Jun 22, 2000 at 09:41:58AM +0200, Geert Uytterhoeven wrote:
> The problem is that drivers assume ISA memory space is at 0 and use e.g.
> 
>     request_mem_region(0xa0000, 65536)
>     
> to request the legacy VGA region, while it should be
> 
>     request_mem_region(isa_mem_base+0xa0000, 65536)
> 
> for compatibility with anything besides ia32.

Well, yes and no.  Again, what I'm saying is that one way
to handle this is to *pretend* isa_mem_base==0, and that
the entire ISA region is contiguous.  Certainly that's good
enough for region allocations.  And if the damage is undone
by ioremap, then the effect is not visible.

I'm not disagreeing that it would make sense to make this
all a bit more explicit with proper interfaces.  However,
I don't see that happening any time real soon.

> > What does your bus configuration look like?
> 
> There are multiple legacy ISA regions on some PowerMacs, which
> have multiple PCI buses and such.

I guessed that.  I was hoping to get specifics.


r~

Re: Proposal: non-PC ISA bus support

[Geert Uytterhoeven]

On Thu, 22 Jun 2000, Richard Henderson wrote:

> On Thu, Jun 22, 2000 at 09:41:58AM +0200, Geert Uytterhoeven wrote:
> > The problem is that drivers assume ISA memory space is at 0 and use e.g.
> > 
> >     request_mem_region(0xa0000, 65536)
> >     
> > to request the legacy VGA region, while it should be
> > 
> >     request_mem_region(isa_mem_base+0xa0000, 65536)
> > 
> > for compatibility with anything besides ia32.
> 
> Well, yes and no.  Again, what I'm saying is that one way
> to handle this is to *pretend* isa_mem_base==0, and that
> the entire ISA region is contiguous.  Certainly that's good
> enough for region allocations.  And if the damage is undone
> by ioremap, then the effect is not visible.

That works only if there's nothing else at address 0 that keeps the resource
busy.

> I'm not disagreeing that it would make sense to make this
> all a bit more explicit with proper interfaces.  However,
> I don't see that happening any time real soon.

Hence my proposal for isa_request_mem_region(). It allows platform specific
code to take care of both the base address and the sparsity (if needed).

> > > What does your bus configuration look like?
> > 
> > There are multiple legacy ISA regions on some PowerMacs, which
> > have multiple PCI buses and such.
> 
> I guessed that.  I was hoping to get specifics.

Benjamin Herrenschmidt <bh40@calva.net> can tell you more about it.

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