Re: PCI IRQ routing problem in 2.4.0

Re: PCI IRQ routing problem in 2.4.0

[Linus Torvalds]

On Mon, 29 Jan 2001, Martin Diehl wrote:
> 
> Right, seems the 0x41/0x01 thing. I have the 0x01 case with SiS 85C503
> router rev. 01. Hopefully the 0x41 boards have a different revision. My
> fear however is, this is due to BIOS implementation of the routing table.
> 
> Using the docs of the 85C503 function from the SiS5595 southbridge
> datasheet I've written a patch to get things right - at least for the 0x01
> case. The mapping on my box appears as follows:
> 
> link/pirq value           config-reg               function
> 0x01/0x02/0x03/0x04       0x41/0x42/0x43/0x44    PCI INTA..D
> 0x61                      0x61                   5513 onboard IDE
> 0x62                      0x62                   onboard USB (OHCI)
> 0x6a                      0x6a                   onboard ACPI
> 0x7e                      0x7e                   onboard data acquisition

I bet that we can fix this up easily.

I bet the "translation" is just something like

	reg = pirq;
	if (reg < 5)
		reg += 0x40;

and that what happened was that SiS _originally_ only specified INTA-INTD,
and specified them as pirq link values 0x01-0x04, mapping to config
registers 0x41-0x44.

Later on they noticed that they wanted to do the other things too, and
they expanded the definition to be "for any other value, it's the config
space address".

> BTW: I was wondering, why we did not update the PCI_INTERRUPT_LINE in
> config space when we re-route dev->irq. Well, documentation/pci.txt says
> we should trust on dev->irq over config space, however stopping lspci
> and friends to confuse us would be too bad either. So I've included a
> one-liner to fix this.

I would prefer _not_ to see this.

Why? Because it's (a) real information what the PCI config space was, and
it might help debug things in the future. And (b) I've seen to many broken
BIOSes that do not re-initialize hardware fully over a soft boot, that I
worry that you'll get different behaviour after doing a "shutdown -r" with
this.

I'd rather not touch config space more than necessary.

		Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: PCI IRQ routing problem in 2.4.0 (updated patch)

[Martin Diehl]

On Mon, 29 Jan 2001, Linus Torvalds wrote:

> 	reg = pirq;
> 	if (reg < 5)
> 		reg += 0x40;

or adding the 0x41..0x44 cases to the switch statement in my patch?

> > BTW: I was wondering, why we did not update the PCI_INTERRUPT_LINE in
> 
> I would prefer _not_ to see this.
> 
> Why? Because it's (a) real information what the PCI config space was, and
> it might help debug things in the future. And (b) I've seen to many broken
> BIOSes that do not re-initialize hardware fully over a soft boot, that I
> worry that you'll get different behaviour after doing a "shutdown -r" with
> this.

Ok, good reason, I believe - so I've dropped this again.

Below is the updated patch. It should handle both (0x01/0x41
like) mappings. I can (and did) only test the 0x01 case.
USBIRQ routing (0x62) supported, IDE/ACPI/DAQ untouched.

Martin

-----

--- linux-2.4.0/arch/i386/kernel/pci-irq.c.orig	Mon Jan  8 14:45:35 2001
+++ linux-2.4.0/arch/i386/kernel/pci-irq.c	Mon Jan 29 19:56:44 2001
@@ -234,22 +234,107 @@
 	return 1;
 }
 
+/*
+ *	PIRQ routing for SiS 85C503 router used in several SiS chipsets
+ *	According to the SiS 5595 datasheet (preliminary V1.0, 12/24/1997)
+ *	the related registers work as follows:
+ *	
+ *	general: one byte per re-routable IRQ,
+ *		 bit 7      IRQ mapping enabled (0) or disabled (1)
+ *		 bits [6:4] reserved
+ *		 bits [3:0] IRQ to map to
+ *		     allowed: 3-7, 9-12, 14-15
+ *		     reserved: 0, 1, 2, 8, 13
+ *
+ *	individual registers in device config space:
+ *
+ *	0x41/0x42/0x43/0x44:	PCI INT A/B/C/D - bits as in general case
+ *
+ *	0x61:			IDEIRQ: bits as in general case - but:
+ *				bits [6:5] must be written 01
+ *				bit 4 channel-select primary (0), secondary (1)
+ *
+ *	0x62:			USBIRQ: bits as in general case - but:
+ *				bit 4 OHCI function disabled (0), enabled (1)
+ *	
+ *	0x6a:			ACPI/SCI IRQ - bits as in general case
+ *
+ *	0x7e:			Data Acq. Module IRQ - bits as in general case
+ *
+ *	Apparently there are systems implementing PCI routing table using both
+ *	link values 0x01-0x04 and 0x41-0x44 for PCI INTA..D, but register offsets
+ *	like 0x62 as link values for USBIRQ e.g. So there is no simple
+ *	"register = offset + pirq" relation.
+ *	Currently we support PCI INTA..D and USBIRQ and try our best to handle
+ *	both link mappings.
+ *	IDE/ACPI/DAQ mapping is currently unsupported (left untouched as set by BIOS).
+ */
+
 static int pirq_sis_get(struct pci_dev *router, struct pci_dev *dev, int pirq)
 {
 	u8 x;
-	int reg = 0x41 + (pirq - 'A') ;
+	int reg = pirq;
 
-	pci_read_config_byte(router, reg, &x);
+	switch(pirq) {
+		case 0x01:
+		case 0x02:
+		case 0x03:
+		case 0x04:
+			reg += 0x40;
+		case 0x41:
+		case 0x42:
+		case 0x43:
+		case 0x44:
+		case 0x62:
+			pci_read_config_byte(router, reg, &x);
+			if (reg != 0x62)
+				break;
+			if (!(x & 0x40))
+				return 0;
+			break;
+		case 0x61:
+		case 0x6a:
+		case 0x7e:
+			printk("SiS pirq: advanced IDE/ACPI/DAQ mapping not yet implemented\n");
+			return 0;
+		default:			
+			printk("SiS router pirq escape (%d)\n", pirq);
+			return 0;
+	}
 	return (x & 0x80) ? 0 : (x & 0x0f);
 }
 
 static int pirq_sis_set(struct pci_dev *router, struct pci_dev *dev, int pirq, int irq)
 {
 	u8 x;
-	int reg = 0x41 + (pirq - 'A') ;
+	int reg = pirq;
 
-	pci_read_config_byte(router, reg, &x);
-	x = (pirq & 0x20) ? 0 : (irq & 0x0f);
+	switch(pirq) {
+		case 0x01:
+		case 0x02:
+		case 0x03:
+		case 0x04:
+			reg += 0x40;
+		case 0x41:
+		case 0x42:
+		case 0x43:
+		case 0x44:
+		case 0x62:
+			x = (irq&0x0f) ? (irq&0x0f) : 0x80;
+			if (reg != 0x62)
+				break;
+			/* always mark OHCI enabled, as nothing else knows about this */
+			x |= 0x40;
+			break;
+		case 0x61:
+		case 0x6a:
+		case 0x7e:
+			printk("advanced SiS pirq mapping not yet implemented\n");
+			return 0;
+		default:			
+			printk("SiS router pirq escape (%d)\n", pirq);
+			return 0;
+	}
 	pci_write_config_byte(router, reg, x);
 
 	return 1;

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: PCI IRQ routing problem in 2.4.0 (updated patch)

[Robert Siemer]

From: Martin Diehl <mdiehlcs@compuserve.de>
> On Mon, 29 Jan 2001, Linus Torvalds wrote:

> Below is the updated patch. It should handle both (0x01/0x41
> like) mappings. I can (and did) only test the 0x01 case.
> USBIRQ routing (0x62) supported, IDE/ACPI/DAQ untouched.

I don't really understand your note above, but your patch alone does
not fix my problem. - Linus diff over pci-irq.c does.

The kernel still does not think what the bios states; it's like the
vanilla 2.4.0 in this regard. (--> on my box: kernel panic after
"modprobe usb-ohci && modprobe hid")


Bye,
	Robert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: PCI IRQ routing problem in 2.4.0 (updated patch)

[Martin Diehl]

On Tue, 30 Jan 2001, Robert Siemer wrote:

> > Below is the updated patch. It should handle both (0x01/0x41
> > like) mappings. I can (and did) only test the 0x01 case.
> > USBIRQ routing (0x62) supported, IDE/ACPI/DAQ untouched.
> 
> I don't really understand your note above, but your patch alone does
> not fix my problem. - Linus diff over pci-irq.c does.

Yes, I know - in fact it couldn't, because your BIOS' irq routing is not
only subject to the 0x01/0x41 ambiguity but also wrong wrt. to the USBIRQ,
which gets routed using link value 0x62 in any other case but yours.

Your routing table is:

00:0c slot=01 0:01/1eb8 1:02/1eb8 2:03/1eb8 3:04/1eb8
00:0b slot=02 0:02/1eb8 1:03/1eb8 2:04/1eb8 3:01/1eb8
00:0a slot=03 0:03/1eb8 1:04/1eb8 2:01/1eb8 3:02/1eb8
00:09 slot=04 0:04/1eb8 1:01/1eb8 2:02/1eb8 3:03/1eb8
00:01 slot=00 0:01/1eb8 1:02/1eb8 2:03/1eb8 3:04/1eb8 >>> no 0x62 here!
00:13 slot=00 0:01/1eb8 1:02/1eb8 2:03/1eb8 3:04/1eb8

suggesting the ISA-bridge (00:01) would be routed exactly like a normal
PCI device, namely your SCSI-HA in slot 1. Since the ISA-bridge provides
both IDE und USB function and they pretend to use pin A, all the kernel
can do is believe the BIOS and so these 3 devices end up unseparable from
each other on link/pirq 0x01 - which we assign to some IRQ when needed.
Your USB however *is* already routed by the BIOS to IRQ 9 using link/pirq
value 0x62, which makes the BIOS provided routing table really crap:

00:01.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513 (rev 01)
60: ff 80 49 00 88 00 00 02 00 80 80 00 20 19 00 00
          ^^
Linus' patch helps you, because it makes us trusting the device's config
space over the routing table. Probably a good idea as long as BIOS'es
wouldn't start to set wrong values in config space too...

So, unless you get a working BIOS update there is no way to get it right.

Another solution might be to put your NIC into slot 1 and configure your
BIOS to share the NIC's IRQ with USB. This way you would set up the
system exactly the same way, your BIOS is cheating the kernel.

> The kernel still does not think what the bios states; it's like the
> vanilla 2.4.0 in this regard. (--> on my box: kernel panic after

in fact vanilla 2.4.0 did believe what the bios states, namely the broken
routing table. It didn't believe however what the devices config space
reports - which turned out to be correct.

You should be happy with 2.4.1 which contains both Linus' and the
0x01/0x41 fix.

Martin

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

RE: PCI IRQ routing problem in 2.4.0 (updated patch)

[Dunlap, Randy]

> From: Martin Diehl [mailto:mdiehlcs@compuserve.de]
...
> Linus' patch helps you, because it makes us trusting the 
> device's config
> space over the routing table. Probably a good idea as long as BIOS'es
> wouldn't start to set wrong values in config space too...
...
> in fact vanilla 2.4.0 did believe what the bios states, 
> namely the broken
> routing table. It didn't believe however what the devices config space
> reports - which turned out to be correct.

The PIRQ (PCI IRQ Routing table) is a Windows 95/98 convention
(requirement).  It isn't used by NT or Windows 2000.
IOW, Linux needs to be well-prepared for handling interrupt
routing in the absence of the PIRQ table.
[http://www.microsoft.com/HWDEV/busbios/PCIIRQ.htm]

~Randy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: PCI IRQ routing problem in 2.4.0 (updated patch)

[Martin Diehl]

(cc's shortened, not to trash Linus et al)

On Thu, 1 Feb 2001, Robert Siemer wrote:

> Is it possible to directly ask the 'IRQ-router' (namely the
> ISA-bridge) for what it is set up for? - I mean which IRQ is routed to
> what without the help of the BIOS?

It's written in the PCI config registers of the router. That's what I've
tried to document in the patch according to the chipset datasheet.
The BIOS in contrast uses link values, which are vendor-specific,
undocumented and sometimes wrong ;-)
But we have to rely on these unless we have the chipset docs to make it
better - hopefully.

> There is a BIOS update for my board out there. Are you interested in
> the difference? - I would give it a try.

Might be intresting _if_ you find something unexpected like new link
values. But I don't expect any surprise. You should end up with something
similar to Aaron - including the misleading mutual IDE/USB conflict
warning. But everythin fine.

> What is the relation between IRQ routing in the ISA-brigde and the
> APIC?

APIC is a different approach to route IRQ's which is used on PII based
systems and newer (IIRC). So it doesn't matter in your case.

Martin

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/