This patch (as1587) simplifies ehci-hcd's scan_isoc() routine by
eliminating some local variables, declaring boolean-valued values as
bool rather than unsigned, changing variable names to make more sense,
and so on.
The logic at the end of the routine is cut down significantly. The
scanning doesn't have to catch up all the way to where the hardware
is; it merely has to catch up to where the hardware was when the last
interrupt occurred. If the hardware has made more progress since then
and issued another interrupt, a rescan will catch up to it.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1586) replaces the kernel timer used by ehci-hcd as an
I/O watchdog with an hrtimer event.
Unlike in the current code, the watchdog event is now always enabled
whenever any isochronous URBs are active. This will prevent bugs
caused by the periodic schedule wrapping around with no completion
interrupts; the watchdog handler is guaranteed to scan the isochronous
transfers at least once during each iteration of the schedule. The
extra overhead will be negligible: one timer interrupt every 100 ms.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1585) fixes a bug in ehci-hcd's scheme for scanning
interrupt QHs.
Currently a single routine takes care of scanning everything on the
periodic schedule. Whenever an interrupt occurs, it scans all
isochronous and interrupt URBs scheduled for frames that have elapsed
since the last scan.
This has two disadvantages. The first is relatively minor: An
interrupt QH is likely to end up getting scanned multiple times,
particularly if the last scan was not fairly recent. (The current
code avoids this by maintaining a periodic_stamp in each interrupt
QH.)
The second is more serious. The periodic schedule wraps around. If
the last scan occurred during frame N, and the next scan occurs when
the schedule has gone through an entire cycle and is back at frame N,
the scanning code won't look at any frames other than N. Consequently
it won't see any QHs that completed during frame N-1 or earlier.
The patch replaces the entire frame-based approach for scanning
interrupt QHs with a new routine using a list-based approach, the same
as for async QHs. This has a slight disadvantage, because it means
that all interrupt QHs have to be scanned every time. But it is more
robust than the current approach.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1584) fixes a minor bug that has been present in
ehci-hcd since the beginning.
Scanning the schedules for URB completions is single-threaded. If a
completion interrupt occurs while an URB is being given back, the
interrupt handler realizes that a scan is in progress on another CPU
and avoids starting a new one.
This means that completion events can be lost. If an URB completes
after it has been scanned but while a scan is still in progress, the
driver won't notice and won't rescan the completed URB.
The patch fixes the problem by adding a new flag to indicate that
another scan is needed after the current scan is done. The flag gets
set whenever a completion interrupt occurs while a scan is in
progress. The rescan will see the completion, thus preventing it from
getting lost.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1583) changes ehci-hcd to use an hrtimer event for
unlinking empty (unused) async QHs instead of using a kernel timer.
The check for empty QHs is moved to a new routine, where it doesn't
require going through an entire scan of both the async and periodic
schedules. And it can unlink multiple QHs at once, unlike the current
code.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1582) changes ehci-hcd's strategy for unlinking async
QHs. Currently the driver never unlinks more than one QH at a time.
This can be inefficient and cause unnecessary delays, since a QH
cannot be reused while it is waiting to be unlinked.
The new strategy unlinks all the waiting QHs at once. In practice the
improvement won't be very big, because it's somewhat uncommon to have
two or more QHs waiting to be unlinked at any time. But it does
happen, and in any case, doing things this way makes more sense IMO.
The change requires the async unlinking code to be refactored
slightly. Now in addition to the routines for starting and ending an
unlink, there are new routines for unlinking a single QH and starting
an IAA cycle. This approach is needed because there are two separate
paths for unlinking async QHs:
When a transfer error occurs or an URB is cancelled, the QH
must be unlinked right away;
When a QH has been idle sufficiently long, it is unlinked
to avoid consuming DMA bandwidth uselessly.
In the first case we want the unlink to proceed as quickly as
possible, whereas in the second case we can afford to batch several
QHs together and unlink them all at once. Hence the division of
labor.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1581) replaces the iaa_watchdog kernel timer used by
ehci-hcd with an hrtimer event, in keeping with the general conversion
to high-res timers.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1580) makes ehci_iso_stream structures behave more like
QHs, in that they will remain allocated until their isochronous
endpoint is disabled. This will come in useful in the future, when
periodic bandwidth gets allocated as an altsetting is installed rather
than on-the-fly.
For now, the change to the ehci_iso_stream lifetimes means that each
structure is always deallocated at exactly one spot in
ehci_endpoint_disable() and never used again. As a result, it is no
longer necessary to use reference counting on these things, and the
patch removes it.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1579) adds an hrtimer event to handle deallocation of
iTDs and siTDs in ehci-hcd.
Because of the frame-oriented approach used by the EHCI periodic
schedule, the hardware can continue to access the Transfer Descriptor
for isochronous (or split-isochronous) transactions for up to a
millisecond after the transaction completes. The iTD (or siTD) must
not be reused before then.
The strategy currently used involves putting completed iTDs on a list
of cached entries and every so often returning them to the endpoint's
free list. The new strategy reduces overhead by putting completed
iTDs back on the free list immediately, although they are not reused
until it is safe to do so.
When the isochronous endpoint stops (its queue becomes empty), the
iTDs on its free list get moved to a global list, from which they will
be deallocated after a minimum of 2 ms. This delay is what the new
hrtimer event is for.
Overall this may not be a tremendous improvement over the current
code, but to me it seems a lot more clear and logical. In addition,
it removes the need for each iTD to keep a reference to the
ehci_iso_stream it belongs to, since the iTD never needs to be moved
back to the stream's free list from the global list.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1578) adds an hrtimer event to handle the death of an
EHCI controller. When a controller dies, it doesn't necessarily stop
running right away. The new event polls at 1-ms intervals to see when
all activity has safely stopped. This replaces a busy-wait polling
loop in the current code.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1577) adds hrtimer support for unlinking interrupt QHs
in ehci-hcd. The current code relies on a fixed delay of either 2 or
55 us, which is not always adequate and in any case is totally bogus.
Thanks to internal caching, the EHCI hardware may continue to access
an interrupt QH for more than a millisecond after it has been unlinked.
In fact, the EHCI spec doesn't say how long to wait before using an
unlinked interrupt QH. The patch sets the delay to 9 microframes
minimum, which ought to be adequate.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1576) adds hrtimer support for managing ehci-hcd's
async schedule. Just as with the earlier change to the periodic
schedule management, two new hrtimer events take care of everything.
One event polls at 1-ms intervals to see when the Asynchronous
Schedule Status (ASS) flag matches the Asynchronous Schedule Enable
(ASE) value; the schedule's state must not be changed until it does.
The other event delays for 15 ms after the async schedule becomes
empty before turning it off.
The new events replace a busy-wait poll and a kernel timer usage.
They also replace the rather illogical method currently used for
indicating the async schedule should be turned off: attempting to
unlink the dedicated QH at the head of the async list.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1575) removes special code added for status polling of
the EHCI controller in PS3 systems. While the controller is running,
the polling is now carried out by an hrtimer handler. When the
controller is suspending or stopping, we use the same polling routine
as the old code -- but in neither case do we need to conclude that the
controller has died if the polling goes on for too long.
As a result the entire handshake_on_error_set_halt() routine is now
unused, so it is removed from the driver.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1574) changes the return type of multiple functions in
ehci-sched.c from int to void. The values they return are now always
0, so there's no reason for them to return any value at all.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1573) adds hrtimer support for managing ehci-hcd's
periodic schedule. There are two issues to deal with.
First, the schedule's state (on or off) must not be changed until the
hardware status has caught up with the current command. This is
handled by an hrtimer event that polls at 1-ms intervals to see when
the Periodic Schedule Status (PSS) flag matches the Periodic Schedule
Enable (PSE) value.
Second, the schedule should not be turned off as soon as it becomes
empty. Turning the schedule on and off takes time, so we want to wait
until the schedule has been empty for a suitable period before turning
it off. This is handled by an hrtimer event that gets set to expire
10 ms after the periodic schedule becomes empty.
The existing code polls (for up to 1125 us and with interrupts
disabled!) to check the status, and doesn't implement a delay before
turning off the schedule. Furthermore, if the polling fails then the
driver decides that the controller has died. This has caused problems
for several people; some controllers can take 10 ms or more to turn
off their periodic schedules.
This patch fixes these issues. It also makes the "broken_periodic"
workaround unnecessary; there is no longer any danger of turning off
the periodic schedule after it has been on for less than 1 ms.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1572) begins the conversion of ehci-hcd over to using
high-resolution timers rather than old-fashioned low-resolution kernel
timers. This reduces overhead caused by timer roundoff on systems
where HZ is smaller than 1000. Also, the new timer framework
introduced here is much more logical and easily extended than the
ad-hoc approach ehci-hcd currently uses for timers.
An hrtimer structure is added to ehci_hcd, along with a bitflag array
and an array of ktime_t values, to keep track of which timing events
are pending and what their expiration times are.
Only the infrastructure for the timing operations is added in this
patch. Later patches will add routines for handling each of the
various timing events the driver needs. In some cases the new hrtimer
handlers will replace the existing handlers for ehci-hcd's kernel
timers; as this happens the old timers will be removed. In other
cases the new timing events will replace busy-wait loops.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1571) adds a new state for ehci-hcd's root hubs:
EHCI_RH_STOPPING. This value is used at times when the root hub is
being stopped and we don't know whether or not the hardware has
finished all its DMA yet.
Although the purpose may not be apparent, this distinction will come
in useful later on. Future patches will avoid actions that depend on
the root hub being operational (like turning on the async or periodic
schedules) when they see the state is EHCI_RH_STOPPING.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1570) adds a pointer for the end of ehci-hcd's
async-unlink list. The list (which is actually a queue) is singly
linked, so having a pointer to its end makes adding new entries easier
-- there's no longer any need to scan through the whole list.
In principle it could be changed to a standard doubly-linked list. It
turns out that doing so actually makes the code less clear, so I'm
leaving it as is.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1569) renames the ehci->reclaim list in ehci-hcd. The
word "reclaim" is used in the EHCI specification to mean something
quite different, and "unlink_next" is more descriptive of the list's
purpose anyway.
Similarly, the "reclaim" field in the ehci_stats structure is renamed
"iaa", which is more meaningful (to experts, anyway) and is a better
match for the "lost_iaa" field.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1568) introduces symbolic constants for some of the
less-frequently used bitfields in the QH structure. This makes the
code a little easier to read and understand.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1567) removes ehci-hcd's reference counting of QH
structures. It's not necessary to refcount these things because they
always get deallocated at exactly one spot in ehci_endpoint_disable()
(except for two special QHs, ehci->async and ehci->dummy) and are
never used again.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1566) removes the code in ehci-hcd's resume routines
which tries to restart or cancel any transfers left active while the
root hub or controller was asleep. This code isn't necessary, because
all URBs are terminated before the root hub is suspended.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Currently, EHCI initialization turns off the controller (in case it
was left running by the firmware) before setting up the ehci_hcd data
structure. This patch (as1565) reverses that order.
Although it doesn't matter now, it will matter later on when future
additions to ehci_halt() will want to acquire a spinlock that gets
initialized by ehci_init().
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
- 3 Palmas fixes, 1 of them being a build error fix.
- 2 mc13xx fixes. 1 for fixing an SPI regmap configuration and another one for
working around an i.Mx hardware bug.
- 1 omap-usb regression fix.
- 1 twl6040 build breakage fix.
- 1 file deletion (ab5500-core.h) that was overlooked during the last merge
window.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJP/vIeAAoJEIqAPN1PVmxKTlMP/RFiIP9Exyy0gqGCMJpYpOfH
m1NX0LMZ9ktv61M0bgx1AZewNCLG0O6vNf1zW6S4aaczx/D5o1uqWTrra7WqIHTj
LG2dTpm1dYo2FHNkaGSwpDCGJI2H1K9l4HBcevJcNeVsE3OSZIfQXOFAdXuxJjf3
RUBZ/dzRAi0/KnZySu+1z3ua3Fbican5CwcljsMEp3K5ajr/d7zFCYDz3Osk+g3k
kvncHZtfeQNhXgfHMm+8nWRnHvpGWutUXtAIL5yzSQgeEtKANe7D2KsxK73t68iV
BkelhzqXk9o711nluA0hF4gvS20/cS675QNbQ6XLUK2N7wsCORqMSTNXxnvJze2E
1hH599dLqPMkq3P5TRCTaQLx8p/QK8Vnrgvsy5pOkSZnqiNU/Owtik0NA4Gz3WrG
f6WMRHNb+wwLdvhkqHUuMjt2OzmIUiuikKu6kt2pyJ3tXj0tPisC0UieF+6fRHG+
yxwrXqKtv/aj+gbp+X476fMWt2LR4Duihq1QkW2tE9rtkVlUMTIJgCj6T1mdC6T5
g1ELR3mi+AXCyOp5d6jpmJmKTnHjQfCPouNgalfFonJlp7Fngih0SzUpwV/XYyP7
CUy490mcRUZUhSmTH4UQV9CfxhQA8gKNbN9Oak499N6UNWSDyoiH/bh+h/BQuAli
Gn6cYgk5IKYjiO020ilG
=dlI4
-----END PGP SIGNATURE-----
Merge tag 'mfd-for-linus-3.5' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6
Pull MFD Fixes from Samuel Ortiz:
- Three Palmas fixes, One of them being a build error fix.
- Two mc13xx fixes. One for fixing an SPI regmap configuration and
another one for working around an i.Mx hardware bug.
- One omap-usb regression fix.
- One twl6040 build breakage fix.
- One file deletion (ab5500-core.h) that was overlooked during the last
merge window.
* tag 'mfd-for-linus-3.5' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6:
mfd: Add missing hunk to change palmas irq to clear on read
mfd: Fix palmas regulator pdata missing
mfd: USB: Fix the omap-usb EHCI ULPI PHY reset fix issues.
mfd: Update twl6040 Kconfig to avoid build breakage
mfd: Delete ab5500-core.h
mfd: mc13xxx workaround SPI hardware bug on i.Mx
mfd: Fix mc13xxx SPI regmap
mfd: Add terminating entry for i2c_device_id palmas table
This patch (as1564c) converts the EHCI platform drivers to use the
central ehci_setup() routine for generic controller initialization
rather than each having its own idiosyncratic approach.
The major point of difficulty lies in ehci-pci's many vendor- and
device-specific workarounds. Some of them have to be applied before
calling ehci_setup() and some after, which necessitates a fair amount
of code motion. The other platform drivers require much smaller
changes.
One point not addressed by the patch is whether ports should be
powered on or off following initialization. The different drivers
appear to handle this pretty much at random. In fact it shouldn't
matter, because the hub driver turns on power to all ports when it
binds to the root hub. Straightening that out will be left for
another day.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1563) removes a lot of duplicated code by moving the
EHCI controller suspend/resume routines into the core driver, where
the various platform drivers can invoke them as needed.
Not only does this simplify these platform drivers, this also makes it
easier for other platform drivers to add suspend/resume support in the
future.
Note: The patch does not touch the ehci-fsl.c file, because its
approach to suspend and resume is so different from all the others.
It will have to be handled specially by its maintainer.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
'ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue' (1fcb57d0) fixes
an issue where the ULPI PHYs were not held in reset while initializing
the EHCI controller. However, it also changes behavior in
omap-usb-host.c omap_usbhs_init by releasing reset while the
configuration in that function was done.
This change caused a regression on BB-xM where USB would not function
if 'usb start' had been run from u-boot before booting. A change was
made to release reset a little bit earlier which fixed the issue on
BB-xM and did not cause any regressions on 3430 sdp, the board for
which the fix was originally made.
This new fix, 'USB: EHCI: OMAP: Finish ehci omap phy reset cycle
before adding hcd.', (3aa2ae74) caused a regression on OMAP5.
The original fix to hold the EHCI controller in reset during
initialization was correct, however it appears that changing
omap_usbhs_init to not hold the PHYs in reset during it's
configuration was incorrect. This patch first reverts both fixes, and
then changes ehci_hcd_omap_probe in ehci-omap.c to hold the PHYs in
reset as the original patch had done. It also is sure to incorporate
the _cansleep change that has been made in the meantime.
I've tested this on Beagleboard xM, I'd really like to get an ack from
the 3430 sdp and OMAP5 guys before getting this merged.
v3 - Brown paper bag its too early in the morning actually run
git commit amend fix
v2 - Put cansleep gpiolib call outside of spinlock
Acked-by: Mantesh Sarashetti <mantesh@ti.com>
Tested-by: Mantesh Sarashetti <mantesh@ti.com>
Acked-by: Keshava Munegowda <keshava_mgowda@ti.com>
Tested-by: Keshava Munegowda <keshava_mgowda@ti.com>
Signed-off-by: Russ Dill <Russ.Dill@gmail.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
There are a few (new) usbdevfs capabilities which an application cannot
discover in any other way then checking the kernel version. There are 3
problems with this:
1) It is just not very pretty.
2) Given the tendency of enterprise distros to backport stuff it is not
reliable.
3) As discussed in length on the mailinglist, USBDEVFS_URB_BULK_CONTINUATION
does not work as it should when combined with USBDEVFS_URB_SHORT_NOT_OK
(which is its intended use) on devices attached to an XHCI controller.
So the availability of these features can be host controller dependent,
making depending on them based on the kernel version not a good idea.
This patch besides adding the new ioctl also adds flags for the following
existing capabilities:
USBDEVFS_CAP_ZERO_PACKET, available since 2.6.31
USBDEVFS_CAP_BULK_CONTINUATION, available since 2.6.32, except for XHCI
USBDEVFS_CAP_NO_PACKET_SIZE_LIM, available since 3.3
Note that this patch only does not advertise the USBDEVFS_URB_BULK_CONTINUATION
cap for XHCI controllers, bulk transfers with this flag set will still be
accepted when submitted to XHCI controllers.
Returning -EINVAL for them would break existing apps, and in most cases the
troublesome scenario wrt USBDEVFS_URB_SHORT_NOT_OK urbs on XHCI controllers
will never get hit, so this would break working use cases.
The disadvantage of not returning -EINVAL is that cases were it is causing
real trouble may go undetected / the cause of the trouble may be unclear,
but this is the best we can do.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The devm_ functions allocate memory that is released when a driver
detaches. This makes the code smaller and a bit simpler.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The devm_ functions allocate memory that is released when a driver
detaches. This makes the code smaller and a bit simpler.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch adds clock gating to suspend and resume functions.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We are starting to support multiple USB phys as
we should thanks for Kishon's work. DeviceTree support
for USB PHYs won't come until discussion with DeviceTree
maintainer is finished.
Together with that series, we have one fix for twl4030
which missed a IRQF_ONESHOT annotation when requesting
a threaded IRQ without a top half handler, and removal
of an unused variable compilation warning to isp1301_omap.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJP8VcOAAoJEIaOsuA1yqREeNYQAIxHOteF78nx5gMwB20agndf
vYCOB3Jymc67vcLuEf60lqoVBuQ7bxGsJyx+HlNkKrVQQfF8enL9UBhUDwvmKytm
Z1FBVmuA33PxS2aGSODkgafODO6wfnp5USzzYjEG+Hu6Q9Zt4rJ3NYakYFXdbrM3
kT3uZ2uwuOd/B1Pzt8oiMSbiF16kLeX0a6m6C4KEFViX0uGHAe/KqN4b9eSbO41q
16fvfthbAaqqSpEoMusI+kCFLku7ib3CXl5d4kgik7C7+wY08JTDWhWBMIl6wiFz
LeDIXfoX0MgEcB3vDszGCf2pgtCNR8rfl/pzuLvr6F6p+Cj6CqtgsfV8HCe43Dzr
RI7Fewl1xdz6MztKRBgr75RxqZ6VA91gLWT21nDI72DEBwyBJ1pk882CxkxSLK+b
VNtI/La9JZkUqb0PXioD0a4JUVpzw5nLatpw1PXZoLUgSozVXmhDE6Wjhl/jvl4y
ZVQVRQn2ZcyNzYY9bG2X08zyDRRvurXFfQ20CfAeBpgvvfccN9e5vGdWVbohwZro
Vn1x+fSyb6KqVOeYlzpAKf+UGXE9UM53YKpjFnmrstqUjbL5ByW2pZn5fYgJP08v
9im3SXwvs3Iz2mzwenRFUpI6PDuaTnIWgB7qquFDY1QwFyAKoPJuVN81/iPCisUM
bIYQILhqgTNNjsnPmpCr
=HwsA
-----END PGP SIGNATURE-----
Merge tag 'xceiv-for-v3.6' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-next
usb: phy: patches for v3.6 merge window
We are starting to support multiple USB phys as
we should thanks for Kishon's work. DeviceTree support
for USB PHYs won't come until discussion with DeviceTree
maintainer is finished.
Together with that series, we have one fix for twl4030
which missed a IRQF_ONESHOT annotation when requesting
a threaded IRQ without a top half handler, and removal
of an unused variable compilation warning to isp1301_omap.
This is quite a big pull request and contains patches
all over the place.
omap_udc is now a bit cleaner after removing omap2 support,
fixing some checkpatch.pl warnings and errors, switching over
to generic map/unmap routines and preventing a NULL pointer
de-reference.
s3c-hsotg has been switched over to devm_* API, got some
locking fixes and improvements and it also got an implementation
for the pullup() method.
the mass storage gadgets changed default value of the removable
parameter, dropped some unused options and made "file" and "ro"
module_parameters read-only in some cases.
ffs function got support for HID descriptor.
Some UDCs have been converted to clk_prepare_enable() and
clk_disable_unprepare().
Marvell now got support for its USB3 controller in mainline
after introducing its mv_u3d_core.c driver.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJP8VZeAAoJEIaOsuA1yqREu0YP/jSrITte+Za8HMfvV1/eVNtz
eVd+dhx82WnfPUmDHPsC+1IzCFlOIufFsqK/lWaNxVkUaL154lL85TPbxVPggNXA
zvEldifaDahDax2B5MRP8hQKpp8rNrik/ePSPv1Lts5HsfPT2aUOYIcNAPlqdaPs
4x4VejujirUGIgo1swocDOHu2nB9PTqnhtLUgLGaZcAMQtT5z/ao5NGeSugbc7sS
jvci0WKWzjxxPT77ZrcyaOrCmzTCR4yK0DZGFNsyVmY9ATTwSr/By0AgQdm36t6f
xdqjGib+Y2C+6xW35suLo1N+3qErClNuvJtvXlQ5VUpa70dsZTFu8KiCv+td7KA1
9mNeovoAiuWKSgDevqJ8g4mND/LFcrGLyKR2dkyA2NNVANgJpPY3y3sjSXV8USt5
pLGolz3XFQsUejIvrmcsHKIXNrCgJChQeaBvM13dmwhw2SWPcW0OSQnw+kPOQm8W
ByqmwSPIYxGKyd0UIcbqjlV5OXI1FcWIDSlTXbQZBId7YfVYqIuMizVvbZ8yE1pG
RTSuyo/khG4OwVKIQoxYboNYBE2MM32L8G6Hh2ataiw1M0rjIvCh6180xENKQ2I1
iK54ViWctzNx7OC5JozUS+9i5KafRPdbxNHMUPGQQXpcCtb6Q4fmeGTyFYuIfTFK
hRzP4o0SpAu7V+CoZ1Zz
=hbE6
-----END PGP SIGNATURE-----
Merge tag 'gadget-for-v3.6' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-next
usb: gadget: patches for v3.6 merge window
This is quite a big pull request and contains patches
all over the place.
omap_udc is now a bit cleaner after removing omap2 support,
fixing some checkpatch.pl warnings and errors, switching over
to generic map/unmap routines and preventing a NULL pointer
de-reference.
s3c-hsotg has been switched over to devm_* API, got some
locking fixes and improvements and it also got an implementation
for the pullup() method.
the mass storage gadgets changed default value of the removable
parameter, dropped some unused options and made "file" and "ro"
module_parameters read-only in some cases.
ffs function got support for HID descriptor.
Some UDCs have been converted to clk_prepare_enable() and
clk_disable_unprepare().
Marvell now got support for its USB3 controller in mainline
after introducing its mv_u3d_core.c driver.
The Microsoft LifeChat 3000 USB headset was causing a very reproducible
hang whenever it was plugged in. At first, I thought the host
controller was producing bad transfer events, because the log was filled
with errors like:
xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD
However, it turned out to be an xHCI driver bug in the ring expansion
patches. The bug is triggered When there are two ring segments, and a
TD that ends just before a link TRB, like so:
______________ _____________
| | ---> | setup TRB B |
______________ | _____________
| | | | data TRB B |
______________ | _____________
| setup TRB A | <-- deq | | data TRB B |
______________ | _____________
| data TRB A | | | | <-- enq, deq''
______________ | _____________
| status TRB A | | | |
______________ | _____________
| link TRB |--------------- | link TRB |
_____________ <--- deq' _____________
TD A (the first control transfer) stalls on the data phase. That halts
the ring. The xHCI driver moves the hardware dequeue pointer to the
first TRB after the stalled transfer, which happens to be the link TRB.
Once the Set TR dequeue pointer command completes, the function
update_ring_for_set_deq_completion runs. That function is supposed to
update the xHCI driver's dequeue pointer to match the internal hardware
dequeue pointer. On the first call this would work fine, and the
software dequeue pointer would move to deq'.
However, if the transfer immediately after that stalled (TD B in this
case), another Set TR Dequeue command would be issued. That would move
the hardware dequeue pointer to deq''. Once that command completed,
update_ring_for_set_deq_completion would run again.
The original code would unconditionally increment the software dequeue
pointer, which moved the pointer off the ring segment into la-la-land.
The while loop would happy increment the dequeue pointer (possibly
wrapping it) until it matched the hardware pointer value.
The while loop would also access all the memory in between the first
ring segment and the second ring segment to determine if it was a link
TRB. This could cause general protection faults, although it was
unlikely because the ring segments came from a DMA pool, and would often
have consecutive memory addresses.
If nothing in that space looked like a link TRB, the deq_seg pointer for
the ring would remain on the first segment. Thus, the deq_seg and the
software dequeue pointer would get out of sync.
When the next transfer event came in after the stalled transfer, the
xHCI driver code would attempt to convert the software dequeue pointer
into a DMA address in order to compare the DMA address for the completed
transfer. Since the deq_seg and the dequeue pointer were out of sync,
xhci_trb_virt_to_dma would return NULL.
The transfer event would get ignored, the transfer would eventually
timeout, and we would mistakenly convert the finished transfer to no-op
TRBs. Some kernel driver (maybe xHCI?) would then get stuck in an
infinite loop in interrupt context, and the whole machine would hang.
This patch should be backported to kernels as old as 3.4, that contain
the commit b008df60c6 "xHCI: count free
TRBs on transfer ring"
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: stable@vger.kernel.org
The host controller port status register supports CAS (Cold Attach
Status) bit. This bit could be set when USB3.0 device is connected
when system is in Sx state. When the system wakes to S0 this port
status with CAS bit is reported and this port can't be used by any
device.
When CAS bit is set the port should be reset by warm reset. This
was not supported by xhci driver.
The issue was found when pendrive was connected to suspended
platform. The link state of "Compliance Mode" was reported together
with CAS bit. This link state was also not supported by xhci and
core/hub.c.
The CAS bit is defined only for xhci root hub port and it is
not supported on regular hubs. The link status is used to force
warm reset on port. Make the USB core issue a warm reset when port
is in ether the 'inactive' or 'compliance mode'. Change the xHCI driver
to report 'compliance mode' when the CAS is set. This force warm reset
on the root hub port.
This patch should be backported to stable kernels as old as 3.2, that
contain the commit 10d674a82e "USB: When
hot reset for USB3 fails, try warm reset."
Signed-off-by: Stanislaw Ledwon <staszek.ledwon@linux.intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Andiry Xu <andiry.xu@amd.com>
Cc: stable@vger.kernel.org
usb_get_phy will return -ENODEV if it's not able to find the phy. Hence
fixed all the callers of usb_get_phy to check for this error condition
instead of relying on a non-zero value as success condition.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
A recent commit, [PATCH] Fix OMAP EHCI suspend/resume failure
(i693) '354ab856' causes ehci probe to fail on omap3xxx. This
exposed bugs in the ehci_hcd_omap_probe error path causing
an oops.
On the error path, call usb_remove_hcd if usb_add_hcd has been
called, and call usb_put_hcd if usb_alloc_hcd has been called.
Tested on BB-xM.
Signed-off-by: Russ.Dill@ti.com
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1562) cleans up the definitions of the EHCI extended
registers to be consistent with the definitions of the standard
registers. This makes the code look a lot nicer, with no functional
change.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The struct fhci_regs (in drivers/usb/host/fhci.h) is basically a redefinition
of the struct qe_usb_ctlr (in arch/powerpc/include/asm/immap_qe.h).
The qe_usb_ctlr struct is preferrable once it uses accurately the registers'
names found in the Freescale's QUICC Engine Block Reference Manuals (QEIWRM.pdf
Rev.4.4 Chapter 19 for MPC836xE series and MPC8323ERM.pdf Rev.2 Chapter 36 for
MPC832xE series), making easier to map the FHCI device driver to the hardware
manual. Also, as the FHCI driver uses the USB Controller registers, the name
qe_usb_ctlr is a more precise representation of the hardware than fhci_regs.
Signed-off-by: Guilherme Maciel Ferreira <guilherme.maciel.ferreira@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add a linked list for keeping multiple PHY instances with different
types so that we can have separate USB2 and USB3 PHYs on one single
board. _get_phy_ has been changed so that the controller gets
the transceiver by type. _remove_phy_ has been added to let the phy
be removed from the phy list.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
_transceiver() in otg.c is replaced with _phy. usb_set_transceiver is
replaced with usb_add_phy to make it similar to other usb standard
function names like usb_add_hcd.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
This lets us catch the USB fixes that went into 3.5-rc3 into this branch,
as we want them here as well.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The ohci-nxp was assuming the clock was enabled by the board init or
bootloader and just enabling the pll. This enables the usbd and otg
clocks this periferal also needs.
Signed-off-by: Alexandre Pereira da Silva <aletes.xgr@gmail.com>
Acked-by: Roland Stigge <stigge@antcom.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Correct "Enbale" -> "Enable", in the desc for USB_HCD_BCMA
and USB_HCD_SSB.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If the platform_data is not set, pdata will be uninitialized value.
Since the driver has the following code, if the condition is true when
the pdata is uninitialized value, the driver may jump to the illegal
phy_init().
if (pdata && pdata->phy_init)
pdata->phy_init();
This patch also fixes the following warning:
CC drivers/usb/host/ehci-hcd.o
drivers/usb/host/ehci-sh.c: In function ‘ehci_hcd_sh_probe’:
drivers/usb/host/ehci-sh.c:104: warning: ‘pdata’ may be used uninitialized in this function
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Its observed with some PHY, the 60Mhz clock gets
cut too soon for OMAP EHCI, leaving OMAP-EHCI in a bad state.
So on starting port suspend, make sure the 60Mhz clock to EHCI
is kept alive using an internal clock, so that EHCi can cleanly
transition its hw state machine on a port suspend.
Its not proven if this is the issue hit on USB3333,
but the symptoms look very similar.
Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
Signed-off-by: Vikram Pandita <vikram.pandita@ti.com>
Signed-off-by: Volodymyr Mieshkov <x0182794@ti.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ohci_finish_controller_resume() is intended to be used in platform specific
drivers ohci-*.c, included from ohci-hcd.c. Some of them don't actually use
ohci_finish_controller_resume(), so mark it as __maybe_unused.
Signed-off-by: Roland Stigge <stigge@antcom.de>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This fixes the following warning:
In file included from drivers/usb/host/ehci-hcd.c:1246:0:
drivers/usb/host/ehci-xilinx-of.c:293:2: warning: initialization from incompatible pointer type [enabled by default]
drivers/usb/host/ehci-xilinx-of.c:293:2: warning: (near initialization for 'ehci_hcd_xilinx_of_driver.shutdown') [enabled by default]
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
After commit aaa0ef289a "PS3 EHCI QH
read work-around", Terratec Grabby (em28xx) stopped working with AMD
Geode LX 800 (USB controller AMD CS5536). Since this is a PS3 only
fix, the following patch adds a conditional block around it.
Signed-off-by: Ricardo Martins <rasm@fe.up.pt>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
