usb: gadget: Fix response available notify count usage

The outstanding responses are purged and notify count is reset
during bus suspend. But the notify interrupt endpoint is not flushed.
If a request is pending with the controller, It gets finished during
resume and the notify count is decremented in the completion handler.
As the notify count is reset during the suspend its become negative now.
As the counter is not zero, interrupt notifications are queued even
though there are no responses. This is leading to watchdog bark due to
an error print messages.

Flush the notify endpoint before resetting the notify counter during
suspend. As we are modifying notify counter under spin lock, atomic
variable is not required. Ensure that notify counter never
becomes negative.

CRs-Fixed: 607029
Change-Id: I78cb7a585c1c2b527ca6b46bc99e7db8067ee21a
Signed-off-by: ChandanaKishori Chiluveru <cchilu@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
USB: Set power supply online status to false after cable disconnect

During bootup, power supply online status is set to true in
qpnp_charger_probe() as soon as usb cable insert is detected by
PMIC without waiting for notification from USB driver.
Later when usb cable is disconnected before charger detection
mechanism starts, online status is not set to false by USB.
As part of cable disconnect, USB checks in msm_otg_notify_charger()
whether the cur_power is same as requested mA, if both are same
then USB does not call power_supply_set_online() to set it to false.

Fix the issue by setting power supply online status to false for
the scenario when usb cable is disconected during bootup before
charger detection mechanism is completed.

CRs-fixed: 634183
Change-Id: Ibd57a40c7364e13bb10870e9e6343224e01171d7
Signed-off-by: Saket Saurabh <ssaurabh@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
tcp: network speed tweak

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
msm: kgsl: Allow GPU start to run in a high priority queue

The GPU start sequence needs to run with low latency when coming
out of slumber for the first draw command. For those cases allow the
start function to be queued into a high priority workqueue to reduce
the chance of it getting scheduled out.

Change-Id: Ic0dedbada7ef4d63b54e826862fbefdfb71a092a
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: flar2 <asegaert@gmail.com>
msm: kgsl: Add an input handler to power up the GPU on a touch event

On a device where the primary input is a touchscreen nobody is
surprised that touch events are often the catalyst for drawing
frames. If the GPU is in slumber we can get a jump on the action
by watching for touch events and turning the GPU on in anticipation
of a draw call. Register for events from all input drivers
returning EV_ABS events and queue a work task to power up the GPU
if it is currently in slumber.

Change-Id: Ic0dedbadbdc96ef9ddd78252ea65f8e1cdd00110
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: flar2 <asegaert@gmail.com>
msm: kgsl: Fix nice level for higher priority GPU start thread

Before, we were actually setting the lowest possible priority.

Change-Id: I3a52de949eee0faea8061dd91ed303fa8231f0d4

Signed-off-by: flar2 <asegaert@gmail.com>
msm: kgsl: Schedule adreno_start in a high priority workqueue

Better safe than sorry. Also, return early if we didn't set a _wake_timeout.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>