Various PMac PCI patches

Various PMac PCI patches

[Michel Lanners]

[-- Attachment #1: Type: TEXT/plain, Size: 1920 bytes --]

Hi all,

Here are some PMac PCI patches and fixes:

1. On the PowerMac, OpenBugware explicitly ignores PCI_INTERRUPT_LINE.
However, a quick grep shows that numerous drivers rely on its value for
driver initialization. Therefore, I've added a config_write to the
existing IRQ fixup code, so that the IRQ gets written back into
the PCI config register. By the way, the fixup function (fix_intr) is
in a general file (pci.c), but only called from PMac-specific code. 

Can those of you with PCI add-on boards see if this breaks anything?

Patch is below (pci.c-patch).

Andre: not sure, but this might have helped for the Promise as well...

2. I've hacked pmac_pcibios_fixup with a few changes:

- It now checks for PCI buses other than the first one, on all bridges.
This should help on the 7x00/8x00 machines (bandit and chaos host
bridges) as well as on the 9x00 (two bandit bridges; second bus would
be invisible up to now). If anyone has a 9x00, can  you test if this
works? For me it only detects one of two devices on bus 1....

- The IRQ fixup code already checks for the presence of interrupts, so
I'v changed Martin's comment. Also, I'm not sure if PMac PCI boards can
ever use more than one interrupt, as all PCI interrupt lines are OR'ed
together on the bridge....

- I've added IO and memory space enable code from i386's fixup code,
minus some port address checks.This should be safe on all concerned
machines.

Patch for all this is below (pmac_pci.c-patch).

If no one objects to these patches, who volounteers to get them into
the mainstream? ;-)

Thanks

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

[-- Attachment #2: pci.c-patch --]
[-- Type: TEXT/plain, Size: 438 bytes --]

--- linux/arch/ppc/kernel/pci.c	Sat Aug  7 17:09:25 1999
+++ linux-ideok/arch/ppc/kernel/pci.c	Sun Aug  8 22:01:36 1999
@@ -100,8 +100,10 @@
 		if (reg == 0 || ((reg[0] >> 8) & 0xff) != dev->devfn)
 			continue;
 		/* this is the node, see if it has interrupts */
-		if (node->n_intrs > 0) 
+		if (node->n_intrs > 0) {
 			dev->irq = node->intrs[0].line;
+			pci_write_config_byte(dev,PCI_INTERRUPT_LINE, dev->irq);
+		}
 		break;
 	}
 }

[-- Attachment #3: pmac_pci.c-patch --]
[-- Type: TEXT/plain, Size: 3204 bytes --]

--- linux/arch/ppc/kernel/pmac_pci.c	Sat Aug  7 17:09:25 1999
+++ linux-ideok/arch/ppc/kernel/pmac_pci.c	Sun Aug  8 22:25:57 1999
@@ -17,6 +17,7 @@
 #include <linux/delay.h>
 #include <linux/string.h>
 #include <linux/init.h>
+#include <linux/malloc.h>
 #include <asm/io.h>
 #include <asm/pgtable.h>
 #include <asm/prom.h>
@@ -447,18 +448,36 @@
 pmac_pcibios_fixup(void))
 {
 	struct pci_dev *dev;
-	
+	int i, has_io, has_mem;
+	unsigned short cmd;
+       	struct bridge_data *bp;
+
+	for (bp = bridge_list; bp != NULL; bp = bp->next) {
+		struct pci_bus *b;
+
+		if (bp->bus_number == 0) continue;
+
+		b = kmalloc(sizeof(struct pci_bus), GFP_KERNEL);
+		memset(b, 0, sizeof(*b));
+		b->next = pci_root.next;
+		pci_root.next = b;
+		b->number = b->secondary = bp->bus_number;
+		b->subordinate = 0xff;
+		b->subordinate = pci_scan_bus(b);
+	}
+
 	/*
-	 * FIXME: This is broken: We should not assign IRQ's to IRQless
-	 *	  devices (look at PCI_INTERRUPT_PIN) and we also should
-	 *	  honor the existence of multi-function devices where
-	 *	  different functions have different interrupt pins. [mj]
+	 * FIXME: This is broken: We should honor the existence of multi-
+	 *	  function devices where different functions have different
+	 *	  interrupt pins. [mj]
+	 *	  Not sure if on the PMac, a single PCI slot can generate
+	 *	  more than one interrupt... [mlan]
 	 */
 	for(dev=pci_devices; dev; dev=dev->next)
 	{
 		/*
-		 * Open Firmware often doesn't initialize the,
-		 * PCI_INTERRUPT_LINE config register properly, so we
+		 * Open Firmware doesn't initialize the
+		 * PCI_INTERRUPT_LINE config register, so we
 		 * should find the device node and se if it has an
 		 * AAPL,interrupts property.
 		 */
@@ -469,6 +488,45 @@
 		    !pin)
 			continue; /* No interrupt generated -> no fixup */
                 fix_intr(bp->node->child, dev);
+
+		/*
+		 * Open Firmware does not enable I/O and memory space
+		 * response on PCI devices. We try to fix this, but we need to
+		 * be sure that the BIOS didn't forget to assign an address
+		 * to the device. [mj]
+		 */
+		has_io = has_mem = 0;
+		for(i=0; i<6; i++) {
+			unsigned long a = dev->base_address[i];
+			if (a & PCI_BASE_ADDRESS_SPACE_IO) {
+				has_io = 1;
+			} else if (a & PCI_BASE_ADDRESS_MEM_MASK)
+				has_mem = 1;
+		}
+		/*
+		 * Don't enable VGA-compatible cards since they have
+		 * fixed I/O and memory space.
+		 *
+		 * Don't enabled disabled IDE interfaces either because
+		 * some BIOSes may reallocate the same address when they
+		 * find that no devices are attached.
+		 */
+		if (((dev->class >> 8) != PCI_CLASS_DISPLAY_VGA) &&
+		    ((dev->class >> 8) != PCI_CLASS_STORAGE_IDE)) {
+			pci_read_config_word(dev, PCI_COMMAND, &cmd);
+			if (has_io && !(cmd & PCI_COMMAND_IO)) {
+				printk("PCI: Enabling I/O for device %02x:%02x\n",
+					dev->bus->number, dev->devfn);
+				cmd |= PCI_COMMAND_IO;
+				pci_write_config_word(dev, PCI_COMMAND, cmd);
+			}
+			if (has_mem && !(cmd & PCI_COMMAND_MEMORY)) {
+				printk("PCI: Enabling memory for device %02x:%02x\n",
+					dev->bus->number, dev->devfn);
+				cmd |= PCI_COMMAND_MEMORY;
+				pci_write_config_word(dev, PCI_COMMAND, cmd);
+			}
+		}
 	}
 }
 

Re: Various PMac PCI patches

[Martin Mares]

Hi,

> Here are some PMac PCI patches and fixes:
> 
> 1. On the PowerMac, OpenBugware explicitly ignores PCI_INTERRUPT_LINE.
> However, a quick grep shows that numerous drivers rely on its value for
> driver initialization. Therefore, I've added a config_write to the
> existing IRQ fixup code, so that the IRQ gets written back into
> the PCI config register. By the way, the fixup function (fix_intr) is
> in a general file (pci.c), but only called from PMac-specific code. 

   No driver should touch PCI_INTERRUPT_LINE at all. If it does,
it's buggy and should be fixed instead of working around it in generic
PCI code. The only correct way how to get the interrupt number is to
look at pci_dev->irq (on some architectures, the interrupt numbers
are too large to fit in the interrupt line configuration register).

> 2. I've hacked pmac_pcibios_fixup with a few changes:
> 
> - It now checks for PCI buses other than the first one, on all bridges.
> This should help on the 7x00/8x00 machines (bandit and chaos host
> bridges) as well as on the 9x00 (two bandit bridges; second bus would
> be invisible up to now). If anyone has a 9x00, can  you test if this
> works? For me it only detects one of two devices on bus 1....

   Isn't it possible to search for the bridges directly instead
of scanning the PCI config space?  I see a lot of similarities between
this and the peer host bridge problems on the PC.

> - The IRQ fixup code already checks for the presence of interrupts, so
> I'v changed Martin's comment. Also, I'm not sure if PMac PCI boards can
> ever use more than one interrupt, as all PCI interrupt lines are OR'ed
> together on the bridge....

   If they really are, just kill the whole comment, it's bogus.

> - I've added IO and memory space enable code from i386's fixup code,
> minus some port address checks.This should be safe on all concerned
> machines.

   I'm not sure whether the logic for not enabling VGA and IDE devices
applies to PMAC as well, I think you can just remove it. Also, it would
be better to update the PC-centric comment from my code :)

   The rest looks OK to me.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"Anything is good and useful if it's made of chocolate."

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Various PMac PCI patches

[Michel Lanners]

Hi Martin,

Thanks for your comments. I'll give the PCI patches a bit more work,
including your suggestions below, update to 2.2.11, and resend them.

On  15 Aug, this message from Martin Mares echoed through cyberspace:
>    No driver should touch PCI_INTERRUPT_LINE at all. If it does,
> it's buggy and should be fixed instead of working around it in generic
> PCI code. The only correct way how to get the interrupt number is to
> look at pci_dev->irq (on some architectures, the interrupt numbers
> are too large to fit in the interrupt line configuration register).

OK, then I'll only update pci_dev->irq. We'll see if any driver
breaks ;-)

>> 2. I've hacked pmac_pcibios_fixup with a few changes:
>> 
>> - It now checks for PCI buses other than the first one, on all bridges.
>> This should help on the 7x00/8x00 machines (bandit and chaos host
>> bridges) as well as on the 9x00 (two bandit bridges; second bus would
>> be invisible up to now). If anyone has a 9x00, can  you test if this
>> works? For me it only detects one of two devices on bus 1....
> 
>    Isn't it possible to search for the bridges directly instead
> of scanning the PCI config space?  I see a lot of similarities between
> this and the peer host bridge problems on the PC.

Bridges, yes. But not PCI devices. What I've done is look at all the
bridges found by the platform-specific PCI code (contained in
struct bridge_data bridge_list), and scan any PCI busses off those
bridges (except bus 0, which gets scanned already).

>> - The IRQ fixup code already checks for the presence of interrupts, so
>> I'v changed Martin's comment. Also, I'm not sure if PMac PCI boards can
>> ever use more than one interrupt, as all PCI interrupt lines are OR'ed
>> together on the bridge....
> 
>    If they really are, just kill the whole comment, it's bogus.

OK, I'll do that. Paul, any idea whether the IRQ OR'ing is done on the
MPC106 as well? Geert, what about your board?

>> - I've added IO and memory space enable code from i386's fixup code,
>> minus some port address checks. This should be safe on all concerned
>> machines.
> 
>    I'm not sure whether the logic for not enabling VGA and IDE devices
> applies to PMAC as well, I think you can just remove it.

Probably not; at least on the Macs there's nothing special about VGA,
and I don't think there is any Mac with a built-in IDE controller that
identifies itself as such on the bus; rather they are integrated into
some multi-IO chip.

I'll drop that special case, then.

> Also, it would
> be better to update the PC-centric comment from my code :)

Sure ;-)

>    The rest looks OK to me.

Good!

;-)

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


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Various PMac PCI patches

[Geert Uytterhoeven]

On Sun, 15 Aug 1999, Michel Lanners wrote:
> >> - The IRQ fixup code already checks for the presence of interrupts, so
> >> I'v changed Martin's comment. Also, I'm not sure if PMac PCI boards can
> >> ever use more than one interrupt, as all PCI interrupt lines are OR'ed
> >> together on the bridge....
> > 
> >    If they really are, just kill the whole comment, it's bogus.
> 
> OK, I'll do that. Paul, any idea whether the IRQ OR'ing is done on the
> MPC106 as well? Geert, what about your board?

On the LongTrail, interrupts are controlled by the OpenPIC in the Hydra Mac
I/O. This OpenPic has 20 inputs, of which 6 are used by PCI (asm-ppc/hydra.h):

#define HYDRA_INT_EXT1          12      /* PCI IRQW */
#define HYDRA_INT_EXT2          13      /* PCI IRQX */
#define HYDRA_INT_EXT3          14      /* PCI IRQY */
#define HYDRA_INT_EXT4          15      /* PCI IRQZ */
#define HYDRA_INT_EXT5          16      /* IDE Primay/Secondary */
#define HYDRA_INT_EXT6          17      /* IDE Secondary */

FYI, input 0 is used for the legacy ISA cascade.

IRQ[W-Z] are wired to INT #A-D in the 4 PCI slots using the standard interrupt
line rotating technique. Full schematics at
ftp://ftp.austin.ibm.com/pub/PPC_support/reference_designs/longtrail/ :-)

The IDE interrupts are wired to the interrupt lines on the W83C553 PCI/ISA+IDE.

> >    No driver should touch PCI_INTERRUPT_LINE at all. If it does,
> > it's buggy and should be fixed instead of working around it in generic
> > PCI code. The only correct way how to get the interrupt number is to
> > look at pci_dev->irq (on some architectures, the interrupt numbers
> > are too large to fit in the interrupt line configuration register).
>
> OK, then I'll only update pci_dev->irq. We'll see if any driver
> breaks ;-)

On the LongTrail (and other PPC boxes with OpenPIC), pci_dev->irq is changed by
the PCI fixup code since interrupts 1-16 are mapped to the legacy ISA
interrupts for compatibility reasons, while 17-36 are the 20 OpenPIC
interrupts.

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Various PMac PCI patches

[Ryan Nielsen]

Michel Lanners wrote:
> 2. I've hacked pmac_pcibios_fixup with a few changes:
> 
> - It now checks for PCI buses other than the first one, on all bridges.
> This should help on the 7x00/8x00 machines (bandit and chaos host
> bridges) as well as on the 9x00 (two bandit bridges; second bus would
> be invisible up to now). If anyone has a 9x00, can  you test if this
> works? For me it only detects one of two devices on bus 1....
 
It detects two out of two on mi 9600.

isa_io_base is set to the address of bus 0 !
so inl() and friends use wrong address for cards on bus 1.

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Various PMac PCI patches

[Michel Lanners]

On  19 Aug, this message from Ryan Nielsen echoed through cyberspace:
> Michel Lanners wrote:
>> 2. I've hacked pmac_pcibios_fixup with a few changes:
>> 
>> - It now checks for PCI buses other than the first one, on all bridges.
>> This should help on the 7x00/8x00 machines (bandit and chaos host
>> bridges) as well as on the 9x00 (two bandit bridges; second bus would
>> be invisible up to now). If anyone has a 9x00, can  you test if this
>> works? For me it only detects one of two devices on bus 1....
>  
> It detects two out of two on mi 9600.

Good! I'll give that part of the patch some more polishing (still some
issues with my second bus), and I'll send it out the 'official' way.

> isa_io_base is set to the address of bus 0 !
> so inl() and friends use wrong address for cards on bus 1.

That's expected (and broken) behaviour right now; I know how to correct
the problem, but I need to do some hacking to get it coded right.

Thanks

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


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Various PMac PCI patches

[Ryan Nielsen]

Michel Lanners wrote:
> > isa_io_base is set to the address of bus 0 !
> > so inl() and friends use wrong address for cards on bus 1.
> 
> That's expected (and broken) behaviour right now; I know how to correct
> the problem, but I need to do some hacking to get it coded right.

What are you plannering ?

I got tulip working by #define _IO_BASE DRIVER_IO_BASE (ifdef) in asm/io.h
and define DRIVER_IO_BASE to a value from pci_io_base(bus) in tulip.c

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Various PMac PCI patches

[Michel Lanners]

On  19 Aug, this message from Ryan Nielsen echoed through cyberspace:
> Michel Lanners wrote:
>> > isa_io_base is set to the address of bus 0 !
>> > so inl() and friends use wrong address for cards on bus 1.
>> 
>> That's expected (and broken) behaviour right now; I know how to correct
>> the problem, but I need to do some hacking to get it coded right.
> 
> What are you plannering ?
> 
> I got tulip working by #define _IO_BASE DRIVER_IO_BASE (ifdef) in asm/io.h
> and define DRIVER_IO_BASE to a value from pci_io_base(bus) in tulip.c

Fixing IO space addresses in the kernel pci structs, so that any driver
referencing the pci structs gets the right kernel virtual address for
the  ports without fiddling with _IO_BASE. In fact, it means adding an
offset to the address reported in the PCI device's config registers.
This offset id provided by the parent bus bridge.

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


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Various PMac PCI patches

[Michel Lanners]

[-- Attachment #1: Type: TEXT/plain, Size: 2209 bytes --]

Hi all,

Here is another try for the PMac PCI multi-patch, trying to solve the
mapping problem with IO ports on PCI devices, among others.

What's in the patch:

- scanning of PCI buses on host bridges other than the first one;
- verbose reporting of fixed IRQ numbers, plus a comment change;
- mapping of a bigger PCI IO-space on the bandit host bridge (23 bits
according to Apple's doc) (Comments, Paul? Others?);
- inclusion of i386's PCI fixup code, enabling IO- and memory-space
response on devices that have such spaces, plus the fix for correciong
IO space offset according to the host bridge;
- setting of _IO_BASE to 0, so inb/outb don't do any offset;
- removal of _IO_BASE from ide-pmac.c

Ryan,

On  19 Aug, this message from Ryan Nielsen echoed through cyberspace:
> It detects two out of two on mi 9600.

Can you check this patch still works for you? It should now also
correct the IO-space addresses, so your PCI card should work in both
buses.

To the list, can those with IDE onboard their PMacs check that this
keeps your IDE working?

There is, however, still an issue with PCMCIA on Powerbook machines,
because:

On  25 Aug, this message from Paul Mackerras echoed through cyberspace:
> I guess that's the best approach overall.  Where I can see it failing
> is with things like pcmcia.  You insert a pcmcia modem card (say) and
> the pcmcia code allocates some I/O ports and tells the card to use
> them.

I will have to investigate this problem, and how the card's and the
pcmcia driver's perspective of that IO port address are. We might be
able to base a solution to this problem on the address of the CardBus
bridge's IO space, as found in that bridge's config space (unbiased),
and in its corresponding struct pci_dev (should have offest applied).

As usual, happy patching... and direct your comments and complaints at
my inbox ;-)

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

[-- Attachment #2: 2.2.11-pci-patches --]
[-- Type: TEXT/plain, Size: 6194 bytes --]

diff -uNr linux-2.2.11/arch/ppc/kernel/pci.c linux/arch/ppc/kernel/pci.c
--- linux-2.2.11/arch/ppc/kernel/pci.c	Sun Aug 15 19:54:40 1999
+++ linux/arch/ppc/kernel/pci.c	Sun Aug 22 12:41:31 1999
@@ -99,8 +99,11 @@
 		if (reg == 0 || ((reg[0] >> 8) & 0xff) != dev->devfn)
 			continue;
 		/* this is the node, see if it has interrupts */
-		if (node->n_intrs > 0) 
+		if (node->n_intrs > 0) {
 			dev->irq = node->intrs[0].line;
+			printk ("PCI: setting IRQ %d on device %02x:%02x.\n",
+				dev->irq, dev->bus->number, dev->devfn);
+		}
 		break;
 	}
 }
diff -uNr linux-2.2.11/arch/ppc/kernel/pmac_pci.c linux/arch/ppc/kernel/pmac_pci.c
--- linux-2.2.11/arch/ppc/kernel/pmac_pci.c	Sat Aug  7 17:09:25 1999
+++ linux/arch/ppc/kernel/pmac_pci.c	Tue Aug 24 22:56:14 1999
@@ -17,6 +17,7 @@
 #include <linux/delay.h>
 #include <linux/string.h>
 #include <linux/init.h>
+#include <linux/malloc.h>
 #include <asm/io.h>
 #include <asm/pgtable.h>
 #include <asm/prom.h>
@@ -418,7 +419,7 @@
 				ioremap(addr->address + 0x800000, 0x1000);
 			bp->cfg_data = (volatile unsigned char *)
 				ioremap(addr->address + 0xc00000, 0x1000);
-			bp->io_base = (void *) ioremap(addr->address, 0x10000);
+			bp->io_base = (void *) ioremap(addr->address, 0x800000);
 		} else {
 			/* XXX */
 			bp->cfg_addr = (volatile unsigned int *)
@@ -447,20 +448,30 @@
 pmac_pcibios_fixup(void))
 {
 	struct pci_dev *dev;
-	
+	int i, has_io, has_mem;
+	unsigned short cmd;
+	struct bridge_data *bp;
+
 	/*
-	 * FIXME: This is broken: We should not assign IRQ's to IRQless
-	 *	  devices (look at PCI_INTERRUPT_PIN) and we also should
-	 *	  honor the existence of multi-function devices where
-	 *	  different functions have different interrupt pins. [mj]
+	 * The generic PCI code scans only bus 0 for devices and P2P
+	 * bridges. We fix this here based on the array of host
+	 * bridges.
 	 */
+	for (bp = bridge_list; bp != NULL; bp = bp->next) {
+		if (bp->bus_number == 0) continue;
+
+		pci_scan_peer_bridge (bp->bus_number);
+	}
+
 	for(dev=pci_devices; dev; dev=dev->next)
 	{
 		/*
-		 * Open Firmware often doesn't initialize the,
-		 * PCI_INTERRUPT_LINE config register properly, so we
-		 * should find the device node and se if it has an
-		 * AAPL,interrupts property.
+		 * Open Firmware doesn't initialize the PCI_INTERRUPT_LINE
+		 * config register, so we need to find the device node and
+		 * see if it has an AAPL,interrupts property.
+		 *
+		 * Note that INTA# - INTD# are OR'ed together per slot,
+		 # so no need to worry about multifunction cards.
 		 */
 		struct bridge_data *bp = bridges[dev->bus->number];
 		unsigned char pin;
@@ -469,6 +480,63 @@
 		    !pin)
 			continue; /* No interrupt generated -> no fixup */
                 fix_intr(bp->node->child, dev);
+
+		/*
+		 * Open Firmware does not enable I/O and memory space
+		 * response on PCI devices. We try to fix this, but we need
+		 * to be sure that OF didn't forget to assign an address
+		 * to the device. [mj]
+		 *
+		 * FIXME: How can we know? We should use OF properties....
+		 *
+		 * In addition, we correct any I/O space address by adding
+		 * the offset provided by the corresponding host bridge.
+		 */
+		has_io = has_mem = 0;
+		for(i=0; i<6; i++) {
+			unsigned long base;
+			unsigned long a = dev->base_address[i];
+			if (a & PCI_BASE_ADDRESS_SPACE_IO) {
+				has_io = 1;
+				base = (unsigned long)
+					pci_io_base(dev->bus->number);
+				if (a < base) a += base;
+				if (a > base) {
+					dev->base_address[i] = a;
+					printk (KERN_INFO "PCI: Correcting IO"
+						"address %d on device %02x:"
+						"%02x, now %08lx.\n", i, 
+						dev->bus->number,dev->devfn,a);
+				}
+			} else if (a & PCI_BASE_ADDRESS_MEM_MASK)
+				has_mem = 1;
+		}
+		/*
+		 * Don't enable VGA-compatible cards since they have
+		 * fixed I/O and memory space.
+		 *
+		 * Don't enabled disabled IDE interfaces either because
+		 * some BIOSes may reallocate the same address when they
+		 * find that no devices are attached.
+		 *
+		 * FIXME: Is this really relevant here?
+		 */
+		if (((dev->class >> 8) != PCI_CLASS_DISPLAY_VGA) &&
+		    ((dev->class >> 8) != PCI_CLASS_STORAGE_IDE)) {
+			pci_read_config_word(dev, PCI_COMMAND, &cmd);
+			if (has_io && !(cmd & PCI_COMMAND_IO)) {
+				printk("PCI: Enabling I/O for device %02x:"
+				    "%02x\n", dev->bus->number, dev->devfn);
+				cmd |= PCI_COMMAND_IO;
+				pci_write_config_word(dev, PCI_COMMAND, cmd);
+			}
+			if (has_mem && !(cmd & PCI_COMMAND_MEMORY)) {
+				printk("PCI: Enabling memory for device %02x:"
+				    "%02x\n", dev->bus->number, dev->devfn);
+				cmd |= PCI_COMMAND_MEMORY;
+				pci_write_config_word(dev, PCI_COMMAND, cmd);
+			}
+		}
 	}
 }
 
diff -uNr linux-2.2.11/include/asm-ppc/io.h linux/include/asm-ppc/io.h
--- linux-2.2.11/include/asm-ppc/io.h	Sun Aug 15 19:54:48 1999
+++ linux/include/asm-ppc/io.h	Fri Aug 20 19:59:16 1999
@@ -32,7 +32,9 @@
 extern unsigned long isa_io_base;
 extern unsigned long isa_mem_base;
 extern unsigned long pci_dram_offset;
-#define _IO_BASE	isa_io_base
+/* We're correcting io base addresses in pci fixup code */
+/* #define _IO_BASE	isa_io_base */
+#define _IO_BASE	0
 #define _ISA_MEM_BASE	isa_mem_base
 #define PCI_DRAM_OFFSET	pci_dram_offset
 #endif /* CONFIG_APUS */
diff -uNr linux-2.2.11/drivers/block/ide-pmac.c linux/drivers/block/ide-pmac.c
--- linux-2.2.11/drivers/block/ide-pmac.c	Wed Aug 25 18:59:00 1999
+++ linux/drivers/block/ide-pmac.c	Wed Aug 25 18:53:22 1999
@@ -109,10 +109,10 @@
 	pio = ide_get_best_pio_mode(drive, pio, 4, &d);
 	switch (pio) {
 	case 4:
-		out_le32((unsigned *)(IDE_DATA_REG + 0x200 + _IO_BASE), 0x211025);
+		out_le32((unsigned *)(IDE_DATA_REG + 0x200), 0x211025);
 		break;
 	default:
-		out_le32((unsigned *)(IDE_DATA_REG + 0x200 + _IO_BASE), 0x2f8526);
+		out_le32((unsigned *)(IDE_DATA_REG + 0x200), 0x2f8526);
 		break;
 	}
 }
@@ -182,7 +182,7 @@
 		if (i >= MAX_HWIFS)
 			break;
 
-		base = (unsigned long) ioremap(np->addrs[0].address, 0x200) - _IO_BASE;
+		base = (unsigned long) ioremap(np->addrs[0].address, 0x200);
 
 		/* XXX This is bogus. Should be fixed in the registry by checking
 		   the kind of host interrupt controller, a bit like gatwick

Re: Various PMac PCI patches

[Ryan Nielsen]

Michel Lanners wrote:
> Can you check this patch still works for you? It should now also
> correct the IO-space addresses, so your PCI card should work in both
> buses.

It works OK.
I think you can get rid of the check for VGA when enabling memory/IO.

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]