linux-toradex.git/drivers/usb/host, branch v2.6.32.15 Linux kernel for Apalis and Colibri modules USB: xhci: properly set endpoint context fields for periodic eps. 2010-05-12T21:57:03+00:00 Sarah Sharp sarah.a.sharp@linux.intel.com 2010-04-16T15:07:27+00:00 2e80b07dcdbe27eda40447ad48e26662beea7b4c commit 9238f25d5d32a435277eb234ec82bacdd5daed41 upstream. For periodic endpoints, we must let the xHCI hardware know the maximum payload an endpoint can transfer in one service interval. The xHCI specification refers to this as the Maximum Endpoint Service Interval Time Payload (Max ESIT Payload). This is used by the hardware for bandwidth management and scheduling of packets. For SuperSpeed endpoints, the maximum is calculated by multiplying the max packet size by the number of bursts and the number of opportunities to transfer within a service interval (the Mult field of the SuperSpeed Endpoint companion descriptor). Devices advertise this in the wBytesPerInterval field of their SuperSpeed Endpoint Companion Descriptor. For high speed devices, this is taken by multiplying the max packet size by the "number of additional transaction opportunities per microframe" (the high bits of the wMaxPacketSize field in the endpoint descriptor). For FS/LS devices, this is just the max packet size. The other thing we must set in the endpoint context is the Average TRB Length. This is supposed to be the average of the total bytes in the transfer descriptor (TD), divided by the number of transfer request blocks (TRBs) it takes to describe the TD. This gives the host controller an indication of whether the driver will be enqueuing a scatter gather list with many entries comprised of small buffers, or one contiguous buffer. It also takes into account the number of extra TRBs you need for every TD. This includes No-op TRBs and Link TRBs used to link ring segments together. Some drivers may choose to chain an Event Data TRB on the end of every TD, thus increasing the average number of TRBs per TD. The Linux xHCI driver does not use Event Data TRBs. In theory, if there was an API to allow drivers to state what their bandwidth requirements are, we could set this field accurately. For now, we set it to the same number as the Max ESIT payload. The Average TRB Length should also be set for bulk and control endpoints, but I have no idea how to guess what it should be. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 9238f25d5d32a435277eb234ec82bacdd5daed41 upstream.

For periodic endpoints, we must let the xHCI hardware know the maximum
payload an endpoint can transfer in one service interval.  The xHCI
specification refers to this as the Maximum Endpoint Service Interval Time
Payload (Max ESIT Payload).  This is used by the hardware for bandwidth
management and scheduling of packets.

For SuperSpeed endpoints, the maximum is calculated by multiplying the max
packet size by the number of bursts and the number of opportunities to
transfer within a service interval (the Mult field of the SuperSpeed
Endpoint companion descriptor).  Devices advertise this in the
wBytesPerInterval field of their SuperSpeed Endpoint Companion Descriptor.

For high speed devices, this is taken by multiplying the max packet size by the
"number of additional transaction opportunities per microframe" (the high
bits of the wMaxPacketSize field in the endpoint descriptor).

For FS/LS devices, this is just the max packet size.

The other thing we must set in the endpoint context is the Average TRB
Length.  This is supposed to be the average of the total bytes in the
transfer descriptor (TD), divided by the number of transfer request blocks
(TRBs) it takes to describe the TD.  This gives the host controller an
indication of whether the driver will be enqueuing a scatter gather list
with many entries comprised of small buffers, or one contiguous buffer.

It also takes into account the number of extra TRBs you need for every TD.
This includes No-op TRBs and Link TRBs used to link ring segments
together.  Some drivers may choose to chain an Event Data TRB on the end
of every TD, thus increasing the average number of TRBs per TD.  The Linux
xHCI driver does not use Event Data TRBs.

In theory, if there was an API to allow drivers to state what their
bandwidth requirements are, we could set this field accurately.  For now,
we set it to the same number as the Max ESIT payload.

The Average TRB Length should also be set for bulk and control endpoints,
but I have no idea how to guess what it should be.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: xhci: properly set the "Mult" field of the endpoint context. 2010-05-12T21:57:03+00:00 Sarah Sharp sarah.a.sharp@linux.intel.com 2010-04-16T15:07:04+00:00 0a0da543426241627580bda5fccb5ddf444a1aba commit 1cf62246c0e394021e494e0a8f1013e80db1a1a9 upstream. A SuperSpeed interrupt or isochronous endpoint can define the number of "burst transactions" it can handle in a service interval. This is indicated by the "Mult" bits in the bmAttributes of the SuperSpeed Endpoint Companion Descriptor. For example, if it has a max packet size of 1024, a max burst of 11, and a mult of 3, the host may send 33 1024-byte packets in one service interval. We must tell the xHCI host controller the number of multiple service opportunities (mults) the device can handle when the endpoint is installed. We do that by setting the Mult field of the Endpoint Context before a configure endpoint command is sent down. The Mult field is invalid for control or bulk SuperSpeed endpoints. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 1cf62246c0e394021e494e0a8f1013e80db1a1a9 upstream.

A SuperSpeed interrupt or isochronous endpoint can define the number of
"burst transactions" it can handle in a service interval.  This is
indicated by the "Mult" bits in the bmAttributes of the SuperSpeed
Endpoint Companion Descriptor.  For example, if it has a max packet size
of 1024, a max burst of 11, and a mult of 3, the host may send 33
1024-byte packets in one service interval.

We must tell the xHCI host controller the number of multiple service
opportunities (mults) the device can handle when the endpoint is
installed.  We do that by setting the Mult field of the Endpoint Context
before a configure endpoint command is sent down.  The Mult field is
invalid for control or bulk SuperSpeed endpoints.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: OHCI: don't look at the root hub to get the number of ports 2010-05-12T21:57:02+00:00 Alan Stern stern@rowland.harvard.edu 2010-04-20T14:37:57+00:00 dd13b9f4a90b5dcefb7ef36393a55c96f3f10a76 commit fcf7d2141f4a363a4a8454c4a0f26bb69e766c5f upstream. This patch (as1371) fixes a small bug in ohci-hcd. The HCD already knows how many ports the controller has; there's no need to go looking at the root hub's usb_device structure to find out. Especially since the root hub's maxchild value is set correctly only while the root hub is bound to the hub driver. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit fcf7d2141f4a363a4a8454c4a0f26bb69e766c5f upstream.

This patch (as1371) fixes a small bug in ohci-hcd.  The HCD already
knows how many ports the controller has; there's no need to go looking
at the root hub's usb_device structure to find out.  Especially since
the root hub's maxchild value is set correctly only while the root hub
is bound to the hub driver.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: EHCI: defer reclamation of siTDs 2010-05-12T21:56:59+00:00 Alan Stern stern@rowland.harvard.edu 2010-04-08T20:56:37+00:00 9ab04f8dc2ec32b1065ab9dfcca3c92456fa77e0 commit 0e5f231bc16ff9910882fa5b9d64d80e7691cfab upstream. This patch (as1369) fixes a problem in ehci-hcd. Some controllers occasionally run into trouble when the driver reclaims siTDs too quickly. This can happen while streaming audio; it causes the controller to crash. The patch changes siTD reclamation to work the same way as iTD reclamation: Completed siTDs are stored on a list and not reused until at least one frame has passed. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Nate Case <ncase@xes-inc.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 0e5f231bc16ff9910882fa5b9d64d80e7691cfab upstream.

This patch (as1369) fixes a problem in ehci-hcd.  Some controllers
occasionally run into trouble when the driver reclaims siTDs too
quickly.  This can happen while streaming audio; it causes the
controller to crash.

The patch changes siTD reclamation to work the same way as iTD
reclamation: Completed siTDs are stored on a list and not reused until
at least one frame has passed.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Nate Case <ncase@xes-inc.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
usb: r8a66597-hcd: fix removed from an attached hub 2010-04-01T22:58:36+00:00 Yoshihiro Shimoda shimoda.yoshihiro@renesas.com 2010-03-16T03:29:35+00:00 b6bc58585c030713f82f11097929b7caada57a79 commit d835933436ac0d1e8f5b35fe809fd4e767e55d6e upstream. fix the problem that when a USB hub is attached to the r8a66597-hcd and a device is removed from that hub, it's likely that a kernel panic follows. Reported-by: Markus Pietrek <Markus.Pietrek@emtrion.de> Signed-off-by: Yoshihiro Shimoda <shimoda.yoshihiro@renesas.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit d835933436ac0d1e8f5b35fe809fd4e767e55d6e upstream.

fix the problem that when a USB hub is attached to the r8a66597-hcd and
a device is removed from that hub, it's likely that a kernel panic follows.

Reported-by: Markus Pietrek <Markus.Pietrek@emtrion.de>
Signed-off-by: Yoshihiro Shimoda <shimoda.yoshihiro@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: xHCI: re-initialize cmd_completion 2010-04-01T22:58:33+00:00 Andiry Xu andiry.xu@amd.com 2010-03-12T09:10:04+00:00 29e72304e5757345c9ece8962230b5a7eae8eeba commit 1d68064a7d80da4a7334cab0356162e36229c1a1 upstream. When a signal interrupts a Configure Endpoint command, the cmd_completion used in xhci_configure_endpoint() is not re-initialized and the wait_for_completion_interruptible_timeout() will return failure. Initialize cmd_completion in xhci_configure_endpoint(). Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 1d68064a7d80da4a7334cab0356162e36229c1a1 upstream.

When a signal interrupts a Configure Endpoint command, the cmd_completion used
in xhci_configure_endpoint() is not re-initialized and the
wait_for_completion_interruptible_timeout() will return failure. Initialize
cmd_completion in xhci_configure_endpoint().

Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: EHCI: adjust ehci_iso_stream for changes in ehci_qh 2010-04-01T22:58:32+00:00 Clemens Ladisch clemens@ladisch.de 2010-03-01T16:18:56+00:00 43763b6eece07ec97e36e00205c3d54f4a57754e commit 1082f57abfa26590b60c43f503afb24102a37016 upstream. The EHCI driver stores in usb_host_endpoint.hcpriv a pointer to either an ehci_qh or an ehci_iso_stream structure, and uses the contents of the hw_info1 field to distinguish the two cases. After ehci_qh was split into hw and sw parts, ehci_iso_stream must also be adjusted so that it again looks like an ehci_qh structure. This fixes a NULL pointer access in ehci_endpoint_disable() when it tries to access qh->hw->hw_info1. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Reported-by: Colin Fletcher <colin.m.fletcher@googlemail.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 1082f57abfa26590b60c43f503afb24102a37016 upstream.

The EHCI driver stores in usb_host_endpoint.hcpriv a pointer to either
an ehci_qh or an ehci_iso_stream structure, and uses the contents of the
hw_info1 field to distinguish the two cases.

After ehci_qh was split into hw and sw parts, ehci_iso_stream must also
be adjusted so that it again looks like an ehci_qh structure.

This fixes a NULL pointer access in ehci_endpoint_disable() when it
tries to access qh->hw->hw_info1.

Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Reported-by: Colin Fletcher <colin.m.fletcher@googlemail.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: EHCI: fix ITD list order 2010-04-01T22:58:32+00:00 Clemens Ladisch clemens@ladisch.de 2010-03-01T08:12:50+00:00 5fe90f08a129e9fd8bda0e0c54746eb7b5297768 commit 92bc3648e6027384479852b770a542722fadee7c upstream. When isochronous URBs are shorter than one frame and when more than one ITD in a frame has been completed before the interrupt can be handled, scan_periodic() completes the URBs in the order in which they are found in the descriptor list. Therefore, the descriptor list must contain the ITDs in the correct order, i.e., a new ITD must be linked in after any previous ITDs of the same endpoint. This should fix garbled capture data in the USB audio drivers. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Reported-by: Colin Fletcher <colin.m.fletcher@googlemail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 92bc3648e6027384479852b770a542722fadee7c upstream.

When isochronous URBs are shorter than one frame and when more than one
ITD in a frame has been completed before the interrupt can be handled,
scan_periodic() completes the URBs in the order in which they are found
in the descriptor list.  Therefore, the descriptor list must contain the
ITDs in the correct order, i.e., a new ITD must be linked in after any
previous ITDs of the same endpoint.

This should fix garbled capture data in the USB audio drivers.

Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Reported-by: Colin Fletcher <colin.m.fletcher@googlemail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: fix crash in uhci_scan_schedule 2010-03-15T15:50:08+00:00 Pete Zaitcev zaitcev@redhat.com 2010-01-08T22:39:22+00:00 0f43110993a731cb24ab39befc7cb1c265a4bf20 commit d23356da714595b888686d22cd19061323c09190 upstream. When hardware is removed on a Stratus, the system may crash like this: ACPI: PCI interrupt for device 0000:7c:00.1 disabled Trying to free nonexistent resource <00000000a8000000-00000000afffffff> Trying to free nonexistent resource <00000000a4800000-00000000a480ffff> uhci_hcd 0000:7e:1d.0: remove, state 1 usb usb2: USB disconnect, address 1 usb 2-1: USB disconnect, address 2 Unable to handle kernel paging request at 0000000000100100 RIP: [<ffffffff88021950>] :uhci_hcd:uhci_scan_schedule+0xa2/0x89c #4 [ffff81011de17e50] uhci_scan_schedule at ffffffff88021918 #5 [ffff81011de17ed0] uhci_irq at ffffffff88023cb8 #6 [ffff81011de17f10] usb_hcd_irq at ffffffff801f1c1f #7 [ffff81011de17f20] handle_IRQ_event at ffffffff8001123b #8 [ffff81011de17f50] __do_IRQ at ffffffff800ba749 This occurs because an interrupt scans uhci->skelqh, which is being freed. We do the right thing: disable the interrupts in the device, and do not do any processing if the interrupt is shared with other source, but it's possible that another CPU gets delayed somewhere (e.g. loops) until we started freeing. The agreed-upon solution is to wait for interrupts to play out before proceeding. No other bareers are neceesary. A backport of this patch was tested on a 2.6.18 based kernel. Testing of 2.6.32-based kernels is under way, but it takes us forever (months) to turn this around. So I think it's a good patch and we should keep it. Tracked in RH bz#516851 Signed-Off-By: Pete Zaitcev <zaitcev@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit d23356da714595b888686d22cd19061323c09190 upstream.

When hardware is removed on a Stratus, the system may crash like this:

ACPI: PCI interrupt for device 0000:7c:00.1 disabled
Trying to free nonexistent resource <00000000a8000000-00000000afffffff>
Trying to free nonexistent resource <00000000a4800000-00000000a480ffff>
uhci_hcd 0000:7e:1d.0: remove, state 1
usb usb2: USB disconnect, address 1
usb 2-1: USB disconnect, address 2
Unable to handle kernel paging request at 0000000000100100 RIP:
 [<ffffffff88021950>] :uhci_hcd:uhci_scan_schedule+0xa2/0x89c

 #4 [ffff81011de17e50] uhci_scan_schedule at ffffffff88021918
 #5 [ffff81011de17ed0] uhci_irq at ffffffff88023cb8
 #6 [ffff81011de17f10] usb_hcd_irq at ffffffff801f1c1f
 #7 [ffff81011de17f20] handle_IRQ_event at ffffffff8001123b
 #8 [ffff81011de17f50] __do_IRQ at ffffffff800ba749

This occurs because an interrupt scans uhci->skelqh, which is
being freed. We do the right thing: disable the interrupts in the
device, and do not do any processing if the interrupt is shared
with other source, but it's possible that another CPU gets
delayed somewhere (e.g. loops) until we started freeing.

The agreed-upon solution is to wait for interrupts to play out
before proceeding. No other bareers are neceesary.

A backport of this patch was tested on a 2.6.18 based kernel.
Testing of 2.6.32-based kernels is under way, but it takes us
forever (months) to turn this around. So I think it's a good
patch and we should keep it.

Tracked in RH bz#516851

Signed-Off-By: Pete Zaitcev <zaitcev@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: xhci: Fix finding extended capabilities registers 2010-03-15T15:50:07+00:00 Edward Shao laface.tw@gmail.com 2010-02-10T19:37:30+00:00 bbb4ae3e0220f07cc88eb7398d7742add03542f1 commit 05197921ff3dad52d99fd1647974c57d9c28d40e upstream. According "5.3.6 Capability Parameters (HCCPARAMS)" of xHCI rev0.96 spec, value of xECP register indicates a relative offset, in 32-bit words, from Base to the beginning of the first extended capability. The wrong calculation will cause BIOS handoff fail (not handoff from BIOS) in some platform with BIOS USB legacy sup support. Signed-off-by: Edward Shao <laface.tw@gmail.com> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 05197921ff3dad52d99fd1647974c57d9c28d40e upstream.

According "5.3.6 Capability Parameters (HCCPARAMS)" of xHCI rev0.96 spec,
value of xECP register indicates a relative offset, in 32-bit words,
from Base to the beginning of the first extended capability.
The wrong calculation will cause BIOS handoff fail (not handoff from BIOS)
in some platform with BIOS USB legacy sup support.

Signed-off-by: Edward Shao <laface.tw@gmail.com>
Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>