firewire: ohci: enable MSI for VIA VT6315 rev 1, drop cycle timer quirk

Commit af0cdf494781 "firewire: ohci: fix regression with VIA VT6315, disable MSI" acted upon a report against VT6315 rev 0:
http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-12/msg02301.html

$ lspci -nn
VIA Technologies, Inc. VT6315 Series Firewire Controller [1106:3403]

I now got a card with

$ lspci -nn
VIA Technologies, Inc. VT6315 Series Firewire Controller [1106:3403] (rev 01)
and this works fine with MSI enabled.

Second, I tested this VT6315 rev 1 without CYCLE_TIMER quirk flag using
http://me.in-berlin.de/~s5r6/linux1394/utils/test_cycle_time_v20100125.c
and found that this chip does in fact access the cycle timer atomically.

Things I can't test because I don't have the hardware:
- whether VT6315 rev 0 really needs QUIRK_CYCLE_TIMER,
- whether the VT6320 PCI device needs QUIRK_CYCLE_TIMER,
- whether the VT6325 and VT6330 PCIe devices need QUIRK_CYCLE_TIMER and QUIRK_NO_MSI.

Hence, just add a whitelist entry specifically for VT6315 rev >= 1 without any quirk flags.

---
 drivers/firewire/ohci.c |    4 ++++
 1 file changed, 4 insertions(+)

@@ -282,6 +282,7 @@ static char ohci_driver_name[] = KBUILD_
 #define PCI_DEVICE_ID_TI_TSB82AA2	0x8025
 #define PCI_DEVICE_ID_VIA_VT630X	0x3044
 #define PCI_REV_ID_VIA_VT6306		0x46
+#define PCI_DEVICE_ID_VIA_VT6315	0x3403
 
 #define QUIRK_CYCLE_TIMER		0x1
 #define QUIRK_RESET_PACKET		0x2

@@ -334,6 +335,9 @@ static const struct {
 	{PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_VT630X, PCI_REV_ID_VIA_VT6306,
 		QUIRK_CYCLE_TIMER | QUIRK_IR_WAKE},
 
+	{PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_VT6315, 1,
+		0},
+
 	{PCI_VENDOR_ID_VIA, PCI_ANY_ID, PCI_ANY_ID,
 		QUIRK_CYCLE_TIMER | QUIRK_NO_MSI},
 };

Stefan Richter
-=====-====- -=-- =----
http://arcgraph.de/sr/

Date:
From: Stefan Richter <[email protected]>
Subject: firewire: ohci: enable MSI for VIA VT6315 rev 1, drop cycle timer quirk

Commit af0cdf494781 "firewire: ohci: fix regression with VIA VT6315, disable MSI" acted upon a report against VT6315 rev 0:
http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-12/msg02301.html

$ lspci -nn
VIA Technologies, Inc. VT6315 Series Firewire Controller [1106:3403]

I now got a card with

$ lspci -nn
VIA Technologies, Inc. VT6315 Series Firewire Controller [1106:3403] (rev 01)
and this works fine with MSI enabled.

Second, I tested this VT6315 rev 1 without CYCLE_TIMER quirk flag using
http://me.in-berlin.de/~s5r6/linux1394/utils/test_cycle_time_v20100125.c
and found that this chip does in fact access the cycle timer atomically.

Things I can't test because I don't have the hardware:
- whether VT6315 rev 0 really needs QUIRK_CYCLE_TIMER,
- whether the VT6320 PCI device needs QUIRK_CYCLE_TIMER,
- whether the VT6325 and VT6330 PCIe devices need QUIRK_CYCLE_TIMER and QUIRK_NO_MSI.

Hence, just add a whitelist entry specifically for VT6315 rev >= 1 without any quirk flags. Before this entry we need an extra entry to catch VT6315 rev <= 0 due to how our ID matching logic works.

---
v2: Oops, a table entry is applied if dev->revision <= table[i].revision.

 drivers/firewire/ohci.c |    7 +++++++
 1 file changed, 7 insertions(+)

@@ -282,6 +282,7 @@ static char ohci_driver_name[] = KBUILD_
 #define PCI_DEVICE_ID_TI_TSB82AA2	0x8025
 #define PCI_DEVICE_ID_VIA_VT630X	0x3044
 #define PCI_REV_ID_VIA_VT6306		0x46
+#define PCI_DEVICE_ID_VIA_VT6315	0x3403
 
 #define QUIRK_CYCLE_TIMER		0x1
 #define QUIRK_RESET_PACKET		0x2

@@ -334,6 +335,12 @@ static const struct {
 	{PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_VT630X, PCI_REV_ID_VIA_VT6306,
 		QUIRK_CYCLE_TIMER | QUIRK_IR_WAKE},
 
+	{PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_VT6315, 0,
+		QUIRK_CYCLE_TIMER | QUIRK_NO_MSI},
+
+	{PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_VT6315, PCI_ANY_ID,
+		0},
+
 	{PCI_VENDOR_ID_VIA, PCI_ANY_ID, PCI_ANY_ID,
 		QUIRK_CYCLE_TIMER | QUIRK_NO_MSI},
 };

Stefan Richter
-=====-====- -=-- =----
http://arcgraph.de/sr/

Nice -- yesterday, just a few days after this patch went into the mainline, this VT6315 card suddenly stopped to generate any interrupt while being in use with a soundcard and jackd. Until then it ran perfectly for many days, with jackd+ffado's combined workload of AT/AR/IT/IR but also with SBP-2 workloads and one or another other application as well.

Now I apparently need to run long-term tests with MSI switched off in order to find out whether this malfunction is MSI related.

Stefan Richter
-=====-====- -==- -=-==
http://arcgraph.de/sr/

PS, this is the state of the card just now after this failure:

10:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6315 Series Firewire Controller (rev 01) (prog-if 10 [OHCI])
Subsystem: VIA Technologies, Inc. VT6315 Series Firewire Controller
Flags: bus master, fast devsel, latency 0, IRQ 74

$ grep "74:" /proc/interrupts 
 74:  132906417   17969317   15309448   18166551   42716375   33292391   30609551   28301206   PCI-MSI-edge      firewire_ohci

I am used to defective MSI support manifesting itself right after driver initialization, not after long periods of use with, say, 319271256 proper interrupts before it goes belly-up. And indeed, the issue with VT6315 rev 0 was an instantaneous malfunction, not a rare and random one
(http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-12/msg02301.html).
I wonder what's up with my VT6315 rev 1.

Stefan Richter
-=====-====- -==- -=-==
http://arcgraph.de/sr/