Skip to content

K
Kernel

openeuler / Kernel
12 个月 前同步成功

通知 5
Star 0
Fork 0
K
Kernel

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

切换分支/标签
  1. 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
  3. 04 5月, 2012 1 次提交
    • A
      xHCI: keep track of ports being resumed and indicate in hub_status_data · f370b996
      由 Andiry Xu 提交于 
      This commit adds a bit-array to xhci bus_state for keeping track of
which ports are undergoing a resume transition. If any of the bits
are set when xhci_hub_status_data() is called, the routine will return
a non-zero value even if no ports have any status changes pending.
This will allow usbcore to handle races between root-hub suspend and
port wakeup.

This patch should be backported to kernels as old as 3.4, that contain
the commit 879d38e6 "USB: fix race
between root-hub suspend and remote wakeup".
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: stable@vger.kernel.org
      f370b996
  5. 11 4月, 2012 1 次提交
    • F
      xhci: don't re-enable IE constantly · 4e833c0b
      由 Felipe Balbi 提交于 
      While we're at that, define IMAN bitfield to aid readability.

The interrupt enable bit should be set once on driver init, and we
shouldn't need to continually re-enable it.  Commit c21599a3 introduced
a read of the irq_pending register, and that allows us to preserve the
state of the IE bit.  Before that commit, we were blindly writing 0x3 to
the register.

This patch should be backported to kernels as old as 2.6.36, or ones
that contain the commit c21599a3 "USB:
xhci: Reduce reads and writes of interrupter registers".
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
      4e833c0b
  7. 14 3月, 2012 4 次提交
  9. 13 3月, 2012 2 次提交
  11. 15 2月, 2012 1 次提交
    • S
      USB/xHCI: Support device-initiated USB 3.0 resume. · 4ee823b8
      由 Sarah Sharp 提交于 
      USB 3.0 hubs don't have a port suspend change bit (that bit is now
reserved).  Instead, when a host-initiated resume finishes, the hub sets
the port link state change bit.

When a USB 3.0 device initiates remote wakeup, the parent hubs with
their upstream links in U3 will pass the LFPS up the chain.  The first
hub that has an upstream link in U0 (which may be the roothub) will
reflect that LFPS back down the path to the device.

However, the parent hubs in the resumed path will not set their link
state change bit.  Instead, the device that initiated the resume has to
send an asynchronous "Function Wake" Device Notification up to the host
controller.  Therefore, we need a way to notify the USB core of a device
resume without going through the normal hub URB completion method.

First, make the xHCI roothub act like an external USB 3.0 hub and not
pass up the port link state change bit when a device-initiated resume
finishes.  Introduce a new xHCI bit field, port_remote_wakeup, so that
we can tell the difference between a port coming out of the U3Exit state
(host-initiated resume) and the RExit state (ending state of
device-initiated resume).

Since the USB core can't tell whether a port on a hub has resumed by
looking at the Hub Status buffer, we need to introduce a bitfield,
wakeup_bits, that indicates which ports have resumed.  When the xHCI
driver notices a port finishing a device-initiated resume, we call into
a new USB core function, usb_wakeup_notification(), that will set
the right bit in wakeup_bits, and kick khubd for that hub.

We also call usb_wakeup_notification() when the Function Wake Device
Notification is received by the xHCI driver.  This covers the case where
the link between the roothub and the first-tier hub is in U0, and the
hub reflects the resume signaling back to the device without giving any
indication it has done so until the device sends the Function Wake
notification.

Change the code in khubd that handles the remote wakeup to look at the
state the USB core thinks the device is in, and handle the remote wakeup
if the port's wakeup bit is set.

This patch only takes care of the case where the device is attached
directly to the roothub, or the USB 3.0 hub that is attached to the root
hub is the device sending the Function Wake Device Notification (e.g.
because a new USB device was attached).  The other cases will be covered
in a second patch.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      4ee823b8
  13. 05 1月, 2012 1 次提交
    • H
      xhci: Properly handle COMP_2ND_BW_ERR · 71d85724
      由 Hans de Goede 提交于 
      I encountered a result of COMP_2ND_BW_ERR while improving how the pwc
webcam driver handles not having the full usb1 bandwidth available to
itself.

I created the following test setup, a NEC xhci controller with a
single TT USB 2 hub plugged into it, with a usb keyboard and a pwc webcam
plugged into the usb2 hub. This caused the following to show up in dmesg
when trying to stream from the pwc camera at its highest alt setting:

xhci_hcd 0000:01:00.0: ERROR: unexpected command completion code 0x23.
usb 6-2.1: Not enough bandwidth for altsetting 9

And usb_set_interface returned -EINVAL, which caused my pwc code to not
do the right thing as it expected -ENOSPC.

This patch makes the xhci driver properly handle COMP_2ND_BW_ERR and makes
usb_set_interface return -ENOSPC as expected.

This should be backported to stable kernels as old as 2.6.32.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
      71d85724
  15. 23 12月, 2011 1 次提交
  17. 27 9月, 2011 8 次提交
  19. 21 9月, 2011 3 次提交
  21. 10 9月, 2011 6 次提交
    • S
      xhci: Implement HS/FS/LS bandwidth checking. · c29eea62
      由 Sarah Sharp 提交于 
      Now that we have a bandwidth interval table per root port or TT that
describes the endpoint bandwidth information, we can finally use it to
check whether the bus bandwidth is oversubscribed for a new device
configuration/alternate interface setting.

The complication for this algorithm is that the bit of hardware logic that
creates the bus schedule is only 12-bit logic.  In order to make sure it
can represent the maximum bus bandwidth in 12 bits, it has to convert the
endpoint max packet size and max esit payload into "blocks" (basically a
less-precise representation).  The block size for each speed of device is
different, aside from low speed and full speed.  In order to make sure we
don't allow a setup where the scheduler might fail, we also have to do the
bandwidth checking in blocks.

After checking that the endpoints fit in the schedule, we store the
bandwidth used for this root port or TT.  If this is a FS/LS device under
an external HS hub, we also update the TT bandwidth and the root port
bandwidth (if this is a newly activated or deactivated TT).

I won't go into the details of the algorithm, as it's pretty well
documented in the comments.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      c29eea62
    • S
      xhci: Track interval bandwidth tables per port/TT. · 2e27980e
      由 Sarah Sharp 提交于 
      In order to update the root port or TT's bandwidth interval table, we will
need to keep track of a list of endpoints, per interval.  That way we can
easily know the new largest max packet size when we have to remove an
endpoint.

Add an endpoint list for each root port or TT structure, sorted by
endpoint max packet size.  Insert new endpoints into the list such that
the head of the list always has the endpoint with the greatest max packet
size.  Only insert endpoints and update the interval table with new
information when those endpoints are periodic.

Make sure to update the number of active TTs when we add or drop periodic
endpoints.  A TT is only considered active if it has one or more periodic
endpoints attached (control and bulk are best effort, and counted in the
20% reserved on the high speed bus).  If the number of active endpoints
for a TT was zero, and it's now non-zero, increment the number of active
TTs for the rootport.  If the number of active endpoints was non-zero, and
it's now zero, decrement the number of active TTs.

We have to be careful when we're checking the bandwidth for a new
configuration/alt setting.  If we don't have enough bandwidth, we need to
be able to "roll back" the bandwidth information stored in the endpoint
and the root port/TT interval bandwidth table.  We can't just create a
copy of the interval bandwidth table, modify it, and check the bandwidth
with the copy because we have lists of endpoints and entries can't be on
more than one list.  Instead, we copy the old endpoint bandwidth
information, and use it to revert the interval table when the bandwidth
check fails.

We don't check the bandwidth after endpoints are dropped from the interval
table when a device is reset or freed after a disconnect, because having
endpoints use less bandwidth should not push the bandwidth usage over the
limits.  Besides which, we can't fail a device disconnect.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      2e27980e
    • S
      xhci: Store endpoint bandwidth information. · 9af5d71d
      由 Sarah Sharp 提交于 
      In the upcoming patches, we'll use some stored endpoint information to
make software keep track of the worst-case bandwidth schedule.  We need to
store several variables associated with each periodic endpoint:
 - the type of endpoint
 - Max Packet Size
 - Mult
 - Max ESIT payload
 - Max Burst Size (aka number of packets, stored in one-based form)
 - the endpoint interval (normalized to powers of 2 microframes)

All this information is available to the hardware, and stored in its
device output context.  However, we need to ensure that the new
information is stored before the xHCI driver drops the xhci->lock to wait
on the Configure Endpoint command, so that another driver requesting a
configuration or alt setting change will see the update.  The Configure
Endpoint command will never fail on the hardware that needs this software
bandwidth checking (assuming the slot is enabled and the flags are set
properly), so updating the endpoint info before the command completes
should be fine.

Until we add in the bandwidth checking code, just update the endpoint
information after the Configure Endpoint command completes, and after a
Reset Device command completes.  Don't bother to clear the endpoint
bandwidth info when a device is being freed, since the xhci_virt_ep is
just going to be freed anyway.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      9af5d71d
    • S
      xhci: Store information about roothubs and TTs. · 839c817c
      由 Sarah Sharp 提交于 
      For upcoming patches, we need to keep information about the bandwidth
domains under the xHCI host.  Each root port is a separate primary
bandwidth domain, and each high speed hub's TT (and potentially each port
on a multi-TT hub) is a secondary bandwidth domain.

If the table were in text form, it would look a bit like this:

EP Interval	Sum of Number	Largest Max	Max Packet
		of Packets	Packet Size	Overhead
	0	   N		   mps		  overhead
...
	15	   N		   mps		  overhead

Overhead is the maximum packet overhead (for bit stuffing, CRC, protocol
overhead, etc) for all the endpoints in this interval.  Devices with
different speeds have different max packet overhead.  For example, if
there is a low speed and a full speed endpoint that both have an interval
of 3, we would use the higher overhead (the low speed overhead).  Interval
0 is a bit special, since we really just want to know the sum of the max
ESIT payloads instead of the largest max packet size.  That's stored in
the interval0_esit_payload variable.  For root ports, we also need to keep
track of the number of active TTs.

For each root port, and each TT under a root port, store some information
about the bandwidth consumption.  Dynamically allocate an array of root
port bandwidth information for the number of root ports on the xHCI host.
Each root port stores a list of TTs under the root port.  A single TT hub
only has one entry in the list, but a multi-TT hub will have an entry per
port.

When the USB core says that a USB device is a hub, create one or more
entries in the root port TT list for the hub.  When a device is deleted,
and it is a hub, search through the root port TT list and delete all
TT entries for the hub.  Keep track of which TT entry is associated with a
device under a TT.

LS/FS devices attached directly to the root port will have usb_device->tt
set to the roothub.  Ignore that, and treat it like a primary bandwidth
domain, since there isn't really a high speed bus between the roothub and
the host.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      839c817c
    • S
      xhci: Store the "real" root port number. · 66381755
      由 Sarah Sharp 提交于 
      Since the xHCI driver now has split USB2/USB3 roothubs, devices under each
roothub can have duplicate "fake" port numbers.  For the next set of
patches, we need to keep track of the "real" port number that the xHCI
host uses to index into the port status arrays.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      66381755
    • S
      xhci: Rename virt_dev->port to fake_port. · fe30182c
      由 Sarah Sharp 提交于 
      The "port" field in xhci_virt_dev stores the port number associated with
one of the two xHCI split roothubs, not the unique port number the xHCI
hardware uses.  Since we'll need to store the real hardware port number in
future patches, rename this field to "fake_port".
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      fe30182c
  23. 18 6月, 2011 2 次提交
    • M
      xhci: Add reset on resume quirk for asrock p67 host · c877b3b2
      由 Maarten Lankhorst 提交于 
      The asrock p67 xhci controller completely dies on resume, add a
quirk for this, to bring the host back online after a suspend.

This should be backported to stable kernels as old as 2.6.37.
Signed-off-by: NMaarten Lankhorst <m.b.lankhorst@gmail.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
      c877b3b2
    • A
      xHCI 1.0: Incompatible Device Error · f6ba6fe2
      由 Alex He 提交于 
      It is one new TRB Completion Code for the xHCI spec v1.0.
Asserted if the xHC detects a problem with a device that does not allow it to
be successfully accessed, e.g. due to a device compliance or compatibility
problem. This error may be returned by any command or transfer, and is fatal
as far as the Slot is concerned. Return -EPROTO by urb->status or frame->status
of ISOC for transfer case. And return -ENODEV for configure endpoint command,
evaluate context command and address device command if there is an incompatible
Device Error. The error codes will be sent back to the USB core to decide how
to do. It's unnecessary for other commands because after the three commands run
successfully means that the device has been accepted.
Signed-off-by: NAlex He <alex.he@amd.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      f6ba6fe2
  25. 03 6月, 2011 3 次提交
  27. 28 5月, 2011 2 次提交
    • S
      Intel xhci: Limit number of active endpoints to 64. · 2cf95c18
      由 Sarah Sharp 提交于 
      The Panther Point chipset has an xHCI host controller that has a limit to
the number of active endpoints it can handle.  Ideally, it would signal
that it can't handle anymore endpoints by returning a Resource Error for
the Configure Endpoint command, but they don't.  Instead it needs software
to keep track of the number of active endpoints, across configure endpoint
commands, reset device commands, disable slot commands, and address device
commands.

Add a new endpoint context counter, xhci_hcd->num_active_eps, and use it
to track the number of endpoints the xHC has active.  This gets a little
tricky, because commands to change the number of active endpoints can
fail.  This patch adds a new xHCI quirk for these Intel hosts, and the new
code should not have any effect on other xHCI host controllers.

Fail a new device allocation if we don't have room for the new default
control endpoint.  Use the endpoint ring pointers to determine what
endpoints were active before a Reset Device command or a Disable Slot
command, and drop those once the command completes.

Fail a configure endpoint command if it would add too many new endpoints.
We have to be a bit over zealous here, and only count the number of new
endpoints to be added, without subtracting the number of dropped
endpoints.  That's because a second configure endpoint command for a
different device could sneak in before we know if the first command is
completed.  If the first command dropped resources, the host controller
fails the command for some reason, and we're nearing the limit of
endpoints, we could end up oversubscribing the host.

To fix this race condition, when evaluating whether a configure endpoint
command will fix in our bandwidth budget, only add the new endpoints to
xhci->num_active_eps, and don't subtract the dropped endpoints.  Ignore
changed endpoints (ones that are dropped and then re-added), as that
shouldn't effect the host's endpoint resources.  When the configure
endpoint command completes, subtract off the dropped endpoints.

This may mean some configuration changes may temporarily fail, but it's
always better to under-subscribe than over-subscribe resources.

(Originally my plan had been to push the resource allocation down into the
ring allocation functions.  However, that would cause us to allocate
unnecessary resources when endpoints were changed, because the xHCI driver
allocates a new ring for the changed endpoint, and only deletes the old
ring once the Configure Endpoint command succeeds.  A further complication
would have been dealing with the per-device endpoint ring cache.)
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      2cf95c18
    • S
      Intel xhci: Ignore spurious successful event. · ad808333
      由 Sarah Sharp 提交于 
      The xHCI host controller in the Panther Point chipset sometimes produces
spurious events on the event ring.  If it receives a short packet, it
first puts a Transfer Event with a short transfer completion code on the
event ring.  Then it puts a Transfer Event with a successful completion
code on the ring for the same TD.  The xHCI driver correctly processes the
short transfer completion code, gives the URB back to the driver, and then
prints a warning in dmesg about the spurious event.  These warning
messages really fill up dmesg when an HD webcam is plugged into xHCI.

This spurious successful event behavior isn't technically disallowed by
the xHCI specification, so make the xHCI driver just ignore the spurious
completion event.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      ad808333
  29. 26 5月, 2011 1 次提交
    • S
      xhci: STFU: Be quieter during URB submission and completion. · f444ff27
      由 Sarah Sharp 提交于 
      Unsurprisingly, URBs get submitted and completed a lot in the xHCI
driver.  If we have to print 10 lines of debug for every URB submitted
or completed, then that can cause the whole system to stay in the
interrupt handler too long, and can cause Missed Service completion
codes for isochronous transfers.

Cut down the debugging in the URB submission and completion paths:
 - Don't squawk about successful transfers, only unsuccessful ones.
 - Only print the number of bytes transferred if this was a short
   transfer.
 - Don't print the endpoint index for successful transfers (will add
   more debug to failed transfers to show endpoint index there later).
 - Stop printing MMIO writes.  This debugging shows up when the endpoint
   doorbell is rung a to start a transfer (basically for every URB).
 - Don't print out the ring enqueue and dequeue pointers
 - Stop printing when we're pointing to a link TRB.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      f444ff27
  31. 10 5月, 2011 3 次提交