Re: [patch] VAIO irq assignment fix

Re: [patch] VAIO irq assignment fix

[Alan Cox]

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

Surely pci_enable_device should do that anyway?

[patch] VAIO irq assignment fix

[Jes Sorensen]

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
--- ../linux-2.4.18-pre2/arch/i386/kernel/dmi_scan.c	Fri Dec 21 12:41:53 2001
+++ arch/i386/kernel/dmi_scan.c	Wed Jan 16 18:36:05 2002
@@ -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
 	 */

Re: [patch] VAIO irq assignment fix

[Jes Sorensen]

>>>>> "Alan" == Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

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

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

Re: [patch] VAIO irq assignment fix

[Jes Sorensen]

>>>>> "Alan" == Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

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.

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

Re: [patch] VAIO irq assignment fix

[Alan Cox]

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

What happens if you use the current ACPI patch btw ?

Re: [patch] VAIO irq assignment fix

[Kai Germaschewski]

On Thu, 17 Jan 2002, Jes Sorensen wrote:

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

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

Re: [patch] VAIO irq assignment fix

[Jes Sorensen]

>>>>> "Kai" == Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de> writes:

Kai> On Thu, 17 Jan 2002, Jes Sorensen wrote:
>>  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.

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

Re: [patch] VAIO irq assignment fix

[Kai Germaschewski]

On Thu, 17 Jan 2002, Jes Sorensen wrote:

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

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
--- linux-2.4.17.patches/arch/i386/kernel/pci-i386.h	Mon Jan 14 23:55:08 2002
+++ linux-2.4.17.work/arch/i386/kernel/pci-i386.h	Fri Dec 28 23:19:14 2001
@@ -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-irq.c linux-2.4.17.work/arch/i386/kernel/pci-irq.c
--- linux-2.4.17.patches/arch/i386/kernel/pci-irq.c	Mon Jan 14 23:55:08 2002
+++ linux-2.4.17.work/arch/i386/kernel/pci-irq.c	Tue Jan  8 00:01:32 2002
@@ -512,6 +512,82 @@
 		pirq_router_dev->slot_name);
 }
 
+static void pcibios_test_irq_handler(int irq, void *dev_id, struct pt_regs *regs)
+{
+}
+
+#ifdef CONFIG_ACPI_PCI
+
+extern int acpi_pci_get_current_irq(struct pci_dev *dev, u8 pin, int *irq);
+extern int acpi_pci_set_current_irq(struct pci_dev *dev, u8 pin, int irq);
+extern int acpi_pci_get_possible_irq_mask(struct pci_dev *dev, u8 pin, int *mask);
+
+static int acpi_lookup_irq(struct pci_dev *dev, u8 pin, int assign)
+{
+	int  newirq, i, irq, retval;
+	char *msg = NULL;
+	u32 mask;
+
+	DBG("IRQ for %s:%d (%d)", dev->slot_name, pin, dev->irq);
+
+	retval = acpi_pci_get_current_irq(dev, pin, &irq);
+	if (retval < 0) {
+		DBG(" -> failed\n");
+		return 0;
+	}
+	DBG(" -> irq %d", irq);
+
+	retval = acpi_pci_get_possible_irq_mask(dev, pin, &mask);
+	if (retval < 0) {
+		DBG(" -> failed\n");
+		return 0;
+	}
+	DBG(" -> mask %04x", mask);
+	mask &= pcibios_irq_mask;
+
+
+	if (assign) {
+		/* Find the best IRQ to assign */
+		newirq = 0;
+		for (i = 0; i < 16; i++) {
+			if (!(mask & (1 << i)))
+				continue;
+			if (pirq_penalty[i] < pirq_penalty[newirq] &&
+			    !request_irq(i, pcibios_test_irq_handler, SA_SHIRQ, "pci-test", dev)) {
+				free_irq(i, dev);
+				newirq = i;
+			}
+		}
+		/* Use the current IRQ if possible */
+		if (irq && ((1 << irq) & mask))
+			newirq = irq;
+
+		DBG(" -> newirq=%d", newirq);
+		if (newirq && (dev->class >> 8) != PCI_CLASS_DISPLAY_VGA) {
+			DBG(" -> assigning IRQ %d", newirq);
+			if (acpi_pci_set_current_irq(dev, pin, newirq) == 0) {
+				eisa_set_level_irq(newirq);
+				DBG(" ... OK\n");
+				msg = "Assigned";
+				irq = newirq;
+			}
+		}
+	} else {
+		msg = "Found";
+	}
+
+	if (irq) {
+		printk(KERN_INFO "PCI: %s IRQ %d for device %s\n", msg, irq, dev->slot_name);
+
+		dev->irq = irq;
+		pirq_penalty[irq]++;
+		return 1;
+	}
+	return 0;
+}
+
+#endif
+
 static struct irq_info *pirq_get_info(struct pci_dev *dev)
 {
 	struct irq_routing_table *rt = pirq_table;
@@ -524,38 +600,25 @@
 	return NULL;
 }
 
-static void pcibios_test_irq_handler(int irq, void *dev_id, struct pt_regs *regs)
-{
-}
-
-static int pcibios_lookup_irq(struct pci_dev *dev, int assign)
+static int pirq_lookup_irq(struct pci_dev *dev, u8 pin, int assign)
 {
-	u8 pin;
-	struct irq_info *info;
-	int i, pirq, newirq;
-	int irq = 0;
-	u32 mask;
 	struct irq_router *r = pirq_router;
+	struct irq_info *info;
+	int  newirq, pirq, i, irq = 0;
 	struct pci_dev *dev2;
 	char *msg = NULL;
+	u32 mask;
 
 	if (!pirq_table)
 		return 0;
 
-	/* Find IRQ routing entry */
-	pci_read_config_byte(dev, PCI_INTERRUPT_PIN, &pin);
-	if (!pin) {
-		DBG(" -> no interrupt pin\n");
-		return 0;
-	}
-	pin = pin - 1;
-	
 	DBG("IRQ for %s:%d", dev->slot_name, pin);
 	info = pirq_get_info(dev);
 	if (!info) {
 		DBG(" -> not found in routing table\n");
 		return 0;
 	}
+
 	pirq = info->irq[pin].link;
 	mask = info->irq[pin].bitmap;
 	if (!pirq) {
@@ -636,26 +699,47 @@
 	return 1;
 }
 
+static int pcibios_lookup_irq(struct pci_dev *dev, int assign)
+{
+	u8 pin;
+
+	/* Find IRQ routing entry */
+	pci_read_config_byte(dev, PCI_INTERRUPT_PIN, &pin);
+	if (!pin) {
+		DBG("PCI: %s: no interrupt pin\n", dev->slot_name);
+		return 0;
+	}
+	pin -= 1;
+
+#ifdef CONFIG_ACPI_PCI
+	if (pci_probe & PCI_ACPI_IRQ)
+		return acpi_lookup_irq(dev, pin, assign);
+#endif
+	return pirq_lookup_irq(dev, pin, assign);
+}
+
 void __init pcibios_irq_init(void)
 {
 	DBG("PCI: IRQ init\n");
-	pirq_table = pirq_find_routing_table();
+	if (!(pci_probe & PCI_ACPI_IRQ)) {
+		pirq_table = pirq_find_routing_table();
 #ifdef CONFIG_PCI_BIOS
-	if (!pirq_table && (pci_probe & PCI_BIOS_IRQ_SCAN))
-		pirq_table = pcibios_get_irq_routing_table();
+		if (!pirq_table && (pci_probe & PCI_BIOS_IRQ_SCAN))
+			pirq_table = pcibios_get_irq_routing_table();
 #endif
-	if (pirq_table) {
-		pirq_peer_trick();
-		pirq_find_router();
-		if (pirq_table->exclusive_irqs) {
-			int i;
-			for (i=0; i<16; i++)
-				if (!(pirq_table->exclusive_irqs & (1 << i)))
-					pirq_penalty[i] += 100;
-		}
-		/* If we're using the I/O APIC, avoid using the PCI IRQ routing table */
-		if (io_apic_assign_pci_irqs)
-			pirq_table = NULL;
+		if (pirq_table) {
+			pirq_peer_trick();
+			pirq_find_router();
+			if (pirq_table->exclusive_irqs) {
+				int i;
+				for (i=0; i<16; i++)
+					if (!(pirq_table->exclusive_irqs & (1 << i)))
+						pirq_penalty[i] += 100;
+			}
+			/* If we're using the I/O APIC, avoid using the PCI IRQ routing table */
+			if (io_apic_assign_pci_irqs)
+				pirq_table = NULL;
+		}
 	}
 }
 
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
--- linux-2.4.17.patches/arch/i386/kernel/pci-pc.c	Mon Jan 14 23:55:08 2002
+++ linux-2.4.17.work/arch/i386/kernel/pci-pc.c	Fri Dec 28 23:18:54 2001
@@ -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/acpi_pci.c linux-2.4.17.work/drivers/acpi/acpi_pci.c
--- linux-2.4.17.patches/drivers/acpi/acpi_pci.c	Mon Jan 14 23:55:08 2002
+++ linux-2.4.17.work/drivers/acpi/acpi_pci.c	Mon Jan  7 23:22:46 2002
@@ -119,9 +119,10 @@
 	if ((0 != acpi_pci_get_status(handle, &sta)) || !(sta & 0x01))
 		return -ENODEV;
 
-#ifdef CONFIG_ACPI_DEBUG
-	printk(KERN_INFO "  link device currently %s\n", (sta & 0x02)?"enabled":"disabled");
-#endif
+	/* If disabled, return */
+
+	if (!(sta & 0x02))
+		return 0;
 
 	/* Get the current (default) IRQ assignment */
 
@@ -146,41 +147,167 @@
 
 	while (resource && (bytes_unparsed > 0)) {
 
-		if (index != i++)
-			continue;
+		switch (resource->id) {
+		case ACPI_RSTYPE_START_DPF:
+		case ACPI_RSTYPE_END_DPF:
+			break;
+		default:
+			i++;
+		}
+
+		if (i <= index)
+			goto next;
 
 		switch (resource->id) {
 		case ACPI_RSTYPE_IRQ:
-			(*irq) = resource->data.irq.interrupts[0];
+		{
+			acpi_resource_irq *p = &resource->data.irq;
+
+			if (p->number_of_interrupts > 0) {
+				(*irq) = p->interrupts[0];
+			}
 			break;
+		}
 		case ACPI_RSTYPE_EXT_IRQ:
-			(*irq) = resource->data.irq.interrupts[0];
+		{
+			acpi_resource_ext_irq *p = &resource->data.extended_irq;
+			if (p->number_of_interrupts > 0) {
+				(*irq) = p->interrupts[0];
+			}
 			break;
 		}
+		}
 
 		if (*irq)
 			break;
 
+	next:
 		bytes_unparsed = bytes_unparsed - resource->length;
 		if (bytes_unparsed > 0)
 			resource = (acpi_resource*)((u8*)resource + resource->length);
 	}
 
-	if (!(*irq))
+	return 0;
+}
+
+
+static int
+acpi_pci_get_link_irq_mask (
+	acpi_handle		handle,
+	u32 			index,
+	u32			*mask)
+{
+	acpi_status		status = AE_OK;
+	acpi_buffer		buffer = {0, NULL};
+	acpi_resource		*resource = NULL;
+	int			bytes_unparsed = 0;
+	int			i = 0;
+
+	if (!handle || !mask)
+		return -EINVAL;
+
+	status = acpi_get_possible_resources(handle, &buffer);
+	if (status != AE_BUFFER_OVERFLOW)
 		return -ENODEV;
 
-	/* If disabled, enable by evaluating _SRS using default IRQ */
+	buffer.pointer = kmalloc(buffer.length, GFP_KERNEL);
+	if (!buffer.pointer)
+		return -ENOMEM;
+	memset(buffer.pointer, 0, buffer.length);
 
-	if (!(sta & 0x02)) {
-		acpi_buffer buffer = {resource->length, resource};
-		printk(KERN_INFO PREFIX "Enabling _PRT entry\n");
-		status = acpi_set_current_resources(handle, &buffer);
-		if (ACPI_FAILURE(status)) {
-			printk(KERN_WARNING PREFIX "Error evaluating _SRS, %s\n",
-				acpi_format_exception(status));
-			return -ENODEV;
+	status = acpi_get_possible_resources(handle, &buffer);
+	if (ACPI_FAILURE(status)) {
+		kfree(buffer.pointer);
+		return -ENODEV;
+	}
+
+	resource = (acpi_resource *) buffer.pointer;
+
+	bytes_unparsed = buffer.length - 16;
+
+	while (resource && (bytes_unparsed > 0)) {
+
+		switch (resource->id) {
+		case ACPI_RSTYPE_START_DPF:
+		case ACPI_RSTYPE_END_DPF:
+			break;
+		default:
+			i++;
+		}
+
+		if (i <= index)
+			goto next;
+
+		switch (resource->id) {
+		case ACPI_RSTYPE_IRQ:
+		{
+			acpi_resource_irq *p = &resource->data.irq;
+			int j;
+			
+			*mask = 0;
+			for (j = 0; j < p->number_of_interrupts; j++) {
+				(*mask) |= (1 << p->interrupts[j]);
+			}
+			return 0;
 		}
+		case ACPI_RSTYPE_EXT_IRQ:
+		{
+			acpi_resource_ext_irq *p = &resource->data.extended_irq;
+			int j;
+			
+			*mask = 0;
+			for (j = 0; j < p->number_of_interrupts; j++) {
+				(*mask) |= (1 << p->interrupts[j]);
+			}
+			return 0;
+		}
+		}
+
+	next:
+		bytes_unparsed = bytes_unparsed - resource->length;
+		if (bytes_unparsed > 0)
+			resource = (acpi_resource *)((u8 *)resource + resource->length);
 	}
+	
+	return -ENODEV;
+}
+  
+  
+static int
+acpi_pci_set_link_irq (
+	acpi_handle		handle,
+	u32 			index,
+	u32			irq)
+{
+	acpi_status		status = AE_OK;
+	acpi_buffer		buffer = {0, NULL};
+	struct {
+		acpi_resource	res;
+		acpi_resource   end;
+	}                       resource;
+	int			bytes_unparsed = 0;
+	int			i = 0;
+
+
+	if (!handle)
+		return -EINVAL;
+
+	memset(&resource, 0, sizeof(resource));
+	resource.res.id = ACPI_RSTYPE_IRQ;
+	resource.res.length = sizeof(acpi_resource);
+	resource.res.data.irq.edge_level = 0; // FIXME?
+	resource.res.data.irq.active_high_low = 0;
+	resource.res.data.irq.shared_exclusive = 1;
+	resource.res.data.irq.number_of_interrupts = 1;
+	resource.res.data.irq.interrupts[0] = irq;
+	resource.end.id = ACPI_RSTYPE_END_TAG;
+
+	buffer.pointer = &resource;
+	buffer.length = resource.res.length + 1;
+	status = acpi_set_current_resources(handle, &buffer);
+
+	if (status != AE_OK)
+		return -ENODEV;
 
 	return 0;
 }
@@ -243,17 +370,15 @@
 
 		/* Type 1 (dynamic)? */
 		if (prt->source) {
-			acpi_handle link_handle = NULL;
-			acpi_get_handle(handle, prt->source, &link_handle);
-			acpi_pci_get_link_irq(link_handle, prt->source_index, 
-				&prt->source_index);
-			prt->source[0] = 0;
+			prt->link_handle = NULL;
+			acpi_get_handle(handle, prt->source, &prt->link_handle);
+/* 			prt->source[0] = 0; */
 		}
 
 #ifdef CONFIG_ACPI_DEBUG
-		printk(KERN_INFO "  device=%02x pin=%02x irq=%d\n", 
+		printk(KERN_INFO "  device=%02x pin=%02x source=%s source_index=%d\n", 
 			(u32)(prt->address>>16), (u32)prt->pin, 
-			(u32)prt->source_index);
+			prt->source, (u32)prt->source_index);
 #endif /*CONFIG_ACPI_DEBUG*/
 
 		acpi_prt.count++;
@@ -266,6 +391,92 @@
 }
 
 
+static acpi_pci_routing_table *
+acpi_pci_find_routing_table_entry(struct pci_dev *dev, u8 pin)
+{
+	int                     busnr = dev->bus->number;
+	acpi_pci_routing_table	*prt = NULL;
+
+	if (busnr >= ACPI_PCI_MAX_BUS)
+		return 0;
+
+	prt = (acpi_pci_routing_table *) acpi_prt.entry[busnr];
+	while (prt && prt->length > 0) {
+		if ((prt->address >> 16) == PCI_SLOT(dev->devfn) && prt->pin == pin)
+			return prt;
+		prt = (acpi_pci_routing_table *)
+			((u8 *) prt + prt->length);
+	}
+	return prt;
+}
+
+
+int
+acpi_pci_get_current_irq(struct pci_dev *dev, u8 pin, int *irq)
+{
+	acpi_pci_routing_table	*prt;
+
+	*irq = 0;
+
+	prt = acpi_pci_find_routing_table_entry(dev, pin);
+	if (!prt)
+		return -ENODEV;
+
+	/* Type 1 (dynamic)? */
+	if (prt->source) {
+		return acpi_pci_get_link_irq(prt->link_handle, 
+					     prt->source_index, irq);
+	} else {
+		*irq = prt->source_index;
+		return 0;
+	}
+}
+
+
+int
+acpi_pci_get_possible_irq_mask(struct pci_dev *dev, u8 pin, int *mask)
+{
+	acpi_pci_routing_table	*prt;
+
+	*mask = 0;
+
+	prt = acpi_pci_find_routing_table_entry(dev, pin);
+	if (!prt)
+		return -ENODEV;
+
+	/* Type 1 (dynamic)? */
+	if (prt->source) {
+		return acpi_pci_get_link_irq_mask(prt->link_handle,
+						  prt->source_index, mask);
+	} else {
+		*mask = 1 << prt->source_index;
+		return 0;
+	}
+}
+
+
+int
+acpi_pci_set_current_irq(struct pci_dev *dev, u8 pin, int irq)
+{
+	acpi_pci_routing_table	*prt;
+
+	prt = acpi_pci_find_routing_table_entry(dev, pin);
+	if (!prt)
+		return -ENODEV;
+
+	/* Type 1 (dynamic)? */
+	if (prt->source) {
+		return acpi_pci_set_link_irq(prt->link_handle,
+					     prt->source_index, irq);
+	} else {
+		if (irq != prt->source_index)
+			return -ENODEV;
+
+		return 0;
+	}
+}
+
+
 static acpi_status __init
 acpi_pci_resolve_bus (
 	acpi_handle		handle,
@@ -432,5 +643,3 @@
 	return 0;
 }
 
-
-
diff -X excl -urN linux-2.4.17.patches/drivers/acpi/include/actypes.h linux-2.4.17.work/drivers/acpi/include/actypes.h
--- linux-2.4.17.patches/drivers/acpi/include/actypes.h	Mon Jan 14 23:55:08 2002
+++ linux-2.4.17.work/drivers/acpi/include/actypes.h	Fri Dec 28 23:16:25 2001
@@ -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;

Re: [patch] VAIO irq assignment fix

[Jes Sorensen]

>>>>> "Kai" == Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de> writes:

Kai> On Thu, 17 Jan 2002, Jes Sorensen wrote:
>> 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.

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

Re: [patch] VAIO irq assignment fix

[Dave Jones]

On Thu, 17 Jan 2002, Jes Sorensen wrote:

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

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

Re: [patch] VAIO irq assignment fix

[Linus Torvalds]

On Thu, 17 Jan 2002, Dave Jones wrote:
>
> Your patch is also useful for the case of CONFIG_ACPI=n
> Worth keeping for that alone.

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

Re: [patch] VAIO irq assignment fix

[Dave Jones]

On Thu, Jan 17, 2002 at 02:35:30PM -0800, Linus Torvalds wrote:
 > 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).

 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

Re: [patch] VAIO irq assignment fix

[Ben Greear]

Dave Jones wrote:

> On Thu, Jan 17, 2002 at 02:35:30PM -0800, Linus Torvalds wrote:
>  > 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).
> 
>  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.


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 <greearb@candelatech.com>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Re: [patch] VAIO irq assignment fix

[Kai Germaschewski]

On Thu, 17 Jan 2002, Linus Torvalds wrote:

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

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.

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

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

Re: [patch] VAIO irq assignment fix

[Alan Cox]

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

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 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?)

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

RE: [patch] VAIO irq assignment fix

[Lee Packham]

[-- Attachment #1: Type: text/plain, Size: 2017 bytes --]

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: linux-kernel-owner@vger.kernel.org
[mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Alan Cox
Sent: 18 January 2002 00:33
To: Kai Germaschewski
Cc: Linus Torvalds; Dave Jones; Jes Sorensen; Alan Cox;
linux-kernel@vger.kernel.org; Marcelo Tosatti
Subject: Re: [patch] VAIO irq assignment fix

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

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 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?)

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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[-- Attachment #2: lspci --]
[-- Type: application/octet-stream, Size: 7584 bytes --]

00:00.0 Host bridge: Intel Corp. 82815 815 Chipset Host Bridge and Memory Controller Hub (rev 11)
	Subsystem: Sony Corporation: Unknown device 80df
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
	Latency: 0
	Capabilities: [88] #09 [f205]

00:02.0 VGA compatible controller: Intel Corp. 82815 CGC [Chipset Graphics Controller] (rev 11) (prog-if 00 [VGA])
	Subsystem: Sony Corporation: Unknown device 80df
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Interrupt: pin A routed to IRQ 9
	Region 0: Memory at f8000000 (32-bit, prefetchable) [size=64M]
	Region 1: Memory at f4000000 (32-bit, non-prefetchable) [size=512K]
	Capabilities: [dc] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:1e.0 PCI bridge: Intel Corp. 82820 820 (Camino 2) Chipset PCI (-M) (rev 03) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
	I/O behind bridge: 00003000-00003fff
	Memory behind bridge: f4100000-f41fffff
	Prefetchable memory behind bridge: fff00000-000fffff
	BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-

00:1f.0 ISA bridge: Intel Corp. 82820 820 (Camino 2) Chipset ISA Bridge (ICH2-M) (rev 03)
	Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0

00:1f.1 IDE interface: Intel Corp. 82820 820 (Camino 2) Chipset IDE U100 (-M) (rev 03) (prog-if 80 [Master])
	Subsystem: Sony Corporation: Unknown device 80df
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Region 4: I/O ports at 1800 [size=16]

00:1f.2 USB Controller: Intel Corp. 82820 820 (Camino 2) Chipset USB (Hub A) (rev 03) (prog-if 00 [UHCI])
	Subsystem: Sony Corporation: Unknown device 80df
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Interrupt: pin D routed to IRQ 9
	Region 4: I/O ports at 1820 [size=32]

00:1f.3 SMBus: Intel Corp. 82820 820 (Camino 2) Chipset SMBus (rev 03)
	Subsystem: Sony Corporation: Unknown device 80df
	Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Interrupt: pin B routed to IRQ 9
	Region 4: I/O ports at 1810 [size=16]

00:1f.4 USB Controller: Intel Corp. 82820 820 (Camino 2) Chipset USB (Hub B) (rev 03) (prog-if 00 [UHCI])
	Subsystem: Sony Corporation: Unknown device 80df
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Interrupt: pin C routed to IRQ 9
	Region 4: I/O ports at 1840 [size=32]

00:1f.5 Multimedia audio controller: Intel Corp. 82820 820 (Camino 2) Chipset AC'97 Audio Controller (rev 03)
	Subsystem: Sony Corporation: Unknown device 80df
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Interrupt: pin B routed to IRQ 9
	Region 0: I/O ports at 1c00 [size=256]
	Region 1: I/O ports at 1880 [size=64]

00:1f.6 Modem: Intel Corp. 82820 820 (Camino 2) Chipset AC'97 Modem Controller (rev 03) (prog-if 00 [Generic])
	Subsystem: Sony Corporation: Unknown device 80df
	Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Interrupt: pin B routed to IRQ 9
	Region 0: I/O ports at 2400 [size=256]
	Region 1: I/O ports at 2000 [size=128]

01:00.0 FireWire (IEEE 1394): Texas Instruments: Unknown device 8021 (rev 02) (prog-if 10 [OHCI])
	Subsystem: Sony Corporation: Unknown device 80df
	Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Interrupt: pin A routed to IRQ 9
	Region 0: Memory at f4105000 (32-bit, non-prefetchable) [size=2K]
	Region 1: Memory at f4100000 (32-bit, non-prefetchable) [size=16K]
	Capabilities: [44] Power Management version 2
		Flags: PMEClk- DSI- D1- D2+ AuxCurrent=0mA PME(D0-,D1-,D2+,D3hot+,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

01:02.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev 80)
	Subsystem: Sony Corporation: Unknown device 80df
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 168
	Interrupt: pin A routed to IRQ 9
	Region 0: Memory at f4106000 (32-bit, non-prefetchable) [size=4K]
	Bus: primary=01, secondary=02, subordinate=05, sec-latency=176
	Memory window 0: 00000000-00000000 (prefetchable)
	Memory window 1: 00000000-00000000 (prefetchable)
	I/O window 0: 00000000-00000003
	I/O window 1: 00000000-00000003
	BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset- 16bInt+ PostWrite+
	16-bit legacy interface ports at 0001

01:02.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev 80)
	Subsystem: Sony Corporation: Unknown device 80df
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 168
	Interrupt: pin B routed to IRQ 0
	Region 0: Memory at f4107000 (32-bit, non-prefetchable) [size=4K]
	Bus: primary=01, secondary=06, subordinate=09, sec-latency=176
	Memory window 0: 00000000-00000000 (prefetchable)
	Memory window 1: 00000000-00000000 (prefetchable)
	I/O window 0: 00000000-00000003
	I/O window 1: 00000000-00000003
	BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset- 16bInt+ PostWrite+
	16-bit legacy interface ports at 0001

01:08.0 Ethernet controller: Intel Corp. 82820 (ICH2) Chipset Ethernet Controller (rev 03)
	Subsystem: Intel Corp.: Unknown device 3013
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 66 (2000ns min, 14000ns max), cache line size 08
	Interrupt: pin A routed to IRQ 9
	Region 0: Memory at f4104000 (32-bit, non-prefetchable) [size=4K]
	Region 1: I/O ports at 3000 [size=64]
	Capabilities: [dc] Power Management version 2
		Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable+ DSel=0 DScale=2 PME-


[-- Attachment #3: interrupts.txt --]
[-- Type: text/plain, Size: 516 bytes --]

           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

Re: [patch] VAIO irq assignment fix ->CompactFlash-pcmcia freeze

[root]

[-- Attachment #1: Type: text/plain, Size: 5052 bytes --]

Lee Packham wrote:

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

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
--- linux-2.4.15.orig/drivers/ide/ide-cs.c      Sun Sep 30 21:26:05 2001
+++ linux/drivers/ide/ide-cs.c  Sun Nov 25 13:11:36 2001
@@ -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
--- linux-2.4.15.orig/drivers/ide/ide.c Thu Oct 25 22:58:35 2001
+++ linux/drivers/ide/ide.c     Sun Nov 25 13:02:34 2001
@@ -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
--- linux-2.4.15.orig/include/linux/ide.h       Thu Nov 22 20:48:07 2001
+++ linux/include/linux/ide.h   Sun Nov 25 13:05:57 2001
@@ -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 {




[-- Attachment #2: gmdiff-lx2415-compactflash+pcmcia+PCI --]
[-- Type: text/plain, Size: 3930 bytes --]

diff -ur linux-2.4.15.orig/drivers/ide/ide-cs.c linux/drivers/ide/ide-cs.c
--- linux-2.4.15.orig/drivers/ide/ide-cs.c	Sun Sep 30 21:26:05 2001
+++ linux/drivers/ide/ide-cs.c	Sun Nov 25 13:11:36 2001
@@ -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
--- linux-2.4.15.orig/drivers/ide/ide.c	Thu Oct 25 22:58:35 2001
+++ linux/drivers/ide/ide.c	Sun Nov 25 13:02:34 2001
@@ -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
--- linux-2.4.15.orig/include/linux/ide.h	Thu Nov 22 20:48:07 2001
+++ linux/include/linux/ide.h	Sun Nov 25 13:05:57 2001
@@ -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 {

RE: [patch] VAIO irq assignment fix

[Grover, Andrew]

> From: Dave Jones [mailto:davej@suse.de]
>  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.

acpitable.c was written to support machines with a bad MPS table but a valid
$PIR. The 20011218 ACPI patch more closely integrates that code with the
rest, but the ability to get at the MADT (the ACPI MPS replacement table)
and other tables without the interpreter is still supported. The code is
under drivers/acpi, though.

I don't see that option going away any time soon.

However, without a valid $PIR (which is what is becoming more common and is
the Sony's problem) you need the interpreter, like Kai mentioned. We are
working to incorporate Kai's code into the next acpi patch, which will
evaluate and use _PRT properly. In fact, that's just what I was working on
this afternoon, so Real Soon Now. ;-)

Regards -- Andy

Re: [patch] VAIO irq assignment fix

[Manfred Spraul]

Lee Packham wrote:
> 
> 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.
>
Have you tried Ingo's IRQ rate limiter? Perhaps someone forgets to send
an EOI to the hardware, and then everything locks up due to a level
triggered interrupt that remains active forever.

http://groups.google.com/groups?hl=en&selm=fa.o69hfov.tl2696%40ifi.uio.no&rnum=5

--
	Manfre