There were some places that compared port_speed == -1 where port_speed
is a u8.  This doesn't work unless we cast the -1 to u8.  Some places
did it correctly.

Instead of using -1 directly, I've created a DUPLICATE_ENTRY define
which does the cast and is more descriptive as well.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

Use XOR to invert the cycle bit, instead of a more complicated
calculation.  Eliminate a check for the link TRB type in find_trb_seg().
We know that there will always be a link TRB at the end of a segment, so
xhci_segment->trbs[TRBS_PER_SEGMENT - 1] will always have a link TRB type.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: NTakashi Iwai <tiwai@suse.de>

When an endpoint stalls, we need to update the xHCI host's internal
dequeue pointer to move it past the stalled transfer.  This includes
updating the cycle bit (TRB ownership bit) if we have moved the dequeue
pointer past a link TRB with the toggle cycle bit set.

When we're trying to find the new dequeue segment, find_trb_seg() is
supposed to keep track of whether we've passed any link TRBs with the
toggle cycle bit set.  However, this while loop's body

	while (cur_seg->trbs > trb ||
			&cur_seg->trbs[TRBS_PER_SEGMENT - 1] < trb) {

Will never get executed if the ring only contains one segment.
find_trb_seg() will return immediately, without updating the new cycle
bit.  Since find_trb_seg() has no idea where in the segment the TD that
stalled was, make the caller, xhci_find_new_dequeue_state(), check for
this special case and update the cycle bit accordingly.

This patch should be queued to kernels all the way back to 2.6.31.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: NTakashi Iwai <tiwai@suse.de>
Cc: stable@kernel.org

When an endpoint stalls, the xHCI driver must move the endpoint ring's
dequeue pointer past the stalled transfer.  To do that, the driver issues
a Set TR Dequeue Pointer command, which will complete some time later.

Takashi was having issues with USB 1.1 audio devices that stalled, and his
analysis of the code was that the old code would not update the xHCI
driver's ring dequeue pointer after the command completes.  However, the
dequeue pointer is set in xhci_find_new_dequeue_state(), just before the
set command is issued to the hardware.

Setting the dequeue pointer before the Set TR Dequeue Pointer command
completes is a dangerous thing to do, since the xHCI hardware can fail the
command.  Instead, store the new dequeue pointer in the xhci_virt_ep
structure, and update the ring's dequeue pointer when the Set TR dequeue
pointer command completes.

While we're at it, make sure we can't queue another Set TR Dequeue Command
while the first one is still being processed.  This just won't work with
the internal xHCI state code.  I'm still not sure if this is the right
thing to do, since we might have a case where a driver queues multiple
URBs to a control ring, one of the URBs Stalls, and then the driver tries
to cancel the second URB.  There may be a race condition there where the
xHCI driver might try to issue multiple Set TR Dequeue Pointer commands,
but I would have to think very hard about how the Stop Endpoint and
cancellation code works.  Keep the fix simple until when/if we run into
that case.

This patch should be queued to kernels all the way back to 2.6.31.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: NTakashi Iwai <tiwai@suse.de>
Cc: stable@kernel.org

Make sure the HCD_FLAG_HW_ACCESSIBLE flag is mirrored by both roothubs,
since it refers to whether the shared hardware is accessible.  Make sure
each bus is marked as suspended by setting usb_hcd->state to
HC_STATE_SUSPENDED when the PCI host controller is resumed.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

This patch changes the xHCI driver to allocate two roothubs.  This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers.  This is a rather large patch, but it
can't be broken up, or it would break git-bisect.

Make the xHCI driver register its own PCI probe function.  This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub.  This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.

Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub.  This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.

The reset method will also mark the xHCI USB2 roothub as having an
integrated TT.  Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT.  We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.

Other details:
-------------

The roothub emulation code is changed to return the correct number of
ports for the two roothubs.  For the USB 3.0 roothub, it only reports the
USB 3.0 ports.  For the USB 2.0 roothub, it reports all the LS/FS/HS
ports.  The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.

The code for initializing a new device context must be changed to set the
proper roothub port number.  Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub.  Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.

The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.

The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.

There's also changes to the driver initialization and shutdown paths:

 1. Make sure that the xhci_hcd pointer is shared across the two
    usb_hcd structures.  The xhci_hcd pointer is allocated and the
    registers are mapped in when xhci_pci_setup() is called with the
    primary HCD.  When xhci_pci_setup() is called with the non-primary
    HCD, the xhci_hcd pointer is stored.

 2. Make sure to set the sg_tablesize for both usb_hcd structures.  Set
    the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
    DMA.  (The PCI DMA mask is set from the primary HCD further down in
    the xhci_pci_setup() function.)

 3. Ensure that the host controller doesn't start kicking khubd in
    response to port status changes before both usb_hcd structures are
    registered.  xhci_run() only starts the xHC running once it has been
    called with the non-primary roothub.  Similarly, the xhci_stop()
    function only halts the host controller when it is called with the
    non-primary HCD.  Then on the second call, it resets and cleans up the
    MSI-X irqs.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

xhci_find_slot_id_by_port() tries to map the port index to the slot ID for
the USB device.  In the future, there will be two xHCI roothubs, and their
port indices will overlap.  Therefore, xhci_find_slot_id_by_port() will
need to use information in the roothub's usb_hcd structure to map the port
index and roothub speed to the right slot ID.

Add a new parameter to xhci_find_slot_id_by_port(), in order to pass in
the roothub's usb_hcd structure.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

There are several variables in the xhci_hcd structure that are related to
bus suspend and resume state.  There are a couple different port status
arrays that are accessed by port index.  Move those variables into a
separate structure, xhci_bus_state.  Stash that structure in xhci_hcd.

When we have two roothhubs that can be suspended and resumed separately,
we can have two xhci_bus_states, and index into the port arrays in each
structure with the fake roothub port index (not the real hardware port
index).
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

In the upcoming patches, the roothub emulation code will need to return
port status and port change buffers based on whether they are called with
the xHCI USB 2.0 or USB 3.0 roothub.  To facilitate that, make the roothub
code index into an array of port addresses with wIndex, rather than
calculating the address using the offset and the address of the PORTSC
registers.  Later we can set the port array to be the array of USB 3.0
port addresses, or the USB 2.0 port addresses, depending on the roothub
passed in.

Create a temporary (statically sized) port array and fill it in with both
USB 3.0 and USB 2.0 port addresses.  This is inefficient to do for every
roothub call, but this is needed for git bisect compatibility.  The
temporary port array will be deleted in a subsequent patch.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

The hcd->flags are in a sorry state.  Some of them are clearly specific to
the particular roothub (HCD_POLL_RH, HCD_POLL_PENDING, and
HCD_WAKEUP_PENDING), but some flags are related to PCI device state
(HCD_HW_ACCESSIBLE and HCD_SAW_IRQ).  This is an issue when one PCI device
can have two roothubs that share the same IRQ line and hardware.

Make sure to set HCD_FLAG_SAW_IRQ for both roothubs when an interrupt is
serviced, or an URB is unlinked without an interrupt.  (We can't tell if
the host actually serviced an interrupt for a particular bus, but we can
tell it serviced some interrupt.)

HCD_HW_ACCESSIBLE is set once by usb_add_hcd(), which is set for both
roothubs as they are added, so it doesn't need to be modified.
HCD_POLL_RH and HCD_POLL_PENDING are only checked by the USB core, and
they are never set by the xHCI driver, since the roothub never needs to be
polled.

The usb_hcd's state field is a similar mess.  Sometimes the state applies
to the underlying hardware: HC_STATE_HALT, HC_STATE_RUNNING, and
HC_STATE_QUIESCING.  But sometimes the state refers to the roothub state:
HC_STATE_RESUMING and HC_STATE_SUSPENDED.

Alan Stern recently made the USB core not rely on the hcd->state variable.
Internally, the xHCI driver still checks for HC_STATE_SUSPENDED, so leave
that code in.  Remove all references to HC_STATE_HALT, since the xHCI
driver only sets and doesn't test those variables.  We still have to set
HC_STATE_RUNNING, since Alan's patch has a bug that means the roothub
won't get registered if we don't set that.

Alan's patch made the USB core check a different variable when trying to
determine whether to suspend a roothub.  The xHCI host has a split
roothub, where two buses are registered for one PCI device.  Each bus in
the xHCI split roothub can be suspended separately, but both buses must be
suspended before the PCI device can be suspended.  Therefore, make sure
that the USB core checks HCD_RH_RUNNING() for both roothubs before
suspending the PCI host.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

Make sure to call into the USB core's link, unlink, and giveback URB
functions with the usb_hcd pointer found by using urb->dev->bus.  This
will avoid confusion later, when the xHCI driver will deal with URBs from
two separate buses (the USB 3.0 roothub and the faked USB 2.0 roothub).

Assume xhci_urb_dequeue() will be called with the proper usb_hcd.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

The xHCI driver doesn't ever test hcd->state for HC_STATE_HALT.  The USB
core recently stopped using it internally, so there's no point in setting
it in the driver.  We still need to set HC_STATE_RUNNING in order to make
it past the USB core's hcd->state check in register_roothub().
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

The xhci_bus_suspend() and xhci_bus_resume() functions are a bit hard to
read, because they have an ambiguously named variable "port".  Rename it
to "port_index".  Introduce a new temporary variable, "max_ports" that
holds the maximum number of roothub ports the host controller supports.
This will reduce the number of register reads, and make it easy to change
the maximum number of ports when there are two roothubs.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

The test of placing a number of command no-ops on the command ring and
counting the number of no-op events that were generated was only used
during the initial xHCI driver bring up.  This test is no longer used, so
delete it.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

The expression

	while (running_total < sg_dma_len(sg))

does not take into account that the remaining data length can be less
than sg_dma_len(sg). In that case, running_total can end up being
greater than the total data length, so an extra TRB is counted.
Changing the expression to

	while (running_total < sg_dma_len(sg) && running_total < temp)

fixes that.

This patch should be queued for stable kernels back to 2.6.31.
Signed-off-by: NPaul Zimmerman <paulz@synopsys.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org

Calculations like

	running_total = TRB_MAX_BUFF_SIZE -
		(sg_dma_address(sg) & (TRB_MAX_BUFF_SIZE - 1));
	if (running_total != 0)
		num_trbs++;

are incorrect, because running_total can never be zero, so the if()
expression will never be true. I think the intention was that
running_total be in the range of 0 to TRB_MAX_BUFF_SIZE-1, not 1
to TRB_MAX_BUFF_SIZE. So adding a

	running_total &= TRB_MAX_BUFF_SIZE - 1;

fixes the problem.

This patch should be queued for stable kernels back to 2.6.31.
Signed-off-by: NPaul Zimmerman <paulz@synopsys.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org

This makes it easier to spot some problems, which will be fixed by the
next patch in the series. Also change dev_dbg to dev_err in
check_trb_math(), so any math errors will be visible even when running
with debug disabled.

Note: This patch changes the expressions containing
"((1 << TRB_MAX_BUFF_SHIFT) - 1)" to use the equivalent
"(TRB_MAX_BUFF_SIZE - 1)". No change in behavior is intended for
those expressions.

This patch should be queued for stable kernels back to 2.6.31.
Signed-off-by: NPaul Zimmerman <paulz@synopsys.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org

Change the BUGs in xhci_find_new_dequeue_state() to WARN_ONs, to avoid
bringing down the box if one of them is hit

This patch should be queued for stable kernels back to 2.6.31.
Signed-off-by: NPaul Zimmerman <paulz@synopsys.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org

The unused space in the doorbell is now marked as RsvdZ, not RsvdP, so
we can avoid reading the doorbell before writing it.

Update the doorbell-related defines to produce the entire doorbell value
from a single macro.  Document the doorbell format in a comment.
Signed-off-by: NMatthew Wilcox <willy@linux.intel.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

printk_ratelimit() is misused in xhci-ring.c.
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

dev_dbg() is used to print ordinary transfer messages in xhci-ring.c.
System log messages will be flushed if CONFIG_USB_DEBUG is set. Replace the
dev_dbg() with xhci_dbg().
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

giveback_first_trb() controls the cycle bit set of the start_trb, to ensure
that the start_trb is written last and the host controller will receive a
whole td at a time.

However, if the ring is wrapped and cycle bit is toggled to zero, then
giveback_first_trb() will be of no effect. In this case, set the cycle bit of
start_trb to 1 at the beginning and clear it in giveback_first_trb().
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

Parameter *td is not used in giveback_first_trb(). Remove it.
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

Fix the more_trbs_coming field of queue_trb() in isoc transfer.
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

The original code that resumed the USB bus on a port status change would
only do so when there was a device connected to the port.  If a device was
just disconnected, the event would be queued for khubd, but khubd wouldn't
run.  That would leave the connect status change (CSC) bit set.

If a USB device was plugged into that same port, the xHCI host controller
would set the current connect status (CCS) bit.  But since the CSC bit was
already set, it would not generate an interrupt for a port status change
event.  That would mean the user could "Safely Remove" a device, have the
bus suspend, disconnect the device, re-plug it in, and then the device
would never be enumerated.

Plugging in a different device on another port would cause the bus to
resume, and khubd would notice the re-connected device.  Running lsusb
would also resume the bus, leading users to report the problem "went away"
when using diagnostic tools.

The solution is to resume the bus when a port status change event is
received, regardless of the port status.

Thank you very much to Maddog for helping me track down this Heisenbug.

This patch should be queued for the 2.6.37 stable tree.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: NJon 'maddog' Hall <maddog@li.org>
Tested-by: NAndiry Xu <andiry.xu@amd.com>
Cc: stable@kernel.org

If the xHCI host controller shares an interrupt line with another device,
the xHCI driver needs to check if the interrupt was generated by its
hardware.  Unfortunately, the user will see a ton of "Spurious interrupt."
lines if the other hardware interrupts often.  Lawrence found his dmesg
output cluttered with this output when the xHCI host shared an interrupt
with his i915 hardware.

Remove the warning, as sharing an interrupt is a normal thing.

This should be applied to the 2.6.36 stable tree.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: NLawrence Rust <lvr@softsystem.co.uk>
Cc: stable@kernel.org

This commit implements port remote wakeup.

When a port is in U3 state and resume signaling is detected from a device,
the port transitions to the Resume state, and the xHC generates a Port Status
Change Event.

For USB3 port, software write a '0' to the PLS field to complete the resume
signaling. For USB2 port, the resume should be signaling for at least 20ms,
irq handler set a timer for port remote wakeup, and then finishes process in
hub_control GetPortStatus.

Some codes are borrowed from EHCI code.
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Add software trigger USB device suspend resume function hook.
Do port suspend & resume in terms of xHCI spec.

Port Suspend:
Stop all endpoints via Stop Endpoint Command with Suspend (SP) flag set.
Place individual ports into suspend mode by writing '3' for Port Link State
(PLS) field into PORTSC register. This can only be done when the port is in
Enabled state. When writing, the Port Link State Write Strobe (LWS) bit shall
be set to '1'.
Allocate an xhci_command and stash it in xhci_virt_device to wait completion for
the last Stop Endpoint Command.  Use the Suspend bit in TRB to indicate the Stop
Endpoint Command is for port suspend. Based on Sarah's suggestion.

Port Resume:
Write '0' in PLS field, device will transition to running state.
Ring an endpoints' doorbell to restart it.

Ref: USB device remote wake need another patch to implement. For details of
how USB subsystem do power management, please see:
    Documentation/usb/power-management.txt
Signed-off-by: NCrane Cai <crane.cai@amd.com>
Signed-off-by: NLibin Yang <libin.yang@amd.com>
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch fixes a isoc transfer bug reported by Sander Eikelenboom.
When ep->skip is set, endpoint ring dequeue pointer should be updated
when processed every missed td. Although ring dequeue pointer will also
be updated when ep->skip is clear, leave it intact during missed tds
processing may cause two issues:

1). If the very next valid transfer following missed tds is a short
transfer, its actual_length will be miscalculated;
2). If there are too many missed tds during transfer, new inserted tds
may found the transfer ring full and urb enqueue fails.
Reported-by: NSander Eikelenboom <linux@eikelenboom.it>
Tested-by: NSander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The code to increment the TRB pointer has a slight ambiguity that could
lead to a bug on different compilers.  The ANSI C specification does not
specify the precedence of the assignment operator over the postfix
operator.  gcc 4.4 produced the correct code (increment the pointer and
assign the value), but a MIPS compiler that one of John's clients used
assigned the old (unincremented) value.

Remove the unnecessary assignment to make all compilers produce the
correct assembly.
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

To tell the host controller that there are transfers on the endpoint
rings, we need to ring the endpoint doorbell.  This is a PCI MMIO write,
which can be delayed until another register read is queued.

The previous code would flush the doorbell write by reading the doorbell
register after the write.  This may take time, and it's not necessary to
force the host controller to know about the transfers right away.  Don't
flush the doorbell register writes.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The interrupter register set includes a register that says whether interrupts
are pending for each event ring (the IP bit).  Each MSI-X vector will get its
own interrupter set with separate IP bits.  The status register includes an
"Event Interrupt (EINT)" bit that is set when an IP bit is set in any of the
interrupters.

When PCI interrupts are used, the EINT bit exactly mirrors the IP bit in the
single interrupter set, and it is a waste of time to check both registers when
trying to figure out if the xHC interrupted or another device on the shared IRQ
line interrupted.  Only check the IP bit to reduce register reads.

The IP bit is automatically cleared by the xHC when MSI or MSI-X is enabled.  It
doesn't make sense to read that register to check for shared interrupts (since
MSI and MSI-X aren't shared).  It also doesn't make sense to write to that
register to clear the IP bit, since it is cleared by the hardware.

We can tell whether MSI or MSI-X is enabled by looking at the irq number in
hcd->irq.  If it's -1, we know MSI or MSI-X is enabled.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Now that the event handler functions no longer use xhci_set_hc_event_deq()
to update the event ring dequeue pointer, that function is not used by
anything in xhci-ring.c.  Move that function into xhci-mem.c and make it
static.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The xHCI specification suggests that writing the hardware event ring dequeue
pointer register too often can be an expensive operation for the xHCI hardware
to manage.  It suggests minimizing the number of writes to that register.

Originally, the driver wrote the event ring dequeue pointer after each
event was processed.  Depending on how the event ring moderation register
is set up and how fast the transfers are completing, there may be several
events processed for each interrupt.  This patch makes the hardware event
ring dequeue pointer be written only once per interrupt.

Make the transfer event handler and port status event handler only write
the software event ring dequeue pointer.  Move the updating of the
hardware event ring dequeue pointer into the interrupt function.  Move the
contents of xhci_set_hc_event_deq() into the interrupt handler.  The
interrupt handler must clear the event handler busy flag, so it might as
well also write the dequeue pointer to the same register.  This eliminates
two 32-bit PCI reads and two 32-bit PCI writes.
Reported-by: NAndiry Xu <andiry.xu@amd.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

xhci_handle_event() is now only called from within xhci-ring.c, so make it
static.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Remove a duplicate register read of the interrupt pending register from
xhci_irq().  Also, remove waiting on the posted write of that register.
The host will see it eventually.  It will probably read the register
itself before deciding whether to interrupt the system again, forcing the
posted write to complete.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

When we move xhci_work() into xhci_irq(), we don't need to read the operational
register status field twice.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Most of the work for interrupt handling is done in xhci-ring.c, so it makes
sense to move the functions that are first called when an interrupt happens
(xhci_irq() or xhci_msi_irq()) into xhci-ring.c, so that the compiler can better
optimize them.

Shorten some lines to make it pass checkpatch.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

I've been using perf to measure the top symbols while transferring 1GB of data
on a USB 3.0 drive with dd.  This is using the raw disk with /dev/sdb, with a
block size of 1K.

During performance testing, the top symbol was xhci_triad_to_transfer_ring(), a
function that should return immediately if streams are not enabled for an
endpoint.  It turned out that the functions to find the endpoint ring was
defined in xhci-mem.c and used in xhci-ring.c and xhci-hcd.c.  I moved a copy of
xhci_triad_to_transfer_ring() and xhci_urb_to_transfer_ring() into xhci-ring.c
and declared them static.  I also made a static version of
xhci_urb_to_transfer_ring() in xhci.c.

This improved throughput on a 1GB read of the raw disk with dd from
186MB/s to 195MB/s, and perf reported sampling the xhci_triad_to_transfer_ring()
0.06% of the time, rather than 9.26% of the time.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch implements isochronous urb enqueue and interrupt handler part.

When an isochronous urb is passed to xHCI driver, first check the transfer
ring to guarantee there is enough room for the whole urb. Then update the
start_frame and interval field of the urb. Always assume URB_ISO_ASAP
is set, and never use urb->start_frame as input.

The number of isoc TDs is equal to urb->number_of_packets. One isoc TD is
consumed every Interval. Each isoc TD consists of an Isoch TRB chained to
zero or more Normal TRBs.

Call prepare_transfer for each TD to do initialization; then calculate the
number of TRBs needed for each TD. If the data required by an isoc TD is
physically contiguous (not crosses a page boundary), then only one isoc TRB
is needed; otherwise one or more additional normal TRB shall be chained to
the isoc TRB by the host.

Set TRB_IOC to the last TRB of each isoc TD. Do not ring endpoint doorbell
to start xHC procession until all the TDs are inserted to the endpoint
transer ring.

In irq handler, update urb status and actual_length, increase
urb_priv->td_cnt. When all the TDs are completed(td_cnt is equal to
urb_priv->length), giveback the urb to usbcore.
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>