Since the wakelock was removed, an interrupt coming during the
transition to system suspend relies on pm_stay_awake() to indicate
that the controller's wakeup source is now active. However, this
depends on pm_save_wakeup_count() to be called by the process
that initiated the suspend. The forthcoming autosleep feature will
be doing this.
But until autosleep is implemented, for robustness additionally
introduce a .suspend_noirq callback which checks for pending
interrupts and returns -EBUSY if there are any, which will force
the PM core to unwind its suspend actions.
Change-Id: If286d654b667d00a0130accb7a783258901ff760
Signed-off-by: Jack Pham <jackp@codeaurora.org>
It is observed that sometimes msm_bus voting upate API taking
longer time to return which delays the HSIC resume sequence
which is time critical.
CRs-Fixed: 388430
Change-Id: I5ad93ee4bbea2b83dad8cc5c8ece8b72ee433d9f
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
In some cases of system suspend, it's possible a runtime resume
may be called on a device if it's already autosuspended (say, in
order to set a device- or port-specific feature, such as the remote
wakeup setting) just prior to putting it back into low power mode.
In this case, if the controller was also auto-suspended it will also
be temporarily runtime resumed by the fact that it is an ancestor to
said device.
The incoming wakelock re-implementation from Google based on wakeup
sources breaks this driver in the above scenario since now acquiring
a wakelock (which calls __pm_stay_awake) during runtime resume while
a simultaneous asynchronous suspend callback of another device is
called will cause it to abort the entire suspend attempt.
This prompts reconsideration of why a wakelock is needed in this
driver. One apparent use is to ensure this controller's runtime
suspend is called before system suspend is allowed. In other words,
we wish to guarantee the HSIC child devices are suspended before
suspending the controller. This can be done by checking that the root
hub device is suspended, else we can abort the suspend callback by
returning -EBUSY.
To handle the cases of interrupts happening during systemwide suspend
but after the controller was already suspended (and thus its runtime
PM disabled), call the pm_stay_awake() to denote a wakeup event. This
will cause the suspend to abort as well as block it from happening
until the interrupt can be serviced--after the controller resumes.
Change-Id: I4fab47c54f7d57065833d96261de08dcdd7238dc
Signed-off-by: Jack Pham <jackp@codeaurora.org>
Currently as part of host bus suspend handling, voting for
XO shutdown and VDD minimization due to which devices connected
to HSUSB 3rd instance will not wakeup the system from system suspend.
Add support for USB remote wakeup feature for detecting devices
connected on HSUSB 3rd instance in case of VDD minimization provided
HW rework for routing D+ line to MPM is implemented.
CRs-Fixed: 380386
Change-Id: Ie8560b99c51efc466dfd257747bbf38bec6e6ba0
Signed-off-by: Vijayavardhan Vennapusa <vvreddy@codeaurora.org>
An ASYNC interrupt is an indication by hardware that some
activity has happended on USB lines in LPM (low power mode),
and USB software should now bring it out of LPM.
Ideally, hardware should give one more interrupt after coming
out of LPM so that USB driver can process that accordingly.
But, sometimes this interrupt is not generated from h/w for
remote wakeup event in host mode. Hence, resume root hub on
receiving the ASYNC interrupt from hardware in Host mode.
CRs-Fixed: 369298
CRs-Fixed: 368948
Change-Id: Ifb166c1f3c749ab8c615308ab52d85ccdc666733
Signed-off-by: Chiranjeevi Velempati <cvelempa@codeaurora.org>
Add runtime power management support in the driver which allows
putting the hardware in low power state, turning off LDOs
and releasing wakelock.
This LPM (aka low power state) support is currently added as part
of USB disconnect and wall-charger connect. LPM support would
later be extended to USB bus suspend as well. Also, support for PHY
retention mode and VDD minimization would be added later.
This commit also adds debugfs nodes that can used to simulate
cable connect and disconnects as A or B device. Following are
the nodes:
-->msm_dwc3/id : Boolean value
-->msm_dwc3/bsv : Boolean value
-->msm_dwc3/connect : can be set to enable/disable
User should first update id/bsv values before enabling 'connect'.
dwc3-msm device is parent of dwc3-core and its runtime PM is managed
by dwc3_otg driver which is responsible for the state transitions
based on notifications from DWC3 h/w or ext_xceiver (using PMIC) for
cable connect and disconnect. This change also allows dwc3 gadget and
host to acquire PM count for the case when dwc3-otg is not present -
e.g. host and device only configurations.
Change-Id: Idd9a59c1ffd46bd98228c9fd4441f668b763534d
Signed-off-by: Manu Gautam <mgautam@codeaurora.org>
Halt the system when HSIC system error happens and dump HSIC
link registres. Also, save the address of msm_hsic_hcd
structure to a global pointer.
CRs-Fixed: 375536
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
Change-Id: Ia346778911f610338f38492bc1ff0e8a9c7a87c7
There is a possibility of HSIC phy getting locked up if RUN/STOP
bit is set before finishing the resume signaling. Hence do not
set the RUN/STOP bit before setting PORT_RESUME bit. Since
PORT_RESUME bit gets cleared automatically by HSIC HW after bus
resume is completed, need to set RUN/STOP bit right after that.
CRs-Fixed: 372145
Change-Id: Icb9effefe14c10f13cfbb3d8f1840c8bdd96aea4
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
There could be race condition between h/w initiating sof
(start of frames) and finishing port reset. This can
cause hsic phy lockup, which results in enumeration failure.
Avoid this race condition by:
1. Moving to the old enumeration sequence where set_address is
initiated before get_device descriptor. This results in one
port reset instead of two port resets.
2. Halt usb controller before initiating port reset and start it after
port reset is complete. This is tricky because PORT_RESET bit
automatically clears when h/w completes the reset and failure to
start the controller within 3ms causes the peripheral device to
suspend resulting in enumeration failure. Hence, after setting
port reset bit forcefully drive strobe/data lines to reset using
ulpi interface and once port reset is complete, disable forceful
reset and start the controller in atomic context.
CRs-fixed: 364458, 359930
Change-Id: I49a2eac8043eb3001956c7ee9ead2c3a901524db
Signed-off-by: Vamsi Krishna <vskrishn@codeaurora.org>
xcvr clock needs to be turned off before de-asserting clock
reset to hsic controller to prevent phy lock up. However, xcvr
clock is defined as parent of system clock, which is always on
during hsic controller reset, prevents xcvr clock being turned
off. Turn off system clock to turn off both system & xcvr clocks
during hsic controller clock reset. Also, simplify reset routine
by removing unnecessary code and delays.
Change-Id: Ic5fb667b4686a724d5ecfc034770f1e7db92b4d6
Signed-off-by: Vamsi Krishna <vskrishn@codeaurora.org>
In Synopsis DWC3 controller, PORTSC register access involves multiple clock
domains. When the software does a PORTSC write, handshakes are needed
across these clock domains. This results in long access times, especially
for USB 2.0 ports. In order to solve this issue, when the PORTSC write
operations happen on the system bus, the command is latched and system bus
is released immediately. However, the real PORTSC write access will take
some time internally to complete. If the software quickly does a read to
the PORTSC, some fields (port status change related fields like OCC, etc.)
may not have correct value due to the current way of handling these bits.
The workaround is to give some delay (5 mac2_clk -> UTMI clock = 60 MHz ->
(16.66 ns x 5 = 84ns) ~100ns after writing to the PORTSC register.
Add controller vendor id and revision fields to the XHCI platform data.
Update quirks field based on the vendor id and revision in the XHCI
platform driver.
CRs-fixed: 371299
Change-Id: Ibe4a88119c483afb522e9a96667f17dccbf74122
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
The warning 'xhci_msix_sync_irqs' defined but not used happened in case
both CONFIG_PCI and CONFIG_PM are not set.
Change-Id: Id94b02fd2d2a87e5df79d32ff251e2985db22554
Signed-off-by: Ido Shayevitz <idos@codeaurora.org>
This is first release of otg driver for the dwc3 Synopsys USB3 core.
The otg driver implements the otg final state machine and control the
activation of the device controller or host controller.
In this first implementation, only simple DRD mode is implemented,
determine if A or B device according to the ID pin as reflected in the
OSTS.ConIDSts field.
Change-Id: I6533490aa2adfe3641ffa926666867c19a979217
Signed-off-by: Ido Shayevitz <idos@codeaurora.org>
commit e879990 (USB: EHCI: remove usages of hcd->state) removed the
hcd->state usage in EHCI driver. Instead rh_state field of ehci_hcd
struct should be used. But the current code is still using
hcd->state. This bug is introduced during 3.4 kernel porting.
If rh_state field is not updated to SUSPEND during root hub suspend,
the root hub will not be resumed upon device connection or remote wakeup.
Change-Id: Id47e7c650c03cda2e7be00be4e8b92a47257fc6a
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
This change add support in ci13xxx_msm_hsic driver and
ehci-msm-hsic driver for VDDCX corner voting.
In case a VDDCX corner resource is supported by the platform,
it will be used. Else, the legacy voting for specific voltage
level will be used.
Change-Id: Iae91d1c945f9b61340628b2fc7c7727e4cca6a1e
CRs-Fixed: 354458
Signed-off-by: Amit Blay <ablay@codeaurora.org>
Signed-off-by: David Collins <collinsd@codeaurora.org>
Host driver's platform_suspend/resume routines are valid only if
LINK is operating in host mode and root-hub has been registered.
Hence, check for 'rh_registered' flag of hcd to process
platform_suspend/resume further.
Change-Id: I5278bd92b30ad5b3a154b5f9f505982097f39ace
Signed-off-by: Manu Gautam <mgautam@codeaurora.org>
Currently writing 0x0 into AHBMODE register which means both data
transactions and QH and TD descriptors are non-posted writes to
system memory. As per HW team recommendation, should write 0x08 value
to set AHB HPROT mode into the AHBMODE register which allows posted
data writes to system memory and will improve the throughput numbers.
Change-Id: Ib44a8cfe11c6ff96ff712643227532e24548e706
Signed-off-by: Vijayavardhan Vennapusa <vvreddy@codeaurora.org>
[sboyd: Only the echi-msm.c part]
This patch changes OTG driver to support different
OTG statemachine states for OTG2.0 complaince. It will
also enable to swap Host role between two OTG devices
via HNP and enable B device to request A device to start
VBUS session via SRP.
Change-Id: Ibe2519ff1570768f51e879af483a6f5c23b38d8f
Signed-off-by: Vijayavardhan Vennapusa <vvreddy@codeaurora.org>
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
[sboyd: Only ehci-msm.c part]
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
In current design, PM usage counter operations are scattered across
charging detection work, state machine work, interrupt handler and
resume work. This did not give any problems for typical device mode
or host mode use cases. But with ACA implementation, there will be
many corner cases where PM usage operations can go wrong and device
stays out of low power mode (LPM). Hence leave PM usage counter
operations to state machine work, which knows best about the device
state.
Don't create device and host controller platform devices as children
of OTG device. This helps OTG state machine to know about host bus
suspend and can take a decision whether low power mode is possible or
not.
Change-Id: I00474e396546d2567d09409e70591a6c9d325c06
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
[sboyd: only the ehci-msm part]
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
There can be SOFs underway after suspending the port
(setting susp bit) which leads to phy lockup or unexpected
device disconnections. Halt the controller before setting
port suspend bit to avoid such issues.
CRs-Fixed: 363920, 356212
Change-Id: I9ab3fe0556e845621d9314b66d2af955251284fb
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
EHCI core intiates HNP by calling otg_start_hnp() API when OTG port
is put into suspend to notify OTG driver which will take care of
HNP by suspending host and kicking gadget.
Change-Id: I2982b9f49140c2dcf2a32691e74f177e8d5d08cb
Signed-off-by: Vijayavardhan Vennapusa <vvreddy@codeaurora.org>
Introduce a new callback method for HCD to receive notification
from EHCI core that HNP enabled port is suspended. HCD may call
otg_start_hnp() to kick OTG state machine. Typically OTG driver
starts A_AIDL_BDIS timer and wait for B-device disconnection.
Change-Id: I1dc02c3ac9cc39ce3f45a4ff05a389fc36e4e952
Signed-off-by: Pavankumar Kondeti <pkondeti@qualcomm.com>
Liquid platform on 8064 has ehci compliant HSUSB core4 to support
GOBI module via PCIe MINI Card CONNECTOR. This patch adds platform
device instance for EHCI compliant USB Host Controller driver.
Change-Id: I0d01babc3a818b308216bb57e48522cd2b62e07c
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
This patch adds support for EHCI compliant USB Host Controller
for Liquid on 8064.
This driver supports Host only mode and is different from ehci-msm
which relies on OTG driver for putting hardware in low pwer mode
and PHY initialization as well.
Change-Id: I84b63b2577311900a0b434f53df547bad62f6316
Signed-off-by: Manu Gautam <mgautam@codeaurora.org>
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
This patch adds support for EHCI compliant USB Host Controller
present in MSM chips. This Controller uses an HSIC PHY which
communicates with downstream devices using STROBE/DATA lines.
HSIC is a supplement to USB 2.0 specification and is preferred
for chip-to-chip interconnect (having maximum circuit length of
10cm) as it removes the analog transceivers.
Change-Id: Id54dcc802e606e0ff7dd31bc64671a797cd8bc09
Signed-off-by: Vijayavardhan Vennapusa <vvreddy@codeaurora.org>
Signed-off-by: Manu Gautam <mgautam@codeaurora.org>
This change has been split out of "USB: EHCI: msm: Add support
for HSIC based Host Controller". It takes only the bits that
change the way how ehci drivers are registered.
Change-Id: I8491e4a52d767ea8046a82cab2589a44d0b660aa
Signed-off-by: Vijayavardhan Vennapusa <vvreddy@codeaurora.org>
Signed-off-by: Manu Gautam <mgautam@codeaurora.org>
Modify the maximum rate at which the HSIC host controller will
issue interrupts from 125us to 8ms. This allows HSIC controller
to aggregate all the interrupts generated in 8ms which improves
the power savings without changing the overall performance of the
driver.
CRs-Fixed: 363135, 354475
Change-Id: I17034451b6ec5a55e63054f66ad2818fc1d59824
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
[sboyd: Drop msm driver changes]
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
HSIC PHY stuck issue is observed if HSIC HW goes to low power
mode in the middle of resume sequence initiated by remote wakeup.
In case of USB bus resume due to remote wakeup set Run/Stop bit
right after receiving remote wakeup interrupt and do not allow
runtime suspend in the middle of remote wakeup.
Also, add correct way to update PORTSC register in driver suspend
and resume routines.
CRs-Fixed: 360555
Change-Id: I0033541042db028d85ef49907dfd37ad5a75c8aa
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
[sboyd: Only take ehci-hcd.c part]
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Is is observed that ehci->async->qh_next ptr is not getting freed up
which is causing crash in ehci_mem_cleanup function. As a temporary
workaround unlink the pending queue heads as a part of ehci_stop.
CRs-fixed: 301134
Signed-off-by: Anji jonnala <anjir@codeaurora.org>
Embedded High-speed Host Electrical Test or EHSET defines following
tests for a USB Host port:
1: TEST_SE0
2: TEST_J
3: TEST_K
4: TEST_PACKET
5: HS_HOST_PORT_SUSPEND_RESUME
6: SINGLE_STEP_GET_DEV_DESC
7: SINGLE_STEP_SET_FEATURE
Tests 1-4 needs support from EHCI i.e setting test control bits in
PORTSC register.
Tests 5&6 dont require any additional support from EHCI stack.
Where as 7th test requires support in EHCI and is being added in this
patch.
For SINGLE_STEP_SET_FEATURE test, first the SETUP request of GetDesc
is sent which is followed by the IN stage after a delay of 15 secs.
SINGLE_STEP_SET_FEATURE test can be initiated like any other 1-4 Test
by issuing a SetFeature request to the root hub with Test-Selector
value = 0x06.
Change-Id: I6ad2bd5fc14c31c80f0291a82fef40c2c5a9045a
Signed-off-by: Manu Gautam <mgautam@qualcomm.com>
isp1763A is ST-E controller which communicates with MSM 8660 over
EBI2 Bus. This patch brings in the the reference driver provided
by ST-E with the following changes:
->New Makefile added to support compilation from inside kernel tree
->Remove -Werror from CFLAGS
->Fix minor compilation error because of some USB header files got
modified in b/w .28 and .35 kernel
Change-Id: Ief053d5d25848a514069302fe35d59e744ee92b5
Signed-off-by: Manu Gautam <mgautam@codeaurora.org>
The immediately preceding gpio_direction_output() already set the value,
so there's no need to repeat it. This also prevents gpio_set_value() from
WARNing when the GPIO is sleepable (e.g. is on an I2C expander); the set
direction API is always sleepable, but plain set_value isn't.
Cc: <stable@vger.kernel.org> # v3.3
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1547) rearranges the Power Management parts of the
ehci-tegra driver to match the conventions used in other EHCI platform
drivers. In particular, the controller should not be powered down by
the root hub's suspend routine; the controller's power level should be
managed by the controller's own PM methods.
The end result of the patch is that the standard ehci_bus_suspend()
and ehci_bus_resume() methods can be used instead of special-purpose
routines. The driver now uses the standard dev_pm_ops methods instead
of legacy power management. Since there is no supported wakeup
mechanism for the controller, runtime suspend is forbidden by default
(this can be overridden via sysfs, if desired).
These adjustments are needed in order to make ehci-tegra compatible
with recent changes to the USB core. The core now checks the root
hub's status following bus suspend; if the controller is automatically
powered down during bus suspend then the check will fail and the root
hub will be resumed immediately. Doing the controller power-down in a
separate method avoids this problem.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Tested-by: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1545) fixes a problem affecting several ASUS computers:
The machine crashes or corrupts memory when going into suspend if the
ehci-hcd driver is bound to any controllers. Users have been forced
to unbind or unload ehci-hcd before putting their systems to sleep.
After extensive testing, it was determined that the machines don't
like going into suspend when any EHCI controllers are in the PCI D3
power state. Presumably this is a firmware bug, but there's nothing
we can do about it except to avoid putting the controllers in D3
during system sleep.
The patch adds a new flag to indicate whether the problem is present,
and avoids changing the controller's power state if the flag is set.
Runtime suspend is unaffected; this matters only for system suspend.
However as a side effect, the controller will not respond to remote
wakeup requests while the system is asleep. Hence USB wakeup is not
functional -- but of course, this is already true in the current state
of affairs.
This fixes Bugzilla #42728.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Steven Rostedt <rostedt@goodmis.org>
Tested-by: Andrey Rahmatullin <wrar@wrar.name>
Tested-by: Oleksij Rempel (fishor) <bug-track@fisher-privat.net>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pull MFD fixes from Samuel Ortiz:
"We have 3 build fixes, a OMAP USB host PHY reset fix and the twl6040
conversion to an i2c driver. The latter may not sound like a fix but
the twl6040 MFD driver won't probe without it, triggering an OMAP4
audio regression."
* tag 'mfd-for-linus-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6:
mfd: Fix modular builds of rc5t583 regulator support
mfd: Fix asic3_gpio_to_irq
ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue
mfd: Convert twl6040 to i2c driver, and separate it from twl core
mfd : Fix dbx500 compilation error
This call is not needed; the IRQ controller should (and does) set up
interrupts correctly. set_irq_flags() isn't exported to modules, to
this also fixes compilation of ehci-tegra.c as a module.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1544) fixes a problem affecting some EHCI controllers.
They can generate interrupts whenever the STS_FLR status bit is turned
on, even though that bit is masked out in the Interrupt Enable
register.
Since the driver doesn't use STS_FLR anyway, the patch changes the
interrupt routine to clear that bit whenever it is set, rather than
leaving it alone.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-and-tested-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1542) changes the criterion ehci-hcd uses to tell when
it needs to resume the controller's root hub. A resume is needed when
a port status change is detected, obviously, but only if the root hub
is currently suspended.
Right now the driver tests whether the root hub is running, and that
is not the correct test. In particular, if the controller has died
then the root hub should not be restarted. In addition, some buggy
hardware occasionally requires the root hub to be running and
sending out SOF packets even while it is nominally supposed to be
suspended.
In the end, the test needs to be changed. Rather than checking whether
the root hub is currently running, the driver will now check whether
the root hub is currently suspended. This will yield the correct
behavior in all cases.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Peter Chen <B29397@freescale.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
It is observed that the echi ports of 3430 sdp board
are not working due to the random timing of programming
the associated GPIOs of the ULPI PHYs of the EHCI for reset.
If the PHYs are reset at during usbhs core driver, host ports will
not work because EHCI driver is loaded after the resetting PHYs.
The PHYs should be in reset state while initializing the EHCI
controller.
The code which does the GPIO pins associated with the PHYs
are programmed to reset is moved from the USB host core driver
to EHCI driver.
Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com>
Reviewed-by: Partha Basak <parthab@india.ti.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Tested-by: Igor Grinberg <grinberg@compulab.co.il>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Re-define XHCI_LEGACY_DISABLE_SMI and used it in right way. All SMI enable
bits will be cleared to zero and flag bits 29:31 are also cleared to zero.
Other bits should be presvered as Table 146.
This patch should be backported to kernels as old as 2.6.31.
Signed-off-by: Alex He <alex.he@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
The caller is allowed to specify the GFP flags for these functions.
We should prefer their flags unless we have good reason. For
example, if we take a spin_lock ourselves we'd need to use
GFP_ATOMIC. But in this case it's safe to use the callers GFP
flags.
The callers all pass GFP_ATOMIC here, so this change doesn't affect
how the kernel behaves but we may add other callers later and this
is a cleanup.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The suspend operation of VIA xHCI host have some issues and
hibernate operation works fine, so The XHCI_RESET_ON_RESUME
quirk is added for it.
This patch should base on "xHCI: Don't write zeroed pointer
to xHC registers" that is released by Sarah. Otherwise, the
host system error will ocurr in the hibernate operation
process.
This should be backported to stable kernels as old as 2.6.37,
that contain the commit c877b3b2ad
"xhci: Add reset on resume quirk for asrock p67 host".
Signed-off-by: Elric Fu <elricfu1@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
The xHCI 1.0 spec errata released on June 13, 2011, changes the ordering
that the xHCI registers are saved and restored in. It moves the
interrupt pending (IMAN) and interrupt control (IMOD) registers to be
saved and restored last. I believe that's because the host controller
may attempt to fetch the event ring table when interrupts are
re-enabled. Therefore we need to restore the event ring registers
before we re-enable interrupts.
This should be backported to kernels as old as 2.6.37, that contain the
commit 5535b1d5f8 "USB: xHCI: PCI power
management implementation"
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Elric Fu <elricfu1@gmail.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: stable@vger.kernel.org
The xhci_save_registers() function saved the event ring dequeue pointer
in the s3 register structure, but xhci_restore_registers() never
restored it. No other code in the xHCI successful resume path would
ever restore it either. Fix that.
This should be backported to kernels as old as 2.6.37, that contain the
commit 5535b1d5f8 "USB: xHCI: PCI power
management implementation".
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Elric Fu <elricfu1@gmail.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: stable@vger.kernel.org
When xhci_mem_cleanup() is called, we can't be sure if the xHC is
actually halted. We can ask the xHC to halt by writing to the RUN bit
in the command register, but that might timeout due to a HW hang.
If the host controller is still running, we should not write zeroed
values to the event ring dequeue pointers or base tables, the DCBAA
pointers, or the command ring pointers. Eric Fu reports his VIA VL800
host accesses the event ring pointers after a failed register restore on
resume from suspend. The hypothesis is that the host never actually
halted before the register write to change the event ring pointer to
zero.
Remove all writes of zeroed values to pointer registers in
xhci_mem_cleanup(). Instead, make all callers of the function reset the
host controller first, which will reset those registers to zero.
xhci_mem_init() is the only caller that doesn't first halt and reset the
host controller before calling xhci_mem_cleanup().
This should be backported to kernels as old as 2.6.32.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Elric Fu <elricfu1@gmail.com>
Cc: stable@vger.kernel.org
