Searched +hist:8 +hist:c03356a (Results 1 - 4 of 4) sorted by relevance
/linux-master/drivers/usb/host/ | ||
H A D | ehci-pci.c | diff ee983463 Fri Oct 28 19:45:34 MDT 2022 Brian Norris <briannorris@chromium.org> usb: ehci-pci: Set PROBE_PREFER_ASYNCHRONOUS This driver often takes on the order of 8ms to start, but every little bit counts. It shouldn't have many cross-device dependencies to race with, nor racy access to shared state with other drivers, so this should be a relatively low risk change. This driver was pinpointed as part of a survey of top slowest initcalls (i.e., are built in, and probing synchronously) on a lab of ChromeOS systems. Signed-off-by: Brian Norris <briannorris@chromium.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20221028184507.v2.1.I9a5353f81d1509f85f3a04f0cdc9099f6fe60811@changeid Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> diff 98cae42d Fri Sep 28 14:01:34 MDT 2012 Alan Stern <stern@rowland.harvard.edu> EHCI: use the isochronous scheduling threshold This patch (as1609) changes the way ehci-hcd uses the "Isochronous Scheduling Threshold" in its calculations. Until now the code has ignored the threshold except for certain Intel PCI-based controllers. This violates the EHCI spec. The new code takes the threshold into account always, removing the need for the fs_i_thresh quirk flag. In addition it implements the "full frame cache" setting more efficiently, moving forward only as far as the next frame boundary instead of always moving forward 8 microframes. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> diff 8e192910 Mon May 21 09:54:43 MDT 2012 Greg Kroah-Hartman <gregkh@linuxfoundation.org> Revert "USB: EHCI: work around bug in the Philips ISP1562 controller" This reverts commit 1996e6c572969a8cf6d7fa97eef621219acd94a9. It turned out to not be needed, now that the real fix has been committed. Reported-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> diff 68aa95d5 Wed Oct 12 08:39:14 MDT 2011 Alan Stern <stern@rowland.harvard.edu> EHCI: workaround for MosChip controller bug This patch (as1489) works around a hardware bug in MosChip EHCI controllers. Evidently when one of these controllers increments the frame-index register, it changes the three low-order bits (the microframe counter) before changing the higher order bits (the frame counter). If the register is read at just the wrong time, the value obtained is too low by 8. When the appropriate quirk flag is set, we work around this problem by reading the frame-index register a second time if the first value's three low-order bits are all 0. This gives the hardware a chance to finish updating the register, yielding the correct value. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Jason N Pitt <jpitt@fhcrc.org> CC: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> diff c430131a Tue May 03 12:11:57 MDT 2011 Jan Andersson <jan@gaisler.com> USB: EHCI: Support controllers with big endian capability regs The two first HC capability registers (CAPLENGTH and HCIVERSION) are defined as one 8-bit and one 16-bit register. Most HC implementations have selected to treat these registers as part of a 32-bit register, giving the same layout for both big and small endian systems. This patch adds a new quirk, big_endian_capbase, to support controllers with big endian register interfaces that treat HCIVERSION and CAPLENGTH as individual registers. Signed-off-by: Jan Andersson <jan@gaisler.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> diff 8d053c79 Thu Aug 20 14:39:54 MDT 2009 Jason Wessel <jason.wessel@windriver.com> USB: ehci-dbgp,ehci: Allow early or late use of the dbgp device If the EHCI debug port is initialized and in use, the EHCI host controller driver must follow two rules. 1) If the EHCI host driver issues a controller reset, the debug controller driver re-initialization must get called after the reset is completed. 2) The EHCI host driver should ignore any requests to the physical EHCI debug port when the EHCI debug port is in use. The code to check for the debug port was moved from ehci_pci_reinit() to ehci_pci_setup because it must get called prior to ehci_reset() which will clear the debug port registers. Signed-off-by: Jason Wessel <jason.wessel@windriver.com> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: dbrownell@users.sourceforge.net Cc: Ingo Molnar <mingo@elte.hu> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Yinghai Lu <yinghai@kernel.org> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> diff 8c03356a Thu Nov 09 12:42:16 MST 2006 Alan Stern <stern@rowland.harvard.edu> EHCI: Fix root-hub and port suspend/resume problems This patch (as738b) fixes numerous problems in the controller/root-hub suspend/resume/remote-wakeup support in ehci-hcd: The bus_resume() routine should wake up only the ports that were suspended by bus_suspend(). Ports that were already suspended should remain that way. The interrupt mask is used to detect loss of power in the bus_resume() routine (if the mask is 0 then power was lost). However bus_suspend() always sets the mask to 0. Instead the mask should retain its normal value, with port-change-detect interrupts disabled if remote wakeup is turned off. The interrupt mask should be reset to its correct value at the end of bus_resume() regardless of whether power was lost. bus_resume() reinitializes the operational registers if power was lost. However those registers are not in the aux power well, hence they can lose their values whenever the controller is put into D3. They should always be reinitialized. When a port-change interrupt occurs and the root hub is suspended, the interrupt handler should request a root-hub resume instead of starting up the controller all by itself. There's no need for the interrupt handler to request a root-hub resume every time a suspended port sends a remote-wakeup request. The pci_resume() method doesn't need to check for connected ports when deciding whether or not to reset the controller. It can make that decision based on whether Vaux power was maintained. Even when the controller does not need to be reset, pci_resume() must undo the effect of pci_suspend() by re-enabling the interrupt mask. If power was lost, pci_resume() must not call ehci_run(). At this point the root hub is still supposed to be suspended, not running. It's enough to rewrite the command register and set the configured_flag. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> diff 8c03356a Thu Nov 09 12:42:16 MST 2006 Alan Stern <stern@rowland.harvard.edu> EHCI: Fix root-hub and port suspend/resume problems This patch (as738b) fixes numerous problems in the controller/root-hub suspend/resume/remote-wakeup support in ehci-hcd: The bus_resume() routine should wake up only the ports that were suspended by bus_suspend(). Ports that were already suspended should remain that way. The interrupt mask is used to detect loss of power in the bus_resume() routine (if the mask is 0 then power was lost). However bus_suspend() always sets the mask to 0. Instead the mask should retain its normal value, with port-change-detect interrupts disabled if remote wakeup is turned off. The interrupt mask should be reset to its correct value at the end of bus_resume() regardless of whether power was lost. bus_resume() reinitializes the operational registers if power was lost. However those registers are not in the aux power well, hence they can lose their values whenever the controller is put into D3. They should always be reinitialized. When a port-change interrupt occurs and the root hub is suspended, the interrupt handler should request a root-hub resume instead of starting up the controller all by itself. There's no need for the interrupt handler to request a root-hub resume every time a suspended port sends a remote-wakeup request. The pci_resume() method doesn't need to check for connected ports when deciding whether or not to reset the controller. It can make that decision based on whether Vaux power was maintained. Even when the controller does not need to be reset, pci_resume() must undo the effect of pci_suspend() by re-enabling the interrupt mask. If power was lost, pci_resume() must not call ehci_run(). At this point the root hub is still supposed to be suspended, not running. It's enough to rewrite the command register and set the configured_flag. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> diff 8de98402 Thu Nov 24 15:59:46 MST 2005 Benjamin Herrenschmidt <benh@kernel.crashing.org> [PATCH] USB: Fix USB suspend/resume crasher (#2) This patch closes the IRQ race and makes various other OHCI & EHCI code path safer vs. suspend/resume. I've been able to (finally !) successfully suspend and resume various Mac models, with or without USB mouse plugged, or plugging while asleep, or unplugging while asleep etc... all without a crash. Alan, please verify the UHCI bit I did, I only verified that it builds. It's very simple so I wouldn't expect any issue there. If you aren't confident, then just drop the hunks that change uhci-hcd.c I also made the patch a little bit more "safer" by making sure the store to the interrupt register that disables interrupts is not posted before I set the flag and drop the spinlock. Without this patch, you cannot reliably sleep/wakeup any recent Mac, and I suspect PCs have some more sneaky issues too (they don't frankly crash with machine checks because x86 tend to silently swallow PCI errors but that won't last afaik, at least PCI Express will blow up in those situations, but the USB code may still misbehave). Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> |
H A D | ehci.h | diff 8af0219e Mon Jan 25 18:44:50 MST 2016 Geyslan G. Bem <geyslan@gmail.com> usb: host: ehci.h: remove macros trailing semicolon Removes trailing semicolon from macros. Caught by checkpatch: "WARNING: macros should not use a trailing semicolon" Signed-off-by: Geyslan G. Bem <geyslan@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> diff 98cae42d Fri Sep 28 14:01:34 MDT 2012 Alan Stern <stern@rowland.harvard.edu> EHCI: use the isochronous scheduling threshold This patch (as1609) changes the way ehci-hcd uses the "Isochronous Scheduling Threshold" in its calculations. Until now the code has ignored the threshold except for certain Intel PCI-based controllers. This violates the EHCI spec. The new code takes the threshold into account always, removing the need for the fs_i_thresh quirk flag. In addition it implements the "full frame cache" setting more efficiently, moving forward only as far as the next frame boundary instead of always moving forward 8 microframes. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> diff 8c5bf7be Wed Jul 11 09:22:39 MDT 2012 Alan Stern <stern@rowland.harvard.edu> USB: EHCI: don't refcount iso_stream structures This patch (as1580) makes ehci_iso_stream structures behave more like QHs, in that they will remain allocated until their isochronous endpoint is disabled. This will come in useful in the future, when periodic bandwidth gets allocated as an altsetting is installed rather than on-the-fly. For now, the change to the ehci_iso_stream lifetimes means that each structure is always deallocated at exactly one spot in ehci_endpoint_disable() and never used again. As a result, it is no longer necessary to use reference counting on these things, and the patch removes it. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> diff 8e192910 Mon May 21 09:54:43 MDT 2012 Greg Kroah-Hartman <gregkh@linuxfoundation.org> Revert "USB: EHCI: work around bug in the Philips ISP1562 controller" This reverts commit 1996e6c572969a8cf6d7fa97eef621219acd94a9. It turned out to not be needed, now that the real fix has been committed. Reported-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> diff 68aa95d5 Wed Oct 12 08:39:14 MDT 2011 Alan Stern <stern@rowland.harvard.edu> EHCI: workaround for MosChip controller bug This patch (as1489) works around a hardware bug in MosChip EHCI controllers. Evidently when one of these controllers increments the frame-index register, it changes the three low-order bits (the microframe counter) before changing the higher order bits (the frame counter). If the register is read at just the wrong time, the value obtained is too low by 8. When the appropriate quirk flag is set, we work around this problem by reading the frame-index register a second time if the first value's three low-order bits are all 0. This gives the hardware a chance to finish updating the register, yielding the correct value. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Jason N Pitt <jpitt@fhcrc.org> CC: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> diff cc62a7eb Sun Jul 03 10:36:57 MDT 2011 Kirill Smelkov <kirr@mns.spb.ru> 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 <sarah.a.sharp@linux.intel.com> Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> diff c430131a Tue May 03 12:11:57 MDT 2011 Jan Andersson <jan@gaisler.com> USB: EHCI: Support controllers with big endian capability regs The two first HC capability registers (CAPLENGTH and HCIVERSION) are defined as one 8-bit and one 16-bit register. Most HC implementations have selected to treat these registers as part of a 32-bit register, giving the same layout for both big and small endian systems. This patch adds a new quirk, big_endian_capbase, to support controllers with big endian register interfaces that treat HCIVERSION and CAPLENGTH as individual registers. Signed-off-by: Jan Andersson <jan@gaisler.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> diff b9638011 Tue Jun 03 23:21:55 MDT 2008 David Brownell <dbrownell@users.sourceforge.net> USB: ehci-hcd unlink speedups This patch fixes some performance bugs observed with some workloads when unlinking EHCI queue header (QH) descriptors from the async ring (control/bulk schedule). The mechanism intended to defer unlinking an empty QH (so there is no penalty in common cases where it's quickly reused) was not working as intended. Sometimes the unlink was scheduled: - too quickly ... which can be a *strong* negative effect, since that QH becomes unavailable for immediate re-use; - too slowly ... wasting DMA cycles, usually a minor issue except for increased bus contention and power usage; Plus there was an extreme case of "too slowly": a logical error in the IAA watchdog-timer conversion meant that sometimes the unlink never got scheduled. The fix replaces a simple counter with a timestamp derived from the controller's 8 KHz microframe counter, and adjusts the timer usage for some issues associated with HZ being less than 8K. (Based on a patch originally by Alan Stern, and good troubleshooting from Leonid.) Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Leonid <leonidv11@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> diff b9638011 Tue Jun 03 23:21:55 MDT 2008 David Brownell <dbrownell@users.sourceforge.net> USB: ehci-hcd unlink speedups This patch fixes some performance bugs observed with some workloads when unlinking EHCI queue header (QH) descriptors from the async ring (control/bulk schedule). The mechanism intended to defer unlinking an empty QH (so there is no penalty in common cases where it's quickly reused) was not working as intended. Sometimes the unlink was scheduled: - too quickly ... which can be a *strong* negative effect, since that QH becomes unavailable for immediate re-use; - too slowly ... wasting DMA cycles, usually a minor issue except for increased bus contention and power usage; Plus there was an extreme case of "too slowly": a logical error in the IAA watchdog-timer conversion meant that sometimes the unlink never got scheduled. The fix replaces a simple counter with a timestamp derived from the controller's 8 KHz microframe counter, and adjusts the timer usage for some issues associated with HZ being less than 8K. (Based on a patch originally by Alan Stern, and good troubleshooting from Leonid.) Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Leonid <leonidv11@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> diff 3b6fcfd0 Sun Dec 30 22:55:05 MST 2007 Karsten Wiese <fzu@wemgehoertderstaat.de> USB: ehci saves some memory in ISO transfer descriptors In the EHCI driver, itd->usecs[8] is used in periodic_usecs(), indexed by uframe. For an ITD's unused uframes it is 0, else it contains the same value as itd->stream->usecs. To check if an ITD's uframe is used, we can instead test itd->hw_transaction[uframe]: if used, it will be nonzero no matter what endianess is used. This patch replaces those two uses, eliminates itd->usecs[], and saves eight bytes from each ITD. Signed-off-by: Karsten Wiese <fzu@wemgehoertderstaat.de> Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> |
H A D | ehci-hub.c | diff 8df0d77d Mon Jan 25 13:45:38 MST 2016 Alan Stern <stern@rowland.harvard.edu> USB: EHCI: improvements to unlink_empty_async_suspended() unlink_empty_async_suspended() is marked __maybe_unused. This is because its caller, ehci_bus_suspend(), is protected by "#ifdef CONFIG_PM". We should use the same protection here instead of __maybe_unused. unlink_empty_async_suspended() gets called only when the root hub is suspended. It's silly for it to call start_iaa_cycle() at such a time; the IAA mechanism doesn't work when the root hub isn't running. It should call end_unlink_async() instead. But even this isn't necessary, since there already is a call to end_iaa_cycle() right before the call to unlink_empty_async_suspended(). All we have to do is interchange the two subroutine calls. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> diff 8d053c79 Thu Aug 20 14:39:54 MDT 2009 Jason Wessel <jason.wessel@windriver.com> USB: ehci-dbgp,ehci: Allow early or late use of the dbgp device If the EHCI debug port is initialized and in use, the EHCI host controller driver must follow two rules. 1) If the EHCI host driver issues a controller reset, the debug controller driver re-initialization must get called after the reset is completed. 2) The EHCI host driver should ignore any requests to the physical EHCI debug port when the EHCI debug port is in use. The code to check for the debug port was moved from ehci_pci_reinit() to ehci_pci_setup because it must get called prior to ehci_reset() which will clear the debug port registers. Signed-off-by: Jason Wessel <jason.wessel@windriver.com> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: dbrownell@users.sourceforge.net Cc: Ingo Molnar <mingo@elte.hu> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Yinghai Lu <yinghai@kernel.org> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> diff 8c774fe8 Thu Feb 01 14:09:59 MST 2007 Alan Stern <stern@rowland.harvard.edu> EHCI: add debugging message to ehci_bus_suspend This patch (as848) adds a useful little debugging message to let us know when ehci-hcd's bus_suspend method runs. The other HCDs have similar messages; now ehci-hcd doesn't need to feel left out. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> diff 8c03356a Thu Nov 09 12:42:16 MST 2006 Alan Stern <stern@rowland.harvard.edu> EHCI: Fix root-hub and port suspend/resume problems This patch (as738b) fixes numerous problems in the controller/root-hub suspend/resume/remote-wakeup support in ehci-hcd: The bus_resume() routine should wake up only the ports that were suspended by bus_suspend(). Ports that were already suspended should remain that way. The interrupt mask is used to detect loss of power in the bus_resume() routine (if the mask is 0 then power was lost). However bus_suspend() always sets the mask to 0. Instead the mask should retain its normal value, with port-change-detect interrupts disabled if remote wakeup is turned off. The interrupt mask should be reset to its correct value at the end of bus_resume() regardless of whether power was lost. bus_resume() reinitializes the operational registers if power was lost. However those registers are not in the aux power well, hence they can lose their values whenever the controller is put into D3. They should always be reinitialized. When a port-change interrupt occurs and the root hub is suspended, the interrupt handler should request a root-hub resume instead of starting up the controller all by itself. There's no need for the interrupt handler to request a root-hub resume every time a suspended port sends a remote-wakeup request. The pci_resume() method doesn't need to check for connected ports when deciding whether or not to reset the controller. It can make that decision based on whether Vaux power was maintained. Even when the controller does not need to be reset, pci_resume() must undo the effect of pci_suspend() by re-enabling the interrupt mask. If power was lost, pci_resume() must not call ehci_run(). At this point the root hub is still supposed to be suspended, not running. It's enough to rewrite the command register and set the configured_flag. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> diff 8c03356a Thu Nov 09 12:42:16 MST 2006 Alan Stern <stern@rowland.harvard.edu> EHCI: Fix root-hub and port suspend/resume problems This patch (as738b) fixes numerous problems in the controller/root-hub suspend/resume/remote-wakeup support in ehci-hcd: The bus_resume() routine should wake up only the ports that were suspended by bus_suspend(). Ports that were already suspended should remain that way. The interrupt mask is used to detect loss of power in the bus_resume() routine (if the mask is 0 then power was lost). However bus_suspend() always sets the mask to 0. Instead the mask should retain its normal value, with port-change-detect interrupts disabled if remote wakeup is turned off. The interrupt mask should be reset to its correct value at the end of bus_resume() regardless of whether power was lost. bus_resume() reinitializes the operational registers if power was lost. However those registers are not in the aux power well, hence they can lose their values whenever the controller is put into D3. They should always be reinitialized. When a port-change interrupt occurs and the root hub is suspended, the interrupt handler should request a root-hub resume instead of starting up the controller all by itself. There's no need for the interrupt handler to request a root-hub resume every time a suspended port sends a remote-wakeup request. The pci_resume() method doesn't need to check for connected ports when deciding whether or not to reset the controller. It can make that decision based on whether Vaux power was maintained. Even when the controller does not need to be reset, pci_resume() must undo the effect of pci_suspend() by re-enabling the interrupt mask. If power was lost, pci_resume() must not call ehci_run(). At this point the root hub is still supposed to be suspended, not running. It's enough to rewrite the command register and set the configured_flag. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> |
H A D | ehci-hcd.c | diff 8b84724e Tue Jul 07 13:50:23 MDT 2020 Gustavo A. R. Silva <gustavoars@kernel.org> usb: host: Use fallthrough pseudo-keyword Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. [1] https://www.kernel.org/doc/html/latest/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://lore.kernel.org/r/20200707195023.GA3792@embeddedor Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> diff 8c68e84f Tue Apr 02 10:24:03 MDT 2013 Manjunath Goudar <manjunath.goudar@linaro.org> USB: EHCI: make ehci-msm a separate driver Separate the Qualcomm QSD/MSM on-chip host controller driver from ehci-hcd host code so that it can be built as a separate driver module. This work is part of enabling multi-platform kernels on ARM; however, note that other changes are still needed before Qualcomm QSD/MSM can be booted with a multi-platform kernel, which is not expected before 3.11. With the infrastructure added by Alan Stern in patch 3e0232039 "USB: EHCI: prepare to make ehci-hcd a library module", we can avoid this problem by turning a bus glue into a separate module, as we do here for the msm bus glue. In V5 (arnd): - add FIXME about missing usb_add_hcd() or usb_remove_hcd() calls In V3: - Detailed commit message added here describing why this patch is required. - Arranged #include's in alphabetical order. - driver.name initialized hcd_name[] = "ehci-msm" in platform_driver structure initialization instead of "msm-ehci", which was the reason why it broke in EHCI USB testing In V2: Tegra patch related changes removed from this patch. Signed-off-by: Manjunath Goudar <manjunath.goudar@linaro.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: David Brown <davidb@codeaurora.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> diff 98cae42d Fri Sep 28 14:01:34 MDT 2012 Alan Stern <stern@rowland.harvard.edu> EHCI: use the isochronous scheduling threshold This patch (as1609) changes the way ehci-hcd uses the "Isochronous Scheduling Threshold" in its calculations. Until now the code has ignored the threshold except for certain Intel PCI-based controllers. This violates the EHCI spec. The new code takes the threshold into account always, removing the need for the fs_i_thresh quirk flag. In addition it implements the "full frame cache" setting more efficiently, moving forward only as far as the next frame boundary instead of always moving forward 8 microframes. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> diff 8c5bf7be Wed Jul 11 09:22:39 MDT 2012 Alan Stern <stern@rowland.harvard.edu> USB: EHCI: don't refcount iso_stream structures This patch (as1580) makes ehci_iso_stream structures behave more like QHs, in that they will remain allocated until their isochronous endpoint is disabled. This will come in useful in the future, when periodic bandwidth gets allocated as an altsetting is installed rather than on-the-fly. For now, the change to the ehci_iso_stream lifetimes means that each structure is always deallocated at exactly one spot in ehci_endpoint_disable() and never used again. As a result, it is no longer necessary to use reference counting on these things, and the patch removes it. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> diff 8e192910 Mon May 21 09:54:43 MDT 2012 Greg Kroah-Hartman <gregkh@linuxfoundation.org> Revert "USB: EHCI: work around bug in the Philips ISP1562 controller" This reverts commit 1996e6c572969a8cf6d7fa97eef621219acd94a9. It turned out to not be needed, now that the real fix has been committed. Reported-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> diff 68aa95d5 Wed Oct 12 08:39:14 MDT 2011 Alan Stern <stern@rowland.harvard.edu> EHCI: workaround for MosChip controller bug This patch (as1489) works around a hardware bug in MosChip EHCI controllers. Evidently when one of these controllers increments the frame-index register, it changes the three low-order bits (the microframe counter) before changing the higher order bits (the frame counter). If the register is read at just the wrong time, the value obtained is too low by 8. When the appropriate quirk flag is set, we work around this problem by reading the frame-index register a second time if the first value's three low-order bits are all 0. This gives the hardware a chance to finish updating the register, yielding the correct value. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Jason N Pitt <jpitt@fhcrc.org> CC: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> diff cc62a7eb Sun Jul 03 10:36:57 MDT 2011 Kirill Smelkov <kirr@mns.spb.ru> 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 <sarah.a.sharp@linux.intel.com> Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> diff c430131a Tue May 03 12:11:57 MDT 2011 Jan Andersson <jan@gaisler.com> USB: EHCI: Support controllers with big endian capability regs The two first HC capability registers (CAPLENGTH and HCIVERSION) are defined as one 8-bit and one 16-bit register. Most HC implementations have selected to treat these registers as part of a 32-bit register, giving the same layout for both big and small endian systems. This patch adds a new quirk, big_endian_capbase, to support controllers with big endian register interfaces that treat HCIVERSION and CAPLENGTH as individual registers. Signed-off-by: Jan Andersson <jan@gaisler.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> diff 5a0e3ad6 Wed Mar 24 02:04:11 MDT 2010 Tejun Heo <tj@kernel.org> include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: Tejun Heo <tj@kernel.org> Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com> diff dccd574c Tue Oct 27 11:55:05 MDT 2009 Sarah Sharp <sarah.a.sharp@linux.intel.com> USB: ehci: Respect IST when scheduling new split iTDs. The EHCI specification says that an EHCI host controller may cache part of the isochronous schedule. The EHCI controller must advertise how much it caches in the schedule through the HCCPARAMS register isochronous scheduling threshold (IST) bits. In theory, adding new iTDs within the IST should be harmless. The HW will follow the old cached linked list and miss the new iTD. SW will notice HW missed the iTD and return 0 for the transfer length. However, Intel ICH9 chipsets (and some later chipsets) have issues when SW attempts to schedule a split transaction within the IST. All transfers will cease being sent out that port, and the drivers will see isochronous packets complete with a length of zero. Start of frames may or may not also disappear, causing the device to go into auto-suspend. This "bus stall" will continue until a control or bulk transfer is queued to a device under that roothub. Most drivers will never cause this behavior, because they use multiple URBs with multiple packets to keep the bus busy. If you limit the number of URBs to one, you may be able to hit this bug. Make sure the EHCI driver does not schedule full-speed transfers within the IST under an Intel chipset. Make sure that when we fall behind the current microframe plus IST, we schedule the new transfer at the next periodic interval after the IST. Don't change the scheduling for new transfers, since the schedule slop will always be greater than the IST. Allow high speed isochronous transfers to be scheduled within the IST, since this doesn't trigger the Intel chipset bug. Make sure that if the host caches the full frame, the EHCI driver's internal isochronous threshold (ehci->i_thresh) is set to 8 microframes + 2 microframes wiggle room. This is similar to what is done in the case where the host caches less than the full frame. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: David Brownell <dbrownell@users.sourceforge.net> Cc: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> |
Completed in 531 milliseconds