09 Jun, 2022
1 commit
-
[ Upstream commit 907ed123b9d096c73e9361f6cd4097f0691497f2 ]
This code does not call of_node_put(opp_np) if of_get_next_available_child()
returns NULL. But it should.Fixes: 45679f9b508f ("opp: Don't parse icc paths unnecessarily")
Signed-off-by: Dan Carpenter
Signed-off-by: Viresh Kumar
Signed-off-by: Sasha Levin
19 Nov, 2021
1 commit
-
[ Upstream commit 27ff8187f13ecfec8a26fb1928e906f46f326cc5 ]
Fix sparse warning:
drivers/opp/of.c:924 _opp_add_static_v2() warn: passing zero to 'ERR_PTR'For duplicate OPPs 'ret' be set to zero.
Fixes: deac8703da5f ("PM / OPP: _of_add_opp_table_v2(): increment count only if OPP is added")
Signed-off-by: YueHaibing
Signed-off-by: Viresh Kumar
Signed-off-by: Sasha Levin
31 Aug, 2021
1 commit
17 Aug, 2021
1 commit
-
The 'required-opps' property is considered optional, hence remove
the pr_err() in of_parse_required_opp() when we find the property is
missing.
While at it, also fix the return value of
of_get_required_opp_performance_state() when of_parse_required_opp()
fails, return a -ENODEV instead of the -EINVAL.Signed-off-by: Rajendra Nayak
Reviewed-by: Ulf Hansson
Acked-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
04 Aug, 2021
1 commit
-
This WARN can be triggered per-core and the stack trace is not useful.
Replace it with plain dev_err(). Fix a comment while at it.Signed-off-by: Michał Mirosław
Signed-off-by: Viresh Kumar
18 Jun, 2021
1 commit
-
Don't limit required_opp_table to genpd only. One possible use case is
cpufreq based devfreq governor, which can use required-opps property to
derive devfreq from cpufreq.Though the OPP core still doesn't support non-genpd required-opps in
_set_required_opps().Suggested-by: Chanwoo Choi
Signed-off-by: Hsin-Yi Wang
[ Viresh: Update _set_required_opps() to check for genpd ]
Signed-off-by: Viresh Kumar
20 May, 2021
1 commit
-
Using list_del_init() instead of list_del() + INIT_LIST_HEAD()
to simpify the code.Signed-off-by: Yang Yingliang
Signed-off-by: Viresh Kumar
15 Mar, 2021
1 commit
-
Add devres wrapper for dev_pm_opp_of_add_table() to simplify drivers
code.Signed-off-by: Yangtao Li
Signed-off-by: Dmitry Osipenko
Signed-off-by: Viresh Kumar
02 Feb, 2021
6 commits
-
The OPP core currently requires the required opp tables to be available
before the dependent OPP table is added, as it needs to create links
from the dependent OPP table to the required ones. This may not be
convenient for all the platforms though, as this requires strict
ordering for probing the drivers.This patch allows lazy-linking of the required-opps. The OPP tables for
which the required-opp-tables aren't available at the time of their
initialization, are added to a special list of OPP tables:
lazy_opp_tables. Later on, whenever a new OPP table is registered with
the OPP core, we check if it is required by an OPP table in the pending
list; if yes, then we complete the linking then and there.An OPP table is marked unusable until the time all its required-opp
tables are available. And if lazy-linking fails for an OPP table, the
OPP core disables all of its OPPs to make sure no one can use them.Tested-by: Hsin-Yi Wang
Signed-off-by: Viresh Kumar -
Print OPP level in debug message of _opp_add_static_v2(). This helps to
chase GENPD bugs.Tested-by: Peter Geis
Tested-by: Nicolas Chauvet
Tested-by: Matt Merhar
Signed-off-by: Dmitry Osipenko
Signed-off-by: Viresh Kumar -
A few drivers have device's clk but they don't want the OPP core to
handle that. Add a new helper for them, dev_pm_opp_of_add_table_noclk().Signed-off-by: Viresh Kumar
Tested-by: Dmitry Osipenko -
We acquire the clk at the time the OPP table is allocated, though it
works fine, it is not the best place to do so. One of the main reason
being we may need to acquire it again from dev_pm_opp_set_clkname() if
the platform wants another clock to be acquired instead.There is also requirement from some of the platforms where they do not
want the OPP core to manage the clock at all.This patch hence defers acquiring the clk until the time we are certain
about which clk we need to acquire and if we really need to acquire one.
With this commit, the clk will get acquired either from
dev_pm_opp_set_clkname() or while we initialize the OPPs within the
table.Signed-off-by: Viresh Kumar
Tested-by: Dmitry Osipenko -
The implementation of dev_pm_opp_of_add_table() and
dev_pm_opp_of_add_table_indexed() are almost identical. Create
_of_add_table_indexed() to reduce code redundancy.Also remove the duplication of the doc style comments by referring to
dev_pm_opp_of_add_table() from dev_pm_opp_of_add_table_indexed().Signed-off-by: Viresh Kumar
Tested-by: Dmitry Osipenko -
The debug message always prints rate=0 instead of a proper value, fix it.
Fixes: 6c591eec67cb ("OPP: Add helpers for reading the binding properties")
Tested-by: Peter Geis
Tested-by: Nicolas Chauvet
Tested-by: Matt Merhar
Signed-off-by: Dmitry Osipenko
[ Viresh: Added Fixes tag ]
Signed-off-by: Viresh Kumar
15 Dec, 2020
1 commit
-
* pm-cpufreq: (31 commits)
cpufreq: Fix cpufreq_online() return value on errors
cpufreq: Fix up several kerneldoc comments
cpufreq: stats: Use local_clock() instead of jiffies
cpufreq: schedutil: Simplify sugov_update_next_freq()
cpufreq: intel_pstate: Simplify intel_cpufreq_update_pstate()
cpufreq: arm_scmi: Discover the power scale in performance protocol
firmware: arm_scmi: Add power_scale_mw_get() interface
cpufreq: tegra194: Rename tegra194_get_speed_common function
cpufreq: tegra194: Remove unnecessary frequency calculation
cpufreq: tegra186: Simplify cluster information lookup
cpufreq: tegra186: Fix sparse 'incorrect type in assignment' warning
cpufreq: imx: fix NVMEM_IMX_OCOTP dependency
cpufreq: vexpress-spc: Add missing MODULE_ALIAS
cpufreq: scpi: Add missing MODULE_ALIAS
cpufreq: loongson1: Add missing MODULE_ALIAS
cpufreq: sun50i: Add missing MODULE_DEVICE_TABLE
cpufreq: st: Add missing MODULE_DEVICE_TABLE
cpufreq: qcom: Add missing MODULE_DEVICE_TABLE
cpufreq: mediatek: Add missing MODULE_DEVICE_TABLE
cpufreq: highbank: Add missing MODULE_DEVICE_TABLE
...
09 Dec, 2020
3 commits
-
The opp binding now allows to have an empty opp table and shared-opp to
still describe that devices share v/f lines.When initialising an empty opp table, allow such case by:
- treating such conditions with warnings in place of errors
- don't fail on empty tableSigned-off-by: Nicola Mazzucato
Signed-off-by: Viresh Kumar -
It has been found that some users (like cpufreq-dt and others on LKML)
have abused the helper dev_pm_opp_get_opp_table() to create the OPP
table instead of just finding it, which is the wrong thing to do. This
routine was meant for OPP core's internal working and exposed the whole
functionality by mistake.Change the scope of dev_pm_opp_get_opp_table() to only finding the
table. The internal helpers _opp_get_opp_table*() are thus renamed to
_add_opp_table*(), dev_pm_opp_get_opp_table_indexed() is removed (as we
don't need the index field for finding the OPP table) and so the only
user, genpd, is updated.Note that the prototype of _add_opp_table() was already left in opp.h by
mistake when it was removed earlier and so we weren't required to add it
now.Acked-by: Ulf Hansson
Signed-off-by: Viresh Kumar
11 Nov, 2020
1 commit
-
There are different platforms and devices which might use different scale
for the power values. Kernel sub-systems might need to check if all
Energy Model (EM) devices are using the same scale. Address that issue and
store the information inside EM for each device. Thanks to that they can
be easily compared and proper action triggered.Suggested-by: Daniel Lezcano
Reviewed-by: Quentin Perret
Signed-off-by: Lukasz Luba
Signed-off-by: Rafael J. Wysocki
06 Nov, 2020
1 commit
-
There is no critical section which needs protection with locks while
allocating an OPP table, except while adding it to the opp_tables list.
And taking the opp_table_lock for the entire duration causes circular
dependency issues like the one mentioned below. This patch takes
another approach to reduce the size of the critical section to avoid
such issues, the details of that are present within the patch.======================================================
WARNING: possible circular locking dependency detected
5.4.72 #14 Not tainted
------------------------------------------------------
chrome/1865 is trying to acquire lock:
ffffffdd34921750 (opp_table_lock){+.+.}, at: _find_opp_table+0x34/0x74but task is already holding lock:
ffffff81f0fc71a8 (reservation_ww_class_mutex){+.+.}, at: submit_lock_objects+0x70/0x1ecfscrypt: AES-256-CTS-CBC using implementation "cts-cbc-aes-ce"
which lock already depends on the new lock.the existing dependency chain (in reverse order) is:
-> #4 (reservation_ww_class_mutex){+.+.}:
__mutex_lock_common+0xec/0xc0c
ww_mutex_lock_interruptible+0x5c/0xc4
msm_gem_fault+0x2c/0x124
__do_fault+0x40/0x16c
handle_mm_fault+0x7cc/0xd98
do_page_fault+0x230/0x3b4
do_translation_fault+0x5c/0x78
do_mem_abort+0x4c/0xb4
el0_da+0x1c/0x20
-> #3 (&mm->mmap_sem){++++}:
__might_fault+0x70/0x98
compat_filldir+0xf8/0x48c
dcache_readdir+0x70/0x1dc
iterate_dir+0xd4/0x180
__arm64_compat_sys_getdents+0xa0/0x19c
el0_svc_common+0xa8/0x178
el0_svc_compat_handler+0x2c/0x40
el0_svc_compat+0x8/0x10
-> #2 (&sb->s_type->i_mutex_key#3){++++}:
down_write+0x54/0x16c
start_creating+0x68/0x128
debugfs_create_dir+0x28/0x114
opp_debug_register+0x8c/0xc0
_add_opp_dev_unlocked+0x5c/0x70
_add_opp_dev+0x38/0x58
_opp_get_opp_table+0xdc/0x1ac
dev_pm_opp_get_opp_table_indexed+0x24/0x30
dev_pm_opp_of_add_table_indexed+0x48/0x84
of_genpd_add_provider_onecell+0xc0/0x1b8
rpmhpd_probe+0x240/0x268
platform_drv_probe+0x90/0xb0
really_probe+0x134/0x2ec
driver_probe_device+0x64/0xfc
__device_attach_driver+0x8c/0xa4
bus_for_each_drv+0x90/0xd8
__device_attach+0xc0/0x148
device_initial_probe+0x20/0x2c
bus_probe_device+0x34/0x94
device_add+0x1fc/0x3b0
of_device_add+0x3c/0x4c
of_platform_device_create_pdata+0xb8/0xfc
of_platform_bus_create+0x1e4/0x368
of_platform_populate+0x70/0xbc
devm_of_platform_populate+0x58/0xa0
rpmh_rsc_probe+0x36c/0x3cc
platform_drv_probe+0x90/0xb0
really_probe+0x134/0x2ec
driver_probe_device+0x64/0xfc
__device_attach_driver+0x8c/0xa4
bus_for_each_drv+0x90/0xd8
__device_attach+0xc0/0x148
device_initial_probe+0x20/0x2c
bus_probe_device+0x34/0x94
device_add+0x1fc/0x3b0
of_device_add+0x3c/0x4c
of_platform_device_create_pdata+0xb8/0xfc
of_platform_bus_create+0x1e4/0x368
of_platform_bus_create+0x230/0x368
of_platform_populate+0x70/0xbc
of_platform_default_populate_init+0xa8/0xc0
do_one_initcall+0x1c8/0x3fc
do_initcall_level+0xb4/0x10c
do_basic_setup+0x30/0x48
kernel_init_freeable+0x124/0x1a4
kernel_init+0x14/0x104
ret_from_fork+0x10/0x18
-> #1 (&opp_table->lock){+.+.}:
__mutex_lock_common+0xec/0xc0c
mutex_lock_nested+0x40/0x50
_add_opp_dev+0x2c/0x58
_opp_get_opp_table+0xdc/0x1ac
dev_pm_opp_get_opp_table_indexed+0x24/0x30
dev_pm_opp_of_add_table_indexed+0x48/0x84
of_genpd_add_provider_onecell+0xc0/0x1b8
rpmhpd_probe+0x240/0x268
platform_drv_probe+0x90/0xb0
really_probe+0x134/0x2ec
driver_probe_device+0x64/0xfc
__device_attach_driver+0x8c/0xa4
bus_for_each_drv+0x90/0xd8
__device_attach+0xc0/0x148
device_initial_probe+0x20/0x2c
bus_probe_device+0x34/0x94
device_add+0x1fc/0x3b0
of_device_add+0x3c/0x4c
of_platform_device_create_pdata+0xb8/0xfc
of_platform_bus_create+0x1e4/0x368
of_platform_populate+0x70/0xbc
devm_of_platform_populate+0x58/0xa0
rpmh_rsc_probe+0x36c/0x3cc
platform_drv_probe+0x90/0xb0
really_probe+0x134/0x2ec
driver_probe_device+0x64/0xfc
__device_attach_driver+0x8c/0xa4
bus_for_each_drv+0x90/0xd8
__device_attach+0xc0/0x148
device_initial_probe+0x20/0x2c
bus_probe_device+0x34/0x94
device_add+0x1fc/0x3b0
of_device_add+0x3c/0x4c
of_platform_device_create_pdata+0xb8/0xfc
of_platform_bus_create+0x1e4/0x368
of_platform_populate+0x70/0xbc
devm_of_platform_populate+0x58/0xa0
rpmh_rsc_probe+0x36c/0x3cc
platform_drv_probe+0x90/0xb0
really_probe+0x134/0x2ec
driver_probe_device+0x64/0xfc
__device_attach_driver+0x8c/0xa4
bus_for_each_drv+0x90/0xd8
__device_attach+0xc0/0x148
device_initial_probe+0x20/0x2c
bus_probe_device+0x34/0x94
device_add+0x1fc/0x3b0
of_device_add+0x3c/0x4c
of_platform_device_create_pdata+0xb8/0xfc
of_platform_bus_create+0x1e4/0x368
of_platform_bus_create+0x230/0x368
of_platform_populate+0x70/0xbc
of_platform_default_populate_init+0xa8/0xc0
do_one_initcall+0x1c8/0x3fc
do_initcall_level+0xb4/0x10c
do_basic_setup+0x30/0x48
kernel_init_freeable+0x124/0x1a4
kernel_init+0x14/0x104
ret_from_fork+0x10/0x18
-> #0 (opp_table_lock){+.+.}:
__lock_acquire+0xee4/0x2450
lock_acquire+0x1cc/0x210
__mutex_lock_common+0xec/0xc0c
mutex_lock_nested+0x40/0x50
_find_opp_table+0x34/0x74
dev_pm_opp_find_freq_exact+0x2c/0xdc
a6xx_gmu_resume+0xc8/0xecc
a6xx_pm_resume+0x148/0x200
adreno_resume+0x28/0x34
pm_generic_runtime_resume+0x34/0x48
__rpm_callback+0x70/0x10c
rpm_callback+0x34/0x8c
rpm_resume+0x414/0x550
__pm_runtime_resume+0x7c/0xa0
msm_gpu_submit+0x60/0x1c0
msm_ioctl_gem_submit+0xadc/0xb60
drm_ioctl_kernel+0x9c/0x118
drm_ioctl+0x27c/0x408
drm_compat_ioctl+0xcc/0xdc
__se_compat_sys_ioctl+0x100/0x206c
__arm64_compat_sys_ioctl+0x20/0x2c
el0_svc_common+0xa8/0x178
el0_svc_compat_handler+0x2c/0x40
el0_svc_compat+0x8/0x10
other info that might help us debug this:
Chain exists of: opp_table_lock --> &mm->mmap_sem --> reservation_ww_class_mutex
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(reservation_ww_class_mutex);
lock(&mm->mmap_sem);
lock(reservation_ww_class_mutex);
lock(opp_table_lock);*** DEADLOCK ***
3 locks held by chrome/1865:
#0: ffffff81edecc0d8 (&dev->struct_mutex){+.+.}, at: msm_ioctl_gem_submit+0x264/0xb60
#1: ffffff81d0000870 (reservation_ww_class_acquire){+.+.}, at: msm_ioctl_gem_submit+0x8e8/0xb60
#2: ffffff81f0fc71a8 (reservation_ww_class_mutex){+.+.}, at: submit_lock_objects+0x70/0x1ec
stack backtrace:
CPU: 0 PID: 1865 Comm: chrome Not tainted 5.4.72 #14
Hardware name: Google Lazor (rev1+) with LTE (DT)
Call trace:
dump_backtrace+0x0/0x158
show_stack+0x20/0x2c
dump_stack+0xc8/0x160
print_circular_bug+0x2c4/0x2c8
check_noncircular+0x1a8/0x1b0
__lock_acquire+0xee4/0x2450
lock_acquire+0x1cc/0x210
__mutex_lock_common+0xec/0xc0c
mutex_lock_nested+0x40/0x50
_find_opp_table+0x34/0x74
dev_pm_opp_find_freq_exact+0x2c/0xdc
a6xx_gmu_resume+0xc8/0xecc
a6xx_pm_resume+0x148/0x200
adreno_resume+0x28/0x34
pm_generic_runtime_resume+0x34/0x48
__rpm_callback+0x70/0x10c
rpm_callback+0x34/0x8c
rpm_resume+0x414/0x550
__pm_runtime_resume+0x7c/0xa0
msm_gpu_submit+0x60/0x1c0
msm_ioctl_gem_submit+0xadc/0xb60
drm_ioctl_kernel+0x9c/0x118
drm_ioctl+0x27c/0x408
drm_compat_ioctl+0xcc/0xdc
__se_compat_sys_ioctl+0x100/0x206c
__arm64_compat_sys_ioctl+0x20/0x2c
el0_svc_common+0xa8/0x178
el0_svc_compat_handler+0x2c/0x40
el0_svc_compat+0x8/0x10Reported-by: Rob Clark
Signed-off-by: Viresh Kumar
27 Oct, 2020
1 commit
-
The patch missed returning 0 early in case of success and hence the
static OPPs got removed by mistake. Fix it.Fixes: 90d46d71cce2 ("opp: Handle multiple calls for same OPP table in _of_add_opp_table_v1()")
Reported-by: Aisheng Dong
Signed-off-by: Viresh Kumar
Tested-by: Dong Aisheng
16 Sep, 2020
4 commits
-
The DT bindings don't put such a constraint, nor should the kernel. It
is perfectly fine for opp-level to be set to 0, if we need to put the
performance state votes for a domain for a particular OPP.Reported-by: Stephan Gerhold
Tested-by: Stephan Gerhold
Signed-off-by: Viresh Kumar -
The bindings allow multiple versions to be passed to "opp-supported-hw"
property, either of which can result in enabling of the OPP.Update code to allow that.
Tested-by: Stephan Gerhold
Tested-by: Dmitry Osipenko
Signed-off-by: Viresh Kumar -
Until now for V1 OPP bindings we used to call
dev_pm_opp_of_cpumask_add_table() first and then
dev_pm_opp_set_sharing_cpus() in the cpufreq-dt driver.A later patch will though update the cpufreq-dt driver to optimize the
code a bit and we will call dev_pm_opp_set_sharing_cpus() first followed
by dev_pm_opp_of_cpumask_add_table(), which doesn't work well today as
it tries to re parse the OPP entries. This should work nevertheless for
V1 bindings as the same works for V2 bindings.Adapt the same approach from V2 bindings and fix this.
Reported-by: Marek Szyprowski
Tested-by: Marek Szyprowski
Signed-off-by: Viresh Kumar
25 Aug, 2020
1 commit
-
The OPP core manages various resources, e.g. clocks or interconnect paths.
These resources are looked up when the OPP table is allocated once
dev_pm_opp_get_opp_table() is called the first time (either directly
or indirectly through one of the many helper functions).At this point, the resources may not be available yet, i.e. looking them
up will result in -EPROBE_DEFER. Unfortunately, dev_pm_opp_get_opp_table()
is currently unable to propagate this error code since it only returns
the allocated OPP table or NULL.This means that all consumers of the OPP core are required to make sure
that all necessary resources are available. Usually this happens by
requesting them, checking the result and releasing them immediately after.For example, we have added "dev_pm_opp_of_find_icc_paths(dev, NULL)" to
several drivers now just to make sure the interconnect providers are
ready before the OPP table is allocated. If this call is missing,
the OPP core will only warn about this and then attempt to continue
without interconnect. This will eventually fail horribly, e.g.:cpu cpu0: _allocate_opp_table: Error finding interconnect paths: -517
... later ...
of: _read_bw: Mismatch between opp-peak-kBps and paths (1 0)
cpu cpu0: _opp_add_static_v2: opp key field not found
cpu cpu0: _of_add_opp_table_v2: Failed to add OPP, -22This example happens when trying to use interconnects for a CPU OPP
table together with qcom-cpufreq-nvmem.c. qcom-cpufreq-nvmem calls
dev_pm_opp_set_supported_hw(), which ends up allocating the OPP table
early. To fix the problem with the current approach we would need to add
yet another call to dev_pm_opp_of_find_icc_paths(dev, NULL).
But actually qcom-cpufreq-nvmem.c has nothing to do with interconnects...This commit attempts to make this more robust by allowing
dev_pm_opp_get_opp_table() to return an error pointer. Fixing all
the usages is trivial because the function is usually used indirectly
through another helper (e.g. dev_pm_opp_set_supported_hw() above).
These other helpers already return an error pointer.The example above then works correctly because set_supported_hw() will
return -EPROBE_DEFER, and qcom-cpufreq-nvmem.c already propagates that
error. It should also be possible to remove the remaining usages of
"dev_pm_opp_of_find_icc_paths(dev, NULL)" from other drivers as well.Note that this commit currently only handles -EPROBE_DEFER for the
clock/interconnects within _allocate_opp_table(). Other errors are just
ignored as before. Eventually those should be propagated as well.Signed-off-by: Stephan Gerhold
Acked-by: Krzysztof Kozlowski
Reviewed-by: Ulf Hansson
[ Viresh: skip checking return value of dev_pm_opp_get_opp_table() for
EPROBE_DEFER in domain.c, fix NULL return value and reorder
code a bit in core.c, and update exynos-asv.c ]
Signed-off-by: Viresh Kumar
24 Aug, 2020
1 commit
-
Remove the unnecessary wrapper and merge
_dev_pm_opp_find_and_remove_table() with dev_pm_opp_remove_table().Tested-by: Rajendra Nayak
Signed-off-by: Viresh Kumar
03 Aug, 2020
1 commit
-
* pm-em:
OPP: refactor dev_pm_opp_of_register_em() and update related drivers
Documentation: power: update Energy Model description
PM / EM: change name of em_pd_energy to em_cpu_energy
PM / EM: remove em_register_perf_domain
PM / EM: add support for other devices than CPUs in Energy Model
PM / EM: update callback structure and add device pointer
PM / EM: introduce em_dev_register_perf_domain function
PM / EM: change naming convention from 'capacity' to 'performance'* pm-core:
mmc: jz4740: Use pm_ptr() macro
PM: Make *_DEV_PM_OPS macros use __maybe_unused
PM: core: introduce pm_ptr() macro
16 Jul, 2020
1 commit
-
Currently, when using _of_add_opp_table_v2 parsed_static_opps is
increased and this value is used in _opp_remove_all_static() to
check if there are static opp entries that need to be freed.
Unfortunately this does not happen when using _of_add_opp_table_v1(),
which leads to warnings.This patch increases parsed_static_opps in _of_add_opp_table_v1() in a
similar way as in _of_add_opp_table_v2().Fixes: 03758d60265c ("opp: Replace list_kref with a local counter")
Cc: v5.6+ # v5.6+
Signed-off-by: Walter Lozano
[ Viresh: Do the operation with lock held and set the value to 1 instead
of incrementing it ]
Signed-off-by: Viresh Kumar
24 Jun, 2020
2 commits
-
The Energy Model framework supports not only CPU devices. Drop the CPU
specific interface with cpumask and add struct device. Add also a return
value, user might use it. This new interface provides easy way to create
a simple Energy Model, which then might be used by e.g. thermal subsystem.Acked-by: Daniel Lezcano
Signed-off-by: Lukasz Luba
Signed-off-by: Rafael J. Wysocki -
The Energy Model framework is going to support devices other that CPUs. In
order to make this happen change the callback function and add pointer to
a device as an argument.Update the related users to use new function and new callback from the
Energy Model.Acked-by: Quentin Perret
Signed-off-by: Lukasz Luba
Acked-by: Daniel Lezcano
Signed-off-by: Rafael J. Wysocki
01 Jun, 2020
1 commit
-
The DT node of the device may contain interconnect paths while the OPP
table doesn't have the bandwidth values. There is no need to parse the
paths in such cases.Signed-off-by: Sibi Sankar
Tested-by: Sibi Sankar
Reviewed-by: Sibi Sankar
[ Viresh: Support the case of !opp_table and massaged changelog ]
Signed-off-by: Viresh Kumar
29 May, 2020
2 commits
-
When we read the OPP keys, it would be nice to do some sanity checks
of the values we get from DT and see if they match with the information
that is populated in the OPP table. Let's pass a pointer of the table,
so that we can do some validation.Signed-off-by: Georgi Djakov
Reviewed-by: Matthias Kaehlcke
Reviewed-by: Sibi Sankar
[ Viresh: Fix rebase conflicts ]
Signed-off-by: Viresh Kumar -
The OPP bindings now support bandwidth values, so add support to parse it
from device tree and store it into the new dev_pm_opp_icc_bw struct, which
is part of the dev_pm_opp.Signed-off-by: Georgi Djakov
Reviewed-by: Matthias Kaehlcke
[ Viresh: Create _read_bw() and use it, renamed _of_find_icc_paths() to
dev_pm_opp_of_find_icc_paths(), exported it and made opp_table
argument optional. Also drop the depends on from Kconfig. ]
Signed-off-by: Viresh Kumar
13 May, 2020
1 commit
-
The opp-hz DT property is not mandatory and we may use another property
as a key in the OPP table. Add helper functions to simplify the reading
and comparing the keys.Signed-off-by: Saravana Kannan
Signed-off-by: Georgi Djakov
Reviewed-by: Matthias Kaehlcke
Reviewed-by: Sibi Sankar
[ Viresh: Removed an unnecessary comment ]
Signed-off-by: Viresh Kumar
10 Dec, 2019
2 commits
-
A kref or refcount isn't the right tool to be used here for counting
number of devices that are sharing the static OPPs created for the OPP
table. For example, we are reinitializing the kref again, after it
reaches a value of 0 and frees the resources, if the static OPPs get
added for the same OPP table structure (as the OPP table structure was
never freed). That is messy and very unclear.This patch makes parsed_static_opps an unsigned integer and uses it to
count the number of users of the static OPPs. The increment and
decrement to parsed_static_opps is done under opp_table->lock now to
make sure no races are possible if the OPP table is getting added and
removed in parallel (which doesn't happen in practice, but can in
theory).Signed-off-by: Viresh Kumar
-
The static OPPs aren't getting freed properly, if errors occur while
adding them. Fix that by calling _put_opp_list_kref() and putting their
reference on failures.Fixes: 11e1a1648298 ("opp: Don't decrement uninitialized list_kref")
Signed-off-by: Viresh Kumar
23 Oct, 2019
1 commit
-
The list_kref reaches a count of 0 when all the static OPPs are removed,
for example when dev_pm_opp_of_cpumask_remove_table() is called, though
the actual OPP table may not get freed as it may still be referenced by
other parts of the kernel, like from a call to
dev_pm_opp_set_supported_hw(). And if we call
dev_pm_opp_of_cpumask_add_table() again at this point, we must
reinitialize the list_kref otherwise the kernel will hit a WARN() in
kref infrastructure for incrementing a kref with value 0.Fixes: 11e1a1648298 ("opp: Don't decrement uninitialized list_kref")
Reported-by: Dmitry Osipenko
Tested-by: Dmitry Osipenko
Signed-off-by: Viresh Kumar
10 Oct, 2019
1 commit
-
_find_opp_of_np() doesn't traverse the list of OPP tables but instead
just the entries within an OPP table and so only requires to lock the
OPP table itself.The lockdep_assert_held() was added there by mistake and isn't really
required.Fixes: 5d6d106fa455 ("OPP: Populate required opp tables from "required-opps" property")
Cc: v5.0+ # v5.0+
Reported-by: Niklas Cassel
Signed-off-by: Viresh Kumar
26 Jul, 2019
1 commit
-
With property "opp-supported-hw" introduced, the OPP table
in DT could be a large OPP table and ONLY a subset of OPPs
are available, based on the version of the hardware running
on. That introduces restriction of using "opp-suspend"
property to define the suspend OPP, as we are NOT sure if the
OPP containing "opp-suspend" property is available for the
hardware running on, and the of opp core does NOT allow multiple
suspend OPPs defined in DT OPP table.To eliminate this restrition, make of opp core allow multiple
suspend OPPs defined in DT, and pick the OPP with highest rate
and with "opp-suspend" property present to be suspend OPP, it
can speed up the suspend/resume process.Signed-off-by: Anson Huang
Signed-off-by: Viresh Kumar
