Skip to content

cloud-kernel
cloud-kernel

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

通知 154
Star 36
Fork 7
cloud-kernel
cloud-kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 15 6月, 2012 1 次提交
  3. 14 6月, 2012 9 次提交
  5. 22 5月, 2012 2 次提交
    • S
      xhci: Fix DIV_ROUND_UP compile error. · c88db160
      由 Sarah Sharp 提交于 
      Fengguang reports that the xHCI driver isn't linked properly on his
machine:

ERROR: "__udivdi3" [drivers/usb/host/xhci-hcd.ko] undefined!
ERROR: "handle_edge_irq" [drivers/gpio/gpio-pch.ko] undefined!
ERROR: "irq_to_desc" [drivers/gpio/gpio-pch.ko] undefined!

The driver compiles fine on my 64-bit box (gcc version 4.6.1).
Fengguang thinks it's because the xHCI driver was using DIV_ROUND_UP()
instead of DIV_ROUND_UP_ULL() with arguments that were unsigned long
long variables.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: NWu Fengguang <wfg@linux.intel.com>
      c88db160
    • S
      xhci: Fix compile with CONFIG_USB_SUSPEND=n · b01bcbf7
      由 Sarah Sharp 提交于 
      The USB 2.0 Link PM code is conditionally compiled when
CONFIG_USB_SUSPEND=y.  I believe that's a mistake, since Link PM is not
directly related to USB device suspend and Link PM is implemented
without relying on any of the suspend code in the USB core.  For now,
keep the USB 2.0 Link PM code conditionally compiled if
CONFIG_USB_SUSPEND=y.

This patch does move the code to implement USB 3.0 Link PM out of the
xHCI driver #ifdefs for CONFIG_USB_SUSPEND and moves it into a section
dependent on CONFIG_PM.  The USB core functions for USB 3.0 Link PM are
already conditionally compiled when CONFIG_PM=y.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      b01bcbf7
  7. 21 5月, 2012 1 次提交
  9. 20 5月, 2012 1 次提交
    • M
      USB: EHCI: fix command register configuration lost problem · 1c01f1d9
      由 Ming Lei 提交于 
      The 3d9545cc(EHCI: maintain the
ehci->command value properly) introducs one command register
configuration lost problem by the below line in ehci_reset:

	ehci->command = ehci_readl(ehci, &ehci->regs->command);

After writting RESET into command register, it is restored to
its default value per EHCI spec[1], so the previous configuration
will be lost, and may introduce some problems reported recently:
	- imx51 Babbage board detect usb hub failed[2], reported
	by Richard Zhao.
	- mouse and keyboard hangs in linux-next found by
	Dan Carpenter and Greg-KH.

So this patch just removes the line to fix these problems, and
keep configurating command register consistent as before the commit
3d9545cc(EHCI: maintain the ehci->command value properly).

[1], 4.1 Host Controller Initialization of EHCI Specification 1.0
[2], failed dmesg log:
	usb 1-1: new high-speed USB device number 2 using mxc-ehci
	hub 1-1:1.0: USB hub found
	hub 1-1:1.0: 7 ports detected
	mxc-ehci mxc-ehci.1: fatal error
	mxc-ehci mxc-ehci.1: HC died; cleaning up
	mxc-ehci mxc-ehci.1: force halt; handshake f5780344 00004000 00004000 -> -110
	mxc-ehci mxc-ehci.1: HC died; cleaning up
	usb 1-1: USB disconnect, device number 2
Reported-by: NRichard Zhao <richard.zhao@freescale.com>
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Reported-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Chen Peter-B29397 <B29397@freescale.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NMing Lei <ming.lei@canonical.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1c01f1d9
  11. 19 5月, 2012 8 次提交
    • H
      USB: ehci-platform: remove update_device · 8377c94f
      由 Hauke Mehrtens 提交于 
      The update_device callback is not needed and the function used here is
from the pci ehci driver. Without this patch we get a compile error if
ehci-platform is compiled without ehci-pci.
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Cc: stable <stable@vger.kernel.org> [3.4]
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8377c94f
    • S
      xhci: Add Intel U1/U2 timeout policy. · e3567d2c
      由 Sarah Sharp 提交于 
      All Intel xHCI host controllers support USB 3.0 Link Power Management.

The Panther Point xHCI host controller needs the xHCI driver to
calculate the U1 and U2 timeout values, because it will blindly accept a
MEL that would cause scheduling issues.

The Lynx Point xHCI host controller will reject MEL values that are too
high, but internally it implements the same algorithm that is needed for
Panther Point xHCI.

Simplify the code paths by just having the xHCI driver calculate what
the U1/U2 timeouts should be.  Comments on the policy are in the code.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      e3567d2c
    • S
      xhci: Add infrastructure for host-specific LPM policies. · 3b3db026
      由 Sarah Sharp 提交于 
      The choice of U1 and U2 timeouts for USB 3.0 Link Power Management (LPM)
is highly host controller specific.  Here are a few examples of why it's
host specific:

 1. Setting the U1/U2 timeout too short may cause the link to go into
    U1/U2 in between service intervals, which some hosts may tolerate,
    and some may not.

 2. The host controller has to modify its bus schedule in order to take
    into account the Maximum Exit Latency (MEL) to bring all the links
    from the host to the device into U0.  If the MEL is too big, and it
    takes too long to bring the links into an active state, the host
    controller may not be able to service periodic endpoints in time.

 3. Host controllers may also have scheduling limitations that force
    them to disable U1 or U2 if a USB device is behind too many tiers of
    hubs.

We could take an educated guess at what U1/U2 timeouts may work for a
particular host controller.  However, that would result in a binary
search on every new configuration or alt setting installation, with
multiple failed Evaluate Context commands.  Worse, the host may blindly
accept the timeouts and just fail to update its schedule for U1/U2 exit
latencies, which could result in randomly delayed periodic transfers.

Since we don't want to cause jitter in periodic transfers, or delay
config/alt setting changes too much, lay down a framework that xHCI
vendors can extend in order to add their own U1/U2 timeout policies.

To extend the framework, they will need to:

 - Modify the PCI init code to add a new xhci->quirk for their host, and
   set the XHCI_LPM_SUPPORT quirk flag.
 - Add their own vendor-specific hooks, like the ones that will be added
   in xhci_call_host_update_timeout_for_endpoint() and
   xhci_check_tier_policy()
 - Make the LPM enable/disable methods call those functions based on the
   xhci->quirk for their host.

An example will be provided for the Intel xHCI host controller in the
next patch.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      3b3db026
    • S
      xhci: Reserve one command for USB3 LPM disable. · dbc33303
      由 Sarah Sharp 提交于 
      We want to do everything we can to ensure that USB 3.0 Link Power
Management (LPM) can be disabled when it is enabled.  If LPM can't be
disabled, we can't suspend USB 3.0 devices, or reset them.  To make sure
we can submit the command to disable LPM, allocate a command in the
xhci_hcd structure, and reserve one TRB on the command ring.

We only need one command per xHCI driver instance, because LPM is only
disabled or enabled while the USB core is holding the bandwidth_mutex
that is shared between the xHCI USB 2.0 and USB 3.0 roothubs.  The
bandwidth_mutex will be held until the command completes, or times out.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      dbc33303
    • S
      xhci: Some Evaluate Context commands must succeed. · 4b266541
      由 Sarah Sharp 提交于 
      The upcoming USB 3.0 Link PM patches will introduce new API to enable
and disable low-power link states.  We must be able to disable LPM in
order to reset a device, or place the device into U3 (device suspend).
Therefore, we need to make sure the Evaluate Context command to disable
the LPM timeouts can't fail due to there being no room on the command
ring.

Introduce a new flag to the function that queues the Evaluate Context
command, command_must_succeed.  This tells the ring handler that a TRB
has already been reserved for the command (by incrementing
xhci->cmd_ring_reserved_trbs), and basically ensures that prepare_ring()
won't fail.  A similar flag was already implemented for the Configure
Endpoint command queuing function.

All functions that currently call xhci_configure_endpoint() to issue an
Evaluate Context command pass "false" for the "must_succeed" parameter,
so this patch should have no effect on current xHCI driver behavior.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      4b266541
    • S
      xhci: Add roothub code to set U1/U2 timeouts. · 797b0ca5
      由 Sarah Sharp 提交于 
      USB 3.0 hubs can be put into a mode where the hub can automatically
request that the link go into a deeper link power state after the link
has been idle for a specified amount of time.  Each of the new USB 3.0
link states (U1 and U2) have their own timeout that can be programmed
per port.

Change the xHCI roothub emulation code to handle the request to set the
U1 and U2 timeouts.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      797b0ca5
    • S
      xhci: Reset reserved command ring TRBs on cleanup. · 33b2831a
      由 Sarah Sharp 提交于 
      When the xHCI driver needs to clean up memory (perhaps due to a failed
register restore on resume from S3 or resume from S4), it needs to reset
the number of reserved TRBs on the command ring to zero.  Otherwise,
several resume cycles (about 30) with a UAS device attached will
continually increment the number of reserved TRBs, until all command
submissions fail because there isn't enough room on the command ring.

This patch should be backported to kernels as old as 2.6.32,
that contain the commit 913a8a34
"USB: xhci: Change how xHCI commands are handled."
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
      33b2831a
    • O
      USB: fix resource leak in xhci power loss path · f8a9e72d
      由 Oliver Neukum 提交于 
      Some more data structures must be freed and counters
reset if an XHCI controller has lost power. The failure
to do so renders some chips inoperative after a certain number
of S4 cycles.

This patch should be backported to kernels as old as 3.2,
that contain the commits c29eea62
"xhci: Implement HS/FS/LS bandwidth checking." and
commit 839c817c
"xhci: Implement HS/FS/LS bandwidth checking."
Signed-off-by: NOliver Neukum <oneukum@suse.de>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
      f8a9e72d
  13. 18 5月, 2012 1 次提交
    • S
      xhci: Add new short TX quirk for Fresco Logic host. · 1530bbc6
      由 Sarah Sharp 提交于 
      Sergio reported that when he recorded audio from a USB headset mic
plugged into the USB 3.0 port on his ASUS N53SV-DH72, the audio sounded
"robotic".  When plugged into the USB 2.0 port under EHCI on the same
laptop, the audio sounded fine.  The device is:

Bus 002 Device 004: ID 046d:0a0c Logitech, Inc. Clear Chat Comfort USB Headset

The problem was tracked down to the Fresco Logic xHCI host controller
not correctly reporting short transfers on isochronous IN endpoints.
The driver would submit a 96 byte transfer, the device would only send
88 or 90 bytes, and the xHCI host would report the transfer had a
"successful" completion code, with an untransferred buffer length of 8
or 6 bytes.

The successful completion code and non-zero untransferred length is a
contradiction.  The xHCI host is supposed to only mark a transfer as
successful if all the bytes are transferred.  Otherwise, the transfer
should be marked with a short packet completion code.  Without the EHCI
bus trace, we wouldn't know whether the xHCI driver should trust the
completion code or the untransferred length.  With it, we know to trust
the untransferred length.

Add a new xHCI quirk for the Fresco Logic host controller.  If a
transfer is reported as successful, but the untransferred length is
non-zero, print a warning.  For the Fresco Logic host, change the
completion code to COMP_SHORT_TX and process the transfer like a short
transfer.

This should be backported to stable kernels that contain the commit
f5182b41 "xhci: Disable MSI for some
Fresco Logic hosts."  That commit was marked for stable kernels as old
as 2.6.36.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: NSergio Correia <lists@uece.net>
Tested-by: NSergio Correia <lists@uece.net>
Cc: stable@vger.kernel.org
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      1530bbc6
  15. 15 5月, 2012 4 次提交
  17. 14 5月, 2012 2 次提交
  19. 12 5月, 2012 3 次提交
  21. 10 5月, 2012 3 次提交
  23. 09 5月, 2012 2 次提交
  25. 08 5月, 2012 2 次提交
  27. 07 5月, 2012 1 次提交