msm: cpufreq: Always update frequency limits when core is online

Remove condition in msm_cpufreq_init() so that when cpu is set to
online, it will call set_cpu_freq() and update the frequency limits.

CRs-Fixed: 462816
Change-Id: I40ac33c9cb4b42590a83f9d61b74f23379f5642e
Signed-off-by: Jennifer Liu <chihning@codeaurora.org>
msm: cpufreq: Configure WQ for higer priority

When the workqueue runs at a lower priority, it gets starved by higher
priority threads. Bump the WQ priority to high to ensure cpufreq work
queue gets a fair scheduling chance

Change-Id: I9e994da94a347dceb884e72ec3dd3da468a4471d
Signed-off-by: Mahesh Sivasubramanian <msivasub@codeaurora.org>

Let's try this again.

Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
msm: cpufreq: Break out early if target frequency is the same as the current

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
msm_rq_stats: squash commit to latest version
cpuidle: remove unused variable dead_state
msm: we dont need this
Revert "usb: mdm_bridge: Free driver data structure memory in correct order"

This reverts commit 6fe9a98b6f908aec02370f9415a5470b81c55530.
USB: Allow skipping device resume during system resume.

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>
USB: Prevent system suspend when HSIC device is active

Some buses like HSIC would like to keep device in suspend state
after system resume.  The remote wakeup or interface activity
later will auto resume the device.  This will work only if the
device is auto suspended before system suspend.  If the device
runtime state had been active during system suspend and system
suspend routine put the device in suspend, it will not be resumed
during system resume.  When remote wakeup happen for this device,
the runtime resume will not bring the device to active as runtime
core think it is already active.

The HSIC bus ensure that device is auto suspended prior to system
suspend by holding a wakelock till the bus is suspended.  HSIC bus
is not handling the case where device is auto resumed immediately
after system suspend begins.  HSIC bus simply put the device into
suspend in system suspend routine.

This patch fixes above issue by returning an error code if the device
is not auto suspended during system suspend.  Also add a safe guard
check in HSIC system resume routine to skip device resume only if it
is auto suspended prior to system suspend.

(cherry picked from commit 41d004c4eaa5565cb8d9113862c3cef1e51be648)
CRs-Fixed: 422876

Change-Id: I07063d1fe2ef054adc5c593691d417272e66221e
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Signed-off-by: Neha Pandey <nehap@codeaurora.org>
usb: ehci_msm2: Resume root hub on receiving ASYNC interrupt

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>
USB: EHCI: Add remote wakeup support for HSUSB 3rd instance

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>
ehci_msm2: Fix enumeration during PHY suspend failure

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)
usb: ehci-msm2: Fix controller autosuspend

When the EHCI controller is removed using platform_device_del(),
the PM disable_depth counter is decremented once by the driver
core. Thus the driver's remove callback additionally calling
pm_runtime_disable() is leading to an unbalanced counter since
pm_runtime_enable() call happens only once when platform_device_add()
calls the probe callback. Fix this by removing the extraneous
pm_runtime_disable().

Change-Id: Ie76256ac50ba65022814285bf57feca109f79d6b
Signed-off-by: Jack Pham <jackp@codeaurora.org>
usb: ehci-msm2: Fix unbalanced clock warning

The EHCI controller may be in suspend state in which its clocks
are already disabled. Fix warning given by clock subsystem when
disabling the clocks a second time when the controller's platform
device is removed by first checking if the device is suspended.

Change-Id: I3c491d0db11cc172d0e6779042c04fc726936b36
Signed-off-by: Jack Pham <jackp@codeaurora.org>
EHCI: HSIC: Add support to vote for SVS digital voltage

HSIC HW can operate at SVS digital voltage when it is active.
Currently HSIC is voting for 120Mhz SFAB and 64Mhz DFAB clock
frequencies. Clock frequencies are directly proportional to SVS
voltage. If DFAB is running at 64Mhz or SFAB is running at 120Mhz
or higher SVS is not possible even though HSIC votes for it. Hence
do not vote for SFAB clock frequency and only vote for 32Mhz for
DFAB in order to allow SVS to happen. Voting for SVS voltage reduces
current consumption by 3mA in HSDPA network.

Change-Id: I8a6844efbbe90a8ea118be8450f8210717c2641b
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
(cherry picked from commit cdf7fd212e2761525c07b842eb630677777cb3e5)
(cherry picked from commit f7f368826935049e7ffdb482865c47a3badcd147)
usb: mdm_bridge: Increase the number of rx urbs

Due to higher HSIC interrupt threshold value, sometimes
driver is running short of enough rx urbs queued to HSIC
HW to receive IP packets from mdm device. In this case
driver is busy processing large number of completed rx
urbs and left with fewer pending urbs with HW. This causes
occasional throughput drops on rx data path. Hence increase
number of rx urb from 50 to 100, to keep HSIC HW busy in
pulling data from mdm device while completed urbs are getting
processed.

(cherry picked from commit e8f691f60db39b50951148c3e68ae35c89cdd397)
CRs-Fixed: 397809
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>

Change-Id: I590c203551c5ac83a71b8628d195f2a15840edf1
Signed-off-by: Neha Pandey <nehap@codeaurora.org>
USB: mdm_bridge: Fix a possible freed memory access

When tethered rmnet/dun interface probe is failed, the bridge channel
platform device is removed in error path.  The gadget driver schedule
a work to open the bridge channel in probe.  Cancel this work in remove
before closing the channel.

Cancel any pending work while closing the bridge.  Otherwise there is
a possibility of rx work running in parallel with probe error path.  If
this happens, rx work access already freed memory.

CRs-Fixed: 442119
(cherry picked from commit 50f3815166483c654ebb325c49e50af4e31547da)

Change-Id: I78c2ee04cfd083248127cfd6b9f07994087729ca
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
usb: mdm_ctrl_bridge: Do not unlink URB upon cable disconnect

MDM control bridge driver unlinks the pending URBs when control
bridge gets closed as a result of usb cable disconnect. Driver
sends set_control_line_state request to MDM upon bridge close.
Right after sending the setup request driver unlinks the pending
URBs. In case if the URB is unlinked after setup stage is completed,
status stage remains pending. This results in a control transfer
stall. Similarly, when the bridge is reopened as a result of USB
cable plug-in, the interrupt URB is not resubmitted, which can also
lead to a QMI stall since the MDM is waiting indefinitely to send
its response available notification. Fix these two potential stall
conditions by not unlinking URBs upon cable disconnect; this will
allow in-progress control transfers to finish gracefully and will
also allow notification interrupts to always be handled. Unlinking
of the URBs will happen during MDM device disconnect, instead of
upon bridge close.

(cherry picked from commit 77f79575ebe35f2ec329827290e7a67fb0e75286)
CRs-Fixed: 419128,418478

Change-Id: I5474372d832de2fd49f17faf77e7e549e80566ad
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
Signed-off-by: Neha Pandey <nehap@codeaurora.org>
msm: usb: fix mdm bridge channel mismatch when disconnecting

The bridge_disconnect assumed the internal channel id in pre-defined order,
which was not matched with the actual usb_interface to be disconnected.
Due to this, other internal resources were freed unexpectedly and caused
occasional crash during reset and power off.

Implemented new routines for matching usb_interface and internal channel id
to free proper resources when bridge_disconnect is called.

Change-Id: I0ca604423dd36928f99fad3e21a24ed4699f96c3
usb: mdm_bridge: Fix race between disconnect and I/O completion handler

There is a possibility of race between device disconnect and I/O
completion handler. In this case disconnect frees bridge device
memory in thread context and I/O completion handler uses already
freed bridge device memory in interrupt context. Hence allocate
bridge device memory at the time of driver load and free it
during unload. Also, do not anchor interrupt and read urb and
unlink them synchronously to avoid accessing transfer buffers
associated to these urbs when driver disconnect frees them.

Guard the race condition by:-
1) Adding check for usb device disconnect state in the I/O
completion handler to avoid further processing I/O completion.

2) Unlinking tx urbs synchronously since asynchronous unlinking
results in the same race condition.

CRs-Fixed: 447591
Change-Id: Iae4c2a1920c16fcf3e1728144a7cfe6ca66c7705
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>