Skip to content
Snippets Groups Projects
Select Git revision
  • llvm_v4.8
  • dev_smp_nullb
  • dev_smp
  • dev_nullb
  • lcd_v4.8 default
  • dev_foobar
  • dev_ixgbe
  • dev_netdummy
  • depriv
  • dev_idl_4.8_no_channels
  • dev_idl_4.8
  • dev_idl
  • temp_lcd_v4.8
  • idl_fixes
  • lcd
  • lcd_stack_protector
  • irq
  • pmfs
  • dev_nvme
  • async
  • sosp-19
  • v3.11.3
  • v3.10.14
  • v3.4.64
  • v3.0.98
  • v3.12-rc3
  • v3.11.2
  • v3.10.13
  • v3.4.63
  • v3.0.97
  • v3.12-rc2
  • v3.12-rc1
  • v3.11.1
  • v3.10.12
  • v3.4.62
  • v3.0.96
  • v3.2.51
  • v3.10.11
  • v3.4.61
  • v3.0.95
40 results
Search by author
  • Any Author
  • Abhiram Balasubramanian Abhiram Balasubramanian abhiram
  • Anton Burtsev Anton Burtsev aburtsev
  • Charlie Jacobsen Charlie Jacobsen cjacobsen
  • David Detweiler David Detweiler ddetweiler
  • David Johnson David Johnson johnsond
  • Michael Quigley Michael Quigley MichaelQuigley
  • Mike Hibler Mike Hibler hibler
  • Robert Ricci Robert Ricci ricci
  • Sarah Spall Sarah Spall spall
  • Scotty Bauer Scotty Bauer ScottyB
  • Vikram Narayanan Vikram Narayanan vikram
11 authors
  1. Jul 08, 2011
    • 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
  3. Jul 01, 2011
  5. Jun 17, 2011
    • Sarah Sharp's avatar
      USB: Fix up URB error codes to reflect implementation. · a9e75863
      Sarah Sharp authored 
      
Documentation/usb/error-codes.txt mentions that urb->status can be set to
-EXDEV, if the isochronous transfer was not fully completed.  However, in
practice, EHCI, UHCI, and OHCI all only set -EXDEV in the individual frame
status, never in the URB status.  Those host controller actually always
pass in a zero status to usb_hcd_giveback_urb, and rely on the core to set
the appropriate status value.

The xHCI driver ran into issues with the uvcvideo driver when it tried to
set -EXDEV in urb->status, because the driver refused to submit URBs, and
the userspace camera application's video froze.

Clean up the documentation to reflect the actual implementation.

Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      a9e75863
  7. Apr 29, 2011
  9. Mar 22, 2011
  11. Feb 04, 2011
    • Pete Zaitcev's avatar
      USB: usbmon: fix-up docs and text API for sparse ISO · d25bc4db
      Pete Zaitcev authored 
      
This is based on a patch that Alan Stern wrote. It did the same simple
thing in both text and binary cases. In the same time, Marton and I
fixed the binary side properly, but this leaves the text to be fixed.
It is not very important due to low maxium data size of text, but
let's add it just for extra correctness.

The pseudocode is too much to keep fixed up, and we have real code
to be used as examples now, so let's drop it too.

Signed-off-by: default avatarPete Zaitcev <zaitcev@redhat.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      d25bc4db
  13. Nov 16, 2010
    • Alan Stern's avatar
      USB: use the runtime-PM autosuspend implementation · fcc4a01e
      Alan Stern authored 
      
This patch (as1428) converts USB over to the new runtime-PM core
autosuspend framework.  One slightly awkward aspect of the conversion
is that USB devices will now have two suspend-delay attributes: the
old power/autosuspend file and the new power/autosuspend_delay_ms
file.  One expresses the delay time in seconds and the other in
milliseconds, but otherwise they do the same thing.  The old attribute
can be deprecated and then removed eventually.

Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      fcc4a01e
  15. Oct 22, 2010
  17. Aug 10, 2010
  19. Aug 04, 2010
    • Justin P. Mattock's avatar
      Documentation: update broken web addresses. · 0ea6e611
      Justin P. Mattock authored 
      
Below you will find an updated version from the original series bunching all patches into one big patch
updating broken web addresses that are located in Documentation/*
Some of the addresses date as far far back as 1995 etc... so searching became a bit difficult,
the best way to deal with these is to use web.archive.org to locate these addresses that are outdated.
Now there are also some addresses pointing to .spec files some are located, but some(after searching
on the companies site)where still no where to be found. In this case I just changed the address
to the company site this way the users can contact the company and they can locate them for the users.

Signed-off-by: default avatarJustin P. Mattock <justinmattock@gmail.com>
Signed-off-by: default avatarThomas Weber <weber@corscience.de>
Signed-off-by: default avatarMike Frysinger <vapier.adi@gmail.com>
Cc: Paulo Marques <pmarques@grupopie.com>
Cc: Randy Dunlap <rdunlap@xenotime.net>
Cc: Michael Neuling <mikey@neuling.org>
Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      0ea6e611
  21. May 20, 2010
  23. Apr 22, 2010
  25. Mar 02, 2010
    • Alan Stern's avatar
      USB: convert to the runtime PM framework · 9bbdf1e0
      Alan Stern authored 
      
This patch (as1329) converts the USB stack over to the PM core's
runtime PM framework.  This involves numerous changes throughout
usbcore, especially to hub.c and driver.c.  Perhaps the most notable
change is that CONFIG_USB_SUSPEND now depends on CONFIG_PM_RUNTIME
instead of CONFIG_PM.

Several fields in the usb_device and usb_interface structures are no
longer needed.  Some code which used to depend on CONFIG_USB_PM now
depends on CONFIG_USB_SUSPEND (requiring some rearrangement of header
files).

The only visible change in behavior should be that following a system
sleep (resume from RAM or resume from hibernation), autosuspended USB
devices will be resumed just like everything else.  They won't remain
suspended.  But if they aren't in use then they will naturally
autosuspend again in a few seconds.

Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      9bbdf1e0
    • Alan Stern's avatar
      USB: implement usb_enable_autosuspend · 088f7fec
      Alan Stern authored 
      
This patch (as1326) adds usb_enable_autosuspend() and
usb_disable_autosuspend() routines for use by drivers.  If a driver
knows that its device can handle suspends and resumes correctly, it
can enable autosuspend all by itself.  This is equivalent to the user
writing "auto" to the device's power/level attribute.

The implementation differs slightly from what it used to be.  Now
autosuspend is disabled simply by doing usb_autoresume_device() (to
increment the usage counter) and enabled by doing
usb_autosuspend_device() (to decrement the usage counter).

The set_level() attribute method is updated to use the new routines,
and the USB Power-Management documentation is updated.

The patch adds a usb_enable_autosuspend() call to the hub driver's
probe routine, allowing the special-case code for hubs in quirks.c to
be removed.

Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      088f7fec
    • Alan Stern's avatar
      USB: check the endpoint type against the pipe type · f661c6f8
      Alan Stern authored 
      
This patch (as1316) adds some error checking to usb_submit_urb().
It's conditional on CONFIG_USB_DEBUG, so it won't affect normal users.
The new check makes sure that the actual type of the endpoint
described by urb->pipe agrees with the type encoded in the pipe value.

The USB error code documentation is updated to include the code
returned by the new check, and the usbfs SUBMITURB handler is updated
to use the correct pipe type when legacy user code tries to submit a
bulk transfer to an interrupt endpoint.

Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      f661c6f8
  27. Dec 23, 2009
  29. Dec 11, 2009
    • Alan Stern's avatar
      USB: prepare for changover to Runtime PM framework · 8e4ceb38
      Alan Stern authored 
      
This patch (as1303) revises the USB Power Management infrastructure to
make it compatible with the new driver-model Runtime PM framework:

	Drivers are no longer allowed to access intf->pm_usage_cnt
	directly; the PM framework manages its own usage counters.

	usb_autopm_set_interface() is eliminated, because it directly
	sets intf->pm_usage_cnt.

	usb_autopm_enable() and usb_autopm_disable() are eliminated,
	because they call usb_autopm_set_interface().

	usb_autopm_get_interface_no_resume() and
	usb_autopm_put_interface_no_suspend() are added.  They
	correspond to pm_runtime_get_noresume() and
	pm_runtime_put_noidle() in the PM framework.

	The power/level attribute no longer accepts "suspend", only
	"on" and "auto".  The PM framework doesn't allow devices to be
	forced into a suspended mode.

The hub driver contains the only code that violates the new
guidelines.  It is updated to use the new interface routines instead.

Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      8e4ceb38
    • Alan Stern's avatar
      USB: remove the auto_pm flag · fb34d537
      Alan Stern authored 
      
This patch (as1302) removes the auto_pm flag from struct usb_device.
The flag's only purpose was to distinguish between autosuspends and
external suspends, but that information is now available in the
pm_message_t argument passed to suspend methods.

Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      fb34d537
  31. Sep 23, 2009
  33. Jun 12, 2009
  35. Mar 24, 2009
  37. Jan 29, 2009
  39. Jan 07, 2009
  41. Dec 17, 2008