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.
Signed-off-by: Stefan Richter <[email protected]>
---
drivers/firewire/ohci.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/firewire/ohci.c
+++ b/drivers/firewire/ohci.c
@@ -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.
Signed-off-by: Stefan Richter <[email protected]>
---
v2: Oops, a table entry is applied if dev->revision <= table[i].revision.
drivers/firewire/ohci.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/drivers/firewire/ohci.c
+++ b/drivers/firewire/ohci.c
@@ -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/
On Apr 16 Stefan Richter wrote:
> 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.
>
> Signed-off-by: Stefan Richter <[email protected]>
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.
> ---
> v2: Oops, a table entry is applied if dev->revision <= table[i].revision.
>
> drivers/firewire/ohci.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> --- a/drivers/firewire/ohci.c
> +++ b/drivers/firewire/ohci.c
> @@ -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/
On Jun 11 Stefan Richter wrote:
> 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.
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/