aboutsummaryrefslogtreecommitdiff
path: root/MAINTAINERS
diff options
context:
space:
mode:
authorStefan Richter <stefanr@s5r6.in-berlin.de>2009-12-26 01:35:14 +0100
committerStefan Richter <stefanr@s5r6.in-berlin.de>2009-12-29 19:58:17 +0100
commit090699c0530ae5380a9b8511d76f656cc437bb6e (patch)
tree395c61692df693e6562446b2d23b06793f87a0a4 /MAINTAINERS
parentcf0e575dcc4cab9fd955e9bec49df7e8ee30a7cf (diff)
firewire: ohci: always use packet-per-buffer mode for isochronous reception
This is a minimal change meant for the short term: Never set the ohci->use_dualbuffer flag to true. There are two reasons to do so: - Packet-per-buffer mode and dual-buffer mode do not behave the same under certain circumstances, notably if several packets are covered by a single fw_cdev_iso_packet descriptor. http://marc.info/?l=linux1394-devel&m=124965653718313 Therefore the driver stack should not silently choose one or the other mode but should leave the choice to the high-level driver (regardless if kernel driver or userspace driver). Or simply always only offer packet-per-buffer mode, since a considerable number of controllers, even current ones, does not offer dual-buffer support. - Even under circumstances where packet-per-buffer mode and dual-buffer mode behave exactly the same --- notably when used through libraw1394, libdc1394, as well as the current two kernel drivers which use isochronous reception (firewire-net and firedtv) --- we are still faced with the problem that several OHCI 1.1 controllers have bugs in dual-buffer mode. Although it looks like we have identified most of those buggy controllers by now, we cannot be quite sure about that. So, use packet-per-buffer by default from now on. This change should be followed up by a more complete solution: Either extend the in-kernel API and the userspace ABI by a choice between the two IR modes or remove all dual-buffer related code from firewire-ohci. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Diffstat (limited to 'MAINTAINERS')
0 files changed, 0 insertions, 0 deletions