The auto setting is used to open related power and clocks
automatically after receiving wakeup signal.
With this feature, the PHY's clock and power can be recovered
correctly from low power mode, it is guaranteed by IC logic.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The mxs-phy has several bugs and features at different
versions, the driver code can get it through of_device_id.data.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
This patch adds suspend/resume support to s3c-hsotg driver. It makes UDC
driver more power efficient.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Reprogramming the DMA after tear down is initiated leads to warning.
This is mainly seen with ISOCH since we do a delayed completion for
ISOCH transfers. In ISOCH transfers dma_completion should not reprogram
if the channel tear down is initiated.
Signed-off-by: George Cherian <george.cherian@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Adapted dwc3 core to use the Generic PHY Framework. So for init, exit,
power_on and power_off the following APIs are used phy_init(), phy_exit(),
phy_power_on() and phy_power_off().
However using the old USB phy library wont be removed till the PHYs of all
other SoC's using dwc3 core is adapted to the Generic PHY Framework.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Since PHYs for dwc3 is optional (not all SoCs having PHYs for DWC3
should be programmed), do not return from probe if the USB PHY library
returns -ENODEV as that indicates the platform does not have a
programmable PHY.
While this can be considered as a temporary fix, a long term solution
would be to add 'nop' PHY for platforms that does not have programmable
PHY.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
few new revisions of the core have been released,
add them to our list of revisions so we can apply
workarounds if necessary.
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit 388e5c5 (usb: dwc3: remove dwc3 dependency
on host AND gadget.) created the possibility for
host-only and peripheral-only dwc3 builds but
left a possible randconfig build error when host-only
builds are selected.
Cc: <stable@vger.kernel.org> # v3.8+
Reported-by: Jim Davis <jim.epost@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
When going into bus suspend/resume we _must_
call gadget driver's ->suspend/->resume callbacks
accordingly. This patch implements that very feature
which has been missing forever.
Signed-off-by: Felipe Balbi <balbi@ti.com>
It's not always we need to force a transfer to be removed
from the core's internal cache. This extra argument will
help differentiating those two cases.
Signed-off-by: Paul Zimmerman <paulz@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
During superspeed, HIRD threshold should always
be zero. Curent driver wasn't making sure that
was the case.
Signed-off-by: Felipe Balbi <balbi@ti.com>
if we have hibernation configured, Databook
instructs us to set KEEP_CONNECT bit together
with RUN_STOP bit, in step 9 of section 12.3.6.1
Initialization for Hibernation Support.
Signed-off-by: Felipe Balbi <balbi@ti.com>
We must read HWPARAMS4 register to figure out
how many scratch buffers we should allocate.
Later patch will use "Set Scratchpad Buffer
Array" command to pass the pointer to the
IP so it can be used during hibernation.
Signed-off-by: Felipe Balbi <balbi@ti.com>
That argument will be used in later patches when we
have working hibernation support. For now, always
pass it as false.
The idea of this patch is to decrease to size of
following patches and slowly add hibernation building
blocks to the gadget side of dwc3 so that it becomes
very easy to review the actual hibernation code.
[ balbi@ti.com : rewrote patch on top of current
tree. Added commit log. ]
Signed-off-by: Paul Zimmerman <paulz@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
This function will be used during hibernation to get
the current link state. It will be needed at least
for Hibernation support.
Signed-off-by: Paul Zimmerman <paulz@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
This extra field will save endpoint state when we're
about to enter hibernation. It will be used later
to restore the endpoint state when resuming.
Signed-off-by: Paul Zimmerman <paulz@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
move 1-bit flags to the bottom of the structure,
sort all bit flags alphabetically, add documentation
which was missing.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Revision 2.20a of the core has a known issue
which would generate bogus hibernation events
_and_ random failures on USB CV TD.9.23 test
case.
The suggested workaround is to ignore hibernation
events which don't match currently connected
speed.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Revisions between 2.10a and 2.50a (included) have
a known issue which may cause xHCI compliance tests
to fail and/or quality issues with Isochronous
transactions.
Note that this issue only impacts certain configurations
of those revisions, namely the ones which have clock
gating enabled.
The suggested workaround is to disable clock gating in
known broken revisions, make sure HW LPM is disabled
and set GCTL.SOFITPSYNC to 1.
Signed-off-by: Felipe Balbi <balbi@ti.com>
by setting IOC always, we can recycle TRBs a
lot sooner at the expense of some increased
CPU load.
The extra load seems to be quite minimal on
OMAP5 devices (instead of 1 IRQ for one MSC
transfer, we get
CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS).
Signed-off-by: Felipe Balbi <balbi@ti.com>
This patch fixes problem with unnecessary usb_ep_set_maxpacket_limit() usage.
It should not be used in at91udc_probe() function, where maxpacket values are
set for field "maxpacket" of struct at91_ep, which is representation of
endpoint in driver internals. Function usb_ep_set_maxpacket_limit() is called
in udc_reinit() function, where struct usb_ep instances are initialised with
values set previously in struct at91_ep instances. So it's very important to
initialise it properly.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
If NO_DMA=y:
drivers/built-in.o: In function `txstate':
musb_gadget.c:(.text+0x35955a): undefined reference to `dma_unmap_single'
musb_gadget.c:(.text+0x35957e): undefined reference to `dma_sync_single_for_cpu'
drivers/built-in.o: In function `musb_g_giveback':
(.text+0x359672): undefined reference to `dma_mapping_error'
drivers/built-in.o: In function `musb_g_giveback':
(.text+0x3596ba): undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `musb_g_giveback':
(.text+0x3596e0): undefined reference to `dma_sync_single_for_cpu'
drivers/built-in.o: In function `rxstate':
musb_gadget.c:(.text+0x3599d0): undefined reference to `dma_unmap_single'
musb_gadget.c:(.text+0x3599f6): undefined reference to `dma_sync_single_for_cpu'
drivers/built-in.o: In function `musb_gadget_queue':
musb_gadget.c:(.text+0x35a8c0): undefined reference to `dma_map_single'
musb_gadget.c:(.text+0x35a8d0): undefined reference to `dma_mapping_error'
musb_gadget.c:(.text+0x35a906): undefined reference to `dma_sync_single_for_cpu'
musb_gadget.c:(.text+0x35a9a0): undefined reference to `dma_unmap_single'
musb_gadget.c:(.text+0x35a9c8): undefined reference to `dma_sync_single_for_cpu'
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The probe() method has the 'dev' local variable declared and used but strangely
not in all cases where it should be...
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
instead of relying on the otg pointer, which
can be NULL in certain cases, we can use the
gadget and host pointers we already hold inside
struct musb.
Cc: <stable@vger.kernel.org>
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
On some older XHCIs streams are not supported and the UAS driver
will fail at probe time. For those devices storage should try
to bind to UAS devices.
This patch adds a flag for stream support to HCDs and evaluates
it.
[Note: Sarah fixed a bug where the USB 2.0 root hub, not USB 3.0 root
hub would get marked as being able to support streams.]
Signed-off-by: Oliver Neukum <oliver@neukum.org>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
If the host controller stops responding to commands, we need to kill all
the URBs that were queued to all endpoints. The current code would only
kill URBs that had been queued to the endpoint rings. ep->ring is set
to NULL if streams has been enabled for the endpoint, which means URBs
submitted with a non-zero stream_id would never get killed. Fix this.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
In preparation for fixing this function for streams endpoints, refactor
code in the command watchdog timeout function into two new functions.
One kills all URBs on a ring (either stream or endpoint), the other
kills all URBs associated with an endpoint. Fix a split string while
we're at it.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Although an interesting concept, I don't think that this is a good idea:
-This will result in lots of "virtual" scsi controllers confusing users
-If we get a scsi-bus-reset we will now need to do a usb-device-reset of all
uas devices on the same usb bus, which is something to avoid if possible
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
At the kernel-summit Sarah Sharp asked me if I was willing to become the
uas maintainer. I said yes, and here is a patch to make this official.
Also remove Matthew Wilcox and Sarah Sharp as maintainers at their request.
I've also added myself to the module's author tag, so that if people look there
rather then in maintainers they will know they should bug me about uas too.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
xhci streams support is fixed, unblock usb attached scsi.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Copy the sg alignment trick from the usb-storage driver, without this I'm
seeing intermittent errors when using uas devices with an ehci controller.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The scsi error handling path re-uses previously queued up (and errored-out)
cmds. If such a re-used cmd had a data-phase then cmdinfo will have
data_in_urb / data_out_urb still set to the free-ed urbs from the errored-out
cmd, and they will get free-ed a second time when the error handling cmd
completes, corrupting the kernel heap.
Clearing cmdinfo on command queue-ing fixes this, and seems like a good idea
in general.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The scsi-host structure is refcounted, scsi_remove_host tears down the
scsi-host but does not decrement the refcount, so we need to call
scsi_put_host on disconnect to get the underlying memory to be freed.
After calling scsi_remove_host, the scsi-core may still hold a reference to
the scsi-host, iow we may still get called after uas_disconnect, but we
do our own life cycle management of uas_devinfo, freeing it on disconnect,
and thus may end up using devinfo after it has been freed. Switch to letting
scsi_host_alloc allocate and manage the memory for us.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
cmds are either on the inflight list or on the dead list, never both, so
we only need one list head.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Before this commit the uas driver would keep track of scsi commands which still
need to have some urbs submitted to the device, and complete this with an
ABORT result code on bus-reset or disconnect, but in flight scsi commands
which have all their urbs submitted, and thus are not part of the work list,
would never get their done callback called.
The problem is killed sense urbs don't have any tag info, so it is impossible
to tell which scsi cmd they belong to, so merely making sure all the urbs
have completed one way or the other is not enough.
This commit fixes this by changing the work list to an inflight list, which
keeps tracks of all inflight scsi cmnds, using the IS_IN_WORK_LIST flag to
determine if actual work needs to be done in uas_do_work(), and by moving
marking all inflight scsi commands as aborted and moving them to the dead list
on bus-reset or disconnect.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
uas_alloc_data_urb always gets called with a stream_id value of 0 when not
using streams. Removing the check makes it consistent with uas_alloc_sense_urb.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
For USB-2 connections the stream-id must always be 0.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Some BIOS-es will hang on reboot when an uas device is attached and left in
uas mode on reboot.
This commit adds a shutdown handler which on reboot puts the device back into
usb-storage mode, fixing the hang on reboot on these systems.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
We can sleep in our own workqueue (which is the whole reason for having
it), and scsi error handlers are also always called from a context which
may sleep.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Since we use a fixed tag / stream for tasks we cannot allow more then one
to run at the same time. This could happen before this time if a task timed
out.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The fixed endpoint config code was only necessary to deal with an early
uas prototype which has never been released, so lets drop it and enforce
proper uas endpoint descriptors.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The loop uses up to 3 bytes of the endpoint extra data.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This is a preparation patch for adding better descriptor validation.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Falling back from uas to usb-storage requires coordination between uas and
usb-storage, so use usb-storage's quirks module parameter, rather then
requiring the user to pass a param to 2 different modules.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
uas devices have 2 alternative settings on their usb-storage interface,
one for usb-storage and one for uas. Using the uas driver is preferred, so if
the uas driver is enabled, and the device has an uas alt setting, don't bind.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Once we start supporting uas hardware, and as more and more uas devices
become available, we will likely start seeing broken devices. This patch
prepares for the inevitable need for blacklisting those devices from
using the uas driver (they will use usb-storage instead).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
On disconnect USB3 protocol ports transit from U0 to SS.Inactive to Rx.Detect,
on a recoverable error, the port stays in SS.Inactive and we recover from it by
doing a warm-reset (through usb_device_reset if we have a udev for the port).
If this really is a disconnect we may end up trying the warm-reset anyways,
since khubd may run before the SS.Inactive to Rx.Detect transition, or it
may get skipped if the transition to Rx.Detect happens before khubd gets run.
With a loose connector, or in the case which actually led me to debugging this
bad ACPI firmware toggling Vbus off and on in quick succession, the port
may transition from Rx.Detect to U0 again before khubd gets run. In this case
the device state is unknown really, but khubd happily goes into the resuscitate
an existing device path, and the device driver never gets notified about the
device state being messed up.
If the above scenario happens with a streams using device, as soon as an urb
is submitted to an endpoint with streams, the following appears in dmesg:
ERROR Transfer event for disabled endpoint or incorrect stream ring
@0000000036807420 00000000 00000000 04000000 04078000
Notice how the TRB address is all zeros. I've seen this both on Intel
Pantherpoint and Nec xhci hosts.
Luckily we can detect the U0 to SS.Inactive to Rx.Detect to U0 all having
happened before khubd runs case since the C_LINK_STATE bit gets set in the
portchange bits on the U0 -> SS.Inactive change. This bit will also be set on
suspend / resume, but then it gets cleared by port_hub_init before khubd runs.
So if the C_LINK_STATE bit is set and a warm-reset is not needed, iow the port
is not still in SS.Inactive, and the port still has a connection, then the
device needs to be reset to put it back in a known state.
I've verified that doing the device reset also fixes the transfer event with
all zeros address issue.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
If streams are still allocated on device-reset or set-interface then the hcd
code implictly frees the streams. Clear host_endpoint->streams in this case
so that if a driver later tries to re-allocate them it won't run afoul of the
device already having streams check in usb_alloc_streams().
Note normally streams still being allocated at reset / set-intf would be a
driver bug, but this can happen without it being a driver bug on reset-resume.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
If we align segment dma pool memory to 64 bytes, then a segment can be located
at 0x10000040 - 0x1000043f, and a segment from another ring at 0x10000440 -
0x1000083f. The last trb in the first segment at 0x10000430 will then translate
to the same radix tree key as the first trb of the second segment, while they
are in different rings!
This patches fixes this by changing the alignment of the dma pool to be 1KB
rather then 64 bytes. An alternative fix would be to reduce the shift used
to calculate the radix tree keys, but that would (slighlty) grow the radix
trees so I believe this is the better fix.
Note this patch is mostly theoretical since in practice I've not seen
the dma_pool actually return not 1KB aligned memory.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
cmd_ring_reserved_trbs gets decremented by xhci_free_stream_info(), so set it
to 0 after freeing all rings, otherwise it wraps around to a very large value
when rings with streams are free-ed.
Before this patch the wrap-around could be triggered when xhci_resume
calls xhci_mem_cleanup if the controller resume fails.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This is a preparation patch for teaching usb-storage to not bind to
uas devices.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This is a preparation patch for teaching usb-storage to not bind to
uas devices.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
If we get ie 16 streams we can use stream-id 1-16, not 1-15.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Handle usb-device resets not triggered from uas_eh_bus_reset_handler(), when
this happens, disable cmd queuing during the reset, and wait for existing
requests to finish in pre_reset.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Fix the uas_eh_bus_reset_handler not properly taking the usbdev lock
before calling usb_device_reset, the usb-core expects this lock to be
taken when usb_device_reset is called.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
I thought it would be a good idea to also test uas with usb-2, and it turns out
it was, as it did not work. The problem is that the uas driver was passing the
bEndpointAddress' direction bit to usb_rcvbulkpipe, the xhci code seems to not
care about this, but with the ehci code this causes usb_submit_urb failure.
With this fixed the uas code works nicely with an uas device plugged into
an ehci port.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The cmd endpoint never has streams, so the stream_id parameter is unused.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
All callers of unlink_data_urbs drop devinfo->lock before calling it, and
then immediately take it again after the call. And the first thing
unlink_data_urbs does is take the lock again, and the last thing it does
is drop it. This commit removes all the unnecessary lock dropping and taking.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
- Rename labels to properly reflect this
- Don't skip free-ing the streams when scsi_init_shared_tag_map fails
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Otherwise they may complete before they get anchored and thus never get
unanchored (as the unanchoring is done by the usb core on completion).
This commit also remove the usb_get_urb / usb_put_urb around cmd submission +
anchoring, since if done in the proper order this is not necessary.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This patch adds a new list where all requests which are canceled are
added to, so we don't loose them. Then, after killing all inflight
urbs on bus reset (and disconnect) we'll walk over the list and clean
them up.
Without this we can end up with aborted requests lingering around in
case of status pipe transfer errors.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Simplifies locking, we'll protect the list with the device spin lock.
Also plugs races which can happen when two devices operate on the
global list.
While being at it rename the list head from "list" to "work", preparing
for the addition of a second list.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This allows userspace to use bulk-streams, just like in kernel drivers, see
Documentation/usb/bulk-streams.txt for details on the in kernel API. This
is exported pretty much one on one to userspace.
To use streams an app must first make a USBDEVFS_ALLOC_STREAMS ioctl,
on success this will return the number of streams available (which may be
less then requested). If there are n streams the app can then submit
usbdevfs_urb-s with their stream_id member set to 1-n to use a specific
stream. IE if USBDEVFS_ALLOC_STREAMS returns 4 then stream_id 1-4 can be
used.
When the app is done using streams it should call USBDEVFS_FREE_STREAMS
Note applications are advised to use libusb rather then using the
usbdevfs api directly. The latest version of libusb has support for streams.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This patch makes it possible to specify a bulk stream id when submitting
an urb using the async usbfs API. It overloads the number_of_packets
usbdevfs_urb field for this. This is not pretty, but given other
constraints it is the best we can do. The reasoning leading to this goes
as follows:
1) We want to support bulk streams in the usbfs API
2) We do not want to extend the usbdevfs_urb struct with a new member, as
that would mean defining new ioctl numbers for all async API ioctls +
adding compat versions for the old ones (times 2 for 32 bit support)
3) 1 + 2 means we need to re-use an existing field
4) number_of_packets is only used for isoc urbs, and streams are bulk only
so it is the best (and only) candidate for re-using
Note that:
1) This patch only uses number_of_packets as stream_id if the app has
actually allocated streams on the ep, so that old apps which may have
garbage in there (as it was unused until now in the bulk case), will not
break
2) This patch does not add support for allocating / freeing bulk-streams, that
is done in a follow up patch
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This is a preparation patch for adding support for bulk streams.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The usb_set_interface documentation says:
* Also, drivers must not change altsettings while urbs are scheduled for
* endpoints in that interface; all such urbs must first be completed
* (perhaps forced by unlinking).
For in kernel drivers we trust the drivers to get this right, but we
cannot trust userspace to get this right, so enforce it by killing any
urbs still pending on the interface.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Documentation/usb/bulk-streams.txt says:
All stream IDs will be deallocated when the driver releases the interface, to
ensure that drivers that don't support streams will be able to use the endpoint
This commit actually implements this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This is a preparation patch for adding support for bulk streams to usbfs.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
So that it can be used in other places too.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
If we're expanding a stream ring, we want to make sure we can add those
ring segments to the radix tree that maps segments to ring pointers.
Try the radix tree insert after the new ring segments have been allocated
(the last segment in the new ring chunk will point to the first newly
allocated segment), but before the new ring segments are linked into the
old ring.
If insert fails on any one segment, remove each segment from the radix
tree, deallocate the new segments, and return. Otherwise, link the new
segments into the tree.
HdG: Add a check to only update stream mappings in xhci_ring_expansion when
the ring is a stream ring.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The ss_ep_comp bmAttributes filed can contain more info then just the
streams, use usb_ss_max_streams to properly get max streams.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This fixes TR dequeue validation failing on Intel XHCI controllers with the
following warning:
Mismatch between completed Set TR Deq Ptr command & xHCI internal state.
Interestingly enough reading the deq ptr from the ep ctx after a
TR Deq Ptr command does work on a Nec XHCI controller, it seems the Nec
writes the ptr to both the ep and stream contexts when streams are used.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Nec XHCI controllers don't seem to care, but without this Intel XHCI
controllers reject Set TR dequeue commands with a COMP_TRB_ERR, leading
to the following warning:
WARN Set TR Deq Ptr cmd invalid because of stream ID configuration
And very shortly after this the system completely freezes.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Before this a device needing ie 32 stream ctxs would end up with an entry from
the small_streams_pool which has 256 bytes entries, where as 32 stream ctxs
need 512 bytes. Things actually keep running for a surprisingly long time
before crashing because of this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
And warn about this, as that would be a driver bug.
Like wise drivers should ensure that streams are properly free-ed before a
device is reset. So lets warn about that too. This already causes warnings
in the form of:
[ 96.982398] xhci_hcd 0000:01:00.0: WARN Can't disable streams for endpoint 0x81
, streams are already disabled!
[ 96.982400] xhci_hcd 0000:01:00.0: WARN xhci_free_streams() called with non-streams endpoint
But it is better to also warn about the actual cause of this later warnings.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
xhci maintains a radix tree for each stream endpoint because it must
be able to map a trb address to the stream ring. Each ring segment
must be added to the ring for this to work. Currently xhci sticks
only the first segment of each stream ring into the radix tree.
Result is that things work initially, but as soon as the first segment
is full xhci can't map the trb address from the completion event to the
stream ring any more -> BOOM. You'll find this message in the logs:
ERROR Transfer event for disabled endpoint or incorrect stream ring
This patch adds a helper function to update the radix tree, and a
function to remove ring segments from the tree. Both functions loop
over the segment list and handles all segments instead of just the
first.
[Note: Sarah changed this patch to add radix_tree_maybe_preload() and
radix_tree_preload_end() calls around the radix tree insert, since we
can now insert entries in interrupt context. There are now two helper
functions to make the code cleaner, and those functions are moved to
make them static.]
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This changes debug messages and warnings in xhci-ring.c
to be on a single line so grep can find them. grep must
have precedence over the 80 column limit.
[Sarah fixed two checkpatch.pl issues with split lines
introduced by this commit.]
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The xHCI driver currently uses a USB core internal field,
udev->lpm_capable, to indicate the xHCI driver knows how to calculate
the LPM timeout values. If this value is set for the host controller
udev, it means Link PM can be enabled for child devices under that host.
Change the code so the xHCI driver isn't mucking with USB core internal
fields. Instead, indicate the xHCI driver doesn't support Link PM on
this host by clearing the U1 and U2 exit latencies in the roothub
SuperSpeed Extended Capabilities BOS descriptor.
The code to check for the roothub setting U1 and U2 exit latencies to
zero will also disable LPM for external devices that do that same. This
was already effectively done with commit
ae8963adb4 "usb: Don't enable LPM if the
exit latency is zero." Leave that code in place, so that if a device
sets one exit latency value to zero, but the other is set to a valid
value, LPM is only enabled for the U1 or U2 state that had the valid
value. This is the same behavior the code had before.
Also, change messages about missing Link PM information from warning
level to info level. Only print a warning about the first device that
doesn't support LPM, to avoid log spam. Further, cleanup some
unnecessary line breaks to help people to grep for the error messages.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
