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>
This is needed to clear out the internal memories of
GPU while moving from secure to unsecure mode.
Change-Id: I9ef4848212246a2ed45395ef97c7f755784cb635
Signed-off-by: Rajesh Kemisetti <rajeshk@codeaurora.org>
Added changes to update rotator OT settings for
sdm660 based on QOS recommendation
Change-Id: Ia950232269dcfa082666faefbda54217790e15df
Signed-off-by: Raviteja Tamatam <travitej@codeaurora.org>
G-Link SPI transport is used to communicate with external audio codec.
Add G-Link SPI transport device to support that configuration.
CRs-Fixed: 1106989
Change-Id: Id447b5e89e653065df6f368a4e5e59b22e0dc159
Signed-off-by: Dhoat Harpal <hdhoat@codeaurora.org>
G-Link SPI transport is used to communicate with external audio codec.
Add G-Link SPI transport device to support that configuration.
CRs-Fixed: 1106989
Change-Id: Iac48fe87152379244e2c813f767b4e497553b8d1
Signed-off-by: Dhoat Harpal <hdhoat@codeaurora.org>
nt36850 wqhd command panel will be used for sdm660 QRD,
so add a new panel driver for it.
Change-Id: I94a76aa3972978f8fb6ebca96bd452fec827b355
Signed-off-by: Ray Zhang <rayz@codeaurora.org>
Signed-off-by: Yahui Wang <yahuiw@codeaurora.org>
Bus topology is the representation of bus connections in SOC
and is required for the bus driver to serve the bandwidth
requests from clients.
Change-Id: I474f390e86f291e78d6126ed769837b123e2a409
Signed-off-by: Odelu Kukatla <okukatla@codeaurora.org>
DOLBY_DAP config is not used, remove it from sdm660 Kconfig.
CRs-Fixed: 1094763
Change-Id: I3f5c9937cbf9834aeb0f9d0b811c215d0246507f
Signed-off-by: Laxminath Kasam <lkasam@codeaurora.org>
Add LPG and PWM parameters to blink the red LED. This is controlled by
userspace during charging.
Disable the battery-charging LED triggers to avoid conflicting LED control
by userspace and kernel battery-charging events.
CRs-Fixed: 1106738
Change-Id: Ic1c0f7ef7f8144fade05cc06db3cf87bce55c236
Signed-off-by: ansharma <ansharma@codeaurora.org>
sdm660 CPU CPR controllers support full hardware closed-loop CPR
operation also known as CPR hardening. Extend the cprh-kbss-regulator
driver to handle CPU subsystem specific power requirements of
the sdm660 chip.
CRs-Fixed: 1105923
Change-Id: I2e24a061a5ad4ee959dd578da9e811ac7700702c
Signed-off-by: Tirupathi Reddy <tirupath@codeaurora.org>
As per the hardware documentation, add support for configuring
ESR tight and broad filters for normal and low temperature. This
is needed as the low temperature ESR filter coefficients are not
functional in the hardware.
All the filter values (in terms of percentage) can be configured
through the device tree. When the battery temperature goes below
10 C or user configured temperature threshold, ESR filter values
of room temperature will be applied to ESR low temperature
filters. Once the battery temperature goes above 10 C, original
values will be applied back to ESR low temperature filters.
Change-Id: I347f194f96ace3036a3c49efe0306d9f909cef36
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
Battery missing detection interrupt fires prematurely for higher
battery ID values than the desired range. Fix this by disabling
BMD when battery is re-inserted and enable it after obtaining the
battery ID.
While at it, update the battery type shown in particular when a
battery profile is not available.
Change-Id: Ia5458a85289e47bda0a9f4bc59683af695974bc5
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
In certain cases like battery hotswap where a strong charger is
connected and battery is re-inserted, the expectation from the
user is to reload the battery profile. This cannot happen unless
a dVdd reset happens and wipes out FG SRAM. To help with the
aforementioned scenario, clear the profile integrity bit every
time when the battery is re-inserted. This way, FG driver will
reload the profile everytime upon battery insertion.
When the battery is missing, cycle counters cannot be cleared as
the access to FG SRAM might not succeed. Hence remove it from the
battery removal path. It will be cleared anyways when the profile
is loaded after the battery is inserted.
While at it, show the cached value of battery_id instead of
reading it every time from RR_ADC peripheral. When the battery is
re-inserted, battery id is obtained from RR_ADC driver anyways
which is sufficient.
Change-Id: I0b9566f7a9fcc81e26e68280382e2d960c49eeb5
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
Add support to dump FG SRAM periodically based on the module
parameters. This will be useful for debugging purpose.
To enable FG SRAM dump,
echo 1 > /sys/module/qpnp_fg_gen3/parameters/sram_dump_en
To disable FG SRAM dump,
echo 0 > /sys/module/qpnp_fg_gen3/parameters/sram_dump_en
To set FG SRAM dump period,
echo 15000 > /sys/module/qpnp_fg_gen3/parameters/sram_dump_period_ms
Change-Id: Ib4bae7f67100a4bda1e4b996f2fbaeb86da979d2
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
In transfer_busy_time(), the new_task flag is set based on the active
window count prior to the call to update_task_ravg(). update_task_ravg()
however, can then increment the active window count and consequently
the new_task flag above becomes stale. This is turn leads to inaccurate
accounting whereby update_task_ravg() does accounting based on the fact
that the task is not new whereas transfer_busy_time() then continues to
do further accounting assuming that the task is new. The accounting
discrepancies are sometimes caught by some of the scheduler BUGs.
Fix the described problem by moving the check is_new_task() after the
call to update_task_ravg(). Also add two missing BUGs that would catch
the problem sooner rather than later.
Change-Id: I8dc4822e97cc03ebf2ca1ee2de95eb4e5851f459
Signed-off-by: Syed Rameez Mustafa <rameezmustafa@codeaurora.org>