x86_64: permit to configure ISA support also for x86_64 systems

PATCH In review Wolfgang Grandegger 5 participants 12 messages Sep 16, 2011 – Sep 22, 2011 x86

Share & tools

Wolfgang Grandegger

author

2011-09-16 09:22 UTC #0 lore raw

PATCH 1/1 x86_64: permit to configure ISA support also for x86_64 systems

There are 64-bit systems out there, like the ATOM N450, which have ISA slots. This patch is necessary to get the "sja1000_isa" Socket-CAN driver working on such systems.

Signed-off-by Wolfgang Grandegger <[email protected]>

---
 arch/x86/Kconfig |    5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

arch/x86/Kconfig +2 -3

index 6a47bb2..08ee2d4 100644
@@ -1947,7 +1947,6 @@ source "drivers/pci/pcie/Kconfig"
 
 source "drivers/pci/Kconfig"
 
-# x86_64 have no ISA slots, but can have ISA-style DMA.
 config ISA_DMA_API
 	bool "ISA-style DMA support" if (X86_64 && EXPERT)
 	default y

@@ -1955,8 +1954,6 @@ config ISA_DMA_API
 	  Enables ISA-style DMA support for devices requiring such controllers.
 	  If unsure, say Y.
 
-if X86_32
-
 config ISA
 	bool "ISA support"
 	---help---

@@ -1966,6 +1963,8 @@ config ISA
 	  (MCA) or VESA.  ISA is an older system, now being displaced by PCI;
 	  newer boards don't support it.  If you have ISA, say Y, otherwise N.
 
+if X86_32
+
 config EISA
 	bool "EISA support"
 	depends on ISA

Signature · 1 line

1.7.4.1

[email protected]

2011-09-16 19:20 UTC #1 lore raw

Quoted 2 lines · Wolfgang Grandegger

There are 64-bit systems out there, like the ATOM N450, which have ISA slots.

That's a scary thought...

arch/x86/Kconfig config ISA · line 1968

Quoted 3 lines

arch/x86/Kconfig +2 -0
+if X86_32
+
 config EISA

But not as scary as the implication that the N450 has ISA but *not* EISA??!?

Wolfgang Grandegger

author

2011-09-16 19:31 UTC #2 lore raw

Quoted 5 lines · On 09/16/2011 09:19 PM, [email protected] wrote:

Quoted 2 lines · Wolfgang Grandegger
There are 64-bit systems out there, like the ATOM N450, which have ISA slots.
That's a scary thought...

Well. Actually we need it for Intel Atom N450 PC/104-Plus SBCs.

Quoted 6 lines

arch/x86/Kconfig config ISA · line 1968
Quoted 4 lines
arch/x86/Kconfig +2 -0
+if X86_32
+
 config EISA
But not as scary as the implication that the N450 has ISA but *not* EISA??!?

Ok, then I will allow EISA as well.

Wolfgang.

Arnd Bergmann

2011-09-20 15:47 UTC #3 lore raw

Quoted 8 lines · Wolfgang Grandegger

Quoted 5 lines · On 09/16/2011 09:19 PM, [email protected] wrote:
Quoted 2 lines · Wolfgang Grandegger
There are 64-bit systems out there, like the ATOM N450, which have ISA slots.
That's a scary thought...
Well. Actually we need it for Intel Atom N450 PC/104-Plus SBCs.

I would assume that you have a small set of ISA add-on cards that you actually need to support, right?

Since most ISA drivers don't actually use isa_register_driver (for good or bad), how about changing the Kconfig entry for the ones you need to 'depends on ISA || PLAT_GRANDEGGER_PC104_ATOM' or similar?

Arnd

Wolfgang Grandegger

author

2011-09-21 08:33 UTC #4 lore raw

Quoted 6 lines · Arnd Bergmann

Quoted 5 lines · Wolfgang Grandegger
Quoted 4 lines · On 09/16/2011 09:19 PM, [email protected] wrote:
Quoted 2 lines · Wolfgang Grandegger
There are 64-bit systems out there, like the ATOM N450, which have ISA slots.

Quoted 6 lines

Quoted 3 lines
Quoted 1 line
That's a scary thought...
Well. Actually we need it for Intel Atom N450 PC/104-Plus SBCs.
I would assume that you have a small set of ISA add-on cards that you actually need to support, right?

Yes, various PC/104 compatible boards can be connected to the ISA bus on such systems (via PC/104 connector). I personally do only care about the CAN devices (as maintainer).

Quoted 4 lines

Since most ISA drivers don't actually use isa_register_driver (for good or bad), how about changing the Kconfig entry for the ones you need to 'depends on ISA || PLAT_GRANDEGGER_PC104_ATOM' or similar?

What should the PLAT_GRANDEGGER_PC104_ATOM be good for? If I replace isa_register_driver() with platform_driver_register(), like the serial 8250 driver does, HAS_IOMEM should be just fine. This would then also avoid the 64-bit trouble expected with old ISA drivers (enabled via ISA). Or have I missed something?

Wolfgang.

Arnd Bergmann

2011-09-21 09:25 UTC #5 lore raw

Quoted 11 lines · On Wednesday 21 September 2011 10:33:10 Wolfgang Grandegger wrote:

Quoted 5 lines
Since most ISA drivers don't actually use isa_register_driver (for good or bad), how about changing the Kconfig entry for the ones you need to 'depends on ISA || PLAT_GRANDEGGER_PC104_ATOM' or similar?
What should the PLAT_GRANDEGGER_PC104_ATOM be good for? If I replace isa_register_driver() with platform_driver_register(), like the serial 8250 driver does, HAS_IOMEM should be just fine. This would then also avoid the 64-bit trouble expected with old ISA drivers (enabled via ISA). Or have I missed something?

I was thinking of the drivers that are for ISA cards but don't actually use the isa_register_driver() function. If you have to change the driver to a platform driver, you are right.

The other point is that you are probably using inb/outb operations, which I'm trying to provide only on ISA/PCMCIA/PCI based systems in the future. Once I finish that work, you will also need to depend on HAS_IOPORT (which currently means something else).

Arnd

Andi Kleen

2011-09-21 22:13 UTC #6 lore raw

Quoted 5 lines · Arnd Bergmann

The other point is that you are probably using inb/outb operations, which I'm trying to provide only on ISA/PCMCIA/PCI based systems in the future. Once I finish that work, you will also need to depend on HAS_IOPORT (which currently means something else).

What does that mean? Most PCs need at least some ioport usage during boot.

-Andi

Signature · 1 line

[email protected] -- Speaking for myself only

Wolfgang Grandegger

author

2011-09-22 06:43 UTC #7 lore raw

In reply to Arnd Bergmann

Quoted 13 lines · Arnd Bergmann

Quoted 11 lines · On Wednesday 21 September 2011 10:33:10 Wolfgang Grandegger wrote:
Quoted 5 lines
Since most ISA drivers don't actually use isa_register_driver (for good or bad), how about changing the Kconfig entry for the ones you need to 'depends on ISA || PLAT_GRANDEGGER_PC104_ATOM' or similar?
What should the PLAT_GRANDEGGER_PC104_ATOM be good for? If I replace isa_register_driver() with platform_driver_register(), like the serial 8250 driver does, HAS_IOMEM should be just fine. This would then also avoid the 64-bit trouble expected with old ISA drivers (enabled via ISA). Or have I missed something?

Quoted 3 lines

I was thinking of the drivers that are for ISA cards but don't actually use the isa_register_driver() function. If you have to change the driver to a platform driver, you are right.

OK, then I will finally convert the sja1000_isa driver to a platform driver instead of allowing CONFIG_ISA for x86_64.

Quoted 4 lines

The other point is that you are probably using inb/outb operations, which I'm trying to provide only on ISA/PCMCIA/PCI based systems in the future. Once I finish that work, you will also need to depend on HAS_IOPORT (which currently means something else).

OK, the sja1000_isa driver just uses memory mapped access.

Wolfgang.

Arnd Bergmann

2011-09-22 14:20 UTC #8 lore raw

Quoted 8 lines · Wolfgang Grandegger

Quoted 5 lines · Arnd Bergmann
On Wednesday 21 September 2011 10:33:10 Wolfgang Grandegger wrote:
The other point is that you are probably using inb/outb operations, which I'm trying to provide only on ISA/PCMCIA/PCI based systems in the future. Once I finish that work, you will also need to depend on HAS_IOPORT (which currently means something else).
OK, the sja1000_isa driver just uses memory mapped access.

According to this it uses both PIO and MMIO:

$ git grep '\(in\|out\|read\|write\)\(b\|w\|l\)' drivers/net/can/sja1000/sja1000_isa.c 
drivers/net/can/sja1000/sja1000_isa.c:  return readb(priv->reg_base + reg);
drivers/net/can/sja1000/sja1000_isa.c:  writeb(val, priv->reg_base + reg);
drivers/net/can/sja1000/sja1000_isa.c:  return inb((unsigned long)priv->reg_base + reg);
drivers/net/can/sja1000/sja1000_isa.c:  outb(val, (unsigned long)priv->reg_base + reg);
drivers/net/can/sja1000/sja1000_isa.c:  outb(reg, base);
drivers/net/can/sja1000/sja1000_isa.c:  return inb(base + 1);
drivers/net/can/sja1000/sja1000_isa.c:  outb(reg, base);
drivers/net/can/sja1000/sja1000_isa.c:  outb(val, base + 1);

But don't worry about it, I'll make the right Kconfig annotation when I submit my patches.

Arnd

Wolfgang Grandegger

author

2011-09-22 14:57 UTC #9 lore raw

Quoted 12 lines · Arnd Bergmann

Quoted 8 lines · Wolfgang Grandegger
Quoted 5 lines · Arnd Bergmann
On Wednesday 21 September 2011 10:33:10 Wolfgang Grandegger wrote:
The other point is that you are probably using inb/outb operations, which I'm trying to provide only on ISA/PCMCIA/PCI based systems in the future. Once I finish that work, you will also need to depend on HAS_IOPORT (which currently means something else).
OK, the sja1000_isa driver just uses memory mapped access.
According to this it uses both PIO and MMIO:

Quoted 9 lines

$ git grep '\(in\|out\|read\|write\)\(b\|w\|l\)' drivers/net/can/sja1000/sja1000_isa.c 
drivers/net/can/sja1000/sja1000_isa.c:  return readb(priv->reg_base + reg);
drivers/net/can/sja1000/sja1000_isa.c:  writeb(val, priv->reg_base + reg);
drivers/net/can/sja1000/sja1000_isa.c:  return inb((unsigned long)priv->reg_base + reg);
drivers/net/can/sja1000/sja1000_isa.c:  outb(val, (unsigned long)priv->reg_base + reg);
drivers/net/can/sja1000/sja1000_isa.c:  outb(reg, base);
drivers/net/can/sja1000/sja1000_isa.c:  return inb(base + 1);
drivers/net/can/sja1000/sja1000_isa.c:  outb(reg, base);
drivers/net/can/sja1000/sja1000_isa.c:  outb(val, base + 1);

Ah, oh, I forgot. The driver supports both, I/O port and memory mapped access.

Quoted 2 lines

But don't worry about it, I'll make the right Kconfig annotation when I submit my patches.

OK,

Wolfgang.

Calvin Walton

2011-09-18 23:19 UTC #10 lore raw

In reply to [email protected]

Quoted 11 lines · On Fri, 2011-09-16 at 15:19 -0400, [email protected] wrote:

Quoted 2 lines · Wolfgang Grandegger
There are 64-bit systems out there, like the ATOM N450, which have ISA slots.
That's a scary thought...
arch/x86/Kconfig config ISA · line 1968
Quoted 3 lines
arch/x86/Kconfig +2 -0
+if X86_32
+
 config EISA
But not as scary as the implication that the N450 has ISA but *not* EISA??!?

Don't get confused, EISA is a completely different bus from ISA! Take a look at
http://en.wikipedia.org/wiki/Extended_Industry_Standard_Architecture
The ports are physically different from standard ISA (although they are backwards compatible), and it requires some complicated BIOS configuration for cards to be detected... I've only ever seen it once on an old 486 portable computer. (The BIOS battery had gone, so it lost its EISA configuration info, and wouldn't boot because it failed to detect the IDE controller.)

The Atom N450 board that Wolfgang has almost certainly does not support EISA.

Calvin

Signature · 1 line

Calvin Walton <[email protected]>

Andi Kleen

2011-09-16 22:33 UTC #11 lore raw

In reply to Wolfgang Grandegger

Quoted 3 lines · Wolfgang Grandegger

There are 64-bit systems out there, like the ATOM N450, which have ISA slots. This patch is necessary to get the "sja1000_isa" Socket-CAN driver working on such systems.

Really bad idea.

You'll get a zillion non 64bit safe unmaintained old ISA drivers then, a non trivial percentage of them will likely explode when just loaded.

Not to speak of the warning load at allyesconfig builds.

Maybe define a ISA_64 or so.

But it's really a bad idea.

-Andi

Signature · 1 line

[email protected] -- Speaking for myself only