The parallel charging code has grown organically.
Clean up the following:
1. Use correct units for all unit based variables.
2. Use slave percent instead of master percent.
3. Remove parallel master module parameter.
4. Put PARALLEL_DISABLE where it belongs in battery psy.
5. Create a get_jeita_cc_delta function similar to get_step_cc_delta
function.
6. Print errors when returning error codes.
Change-Id: I27ec29c3a6c5f3aac31705e60e1b8cf3270322a1
Signed-off-by: Nicholas Troast <ntroast@codeaurora.org>
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Add support for Lpass PIL which facilitates the loading of Lpass
firmware, authentication and bringing it out of reset.
Change-Id: I367f4b3afdae9d0f78081e142be34132aaf07ab4
Signed-off-by: Gaurav Kohli <gkohli@codeaurora.org>
The previous patches in this series introduce the mechanics of CPU
load tracking without fixups for intra cluster migration and top task
load tracking. Add a tunable that dictates what of the above needs to
be considered when reporting load to the governor. The default policy
is to take the maximum of the CPU load and top task load.
Change-Id: Ie585a11ed774b929910d04c41471db3a2a102ec5
Signed-off-by: Syed Rameez Mustafa <rameezmustafa@codeaurora.org>
find_next_top_index() is responsible for finding the second top task
on a CPU when the top task migrates away from that CPU. This operation
is expensive as we need to iterate the entire array of top tasks to
find the second top task.
Optimize this by introducing bitmaps for tracking top task indices.
There are two bitmaps; one for the previous window and one for the
current window. Each bit in a bitmap tracks whether the corresponding
bucket in the top task hashmap has a non zero refcount. The bit is set
when the refcount becomes non zero and is cleared when it becomes zero.
Finding the second top task upon migration is then simply a matter of
finding the highest set bit in the bitmap.
Change-Id: Ibafaf66eed756b0328704dfaa89c17ab0d84e359
Signed-off-by: Syed Rameez Mustafa <rameezmustafa@codeaurora.org>
The previous patches in this rewrite of scheduler guided frequency
selection reintroduces the part-picture problem that we addressed in
our initial implementation. In that, when tasks migrate across CPUs
within a cluster, we end up losing the complete picture of the
sequential nature of the workload.
This patch aims to solve that problem slightly differently. We track
the top task on every CPU within a window. Top task is defined as the
task that runs the most in a given window. This enhances our ability
to detect the sequential nature of workloads. A single migrating task
executing for an entire window will cause 100% load to be reported
for frequency guidance instead of the maximum footprint left on any
individual CPU in the task's trail. There are cases, that this new
approach does not address. Namely, cases where the sum of two or more
tasks accurately reflects the true sequential nature of the workload.
Future optimizations might aim to tackle that problem.
To track top tasks, we first realize that there is no strict need to
maintain the task struct itself as long as we know the load exerted by
the top task. We also realize that to maintain top tasks on every CPU
we have to track the execution of every single task that runs during
the window. The load associated with a task needs to be migrated when
the task migrates from one CPU to another. When the top task migrates
away, we need to locate the second top task and so on.
Given the above realizations, we use hashmaps to track top task load
both for the current and the previous window. This hashmap is
implemented as an array of fixed size. The key of the hashmap is given
by task_execution_time_in_a_window / array_size. The size of the array
(number of buckets in the hashmap) dictate the load granularity of each
bucket. The value stored in each bucket is a refcount of all the tasks
that executed long enough to be in that bucket.
This approach has a few benefits. Firstly, any top task stats update
now take O(1) time. While task migration is also O(1), it does still
involve going through up to the size of the array to find the second
top task. Further patches will aim to optimize this behavior. Secondly,
and more importantly, not having to store the task struct itself saves
a lot of memory usage in that 1) there is no need to retrieve task
structs later causing cache misses and 2) we don't have to unnecessarily
hold up task memory for up to 2 full windows by calling get_task_struct()
after a task exits.
Change-Id: I004dba474f41590db7d3f40d9deafe86e71359ac
Signed-off-by: Syed Rameez Mustafa <rameezmustafa@codeaurora.org>
In the current frequency guidance implementation the scheduler migrates
task load from the source CPU to the destination CPU when a task migrates.
The underlying assumption is that a task will stay on the destination CPU
following the migration. Hence a CPU's load should reflect the sum of
all tasks that last ran on that CPU prior to window expiration even if
these tasks executed on some other CPU in that window prior to being
migrated.
However, given the ubiquitous nature of migrations the above assumption
is flawed causing the scheduler to often add up load on a single CPU
that in reality ran concurrently on multiple CPUs and will continue to
run concurrently in subsequent windows. This leads to load over
reporting on a single CPU which in turn causes CPU frequency to be higher
than necessary.
This is the first patch in a series of patches that attempts to change
how load fixups are done upon migration to prevent load over reporting.
In this patch, we stop doing migration fixups for intra-cluster
migrations. Inter-cluster migration fixups are still retained.
In order to achieve the above, we make use the per CPU footprint of each
task introduced in the previous patch. Upon inter cluster migration, we
go through every CPU in the source cluster to subtract the migrating
task's contribution to the busy time on each one of those CPUs. The sum
of the contributions is then added to the destination CPU allowing it
to ramp up to the appropriate frequency for that task.
Subtracting load from each of the source CPUs is not trivial, however,
as it would require all runqueue locks to held. To get around this
we introduce a deferred load subtraction mechanism whereby subtracting
load from each of the source CPUs in deferred until an opportune moment.
This opportune moment is when the governor comes asking the scheduler
for load. At that time, all necessary runqueue locks are already held.
There are a few cases to consider when doing deferred subtraction. Since
we are not holding all runqueue locks other CPUs in the source cluster
can be in a different window than the source CPU where the task
is migrating from.
Case 1: Other CPU in the source cluster is in the same window
No special consideration
Case 2: Other CPU in the source cluster is ahead by 1 window
In this case, we will be doing redundant updates to subtraction load
for the prev window. There is no way to avoid this redundant update
though, without holding the rq lock.
Case 3: Other CPU in the source cluster is trailing by 1 window
In this case, we might end up overwriting old data for that CPU. But
this is not a problem as when the other CPU calls update_task_ravg()
it will move to the same window. This relies on maintaining
synchronized windows between CPUs, which is true today.
Finally, we must deal with frequency aggregation. When frequency
aggregation is in effect, there is little point in dealing with per
CPU footprint since the load of all related tasks have to be reported
on a single CPU. Therefore when a task enters a related group we clear
out all per CPU contributions and add it to the task CPU's cpu_time
struct. From that point onwards we stop managing per CPU contributions
upon inter cluster migrations since that work is redundant. Finally
when a task exits a related group we must walk every CPU in reset
all CPU contributions. We then set the task CPU contribution to the
respective curr/prev sum values and add that sum to the task CPU
rq runnable sum.
Change-Id: I1f8d596e6c930f3f6f00e24109ddbe8b121f8d6b
Signed-off-by: Syed Rameez Mustafa <rameezmustafa@codeaurora.org>
Keeping a track of the load footprint of each task on every CPU
that it executed on gives the scheduler much more flexibility in
terms of the number of frequency guidance policies. These new fields
will be used in subsequent patches as we alter the load fixup
mechanism upon task migration. We still need to maintain the
curr/prev_window sums as they will also be required in subsequent
patches as we start to track top tasks based on cumulative load.
Also, we need to call init_new_task_load() for the idle task. This
is an existing harmless bug as load tracking for the idle task is
irrelevant. However, in this patch we are adding pointers to the
ravg structure. These pointers have to be initialized even for the
idle task.
Finally move init_new_task_load() to sched_fork(). This was always
the more appropriate place, however, following the introduction of
new pointers in the ravg struct, this is necessary to avoid races
with functions such as reset_all_task_stats().
Change-Id: Ib584372eb539706da4319973314e54dae04e5934
Signed-off-by: Syed Rameez Mustafa <rameezmustafa@codeaurora.org>
As per the hardware programming guide, a period of N needs to be
programmed as N-1.
Change-Id: I58c13a97dd35b3a439ea1af25bc93182e38e29f0
CRs-Fixed: 1066261
Signed-off-by: Venu Yeshala <vyeshala@codeaurora.org>
Signed-off-by: Shubhraprakash Das <sadas@codeaurora.org>
Set the vfe clock rate before putting the ahb vote into
suspend otherwise the clock vote will bump up the ahb
vote and prevent shutdown.
CRs-Fixed: 1078215
Change-Id: I439ae8aea839af6d9b84fe1384feb18de3d9d276
Signed-off-by: Shubhraprakash Das <sadas@codeaurora.org>
Acquire lock before you check if the service exist. This leads to
race condition where you end up adding same service multiple times
in service_list and make multiple registration request to servreg.
CRs-Fixed: 1078753
Change-Id: I8ae92ee1d26bd6687b6b2b4cbed1032485d7450e
Signed-off-by: Puja Gupta <pujag@codeaurora.org>
Allow for changing the switching frequency via a power supply property.
The main charger will call this property to ensure optimal power
dissipation.
CRs-Fixed: 1048242
Change-Id: I17aeabe9c20388747dc1965bef22127bd054a828
Signed-off-by: Harry Yang <harryy@codeaurora.org>
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Modern battery chargers use a switching buck whose frequency
can be adjusted. Create a property to read/update it.
CRs-Fixed: 1048242
Change-Id: I7611e6b697222427303df47f837716005e013443
Signed-off-by: Harry Yang <harryy@codeaurora.org>
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
There is a possibility where the driver fails to change
the usb type to Unknown when the cable is removed - in particular
when pd is not allowed.
Use the debounce done event of the typec change interrupt to update
the usb type to Unknown.
Change-Id: I7f201209101e54461e3d08d677bd7b266f971420
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Currently the driver uses the dev_ variants to print debug information.
This is not useful.
Instead print the function name and use pr_ variants to print debug
information.
Change-Id: I0eeb61e847b07ac9b7622ac521bace24a417bb14
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
If an HVDCP charger is detected and it does not support PD, that means
it is likely a legacy QC2 or QC3 charger. Rerun APSD when PD sets us to
be inactive.
For cases when pd is not allowed, PD won't set inactive status. For such
cases use the hvdcp_timeout interrupt to rerun APSD.
Change-Id: Ibe03e1dc88700b605e2f43ee4bca266ce3dee92b
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Add support to set current limits from usb and pd.
Ensure that the limit from the pd is only enforced when pd is active
and that the limit from usb is enforced only when pd is inactive.
There is one situation when the input needs to be suspended as
per the usb driver's request when pd sets system_suspend_supported.
For that allow the usb voter to set that low current value to
suspend.
Also ensure that the pd and usb votes are nullified when source
is removed.
In addition, the return the individual valid votes from usb and pd
when their current_max are read.
Change-Id: I215e9e82f44061c4083a4df8cab400beadf6322d
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
The current driver votes and unvotes for removal/insertion at
two interrupt handlers, debounce done and the type C detach.
The recommendation from hw teams is to use debounce done for both
insertion and removal. Update the code.
While at it, provide clean functions to vote and unvote for four
situations
a typec cable insertion
a typec cable removal
a source insertion
a source removal
Note that this allows us to cleanly handle PD hard resets where
the typec connection remains intact but the source (or vbus) related
state needs to be reset.
This also helps us in cleanly handling power sole swaps where the source
plugged and removed functions handle vbus related states while typec
functions handle the typec related states.
Change-Id: I49fccb1fcf8eaea8fea1ae186906689a628c02f8
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
There could be cables where vbus and cc lines are shorted or connected
using a small resistor. Raising VBUS to higher values could cause CC
line to get damaged. CC line cannot tolerate a voltage higher than 6V.
So if such a cable is seen, prevent pd stack from running so there is no
opportunity to increase vbus by selecting a higher voltage profile. Also
disable HVDP too.
Also, prevent PD_ALLOWED if a legacy cable is seen - the spec mentions
that if VBUS is seen along with CC, the adapter is not pd capable.
Change-Id: I7411bd541ffe704dda97dd869a3dbd4dbfc99518
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Since the USB_PD type is no more set by the PD driver, it is
expected that the type be set based on pd_active property being
ACTIVE. So set the type and update the userspace when it changes.
Change-Id: I0f76f092d3e8de7a916e995e4d825fe0da79bf78
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
While PD is under hard reset and the device is in sink mode, it
shouldn't leave sink mode because VBUS goes away. Instead it should
stay in sink mode while hard reset is being conducted and exit sink
mode only if CC gets detached.
Configure the exit state when hard reset is in progress. Also while
hard reset is in progress disable APSD else a APSD could run and
disturb SDP communication after VBUS recovers in hard reset procedure.
Change-Id: I7f5046d4822438e949658356e683e74acfa664f7
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Currently the code prevents pd if an hvdcp is detected. We want to
change that in that we want to prevent pd only while hvdcp detection
is in progress. Once completed, we need to enable pd even if an hvdcp
is detected. Enabling PD even for hvdcp allows us to detect a QC 4.0
which communicates over PD.
Currently we model the pd_allowed votable as an enable votable i.e.
if any one of the voters enable it, pd_allowed gets enabled.
Change that to a disable votable named pd_disallowed_votable,
which gets disabled when CC is detached, and hvdcp2.0 detection is not
yet completed.
Change-Id: I2ae261c71694695b41d8a31c4b40542d5e227c3a
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Some platforms do not support HVDCP charging. Provide means to
disable them.
Provide a votable for disabling HVDCP in preparation to handle
VBUS and CC line shorted situation.
Note that when hvdcp is disabled, we only disable voltage
negotiations i.e. qc 2.0 detection remains enabled since it
does not need voltage to change.
Change-Id: Id7eaa46f08ac451a918a550f7837efbef78ab6f6
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
When a float charger is detected by APSD there are configuration options
that change the behavior of the charger. These options should be
configurable from the device tree. Add a DT parameter "qcom,float-option"
and configure it as follows:
1 - Treat as a DCP
2 - Treat as a SDP
3 - Disable charging
4 - Suspend USB input
Change-Id: Ia9219bc232f2092569dfb1a14f628e788173c4ff
Signed-off-by: Nicholas Troast <ntroast@codeaurora.org>
It is useful when debugging to force power supply changed events. Add
debugfs entries for each power supply to allow forcing power supply
changed events.
Change-Id: I018eb018de2a8119acc09824c82cca8ff1b52faa
Signed-off-by: Nicholas Troast <ntroast@codeaurora.org>
The PARALLEL_PERCENT property is used for the parallel distribution
percentage.
Change-Id: I7d2a7a775437770075ddbd2d1a36ce5d9e44a631
Signed-off-by: Nicholas Troast <ntroast@codeaurora.org>
900mA can be drawn from a USB 3.0 port that has been enumerated. Do it.
Change-Id: I94e5d36feb3cd54bcc46e8c56933340cad839c1f
Signed-off-by: Nicholas Troast <ntroast@codeaurora.org>
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
The SMB138X TADC can provide the parallel charger with the
measured battery current. Enable it.
Change-Id: I32e5e5ed4ab3f09635f4fe512a1e9b75436ab88e
Signed-off-by: Nicholas Troast <ntroast@codeaurora.org>
When ion imports dma buf, it will return negative error number
in the case of failure like bad file number or invalid dma buf file.
check ion_handle for error numbers.
CRs-Fixed: 1071602
Change-Id: I1ea93161b85deb667cbb6f8515ff7c6943da6e3d
Signed-off-by: Karthikeyan Periasamy <kperiasa@codeaurora.org>
If wrong parameters are set on the dtsi to configure the
esd, a null pointer access can happen. Fix this to make
sure we check for valid pointers and otherwise just
throw an error, but not access an invalid pointer.
Change-Id: I3df0889c1225dcb613910cb90f050a2994f5834d
Signed-off-by: Ingrid Gallardo <ingridg@codeaurora.org>
Enable esd check with register read mode for nt35597 dsc
command and video mode panels and esd check with bta
mode for nt35597 dual-dsi command mode panel in msmcobalt.
Change-Id: I8121d45fedab6197f8466d25674d5b0decd45f1b
Signed-off-by: Ingrid Gallardo <ingridg@codeaurora.org>
Add the implementation defined registers for msmfalcon that ensures the
correct operation of SMMU.
Change-Id: Iaaa9661e0c078ea1e4bb6e110bf4fe672dd2a7e9
Signed-off-by: Charan Teja Reddy <charante@codeaurora.org>
