From cc55687124426e3a6a5301780c4e6bb36bb531fd Mon Sep 17 00:00:00 2001 From: Niels de Vos Date: Tue, 31 May 2011 23:00:10 +0100 Subject: ehci-hcd: remove EOL from MODULE_PARM_DESC for 'hird' option There is no need to have a "\n" on a MODULE_PARM_DESC, remove it Signed-off-by: Niels de Vos Signed-off-by: Greg Kroah-Hartman --- drivers/usb/host/ehci-hcd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'drivers/usb/host/ehci-hcd.c') diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c index b435ed67dd5c..e18862c5b059 100644 --- a/drivers/usb/host/ehci-hcd.c +++ b/drivers/usb/host/ehci-hcd.c @@ -110,7 +110,7 @@ MODULE_PARM_DESC (ignore_oc, "ignore bogus hardware overcurrent indications"); /* for link power management(LPM) feature */ static unsigned int hird; module_param(hird, int, S_IRUGO); -MODULE_PARM_DESC(hird, "host initiated resume duration, +1 for each 75us\n"); +MODULE_PARM_DESC(hird, "host initiated resume duration, +1 for each 75us"); #define INTR_MASK (STS_IAA | STS_FATAL | STS_PCD | STS_ERR | STS_INT) -- cgit v1.2.3 From 4c67045bfc2c14a1d3c6040e80eb4a62946282dd Mon Sep 17 00:00:00 2001 From: Kirill Smelkov Date: Sun, 3 Jul 2011 20:36:56 +0400 Subject: USB: EHCI: Move sysfs related bits into ehci-sysfs.c The only sysfs attr implemented so far is "companion" from ehci-hub.c, but in the next patch we are going to add another sysfs file, so prior to that let's structure things and move already-in-there sysfs code to separate file. NOTE: All the code I'm moving into this new file was written by Alan Stern (in 57e06c11 "EHCI: force high-speed devices to run at full speed"; Jan 16 2007), that's why I'm putting Copyright (C) 2007 by Alan Stern there after explicit request from the author. Signed-off-by: Kirill Smelkov Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman --- drivers/usb/host/ehci-hcd.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) (limited to 'drivers/usb/host/ehci-hcd.c') diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c index e18862c5b059..8306155de9e5 100644 --- a/drivers/usb/host/ehci-hcd.c +++ b/drivers/usb/host/ehci-hcd.c @@ -336,6 +336,7 @@ static void ehci_work(struct ehci_hcd *ehci); #include "ehci-mem.c" #include "ehci-q.c" #include "ehci-sched.c" +#include "ehci-sysfs.c" /*-------------------------------------------------------------------------*/ @@ -520,7 +521,7 @@ static void ehci_stop (struct usb_hcd *hcd) ehci_reset (ehci); spin_unlock_irq(&ehci->lock); - remove_companion_file(ehci); + remove_sysfs_files(ehci); remove_debug_files (ehci); /* root hub is shut down separately (first, when possible) */ @@ -754,7 +755,7 @@ static int ehci_run (struct usb_hcd *hcd) * since the class device isn't created that early. */ create_debug_files(ehci); - create_companion_file(ehci); + create_sysfs_files(ehci); return 0; } -- cgit v1.2.3 From cc62a7eb6396e8be95b9a30053ed09191818b99b Mon Sep 17 00:00:00 2001 From: Kirill Smelkov Date: Sun, 3 Jul 2011 20:36:57 +0400 Subject: USB: EHCI: Allow users to override 80% max periodic bandwidth 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 --- drivers/usb/host/ehci-hcd.c | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'drivers/usb/host/ehci-hcd.c') diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c index 8306155de9e5..4ee62bef3723 100644 --- a/drivers/usb/host/ehci-hcd.c +++ b/drivers/usb/host/ehci-hcd.c @@ -571,6 +571,12 @@ static int ehci_init(struct usb_hcd *hcd) hcc_params = ehci_readl(ehci, &ehci->caps->hcc_params); + /* + * by default set standard 80% (== 100 usec/uframe) max periodic + * bandwidth as required by USB 2.0 + */ + ehci->uframe_periodic_max = 100; + /* * hw default: 1K periodic list heads, one per frame. * periodic_size can shrink by USBCMD update if hcc_params allows. -- cgit v1.2.3 From 004c19682884d4f40000ce1ded53f4a1d0b18206 Mon Sep 17 00:00:00 2001 From: Alan Stern Date: Tue, 5 Jul 2011 12:34:05 -0400 Subject: USB: EHCI: go back to using the system clock for QH unlinks This patch (as1477) fixes a problem affecting a few types of EHCI controller. Contrary to what one might expect, these controllers automatically stop their internal frame counter when no ports are enabled. Since ehci-hcd currently relies on the frame counter for determining when it should unlink QHs from the async schedule, those controllers run into trouble: The frame counter stops and the QHs never get unlinked. Some systems have also experienced other problems traced back to commit b963801164618e25fbdc0cd452ce49c3628b46c8 (USB: ehci-hcd unlink speedups), which made the original switch from using the system clock to using the frame counter. It never became clear what the reason was for these problems, but evidently it is related to use of the frame counter. To fix all these problems, this patch more or less reverts that commit and goes back to using the system clock. But this can't be done cleanly because other changes have since been made to the scan_async() subroutine. One of these changes involved the tricky logic that tries to avoid rescanning QHs that have already been seen when the scanning loop is restarted, which happens whenever an URB is given back. Switching back to clock-based unlinks would make this logic even more complicated. Therefore the new code doesn't rescan the entire async list whenever a giveback occurs. Instead it rescans only the current QH and continues on from there. This requires the use of a separate pointer to keep track of the next QH to scan, since the current QH may be unlinked while the scanning is in progress. That new pointer must be global, so that it can be adjusted forward whenever the _next_ QH gets unlinked. (uhci-hcd uses this same trick.) Simplification of the scanning loop removes a level of indentation, which accounts for the size of the patch. The amount of code changed is relatively small, and it isn't exactly a reversion of the b963801164 commit. This fixes Bugzilla #32432. Signed-off-by: Alan Stern CC: Tested-by: Matej Kenda Signed-off-by: Greg Kroah-Hartman --- drivers/usb/host/ehci-hcd.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) (limited to 'drivers/usb/host/ehci-hcd.c') diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c index 4ee62bef3723..2902199fa8ff 100644 --- a/drivers/usb/host/ehci-hcd.c +++ b/drivers/usb/host/ehci-hcd.c @@ -90,7 +90,8 @@ static const char hcd_name [] = "ehci_hcd"; #define EHCI_IAA_MSECS 10 /* arbitrary */ #define EHCI_IO_JIFFIES (HZ/10) /* io watchdog > irq_thresh */ #define EHCI_ASYNC_JIFFIES (HZ/20) /* async idle timeout */ -#define EHCI_SHRINK_FRAMES 5 /* async qh unlink delay */ +#define EHCI_SHRINK_JIFFIES (DIV_ROUND_UP(HZ, 200) + 1) + /* 200-ms async qh unlink delay */ /* Initial IRQ latency: faster than hw default */ static int log2_irq_thresh = 0; // 0 to 6 @@ -148,10 +149,7 @@ timer_action(struct ehci_hcd *ehci, enum ehci_timer_action action) break; /* case TIMER_ASYNC_SHRINK: */ default: - /* add a jiffie since we synch against the - * 8 KHz uframe counter. - */ - t = DIV_ROUND_UP(EHCI_SHRINK_FRAMES * HZ, 1000) + 1; + t = EHCI_SHRINK_JIFFIES; break; } mod_timer(&ehci->watchdog, t + jiffies); -- cgit v1.2.3