1. 19 3月, 2013 2 次提交
    • A
      USB: EHCI: improve use of per-port status-change bits · 4dd405a4
      Alan Stern 提交于
      This patch (as1634) simplifies some of the code associated with the
      per-port change bits added in EHCI-1.1, and in particular it fixes a
      bug in the logic of ehci_hub_status_data().  Even if the change bit
      doesn't indicate anything happened on a particular port, we still have
      to notify the core about changes to the suspend or reset status.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4dd405a4
    • A
      USB: EHCI: decrease schedule-status poll timeout · 6d5df897
      Alan Stern 提交于
      This patch (as1657) decreases the timeout used by ehci-hcd for polling
      the async and periodic schedule statuses.  The timeout is currently
      set to 20 ms, which is much too high.  Controllers should always
      update the schedule status within one or two ms of being told to do
      so; if they don't then something is wrong.
      
      Furthermore, bug reports have shown that sometimes controllers
      (particularly those made by VIA) don't update the status bit at all,
      even when the schedule does change state.  When this happens, polling
      for 20 ms would cause an unnecessarily long delay.
      
      The delay is reduced to somewhere between 2 and 4 ms, depending on the
      slop allowed by the kernel's high-res timers.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6d5df897
  2. 16 3月, 2013 17 次提交
  3. 27 2月, 2013 1 次提交
    • A
      USB: EHCI: revert "remove ASS/PSS polling timeout" · 221f8dfc
      Alan Stern 提交于
      This patch (as1649) reverts commit
      55bcdce8 (USB: EHCI: remove ASS/PSS
      polling timeout).  That commit was written under the assumption that
      some controllers may take a very long time to turn off their async and
      periodic schedules.  It now appears that in fact the schedules do get
      turned off reasonably quickly, but some controllers occasionally leave
      the schedules' status bits turned on and consequently ehci-hcd can't
      tell that the schedules are off.
      
      VIA controllers in particular have this problem.  ehci-hcd tells the
      hardware to turn off the async schedule, the schedule does get turned
      off, but the status bit remains on.  Since the EHCI spec requires that
      the schedules not be re-enabled until the previous disable has taken
      effect, with an unlimited timeout the async schedule never gets turned
      back on.  The resulting symptom is that the system is unable to
      communicate with USB devices.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Reported-and-tested-by: NRonald <ronald645@gmail.com>
      Reported-and-tested-by: NPaul Hartman <paul.hartman@gmail.com>
      Reported-and-tested-by: NDieter Nützel <dieter@nuetzel-hh.de>
      Reported-and-tested-by: NJean Delvare <khali@linux-fr.org>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      221f8dfc
  4. 21 2月, 2013 3 次提交
  5. 19 2月, 2013 1 次提交
  6. 16 2月, 2013 2 次提交
    • M
      USB: EHCI: make ehci-orion a separate driver · 6ed3c43d
      Manjunath Goudar 提交于
      With the multiplatform changes in arm-soc tree, it becomes
      possible to enable the mvebu platform (which uses
      ehci-orion) at the same time as other platforms that require
      a conflicting EHCI bus glue. At the moment, this results
      in a warning like
      
      drivers/usb/host/ehci-hcd.c:1297:0: warning: "PLATFORM_DRIVER" redefined [enabled by default]
      drivers/usb/host/ehci-hcd.c:1277:0: note: this is the location of the previous definition
      drivers/usb/host/ehci-orion.c:334:31: warning: 'ehci_orion_driver' defined but not used [-Wunused-variable]
      
      and an ehci driver that only works on one of them.
      
      With the infrastructure added by Alan Stern in patch 3e023203
      "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 orion bus glue.
      Signed-off-by: NManjunath Goudar <manjunath.goudar@linaro.org>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6ed3c43d
    • M
      USB: EHCI: make ehci-vt8500 a separate driver · d57ada0c
      Manjunath Goudar 提交于
      With the multiplatform changes in arm-soc tree, it becomes
      possible to enable the vt8500 platform at the same time
      as other platforms that require a conflicting EHCI bus
      glue. At the moment, this results in a warning like
      
      drivers/usb/host/ehci-hcd.c:1277:0: warning: "PLATFORM_DRIVER" redefined [enabled by default]
      drivers/usb/host/ehci-hcd.c:1257:0: note: this is the location of the previous definition
      drivers/usb/host/ehci-omap.c:319:31: warning: 'ehci_hcd_omap_driver' defined but not used [-Wunused-variable]
      
      and an ehci driver that only works on one of them.
      
      With the infrastructure added by Alan Stern in patch 3e023203
      "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 vt8500 bus glue.
      Signed-off-by: NManjunath Goudar <manjunath.goudar@linaro.org>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NTony Prisk <linux@prisktech.co.nz>
      Cc: Alexey Charkov <alchark@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d57ada0c
  7. 15 2月, 2013 2 次提交
  8. 13 2月, 2013 1 次提交
  9. 09 2月, 2013 1 次提交
  10. 31 1月, 2013 2 次提交
  11. 30 1月, 2013 1 次提交
  12. 29 1月, 2013 4 次提交
  13. 26 1月, 2013 3 次提交