Add battery profile for qrd sdm660 to make sure FG could load it
and work as expected.
Disable soft hot jeita threshold according to the battery vendor's and
hardware team's suggestion to make sure the battery could sustain at 1C
charging current longer.
CRs-Fixed: 1108198
Change-Id: Ifebeadae1590813ad785d25a399011efb447746d
Signed-off-by: cyizhao <cyizhao@codeaurora.org>
Users of usleep_range() expect that it will _never_ return in less time
than the minimum passed parameter. However, nothing in the code ensures
this, when the sleeping task is woken by wake_up_process() or any other
mechanism which can wake a task from uninterruptible state.
Neither usleep_range() nor schedule_hrtimeout_range*() have any protection
against wakeups. schedule_hrtimeout_range*() is designed this way despite
the fact that the API documentation does not mention it.
msleep() already has code to handle this case since it will loop as long
as there was still time left. usleep_range() has no such loop, add it.
Presumably this problem was not detected before because usleep_range() is
only used in a few places and the function is mostly used in contexts which
are not exposed to wakeups of any form.
An effort was made to look for users relying on the old behavior by
looking for usleep_range() in the same file as wake_up_process().
No problems were found by this search, though it is conceivable that
someone could have put the sleep and wakeup in two different files.
An effort was made to ask several upstream maintainers if they were aware
of people relying on wake_up_process() to wake up usleep_range(). No
maintainers were aware of that but they were aware of many people relying
on usleep_range() never returning before the minimum.
Change-Id: Ia403f0dc9cac711c8a4b6fcc4cf0094ad1358ed7
Reported-by: Tao Huang <huangtao@rock-chips.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Cc: heiko@sntech.de
Cc: broonie@kernel.org
Cc: briannorris@chromium.org
Cc: Andreas Mohr <andi@lisas.de>
Cc: linux-rockchip@lists.infradead.org
Cc: tony.xie@rock-chips.com
Cc: John Stultz <john.stultz@linaro.org>
Cc: djkurtz@chromium.org
Cc: linux@roeck-us.net
Cc: tskd08@gmail.com
Link: http://lkml.kernel.org/r/1477065531-30342-1-git-send-email-dianders@chromium.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Git-commit: 6c5e9059692567740a4ee51530dffe51a4b9584d
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Runmin Wang <runminw@codeaurora.org>
Linus noticed that lock_timer_base() lacks a READ_ONCE() for accessing the
timer flags. As a consequence the compiler is allowed to reload the flags
between the initial check for TIMER_MIGRATION and the following timer base
computation and the spin lock of the base.
While this has not been observed (yet), we need to make sure that it never
happens.
Change-Id: I577327e02ab77b6de951ac2aa936cb5d5a4f477a
Fixes: 0eeda71bc3 ("timer: Replace timer base by a cpu index")
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1610241711220.4983@nanos
Cc: stable@vger.kernel.org
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Git-commit: b831275a3553c32091222ac619cfddd73a5553fb
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
[runminw@codeaurora.org: resolve trivial merge conflicts]
Signed-off-by: Runmin Wang <runminw@codeaurora.org>
Keep gcc_bimc_gfx_clk always on to prevent a stall during BIMC
redirection handshake that occurs as part of a transition between
different CCI power modes. The stall causes momentary bandwidth drops
for the display ports and creates display buffer underflows.
Change-Id: Ie7de487fbe16c7e6b1234a96c1208d54daa5a9bb
Signed-off-by: David Dai <daidavid1@codeaurora.org>
Add a level at the lower end of the memlat table for the Silver
cluster so that the memlat driver votes for at least 200MHz
when the CPU's effective frequency is at most 300MHz for latency
bound workloads.
Change-Id: I2695d2d115d925ac8b274d93e59b2be6578f3001
Signed-off-by: Rohit Gupta <rohgup@codeaurora.org>
Free all the SKP ION buffers that were locked for SPSS app swapping,
when remote subsystem reset.
Change-Id: I5230152cc7c3e721b1ebb01b663b9fd14bd2d6c9
Signed-off-by: Amir Samuelov <amirs@codeaurora.org>
This patch enables allocation of 5MB for new diag client
of memshare.
CRs-Fixed: 1107794
Change-Id: Ibfbd9c2fc13860b647c1411e6c60f4a543683993
Signed-off-by: Manoj Prabhu B <bmanoj@codeaurora.org>
The UB size has been updated to 64KB for
SDM660.
Change-Id: I6493574b17f7ad458476f6e25a8aef19c0befdae
Signed-off-by: Meera Gande <mgande@codeaurora.org>
Rename clock handles as per de-initialization sequence,
which is required to avoid the dangling pointers.
Change-Id: I9e0715e2a47f318acc414605ce8e624c432d6665
Signed-off-by: AnilKumar Chimata <anilc@codeaurora.org>
If cluster deepest low power mode is disabled in idle path, the
residencies are recalculated and the max_residency for the shallower
mode becomes ~0 even if deepest mode is not disabled in suspend path.
Because of this while the cluster mode is selected during suspend,
it selects shallower mode instead of deepest mode available.
During suspend ignore the residency to select the cluster level
low power mode.
Change-Id: I812e33ad45e563b88c478d5d70296d5bd488438f
Signed-off-by: Srinivas Rao L <lsrao@codeaurora.org>
pl psy access is guarded by pl_disable_votable, disabled in PMI
probe. Accessing parallel psy before it is available will cause
crash.
Fix this by allowing access to parallel psy only after all the
initial votes have been cast on pl_disable_votable in probe.
CRs-Fixed: 1101600
Change-Id: Idd289229f45c31cf8fd234339b6738bd241283bd
Signed-off-by: Harry Yang <harryy@codeaurora.org>
While switching to HS mode, high speed mode timing should be selected
in the device before changing the clock frequency in the host.
But present driver first updates the frequency in host and then selects
HS mode in device while selecting HS400 mode. This is a spec violation.
Updated the sequence to comply with spec.
Change-Id: I5b2c1f724d820daf9c0bca8651cf85bd0ff67655
Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
Currently the legacy cable bit is always asserted during off mode
PON via USBIN. This causes PD to be disallowed even when a
non-legacy cable is attached in off mode.
Fix this by always allowing PD upon USBIN attach PON, but keep the
normal legacy detection flow for all subsequent insertions.
CRs-Fixed: 1107607
Change-Id: I20acd75643955b6d2144389159a0dad41f01a532
Signed-off-by: Harry Yang <harryy@codeaurora.org>
Calling ioremap() in clk_osm_panic_callback() can result in
BUG() when the kernel is panic-ing. It is not safe to use
ioremap() in atomic context. Map the debug registers at probe
time instead.
Change-Id: I4009ea6e10df2dc8649cf0b0c1a5b6398d3c689e
Signed-off-by: Taniya Das <tdas@codeaurora.org>
Calling ioremap() in clk_osm_panic_callback() can result in
BUG() when the kernel is panic-ing. It is not safe to use
ioremap() in atomic context. Map the debug registers at probe
time instead.
CRs-Fixed: 1086427
Change-Id: Ie14be6ee9ffbcb09009d5d05235e20f6ac215fa0
Signed-off-by: Osvaldo Banuelos <osvaldob@codeaurora.org>
Forcing a certain value on the result of the votable is a very
desireable feature to speed up debugging.
For this create a debugfs dir per votable and implement following debugfs
files
- status : This is the same as the earlier one which dumps clients and
their values and results.
- force_val : The value of the vote to force. This will be an integer
value for min/max votables and should be a boolean value
for set_any votables.
- force_active: This flag activates or deactives the force mode.
Note that writing to the force active flags always invokes the callback
when present even if the same value is being set. When activated the
callback is called with the result set to force_val and the client set to
"DEBUG_FORCE_CLIENT".
While activated, other clients are allowed to vote, their votes are
noted and the effective values tracked internally are updated. Only the
callback is skipped. This internal tracking of the effective values help
in switching back quickly to the voted results once the force mode is
deactivated IOW When deactivated the callback is called with the result
and client set to the effective ones which could have been the same as
the ones prior to force activation or could have been updated by
the calls to vote() while force was activte.
Also, note that while force is activated, the calls to
get_effective_result and get_effective_client return the force_val
and "FORCE_DEBUG_CLIENT" instead of the internal effective values. This
provides consistency with callback values.
Change-Id: Id9eb5b27675e3ed53176175c13e0d654783bcf08
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Interrupts are not specified correctly for haptics device on
pm660. Fix it.
Change-Id: I4a34c82c67b32276d64b74a9dd49bf5568c800dd
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
Interrupts are not specified correctly for haptics device on
pmi8998. Fix it.
Change-Id: I9c98c7adacba359e35dec291a034c54bccf3cfbd
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
Due to integer overflow ,the bound check in config frame function
may pass and this may allow user to access invalid buffer. This
fix takes care of proper bound and don't allow integer overflow.
CRs-Fxied: 1097709
Change-Id: I504ad591633afaba82268b5ee27a321691d75c80
Signed-off-by: Kumar Behera <mohanb@codeaurora.org>
Heavy task prediction code needs further tuning to avoid any
negative power impact. Delete the code for now instead of adding
tunables to avoid inefficiencies in the scheduler path.
Change-Id: I71e3b37a5c99e24bc5be93cc825d7e171e8ff7ce
Signed-off-by: Rohit Gupta <rohgup@codeaurora.org>
hispeed_freq can still be useful with some versions of predictive
load based scaling. So, allow that.
Change-Id: I84ce1e2b6e7e839bd278aa3deaac21f4cd8503a8
Signed-off-by: Rohit Gupta <rohgup@codeaurora.org>
