PHY suspend fails as part of USB LPM at times. Currently, we are resetting
the PHY and Link during this failure case, but the EHCI stack is not reset
due to which we are seeing device enumeration failure cases. Fix this issue
by removing hcd and adding hcd back during PHY suspend failure.
CRs-Fixed: 382279
Change-Id: I2d69e75409ec2b783dbdd06de4f34fe0356c1c45
Signed-off-by: Chiranjeevi Velempati <cvelempa@codeaurora.org>
(cherry picked from commit ce16958d07cedf2c46c97a9b0088a410c1a464a2)
HSIC controller can not detect HSIC device in low power mode. Hence
controller suspend is allowed only when port is enabled. But this
check is done in controller suspend routine. Controller suspend is
attempted after root hub bus is suspended. Even if we fail, controller
suspend, root hub bus remains in suspend state. This would delay
the enumeration of HSIC device as root hub bus resume takes some time.
CRs-Fixed: 396444
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
(cherry picked from commit a723f744025854c7132410fd1699bc0997617fb9)
Change-Id: I30c2117a0a6debfbc98a08610a83b56d5ac75f5b
Signed-off-by: Sudhir Sharma <sudsha@codeaurora.org>
In order to remove queue heads(QH) from Asynchronous Schedule Interrupt
on Async Advance(IAA) bit is used in USBCMD as doorbell by ehci driver
to handshake with host controller. When the host controller has evicted
all appropriate cached schedule states, then the host controller will
assert an interrupt which indicates ehci driver that it is safe to
modify a removed queue head from the asynchronous list.
EHCI driver walks through the asynchronous schedule list to search for
the QH(say QH1) which needs to be unlinked from HW. It removes QH1 from
the list, sets ehci->reclaim points to QH1 and starts iaa watchdog timer
after setting IAAD bit in USBCMD register. Before getting IAAD interrupt
for QH1, rest of other interface drives can also issue unlinking of their
QHs which get added to the list of QHs to be removed and pointed by
ehci->reclaim. It is possible that IAAD interrupt gets delayed for more
than current watchdog timeout value. This causes watchdog handler to
finish the unlinking process of QH1 with ehci lock held. Unlinking process
ends by setting QH1's next pointer to NULL, ehci->reclaim pointing to next
QH to be unlinked(say QH2) and calling qh_completions() to retire all the
transfer descriptor associated with QH1. qh_completions() releases
ehci->lock in ehci_urb_done(). There is a possibility of controller
asserting IAAD interrupt during this time on other core. After ehci lock
is released, ehci irq handler gets a chance to acquire ehci lock and
execute which results in premature unlinking of QH2, since ehci->reclaim
now points to QH2. QH2 is not yet removed from the asynchronous list and
ehci driver has not initiated IAAD handshake for QH2. Similarly unlinking
ends for QH2 by setting QH2's next qh pointer to NULL, since QH2 is not yet
removed from asynchronous list, this breaks the list. Due to this racing
between IAAD interrupt and watchdog timer interrupt ehci driver loses
track of which IAAD interrupt triggered for which QH. This results in NULL
pointer dereference while searching for subsequent QHs to be unlinked, in
already broken asynchronous list. Hence increase the IAA watchdog timeout
value from 10ms to a higher value of 100ms. Higher timeout value avoids
the race between IAAD interrupt and IAA watchdog handler and allows IAAD
interrupt to finish the unlinking of QH. Watchdog handler is still be
used to take care of scenarios when controller does not generate IAAD
interrupt for some reason (which is rare, but possible).
CRs-Fixed: 396250
Change-Id: Id1deccf834ca1108121c6533e016b9b3f5fc0ff2
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
(cherry picked from commit 8a657de16d301e1bfab7ba69349446720d4a70e3)
Signed-off-by: Sudhir Sharma <sudsha@codeaurora.org>
During HSIC probe driver registers the level triggered interrupt
on wakeup gpio. Wakeup irq line is disabled based on the return
status of interrupt registration. There is a possibility that
wakeup gpio is already pulled high after registering the interrupt
which can cause wakeup interrupts to be fired on continuously
without getting chance to disable the irq line. Hence do not
enable wake up interrupt on request irq.
CRs-Fixed: 394540
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
(cherry picked from commit bbcdcbc3f09cc90d4b8fdd607244c3d73c9ae801)
Conflicts:
drivers/usb/host/ehci-msm-hsic.c
Change-Id: I9b20d54d919333d11201d30513b4111f3fb31df3
Signed-off-by: Sudhir Sharma <sudsha@codeaurora.org>
This change addresses following enhancements to debug
logging:-
1) Add data payload logging which is not currently
supported. This helps to sniff first 32 bytes of data
being sent and received. Data payload logging is
enabled by default. To disable data payload logging:-
echo 0 > /sys/module/ehci_hcd/parameters/enable_payload_log
2) Current urb submission event logging does not cover
root hub submissions, hence move urb submission logging
to hcd driver.
3) Current urb submission event logging does not return
the correct status if submission fails. Hence log the
return status of urb submission.
CRs-Fixed: 393294
Change-Id: Ic7e555e1545ec7d7b0e4042cd35235e0af26fb01
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
(cherry picked from commit 4d50a43dce8645955d8ed739d7a183e62922c721)
Signed-off-by: Sudhir Sharma <sudsha@codeaurora.org>
If PM resume and Wakeup irq happen at same time
its possible to disable wakeup irq twice. Prevent
the same by protecting with spinlock
CRs-Fixed: 396895
Change-Id: I3320478d6c770787bc571964f4a38dce6927af63
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
(cherry picked from commit d343c01025fc3bb597fbb60c8fc4369cc17cbf5d)
Signed-off-by: Sudhir Sharma <sudsha@codeaurora.org>
HSIC controller should send SOF with in 3 msec after completing
the resume signal. If processor is in idle sleep state, the timer
interrupt generated by HSIC controller to indicate resume completion
gets delayed. If the interrupt handler is not run with in 3msec
after resume, the resume sequence is repeated. Disallow processor
idle sleep to avoid multiple resume cycles.
CRs-Fixed: 397154
Change-Id: Ibc8965ad8bcd94e0b1b1d39b5b2ad8f39cf51095
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
(cherry picked from commit 4f5dc3be7b2b9939bc7a1b9526ccb70d93b53361)
Signed-off-by: Sudhir Sharma <sudsha@codeaurora.org>
Some buses would like to keep their devices in suspend state during system
resume. For example HSIC controller driver prevent system suspend when
HSIC device is active. If this device is resumed, during system resume
HSIC controller acquire wake lock and prevent the subsequent suspend till
HSIC device is auto suspended.
CRs-Fixed: 403975
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
(cherry picked from commit 6f199aa800253a69e5679d1057823039f1bd65c9)
Change-Id: Ic8ab631ec1f15685cc35823aa7c57d699738d5fc
Signed-off-by: Sudhir Sharma <sudsha@codeaurora.org>
There is a possibility of QH overlay region having reference to a stale
qTD pointer during unlink.
Consider an endpoint having two pending qTD before unlink process begins.
The endpoint's QH queue looks like this.
qTD1 --> qTD2 --> Dummy
To unlink qTD2, QH is removed from asynchronous list and Asynchronous
Advance Doorbell is programmed. The qTD1's next qTD pointer is set to
qTD2'2 next qTD pointer and qTD2 is retired upon controller's doorbell
interrupt. If QH's current qTD pointer points to qTD1, transfer overlay
region still have reference to qTD2. But qtD2 is just unlinked and freed.
This may cause EHCI system error. Fix this by updating qTD next pointer
in QH overlay region with the qTD next pointer of the current qTD.
CRs-Fixed: 386914
Change-Id: Idbc41b93674955325c8da445fcb25d189bddddb2
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
HSIC runtime resume initiated by an interface driver and remote wakeup
gpio interrupt handler can run in parallel. If HSIC runtime resume is
triggered by runtime PM core, pm_runtime_get call will fail in wakeup
interrupt handler. Check the return code and decrement the PM usage
counter.
CRs-Fixed: 403708
Change-Id: I3108c4aed86723a629a98bdbc461679178727fe5
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Interrupt threshold value is the maximum rate at which HSIC
controller will issue interrupts to processor. Increasing
this value results in fewer interrupts which may save power
as processor has to handle fewer interrupts. Side effect of
increasing this value is higher data latency. For fusion3,
set the ITC(interrupt threshold control) to 5 and default
for other targets. Also, allow ehci stack to set ITC value
per controller basis.
CRs-Fixed: 374661
Change-Id: I0e6bc210679ef211c2850ffbe1dfc80da2f65bf0
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
Signed-off-by: Ajay Dudani <adudani@codeaurora.org>
Due to h/w bug in hsic controller, interrupts are disabled during
resume signalling (~20ms), commit: e404049ae, which may result in
below issues
1. Delayed MDP interrupts causing display stutters
2. Since default workqueue disables preemption for 20ms, the kernel
scheduler schedules out the worker thread for long time. It results
in MDM crash due to delayed response
To avoid busy loop, port resume is performed without disabling the
interrupts. Due to this if resume time constraint is not met then
don't start SOF and retry RESUME after some time. This delay (w/o SOF)
lets the device to enter SUSPEND state (after issuing remote wakeup)
and followed by RESUME after sometime. Also, Move the resume code to
hsic controller driver to avoid changes to ehci upstream code.
CRs-Fixed: 383752
Change-Id: Ic4768587bbb9a00d8cf495065ec9e14c46a5c1d4
Signed-off-by: Vamsi Krishna <vskrishn@codeaurora.org>
Signed-off-by: Manu Gautam <mgautam@codeaurora.org>
Signed-off-by: Ajay Dudani <adudani@codeaurora.org>
ulpi_read() relies on jiffies to calculate the timeout
for read operation on phy register. Calling ulpi_read()
with interrupts disabled, freezes jiffies on local processor.
In case of phy lockup this results in infinite loop leading
to watchdog reset. Use loop counter for timeout instead of
jiffies for read operation to avoid watchdog reset.
CRs-Fixed: 388234
Change-Id: I1d46052b087c42b9f422b6f7eb691498fa104718
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
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>
