We want to request TZ to change page table format
for non secure context banks only if static-cb
option is enabled. If the option is disabled then
programming of global registers would be done by
HLOS itself and we need not request TZ to change
page table format.
Change-Id: Id2228e6d2ec835e169d679296760256ce0524050
Signed-off-by: Susheel Khiani <skhiani@codeaurora.org>
For targets where we have slave side protection,
global register programming is handled by TZ. And
since it supports V7S page table format only, by
default TZ programs all context bank to permit
V7S format by programming VA64 bit of CBA2R register
as 0.
But if context bank itself is non secure then its
page tables are managed by HLOS where we can
support V8L page table format. So, provide a way
to request TZ to change page table format to V8L
for non secure context banks.
CRs-Fixed: 959535
Change-Id: I1f4d4b98c4f240a8351f791901abdfa78b829973
Signed-off-by: Susheel Khiani <skhiani@codeaurora.org>
restore_sec_cfg call needs to be made to inform
secure world that device have resumed from power
collapse mode and security settings need to be
relaxed. Accordingly we had a restore_sec_cfg
call in arm_smmu_resume which would be called
from regulator_notifier on regulator enable
event.
But during initial device probe also we need to
read through SMMU global registers like IDR0,
IDR1 to understand hardware configuration of SMMU
and accordingly populate our data structures. We
can't call arm_smmu_resume at this point as we
are still to identify page size of SMMU register
map which we get only through reading IDR1
register.
So make an explicit restore_sec_cfg call at SMMU
probe which would enable us to read through
SMMU global registers. We need this call only
for targets which have slave side protection
mechanism.
CRs-Fixed: 959535
Change-Id: If4e53966edbf4e76a3d03f3a8684563f0ceac13d
Signed-off-by: Susheel Khiani <skhiani@codeaurora.org>
When we have SMMU halt/resume functionality
enabled we try to program MICRO_MMU_CTRL register
which is part of SMMU implementation defined
register space. Now targets which have slave side
protection mechanism, implementation defined
register space of SMMU is protected by XPUs along
with other SMMU global register space. As a result
we would get a fault if we directly try to program
MICRO_MMU_CTRL register.
Instead we request TZ through atomic scm call to
program this register for us. Since we have read only
permission available for these registers we need to
ensure that write operation is requested through TZ.
CRs-Fixed: 959535
Change-Id: Ie257553a25bb11785b69568d8eccbef91d8d18e0
Signed-off-by: Susheel Khiani <skhiani@codeaurora.org>
For targets where we have no hypervisor, slave
side protection mechanism is used to provide
buffer protection. Add functionality to make
calls into TZ for mapping/unmapping of buffers.
CRs-Fixed: 959535
Change-Id: I3106a98370a70611f4670aaf1c0f95c9e758a87c
Signed-off-by: Susheel Khiani <skhiani@codeaurora.org>
To implement slave side protection, programming of
global registers as well as secure context bank
registers is handed over to TZ. Now, instead of
dynamically allocating context banks, TZ allocates
CBs once in pre defined static manner during boot
and this allocation is maintained throughout the
life of system.
Add an option to enable use of this pre-defined
context bank allocation. We would be reading
through SMR and S2CR registers at run time
to identify CB allocated for a particular sid.
CRs-Fixed: 959535
Change-Id: I782470a2e4d2a66be17ed2b965ba52b7917592f6
Signed-off-by: Susheel Khiani <skhiani@codeaurora.org>
Up until now, the arm-smmu driver has only supported one type of
security mechanism: master-side access control. However, in the near
future it will be getting support for slave-side access control, at
which point saying a domain is "secure" will be ambiguous. Make the
distinction explicit by renaming arm_smmu_is_domain_secure to
arm_smmu_is_master_side_secure.
CRs-Fixed: 959535
Change-Id: Ie9bc077fe60d0b97c744fdb5b3f553cc056df27f
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Update MSM_REMOTEQDSS to QCOM_REMOTEQDSS per kernel upgrade guidelines.
Change-Id: I6abf84a27f7271181833d0112f1d795354ea7f0c
Signed-off-by: Patrick Daly <pdaly@codeaurora.org>
Add the reference count for Smart Wireless Interface Manager to
know whether there are any process who still has the socket in
question in use or not.
Enable INET DIAG.
Redefine the TCP_FLAG as it gives compiling error when an enum is defined
by a function return.
Change-Id: I1aa9c810fec2e332048c9ef4199ec3f996bc3a75
Signed-off-by: Chinh Tran <chinht@codeaurora.org>
[chiaweic@codeaurora.org: resolve conflicts encountered with port to 4.4]
Signed-off-by: Skylar Chang <chiaweic@codeaurora.org>
We now support building Android in a build tree that contains
multiple kernels. The kernel version to be built is passed in
by the higher level makefiles.
Currently supported structure:
- legacy <Android Root>/kernel
- New <Android Root>/kernel/msm-*
Change-Id: Ibd6c03c019643adfbadc61e46a3dd760930028bb
Signed-off-by: Ameya Thakur <ameyat@codeaurora.org>
Signed-off-by: David Ng <dave@codeaurora.org>
Currently the load argument is taken as unsigned long in
sl_busy_to_laf. In case of 32-bit kernels, the use of
unsigned long results in overflows since it is only 32-bits.
And so the cpu_load calculation is going wrong and most of
the times getting reported very low values. Hence use
mult_frac call to avoid overflows when the final result
is expected to be within 32-bits.
Change-Id: Ib9e8bf6e777cd07b141761fb14c80840563b4cd5
Signed-off-by: Hanumath Prasad <hpprasad@codeaurora.org>
With modification in scheduler, governor now gets predicted
instantaneous demand waiting to run in addition to demand from
previous window for each CPU. Make use of this information since
prediction from scheduler could be more accurate than just looking at
past few windows.
Governor calculates two frequencies during each sampling period: one based
on demand in previous sampling period (f_prev), and the other based on
prediction provided by scheduler (f_pred). Max of both will be selected
as final frequency. Hispeed related logic, including both frequency
selection and delay is ignored when prediction is enabled. If only
f_pred but not f_prev picked policy->max, max_freq_hysteresis period is
not started/extended. This is to reduce power cost of mis-prediction
if it happens.
One use case prediction could dramatically help is when a heavy task
wakes up after sleeping for a long time. With prediction, governor
could ramp up to frequency the task needs much faster than before.
To enable prediction, echo 1 to enable_prediction file in
cpufreq interactive sysfs directory.
Change-Id: I27396785886e43ea01c9000c651c8bd142172273
Suggested-by: Saravana Kannan <skannan@codeaurora.org>
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
Multiple migrations can happen together within short period if
scheduler is re-arranging a few tasks. In this case, it's only useful
to change frequency at the end of all migrations. Delay handling of
scheduler notification by 1ms.
Change-Id: I9ee7b1e93ce57c28919b5609c40dcde9bd14abed
Suggested-by: Saravana Kannan <skannan@codeaurora.org>
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
Scheduler could send a notification to governor each time a task wakes
up. If governor wakes up another task as a response to such a
notification, it could result in endless recursive notifications.
Use wake_up_process_no_notif to ensure scheduler won't send another
notification for speedchange task woken up by the governor.
Change-Id: I697affcbdf79e2ad0cfe843eb880d304960682f4
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
This change adds MSM specific USB function drivers and relevant glue
drivers providing RMNET, RNDIS, DPL, ECM and MBIM functionality with
BAM2BAM IPA mode. This snapshot is taken as of msm-3.18 kernel
'commit 8007444c107a ("Merge pinctrl: qcom: Update gcc_gp1_clk_b_groups
for msm8953")'.
Signed-off-by: Mayank Rana <mrana@codeaurora.org>
The commit 5e16bbc2fb ("sched: Streamline the task migration locking
a little") hardened task migration locking and now __migrate_task() is
called after rq lock held. Move out notification out of spinlock.
Change-Id: I553adcfe80d5c670f4ddf83438226fd5e0924fe8
Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
Fix various compilation failures when CONFIG_SCHED_HMP or
CONFIG_SCHED_INPUT isn't enabled.
Change-Id: I385dd37cfd778919f54f606bc13bebedd2fb5b9e
Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
Biasing sync wakee task towards waker CPU's cluster makes sense when the
waker's demand is high enough so the wakee also can take advantage
of high CPU frequency voted because of waker's load. Placing sync wakee
on the low demand waker's CPU can lead placement imbalance which can
lead unnecessary migration.
Introduce a new tunable "sched_big_waker_task_load" that defines the big
waker so scheduler avoid wakee on waker's cluster bias when the waker's
load is below the tunable.
CRs-fixed: 971295
Change-Id: I1550ede0a71ac8c9be74a7daabe164c6a269a3fb
Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
[joonwoop@codeaurora.org: fixed a minor conflict in
include/linux/sched/sysctl.h.]
If sync wakee task's demand is small it's worth to place the wakee task
on waker's cluster for better performance in the sense that waker and
wakee are corelated so the wakee should take advantage of waker cluster's
frequency which is voted by the waker along with cache locality benefit.
While biasing towards the waker's cluster we want to avoid the waker CPU
as much as possible as placing the wakee on the waker's CPU can make the
waker got preempted and migrated by load balancer.
Introduce a new tunable 'sched_small_wakee_task_load' that differentiates
eligible small wakee task and place the small wakee tasks on the waker's
cluster.
CRs-fixed: 971295
Change-Id: I96897d9a72a6f63dca4986d9219c2058cd5a7916
Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
[joonwoop@codeaurora.org: fixed a minor conflict in
include/linux/sched/sysctl.h.]
p->grp is being accessed outside of lock which can cause null-pointer
dereference. Fix this and also add rcu critical section around access
of this data structure.
CRs-fixed: 985379
Change-Id: Ic82de6ae2821845d704f0ec18046cc6a24f98e39
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
[joonwoop@codeaurora.org: fixed conflict in init_new_task_load().]
Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
At present sched_select_prev_cpu_us tunable is restricted to values
below 100us. Fix this unintended restriction.
CRs-Fixed: 972237
Change-Id: I5eaf9f40468805c396328ca1022baef32acf8de0
Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
The idle task's mark_start can get updated even without the CPU being
online. Hence the mark_start is restored when the CPU is coming online.
The idle task's mark_start is reset in init_idle()->__sched_fork()->
init_new_task_load(). The original mark_start is saved and restored
later. This can be avoided by moving init_new_task_load() to
wake_up_new_task(), which never gets called for an idle task.
We only care about idle task's ravg.mark_start and not initializing
the other fields of ravg struct will not have any side effects.
This clean up allows the subsequent patches to drop the rq->lock
while calling __sched_fork() in init_idle().
CRs-Fixed: 965873
Change-Id: I41de6d69944d7d44b9c4d11b2d97ad01bd8fe96d
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
[joonwoop@codeaurora.org: fixed a minor conflict in core.c. omitted
changes for CONFIG_SCHED_QHMP.]
Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
When sched_restrict_cluster_spill knob is enabled, RT tasks are restricted
to lower power cluster. This knob also restricts inter cluster no-hz kicks.
Ignore this knob setting when sched_boost is enabled so that tasks are
placed on CPUs with highest spare capacity.
CRs-Fixed: 968852
Change-Id: I01b3fc10b39dc834a733d64c2ee29c308d7ff730
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Current window based load tracking only saves history for five
windows. A historically heavy task's heavy load will be completely
forgotten after five windows of light load. Even before the five
window expires, a heavy task wakes up on same CPU it used to run won't
trigger any frequency change until end of the window. It would starve
for the entire window. It also adds one "small" load window to
history because it's accumulating load at a low frequency, further
reducing the tracked load for this heavy task.
Ideally, scheduler should be able to identify such tasks and notify
governor to increase frequency immediately after it wakes up.
Add a histogram for each task to track a much longer load history. A
prediction will be made based on runtime of previous or current
window, histogram data and load tracked in recent windows. Prediction
of all tasks that is currently running or runnable on a CPU is
aggregated and reported to CPUFreq governor in sched_get_cpus_busy().
sched_get_cpus_busy() now returns predicted busy time in addition
to previous window busy time and new task busy time, scaled to
the CPU maximum possible frequency.
Tunables:
- /proc/sys/kernel/sched_gov_alert_freq (KHz)
This tunable can be used to further filter the notifications.
Frequency alert notification is sent only when the predicted
load exceeds previous window load by sched_gov_alert_freq converted to
load.
Change-Id: If29098cd2c5499163ceaff18668639db76ee8504
Suggested-by: Saravana Kannan <skannan@codeaurora.org>
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
[joonwoop@codeaurora.org: fixed merge conflicts around __migrate_task()
and removed changes for CONFIG_SCHED_QHMP.]
Each time a task wakes up, scheduler evaluates its load and notifies
governor if the resulting frequency of destination CPU is larger than
a threshold. However, some governor wakes up a separate task that
handles frequency change, which again calls wake_up_process().
This is dangerous because if the task being woken up meets the
threshold and ends up being moved around, there is a potential for
endless recursive notifications.
Introduce a new API for waking up a task without triggering
frequency notification.
Change-Id: I24261af81b7dc410c7fb01eaa90920b8d66fbd2a
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
If the tasks are run on the higher capacity cluster solely due to the
reason that they can not be be fit in the lower capacity cluster, the
downmigrate threshold prevents the frequent tasks migrations between
the clusters.
Change-Id: I234a23ffd907c2476c94d5f6227dab1bb6c9bebb
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
The current CPU selection algorithm for RT tasks looks for the
least loaded CPU in all clusters. Stop the search at the lowest
possible power cluster based on "sched_restrict_cluster_spill"
sysctl tunable.
Change-Id: I34fdaefea56e0d1b7e7178d800f1bb86aa0ec01c
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
The select_best_cpu() algorithm iterates over all the clusters and
selects the most power efficient CPU that satisfies the task needs.
During the search, skip the next cluster if its minimum power cost
is higher than the power cost of an eligible CPU found in the previous
cluster.
In a b.L system, if the BIG cluster minimum power cost is higher than
the maximum power cost of the little cluster, this optimization avoids
searching the BIG cluster if an eligible CPU is found in the little
cluster.
Change-Id: I5e3755f107edb6c72180edbec2a658be931c276d
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
The frequency based inter cluster load balance restrictions are not
reliable as frequency does not provide a good estimate of the CPU's
current load. Replace them with the spill_load and spill_nr_run
based checks.
The higher capacity cluster is restricted from pulling the tasks from
the lower capacity cluster unless all of the lower capacity CPUs are
above spill. This behavior can be controlled by a sysctl tunable and
it is disabled by default (i.e. no load balance restrictions).
Change-Id: I45c09c8adcb61a8a7d4e08beadf2f97f1805fb42
Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
[joonwoop@codeaurora.org: fixed merge conflicts due to omitted changes
for CONFIG_SCHED_QHMP.]
Provide userspace interface for tasks to be grouped together as
"related" threads. For example, all threads involved in updating
display buffer could be tagged as related.
Scheduler will attempt to provide special treatment for group of
related threads such as:
1) Colocation of related threads in same "preferred" cluster
2) Aggregation of demand towards determination of cluster frequency
This patch extends scheduler to provide best-effort colocation support
for a group of related threads.
Change-Id: Ic2cd769faf5da4d03a8f3cb0ada6224d0101a5f5
Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
[joonwoop@codeaurora.org: fixed minor merge conflicts. removed ifdefry
for CONFIG_SCHED_QHMP.]
Signed-off-by: Syed Rameez Mustafa <rameezmustafa@codeaurora.org>
Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
Make use of clusters in the fair and rt scheduling classes. This is
needed as the freq domain mask can no longer be used to do correct
task placement. The freq domain mask was being used to demarcate
clusters.
Change-Id: I57f74147c7006f22d6760256926c10fd0bf50cbd
Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
Signed-off-by: Syed Rameez Mustafa <rameezmustafa@codeaurora.org>
[joonwoop@codeaurora.org: fixed merge conflicts due to omitted changes
for CONFIG_SCHED_QHMP.]
Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
A cluster is set of CPUs sharing some power controls and an L2 cache.
This patch buids a list of clusters at bootup which are sorted by
their max_power_cost. Many cluster-shared attributes like cur_freq,
max_freq etc are needlessly maintained in per-cpu 'struct rq' currently.
Consolidate them in a cluster structure.
Change-Id: I0567672ad5fb67d211d9336181ceb53b9f6023af
Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
[joonwoop@codeaurora.org: fixed minor conflict in
arch/arm64/kernel/topology.c. fixed conflict due to ommited changes for
CONFIG_SCHED_QHMP.]
Signed-off-by: Syed Rameez Mustafa <rameezmustafa@codeaurora.org>
This snapshot is taken as of msm-3.18 commit
d5809484b (Merge "msm: ipa: fix race condition
when teardown pipe" )
Signed-off-by: Skylar Chang <chiaweic@codeaurora.org>
Both QUSB PHY and QMP PHY are required set of registers to configure
as part of initialization sequence. This change provides those registers'
offset and value to program with it.
Also remove android_usb device node as it usage is deprecated now.
Signed-off-by: Mayank Rana <mrana@codeaurora.org>
Currently QMP PHY driver expects to have both se_clk and diff_clk
based PHY initialization sequence from devicetree. This change
removes need of both phy_clk_scheme based init sequence as on newer
platform QMP PHY only uses one of phy_clk_scheme.
Signed-off-by: Mayank Rana <mrana@codeaurora.org>
This change adds phy_clk_scheme property related configuration with
QUSB PHY device node for 8996 and cobalt.
Signed-off-by: Mayank Rana <mrana@codeaurora.org>
This change adds qcom,phy-clk-scheme mandatory property with QUSB
PHY driver. qcom,phy-clk-scheme property must have "cml" (i.e. DIFF
clock scheme) or "cmos" (i.e. SE clock scheme). Based on this input
qusb phy driver uses required reset and initialization sequence.
Signed-off-by: Mayank Rana <mrana@codeaurora.org>
On newer platform TCSR register based clk_scheme usage is not
available. Hence remove its usage from QUSB and QMP PHY drivers.
Signed-off-by: Mayank Rana <mrana@codeaurora.org>
This change fixes below compilation warning on Kernel 4.4.
watchdog.c:122:22: warning: 'hardlockup_allcpu_dumped' \
defined but not used [-Wunused-variable]
Signed-off-by: Satya Durga Srinivasu Prabhala <satyap@codeaurora.org>
This change fixes below compilation warnings on Kernel 4.4.
thermal_core.c:303:2: warning: format '%d' expects argument of \
type 'int', but argument 4 has type 'long int' [-Wformat=]
thermal_core.c:303:2: warning: format '%d' expects argument of \
type 'int', but argument 5 has type 'long int' [-Wformat=]
Signed-off-by: Satya Durga Srinivasu Prabhala <satyap@codeaurora.org>
Now that we don't use SNDRV_PCM_RATE_xxx bit fields for sample rate, we need to
change the description to an array for describing the sample rates supported by
the sink/source
Change-Id: I2dc6b4e48cccbc7a3da7207be42cf11502373572
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Git-commit: b8bab04829
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
Signed-off-by: Banajit Goswami <bgoswami@codeaurora.org>
Signed-off-by: vivek mehta <mvivek@codeaurora.org>
[fred@codeaurora.org: resolved context conflict in struct snd_codec_desc]
[fred@codeaurora.org: added msm-compress-q6-v2.c to resolve compilation error]
Signed-off-by: Fred Oh <fred@codeaurora.org>
On the 4.4 kernel non platform devices now have to call
arch_setup_dma_ops to setup their dma ops otherwise the
dummy dma opts will be used.
This because of change the following change:
1dccb59 arm64: simplify dma_get_ops
Introduce a panic if a the dummy dma alloc is used to
help clients more easily identify why their dma allocations
are failing.
This patch can later be reverted once all non platform devices
have fixed their code.
Change-Id: I2dd7eb0694c8c403da21133601eb7e831ead2dfd
Signed-off-by: Liam Mark <lmark@codeaurora.org>
