In commit 3610ea5397 (ehci: workaround for pci
quirk timeout on ExoPC), a workaround was added to skip the negociation for
the handoff of the EHCI controller.
Refactor the DMI detection code to use standard dmi_check_system function.
Signed-off-by: Anisse Astier <anisse@astier.eu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
There are cases, when 80% max isochronous bandwidth is too limiting.
For example I have two USB video capture cards which stream uncompressed
video, and to stream full NTSC + PAL videos we'd need
NTSC 640x480 YUV422 @30fps ~17.6 MB/s
PAL 720x576 YUV422 @25fps ~19.7 MB/s
isoc bandwidth.
Now, due to limited alt settings in capture devices NTSC one ends up
streaming with max_pkt_size=2688 and PAL with max_pkt_size=2892, both
with interval=1. In terms of microframe time allocation this gives
NTSC ~53us
PAL ~57us
and together
~110us > 100us == 80% of 125us uframe time.
So those two devices can't work together simultaneously because the'd
over allocate isochronous bandwidth.
80% seemed a bit arbitrary to me, and I've tried to raise it to 90% and
both devices started to work together, so I though sometimes it would be
a good idea for users to override hardcoded default of max 80% isoc
bandwidth.
After all, isn't it a user who should decide how to load the bus? If I
can live with 10% or even 5% bulk bandwidth that should be ok. I'm a USB
newcomer, but that 80% set in stone by USB 2.0 specification seems to be
chosen pretty arbitrary to me, just to serve as a reasonable default.
NOTE 1
~~~~~~
for two streams with max_pkt_size=3072 (worst case) both time
allocation would be 60us+60us=120us which is 96% periodic bandwidth
leaving 4% for bulk and control. Alan Stern suggested that bulk then
would be problematic (less than 300*8 bittimes left per microframe), but
I think that is still enough for control traffic.
NOTE 2
~~~~~~
Sarah Sharp expressed concern that maxing out periodic bandwidth
could lead to vendor-specific hardware bugs on host controllers, because
> It's entirely possible that you'll run into
> vendor-specific bugs if you try to pack the schedule with isochronous
> transfers. I don't think any hardware designer would seriously test or
> validate their hardware with a schedule that is basically a violation of
> the USB bus spec (more than 80% for periodic transfers).
So far I've only tested this patch on my HP Mini 5103 with N10 chipset
kirr@mini:~$ lspci
00:00.0 Host bridge: Intel Corporation N10 Family DMI Bridge
00:02.0 VGA compatible controller: Intel Corporation N10 Family Integrated Graphics Controller
00:02.1 Display controller: Intel Corporation N10 Family Integrated Graphics Controller
00:1b.0 Audio device: Intel Corporation N10/ICH 7 Family High Definition Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 1 (rev 02)
00:1c.3 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 4 (rev 02)
00:1d.0 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #3 (rev 02)
00:1d.3 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #4 (rev 02)
00:1d.7 USB Controller: Intel Corporation N10/ICH 7 Family USB2 EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
00:1f.0 ISA bridge: Intel Corporation NM10 Family LPC Controller (rev 02)
00:1f.2 SATA controller: Intel Corporation N10/ICH7 Family SATA AHCI Controller (rev 02)
01:00.0 Network controller: Broadcom Corporation BCM4313 802.11b/g/n Wireless LAN Controller (rev 01)
02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8059 PCI-E Gigabit Ethernet Controller (rev 11)
and the system works stable with 110us/uframe (~88%) isoc bandwith allocated for
above-mentioned isochronous transfers.
NOTE 3
~~~~~~
This feature is off by default. I mean max periodic bandwidth is set to
100us/uframe by default exactly as it was before the patch. So only those of us
who need the extreme settings are taking the risk - normal users who do not
alter uframe_periodic_max sysfs attribute should not see any change at all.
NOTE 4
~~~~~~
I've tried to update documentation in Documentation/ABI/ thoroughly, but
only "TBD" was put into Documentation/usb/ehci.txt -- the text there seems
to be outdated and much needing refreshing, before it could be amended.
Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The only sysfs attr implemented so far is "companion" from ehci-hub.c,
but in the next patch we are going to add another sysfs file, so prior
to that let's structure things and move already-in-there sysfs code to
separate file.
NOTE: All the code I'm moving into this new file was written by Alan
Stern (in 57e06c11 "EHCI: force high-speed devices to run at full
speed"; Jan 16 2007), that's why I'm putting
Copyright (C) 2007 by Alan Stern
there after explicit request from the author.
Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This controller can control "Transaction Translators", but
the hcd->has_tt is not set.
Since the commit d199c96d41
("USB: prevent buggy from crashing the USB stack") has checked it,
the driver could not work the low/full speed device.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Loading the ehci-hcd module on the ath79 platform causes
a NULL pointer dereference:
CPU 0 Unable to handle kernel paging request at virtual address 00000000, epc == c0252928, ra == c00de968
Oops[#1]:
Cpu 0
$ 0 : 00000000 00000070 00000001 00000000
$ 4 : 802cf870 0000117e ffffffff 8019c7bc
$ 8 : 0000000a 00000002 00000001 fffffffb
$12 : 8026ef20 0000000f ffffff80 802dad3c
$16 : 8077a2d4 8077a200 c00f3484 8019ed84
$20 : c00f0000 00000003 000000a0 80262c2c
$24 : 00000002 80079da0
$28 : 80788000 80789c80 80262b14 c00de968
Hi : 00000000
Lo : b61f0000
epc : c0252928 __mod_vermagic5+0xc260/0xc7e8 [ehci_hcd]
Not tainted
ra : c00de968 usb_add_hcd+0x2a4/0x858 [usbcore]
Status: 1000c003 KERNEL EXL IE
Cause : 00800008
BadVA : 00000000
PrId : 00019374 (MIPS 24Kc)
Modules linked in: ehci_hcd(+) pppoe pppox ipt_REJECT xt_TCPMSS ipt_LOG
xt_comment xt_multiport xt_mac xt_limit iptable_mangle iptable_filte
r ip_tables xt_tcpudp x_tables ppp_async ppp_generic slhc ath mac80211
usbcore nls_base input_polldev crc_ccitt cfg80211 compat input_core a
rc4 aes_generic crypto_algapi
Process insmod (pid: 379, threadinfo=80788000, task=80ca2180,
tls=77fe52d0)
Stack : c0253184 80c57d80 80789cac 8077a200 00000001 8019edc0 807fa800 8077a200
8077a290 c00f3484 8019ed84 c00f0000 00000003 000000a0 80262c2c c00de968
802d0000 800878cc c0253228 c02528e4 c0253184 80c57d80 80bf6800 80ca2180
8007b75c 00000000 8077a200 802cf830 802d0000 00000003 fffffff4 00000015
00000348 00000124 800b189c c024bb4c c0255000 801a27e8 c0253228 c02528e4
...
Call Trace:
[<c0252928>] __mod_vermagic5+0xc260/0xc7e8 [ehci_hcd]
It is caused by:
commit c430131a02
Author: Jan Andersson <jan@gaisler.com>
Date: Tue May 3 20:11:57 2011 +0200
USB: EHCI: Support controllers with big endian capability regs
The two first HC capability registers (CAPLENGTH and HCIVERSION)
are defined as one 8-bit and one 16-bit register. Most HC
implementations have selected to treat these registers as part
of a 32-bit register, giving the same layout for both big and
small endian systems.
This patch adds a new quirk, big_endian_capbase, to support
controllers with big endian register interfaces that treat
HCIVERSION and CAPLENGTH as individual registers.
Signed-off-by: Jan Andersson <jan@gaisler.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The reading of the HC capability register has been moved by that
commit to a place where the ehci->caps field is not initialized
yet. This patch moves the reading of the register back to the
original place.
Acked-by: Jan Andersson <jan@gaisler.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Both control and bulk transfers use isp1760 slots of type ATL, but the
driver unlink code for ATL slots only acts on urbs describing a bulk
transfer, letting the code for INT slots take care of the unlink instead,
which often ended up removing the interrupt transfer for root hub events
instead. That's not good, and gets fixed by this patch.
Signed-off-by: Arvid Brodin <arvid.brodin@enea.com>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* 'for-usb-linus' of git+ssh://master.kernel.org/pub/scm/linux/kernel/git/sarah/xhci:
USB: Fix up URB error codes to reflect implementation.
xhci: Always set urb->status to zero for isoc endpoints.
xhci: Add reset on resume quirk for asrock p67 host
xHCI 1.0: Incompatible Device Error
xHCI 1.0: Force Stopped Event(FSE)
xhci: Don't warn about zeroed bMaxBurst descriptor field.
USB: Free bandwidth when usb_disable_device is called.
xhci: Reject double add of active endpoints.
When the xHCI driver encounters a Missed Service Interval event for an
isochronous endpoint ring, it means the host controller skipped over
one or more isochronous TDs. For TD that is skipped, skip_isoc_td() is
called. This sets the frame descriptor status to -EXDEV, and also sets
the value stored in the int pointed to by status to -EXDEV.
If the isochronous TD happens to be the last TD in an URB,
handle_tx_event() will use the status variable to give back the URB to
the USB core. That means drivers will see urb->status as -EXDEV.
It turns out that EHCI, UHCI, and OHCI always set urb->status to zero for
an isochronous urb, regardless of what the frame status is. See
itd_complete() in ehci-sched.c:
} else {
/* URB was too late */
desc->status = -EXDEV;
}
}
/* handle completion now? */
if (likely ((urb_index + 1) != urb->number_of_packets))
goto done;
/* ASSERT: it's really the last itd for this urb
list_for_each_entry (itd, &stream->td_list, itd_list)
BUG_ON (itd->urb == urb);
*/
/* give urb back to the driver; completion often (re)submits */
dev = urb->dev;
ehci_urb_done(ehci, urb, 0);
ehci_urb_done() completes the URB with the status of the third argument, which
is always zero in this case.
It turns out that many USB webcam drivers, such as uvcvideo, cannot
handle urb->status set to a non-zero value. They will not resubmit
their isochronous URBs in that case, and userspace will see a frozen
video.
Change the xHCI driver to be consistent with the EHCI and UHCI driver,
and always set urb->status to 0 for isochronous URBs.
This patch should be backported to kernels as old as 2.6.36
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: "Xu, Andiry" <Andiry.Xu@amd.com>
Cc: stable@kernel.org
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: Maarten Lankhorst <m.b.lankhorst@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
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: Alex He <alex.he@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Following the loss of David Brownell, I volunteer to maintain the
ohci-hcd and ehci-hcd drivers. This patch (as1472) makes it official.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
FSE shall occur on the TD natural boundary. The software ep_ring dequeue pointer
exceed the hardware ep_ring dequeue pointer in these cases of Table-3. As a
result, the event_trb(pointed by hardware dequeue pointer) of the FSE can't be
found in the current TD(pointed by software dequeue pointer). What should we do
is to figured out the FSE case and skip over it.
Signed-off-by: Alex He <alex.he@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The USB 3.0 specification says that the bMaxBurst field in the SuperSpeed
Endpoint Companion descriptor is supposed to indicate how many packets a
SS device can handle before it needs to wait for an explicit handshake
from the host controller. A zero value means the device can only handle
one packet before it needs a handshake. Remove a warning in the xHCI
driver that implies this is an invalid value.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
While trying to switch a UAS device from the BOT configuration to the UAS
configuration via the bConfigurationValue file, Tanya ran into an issue in
the USB core. usb_disable_device() sets entries in udev->ep_out and
udev->ep_out to NULL, but doesn't call into the xHCI bandwidth management
functions to remove the BOT configuration endpoints from the xHCI host's
internal structures.
The USB core would then attempt to add endpoints for the UAS
configuration, and some of the endpoints had the same address as endpoints
in the BOT configuration. The xHCI driver blindly added the endpoints
again, but the xHCI host controller rejected the Configure Endpoint
command because active endpoints were added without being dropped.
Make the xHCI driver reject calls to xhci_add_endpoint() that attempt to
add active endpoints without first calling xhci_drop_endpoint().
This should be backported to kernels as old as 2.6.31.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Tanya Brokhman <tlinder@codeaurora.org>
Cc: stable@kernel.org
Several fixes as well where the +1 was missing.
Done via coccinelle scripts like:
@@
struct resource *ptr;
@@
- ptr->end - ptr->start + 1
+ resource_size(ptr)
and some grep and typing.
Mostly uncompiled, no cross-compilers.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
There is no need to have a "\n" on a MODULE_PARM_DESC, remove it
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Add a label before the call to clk_put and jump to that in the error
handling code that occurs after the call to clk_get has succeeded.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@r exists@
expression e1,e2;
statement S;
@@
e1 = clk_get@p1(...);
... when != e1 = e2
when != clk_put(e1)
when any
if (...) { ... when != clk_put(e1)
when != if (...) { ... clk_put(e1) ... }
* return@p3 ...;
} else S
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Acked-by: Eric Miao <eric.y.miao@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch adds power management support such as suspend and resume
functions.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Full-speed isoc endpoints specify interval in exponent based form in
frames, not microframes, so we need to adjust accordingly.
NEC xHCI host controllers will return an error code of 0x11 if a full
speed isochronous endpoint is added with the Interval field set to
something less than 3 (2^3 = 8 microframes, or one frame). It is
impossible for a full speed device to have an interval smaller than one
frame.
This was always an issue in the xHCI driver, but commit
dfa49c4ad1 "USB: xhci - fix math in
xhci_get_endpoint_interval()" removed the clamping of the minimum value
in the Interval field, which revealed this bug.
This needs to be backported to stable kernels back to 2.6.31.
Reported-by: Matt Evans <matt@ozlabs.org>
Signed-off-by: Dmitry Torokhov <dtor@vmware.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
Some Fresco Logic hosts, including those found in the AUAU N533V laptop,
advertise MSI, but fail to actually generate MSI interrupts. Add a new
xHCI quirk to skip MSI enabling for the Fresco Logic host controllers.
Fresco Logic confirms that all chips with PCI vendor ID 0x1b73 and device
ID 0x1000, regardless of PCI revision ID, do not support MSI.
This should be backported to stable kernels as far back as 2.6.36, which
was the first kernel to support MSI on xHCI hosts.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Sergey Galanov <sergey.e.galanov@gmail.com>
Cc: stable@kernel.org
xHCI controllers respond to a Reset Device command when the Slot is in the
Enabled/Disabled state by returning an error. This is fine on other host
controllers, but the Etron xHCI host controller returns a vendor-specific
error code that the xHCI driver doesn't understand. The xHCI driver then
gives up on device enumeration.
Instead of issuing a command that will fail, just return. This fixes the
issue with the xhci driver not working on ASRock P67 Pro/Extreme boards.
This should be backported to stable kernels as far back as 2.6.34.
Signed-off-by: Maarten Lankhorst <m.b.lankhorst@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
This needs to be added to the stable trees back to 2.6.34 to support an
upcoming bug fix.
Signed-off-by: Maarten Lankhorst <m.b.lankhorst@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
Some of the recently-added cpu_to_leXX and leXX_to_cpu made things somewhat
messy; this patch neatens some of these areas, removing unnecessary casts
in those parts also. In some places (where Y & Z are constants) a
comparison of (leXX_to_cpu(X) & Y) == Z has been replaced with
(X & cpu_to_leXX(Y)) == cpu_to_leXX(Z). The endian reversal of the
constants should wash out at compile time.
Signed-off-by: Matt Evans <matt@ozlabs.org>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Commit 834cb0fc47 "xhci: Fix memory leak
bug when dropping endpoints" added a small endian bug. This patch fixes
xhci_check_bandwidth() to read add/drop_flags LE.
Signed-off-by: Matt Evans <matt@ozlabs.org>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Commit 926008c938 "USB: xhci: simplify logic
of skipping missed isoc TDs" added a small endian bug. This patch
fixes skip_isoc_td() to read the DMA pointer correctly.
Signed-off-by: Matt Evans <matt@ozlabs.org>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* 'for-usb-next' of git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci:
Intel xhci: Limit number of active endpoints to 64.
Intel xhci: Ignore spurious successful event.
Intel xhci: Support EHCI/xHCI port switching.
Intel xhci: Add PCI id for Panther Point xHCI host.
xhci: STFU: Be quieter during URB submission and completion.
xhci: STFU: Don't print event ring dequeue pointer.
xhci: STFU: Remove function tracing.
xhci: Don't submit commands when the host is dead.
xhci: Clear stopped_td when Stop Endpoint command completes.
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: Sarah Sharp <sarah.a.sharp@linux.intel.com>
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: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The Intel Panther Point chipsets contain an EHCI and xHCI host controller
that shares some number of skew-dependent ports. These ports can be
switched from the EHCI to the xHCI host (and vice versa) by a hardware MUX
that is controlled by registers in the xHCI PCI configuration space. The
USB 3.0 SuperSpeed terminations on the xHCI ports can be controlled
separately from the USB 2.0 data wires.
This switchover mechanism is there to support users who do a custom
install of certain non-Linux operating systems that don't have official
USB 3.0 support. By default, the ports are under EHCI, SuperSpeed
terminations are off, and USB 3.0 devices will show up under the EHCI
controller at reduced speeds. (This was more palatable for the marketing
folks than having completely dead USB 3.0 ports if no xHCI drivers are
available.) Users should be able to turn on xHCI by default through a
BIOS option, but users are happiest when they don't have to change random
BIOS settings.
This patch introduces a driver method to switchover the ports from EHCI to
xHCI before the EHCI driver finishes PCI enumeration. We want to switch
the ports over before the USB core has the chance to enumerate devices
under EHCI, or boot from USB mass storage will fail if the boot device
connects under EHCI first, and then gets disconnected when the port
switches over to xHCI.
Add code to the xHCI PCI quirk to switch the ports from EHCI to xHCI. The
PCI quirks code will run before any other PCI probe function is called, so
this avoids the issue with boot devices.
Another issue is with BIOS behavior during system resume from hibernate.
If the BIOS doesn't support xHCI, it may switch the devices under EHCI to
allow use of the USB keyboard, mice, and mass storage devices. It's
supposed to remember the value of the port routing registers and switch
them back when the OS attempts to take control of the xHCI host controller,
but we all know not to trust BIOS writers.
Make both the xHCI driver and the EHCI driver attempt to switchover the
ports in their PCI resume functions. We can't guarantee which PCI device
will be resumed first, so this avoids any race conditions. Writing a '1'
to an already set port switchover bit or a '0' to a cleared port switchover
bit should have no effect.
The xHCI PCI configuration registers will be documented in the EDS-level
chipset spec, which is not public yet. I have permission from legal and
the Intel chipset group to release this patch early to allow good Linux
support at product launch. I've tried to document the registers as much
as possible, so please let me know if anything is unclear.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
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: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Stop printing out the event ring dequeue pointer and status register in
the operational register set. The host will report an OK status 99% of
the time the interrupt handler is called, and usually when it's really
hosed, a host controller won't even call the interrupt handler. So the
line is really useless.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Remove unnecessary debugging from the xHCI driver. We don't need to
know what function we're calling or returning from. Now I know how to
use markup-oops.pl to de-mystify stack dumps of crashes.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
When the xHCI host controller dies, the USB core may attempt to reset the
devices to their default configuration before disconnecting them. This
causes calls into the xHCI bandwidth allocation functions. Don't allow
those functions to submit commands or work on xHCI structures if the host
controller is marked as dying.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
When an URB is cancelled, the xHCI driver issues a Stop Endpoint command
so that it can manipulate the ring and remove the transfer. The xHC
hardware then places a transfer event with the completion code "Stopped"
or "Stopped Invalid" to let the driver know what TD it was in the middle
of processing. This TD and TRB is stored in ep->stopped_td and
ep->stopped_trb. These pointers are also used in handling stalled
endpoints.
By design, the Stop Endpoint command can race with URB completion. By
the time the Stop Endpoint command is handled, the URBs to be cancelled
may have been given back to the driver. Unfortunately, the stopped_td
and stopped_trb pointers were not getting cleared in this case.
The USB core unconditionally tries to reset the toggle bits on any
endpoints when a new alternate interface setting is installed. When the
xHCI driver saw that ep->stopped_td was still set from the Stop Endpoint
command, xhci_reset_endpoint assumed the endpoint was actually stalled,
and attempted to clean up the endpoint rings. This would manifest
itself in a failed Reset Endpoint command and failed Set TR dequeue
Pointer command after a successful Configure Endpoint command. It may
have also been causing driver oops when the stopped_td was accessed.
This patch should be backported to stable kernels since 2.6.31. Before
2.6.33, stopped_td was found in the xhci_endpoint_ring, not the
xhci_virt_ep.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* git://git.kernel.org/pub/scm/linux/kernel/git/brodo/pcmcia-2.6:
pcmcia: Make struct pcmcia_device_id const, sound drivers edition
staging: pcmcia: Convert pcmcia_device_id declarations to const
pcmcia: Convert pcmcia_device_id declarations to const
pcmcia: Make declaration and uses of struct pcmcia_device_id const
pcmcia/sa1100: put sa11x0_pcmcia_hw_init[] to .devinit.data
* 'usb-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6: (205 commits)
USB: EHCI: Remove SPARC_LEON {read,write}_be definitions from ehci.h
USB: UHCI: Support big endian GRUSBHC HC
sparc: add {read,write}*_be routines
USB: UHCI: Add support for big endian descriptors
USB: UHCI: Use ACCESS_ONCE rather than using a full compiler barrier
USB: UHCI: Add support for big endian mmio
usb-storage: Correct adjust_quirks to include latest flags
usb/isp1760: Fix possible unlink problems
usb/isp1760: Move function isp1760_endpoint_disable() within file.
USB: remove remaining usages of hcd->state from usbcore and fix regression
usb: musb: ux500: add configuration and build options for ux500 dma
usb: musb: ux500: add dma glue layer for ux500
usb: musb: ux500: add dma name for ux500
usb: musb: ux500: add ux500 specific code for gadget side
usb: musb: fix compile error
usb-storage: fix up the unusual_realtek device list
USB: gadget: f_audio: Fix invalid dereference of initdata
EHCI: don't rescan interrupt QHs needlessly
OHCI: fix regression caused by nVidia shutdown workaround
USB: OTG: msm: Free VCCCX regulator even if we can't set the voltage
...
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (39 commits)
b43: fix comment typo reqest -> request
Haavard Skinnemoen has left Atmel
cris: typo in mach-fs Makefile
Kconfig: fix copy/paste-ism for dell-wmi-aio driver
doc: timers-howto: fix a typo ("unsgined")
perf: Only include annotate.h once in tools/perf/util/ui/browsers/annotate.c
md, raid5: Fix spelling error in comment ('Ofcourse' --> 'Of course').
treewide: fix a few typos in comments
regulator: change debug statement be consistent with the style of the rest
Revert "arm: mach-u300/gpio: Fix mem_region resource size miscalculations"
audit: acquire creds selectively to reduce atomic op overhead
rtlwifi: don't touch with treewide double semicolon removal
treewide: cleanup continuations and remove logging message whitespace
ath9k_hw: don't touch with treewide double semicolon removal
include/linux/leds-regulator.h: fix syntax in example code
tty: fix typo in descripton of tty_termios_encode_baud_rate
xtensa: remove obsolete BKL kernel option from defconfig
m68k: fix comment typo 'occcured'
arch:Kconfig.locks Remove unused config option.
treewide: remove extra semicolons
...
Commit e66eed651f ("list: remove prefetching from regular list
iterators") removed the include of prefetch.h from list.h, which
uncovered several cases that had apparently relied on that rather
obscure header file dependency.
So this fixes things up a bit, using
grep -L linux/prefetch.h $(git grep -l '[^a-z_]prefetchw*(' -- '*.[ch]')
grep -L 'prefetchw*(' $(git grep -l 'linux/prefetch.h' -- '*.[ch]')
to guide us in finding files that either need <linux/prefetch.h>
inclusion, or have it despite not needing it.
There are more of them around (mostly network drivers), but this gets
many core ones.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
{read,write}l_be are now defined for SPARC and do not need to be
defined for SPARC_LEON in ehci.h. This patch fixes the following
warnings:
CC drivers/usb/host/ehci-hcd.o
In file included from drivers/usb/host/ehci-hcd.c:119:
drivers/usb/host/ehci.h:631:1: warning: "readl_be" redefined
...
drivers/usb/host/ehci-hcd.c:119:
drivers/usb/host/ehci.h:632:1: warning: "writel_be" redefined
...
Signed-off-by: Jan Andersson <jan@gaisler.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch adds support for big endian GRUSBHC UHCI controllers.
The HCD bus glue will probe the register interface to determine
the endianness of the controller.
Tested on GR-LEON4-ITX board which has a controller with little endian
interface and on custom LEON3 board with a BE controller.
Signed-off-by: Jan Andersson <jan@gaisler.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch adds support for universal host controllers that use
big endian descriptors. Support for BE descriptors requires a non-PCI
host controller. For kernels with PCI-only UHCI there should be no
change in behaviour.
This patch tries to replicate the technique used to support BE descriptors
in the EHCI HCD. Parts added to uhci-hcd.h are basically copy'n'paste from
ehci.h.
Signed-off-by: Jan Andersson <jan@gaisler.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1462) updates the special accessor functions defined in
uhci-hcd.h. Rather than using a full compiler barrier, all we really
need is the ACCESS_ONCE() mechanism, because the idea is to force the
compiler to store a fixed copy of a possibly changing value.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch adds support for big endian mmio to the UHCI HCD. Big endian
mmio is supported by adding a flag bit to the UHCI HCD replicating the
solution used in the EHCI HCD.
When adding big endian support this patch also adds a check to see if we
need to support HCs with PCI I/O registers when we support HCs with MMIO.
This patch also adds 'const' to the register access functions' uhci_hcd
argument.
Signed-off-by: Jan Andersson <jan@gaisler.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Use skip map to avoid spurious interrupts from unlinked transfers.
Also changes to urb_dequeue() and endpoint_disable() to avoid
release of spinlock in uncertain state.
Signed-off-by: Arvid Brodin <arvid.brodin@enea.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Preparation for patch #2. The function isp1760_endpoint_disable() does almost
the same thing as urb_dequeue(). In patch #2 I change these to use a common
helper function instead of calling each other - for clarity but also to
avoid releasing the spinlock while in a "questionable" state. It seemed
proper to have these functions close to each other in the code.
Signed-off-by: Arvid Brodin <arvid.brodin@enea.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1467) removes the last usages of hcd->state from
usbcore. We no longer check to see if an interrupt handler finds that
a controller has died; instead we rely on host controller drivers to
make an explicit call to usb_hc_died().
This fixes a regression introduced by commit
9b37596a2e (USB: move usbcore away from
hcd->state). It used to be that when a controller shared an IRQ with
another device and an interrupt arrived while hcd->state was set to
HC_STATE_HALT, the interrupt handler would be skipped. The commit
removed that test; as a result the current code doesn't skip calling
the handler and ends up believing the controller has died, even though
it's only temporarily stopped. The solution is to ignore HC_STATE_HALT
following the handler's return.
As a consequence of this change, several of the host controller
drivers need to be modified. They can no longer implicitly rely on
usbcore realizing that a controller has died because of hcd->state.
The patch adds calls to usb_hc_died() in the appropriate places.
The patch also changes a few of the interrupt handlers. They don't
expect to be called when hcd->state is equal to HC_STATE_HALT, even if
the controller is still alive. Early returns were added to avoid any
confusion.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Manuel Lauss <manuel.lauss@googlemail.com>
CC: Rodolfo Giometti <giometti@linux.it>
CC: Olav Kongas <ok@artecdesign.ee>
CC: <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1466) speeds up processing of ehci-hcd's periodic list.
The existing code will pointlessly rescan an interrupt endpoint queue
each time it encounters the queue's QH in the periodic list, which can
happen quite a few times if the endpoint's period is low. On some
embedded systems, this useless overhead can waste so much time that
the driver falls hopelessly behind and loses events.
The patch introduces a "periodic_stamp" variable, which gets
incremented each time scan_periodic() runs and each time the scan
advances to a new frame. If the corresponding stamp in an interrupt
QH is equal to the current periodic_stamp, we assume the QH has
already been scanned and skip over it. Otherwise we scan the QH as
usual, and if none of its URBs have completed then we store the
current periodic_stamp in the QH's stamp, preventing it from being
scanned again.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1463) fixes a regression caused by commit
3df7169e73 (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: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Andre "Osku" Schmidt <andre.osku.schmidt@googlemail.com>
Tested-by: Yury Siamashka <yurand2@gmail.com>
CC: <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
When the USB core wants to change to an alternate interface setting that
doesn't include an active endpoint, or de-configuring the device, the xHCI
driver needs to issue a Configure Endpoint command to tell the host to
drop some endpoints from the schedule. After the command completes, the
xHCI driver needs to free rings for any endpoints that were dropped.
Unfortunately, the xHCI driver wasn't actually freeing the endpoint rings
for dropped endpoints. The rings would be freed if the endpoint's
information was simply changed (and a new ring was installed), but dropped
endpoints never had their rings freed. This caused errors when the ring
segment DMA pool was freed when the xHCI driver was unloaded:
[ 5582.883995] xhci_hcd 0000:06:00.0: dma_pool_destroy xHCI ring segments, ffff88003371d000 busy
[ 5582.884002] xhci_hcd 0000:06:00.0: dma_pool_destroy xHCI ring segments, ffff880033716000 busy
[ 5582.884011] xhci_hcd 0000:06:00.0: dma_pool_destroy xHCI ring segments, ffff880033455000 busy
[ 5582.884018] xhci_hcd 0000:06:00.0: Freed segment pool
[ 5582.884026] xhci_hcd 0000:06:00.0: Freed device context pool
[ 5582.884033] xhci_hcd 0000:06:00.0: Freed small stream array pool
[ 5582.884038] xhci_hcd 0000:06:00.0: Freed medium stream array pool
[ 5582.884048] xhci_hcd 0000:06:00.0: xhci_stop completed - status = 1
[ 5582.884061] xhci_hcd 0000:06:00.0: USB bus 3 deregistered
[ 5582.884193] xhci_hcd 0000:06:00.0: PCI INT A disabled
Fix this issue and free endpoint rings when their endpoints are
successfully dropped.
This patch should be backported to kernels as old as 2.6.31.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
When an endpoint ring is freed, it is either cached in a per-device ring
cache, or simply freed if the ring cache is full. If the ring was added
to the cache, then virt_dev->num_rings_cached is incremented. The cache
is designed to hold up to 31 endpoint rings, in array indexes 0 to 30.
When the device is freed (when the slot was disabled),
xhci_free_virt_device() is called, it would free the cached rings in
array indexes 0 to virt_dev->num_rings_cached.
Unfortunately, the original code in xhci_free_or_cache_endpoint_ring()
would put the first entry into the ring cache in array index 1, instead of
array index 0. This was caused by the second assignment to rings_cached:
rings_cached = virt_dev->num_rings_cached;
if (rings_cached < XHCI_MAX_RINGS_CACHED) {
virt_dev->num_rings_cached++;
rings_cached = virt_dev->num_rings_cached;
virt_dev->ring_cache[rings_cached] =
virt_dev->eps[ep_index].ring;
This meant that when the device was freed, cached rings with indexes 0 to
N would be freed, and the last cached ring in index N+1 would not be
freed. When the driver was unloaded, this caused interesting messages
like:
xhci_hcd 0000:06:00.0: dma_pool_destroy xHCI ring segments, ffff880063040000 busy
This should be queued to stable kernels back to 2.6.33.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
Dmitry's patch
dfa49c4ad1 USB: xhci - fix math in xhci_get_endpoint_interval()
introduced a bug. The USB 2.0 spec says that full speed isochronous endpoints'
bInterval must be decoded as an exponent to a power of two (e.g. interval =
2^(bInterval - 1)). Full speed interrupt endpoints, on the other hand, don't
use exponents, and the interval in frames is encoded straight into bInterval.
Dmitry's patch was supposed to fix up the full speed isochronous to parse
bInterval as an exponent, but instead it changed the *interrupt* endpoint
bInterval decoding. The isochronous endpoint encoding was the same.
This caused full speed devices with interrupt endpoints (including mice, hubs,
and USB to ethernet devices) to fail under NEC 0.96 xHCI host controllers:
[ 100.909818] xhci_hcd 0000:06:00.0: add ep 0x83, slot id 1, new drop flags = 0x0, new add flags = 0x99, new slot info = 0x38100000
[ 100.909821] xhci_hcd 0000:06:00.0: xhci_check_bandwidth called for udev ffff88011f0ea000
...
[ 100.910187] xhci_hcd 0000:06:00.0: ERROR: unexpected command completion code 0x11.
[ 100.910190] xhci_hcd 0000:06:00.0: xhci_reset_bandwidth called for udev ffff88011f0ea000
When the interrupt endpoint was added and a Configure Endpoint command was
issued to the host, the host controller would return a very odd error message
(0x11 means "Slot Not Enabled", which isn't true because the slot was enabled).
Probably the host controller was getting very confused with the bad encoding.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Dmitry Torokhov <dtor@vmware.com>
Reported-by: Thomas Lindroth <thomas.lindroth@gmail.com>
Tested-by: Thomas Lindroth <thomas.lindroth@gmail.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
There are several functions using same code to get max ports and port array,
this patch moves the common code to a function in order to reuse them easily.
Signed-off-by: Huajun Li <huajun.li.lee@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The BIOS handoff for the unused EHCI controller on the ExoPC tablet
hangs for 90 seconds on boot. Detect that device, skip negotiation
and force the handoff.
Signed-off-by: Andy Ross <andy.ross@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Factor the handoff code out from quirk_usb_disable_ehci
Signed-off-by: Andy Ross <andy.ross@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
When the xHCI driver attempts to cancel a transfer, it issues a Stop
Endpoint command and waits for the host controller to indicate which TRB
it was in the middle of processing. The host will put an event TRB with
completion code COMP_STOP on the event ring if it stops on a control
transfer TRB (or other types of transfer TRBs). The ring handling code
is supposed to set ep->stopped_trb to the TRB that the host stopped on
when this happens.
Unfortunately, there is a long-standing bug in the control transfer
completion code. It doesn't actually check to see if COMP_STOP is set
before attempting to process the transfer based on which part of the
control TD completed. So when we get an event on the data phase of the
control TRB with COMP_STOP set, it thinks it's a normal completion of
the transfer and doesn't set ep->stopped_td or ep->stopped_trb.
When the ring handling code goes on to process the completion of the Stop
Endpoint command, it sees that ep->stopped_trb is not a part of the TD
it's trying to cancel. It thinks the hardware has its enqueue pointer
somewhere further up in the ring, and thinks it's safe to turn the control
TRBs into no-op TRBs. Since the hardware was in the middle of the control
TRBs to be cancelled, the proper software behavior is to issue a Set TR
dequeue pointer command.
It turns out that the NEC host controllers can handle active TRBs being
set to no-op TRBs after a stop endpoint command, but other host
controllers have issues with this out-of-spec software behavior. Fix this
behavior.
This patch should be backported to kernels as far back as 2.6.31, but it
may be a bit challenging, since process_ctrl_td() was introduced in some
refactoring done in 2.6.36, and some endian-safe patches added in 2.6.40
that touch the same lines.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: stable@kernel.org
The __devinit and __devexit macros were added to probe and remove
functions. The macros move the probe and remove functions to the
devinit and devexit sections
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* 'for-usb-next' of git+ssh://master.kernel.org/pub/scm/linux/kernel/git/sarah/xhci:
xHCI 1.0: Max Exit Latency Too Large Error
xHCI 1.0: TT_THINK_TIME set
xHCI 1.0: Block Interrupts for Isoch transfer
xHCI 1.0: Isoch endpoint CErr field set
xHCI 1.0: Control endpoint average TRB length field set
xHCI 1.0: Setup Stage TRB Transfer Type flag
This is a new TRB Completion Code of the xHCI spec 1.0.
Asserted by the Evalute Context Command if the proposed Max Exit Latency would
not allow the periodic endpoints of the Device Slot to be scheduled.
Signed-off-by: Alex He <alex.he@amd.com>
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
xHCI 1.0 spec says the TT Think Time field shall be set to zero if the device
is not a High-speed hub.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Currently an isoc URB is divided into multiple TDs, and every TD will
trigger an interrupt when it's processed. However, software can schedule
multiple TDs at a time, and it only needs an interrupt every URB.
xHCI 1.0 introduces the Block Event Interrupt(BEI) flag which allows Normal
and Isoch Transfer TRBs to place an Event TRB on an Event Ring but not
assert an intrrupt to the host, and the interrupt rate is significantly
reduced and the system performance is improved.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
xHCI 1.0 specification specifies that CErr does not apply to Isoch endpoints
and shall be set to '0' for Isoch endpoints.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
xHCI 1.0 specification indicates that software should set Average TRB Length
to '8' for control endpoints.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Setup Stage Transfer Type field is added to indicate the presence and the
direction of the Data Stage TD, and determines the direction of the Status
Stage TD so the wLength length field should be ignored by the xHC.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This patch adds support for the UHCI part of the GRLIB GRUSBHC controller
found on some LEON/GRLIB SoCs.
The UHCI HCD previously only supported controllers connected over PCI.
This patch adds support for the first non-PCI UHCI HC. I have tried to
replicate the solution used in ehci-hcd.c.
Tested on GR-LEON4-ITX board (LEON4/GRLIB with GRUSBHC) and x86 with Intel
UHCI HC.
Signed-off-by: Jan Andersson <jan@gaisler.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch is part of a series that extend the UHCI HCD to support
non-PCI host controllers.
This patch also extends the uhci_{read,write}* functions to allow accesses
to registers not mapped into PCI I/O space. This extension also includes
the addition of a void __iomem pointer to the uhci structure.
A new Kconfig option is added to signal that the system has a non-PCI HC.
If this Kconfig option is set, uhci-hcd.c will include generic reset functions
for systems that do not make use of keyboard and mouse legacy support. PCI
controllers will still always use the reset functions from pci-quirks
This patch is followed by a patch that adds bus glue for the first non-PCI
UHCI HC.
Signed-off-by: Jan Andersson <jan@gaisler.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch is part of a series that extend the UHCI HCD to support
non-PCI controllers.
This patch replaces in{b,w,l} and out{b,wl} with calls to local inline
functions. This is done so that the register access functions can be
extended to support register areas not mapped in PCI I/O space.
Signed-off-by: Jan Andersson <jan@gaisler.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch is part of a series that extend the UHCI HCD to support
non-PCI controllers.
This patch moves PCI specific functions to uhci-pci.c and includes
this file in uhci-hcd.c. It also renames the function uhci_init to
uhci_pci_init.
uhci_init/uhci_pci_init is modified so that the port-detection logic
is kept in a new separate function uhci_count_ports() in uhci-hcd.c.
Signed-off-by: Jan Andersson <jan@gaisler.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch is part of a series that extend the UHCI HCD to support
non-PCI host controllers.
This patch fixes the following warnings from checkpatch:
ERROR: switch and case should be at the same indent
+ switch (to_pci_dev(uhci_dev(uhci))->vendor) {
+ default:
[...]
+ case PCI_VENDOR_ID_GENESYS:
[...]
+ case PCI_VENDOR_ID_INTEL:
WARNING: static char array declaration should probably be static const char
+ static char bad_Asus_board[] = "A7V8X";
WARNING: Use DEFINE_PCI_DEVICE_TABLE for struct pci_device_id
+static const struct pci_device_id uhci_pci_ids[] = { {
Signed-off-by: Jan Andersson <jan@gaisler.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch is part of a series that extend the UHCI HCD to support
non-PCI controllers.
This patch changes calls to uhci_reset_hc, uhci_check_and_reset_hc,
configure_hc, resume_detect_interrupts_are_broken and
global_suspend_mode_is_broken so that they are made through pointers
in the uhci hcd struct. This will allow these functions to be replaced
with bus/arch specific functions.
Signed-off-by: Jan Andersson <jan@gaisler.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch is part of a series that extend the UHCI HCD to support
non-PCI host controllers.
uhci-hub.c contained two PCI vendor checks for silicon quirks. Move
these checks into uhci-hcd.c and use bits in uhci_hcd structure to
mark that we need to use the quirks.
This patch is followed by other patches that will remove PCI
dependencies from uhci-hcd.c as well.
Signed-off-by: Jan Andersson <jan@gaisler.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch fixes the checkpatch errors ans warnings listed below:
ERROR: do not use assignment in if condition
WARNING: line over 80 characters
WARNING: braces {} are not necessary for single statement blocks
WARNING: space prohibited between function name and open parenthesis '('
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Remove a stray 'return 0' at the top of the suspend callback,
and move au1xxx_stop_ehc() out of the ehci spinlock since it takes
some time to complete.
Signed-off-by: Manuel Lauss <manuel.lauss@googlemail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Saves about 50KB of data.
Old/new size of all objects:
text data bss dec hex filename
563015 80096 130684 773795 bcea3 (TOTALS)
610916 32256 130632 773804 bceac (TOTALS)
Signed-off-by: Joe Perches <joe@perches.com>
Acked-by: Kurt Van Dijck <kurt.van.dijck@eia.be> (for drivers/net/can/softing/softing_cs.c)
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
This patch adds support for the GRLIB GRUSBHC EHCI controller from
Aeroflex Gaisler. The controller is typically found on LEON/GRLIB
SoCs.
Tested on GR-LEON4-ITX with with little endian interface and on
LEON3 system on GR-PCI-XC5V development board for big endian
controller.
Signed-off-by: Jan Andersson <jan@gaisler.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The two first HC capability registers (CAPLENGTH and HCIVERSION)
are defined as one 8-bit and one 16-bit register. Most HC
implementations have selected to treat these registers as part
of a 32-bit register, giving the same layout for both big and
small endian systems.
This patch adds a new quirk, big_endian_capbase, to support
controllers with big endian register interfaces that treat
HCIVERSION and CAPLENGTH as individual registers.
Signed-off-by: Jan Andersson <jan@gaisler.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch clears PORT_PLC if xhci_bus_resume() resumes a previous suspended
port, because if a port transition from U3 to U0 state, it will report a
port link state change, and software should clear the corresponding PLC bit.
It also uses hcd->speed to check if a port is a USB2 protocol port.
The patch fixes the issue that USB keyboard can not wakeup system from
hibernation.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The reset value of the uSOF cycle period is incorrect. Set it to
60,000 bits. Without this, several commercial USB flash memory
devices and hubs fail to work properly.
Signed-off-by: David Daney <ddaney@caviumnetworks.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The UCTL clock initialization will cause the ehci and ohci blocks to
become inoperable if the clocks are reinitialized.
Check to see if the clocks have already been initialized.
Also use a mutex to protect the clock initialization code so that
there can be no attempt to use the clocks before they are fully
configured.
Signed-off-by: David Daney <ddaney@caviumnetworks.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This fixes a bug in my previous (2.6.38) patch series which caused
urb->status value to be wrong after unlink (broke usbtest 11, 12).
Signed-off-by: Arvid Brodin <arvid.brodin@enea.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* 'for-usb-next' of git+ssh://master.kernel.org/pub/scm/linux/kernel/git/sarah/xhci:
xhci 1.0: Set transfer burst last packet count field.
xhci 1.0: Set transfer burst count field.
xhci 1.0: Update TD size field format.
xhci 1.0: Only interrupt on short packet for IN EPs.
xhci: Remove sparse warning about cmd_status.
usbcore: warm reset USB3 port in SS.Inactive state
usbcore: Refine USB3.0 device suspend and resume
xHCI: report USB3.0 portstatus comply with USB3.0 specification
xHCI: Set link state support
xHCI: Clear link state change support
xHCI: warm reset support
usb/ch9: use proper endianess for wBytesPerInterval
xhci: Remove recursive call to xhci_handle_event
xhci: Add an assertion to check for virt_dev=0 bug.
xhci: Add rmb() between reading event validity & event data access.
xhci: Make xHCI driver endian-safe
This patch replaces the code that handles qtds. Intead of directly allocating
chip mem and chip slot, enqueue the transfer in a list of queue heads. Use
a centralized function enqueue_qtds() to prioritize and enqueue transfers.
This removes all of the interrupt context BUG() calls when out of chip
mem or transfer slots. It also makes it possible to efficiently use the
dual-port mem on the chip for double-buffered transfers, which improve
transfer times to/from/between usb sticks by about 40 % on my HW.
With this patch it should also be possible to handle qtd scheduling outside
of the interrupt handler, for significantly improved kernel latency. I have
not implemented this since there are some locking issues which I haven't
had time to look at.
Signed-off-by: Arvid Brodin <arvid.brodin@enea.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This fixes a bug in my previous (2.6.38) patch series which caused
urb->status value to be wrong after unlink (broke usbtest 11, 12).
Signed-off-by: Arvid Brodin <arvid.brodin@enea.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Since we always set the OR flag for each transfer, we can just as well set all
these bits to 1 at init and be done with it. Also, HcBufferStatus can be set
at init as per the ISP1761 datasheet page 47 with no loss of performance.
Signed-off-by: Arvid Brodin <arvid.brodin@enea.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This collects urb enqueue code that was spread out all over the place
into a couple of more readable functions.
Signed-off-by: Arvid Brodin <arvid.brodin@enea.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This removes the "qh is 0" printout. qh == NULL if the urb has
been unlinked, so this condition is normal.
Signed-off-by: Arvid Brodin <arvid.brodin@enea.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The xHCI 1.0 specification defines a new isochronous TRB field, called
transfer burst last packet count (TBLPC). This field defines the number
of packets in the last "burst" of packets in a TD. Only SuperSpeed
endpoints can handle more than one burst, so this is set to the number for
packets in a TD for all non-SuperSpeed devices (minus one, since the field
is zero based).
This patch should have no effect on host controllers that don't advertise
the xHCI 1.0 (0x100) version number in their hci_version field.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The xHCI 1.0 specification adds a new field to the fourth dword in an
isochronous TRB: the transfer burst count (TBC). This field is only
non-zero for SuperSpeed devices. Each SS endpoint sets the bMaxBurst
field in the SuperSpeed endpoint companion descriptor, which indicates how
many max-packet-sized "bursts" it can handle in one service interval. The
device driver may choose to burst less max packet sized chunks each
service interval (which is defined by one TD). The xHCI driver indicates
to the host controller how many bursts it needs to schedule through the
transfer burst count field.
This patch will only effect xHCI hosts that advertise 1.0 support (0x100)
in the HCI version field of their capabilities register.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The xHCI 1.0 specification changes the format of the TD size field in
Normal and Isochronous TRBs. The field in control TRBs is still set to
reserved zero. Instead of representing the number of bytes left to
transfer in the TD (including the current TRB's buffer), it now represents
the number of packets left to transfer (*not* including this TRB).
See section 4.11.2.4 of the xHCI 1.0 specification for details. The math
is basically copied straight from there.
Create a new function, xhci_v1_0_td_remainder(), that should be called for
all xHCI 1.0 host controllers. The field location and maximum value is
still the same, so reuse the old function, xhci_td_remainder(), to handle
the bit shifting.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
It doesn't make sense to set the interrupt on short packet (TRB_ISP) flag
for TRBs queued to endpoints that only receive packets from the host
controller (i.e. OUT endpoints). Packets can only be short when they are
sent from a USB device. Plus, the xHCI 1.0 specification forbids setting
the flag for anything but IN endpoints.
While we're at it, remove some of my snide remarks about the inefficiency
of event data TRBs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Sparse complains about the arguments to xhci_evaluate_context_result() and
xhci_configure_endpoint_result():
CHECK drivers/usb/host/xhci.c
drivers/usb/host/xhci.c:1647:53: warning: incorrect type in argument 3 (different signedness)
drivers/usb/host/xhci.c:1647:53: expected int *cmd_status
drivers/usb/host/xhci.c:1647:53: got unsigned int [usertype] *[assigned] cmd_status
drivers/usb/host/xhci.c:1648:50: warning: incorrect type in argument 3 (different signedness)
drivers/usb/host/xhci.c:1648:50: expected int *cmd_status
drivers/usb/host/xhci.c:1648:50: got unsigned int [usertype] *[assigned] cmd_status
The command status is taken from the command completion event TRB, and
will always be a positive number. Change the signature of
xhci_evaluate_context_result() and xhci_configure_endpoint_result() to
take a u32 for cmd_status.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
In the past, we use USB2.0 request to suspend and resume a USB3.0 device.
Actually, USB3.0 hub does not support Set/Clear PORT_SUSPEND request,
instead, it uses Set PORT_LINK_STATE request. This patch makes USB3.0 device
suspend/resume comply with USB3.0 specification.
This patch fixes the issue that USB3.0 device can not be suspended when
connected to a USB3.0 external hub.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
