• Kirill Smelkov's avatar
    USB: EHCI: Allow users to override 80% max periodic bandwidth · cc62a7eb
    Kirill Smelkov authored
    There are cases, when 80% max isochronous bandwidth is too limiting.
    
    For example I have two USB video capture cards which stream uncompressed
    video, and to stream full NTSC + PAL videos we'd need
    
        NTSC 640x480 YUV422 @30fps      ~17.6 MB/s
        PAL  720x576 YUV422 @25fps      ~19.7 MB/s
    
    isoc bandwidth.
    
    Now, due to limited alt settings in capture devices NTSC one ends up
    streaming with max_pkt_size=2688  and  PAL with max_pkt_size=2892, both
    with interval=1. In terms of microframe time allocation this gives
    
        NTSC    ~53us
        PAL     ~57us
    
    and together
    
        ~110us  >  100us == 80% of 125us uframe time.
    
    So those two devices can't work together simultaneously because the'd
    over allocate isochronous bandwidth.
    
    80% seemed a bit arbitrary to me, and I've tried to raise it to 90% and
    both devices started to work together, so I though sometimes it would be
    a good idea for users to override hardcoded default of max 80% isoc
    bandwidth.
    
    After all, isn't it a user who should decide how to load the bus? If I
    can live with 10% or even 5% bulk bandwidth that should be ok. I'm a USB
    newcomer, but that 80% set in stone by USB 2.0 specification seems to be
    chosen pretty arbitrary to me, just to serve as a reasonable default.
    
    NOTE 1
    ~~~~~~
    
    for two streams with max_pkt_size=3072 (worst case) both time
    allocation would be 60us+60us=120us which is 96% periodic bandwidth
    leaving 4% for bulk and control.  Alan Stern suggested that bulk then
    would be problematic (less than 300*8 bittimes left per microframe), but
    I think that is still enough for control traffic.
    
    NOTE 2
    ~~~~~~
    
    Sarah Sharp expressed concern that maxing out periodic bandwidth
    could lead to vendor-specific hardware bugs on host controllers, because
    
    > It's entirely possible that you'll run into
    > vendor-specific bugs if you try to pack the schedule with isochronous
    > transfers.  I don't think any hardware designer would seriously test or
    > validate their hardware with a schedule that is basically a violation of
    > the USB bus spec (more than 80% for periodic transfers).
    
    So far I've only tested this patch on my HP Mini 5103 with N10 chipset
    
        kirr@mini:~$ lspci
        00:00.0 Host bridge: Intel Corporation N10 Family DMI Bridge
        00:02.0 VGA compatible controller: Intel Corporation N10 Family Integrated Graphics Controller
        00:02.1 Display controller: Intel Corporation N10 Family Integrated Graphics Controller
        00:1b.0 Audio device: Intel Corporation N10/ICH 7 Family High Definition Audio Controller (rev 02)
        00:1c.0 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 1 (rev 02)
        00:1c.3 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 4 (rev 02)
        00:1d.0 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #1 (rev 02)
        00:1d.1 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #2 (rev 02)
        00:1d.2 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #3 (rev 02)
        00:1d.3 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #4 (rev 02)
        00:1d.7 USB Controller: Intel Corporation N10/ICH 7 Family USB2 EHCI Controller (rev 02)
        00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
        00:1f.0 ISA bridge: Intel Corporation NM10 Family LPC Controller (rev 02)
        00:1f.2 SATA controller: Intel Corporation N10/ICH7 Family SATA AHCI Controller (rev 02)
        01:00.0 Network controller: Broadcom Corporation BCM4313 802.11b/g/n Wireless LAN Controller (rev 01)
        02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8059 PCI-E Gigabit Ethernet Controller (rev 11)
    
    and the system works stable with 110us/uframe (~88%) isoc bandwith allocated for
    above-mentioned isochronous transfers.
    
    NOTE 3
    ~~~~~~
    
    This feature is off by default. I mean max periodic bandwidth is set to
    100us/uframe by default exactly as it was before the patch. So only those of us
    who need the extreme settings are taking the risk - normal users who do not
    alter uframe_periodic_max sysfs attribute should not see any change at all.
    
    NOTE 4
    ~~~~~~
    
    I've tried to update documentation in Documentation/ABI/ thoroughly, but
    only "TBD" was put into Documentation/usb/ehci.txt -- the text there seems
    to be outdated and much needing refreshing, before it could be amended.
    
    Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: default avatarKirill Smelkov <kirr@mns.spb.ru>
    Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
    Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
    cc62a7eb
sysfs-module 1.25 KB