Eric Lee / smarc-fsl-linux-kernel

09 Jul, 2011

1 commit

  • cc62a7eb6   USB: EHCI: Allow users to override 80% max periodic bandwidth ... Browse Code »

    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
    Signed-off-by: Kirill Smelkov
    Acked-by: Alan Stern
    Signed-off-by: Greg Kroah-Hartman

    Kirill Smelkov
     

11 Aug, 2010

1 commit

17 Apr, 2005

1 commit

  • 1da177e4c   Linux-2.6.12-rc2 ... Browse Code »

    Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds