firewire: ohci: fix VIA VT6306 video reception

Add quirk for VT6306 wake bit behavior.

VT6306 seems to reread the wrong descriptor when the wake bit is
written. work around by putting a copy of the branch address in the
first descriptor of the block.

[Stefan R:  This fixes the known broken video reception via gstreamer
on VIA VT6306.  100% repeatable testcase:
$ gst-launch-0.10 dv1394src \! dvdemux \! dvdec \! xvimagesink
with a camcorder or other DV source connected.  Likewise for MPEG2-TS
reception via gstreamer, e.g. from TV settop boxes.
Perhaps this also fixes dv4l on VT6306, but this is as yet untested.
Kino, dvgrab or FFADO had not been affected by this chip quirk.
Additional comments from Andy:]

I've looked into some problems with the wake bit on a vt6306 family
chip (1106:3044, rev 46).

I used this firewire card in a mythtv setup (ISO receive MPEG2 stream)
with Debian 2.6.32 kernels for ~2 years without problems.

Since upgrading to 3.2, I've been having problems with the input stream
freezing -- input data stops until I restart mythtv (I expect closing
and reopening the device would be sufficient). This happens
infrequently, maybe one out of 20 recordings. I eventually determined
that the problem is more likely to occur if the system is loaded.

I isolated the kernel version as the triggering SW factor and then
specifically the change from dualbuffer back to packet-per-buffer DMA
mode.

The possibility that the controller does not properly respond to the
wake bit was suggested in
https://bugzilla.redhat.com/show_bug.cgi?id=415841, but not proven.

Based on the fact that dualbuffer mode worked while packet-per-buffer
has trouble, I guessed that upon seeing the wake bit written, the vt6306
controller only checks the branch address in the first descriptor of the
block, even if that is not the correct place to look (because the block
has multiple descriptors).

This theory seems to be correct. When the ISO reception is hung, I am
able to resume it by manually writing the branch address to the first
descriptor in the block, and then writing the wake bit.

I've had luck so far with the attached patch, so I'm including it. It's
probably not a complete solution -- I haven't tested transmit modes to
see whether they have a similar issue.

I doubt that the quirk test is any cheaper than just writing the extra
branch address in all cases, but it does reduce the risk of breaking
other hardware.

[Stefan R:  omitted QUIRK_NO_MSI from VT6306 quirks table entry,
changed whitespace]

Signed-off-by: Andy Leiserson <andy@leiserson.org>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>

0 files changed, 0 insertions, 0 deletions