1. 18 5月, 2011 1 次提交
    • A
      OHCI: fix regression caused by nVidia shutdown workaround · 2b7aaf50
      Alan Stern 提交于
      This patch (as1463) fixes a regression caused by commit
      3df7169e (OHCI: work around for nVidia
      shutdown problem).
      
      The original problem encountered by people using NVIDIA chipsets was
      that USB devices were not turning off when the system shut down.  For
      example, the LED on an optical mouse would remain on, draining a
      laptop's battery.  The problem was caused by a bug in the chipset; an
      OHCI controller in the Reset state would continue to drive a bus reset
      signal even after system shutdown.  The workaround was to put the
      controllers into the Suspend state instead.
      
      It turns out that later NVIDIA chipsets do not suffer from this bug.
      Instead some have the opposite bug: If a system is shut down while an
      OHCI controller is in the Suspend state, USB devices remain powered!
      On other systems, shutting down with a Suspended controller causes the
      system to reboot immediately.  Thus, working around the original bug
      on some machines exposes other bugs on other machines.
      
      The best solution seems to be to limit the workaround to OHCI
      controllers with a low-numbered PCI product ID.  I don't know exactly
      at what point NVIDIA changed their chipsets; the value used here is a
      guess.  So far it was worked out okay for all the people who have
      tested it.
      
      This fixes Bugzilla #35032.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Tested-by: NAndre "Osku" Schmidt <andre.osku.schmidt@googlemail.com>
      Tested-by: NYury Siamashka <yurand2@gmail.com>
      CC: <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      2b7aaf50
  2. 08 3月, 2011 1 次提交
  3. 02 3月, 2011 1 次提交
    • A
      USB host: Move AMD PLL quirk to pci-quirks.c · ad93562b
      Andiry Xu 提交于
      This patch moves the AMD PLL quirk code in OHCI/EHCI driver to pci-quirks.c,
      and exports the functions to be used by xHCI driver later.
      
      AMD PLL quirk disable the optional PM feature inside specific
      SB700/SB800/Hudson-2/3 platforms under the following conditions:
      
      1. If an isochronous device is connected to OHCI/EHCI/xHCI port and is active;
      2. Optional PM feature that powers down the internal Bus PLL when the link is
         in low power state is enabled.
      
      Without AMD PLL quirk, USB isochronous stream may stutter or have breaks
      occasionally, which greatly impair the performance of audio/video streams.
      
      Currently AMD PLL quirk is implemented in OHCI and EHCI driver, and will be
      added to xHCI driver too. They are doing similar things actually, so move
      the quirk code to pci-quirks.c, which has several advantages:
      
      1. Remove duplicate defines and functions in OHCI/EHCI (and xHCI) driver and
         make them cleaner;
      2. AMD chipset information will be probed only once and then stored.
         Currently they're probed during every OHCI/EHCI initialization, move
         the detect code to pci-quirks.c saves the repeat detect cost;
      3. Build up synchronization among OHCI/EHCI/xHCI driver. In current
         code, every host controller enable/disable PLL only according to
         its own status, and may enable PLL while there is still isoc transfer on
         other HCs. Move the quirk to pci-quirks.c prevents this issue.
      Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
      Cc: David Brownell <dbrownell@users.sourceforge.net>
      Cc: Alex He <alex.he@amd.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      ad93562b
  4. 18 2月, 2011 1 次提交
  5. 05 2月, 2011 1 次提交
    • A
      USB host: Move AMD PLL quirk to pci-quirks.c · b7d5b439
      Andiry Xu 提交于
      This patch moves the AMD PLL quirk code in OHCI/EHCI driver to pci-quirks.c,
      and exports the functions to be used by xHCI driver later.
      
      AMD PLL quirk disable the optional PM feature inside specific
      SB700/SB800/Hudson-2/3 platforms under the following conditions:
      
      1. If an isochronous device is connected to OHCI/EHCI/xHCI port and is active;
      2. Optional PM feature that powers down the internal Bus PLL when the link is
         in low power state is enabled.
      
      Without AMD PLL quirk, USB isochronous stream may stutter or have breaks
      occasionally, which greatly impair the performance of audio/video streams.
      
      Currently AMD PLL quirk is implemented in OHCI and EHCI driver, and will be
      added to xHCI driver too. They are doing similar things actually, so move
      the quirk code to pci-quirks.c, which has several advantages:
      
      1. Remove duplicate defines and functions in OHCI/EHCI (and xHCI) driver and
         make them cleaner;
      2. AMD chipset information will be probed only once and then stored.
         Currently they're probed during every OHCI/EHCI initialization, move
         the detect code to pci-quirks.c saves the repeat detect cost;
      3. Build up synchronization among OHCI/EHCI/xHCI driver. In current
         code, every host controller enable/disable PLL only according to
         its own status, and may enable PLL while there is still isoc transfer on
         other HCs. Move the quirk to pci-quirks.c prevents this issue.
      Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
      Cc: David Brownell <dbrownell@users.sourceforge.net>
      Cc: Alex He <alex.he@amd.com>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      b7d5b439
  6. 23 10月, 2010 1 次提交
    • A
      OHCI: work around for nVidia shutdown problem · 3df7169e
      Alan Stern 提交于
      This patch (as1417) fixes a problem affecting some (or all) nVidia
      chipsets.  When the computer is shut down, the OHCI controllers
      continue to power the USB buses and evidently they drive a Reset
      signal out all their ports.  This prevents attached devices from going
      to low power.  Mouse LEDs stay on, for example, which is disconcerting
      for users and a drain on laptop batteries.
      
      The fix involves leaving each OHCI controller in the OPERATIONAL state
      during system shutdown rather than putting it in the RESET state.
      Although this nominally means the controller is running, in fact it's
      not doing very much since all the schedules are all disabled.  However
      there is ongoing DMA to the Host Controller Communications Area, so
      the patch also disables the bus-master capability of all PCI USB
      controllers after the shutdown routine runs.
      
      The fix is applied only to nVidia-based PCI OHCI controllers, so it
      shouldn't cause problems on systems using other hardware.  As an added
      safety measure, in case the kernel encounters one of these running
      controllers during boot, the patch changes quirk_usb_handoff_ohci()
      (which runs early on during PCI discovery) to reset the controller
      before anything bad can happen.
      Reported-by: NPali Rohár <pali.rohar@gmail.com>
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      CC: David Brownell <david-b@pacbell.net>
      Tested-by: NPali Rohár <pali.rohar@gmail.com>
      CC: stable <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      3df7169e
  7. 11 8月, 2010 1 次提交
  8. 18 11月, 2009 1 次提交
  9. 16 6月, 2009 2 次提交
  10. 18 2月, 2009 1 次提交
  11. 28 1月, 2009 1 次提交
    • R
      USB: Fix suspend-resume of PCI USB controllers · a15d95a0
      Rafael J. Wysocki 提交于
      Commit a0d4922d
      (USB: fix up suspend and resume for PCI host controllers) attempted
      to fix the suspend-resume of PCI USB controllers, but unfortunately
      it did that incorrectly and interrupts are left enabled by the USB
      controllers' ->suspend_late() callback as a result.  This leads to
      serious problems during suspend which are very difficult to debug.
      
      Fix the issue by removing the ->suspend_late() callback of PCI
      USB controllers and moving the code from there to the ->suspend()
      callback executed with interrupts enabled.  Additionally, make
      the ->resume() callback of PCI USB controllers execute
      pci_enable_wake(dev, PCI_D0, false) to disable wake-up from the
      full power state (PCI_D0).
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Tested-by: NAndrey Borzenkov <arvidjaar@mail.ru>
      Tested-by: N"Jeff Chua" <jeff.chua.linux@gmail.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Christian Borntraeger <borntraeger@de.ibm.com>
      Cc: "Zdenek Kabelac" <zdenek.kabelac@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      a15d95a0
  12. 08 1月, 2009 2 次提交
    • A
      USB: automatically enable wakeup for PCI host controllers · 6fd9086a
      Alan Stern 提交于
      This patch (as1193b) enables wakeup during initialization for all PCI
      host controllers, and it removes some code (and comments!) that are no
      longer needed now that the PCI core automatically initializes wakeup
      settings for all new devices.
      
      The idea is that the bus should initialize wakeup, and the bus glue
      or controller driver should enable it.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      6fd9086a
    • A
      USB: fix up suspend and resume for PCI host controllers · a0d4922d
      Alan Stern 提交于
      This patch (as1192) rearranges the USB PCI host controller suspend and
      resume and resume routines:
      
      	Use pci_wake_from_d3() for enabling and disabling wakeup,
      	instead of pci_enable_wake().
      
      	Carry out the actual state change while interrupts are
      	disabled.
      
      	Change the order of the preparations to agree with the
      	general recommendation for PCI devices, instead of
      	messing around with the wakeup settings while the device
      	is in D3.
      
      		In .suspend:
      			Call the underlying driver to disable IRQ
      				generation;
      			pci_wake_from_d3(device_may_wakeup());
      			pci_disable_device();
      
      		In .suspend_late:
      			pci_save_state();
      			pci_set_power_state(D3hot);
      			(for PPC_PMAC) Disable ASIC clocks
      
      		In .resume_early:
      			(for PPC_PMAC) Enable ASIC clocks
      			pci_set_power_state(D0);
      			pci_restore_state();
      
      		In .resume:
      			pci_enable_device();
      			pci_set_master();
      			pci_wake_from_d3(0);
      			Call the underlying driver to reenable IRQ
      				generation
      
      	Add the necessary .suspend_late and .resume_early method
      	pointers to the PCI host controller drivers.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      CC: Rafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      a0d4922d
  13. 22 8月, 2008 1 次提交
    • A
      USB: automatically enable RHSC interrupts · b5fb454f
      Alan Stern 提交于
      This patch (as1069c) changes the way OHCI root-hub status-change
      interrupts are enabled.  Currently a special HCD method,
      hub_irq_enable(), is called when the hub driver is finished using a
      root hub.  This approach turns out to be subject to races, resulting
      in unnecessary polling.
      
      The patch does away with the method entirely.  Instead, the driver
      automatically enables the RHSC interrupt when no more status changes
      are present.  This scheme is safe with controllers using
      level-triggered semantics for their interrupt flags.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      b5fb454f
  14. 14 8月, 2008 1 次提交
  15. 07 7月, 2008 1 次提交
  16. 25 4月, 2008 4 次提交
    • A
      USB: don't explicitly reenable root-hub status interrupts · e8721549
      Alan Stern 提交于
      This patch (as1069b) changes the way OHCI root-hub status-change
      interrupts are enabled.  Currently a special HCD method,
      hub_irq_enable(), is called when the hub driver is finished using a
      root hub.  This approach turns out to be subject to races, resulting
      in unnecessary polling.
      
      The patch does away with the method entirely.  Instead, the driver
      automatically enables the RHSC interrupt when no more status changes
      are present.  This scheme is safe with controllers using
      level-triggered semantics for their interrupt flags.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      e8721549
    • A
      USB: OHCI: host-controller resumes leave root hub suspended · 43bbb7e0
      Alan Stern 提交于
      Drivers in the ohci-hcd family should perform certain tasks whenever
      their controller device is resumed.  These include checking for loss
      of power during suspend, turning on port power, and enabling interrupt
      requests.
      
      Until now these jobs have been carried out when the root hub is
      resumed, not when the controller is.  Many drivers work around the
      resulting awkwardness by automatically resuming their root hub
      whenever the controller is resumed.  But this is wasteful and
      unnecessary.
      
      To simplify the situation, this patch (as1066) adds a new core
      routine, ohci_finish_controller_resume(), which can be used by all the
      OHCI-variant drivers.  They can call the new routine instead of
      resuming their root hubs.  And ohci-pci.c can call it instead of using
      its own special-purpose handler.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      43bbb7e0
    • A
      USB: clarify usage of hcd->suspend/resume methods · 7be7d741
      Alan Stern 提交于
      The .suspend and .resume method pointers in struct usb_hcd have not
      been fully understood by host-controller driver writers.  They are
      meant for use with PCI controllers; other platform-specific drivers
      generally should not refer to them.
      
      To try and clarify matters, this patch (as1065) renames those methods
      to .pci_suspend and .pci_resume.  It eliminates corresponding dead code
      and bogus references in the ohci-ssb and u132-hcd drivers.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      7be7d741
    • A
      USB: OHCI: fix bug in controller resume · 0d22f655
      Alan Stern 提交于
      This patch (as1063) fixes a bug in the way ohci-hcd resumes its
      controllers.  It leaves the Master Interrupt Enable bit turned off.
      
      If the root hub is resumed immediately this won't matter.  But if the
      root hub is suspended (say because no devices are plugged in), it won't
      ever wake up by itself.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      CC: David Brownell <david-b@pacbell.net>
      Cc: stable <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      0d22f655
  17. 13 10月, 2007 1 次提交
    • M
      USB: OHCI handles more ZFMicro quirks · 89a0fd18
      Mike Nuss 提交于
      The ZF Micro OHCI controller exhibits unexpected behavior that seems to be
      related to high load.  Under certain conditions, the controller will
      complete a TD, remove it from the endpoint's queue, and fail to add it to
      the donelist. This causes the endpoint to appear to stop responding. Worse,
      if the device is removed while in that state, OHCI will hang while waiting
      for the orphaned TD to complete.  The situation is not recoverable without
      rebooting.
      
      This fix enhances the scope of the existing OHCI_QUIRK_ZFMICRO flag:
      
       1. A watchdog routine periodically scans the OHCI structures to check
          for orphaned TDs. In these cases the TD is taken back from the
          controller and completed normally.
      
       2. If a device is removed while the endpoint is hung but before the
          watchdog catches the situation, any outstanding TDs are taken back
          from the controller in the 'sanitize' phase.
      
      The ohci-hcd driver used to print "INTR_SF lossage" in this situation;
      this changes it to the universally accurate "ED unlink timeout".  Other
      instances of this message presumably have different root causes.
      
      Both this Compaq quirk and a NEC quirk are now properly compiled out for
      non-PCI builds of this driver.
      Signed-off-by: NMike Nuss <mike@terascala.com>
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      89a0fd18
  18. 13 7月, 2007 2 次提交
    • M
      USB: Fix NEC OHCI chip silicon bug · d576bb9f
      Michael Hanselmann 提交于
      This patch fixes a silicon bug in some NEC OHCI chips. The bug appears
      at random times and is very, very difficult to reproduce. Without the
      following patch, Linux would shut the chip and its associated devices
      down. In Apple PowerBooks this leads to an unusable keyboard and mouse
      (SSH still working). The idea of restarting the chip is taken from
      public Darwin code.
      Signed-off-by: NMichael Hanselmann <linux-kernel@hansmi.ch>
      Cc: David Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      d576bb9f
    • A
      USB: EHCI, OHCI: handover changes · 383975d7
      Alan Stern 提交于
      This patch (as887) changes the way ehci-hcd and ohci-hcd handle a loss
      of VBUS power during suspend.  In order for the USB-persist facility
      to work correctly, it is necessary for low- and full-speed devices
      attached to a high-speed port to be handed back to the companion
      controller during resume processing.
      
      This entails three changes: adding code to ehci-hcd to perform the
      handover, removing code from ohci-hcd to turn off ports during
      root-hub reinit, and adding code to ohci-hcd to turn on ports during
      PCI controller resume.  (Other bus glue resume methods for platforms
      supporting high-speed controllers would need a similar change, if any
      existed.)
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      383975d7
  19. 23 5月, 2007 1 次提交
  20. 28 4月, 2007 2 次提交
  21. 08 2月, 2007 3 次提交
  22. 21 12月, 2006 1 次提交
  23. 29 9月, 2006 1 次提交
  24. 28 9月, 2006 2 次提交
    • A
      USB: Properly unregister reboot notifier in case of failure in ehci hcd · 64a21d02
      Aleksey Gorelov 提交于
      If some problem occurs during ehci startup, for instance, request_irq fails,
      echi hcd driver tries it best to cleanup, but fails to unregister reboot
      notifier, which in turn leads to crash on reboot/poweroff.
      
      The following patch resolves this problem by not using reboot notifiers
      anymore, but instead making ehci/ohci driver get its own shutdown method.  For
      PCI, it is done through pci glue, for everything else through platform driver
      glue.
      
      One downside: sa1111 does not use platform driver stuff, and does not have its
      own shutdown hook, so no 'shutdown' is called for it now.  I'm not sure if it
      is really necessary on that platform, though.
      Signed-off-by: NAleks Gorelov <dared1st@yahoo.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: David Brownell <david-b@pacbell.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      64a21d02
    • D
      USB: OHCI avoids root hub timer polling · d413984a
      David Brownell 提交于
      This teaches OHCI to use the root hub status change (RHSC) IRQ, bypassing
      root hub timers most of the time and switching over to the "new" root hub
      polling scheme.  It's complicated by the fact that implementations of OHCI
      trigger and ack that IRQ differently (the spec is vague there).
      
      Avoiding root hub timers helps mechanisms like "dynamic tick" leave the
      CPU in lowpower modes for longer intervals.
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      d413984a
  25. 26 9月, 2006 1 次提交
  26. 28 4月, 2006 1 次提交
  27. 21 3月, 2006 1 次提交
    • D
      [PATCH] USB: ohci uses driver model wakeup flags · 6a9062f3
      David Brownell 提交于
      This makes OHCI use the driver model wakeup control bits for its root hub
      (e.g. disable on amd756, because of chip erratum) and for the controller
      itself.  It no longer uses the hcd glue bits with those roles, and depends
      on the previous patch making the root hub available earlier.
      
      Note that on most platforms (boot code properly setting the RWC bit) this
      gives a partial workaround for the way PCI isn't currently flagging devices
      that support PME# signals.  (Because of odd PCI init sequencing on PPC.)
      That's because many OHCI controllers support "legacy PCI PM" ... without
      involving any PCI PM capability.
      
      USB wakeup from STR, if it works on your system, may still involve
      tweaking things by hand in /proc/acpi/wakeup.
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      6a9062f3
  28. 30 11月, 2005 1 次提交
    • B
      [PATCH] USB: Fix USB suspend/resume crasher (#2) · 8de98402
      Benjamin Herrenschmidt 提交于
      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: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      8de98402
  29. 24 11月, 2005 1 次提交
  30. 11 11月, 2005 1 次提交