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>
This patch adds a new watermark governor that actively alters the
watermark values based on the current frequency and target load.
The governor takes target load as a given property (80% by default)
and every time when the governor re-estimation is triggered, the
governor checks the current load and calculates the next frequency
that would push the device as close this target load as possible.
At this point also the watermark values are updated so that next
time the interrupt should come when the load change is significant
enough to cause frequency change to either next or previous
frequency.
Change-Id: I860a0bc984d55628a0e560652a93306616b080cf
Signed-off-by: Arto Merilainen <amerilainen@nvidia.com>
Reviewed-on: http://git-master/r/598801
Reviewed-on: http://git-master/r/1160008
(cherry picked from linux-4.9 commit e55ba2a709574ce4f01ca2f8211393c795b75dad)
[talho: removed Kconfig and Makefile changes from the patch]
Signed-off-by: Timo Alho <talho@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1770140
Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
MODULE_LICENCE was not declared
exit function didnt have an explicit return
linux/module.h wasn't included because of which
module_exit was throwing errors.
Added the statement to do the same.
Bug 200199306
Change-Id: Ib9e3a6f832b75095b9465dbe236a1f1c3606563f
Signed-off-by: Ishan Mittal <imittal@nvidia.com>
(cherry picked from linux-4.9 commit be9e41d39b8f9b6bbd716ea7a26ea7fdec54bad7)
Reviewed-on: https://git-master.nvidia.com/r/1770137
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 update_devfreq(), we currently get target frequency,
compare it with previous_freq, and set it only if
new freq is different one
But get_target_freq() (nvhost_pod_estimate_freq())
already takes care of such cases in normal conditions
Hence, remove the check with previous_freq in
update_devfreq()
For case when we disable podgov governor, we might still end
up setting max freq all the time
Hence, add a check on previous_freq, and if previous_freq
is already max, do not set it
Bug 200175874
Bug 200161377
Change-Id: I287d37c07ee6214ed48612482211ce0f45088ca4
Signed-off-by: Deepak Nibade <dnibade@nvidia.com>
Reviewed-on: http://git-master/r/1111437
Reviewed-on: http://git-master/r/1113417
(cherry picked from linux-4.9 commit 9c424ce31bedac5db0c2d93e083f20ea89ed1836)
Reviewed-on: https://git-master.nvidia.com/r/1770136
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 currently have below
sequence
- profile->get_dev_status()
- check if (!podgov->enable)
- check if (podgov->p_user)
But in case we have podgov disabled, we unnecessarily
call profile->get_dev_status()
Hence, do all such checks before calling get_dev_status()
Bug 200161377
Change-Id: I6128803c21bea6c5efefd517ea1c69e4f1b1597e
Signed-off-by: Deepak Nibade <dnibade@nvidia.com>
Reviewed-on: http://git-master/r/929508
Reviewed-on: http://git-master/r/933703
(cherry picked from linux-4.9 commit b8d1d439d206887c3cf4ff50119647b02efdae0e)
Reviewed-on: https://git-master.nvidia.com/r/1770135
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 devfreq drivers are available in kernel/nvidia and it
is required to integrate in kernel/nvidia-oot.
Remove Makefile so avoid makefile conflict.
Bug 4038415
Change-Id: If0e81b66271d65c5a6d613d61be0e95d1af503e1
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Guest VM has access to all of the profiler carveout right now so that
it can read full carveout and dump all the entries.
Right now address and size of Guest VM owned profiler carveout is parsed
from kernel command line. And the address of full profiler carveout
(containing logs of other VMs too) is calculated based on assumptions.
Current architecture is now getting reworked so that only a privileged
Guest VM can access full carveout and that too in read-only mode. Each
VM will have read-write access to its own carveout to read/write
profiler entries of that VM.
Update tegra_bootloader_debug_init.c to parse tegra_bl_prof_ro_start and
tegra_bl_prof_ro_size from kernel command line. These values indicate
address and size of the full read only carveout.
In tegra_bootloader_debuginit(), map the address of read only carveout
to tegra_bl_mapped_prof_ro_start and set is_privileged_vm to true.
Only privileged VM will be assigned this read only address by BL.
tegra_bl_mapped_prof_start continues to map to read-write carveout
owned by the VM.
Update profiler_show() so that it reads entries from the read-only
carveout if is_privileged_vm is set, otherwise it reads from read
write carveout.
Bug 3566403
Change-Id: I3c1e5d42d67f7724c6fa43b7e27f08ce2cd607b7
Signed-off-by: Deepak Nibade <dnibade@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2868921
Reviewed-by: Bharat Nihalani <bnihalani@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
1. Update to VERSION "3.1.6fd4e69.20220818-105856"
2. Update the fw file for RTL8851A, RTL8852B
3. rtk_coex: Support vendor cmd for reporting the profile and state of each connection
4. rtk_bt/rtk_misc/rtk_coex/hci_ldisc/btrtksdio: fix the issues by coverity scan and Sparse build
5. rtk_bt: Add shutdown wakeup and fix failure of usb enumeration
6. rtk_bt: Add marco to distinguish powerkey or anykey wakeup
Bug 3528414
Change-Id: Ia44029f189f8fc2cd62160dbc763c6e91e8cd9b4
Signed-off-by: Sushil Singh <sushilkumars@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2876940
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Tested-by: Revanth Kumar Uppala <ruppala@nvidia.com>
Reviewed-by: Revanth Kumar Uppala <ruppala@nvidia.com>
Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com>
Upstream Linux commit 03c835f498b5 ("i2c: Switch .probe() to not take an
id parameter") removes the 'id' argument from the I2C probe callback.
Update the ov5693 driver, which defines an I2C probe callback function,
to fix building the driver for Linux v6.3.
Bug 4014315
Change-Id: Ic037da06b1999801fb62e6ccd39b92fe86b5402a
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2875027
Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
The functions eth_hw_addr_set() and dev_addr_mod() do not exist for
Linux v5.14 and so compiling the marvell oak driver fails for Linux
v5.14. Fix this by calling memcpy() instead of eth_hw_addr_set() and
dev_addr_mod() for Linux v5.14. Note that both eth_hw_addr_set() and
dev_addr_mod() internally call memcpy() and so this is equivalent.
Bug 3820317
Change-Id: I4b49e031383adf62a55f1d01e8de2fcc0ad47862
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2875022
Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
The sensor kernel tests module is a simple test runner whose
responsibility is to dispatch tests and communicate with the
companion userspace binary over Generic Netlink sockets. Tests
may choose to register themselves with this module where they
then can be executed from userspace.
The sensor DT test asserts DT compliance of a given sensor node
with respect to a given TVCF version
A small set of logging utilities have been added to allow
tests the ability to log their results to the kernel log
or to some other handle (typically injected via the sensor
kernel tests module) through a common interface.
Bug 3583587
Change-Id: I22acf9c90fc82fbbdad8ba271dcdbbd6a5898eda
Signed-off-by: Ankur Pawar <ankurp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2857293
Reviewed-by: Frank Chen <frankc@nvidia.com>
Reviewed-by: Semi Malinen <smalinen@nvidia.com>
Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
