All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <bjorn.helgaas-VXdhtT5mjnY@public.gmane.org>
To: Li Shaohua <shaohua.li-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: Zwane Mwaikambo <zwane-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>,
	Grzegorz Kulewski
	<kangur-ghbW0t/Qn0CsTnJN9+BGXg@public.gmane.org>,
	Andrew Morton <akpm-3NddpPZAyC0@public.gmane.org>,
	ACPI List
	<acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>,
	lkml <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Len Brown <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Subject: Re: Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
Date: Fri, 18 Mar 2005 11:07:19 -0700	[thread overview]
Message-ID: <1111169239.13286.39.camel@eeyore> (raw)
In-Reply-To: <1111108150.22239.6.camel-U5EdaLXB8smDugQYiPIPGdh3ngVCH38I@public.gmane.org>

On Fri, 2005-03-18 at 09:09 +0800, Li Shaohua wrote:
> On Fri, 2005-03-18 at 02:08, Bjorn Helgaas wrote:
> > On Thu, 2005-03-17 at 09:33 +0800, Li Shaohua wrote:
> > > The comments in previous quirk said it's required only in PIC mode.
> > ...
> > > I feel we concerned too much. Changing the interrupt line isn't harmful,
> > > right? Linux actually ignored interrupt line. Maybe just a
> > > PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq) is
> > > sufficient.
> > 
> > I think it's good to limit the scope of the quirk as much as
> > possible because that makes it easier to do future restructuring,
> > such as device-specific interrupt routers.
> > 
> > The comment (before quirk_via_acpi(), nowhere near quirk_via_irqpic())
> > says *on-chip devices* have this unusual behavior when the interrupt
> > line is written.  That makes sense to me.
> > 
> > Writing the interrupt line on random plug-in Via PCI devices does
> > not make sense to me, because for that to have any effect, an
> > upstream bridge would have to be snooping the traffic going through
> > it.  That doesn't sound plausible to me.
> > 
> > What about this:
> Hmm, this looks like previous solution. We removed the specific via
> quirk is because we don't know how many devices have such issue. Every
> time we encounter an IRQ issue in a VIA PCI device, we will suspect it
> requires quirk and keep try. This is a big overhead. 

OK.  Try this one for size.  It differs from what's currently in
the tree in these ways:

    - It's a quirk, so we don't have to clutter acpi_pci_irq_enable()
      and pirq_enable_irq() with Via-specific code.

    - It doesn't do anything unless we're in PIC mode.  The comment
      suggests this issue only affects PIC routing.

    - We do this for ALL Via devices.  The current code in the tree
      does it for all devices in the system IF there is a Via device
      with devfn==0, which misses Grzegorz's case.

Does anybody have a pointer to a spec that talks about this?  It'd
be awfully nice to have a reference.

Grzegorz, can you check to make sure this still works after all the
tweaking?

===== arch/i386/pci/irq.c 1.55 vs edited =====
--- 1.55/arch/i386/pci/irq.c	2005-02-07 22:39:15 -07:00
+++ edited/arch/i386/pci/irq.c	2005-03-15 10:11:44 -07:00
@@ -1026,7 +1026,6 @@
 static int pirq_enable_irq(struct pci_dev *dev)
 {
 	u8 pin;
-	extern int via_interrupt_line_quirk;
 	struct pci_dev *temp_dev;
 
 	pci_read_config_byte(dev, PCI_INTERRUPT_PIN, &pin);
@@ -1081,10 +1080,6 @@
 		printk(KERN_WARNING "PCI: No IRQ known for interrupt pin %c of device %s.%s\n",
 		       'A' + pin, pci_name(dev), msg);
 	}
-	/* VIA bridges use interrupt line for apic/pci steering across
-	   the V-Link */
-	else if (via_interrupt_line_quirk)
-		pci_write_config_byte(dev, PCI_INTERRUPT_LINE, dev->irq & 15);
 	return 0;
 }
 
===== drivers/acpi/pci_irq.c 1.37 vs edited =====
--- 1.37/drivers/acpi/pci_irq.c	2005-03-01 09:57:29 -07:00
+++ edited/drivers/acpi/pci_irq.c	2005-03-15 10:10:57 -07:00
@@ -388,7 +388,6 @@
 	u8			pin = 0;
 	int			edge_level = ACPI_LEVEL_SENSITIVE;
 	int			active_high_low = ACPI_ACTIVE_LOW;
-	extern int		via_interrupt_line_quirk;
 
 	ACPI_FUNCTION_TRACE("acpi_pci_irq_enable");
 
@@ -437,9 +436,6 @@
 			return_VALUE(0);
 		}
  	}
-
-	if (via_interrupt_line_quirk)
-		pci_write_config_byte(dev, PCI_INTERRUPT_LINE, irq & 15);
 
 	dev->irq = acpi_register_gsi(irq, edge_level, active_high_low);
 
===== drivers/pci/quirks.c 1.72 vs edited =====
--- 1.72/drivers/pci/quirks.c	2005-03-10 01:38:25 -07:00
+++ edited/drivers/pci/quirks.c	2005-03-18 10:55:01 -07:00
@@ -683,19 +683,40 @@
 }
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_82454NX,	quirk_disable_pxb );
 
-/*
- *	VIA northbridges care about PCI_INTERRUPT_LINE
- */
-int via_interrupt_line_quirk;
+#ifdef CONFIG_ACPI
+#include <linux/acpi.h>
+#endif
 
-static void __devinit quirk_via_bridge(struct pci_dev *pdev)
+static void __devinit quirk_via_irqpic(struct pci_dev *dev)
 {
-	if(pdev->devfn == 0) {
-		printk(KERN_INFO "PCI: Via IRQ fixup\n");
-		via_interrupt_line_quirk = 1;
+	u8 irq, new_irq;
+
+#ifdef CONFIG_X86_IO_APIC
+	if (skip_ioapic_setup)
+		return;
+#endif
+#ifdef CONFIG_ACPI
+	if (acpi_irq_model != ACPI_IRQ_MODEL_PIC)
+		return;
+#endif
+	/*
+	 * Some Via devices make an internal connection to the PIC when the
+	 * PCI_INTERRUPT_LINE register is written.  If we've changed the
+	 * device's IRQ, we need to update this routing.
+	 *
+	 * I suspect this only happens for devices on the same chip as the
+	 * PIC, but I don't know how to identify those without listing them
+	 * all individually, which is a maintenance problem.
+	 */
+	new_irq = dev->irq & 0xf;
+	pci_read_config_byte(dev, PCI_INTERRUPT_LINE, &irq);
+	if (new_irq != irq) {
+		printk(KERN_INFO "PCI: Via PIC IRQ fixup for %s, from %d to %d\n",
+			pci_name(dev), irq, new_irq);
+		pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
 	}
 }
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA,	PCI_ANY_ID,                     quirk_via_bridge );
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irqpic);
 
 /*
  *	Serverworks CSB5 IDE does not fully support native mode




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <bjorn.helgaas@hp.com>
To: Li Shaohua <shaohua.li@intel.com>
Cc: Zwane Mwaikambo <zwane@arm.linux.org.uk>,
	Grzegorz Kulewski <kangur@polcom.net>,
	Andrew Morton <akpm@osdl.org>,
	ACPI List <acpi-devel@lists.sourceforge.net>,
	lkml <linux-kernel@vger.kernel.org>,
	Len Brown <len.brown@intel.com>
Subject: Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
Date: Fri, 18 Mar 2005 11:07:19 -0700	[thread overview]
Message-ID: <1111169239.13286.39.camel@eeyore> (raw)
In-Reply-To: <1111108150.22239.6.camel@sli10-desk.sh.intel.com>

On Fri, 2005-03-18 at 09:09 +0800, Li Shaohua wrote:
> On Fri, 2005-03-18 at 02:08, Bjorn Helgaas wrote:
> > On Thu, 2005-03-17 at 09:33 +0800, Li Shaohua wrote:
> > > The comments in previous quirk said it's required only in PIC mode.
> > ...
> > > I feel we concerned too much. Changing the interrupt line isn't harmful,
> > > right? Linux actually ignored interrupt line. Maybe just a
> > > PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq) is
> > > sufficient.
> > 
> > I think it's good to limit the scope of the quirk as much as
> > possible because that makes it easier to do future restructuring,
> > such as device-specific interrupt routers.
> > 
> > The comment (before quirk_via_acpi(), nowhere near quirk_via_irqpic())
> > says *on-chip devices* have this unusual behavior when the interrupt
> > line is written.  That makes sense to me.
> > 
> > Writing the interrupt line on random plug-in Via PCI devices does
> > not make sense to me, because for that to have any effect, an
> > upstream bridge would have to be snooping the traffic going through
> > it.  That doesn't sound plausible to me.
> > 
> > What about this:
> Hmm, this looks like previous solution. We removed the specific via
> quirk is because we don't know how many devices have such issue. Every
> time we encounter an IRQ issue in a VIA PCI device, we will suspect it
> requires quirk and keep try. This is a big overhead. 

OK.  Try this one for size.  It differs from what's currently in
the tree in these ways:

    - It's a quirk, so we don't have to clutter acpi_pci_irq_enable()
      and pirq_enable_irq() with Via-specific code.

    - It doesn't do anything unless we're in PIC mode.  The comment
      suggests this issue only affects PIC routing.

    - We do this for ALL Via devices.  The current code in the tree
      does it for all devices in the system IF there is a Via device
      with devfn==0, which misses Grzegorz's case.

Does anybody have a pointer to a spec that talks about this?  It'd
be awfully nice to have a reference.

Grzegorz, can you check to make sure this still works after all the
tweaking?

===== arch/i386/pci/irq.c 1.55 vs edited =====
--- 1.55/arch/i386/pci/irq.c	2005-02-07 22:39:15 -07:00
+++ edited/arch/i386/pci/irq.c	2005-03-15 10:11:44 -07:00
@@ -1026,7 +1026,6 @@
 static int pirq_enable_irq(struct pci_dev *dev)
 {
 	u8 pin;
-	extern int via_interrupt_line_quirk;
 	struct pci_dev *temp_dev;
 
 	pci_read_config_byte(dev, PCI_INTERRUPT_PIN, &pin);
@@ -1081,10 +1080,6 @@
 		printk(KERN_WARNING "PCI: No IRQ known for interrupt pin %c of device %s.%s\n",
 		       'A' + pin, pci_name(dev), msg);
 	}
-	/* VIA bridges use interrupt line for apic/pci steering across
-	   the V-Link */
-	else if (via_interrupt_line_quirk)
-		pci_write_config_byte(dev, PCI_INTERRUPT_LINE, dev->irq & 15);
 	return 0;
 }
 
===== drivers/acpi/pci_irq.c 1.37 vs edited =====
--- 1.37/drivers/acpi/pci_irq.c	2005-03-01 09:57:29 -07:00
+++ edited/drivers/acpi/pci_irq.c	2005-03-15 10:10:57 -07:00
@@ -388,7 +388,6 @@
 	u8			pin = 0;
 	int			edge_level = ACPI_LEVEL_SENSITIVE;
 	int			active_high_low = ACPI_ACTIVE_LOW;
-	extern int		via_interrupt_line_quirk;
 
 	ACPI_FUNCTION_TRACE("acpi_pci_irq_enable");
 
@@ -437,9 +436,6 @@
 			return_VALUE(0);
 		}
  	}
-
-	if (via_interrupt_line_quirk)
-		pci_write_config_byte(dev, PCI_INTERRUPT_LINE, irq & 15);
 
 	dev->irq = acpi_register_gsi(irq, edge_level, active_high_low);
 
===== drivers/pci/quirks.c 1.72 vs edited =====
--- 1.72/drivers/pci/quirks.c	2005-03-10 01:38:25 -07:00
+++ edited/drivers/pci/quirks.c	2005-03-18 10:55:01 -07:00
@@ -683,19 +683,40 @@
 }
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_82454NX,	quirk_disable_pxb );
 
-/*
- *	VIA northbridges care about PCI_INTERRUPT_LINE
- */
-int via_interrupt_line_quirk;
+#ifdef CONFIG_ACPI
+#include <linux/acpi.h>
+#endif
 
-static void __devinit quirk_via_bridge(struct pci_dev *pdev)
+static void __devinit quirk_via_irqpic(struct pci_dev *dev)
 {
-	if(pdev->devfn == 0) {
-		printk(KERN_INFO "PCI: Via IRQ fixup\n");
-		via_interrupt_line_quirk = 1;
+	u8 irq, new_irq;
+
+#ifdef CONFIG_X86_IO_APIC
+	if (skip_ioapic_setup)
+		return;
+#endif
+#ifdef CONFIG_ACPI
+	if (acpi_irq_model != ACPI_IRQ_MODEL_PIC)
+		return;
+#endif
+	/*
+	 * Some Via devices make an internal connection to the PIC when the
+	 * PCI_INTERRUPT_LINE register is written.  If we've changed the
+	 * device's IRQ, we need to update this routing.
+	 *
+	 * I suspect this only happens for devices on the same chip as the
+	 * PIC, but I don't know how to identify those without listing them
+	 * all individually, which is a maintenance problem.
+	 */
+	new_irq = dev->irq & 0xf;
+	pci_read_config_byte(dev, PCI_INTERRUPT_LINE, &irq);
+	if (new_irq != irq) {
+		printk(KERN_INFO "PCI: Via PIC IRQ fixup for %s, from %d to %d\n",
+			pci_name(dev), irq, new_irq);
+		pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
 	}
 }
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA,	PCI_ANY_ID,                     quirk_via_bridge );
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irqpic);
 
 /*
  *	Serverworks CSB5 IDE does not fully support native mode



  parent reply	other threads:[~2005-03-18 18:07 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-05  7:46 Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB Andrew Morton
     [not found] ` <20050304234622.63e8a335.akpm-3NddpPZAyC0@public.gmane.org>
2005-03-05  8:10   ` Patrick Ale
2005-03-10 23:08   ` Grzegorz Kulewski
2005-03-10 23:08     ` Grzegorz Kulewski
     [not found]     ` <Pine.LNX.4.62.0503110006260.30687-xO7mqm7LmoOZ0THcR2OzsA@public.gmane.org>
2005-03-11 16:48       ` Bjorn Helgaas
2005-03-11 16:48         ` [ACPI] " Bjorn Helgaas
2005-03-11 19:36         ` Grzegorz Kulewski
2005-03-11 19:36           ` [ACPI] " Grzegorz Kulewski
     [not found]           ` <Pine.LNX.4.62.0503112009070.22293-xO7mqm7LmoOZ0THcR2OzsA@public.gmane.org>
2005-03-11 20:56             ` Bjorn Helgaas
2005-03-11 20:56               ` [ACPI] " Bjorn Helgaas
2005-03-11 21:47               ` Grzegorz Kulewski
2005-03-11 21:47                 ` [ACPI] " Grzegorz Kulewski
     [not found]                 ` <Pine.LNX.4.62.0503112239580.25254-xO7mqm7LmoOZ0THcR2OzsA@public.gmane.org>
2005-03-11 22:29                   ` Bjorn Helgaas
2005-03-11 22:29                     ` [ACPI] " Bjorn Helgaas
2005-03-12  0:13                     ` Grzegorz Kulewski
2005-03-12  0:13                       ` [ACPI] " Grzegorz Kulewski
2005-03-13 15:14                     ` Grzegorz Kulewski
2005-03-13 15:14                       ` [ACPI] " Grzegorz Kulewski
     [not found]                       ` <Pine.LNX.4.62.0503131607330.23588-xO7mqm7LmoOZ0THcR2OzsA@public.gmane.org>
2005-03-15 19:35                         ` Bjorn Helgaas
2005-03-15 19:35                           ` [ACPI] " Bjorn Helgaas
2005-03-15 23:02                           ` Zwane Mwaikambo
2005-03-15 23:02                             ` [ACPI] " Zwane Mwaikambo
     [not found]                             ` <Pine.LNX.4.61.0503151543420.23036-SOP5cCwKKQRMCHjbocvOOJqQE7yCjDx5@public.gmane.org>
2005-03-16 16:10                               ` Bjorn Helgaas
2005-03-16 16:10                                 ` [ACPI] " Bjorn Helgaas
2005-03-17  1:33                                 ` Li Shaohua
2005-03-17  1:33                                   ` [ACPI] " Li Shaohua
2005-03-17 18:08                                   ` Bjorn Helgaas
2005-03-18  1:09                                     ` Li Shaohua
     [not found]                                       ` <1111108150.22239.6.camel-U5EdaLXB8smDugQYiPIPGdh3ngVCH38I@public.gmane.org>
2005-03-18 18:07                                         ` Bjorn Helgaas [this message]
2005-03-18 18:07                                           ` Bjorn Helgaas
2005-03-21 16:33                                           ` Bjorn Helgaas
2005-03-21 23:33                                             ` Grzegorz Kulewski
2005-03-21 23:33                                               ` [ACPI] " Grzegorz Kulewski
2005-03-22 20:57                                               ` Bjorn Helgaas
     [not found]                                                 ` <41062.15.99.19.46.1111525073.squirrel-hO9VIT4gnBFxnVILBQAtiA@public.gmane.org>
2005-03-23  0:54                                                   ` Li Shaohua
2005-03-23  0:54                                                     ` [ACPI] " Li Shaohua
2005-03-23  3:57                                                     ` Bjorn Helgaas
2005-03-23  3:57                                                       ` Bjorn Helgaas
     [not found]                                                       ` <1110.65.74.231.82.1111550240.squirrel-TOYrGrLsdJ1xnVILBQAtiA@public.gmane.org>
2005-03-23 18:40                                                         ` Len Brown
2005-03-23 18:40                                                           ` [ACPI] " Len Brown
2005-03-24 18:24                                                           ` Bjorn Helgaas
2005-03-24 18:24                                                             ` [ACPI] " Bjorn Helgaas
2005-03-25 19:07                                                             ` Len Brown
2005-03-25 19:07                                                               ` [ACPI] " Len Brown
  -- strict thread matches above, loose matches on Subject: below --
2005-03-14  9:30 Li, Shaohua

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1111169239.13286.39.camel@eeyore \
    --to=bjorn.helgaas-vxdhtt5mjny@public.gmane.org \
    --cc=acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    --cc=akpm-3NddpPZAyC0@public.gmane.org \
    --cc=kangur-ghbW0t/Qn0CsTnJN9+BGXg@public.gmane.org \
    --cc=len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=shaohua.li-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    --cc=zwane-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.