We see huge jumps in Unusable Charge (UUC) as temperature, average
load or state of charge (SOC) changes, which results in huge jumps
in the reported capacity.
Increase/Decrease UUC slowly (limit 1%) each time SOC is requested.
This results in linearity improvements.
Change-Id: I82022aa499a53c5ea42e7079e96d3c94dfc0be01
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
The "adjust_soc" algorithm where we change the open circuit voltage
(ocv) in steps so that the state of charge (soc) starts approaching
the estimated soc, causes nonlinearity in the soc curves if an incorrect
resistance value is fed to the algorithm.
As battery ages and temperature changes, it is hard to estimate the
exact battery resistance.
So to fix the nonlinearity, limit the amount by which the ocv is
changed. Make it proportional to the current, i.e. change ocv by
small amounts in light load and let it change by proportionally
large amounts in heavy load situations.
Also, make the point where the soc is adjusted configurable via platform
data instead of forcing it to 25%.
Change-Id: Idc141e6bf3172dab278afe1900f5a1f9cdd624dd
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
When a phone shuts down because of 0% State of charge (soc) while it is
under heavy load, the unusable charge value is very high. The unusable
charge value is based on load.
When the device restarts, that load has significantly decreased
causing uuc value to reduce. This in turn increases the soc. In certain
cases the increase is so large that it falls beyond the shutdown soc
limit checks and a higher soc value is reported. That is unacceptable.
This problem can be addressed if we can remember the load used to
calculate uuc between restarts. Use the lower nibble of register 0x105
to store the average current. Since we want finer resolution towards higher
current let the first step be 500mA and then each increment be 50mA steps.
Also since we are saving the range of load between restarts fill up all
the load samples in uuc calculation with this value. This emulates a
low pass filter on current changes and increases/decreases uuc
gradually.
Change-Id: I4f2ab27865756243d023f48798cc002ff12a9d31
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
The wall time does keep track of time when the device
is suspended. This causes the average current values to be high.
Use rtc clock instead of the monotonic clock api. Since the rtc
clock has only one second resolution the driver rejects calculating
average current if it is invoked in less than 15 seconds. In such
cases it uses the previously calculated average current.
Change-Id: Ie0a8dc51273606cc3deac69600f22fe05139a4b5
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
The bms ccadc counters are incremented/decremented every 56 ticks of the
sleep clock not 55. Correct the tick count.
Also sleep clock is derived by dividing the 19.2Mhz clock by 586. Hence
the HZ count of the sleep clock should be 32764 instead of 32768. Fix
this too.
CRs-Fixed: 381923
Change-Id: I213b3618d33a60533580f4dd2d6644e18a97fcf9
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Few platforms do not want to use the shutdown soc. Provide a option to
selectively disable it.
Change-Id: Ie57d474f4e81e4ce2e7e7a4a92cda20d4c8dd184
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
When a phone boots up with a weak battery the ocv (open circuit voltage)
is so low that we end up in a -ve soc.
If a charger is plugged in, it takes a while for that -ve soc to reach
0. Until then the reported soc is returned 0. (note the driver
never reports a -ve soc). This creates an impression that it takes very
long to go from 0% to 1%.
Change this by bumping up the pon ocv a bit such that soc is reported
exact 0.
Change-Id: I3244723845920c9538dff7e72dab253fd4aa7e2b
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Seek up/down in some band is tuning to a station
which is out of band becuase band limits passed from upper
layer are not used
Change-Id: Ic7d11cb33e7964d385be04b0d2e007889ccc1429
CRs-Fixed: 384287
Signed-off-by: Ayaz Ahmad <aahmad@codeaurora.org>
Commit cf579dfb82 (PM / Sleep: Introduce
"late suspend" and "early resume" of devices) introduced a bug where
suspend_late handlers would be called, but if dpm_suspend_noirq returned
an error the early_resume handlers would never be called. All devices
would end up on the dpm_late_early_list, and would never be resumed
again.
Fix it by calling dpm_resume_early when dpm_suspend_noirq returns
an error.
Signed-off-by: Colin Cross <ccross@android.com>
Cc: stable@vger.kernel.org
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Change-Id: I6fe42f02efdc0b5fb0949b7d5c1c8eb8da96825d
Signed-off-by: Joel King <joelking@codeaurora.org>
The token field is for identification to determine response packet's
source. Fill this field correctly to address afe_loopback timeout.
Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
During chip level restart due to SSR; the crash shutdown routine of
individual subsystem are called. These routines only set
APPS_SMSM_RESET bit; and it doesn't wait for the subsystem to finish
it's error fatal routine and acknowledge it. So the Apps may reset
the msm before the subsystem finishes it's error fatal routines.
So add a 3 second delay in WCNSS crash shutdown routine; which is more
than double the time required for WCNSS to finish the error fatal
routines.
Change-Id: I1268679019b3478bb397f9104d6a2b8dac1a7fd6
Signed-off-by: Sameer Thalappil <sameert@codeaurora.org>
Fix the address range checked with no MMU by always
returning true for no MMU as there is no particular
address range when MMU is not used
Change-Id: I522681d13b2281d482bad91dd00d34ec0f440a1f
Signed-off-by: Shubhraprakash Das <sadas@codeaurora.org>
Signed-off-by: Alex Wong <waiw@codeaurora.org>
The documentation incorrectly specifies 'select' instead of
'src-select'. Update this to be consistent with the driver.
Change-Id: I90bffc26affdefa42192c7f10d4af80ad0340f7f
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
Instead of always sleeping for 950 to 1050
microseconds between subsequent reads of the
BAM RX pipe, allow the driver to pick an
interval based on how full the BAM pipe is.
Using this technique allows the CPU to stay
in an idle state longer than with just 1ms
sleeps without compromising performance.
Change-Id: I996cd3a9da912a0acc5552566a093d3904cec4e7
Signed-off-by: Anurag Singh <anursing@codeaurora.org>
It is observed that sometimes msm_bus voting upate API taking
longer time to return which delays the HSIC resume sequence
which is time critical.
CRs-Fixed: 388430
Change-Id: I5ad93ee4bbea2b83dad8cc5c8ece8b72ee433d9f
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
Fix typo in code which is causing incorrect setting of vertical front
porch on timing generator settings and incorrect output to panel.
Change-Id: I4de61209443fcb284b7d4064a2039b5f546935d1
Signed-off-by: Adrian Salido-Moreno <adrianm@codeaurora.org>
According to the TLMM_v3 hardware spec the INTR_POL_CTL bit
is to be set:
Low for level low interrupts;
High for level high interrupts;
High for all edge interrupts.
Make sure the software configures it as desired.
Change-Id: I3369def7bd00e427c7dfe109bcdd4b6e207ad239
Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
The reset state for the INTR_CFG register is 0xE2. We need
the upper nibble to specify the target processor for the
gpio interrupt (Value 0x4 for APPS). But we were ORing
0x4 with 0xE still keeps it as 0xE. Get rid of the
incorrect read, modify, write cycle. Make sure the
reset state is wiped off before setting the interrupt
configuration bits.
Change-Id: I3deee9fcebe9eec78f89635313c5f3d0923fede5
Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
Initialize the Krait headswitches when bringing secondary
CPUs out of reset.
Change-Id: I80ab07d91d5b4d5928844e361717f28208ab9aa2
Signed-off-by: Stepan Moskovchenko <stepanm@codeaurora.org>
Create a function to be called very early (before the krait-regulator
driver probes) to switch a cpu in BHS mode. Since we have not yet
probed yet, use the base address passed in to do the necessary writes.
Change-Id: I1cb1659f1e31e52b9d209427887230ee922aef80
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Currently mdp clk and bw requests are predefined in a 4-entry table
passed from the board file, and the logic to decide which level to use
is mainly based on source resolution. This patch is intended to
address several issues with this approach.
One major issue is clk and bandwidth depends on seperate things, and
need to be considered seperately. e.g. with mdp composition of
multiple pipes, bw request may be high but clk requirement may still
be low. The current approach that binds these two things together
causes inefficiency of power.
Another major issue is that there is no logic to calculate mdp clk
requirement of a single pipe based upon panel clk and downscale
parameters. Further the worst case of mdp clk should be determined by
all pipe usage. Without proper logic, many underrun have been
experienced, and blt mode may not be enalbed properly.
Also mdp_clk or blt mode update must be on right timing especially
between these two pathes: overlay play and pan display. In the
situations of performance from high to low or from low to high clk and
blt must be handled properly to avoid underruns.
In a summary, to support many different panels and targets and
complicated mdp pipe usage(mdp composition), mdp driver related to clk
and bw needs to be implemented differently. This patch is to seperate
clk and bw, and maily to deal with mdp clk and blt. Later increasing
granuity of bw will be added.
Change-Id: I678fbf86d6997ed7b602ce81cf2e0fff6164d129
Signed-off-by: Siddhartha Agrawal <agrawals@codeaurora.org>
If the vote for pm runtime is done while codec shutdown, it is possible
that the runtime pm vote occurs even before the slimbus port for tx/rx
audio channel is disconnected. This can cause problem in audio playback/
record. Fix by moving the vote for runtime pm after slimbus port has
been disconnected
Change-Id: I711bc5cfee5b832575ea0b91cf68e826f1a3c0f5
Signed-off-by: Bhalchandra Gajare <gajare@codeaurora.org>
Before "msm: SSR: Pull struct restart_wq_data into struct
subsys_device" we would allocate a work struct for every instance
of a subsystem_restart() call. After that change, we only
allocate one instance of the work during intialization and we
serialize calls to queue_work() with a restarting flag in the
subsys_device structure. This has the unfortunate side effect of
silently ignoring a subsystem_restart() call made while a
subsystem is in the process of restarting (i.e. hasn't reached
the end of subsystem_restart_wq_func().
Add a refcount around the wake lock so that the system stays out
of suspend for as long as any restart work item is being processed.
Then queue the work unconditionally so that the work queue
function can determine that a subsystem restart is happening
while the subsystem is powering up.
Change-Id: Ide5627a29a0df7c1c102cf508ce577ce4f751140
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
- Adds Error check before calling control to make
sure that Venus is in right state.
- Adds supports to calculate right scratch buffer length.
Change-Id: I83043a87859d7bb31c683e3ad19a4a23fb519747
Signed-off-by: Praneeth Paladugu <ppaladug@codeaurora.org>
Packet polling is intended to be used with interrupts disabled, however in
multicore targets, interrupts may not be disabled on all cores. Therefore
packet polling must lock on shared resources to ensure cores with
interrupts enabled do not stomp on polling operations.
Change-Id: I2faa1024024a46ef7c55224f8e9c5e548d07c5e4
Signed-off-by: Jeffrey Hugo <jhugo@codeaurora.org>
Since MSM no longer uses PMEM, the variables, macros, and kernel
config (CONFIG_KERNEL_PMEM_EBI_REGION) relating to PMEM should be
renamed to something more generic.
Change-Id: I4ca909098c96317853d4f040850b63f37db4811e
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Contains the platform data needed to run the TSPP driver on 8064.
For more details on the TSPP peripheral, please read:
kernel/Documentation/arm/msm/tspp.txt
Change-Id: Icaa3cca0e951bcd79cc7ed4efe456b38fa586c8d
Signed-off-by: Joel Nider <jnider@codeaurora.org>
When a strong battery is removed, it was seen that the battery voltage
lines on the phone take about five to six seconds to go below 2.1volts
where the pmic resets all the battery backed registers.
If a new battery is plugged in within this time the driver will force
the shutdown soc on this battery which is incorrect.
Compare the shutdown soc with the calculated soc and if they are
different than a configurable limit, simply discard the shutdown soc
and use the calculated soc.
Change-Id: I02e7c78eb5e9df0127ce7e78b0bd9792a8141039
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
The adjusting algorithm was designed to prevent uvlo event towards
low state of charge situations. It works by decreasing ocv so that the
a lower soc is reported.
When the battery is fully charged, we fake an ocv event, causing the
ocv to jump to 100% and cc to 0. But after a few milliseconds when
charging stops, the adjusting algorithm reduces the ocv which
causes the SOC to jump from 100% to 99%.
This jump from 100 to 99 is incorrect. Moreover we have seen quick
decreases at high soc range because of the adjusting algorithm.
To fix that and the 100 to 99% jumps simply don't run the adjusting
algorithm when the battery soc is above 90%.
Change-Id: I68e8bb72ec0e58552f9fedecceaffbf149c1f10e
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
When ocv (open circuit voltage of the battery) is adjusted to match a
specific soc, rbatt (the battery resistance) changes too. This is
because rbatt is dependent on the remaining charge which changes as
the ocv changes.
The issue we observed with this changing rbatt was the unusable charge
changes which causes the soc to move away from the soc the algorithm
attempts to match.
To get around this issue adjust both the rbatt and ocv in a iterative
fashion until rbatt value stabilizes.
Change-Id: Id3e36c1a8361a6d71b63fca3e6b0c2a4a9bb7e06
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
The soc (state of charge) calculation algorithms and the associated
adjusting algorithms were coded assuming that the soc will be queried
at distant intervals (more than 20 seconds).
However this assumption is bad and soc can be queried at sub second
intervals. These soc queries in quick succession causes the adjusting
algorithm to over correct the battery voltage.
Separate the soc calculation from the soc reporting - calculate soc
at specific intervals, while the reporting uses the values resulting
from the latest calculation. This way the adjusting algorithms run
at specified intervals and are not perturbed by the sub second querying
for soc.
Change-Id: I240bfdbd3ae3b2e37ae16cc3757a25f5a918e972
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
When ocv (open circuit voltage of the battery) is adjusted to match a
specific soc, rbatt (the battery resistance) changes too. This is because
rbatt is dependent on the remaining charge which changes as the ocv
changes.
The issue we observed with this changing rbatt was the unusable charge
changes which causes the soc to move away from the soc the algorithm
attempts to match.
To get around this issue adjust both the rbatt and ocv when we want to
match a soc for a specific soc.
Change-Id: Ifa8efe1e37b9982d6d67730f911e47e369e9b4ff
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
When the battery percent charge goes low we want to increase the
frequency of state of charge updates. This helps the correction
algorithm ample opportunities to correct the state of charge and
prevent a low voltage shutdown.
Change-Id: Ie846350ee4c1fd70198d28646779b20349134ef7
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
It could happen that the calculated soc was higher than the reported
soc even when a charger is not plugged in. This usually happens when
the battery temperature increases or the average current changes causing
unusable charge to go low. The current code never reports this high soc
unless a charger is plugged in.
However at the instant when charger is plugged in, the driver reports
that high calculated soc. This jump in soc in an instant is
unacceptable.
Slowly increase the reported soc so that it approaches the calculated
soc while charging. Basically we are playing catchup between reported
soc and calculated soc. The catch up time is based on how big the
difference between calculated soc and reported soc is - we allow
60 seconds per percent delta.
Change-Id: Ic1ae741c23ea596a46ca2cd49b58c75cf773c3e5
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
The dynamic UUC algorithm changes the UUC as load, state of charge and
temperature changes. This uncontrolled behaviour causes unacceptable
jumps in state of charge numbers.
Replace the dynamic UUC algorithm with a simple average current based
UUC. The average current is calculated by remembering the load for last
few (16) samples. Also to maintain a reasonable UUC while charging, a
load of 300mA is assumed.
Note that the first time UUC is calculated we don't have load samples
and in that case the instantaneous current is used.
Since we now don't change the UUC with respect to max possible load
(itest), the usage of this value is removed. Also instead of failure
voltage we introduce cutoff voltage which represents the loaded voltage
by which the battery should be reported 0%.
Change-Id: Ia640164ee2c9690537308d4e840953824ba15b58
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Experiments have shown that shutdown_soc is very accurate. However
upon a restart, the battery may be unsettled, leading to a significantly
different power on soc.
Update the code to force the value of shutdown soc on the power on
soc. To do this simply update the power on OCV (open circuit voltage)
value.
Change-Id: I1015b800e559cb08422364ffc8c8b981ddd4f07e
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
The power supply api reports usb as missing if a usb wall charger
is plugged in - this is expected as a usb wall charger should be
treated as a dc charger - not a usb charger.
The bms needs to know if anything is connected to the usb port, it
does not care whether it is a usb wall charger or pc usb charger.
Use a direct api exposed by the charger that reports the USBIN_VALID
bit.
Change-Id: Ide05f7da1b14ad3b288633e887611dd5fa79276a
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Introduce periodic hkadc calibration again. A bug was introduced when
periodic ccadc calibration code was moved to the ccadc driver - hkadc
calibration got dropped.
Reintroduce periodic hkadc calibration.
Change-Id: Ib22e03ce881320ca556bfbddd55e658b42363065
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
There is a bug in the sequence between when the calibration work is
scheduled and the global chip pointer is initialized. If work is
scheduled before the chip pointer is initialized it refuses to
calibrate.
Initialize the chip pointer before scheduling calibration work.
Change-Id: I333c97c005e8bc17a28fc0dac3f76e4f26fcc486
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
The code is rounding down state of charge value in the final step of the
calculation. Instead use a division that returns the closest integer.
Change-Id: Ia47d1c4eb684dd4c31e454dc762add0feab66b75
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Since battery resistance is found to be changing w.r.t. state of charge,
temperature and time since a load change happened, it is best if rbatt
is estimated using learnt tables.
Remove all the code that attempts to read battery resistance from BMS.
Change-Id: Id8d84d610df0bcca79d7e42ffae572c0898d63c6
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
If the battery fet is open, the current sourced or sinked from the
battery is very low. There is a high chance that an open circuit
voltage(OCV) happens. Putting the BMS in override mode resets the timer
whose expiry causes an OCV.
Avoid putting the BMS in override mode if battery fet is open.
Change-Id: Idc463bcc55b51cf188cc8ee440a66f763654f174
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
"#gpio-cells" property somehow ended up being defined
twice in the device node for gpio. Remove it
Change-Id: I555a2d23c2f11c8bb28c8797b9e71a48cb066a49
Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
Timing generator was getting started before the register flush.
Stale values were sometimes causing IOMMU page faults on bootup.
Signed-off-by: Siddhartha Agrawal <agrawals@codeaurora.org>
Change-Id: Ia671c3603e383af94197a23a8e5e5f32274a9978
By doing this we don't need to look up mctl instance, which is
not necessary because NOTIFY_VFE_IRQ does nothing more than
routing IRQ to VFE subdev.
If we were to look up mctl instance, for IRQs like RESET_ACK,
we won't know whether we should use PIX or RDI instance.
Change-Id: Idbecc47d7e031302cc4c03aa9936584ea10225d3
Signed-off-by: Shuzhen Wang <shuzhenw@codeaurora.org>
This reverts commit ecfd56aaca9e1ed20e6eae3322c365f9d8e5cc0c.
krait-regulator is now working, so it's safe to switch over.
Change-Id: I6f52eb4b543e2f8da879bf0dc32f9237cbd318a6
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
Currently we enable the timer and unmask the interrupt
before setting the TVAL.
(in commit 9c642ecd6b71bb068c8a931285dc1dce043b137c)
This could cause a regression by opening a window
where TVAL can be negative (from a previous timer trigger)
and the interrupt unmasked, which would lead to an
immediate trigger, before TVAL is updated with the new value.
We need to set the TVAL after unmasking the interrupt, but
before enabling the timer.
Change-Id: I4989834f5dd50aa72e4e97f9ab15b82931bfdd1c
Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
