summaryrefslogtreecommitdiffstats
path: root/firmware
diff options
context:
space:
mode:
authorStefan Richter <stefanr@s5r6.in-berlin.de>2009-01-20 19:09:58 +0100
committerStefan Richter <stefanr@s5r6.in-berlin.de>2009-01-24 11:17:28 +0100
commit64c634ef83991b390ec0503e61f16efb0ba3c60b (patch)
tree8af40a878618572e51f4c0a3fc1dfbce028aa202 /firmware
parent8b7b6afaa84708d08139daa08538ca3e56c351f1 (diff)
downloadop-kernel-dev-64c634ef83991b390ec0503e61f16efb0ba3c60b.zip
op-kernel-dev-64c634ef83991b390ec0503e61f16efb0ba3c60b.tar.gz
ieee1394: ohci1394: increase AT req. retries, fix ack_busy_X from Panasonic camcorders and others
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 . Tested-by: Mathias Beilstein Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Diffstat (limited to 'firmware')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud