GPS driver which makes use of PPS timestamp expects time
with respect to boot time. Existing pps_get_ts function
doesn't return time from the boot so replaced this function
with get_monotonic_boottime function which returns elapsed time
from the boot.
Change-Id: I8f656a1c4ef43f6314d4ab295a177125bcc8195e
CRs-Fixed: 1012438
Signed-off-by: Naresh Munagala <nareshm@codeaurora.org>
The binder allocator assumes that the thread that
called binder_open will never die for the lifetime of
that proc. That thread is normally the group_leader,
however it may not be. Use the group_leader instead
of current.
Bug: 35707103
Test: Created test case to open with temporary thread
Change-Id: Id693f74b3591f3524a8c6e9508e70f3e5a80c588
Signed-off-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Martijn Coenen <maco@android.com>
Git-commit: 359795138d
Git-repo: https://android.googlesource.com/kernel/common/
Signed-off-by: Runmin Wang <runminw@codeaurora.org>
Adjust the PLL disable sequence as per the latest HW
programming guidelines to ensure there will not be any
stray clock glitches when PLL is turned OFF abruptly.
Change-Id: I6df35bbe18b0c42b43f38b9dd85c3502b2038928
Signed-off-by: Abhinav Kumar <abhinavk@codeaurora.org>
When the supply to PLL digital domain is turned off,
it can result in certain PLL registers to get corrupted.
Make sure to re-program the PLL registers to the
power-on-reset value before starting to program the PLL again
to ensure that it locks reliably.
Change-Id: I63cac884cf11eae60b187f83654f5922a3342d66
Signed-off-by: Abhinav Kumar <abhinavk@codeaurora.org>
During clock gating (ufshcd_gate_work()), we first put the link hibern8 by
calling ufshcd_uic_hibern8_enter() and if ufshcd_uic_hibern8_enter()
returns success (0) then we gate all the clocks.
Now let’s zoom in to what ufshcd_uic_hibern8_enter() does internally:
It calls __ufshcd_uic_hibern8_enter() which on detecting the LINERESET,
initiates the full recovery and puts the link back to highest HS gear and
returns success (0) to ufshcd_uic_hibern8_enter() which is the issue as
link is still in active state due to recovery!
Now ufshcd_uic_hibern8_enter() returns success to ufshcd_gate_work() and
hence it goes ahead with gating the UFS clock while link is still in active
state hence I believe controller would raise UIC error interrupts. But when
we service the interrupt, clocks might have already been disabled!
This change fixes for this by returning failure from
__ufshcd_uic_hibern8_enter() if recovery succeeds as link is still not in
hibern8, upon receiving the error ufshcd_hibern8_enter() would initiate
retry to put the link state back into hibern8.
Change-Id: Ib550fb791fa4c582b8f2d317a7f5f7594acb0872
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
CPU hotplug operations take place in preemptible context. This leaves
the hotplugging thread at the mercy of overall system load and CPU
availability. If the hotplugging thread does not get an opportunity
to execute after it has already begun a hotplug operation, CPUs can
end up being stuck in a quasi online state. In the worst case a CPU
can be stuck in a state where the migration thread is parked while
another task is executing and changing affinity in a loop. This
combination can result in unbounded execution time for the running
task until the hotplugging thread gets the chance to run to complete
the hotplug operation.
Fix the said problem by ensuring that hotplug can only occur from
threads belonging to the RT sched class. This allows the hotplugging
thread priority on the CPU no matter what the system load or the
number of available CPUs are. If a SCHED_NORMAL task attempts to
hotplug a CPU, we temporarily elevate it's scheduling policy to RT.
Furthermore, we disallow hotplugging operations to begin if the
calling task belongs to the idle and deadline classes or those that
use the SCHED_BATCH policy.
Change-Id: Idbb1384626e6ddff46c0d2ce752eee68396c78af
Signed-off-by: Syed Rameez Mustafa <rameezmustafa@codeaurora.org>
Add support to handle system error and shutdown notification
from MHI host.
CRs-Fixed: 2022936
Change-Id: Id36097dffd7571490d7d53d2e496bfe024702a42
Signed-off-by: Sujeev Dias <sdias@codeaurora.org>
Two notify requests are being queued for one available modem
response. So for the first GET_ENCAPSULATED_RESPONSE we provide
the host with the available response. Now for the next
GET_ENCAPSULATED_COMMAND we notify the host that the response is
available even before the modem is ready with a response because
of the extra notify request queued on the interrupt endpoint.
This causes a STALL for the next GET_ENCAPSULATED_RESPONSE request.
This is caused because we are queueing a notify request from the
completion handler of the interrupt endpoint request when the
response queue is not empty.
Fix this by queuing a notify request when a new response is
available only after the current resposne is send to the Host.
Change-Id: If84bc315f2be910503328cc6b0e21be342c6eb37
Signed-off-by: Sriharsha Allenki <sallenki@codeaurora.org>
Signed-off-by: Mayank Rana <mrana@codeaurora.org>
Add support to handle system error and shutdown
notifications from mhi host.
CRs-Fixed: 1097560
Change-Id: Ied6c907586aa4dc2ed3b1a7c19305877144b3b21
Signed-off-by: Sujeev Dias <sdias@codeaurora.org>
Driver register doesn't have to be synchronous with probe call
back. Keep the driver registered till unregister gets called and
never reset ops during probe failure.
CRs-fixed: 2029329
Change-Id: I61331c7f33b29b0bc4833a8e4c52ee94f17660e7
Signed-off-by: Anurag Chouhan <achouhan@codeaurora.org>
Soundwire control data is NULL if there is no soundwire slave
device enumerated.
Add null check to avoid panic.
Change-Id: Ief60d69c36c2a9831825f38da2c9a3f6dd5f13dc
CRs-Fixed: 2020293
Signed-off-by: Meng Wang <mwang@codeaurora.org>
Check for legacy PM4 commands instead of adreno version to calculate
ringbuffer space for PM4 commands that write to memory.
Change-Id: I5d1d4cfbc70bc73ddee9ee752de24aae154a04dc
Signed-off-by: Lynus Vaz <lvaz@codeaurora.org>
During recovery, there are cases where in WLAN driver running on
APPS can access WLAN copy engine register causing exceptions
because of WLAN hardware in reset state.
Add voltage regulator and clk in icnss device node to vote for WLAN
hardware resources by the icnss platform driver during WLAN recovery.
CRs-Fixed: 2029173
Change-Id: I00bbad40ee152c8dac187ff1f541e34b254589cb
Signed-off-by: Sarada Prasanna Garnayak <sgarna@codeaurora.org>
During recovery, there are cases where in WLAN driver running on
APPS can access WLAN copy engine register causing exceptions
because of WLAN hardware in reset state.
Add voltage regulator and clk in icnss device node to vote for WLAN
hardware resources by the icnss platform driver during WLAN recovery.
CRs-Fixed: 2029102
Change-Id: Iba785acc391fb56ea068199598ddc14d20bb3481
Signed-off-by: Sarada Prasanna Garnayak <sgarna@codeaurora.org>
