Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 30 5月, 2008 2 次提交
    • G
      Revert "USB: EHCI: fix performance regression" · bb7e6984
      由 Greg Kroah-Hartman 提交于 
      This reverts commit fa38dfcc.

It wasn't really a regression and David and Alan are still working
through the issues reported.
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      bb7e6984
    • A
      USB: EHCI: fix performance regression · fa38dfcc
      由 Alan Stern 提交于 
      This patch (as1099) fixes a performance regression in ehci-hcd.  The
fundamental problem is that queue headers get removed from the
schedule too quickly, since the code checks for a counter advancing
rather than making an actual time-based check.  The latency involved
in removing the queue header and then relinking it can severely
degrade certain kinds of workloads.

The patch replaces a simple counter with a timestamp derived from the
controller's uframe value.  In addition, the delay for unlinking an
idle queue header is increased from 5 ms to 10 ms; since some
controllers (nVidia) have a latency of up to 1 ms for unlinking, this
reduces the relative impact from 20% to 10%.

Finally, a logical error left over from the IAA watchdog-timer
conversion is corrected.  Now the driver will always either unlink an
idle queue header or set up a timer to unlink it later.  The old code
would sometimes fail to do either.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: David Brownell <david-b@pacbell.net>
Cc: Leonid <leonidv11@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      fa38dfcc
  3. 25 4月, 2008 5 次提交
  5. 28 3月, 2008 1 次提交
  7. 11 3月, 2008 1 次提交
    • D
      USB: fix ehci unlink regressions · e82cc128
      由 David Brownell 提交于 
      The recent EHCI driver update to split the IAA watchdog timer out from
the other timers made several things work better, but not everything;
and it created a couple new issues in bugzilla.  Ergo this patch:

  - Handle a should-be-rare SMP race between the watchdog firing
    and (very late) IAA interrupts;

  - Remove a shouldn't-have-been-added WARN_ON() test;

  - Guard against one observed OOPS;

  - If this watchdog fires during clean HC shutdown, it should act
    as a NOP instead of interfering with the shutdown sequence;

  - Guard against silicon errata hypothesized by some vendors:
      * IAA status latch broken, but IAAD cleared OK;
      * IAAD wasn't cleared when IAA status got reported;

The WARN_ON is in bugzilla as 10168; the OOPS as 10078; these are
both regressions.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Tested-by: NGordon Farquharson <gordonfarquharson@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      e82cc128
  9. 22 2月, 2008 2 次提交
  11. 02 2月, 2008 6 次提交
  13. 29 11月, 2007 1 次提交
    • D
      USB: fix up EHCI startup synchronization · 1cb52658
      由 David Brownell 提交于 
      A recent patch added software synchronization during EHCI startup,
so ports aren't switched away from the companion controllers after
resets have started.  This patch adds a short delay letting hardware
finish that port switching before any new resets begin ... so both
ends of that hardware race window are closed.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Cc: Dave Miller <davem@davemloft.net>
Cc: Dely Sy <dely.l.sy@intel.com>
Cc: stable <stable@kernel.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      1cb52658
  15. 13 10月, 2007 2 次提交
    • A
      USB: mutual exclusion for EHCI init and port resets · 32fe0198
      由 Alan Stern 提交于 
      This patch (as999) fixes a problem that sometimes shows up when host
controller driver modules are loaded in the wrong order.  If ehci-hcd
happens to initialize an EHCI controller while the companion OHCI or
UHCI controller is in the middle of a port reset, the reset can fail
and the companion may get very confused.  The patch adds an
rw-semaphore and uses it to keep EHCI initialization and port resets
mutually exclusive.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Acked-by: NDavid Brownell <david-b@pacbell.net>
Cc: David Miller <davem@davemloft.net>
Cc: Dely L Sy <dely.l.sy@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      32fe0198
    • A
      USB: make HCDs responsible for managing endpoint queues · e9df41c5
      由 Alan Stern 提交于 
      This patch (as954) implements a suggestion of David Brownell's.  Now
the host controller drivers are responsible for linking and unlinking
URBs to/from their endpoint queues.  This eliminates the possiblity of
strange situations where usbcore thinks an URB is linked but the HCD
thinks it isn't.  It also means HCDs no longer have to check for URBs
being dequeued before they were fully enqueued.

In addition to the core changes, this requires changing every host
controller driver and the root-hub URB handler.  For the most part the
required changes are fairly small; drivers have to call
usb_hcd_link_urb_to_ep() in their urb_enqueue method,
usb_hcd_check_unlink_urb() in their urb_dequeue method, and
usb_hcd_unlink_urb_from_ep() before giving URBs back.  A few HCDs make
matters more complicated by the way they split up the flow of control.

In addition some method interfaces get changed.  The endpoint argument
for urb_enqueue is now redundant so it is removed.  The unlink status
is required by usb_hcd_check_unlink_urb(), so it has been added to
urb_dequeue.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
CC: David Brownell <david-b@pacbell.net>
CC: Olav Kongas <ok@artecdesign.ee>
CC: Tony Olech <tony.olech@elandigitalsystems.com>
CC: Yoshihiro Shimoda <shimoda.yoshihiro@renesas.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      e9df41c5
  17. 21 8月, 2007 1 次提交
    • L
      Revert "USB: EHCI cpufreq fix" · 8eb891fc
      由 Linus Torvalds 提交于 
      This reverts commit 196705c9.  It was
reported to cause a regression by Daniel Exner, and Arjan van de Ven
points out that we actually already have infrastructure in place for
setting limits on acceptable DMA latency that would be the much more
correct fix for the problem with some Broadcom EHCI controllers.

Fixed up trivial conflicts due to the changes to support big-endian host
controller descriptors in drivers/usb/host/{ehci-sched.c,ehci.h}.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8eb891fc
  19. 13 7月, 2007 7 次提交
  21. 09 5月, 2007 1 次提交
  23. 12 4月, 2007 1 次提交
    • A
      EHCI: fix remote wakeup regression in 2.6.21-rc · 61e8b858
      由 Alan Stern 提交于 
      There is one significant difference between the behavior of root hubs
(as embodied in host controller hardware) and external hubs: When a
remote-wakeup signal is received, an external hub sends an interrupt
message at the _end_ of the resume sequence but a root hub generates
and interrupt at the _beginning_ of the resume sequence.  The host
system must poll for the end of the sequence.

When ehci-hcd was converted to interrupt-driven operation instead of
using polling, the remaining need for this particular poll was
overlooked.  This patch (as894) fixes the problem.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      61e8b858
  25. 17 2月, 2007 2 次提交
  27. 16 2月, 2007 1 次提交
  29. 08 2月, 2007 4 次提交
  31. 02 12月, 2006 2 次提交
    • A
      EHCI: Fix root-hub and port suspend/resume problems · 8c03356a
      由 Alan Stern 提交于 
      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: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      8c03356a
    • D
      USB: add ehci_hcd.ignore_oc parameter · 93f1a47c
      由 David Brownell 提交于 
      Certain boards seem to like to issue false overcurrent notifications, for
example on ports that don't have anything connected to them.  This looks
like a hardware error, at the level of noise to those ports' overcurrent
input signals (or non-debounced VBUS comparators).  This surfaces to users
as truly massive amounts of syslog spam from khubd (which is appropriate
for real hardware problems, except for the volume from multiple ports).

Using this new "ignore_oc" flag helps such systems work more sanely, by
preventing such indications from getting to khubd (and spam syslog).  The
downside is of course that true overcurrent errors will be masked; they'll
appear as spontaneous disconnects, without the diagnostics that will let
users troubleshoot issues like short circuited cables.

Note that the bulk of these reports seem to be with VIA southbridges, but
I think some were with Intel ones.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      93f1a47c
  33. 18 10月, 2006 1 次提交