VAIO irq assignment fix

Hi

I have gotten a Sony VAIO R505TL laptop which has a Richo RL5C574 Cardbus controller however the broken bios doesn't assign an irq to the controller even though it is attached.

This patch solves the problem and makes cardbus insert/eject a lot more stable for me.

Cheers,
Jes

@@ -5,6 +5,7 @@
 #include <linux/init.h>
 #include <linux/apm_bios.h>
 #include <linux/slab.h>
+#include <linux/pci.h>
 #include <asm/io.h>
 #include <linux/pm.h>
 #include <asm/keyboard.h>

@@ -416,6 +417,26 @@
 
 
 /*
+ * Work around broken Sony VAIO Notebooks which do not assign irqs
+ * to their Richo RL5C475 Cardbus controller, IRQ is 9.
+ */
+static __init int fix_broken_sony_bios_irq(struct dmi_blacklist *d)
+{
+	struct pci_dev *pdev = NULL;
+
+	pdev = pci_find_device(PCI_VENDOR_ID_RICOH,
+			       PCI_DEVICE_ID_RICOH_RL5C475, pdev);
+	if (pdev) {
+		pdev->irq = 9;
+		pci_write_config_byte(pdev, PCI_INTERRUPT_LINE, 9);
+		printk(KERN_INFO "%s detected - fixing missing/"
+		       "broken IRQ routing\n", d->ident);
+	}
+	return 0;
+}
+
+
+/*
  *	Simple "print if true" callback
  */
  

@@ -614,7 +635,13 @@
 			NO_MATCH, NO_MATCH
 			} },
 	 
-			
+	{ fix_broken_sony_bios_irq, "Sony VAIO R505TL Series Laptop", {
+			MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
+			MATCH(DMI_BIOS_VENDOR, "Phoenix Technologies LTD"),
+			MATCH(DMI_BIOS_VERSION, "R0202U1"),
+			NO_MATCH
+			} },
+
 	/*
 	 *	Generic per vendor APM settings
 	 */

Surely pci_enable_device should do that anyway?

Alan> Surely pci_enable_device should do that anyway?

The problem is that the interrupt is not set in the PIRQ table so if we don't shoehorn it in, the interrupt source wont be found.

Jes

What happens if you use the current ACPI patch btw ?

Alan> Surely pci_enable_device should do that anyway?

Alan> What happens if you use the current ACPI patch btw ?

Nothing ;(

The option that says 'use ACPI for interrupt routing' doesn't do anything yet.

Jes

Is the interrupt in the ACPI PCI IRQ routing table? Basic support for that is in the latest ACPI patch, 20011218 (www.sf.net/projects/acpi), it'll print the _PRT entries during boot. However, the info isn't used to actually setup the routing, so it won't help your problem. I have a patch which uses the ACPI table for setting up IRQ routing, that should make sure system work properly.

--Kai

Kai> Is the interrupt in the ACPI PCI IRQ routing table? Basic support Kai> for that is in the latest ACPI patch, 20011218
Kai> (www.sf.net/projects/acpi), it'll print the _PRT entries during Kai> boot. However, the info isn't used to actually setup the routing, Kai> so it won't help your problem. I have a patch which uses the ACPI Kai> table for setting up IRQ routing, that should make sure system work Kai> properly.

I think it's in the ACPI table since a certain M$ OS finds the interrupt source. As I mentioned to Alan, I tried the latest ACPI patch but as you say, nothing is done with the information. I haven't tried enabling ACPI_DEBUG but that sounds to be a next step.

I'd be interested in trying out your patch as well.

Cheers,
Jes

ACPI_DEBUG should print the table at least :)

My patch is appended, it applies on top of 2.4.17+acpi-20011218

--Kai

diff -X excl -urN linux-2.4.17.patches/arch/i386/kernel/pci-i386.h linux-2.4.17.work/arch/i386/kernel/pci-i386.h
@@ -21,6 +21,7 @@
 #define PCI_ASSIGN_ROMS		0x1000
 #define PCI_BIOS_IRQ_SCAN	0x2000
 #define PCI_ASSIGN_ALL_BUSSES	0x4000
+#define PCI_ACPI_IRQ		0x8000
 
 extern unsigned int pci_probe;
 

diff -X excl -urN linux-2.4.17.patches/arch/i386/kernel/pci-pc.c linux-2.4.17.work/arch/i386/kernel/pci-pc.c
@@ -1253,6 +1253,12 @@
 		return NULL;
 	}
 #endif
+#ifdef CONFIG_ACPI_PCI
+	else if (!strcmp(str, "acpiirq")) {
+		pci_probe |= PCI_ACPI_IRQ;
+		return NULL;
+	}
+#endif
 #ifdef CONFIG_PCI_DIRECT
 	else if (!strcmp(str, "conf1")) {
 		pci_probe = PCI_PROBE_CONF1 | PCI_NO_CHECKS;

diff -X excl -urN linux-2.4.17.patches/drivers/acpi/include/actypes.h linux-2.4.17.work/drivers/acpi/include/actypes.h
@@ -1125,6 +1125,7 @@
 	u32                         pin;
 	acpi_integer                address;        /* here for 64-bit alignment */
 	u32                         source_index;
+	void                        *link_handle;
 	NATIVE_CHAR                 source[4];      /* pad to 64 bits so sizeof() works in all cases */
 
 } acpi_pci_routing_table;

Kai> ACPI_DEBUG should print the table at least :)

Kai> My patch is appended, it applies on top of 2.4.17+acpi-20011218

Tried it and I can report your patch works as well. I guess I'll need to modify my patch to not mangle things if your patch is installed, or at least we should keep my patch in place until the latest ACPI gets integrated.

Cheers,
Jes

Your patch is also useful for the case of CONFIG_ACPI=n Worth keeping for that alone. I think it needs mangling a little to look a bit more like the similar HP workaround though, but thats a minor nit.

| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

No. Could we please integrate this not with ACPI, but with the much more limited "arch/i386/kernel/acpitable.c", which does NOT imply full ACPI, only scanning the tables for information in static format (like the irq routing stuff).

That we can/will/should always enable, and we should NOT EVER encourage this kind of "per-BIOS" crud. That just becomes a total horror to maintain in the long run.

Please?

Linus

Unfortunately, the PCI interrupt routing stuff in ACPI is not in a static table, but needs the full-blown AML interpreter. Bad, but we can't do anything about it.

There's one thing which may be worth doing, I think someone else did suggest this before: Allow for overriding BIOS tables with user provided correct ones. In this case, Jes could add an entry for the PCMCIA bridge to the $PIR table and tell the kernel to use this instead of the buggy BIOS' one.

The question is how to do this cleanly. Of course, it's easy enough to invent some way to use a corrected table which is linked into vmlinux at compile time. However, that means that the user has to recompile his kernel to add the table, which is not an easy option for everyone.

It would be nicer to dynamically add the table, e.g. have the bootloader load it, kind of like the initrd, but that seems not possible without a lot of effort. (Or is the initrd protocol flexible enough to allow for this?)

--Kai

Is that true of the MPS table as well ? Can you deduce one from the other even if you dont have a usable APIC ?

It may not be enough. The AML can be doing register setup and configuration.

Now... I have a Sony Vaio FX-103 with the RICOH RL5C476 not the 75. The laptop has 192 MB of RAM (not the standard 64) and a 10gb harddisk. Mandrake 8.1 with a 2.4.16 kernel with a USB PCI IRQ Routing patch to make USB work (yes I am waiting heavily for the ACPI stuff!).

Anyhow, no matter what I do (including your patch modified to work on the different controller) I cannot get two cards to work inside this laptop.

One is a wireless card, one is a compact flash converter thing (for the camera).

Both cards work individually. The laptop locks up if I insert both cards. There is no OOPS or anything... It just locks up. Removing the cards does not spring it back to life.

It is probably down to the fact that the Vaio laptops assign everything IRQ9. Please find attached my /proc/interrupts and lspci -vvv.

Any ideas?

Thanks

Lee P.

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Alan Cox
Sent: 18 January 2002 00:33
To: Kai Germaschewski
Cc: Linus Torvalds; Dave Jones; Jes Sorensen; Alan Cox; [email protected]; Marcelo Tosatti
Subject: Re: [patch] VAIO irq assignment fix

static

Is that true of the MPS table as well ? Can you deduce one from the other
even if you dont have a usable APIC ?

bootloader

a

It may not be enough. The AML can be doing register setup and configuration.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

CPU0

  0:      33588          XT-PIC  timer
  1:        335          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  5:          5          XT-PIC  prism2_cs
  8:          1          XT-PIC  rtc
  9:       1181          XT-PIC  acpi, usb-uhci, usb-uhci, Intel ICH, i810@PCI:0:2:0
 11:          3          XT-PIC  sonypi
 12:        676          XT-PIC  PS/2 Mouse
 14:       5368          XT-PIC  ide0
 15:          3          XT-PIC  ide1
NMI:          0 
ERR:          0

This is _probably_ caused by an IRQ storm, as the IDE code (which is used for your Compact Flash) raises an IRQ in it's probe routine but hasn't installed a handler.

The proper patch for this is ignored by Linus and Marcelo since August 2000.

Though Andre has acknowledged the bug and my patch is included in his latest ide patches.

Try this and report:

diff -ur linux-2.4.15.orig/drivers/ide/ide-cs.c linux/drivers/ide/ide-cs.c
@@ -42,6 +42,7 @@
 #include <linux/ioport.h>
 #include <linux/hdreg.h>
 #include <linux/major.h>
+#include <linux/ide.h>
 
 #include <asm/io.h>
 #include <asm/system.h>

@@ -226,6 +227,16 @@
 #define CFG_CHECK(fn, args...) \
 if (CardServices(fn, args) != 0) goto next_entry
 
+int idecs_register (int io_base, int ctl_base, int irq)
+{
+        hw_regs_t hw;
+        ide_init_hwif_ports(&hw, (ide_ioreg_t) io_base, (ide_ioreg_t)

ctl_base, NULL);

+        hw.irq = irq;
+        hw.chipset = ide_pci; // this enables IRQ sharing w/ PCI irqs
+        return ide_register_hw(&hw, NULL);

+}
+
+
void ide_config(dev_link_t *link)

 {
     client_handle_t handle = link->handle;
@@ -327,12 +338,16 @@
     if (link->io.NumPorts2)
        release_region(link->io.BasePort2, link->io.NumPorts2);

+ /* disable drive interrupts during IDE probe */
+ if(ctl_base)
+ outb(0x02, ctl_base);
+

     /* retry registration in case device is still spinning up */
     for (i = 0; i < 10; i++) {
-       hd = ide_register(io_base, ctl_base, link->irq.AssignedIRQ);
+       hd = idecs_register(io_base, ctl_base, link->irq.AssignedIRQ);
        if (hd >= 0) break;
        if (link->io.NumPorts1 == 0x20) {
-           hd = ide_register(io_base+0x10, ctl_base+0x10,
+           hd = idecs_register(io_base+0x10, ctl_base+0x10,
                              link->irq.AssignedIRQ);
            if (hd >= 0) {
                io_base += 0x10; ctl_base += 0x10;

Only in linux/drivers/ide: ide-cs.c-2415

diff -ur linux-2.4.15.orig/drivers/ide/ide.c linux/drivers/ide/ide.c
@@ -2293,6 +2293,7 @@
        memcpy(hwif->io_ports, hwif->hw.io_ports, sizeof(hwif->hw.io_ports));
 
        hwif->irq = hw->irq;
        hwif->noprobe = 0;
+       hwif->chipset = hw->chipset;
 
        if (!initializing) {

                ide_probe_module();

diff -ur linux-2.4.15.orig/include/linux/ide.h linux/include/linux/ide.h
@@ -223,6 +223,23 @@
 #endif
 
 /*
+ * hwif_chipset_t is used to keep track of the specific hardware
+ * chipset used by each IDE interface, if known.
+ */
+typedef enum {  ide_unknown,    ide_generic,    ide_pci,
+                ide_cmd640,     ide_dtc2278,    ide_ali14xx,
+                ide_qd65xx,     ide_umc8672,    ide_ht6560b,
+                ide_pdc4030,    ide_rz1000,     ide_trm290,
+                ide_cmd646,     ide_cy82c693,   ide_4drives,
+                ide_pmac,       ide_etrax100
+} hwif_chipset_t;
+
+#define IDE_CHIPSET_PCI_MASK    \
+    ((1<<ide_pci)|(1<<ide_cmd646)|(1<<ide_ali14xx))
+#define IDE_CHIPSET_IS_PCI(c)   ((IDE_CHIPSET_PCI_MASK >> (c)) & 1)
+
+
+/*
  * Structure to hold all information about the location of this port
  */
 typedef struct hw_regs_s {

@@ -231,6 +248,7 @@
        int             dma;                    /* our dma entry */
        ide_ack_intr_t  *ack_intr;              /* acknowledge interrupt */
        void            *priv;                  /* interface specific data */
 
+       hwif_chipset_t  chipset;
 } hw_regs_t;
 

/*
@@ -439,22 +457,6 @@
* ide soft-power support
*/
typedef int (ide_busproc_t) (struct hwif_s *, int);
-
-/*
- * hwif_chipset_t is used to keep track of the specific hardware
- * chipset used by each IDE interface, if known.
- */

-typedef enum { ide_unknown,    ide_generic,    ide_pci,
-               ide_cmd640,     ide_dtc2278,    ide_ali14xx,
-               ide_qd65xx,     ide_umc8672,    ide_ht6560b,
-               ide_pdc4030,    ide_rz1000,     ide_trm290,
-               ide_cmd646,     ide_cy82c693,   ide_4drives,
-               ide_pmac,       ide_etrax100

-} hwif_chipset_t;
-
-#define IDE_CHIPSET_PCI_MASK \
- ((1<<ide_pci)|(1<<ide_cmd646)|(1<<ide_ali14xx))
-#define IDE_CHIPSET_IS_PCI(c) ((IDE_CHIPSET_PCI_MASK >> (c)) & 1)

#ifdef CONFIG_BLK_DEV_IDEPCI
typedef struct ide_pci_devid_s {

diff -ur linux-2.4.15.orig/drivers/ide/ide-cs.c linux/drivers/ide/ide-cs.c
@@ -42,6 +42,7 @@
 #include <linux/ioport.h>
 #include <linux/hdreg.h>
 #include <linux/major.h>
+#include <linux/ide.h>
 
 #include <asm/io.h>
 #include <asm/system.h>

@@ -226,6 +227,16 @@
 #define CFG_CHECK(fn, args...) \
 if (CardServices(fn, args) != 0) goto next_entry
 
+int idecs_register (int io_base, int ctl_base, int irq)
+{
+        hw_regs_t hw;
+        ide_init_hwif_ports(&hw, (ide_ioreg_t) io_base, (ide_ioreg_t) ctl_base, NULL);
+        hw.irq = irq;
+        hw.chipset = ide_pci; // this enables IRQ sharing w/ PCI irqs
+        return ide_register_hw(&hw, NULL);
+}
+
+
 void ide_config(dev_link_t *link)
 {
     client_handle_t handle = link->handle;

@@ -327,12 +338,16 @@
     if (link->io.NumPorts2)
 	release_region(link->io.BasePort2, link->io.NumPorts2);
 
+    /* disable drive interrupts during IDE probe */
+    if(ctl_base)
+    	outb(0x02, ctl_base);
+
     /* retry registration in case device is still spinning up */
     for (i = 0; i < 10; i++) {
-	hd = ide_register(io_base, ctl_base, link->irq.AssignedIRQ);
+	hd = idecs_register(io_base, ctl_base, link->irq.AssignedIRQ);
 	if (hd >= 0) break;
 	if (link->io.NumPorts1 == 0x20) {
-	    hd = ide_register(io_base+0x10, ctl_base+0x10,
+	    hd = idecs_register(io_base+0x10, ctl_base+0x10,
 			      link->irq.AssignedIRQ);
 	    if (hd >= 0) {
 		io_base += 0x10; ctl_base += 0x10;

Only in linux/drivers/ide: ide-cs.c-2415

diff -ur linux-2.4.15.orig/drivers/ide/ide.c linux/drivers/ide/ide.c
@@ -2293,6 +2293,7 @@
 	memcpy(hwif->io_ports, hwif->hw.io_ports, sizeof(hwif->hw.io_ports));
 	hwif->irq = hw->irq;
 	hwif->noprobe = 0;
+	hwif->chipset = hw->chipset;
 
 	if (!initializing) {
 		ide_probe_module();

diff -ur linux-2.4.15.orig/include/linux/ide.h linux/include/linux/ide.h
@@ -223,6 +223,23 @@
 #endif
 
 /*
+ * hwif_chipset_t is used to keep track of the specific hardware
+ * chipset used by each IDE interface, if known.
+ */
+typedef enum {  ide_unknown,    ide_generic,    ide_pci,
+                ide_cmd640,     ide_dtc2278,    ide_ali14xx,
+                ide_qd65xx,     ide_umc8672,    ide_ht6560b,
+                ide_pdc4030,    ide_rz1000,     ide_trm290,
+                ide_cmd646,     ide_cy82c693,   ide_4drives,
+                ide_pmac,       ide_etrax100
+} hwif_chipset_t;
+
+#define IDE_CHIPSET_PCI_MASK    \
+    ((1<<ide_pci)|(1<<ide_cmd646)|(1<<ide_ali14xx))
+#define IDE_CHIPSET_IS_PCI(c)   ((IDE_CHIPSET_PCI_MASK >> (c)) & 1)
+
+
+/*
  * Structure to hold all information about the location of this port
  */
 typedef struct hw_regs_s {

@@ -231,6 +248,7 @@
 	int		dma;			/* our dma entry */
 	ide_ack_intr_t	*ack_intr;		/* acknowledge interrupt */
 	void		*priv;			/* interface specific data */
+	hwif_chipset_t  chipset;
 } hw_regs_t;
 
 /*

@@ -439,22 +457,6 @@
  * ide soft-power support
  */
 typedef int (ide_busproc_t) (struct hwif_s *, int);
-
-/*
- * hwif_chipset_t is used to keep track of the specific hardware
- * chipset used by each IDE interface, if known.
- */
-typedef enum {	ide_unknown,	ide_generic,	ide_pci,
-		ide_cmd640,	ide_dtc2278,	ide_ali14xx,
-		ide_qd65xx,	ide_umc8672,	ide_ht6560b,
-		ide_pdc4030,	ide_rz1000,	ide_trm290,
-		ide_cmd646,	ide_cy82c693,	ide_4drives,
-		ide_pmac,       ide_etrax100
-} hwif_chipset_t;
-
-#define IDE_CHIPSET_PCI_MASK	\
-    ((1<<ide_pci)|(1<<ide_cmd646)|(1<<ide_ali14xx))
-#define IDE_CHIPSET_IS_PCI(c)	((IDE_CHIPSET_PCI_MASK >> (c)) & 1)
 
 #ifdef CONFIG_BLK_DEV_IDEPCI
 typedef struct ide_pci_devid_s {

I was under the impression that the Intel ACPI folks had things in mind for acpitable.c along the lines of 'rm', in favour of having their new interpretor do a "Load, setup, get the hell out" approach for those that didn't want it staying around.

Either way, I agree improving our ACPI support is a better solution in the long run.

| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

No argument here, but I'd love to use my cardbus NICs in my VAIO one way or another in the next stable kernel!

Ben Greear <[email protected]>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear