sync: signal pt before sync_timeline object gets destroyed

There is a race condition

Assume we have *one* sync_fence object, with *one* sync_pt
which belongs to *one* sync_timeline, given this condition,
sync_timeline->kref will have two counts, one for sync_timeline
(implicit) and another for sync_pt.

Assume following is the situation on CPU

Theead-1 : (Thread which calls sync_timeline_destroy())
  -> (some function calls)
   -> sync_timeline_destory()
    -> sync_timeline_signal() (CPU is inside this
function after putting reference to sync_timeline)

At this time Thread-2 comes and does following

Thread-2 : (fclose on fence fd)
> sync_fence_release() -> because of fclose() on fence object
 -> sync_fence_free()
  -> sync_pt_free()
   -> kref_put(&pt->parent->kref, sync_timeline_free);
    -> sync_timeline_free() (CPU is inside this because
this time kref will be zero after _put)

Thread-2 will free sync_timeline object before Thread-1
has finished its work inside sync_timeline_signal.

With this change we signals all sync_pt before putting
reference to sync_timeline object.

Change-Id: Ic680e4d0bbef1c46bcb7cfba693395645241d203
Signed-off-by: Prakash Kamliya <pkamliya@codeaurora.org>
Signed-off-by: Rom Lemarchand <romlem@google.com>
msm: kgsl: Use a read/lock for the context idr

Everybody loves a rcu but in this case we are dangerously mixing rcu's
and atomic operations. Add a read/write lock to explicitly protect the
idr. Also fix a few spots where the idr was used without protection.

Change-Id: Ic2f1e5c45692683b52a9f662ccdd2fb59bc7ae0e
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Harsh Vardhan Dwivedi <hdwivedi@codeaurora.org>
msm: kgsl: Add a missing refcount put for kgsl_context

Fix a potential memory leak by putting in the missing kgsl_context_put()
in fault trace detect.

Change-Id: Ic0b43c831a88ac3e45bbe484bde843b46b6f09f6
Signed-off-by: Harsh Vardhan Dwivedi <hdwivedi@codeaurora.org>
msm: kgsl: Try fault tolerance even if there is no active context

No active context means that GPU could have failed when executing
commands that set an active context. In this case there are no bad
commands. This sort of hang can mostly be attributed to power
fluctuations or memory barriers which in all likelyhood can pass
after a reset. So treat no active context as a recoverable hang
scenario as well.

Change-Id: I0481a480bdb895f67daa2ed32df49eb1afe29029
Signed-off-by: Shubhraprakash Das <sadas@codeaurora.org>
Signed-off-by: Lynus Vaz <lvaz@codeaurora.org>
Signed-off-by: Ananta Kishore K <akollipa@codeaurora.org>
msm: kgsl: Fix the KGSL driver to compile when CONFIG_DEBUG_FS=n

Fix a compilation error when CONFIG_DEBUG_FS is disabled. Add an
initialization flag to the process struct rather than rely on a
pointer to the debugfs node which will always be NULL if debugfs
is not available.

CRs-fixed: 542231
Change-Id: Ic0dedbadf0241fd476e56d6e116a811697b38190
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
msm: vidc: free the recon buffers in cleanup function

- The recon buffers were not released when video recording
  was killed abruptly leading to memory leak.

- Fix provided to release the recon buffers when media
  server killed abruptly.

Change-Id: I48ac1a592719446b7e4bf87bbd707d09351d1e61
Signed-off-by: srikarri <sridur@codeaurora.org>
Revert bcmdhd driver to sane state

 * Firmware is not compatible with these changes!

Revert "net: wireless: bcmdhd: Fix of Wireless Location Service"

This reverts commit b9a1b93d685e89954c06f637ab9c64ef189be0f9.

Revert "net: wireless: bcmdhd: Fix of Wireless Location Service"

This reverts commit b7adad29fb903bffe6e1db5129ad411827df4352.

Revert "net: wireless: bcmdhd: Update Location Service code"

This reverts commit 79095cb79b45b3957240f6dbbee6eab2334956b9.

Revert "net: wireless: bcmdhd: enable WL_IFACE_COMB_NUM_CHANNELS"

This reverts commit 4589ecdfdc732a54574c01f8e1a8d83e9a10a8d2.

Revert "net: wireless: bcmdhd: Update to version 1.88.45"

This reverts commit 17cb1b5c878f86a1d830a616b98805b2434073a8.

Revert "net: wireless: bcmdhd: Update to version 1.88.42"

This reverts commit d6f5b4fe9cca76c3e4f2427170fcdccfe44fb1fb.

Revert "net: wireless: bcmdhd: Update to version 1.88.41"

This reverts commit 5562cf9003a1884f397e452681521febfee1c6a3.

Change-Id: Iac7e0f89833668068dcc1c67278f0768130d2076
usb: Remove CONFIG_USB_OTG_HOST

 * Set the correct behavior for HTC's driver, and turn these options off
   for M7. They cause some nasty side effects on many XHCI systems.

Change-Id: Ibe4685b7f1e130e7a5ffa38bf04b6fef01a3b402
m7: Update board and defconfig for USB changes

Change-Id: I7f27103f259b94de0da55b5712825f708081e3a7
usbaudio: Merge with upstream

Change-Id: I4c06b1ea790bf2a632974c3f2f84a20aa08159f7
msm: usbaudio: Fix memory allocation for USB audio module init

Fix memory allocation issue in snd_usb_audio_init()
use sizeof(struct) insead of sizeof(pointer)

Change-Id: I270bbd7111e97dd4e0e92378f61d5025e16f5fca
Signed-off-by: Alex Fradkin <afradkin@codeaurora.org>
PM: Prevent runtime suspend during system resume

This patch (as1591) moves the pm_runtime_get_noresume() and
pm_runtime_put_sync() calls from __device_suspend() and
device_resume() to device_prepare() and device_complete() in the PM
core.

The reason for doing this is to make sure that parent devices remain
at full power (i.e., don't go into runtime suspend) while their
children are being resumed from a system sleep.

The PCI core already contained equivalent code to serve the same
purpose.  The patch removes the duplicated code, since it is no longer
needed.  One of the comments from the PCI core gets moved into the PM
core, and a second comment is added to explain whe the _get_noresume
and _put_sync calls are present.

Change-Id: I31d311cd9d82ad53eca57d5825ae4d81c32e92b5
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Revert "USB: ensure parent device is resumed for child's system-resume"

This reverts commit de86e6482897db0006151ae9154f181e75f5ab2c.

Commit 7c8527ce ("PM: Prevent runtime suspend during system resume")
fixes the general issue of a parent device being prematurely
runtime suspended before a child device is resumed. It does so
by moving the pm_runtime_put_sync() call from the device_resume()
stage to device_complete(), which happens to act on the devices
in reverse (children before parent) order.

Thus when usb_resume() is called by device_resume(), we know its
parent will be runtime PM enabled and its usage counter is still
non-zero. This obviates the need to do an additional
pm_runtime_get_sync() before calling usb_resume_both() as the
device and its interfaces now have the opportunity to increment
the parent's power.child_count if necessary without fear of
having a runtime suspended parent.

(cherry picked from commit d48e904824ec38f9db01fcaccb527063b4c5d894)

Change-Id: I6d092c649889daf9483ed27aebe67df50d38ae91
CRs-fixed: 396041
Signed-off-by: Jack Pham <jackp@codeaurora.org>
usb: Squashed commit of upstream USB fixes

 * Corrects power management and latency/jitter issues.

EHCI: HSIC: Increase IAA watchdog timeout to 100ms

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>

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>

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>

Revert "usb: ehci-msm-hsic: replace wakelock with wakeup source"

This reverts commit dd5ad79f501c462fbee8e36c57747883d2317d29.

Signed-off-by: Iliyan Malchev <malchev@google.com>

Change-Id: Ie9aeff9fe6e1ab1cf3797dc7d7499ee9ab8a6654
Signed-off-by: Ajay Dudani <adudani@codeaurora.org>
Signed-off-by: Iliyan Malchev <malchev@google.com>

usb: ehci-msm-hsic: abort suspend when interrupts are pending

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>

msm: hsic: Retry port RESUME if unable to send SOFs within 3ms

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>

EHCI: Update qTD next pointer in QH overlay region during unlink

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>

EHCI: HSIC: Prevent disabling wakeup irq twice

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>

EHCI: HSIC: Handle wakeup interrupt properly during probe

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)

Change-Id: I9b20d54d919333d11201d30513b4111f3fb31df3
Signed-off-by: Sudhir Sharma <sudsha@codeaurora.org>

EHCI: HSIC: Fail root hub bus suspend when port is not enabled

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>

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)

EHCI: HSIC: Fix GPT timer count values used for resume sequence

The counter value to be loaded into GPT timer represents the time
in micro seconds minus 1 for the timer duration.  The current code
incorrectly programs the timer.  Fix it.

CRs-Fixed: 449090
Change-Id: I53eddb6b4323bbfaf0e3a1d3aaa0fb9120c70647
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
m7: Disable USB debug logging

Change-Id: I8a60610575af0e254c1ea16c95f7af5d9567d58e
usb: msm: Import HTC changes for OTG

 * Support for host notify and charger notify

Change-Id: Ia9a27988e6bcda7b2b300b34b09988737dbeba9a
Restrict slave mountspace so Dalvik apps can mount system-wide volumes
gpu:rework gpu freqs, add two more  steps (450, 400), thanks @tbalden
LOAD_FREQ (4*HZ+61) avoids loadavg Moire

I suggest (4*HZ+61) for a better distribution.

With some seconds based load (like SSL heartbeats)
and LOAD_FREQ at (5*HZ+1) I see Moire patterns like inverse sawtooth,
since 2 or 3 probes hit the jobs (load increases quickly),
followed by several probes missing it.

A 4.61 sec interval gives optimal distribution over when within a
second a probe is taken, as .61 is close to golden ratio phi 1.618...
(test in http://ripke.com/goldenratio.c).

12*4.61 = 55.32 secs is still close to a minute,
and 13*4.61=59.93 is even closer than the current 12*5.01=60.12
(with exponents EXP_x adjusted to a ratio of 13 instead of 12).

best
Klaus

Change-Id: I28d79b5ffd0fd166760f76e4d04f80efed5b5702
Add dancedance governor

By @Snuzzo

Change-Id: I8bd4f56dfd0bc37f95d2e66035e69162c3b83dd3