Previous implementation lacks of documentation and it's hard to
understand the effect of changing specific tunable parameter.
Revise the implementation so that the scaling behavior is somehow
aligned with the tegra_wmark governor supported by the actmon. The
only different is that nvhost_podgov governor is polling-based DFS
algorithm and it maintaines the moving average load in the governor
instead of hardware itself.
Bug 4892068
Change-Id: I033cb1359a484d4c9433fa4f2e7a99c42cb636b3
Signed-off-by: Johnny Liu <johnliu@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3315446
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Rajesh Devaraj <rdevaraj@nvidia.com>
Since K519+, frequency table and max_state information is stored in the
devfreq struct directly, not in the devfreq_dev_profile struct. Use
nvidia conftest to conditionally build the governor and choose the
correct data structure for accessing the information.
Kernel build won't complain anything when build the governor, but when
the devfreq driver (e.g. nvgpu) trying to add the devfreq device
with the nvhost_pogdov governor, it will fail to add the devfreq
device since the frequency table information is NULL in the
devfreq_dev_profile and the governor use the wrong information.
Bug 4883576
Change-Id: I885bc4ceac885eea5644416b6eacefbbea523a2b
Signed-off-by: Johnny Liu <johnliu@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3229870
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: svcacv <svcacv@nvidia.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Some distros might use old kernel source but with some latest upstream
kernel patches backported to their kernel source tree. To deal with this
scenario and avoid kernel compilation failure, use conftest to check the
existence of features against the kernel source tree which the OOT
modules are built upon and do the conditional build based on the test
result generated with the conftest tool.
Use NV_DEVFREQ_HAS_FREQ_TABLE to determine whether freq_table field is
there in struct devfreq data strcuture, and choose the correct path for
building the module.
Use tegra_wmark-specific devfreq_get_freq_range always to avoid kernel
version check and conftest check. Since devfreq_get_freq_range exists in
the devfreq-specific governor.h (e.g. drivers/devfreq/governor.h) file
instead of globabl linux kernel include header files
(e.g. include/linux/devfreq.h), conftest cannot be used to the existence
of devfreq_get_freq_range kernel function.
Bug 4884092
Change-Id: I5bde4c712f59f38de74c1d8d95135c9b25d621b1
Signed-off-by: Johnny Liu <johnliu@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3220896
(cherry picked from commit c580fd0d06)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3220970
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Since K519, devfreq takes the priority of devfreq_dev_profile to save
the frequency table information and the number of frequency steps.
Therefore, change the implementation of tegra_wmark devfreq governor to
use devfreq to access the frequency table information and the nubmer of
frequency steps instead of devfreq_dev_profile.
Bug 4288411
Signed-off-by: Johnny Liu <johnliu@nvidia.com>
Change-Id: Ib0affdcc8913642167cd82d45d014c46b51a8c38
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2980425
Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
When devfreq_suspend_device get called, tegra_wmark will disable the
upper and lower watermark thresholds so that no DFS logic get triggered
after the suspension.
When devfreq_resume_device get called, tegra_wmark will enable back the
upper and lower watermark thresholds so that interrupt-driven DFS logic
can work properly.
Bug 4168788
Signed-off-by: Johnny Liu <johnliu@nvidia.com>
Change-Id: I98fa1487db26fdfe95f5c958dbe15bf0f49035d5
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2927019
Reviewed-by: svcacv <svcacv@nvidia.com>
Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
The tegra_wmark governor can be used e.g. with DRM clients, such as VIC,
NVDEC, NVENC, and NVJPG. This governor tightly collaborates with the
actmon hardware used for monitoring the active time of the underlying
DRM clients.
Bug 3788919
Signed-off-by: Johnny Liu <johnliu@nvidia.com>
Change-Id: Ie4d4c2b173615aa239436fbb1545118435629d38
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2894529
Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Remove the config variables as there is no Kconfig to define
these configs:
CONFIG_DEVFREQ_GOV_WMARK_SIMPLE
CONFIG_DEVFREQ_GOV_WMARK_ACTIVE
Remove the handling of non-module build as devfreq is always
build as module.
Remove the wmark-related devfreq governors as we plan to keep
them under drivers/gpu/drm/tegra. They are tightly bound with
the actmon and drm drivers.
Bug 4074863
Signed-off-by: Johnny Liu <johnliu@nvidia.com>
Change-Id: Iba8f5da770d86ddcfb6315f72fd74fc9a781ab39
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2893701
Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Currently the pod v2 governor only supports kernel upto Linux v6.0. Now
that Linux v6.2-rc2 we can enable support for this kernel by ensuring
that the definitions and functions defined in the governor_v2.h are
compatible with upstream.
Note that by enabling support for v6.2 kernels, we want to allow the
driver to be built for all v6.2.x kernels and not just v6.2.0. So enable
building the driver for all kernels less than v6.3.0.
Bug 3820317
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Change-Id: I3087c660c9cd7d4aac016d5e9c8d9a089eea368c
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2836690
(cherry picked from commit 7f73ecbdf7d78ae6f61234374706a24bda73e079)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2837247
Reviewed-by: svc_kernel_abi <svc_kernel_abi@nvidia.com>
Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Currently the pod v2 governor only supports kernel upto Linux v6.0.
Now that Linux v6.1-rc1 is released we can enable support for Linux v6.1
by ensuring that the definitions and functions defined in the
governor_v2.h are compatible with upstream.
Bug 3835208
Change-Id: I028346f2ac2c0f8e5c08b75e91355a719803e999
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2793480
Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Currently the pod v2 governor only supports kernel upto Linux v5.19.
Now that Linux v6.0-rc2 we can enable support for this kernel by
ensuring that the definitions and functions defined in the governor_v2.h
are compatible with upstream.
Bug 3767126
Change-Id: I18c055bd8c8c963130921993522aaf52bdc5ec99
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2772878
Reviewed-by: Bibek Basu <bbasu@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Currently the pod v2 governor only supports kernel upto Linux v5.17. Now
that Linux v5.19-rc2 we can enable support for this kernel by ensuring
that the definitions and functions defined in the governor_v2.h are
compatible with upstream.
JIRA LS-418
Bug 3674235
Change-Id: I3a42290e5207163b82dea8a13d11bfa6decb8317
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2728508
Reviewed-by: Bibek Basu <bbasu@nvidia.com>
Reviewed-by: svc_kernel_abi <svc_kernel_abi@nvidia.com>
GVS: Gerrit_Virtual_Submit
Fix the following CERT-C Violations:
governor_pod_scaling_v2.c : CERT ERR33-C
The violations occur due to non-verification of the snprintf
return values.
Adding WARN_ON statements to verify the return values.
CID 378002
CID 391305
CID 442828
CID 443110
Bug 3512546
Signed-off-by: Jinesh Parakh <jparakh@nvidia.com>
Change-Id: I91c35ecce9348d4f7127eafa603d2b8c2391ba18
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2723684
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
governor_pod_scaling_v2 will be provided as a kernel module in future
NVIDIA software deliverables for Linux platforms. As of this moment, the
function that returns the range of the device's scaling frequency hasn't
been exposed from Linux kernel for modules to call. A similar function
is implemented in the governor_pod_scaling_v2, but this function cannot
get the frequency constraints put through the PM QOS interface due to
the same reason, lack of kernel API function. An upstream kernel patch
has been proposed by the power management maintainer to provide the
function needed by governor_pod_scaling_v2, but it's not in any release
kernel yet. For now, PM QOS support is removed from
governor_pod_scaling_v2 and it will be added back when the upstream
kernel patch is available in kernel releases.
drivers_devfreq_governor_5_14.h is a copy of drivers/devfreq/governor.h
of Linux kernel 5.14. Having this copy is to avoid introducing the
dependency on Linux source for building the podgov as external module.
JIRA ID: LS-418
Signed-off-by: Peng Liu <pengliu@nvidia.com>
Change-Id: I0c70acf5679fed53f30bc3ba7c01ea571036cc5e
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2638232
Reviewed-by: svc_kernel_abi <svc_kernel_abi@nvidia.com>
Reviewed-by: Vijayakumar Subbu <vsubbu@nvidia.com>
Reviewed-by: Jonathan Hunter <jonathanh@nvidia.com>
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
Reviewed-by: svc-mobile-cert <svc-mobile-cert@nvidia.com>
GVS: Gerrit_Virtual_Submit
Introduce DEVFREQ_GOV_POD_SCALING_V2 for podgov
governor implementation on kernel-5.9 and later
version to address major changes in upstream
devfreq framework.
1. devfreq framework uses devm_pm_qos to store
"min/max frequency request from user-space",
which caused 'min_freq' & 'max_freq' field
in struct devfreq have been removed.
2. DEVFREQ_GOV_INTERVAL renamed as DEVFREQ_GOV_UPDATE_INTERVAL, and
devfreq_interval_update() renamed as devfreq_update_interval()
3. return type of debugfs_create_u32() changed to void
Bug 200639056
Change-Id: I673ae3ac6b55b26766253ae0f1aeba181e2e0b53
Signed-off-by: Aaron Tian <atian@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2400108
Reviewed-by: automaticguardword <automaticguardword@nvidia.com>
Reviewed-by: Bitan Biswas <bbiswas@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
GVS: Gerrit_Virtual_Submit
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
While the device is active, devfreq calls into
podgov to set the device frequency based on the
device workload. When the device goes into
suspension, devfreq would do one last call into
podgov before going into suspension. However,
because podgov decides the frequency based on
the history of previous loads, if the load drops
suddenly (i.e. going from 100% to 0%), this last
call might result in the frequency set high and
kept high until devfreq resumes running.
In this change, podgov would check if the device
has been suspended, and if so, it would clear the
history and set the frequency to min freq before
suspending devfreq. As a result, whenever the
device is suspended, its frequency will be set to
min freq.
Bug 200613859
Change-Id: I1ad2fd563407d53177a84f8fddbf47b699fa97b5
Signed-off-by: Mary Do <mdo@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2358085
(cherry picked from commit 87aa75c4ecd60a13056e32a00876b48591a520ec)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2363435
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Reviewed-by: automaticguardword <automaticguardword@nvidia.com>
Reviewed-by: Winnie Hsu <whsu@nvidia.com>
Reviewed-by: Alex Waterman <alexw@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
GVS: Gerrit_Virtual_Submit
Modify T186/T210 VIC actmon driver and wmark_active governor
to address the following issues:
1. To let VIC actmon reports accurate VIC active
cycle counts, set static WEIGHT_COUNT in both
VIC actmon and VIC IP block. It ensures
VIC actmon can capture all activity signal
toggle event from VIC.
The value of WEIGHT_COUNT are equal to:
4 * (max VIC freq / VIC_actmon freq)
= 4 * (1024 / 19.2)
~= 213
2. Since VIC actmon reports active "VIC clock
cycle" instead of "VIC actmon clock cycle",
"relative loading translation" should consider
current VIC clock freq.
E.g.,
- sample_period = 80 us, VIC freq = 115.2 Mhz
- 9216 cycles represents 100% loading
(115.2 * 80)
3. Update upper/lower wmark settings after VIC
clock scaled completed, to ensure wmark settings
are equil to 0 ~ 100% loading of current freq.
- Register 'get_dev_status' instance in
devfreq_dev_profile, to let wmark active
governor can query current device freq.
- Register devfreq transition notifier in
wmark_active governor. It will query current
device freq. and update corresponding wmark
value after VIC freq. changed.
Bug 200501949
Change-Id: Ic159eb93fddc37d55b0c9649a3afcb50ed82cac2
Signed-off-by: Aaron Tian <atian@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/2200520
(cherry picked from commit d6c7740ea2ddd9d5087d938e9ee3b3bc2c9b6d0a)
Reviewed-on: https://git-master.nvidia.com/r/2263225
GVS: Gerrit_Virtual_Submit
Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
A circle buffer is introduced to store recent normalized GPU active
cycle counts. The highest value in this buffer marks the busiest
moment in recent history. When podgov decides next GPU freqeuncy, it
makes sure the new frequency level can satisfy the recent high work
load. This can be considered as an adaptive GPU frequency floor. This
feature can reduce stutter for certain use cases where work load
spikes occur without any temporal pattern, such as 4k video playback.
Bug 1963732
Change-Id: I70024f4d3ffb63425852e4f320eeffb6bc77c5e3
Signed-off-by: Peng Liu <pengliu@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/2114154
GVS: Gerrit_Virtual_Submit
Reviewed-by: Thomas Fleury <tfleury@nvidia.com>
Tested-by: Aaron Tian <atian@nvidia.com>
Reviewed-by: David Lock <dlock@nvidia.com>
Reviewed-by: Mubushir Rahman <mubushirr@nvidia.com>
Reviewed-by: Alex Waterman <alexw@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
GPU clock may change within the period of time defined by smooth. Thus
the result of averaging load percentages within smooth window has less
meanning. New method keeps track of active GPU cycle count per time
unit, and average load is average active cycle count divided by
current GPU clock (total cycle count per time unit).
Bug 1963732
Change-Id: I88cfb998f9bcfa0d6d0397f653f8e3096d4b3eed
Signed-off-by: Peng Liu <pengliu@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/2033266
Reviewed-by: Automatic_Commit_Validation_User
GVS: Gerrit_Virtual_Submit
Reviewed-by: Alex Waterman <alexw@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Add include path pointing to core kernel repository in order for the
drivers to include "governor.h" and possibly other local header files
from there.
Bug 2246029
Change-Id: Ic4e31e51c6ef6fa8b2f9ef6ce19e4ae87f90a1f3
Signed-off-by: Timo Alho <talho@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1774215
Reviewed-by: Bharat Nihalani <bnihalani@nvidia.com>
Some source files include header files using <> even though the header
file is not in a directory typically in the system include path. This
works when compiling the kernel with an O= option (which stores built
files outside the source tree) because the kernel adds various extra
source paths to the system include path. However, this doesn't happen when
building in-tree, so the source must be fixed to use "" for "local" files.
Similarly, fix one usage of "" where no path was specified in the ""
filename, whereas the header was in a relative directory to the source.
Again, with O= I believe this works because the kernel added the file's
location into the include path, but doesn't for in-tree builds.
Note: Parts of the original commit apply to source that has been moved
to linux-nvidia.git; see change Icf4f94b671e73c0a889bb996edc3f15d5fbde98b
for that part of the original rel-28 change.
Bug 1978388
Change-Id: I907c88a4822b309a33c031ec21dd215047ea3e94
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1544318
Reviewed-on: https://git-master.nvidia.com/r/1545674
Reviewed-on: https://git-master.nvidia.com/r/1546976
(cherry picked from linux-4.9 commit cc6281afdbe059734d53f54020f1ead0b5cf3659)
Reviewed-on: https://git-master.nvidia.com/r/1770153
Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Timo Alho <talho@nvidia.com>
Tested-by: Timo Alho <talho@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
The pod governor used to rely on being invoked from nvgpu on every
gk20_busy/idle() call. This was done originally for load-tracking
purposes. This change refactors the code to instead rely on devfreq's
internal polling loop for calling the governor periodically. It also
removes the idle timeout from the podgov code, since devfreq will keep
polling even when the GPU is idle.
Jira NVGPU-20
Change-Id: I767b74c250d199e3cd5f7e249a49736836a54c0d
Signed-off-by: Peter Boonstoppel <pboonstoppel@nvidia.com>
Reviewed-on: https://git-master/r/1484196
(cherry picked from linux-4.9 commit 5a0a5adcd0bd6fabbff9818ed6adba79cd8242ef)
Reviewed-on: https://git-master.nvidia.com/r/1770150
Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Timo Alho <talho@nvidia.com>
Tested-by: Timo Alho <talho@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
In nvhost_pod_estimate_freq(), we have *freq = 0
in case we decide to keep same frequency
In that case we set *freq as current frequency and
then set last_scale timestamp
This can result in keeping same frequency for
long duration due to less delta from last_scale
To fix this, return immediately in case *freq
is zero and do not set last_scale timestamp
Bug 200255163
Change-Id: Ie13bf54e2415c4016a101b9ea12a9abda83240fd
Signed-off-by: Deepak Nibade <dnibade@nvidia.com>
Reviewed-on: http://git-master/r/1265185
Reviewed-on: http://git-master/r/1506359
(cherry picked from linux-4.9 commit be5331c94ebe9044cb67e3f622db517bfb7e28d4)
Reviewed-on: https://git-master.nvidia.com/r/1770149
Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Timo Alho <talho@nvidia.com>
Tested-by: Timo Alho <talho@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
API scaling_state_check() returns 0 in case no change
in frequency is required
In nvhost_pod_estimate_freq(), we set *freq to 0
in case scaling_state_check() returns 0
And as a result of this, update_devfreq() will just
keep setting minimum frequency instead of keeping
same frequency - and this results in huge
performance degradation
To fix this, set *freq to current frequency in case
scaling_state_check() returns 0 as estimated
frequency
Bug 200255163
Change-Id: Ia8fe54dfd48b0898cc1dd53d821b1c95865b1f57
Signed-off-by: Deepak Nibade <dnibade@nvidia.com>
Reviewed-on: http://git-master/r/1261281
(cherry picked from linux-4.9 commit 624718566201ce9c0b9780be6f29dc2ae9082b09)
Reviewed-on: https://git-master.nvidia.com/r/1770146
Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Timo Alho <talho@nvidia.com>
Tested-by: Timo Alho <talho@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
In nvhost_pod_estimate_freq(), we return
GET_TARGET_FREQ_DONTSCALE if new frequency is same
as current frequency
And based on this return value, update_devfreq()
will just return without actually calling target()
function
But it is possible that target() function has freq
clipping of its own, and skipping target() itself
will break this
Hence in case we find new frequency same as current
frequency, do not return GET_TARGET_FREQ_DONTSCALE
Instead just return 0
Note that we still return GET_TARGET_FREQ_DONTSCALE
if governor itself is disabled, and this is
required in perf measurement cases
Bug 200245796
Change-Id: I55a3a344982c5b5441ba011cd0dd254947e89e5c
Signed-off-by: Deepak Nibade <dnibade@nvidia.com>
Reviewed-on: http://git-master/r/1251841
(cherry picked from linux-4.9 commit c6417ac88eb43501b8bf6d5351059ac2dadaf2c0)
Reviewed-on: https://git-master.nvidia.com/r/1770145
Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Timo Alho <talho@nvidia.com>
Tested-by: Timo Alho <talho@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
The wmark_active governor initialization assumes that the device
frequency is the lowest possible frequency when the governor is
started or resumed. However, this may not be correct if the
governor was suspended/stopped before the clock had been slowed
down.
This patch modifies the governor to read the frequency during
governor initialization and resume.
Change-Id: I38d3256102b344bc8818c5623a015843678a8ce5
Signed-off-by: Arto Merilainen <amerilainen@nvidia.com>
Reviewed-on: http://git-master/r/733007
Reviewed-on: http://git-master/r/1160009
(cherry picked from linux-4.9 commit 32e2561dffc5d7390fa4fd503651da9013403ecb)
Reviewed-on: https://git-master.nvidia.com/r/1770141
Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Timo Alho <talho@nvidia.com>
Tested-by: Timo Alho <talho@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
