]> git.karo-electronics.de Git - karo-tx-linux.git/commit
firewire: ohci: increase AT req. retries, fix ack_busy_X from Panasonic camcorders...
authorStefan Richter <stefanr@s5r6.in-berlin.de>
Sat, 7 Feb 2009 12:04:09 +0000 (13:04 +0100)
committerGreg Kroah-Hartman <gregkh@suse.de>
Thu, 12 Feb 2009 17:50:26 +0000 (09:50 -0800)
commit00a3a8d6daf77f5f2df3ec3d164a5077abb8d2d3
tree2687e8734c32b8fab58f3c87c869e0627f4d2fc3
parent437a9be5ddd9b1487a52f2e400b471c741ac82fd
firewire: ohci: increase AT req. retries, fix ack_busy_X from Panasonic camcorders and others

Commit 8b7b6afaa84708d08139daa08538ca3e56c351f1 upstream.

Camcorders have a tendency to fail read requests to their config ROM and
write request to their FCP command register with ack_busy_X.  This has
become a problem with newer kernels and especially Panasonic camcorders,
causing AV/C in dvgrab and kino to fail.  Dvgrab for example frequently
logs "send oops"; kino reports loss of AV/C control.  I suspect that
lower CPU scheduling latencies in newer kernels made this issue more
prominent now.

According to
https://sourceforge.net/tracker/?func=detail&atid=114103&aid=2492640&group_id=14103
this can be fixed by configuring the FireWire controller for more
hardware retries for request transmission; these retries are evidently
more successful than libavc1394's own retry loop (typically 3 tries on
top of hardware retries).

Presumably the same issue has been reported at
https://bugzilla.redhat.com/show_bug.cgi?id=449252 and
https://bugzilla.redhat.com/show_bug.cgi?id=477279 .

In a quick test with a JVC camcorder (which didn't malfunction like the
reported camcorders), this change decreased the number of ack_busy_X
from 16 in three runs of dvgrab to 4 in three runs of the same capture
duration.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
drivers/firewire/fw-ohci.c