There is GVS intermittency where few audio tests fail because there is
no APE sound card available. The card registration itself does not
happen because there is kernel data abort and following dump is seen:
[ 36.163223] Unable to handle kernel paging request at virtual address ffffffffffffffc0
[ 36.171180] Mem abort info:
[ 36.171182] ESR = 0x0000000096000004
[ 36.171183] EC = 0x25: DABT (current EL), IL = 32 bits
[ 36.171186] SET = 0, FnV = 0
[ 36.174218] EA = 0, S1PTW = 0
[ 36.174219] FSC = 0x04: level 0 translation fault
[ 36.174221] Data abort info:
[ 36.174222] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
[ 36.174223] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 36.174224] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 36.174226] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000813b67000
[ 36.174228] [ffffffffffffffc0] pgd=0000000000000000, p4d=0000000000000000
[ 36.174234] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
This seems to happen because mixer control override driver has the
dependency over the sound card and this dependency check is incorrect.
The attempt is made to register override controls before the sound card
is fully ready.
One option is to use 'card->instantiated' flag to add the dependency.
However this flag update is protected by card mutext and client_mutex
which is local to the core. So this flag check does not appear fully
reliable.
As a safer option, the override device is made child of sound device.
This way the probe order is ensured and override probe happens only
after a successful sound probe. This requires a change in machine driver
to allow probe() happen for child devices. This may be a concern during
usage of upstream machine driver which does not have provision for child
device probing. For now unblock the upstream AHUB usage by using this
safe option and investigate the best option to make the override driver
independent.
Bug 4508166
Bug 4451662
TAS-2251
Change-Id: Ib13f0a3a0ac272a0f2325b9d74efbc31128f0991
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3083180
Reviewed-by: Mohan kumar <mkumard@nvidia.com>
Reviewed-by: Sharad Gupta <sharadg@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Fix imx477 partial frame issue and wrong frame-length
/exposure time calculations.
Uses hardcoded sensor internal clock frequency
instead of clock values from sensor device tree.
Adding clock frequency to device tree also require
deskew_initial_enable = "true". Setting deskew in
device tree is causing kernel panic in function
nvcsi_deskew_setup(). For unblocking the IMX477
use case, set hardcoded clock in driver for now.
Bug 4384649
Change-Id: Iedb02673c6f4da140aee22adc991805b6aa1eb7e
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3086503
cherry-picked from <4d4e68569911d4424073a3b39f5b2642346a077a>
Signed-off-by: Ankur Pawar <ankurp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3087470
Reviewed-by: Praveen AC <pac@nvidia.com>
Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Currently, the DLA driver does not return an error if the ICC write
handle is not found and so it is possible that ICC failures will go
undetected. By using dev_err_probe(), error messages are only printed if
the error is not -EPROBE_DEFER. If an -EPROBE_DEFER error is returned
from the ICC, then no error message is printed because probe is being
deferred and we will try to probe the driver again later. This ensures
that the DLA driver will wait for the ICC to be ready and if any other
error occurs, then an error message will be displayed and the proper
error code returned.
Bug 4496044
Change-Id: I88632d7c6f7f1b83e0a69e4b132404a77fc090ec
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3084821
Reviewed-by: Johnny Liu <johnliu@nvidia.com>
Reviewed-by: Arvind M <am@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
If the userspace service 'irqbalance' is installed then the nvethernet
driver crashes when there is network activity. To avoid this crash set
the IRQF_NOBALANCING flash for the VM interrupts. No performance
degradation is observed when running iperf3 with a 1Gbps link.
Long-term the nvethernet driver still needs to be fixed to allow IRQ
balancing.
Bug 4293378
Bug 4541158
Change-Id: I0aa4ee28e36c7d273f14ff043544e72d3e988bd3
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3087525
(cherry picked from commit f9ed570c2b)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3088936
Reviewed-by: Revanth Kumar Uppala <ruppala@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
1. Register resume_noirq handler for profiling the time when early
driver resume sequence is started. Since this driver is loaded after
boot, this should get called very early in the resume sequence.
2. Register PM notifier to know when resume is complete. This helps
in profiling the time when entire resume sequence is complete.
These 2 timestamps should approximately indicate the time it takes
for Linux to resume.
Adding this code in this driver removes dependency of providing this
information from some other driver.
Bug 4454722
Signed-off-by: Bharat Nihalani <bnihalani@nvidia.com>
Change-Id: I214eb4ff2808ecb87b828cb4556a2a00cc2d4545
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3047836
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3062030
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Probing a driver can be deferred if a resource is not ready and this is
accomplished by returning -EPROBE_DEFER from the .probe function. This
tells to kernel to probe the driver again some time later. When probing
a driver is deferred it is not necessary to print an error message
because this is an expected error case. To avoid printing an error
message on probe deferral, the dev_err_probe() function can be used
which will only print an error if the error code is not -EPROBE_DEFER.
Therefore, update the camera drivers to use dev_err_probe() to avoid
printing an error message when -EPROBE_DEFER if returned from ICC.
This change will also cause the probing of the rtcpu-debug driver to
be deferred if -EPROBE_DEFER is returned and prevent the rtcpu-debug
driver from being probed at all if an real error is encountered.
Bug 4496044
Change-Id: I8a5313750e11b4bd661191c0c544c39e43478089
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3084829
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Kernel freeze is occurring due to incorrect cleanup
in vi5.c.
Fix for kernel freeze:
1 Don't call vi_channel_drv_unregister() and
tegra_vi_media_controller_cleanup() in vi5_remove.
2 capture_vi_probe() is calling vi_channel_drv_register() and
tegra_capture_vi_media_controller_init(), so capture_vi_remove()
should call vi_channel_drv_unregister() and
tegra_vi_media_controller_cleanup()
3 Use correct dev pointer in vi_channel_drv_unregister().
Code cleanup:
1 Remove use_legacy_path variable that was used for T186.
2 Removed unused t194_vi5_file_private struct.
Bug 4415340
Change-Id: I7a75d90e1d2a1fb78a6a5b083a66836b1723156c
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3077660
cherry-picked from <29e88ed17e757c0129a54a3fb44990cec4a33983>
Signed-off-by: Ankur Pawar<ankurp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2936745
Reviewed-by: Anubhav Rai <arai@nvidia.com>
Reviewed-by: Shubham Chandra <shubhamc@nvidia.com>
Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
The OOT variants of the host1x and tegra-drm drivers originally had
a '-next' suffix in the name to differentiate these from the upstream
versions. Now that the OOT drivers are installed under the 'updates'
directory, the '-next' suffix can be dropped because 'kmod' will
prioritise loading the variant in 'updates' over those built from the
kernel tree.
Bug 4410785
Change-Id: I29287ddb935b681a5ee8a3326428eba82715da76
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3065465
Reviewed-by: Brad Griffis <bgriffis@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Most of the AHUB module drivers are already upstreamed and there are
alternate ways to have the same feature parity with the legacy OOT
drivers. Thus there is no need to maintain the legacy OOT drivers
going forward. This commit removes all AHUB drivers which are already
in upstream and the same have been enabled as a default choice for
Terga234 and later chips.
Removal of OOT versions of upstreamed drivers resulted in following
build errors:
- AFC, IQC and machine driver include "tegra210_ahub.h". Due to
the removal of AHUB driver, the header is not found. It is found
that there is no actual dependency for these drivers on the AHUB
header.
Fix this by just removing the header inclusion.
- ARAD driver has dependency on ASRC driver for few helper functions.
Upstream ASRC driver does not expose these helpers yet, because
these are only required by ARAD module and all of these should go
together for upstream.
Fix this build error by guarding the header 'tegra186_asrc.h'
under macro 'CONFIG_SND_SOC_TEGRA186_ASRC_WAR'. The helper function
calls in ARAD driver are guarded under the same macro and this macro
is not enabled. This may leave ARAD broken with upstream ASRC driver
which is fine since there is no ARAD productization yet and this
will be taken care in bug 4432184.
Bug 4451662
Bug 4432184
TAS-2251
Change-Id: I5aa9ee1ae5ce58f3db8910f7e940dd2980da163a
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3074654
Reviewed-by: Mohan kumar <mkumard@nvidia.com>
Reviewed-by: Sheetal . <sheetal@nvidia.com>
Reviewed-by: Manoj Gangwal <mgangwal@nvidia.com>
Reviewed-by: Aditya Bavanari <abavanari@nvidia.com>
Reviewed-by: Sharad Gupta <sharadg@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
There is plan to use OOT machine driver with upstream AHUB drivers
as a first step in alignment with upstream drivers. The machine driver
will be taken up after this.
To allow usage of upstream AHUB drivers, make following changes:
- Update OOT PCM override driver to work with codec2codec links
as well. Note that PCM override controls in the module drivers
were rejected in upstream and it is one of the major differences
between upstream and OOT AHUB drivers.
- Register dummy DAI to use with I/O DAP DAI link. Exposure of
dummy DAIs was not encouraged in upstream from the I/O module
drivers. The codec2codec I/O links require a codec to be present.
Hence expose dummy DAI from machine driver and use the same in
I/O DAI links.
Bug 4451662
TAS-2251
Change-Id: If6904073eca29167620bf5d273cdcd306196f6ba
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3059819
Reviewed-by: svcacv <svcacv@nvidia.com>
Reviewed-by: Mohan kumar <mkumard@nvidia.com>
Reviewed-by: Sharad Gupta <sharadg@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Remove macro-protected dead code. NVMAP_LOADABLE_MODULE enables NvMap as
an OOT module, while NVMAP_UPSTREAM_KERNEL is a config for kstable/OOT
kernel. For Kernel 5.10+ both are always defined, So the related macro
protected code can be safely removed.
Bug 4479135
Change-Id: If3d32533f26f5928bd3ef7066bddba1505b77614
Signed-off-by: Yash Bhatt <ybhatt@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3079649
Reviewed-by: Ashish Mhetre <amhetre@nvidia.com>
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Remove macro-protected dead code. NVMAP_LOADABLE_MODULE enables NvMap as
an OOT module, while NVMAP_UPSTREAM_KERNEL is a config for kstable/OOT
kernel. For Kernel 5.10+ both are always defined, So the related macro
protected code can be safely removed.
Bug 4479135
Change-Id: I8e1bf930b15dfc8411d833383fb3eae2778edfe3
Signed-off-by: Yash Bhatt <ybhatt@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3079522
Reviewed-by: Ashish Mhetre <amhetre@nvidia.com>
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Remove macro-protected dead code. NVMAP_LOADABLE_MODULE enables NvMap as
an OOT module, while NVMAP_UPSTREAM_KERNEL is a config for kstable/OOT
kernel. For Kernel 5.10+ both are always defined, So the related macro
protected code can be safely removed.
Bug 4479135
Change-Id: I792f1cb2c54fd21bcf0e73ffc52e46e4efd47862
Signed-off-by: Yash Bhatt <ybhatt@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3079420
Reviewed-by: Ashish Mhetre <amhetre@nvidia.com>
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Currently, each process holding an open TegraDRM channel reserves
for itself one of the limited number of hardware memory contexts.
Attempting to allocate a channel when all contexts are in use
results in failure.
While we cannot have more contexts than the hardware supports in
active use, idle channels don't necessarily need to have a backing
memory context. As such, in this patch, we add another layer
to allow hardware memory contexts to be "stolen away" by channels
that are in active use, from idle processes.
The way this is implemented, is by keeping track of memory
mappings on each abstracted memory context. If we need to
steal that memory context's backing hardware context, we unmap
everything from it and give it away. When that abstracted
memory context is needed again (re-activated), we attempt
to allocate or steal another hardware context and re-map
the previously unmapped buffers.
Unfortunately, this means additional overhead and unpredictability
at submit time. Submit can fail if we cannot re-allocate a
backing memory context. Future work includes a provision for
un-stealable backing hardware memory contexts for processes
requiring more determinism, as well as optimization and cosmetic
improvements.
Bug 4403250
Bug 4399310
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Change-Id: I3d13e3476f1bff3c4757152254496cddaaafd76a
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3058905
Reviewed-by: Santosh BS <santoshb@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
The following error messages are sometimes observed on boot ...
tegra-nvjpg 15380000.nvjpg: failed to get icc write handle
tegra-nvdec 15480000.nvdec: failed to get icc write handle
tegra-nvjpg 15540000.nvjpg: failed to get icc write handle
tegra-nvenc 154c0000.nvenc: failed to get icc write handle
tegra-vic 15340000.vic: failed to get icc write handle
tegra-nvjpg 15380000.nvjpg: failed to get icc write handle
The above messages are harmless because the ICC core is returning
-EPROBE_DEFER to indicate that the ICC provider is not available. When
-EPROBE_DEFER is returned the kernel will attempt to probe the device
again and so print an error on -EPROBE_DEFER can be misleading. Fix the
above by using the function dev_err_probe() to print error messages
because this function will only print an error message if the error code
is not -EPROBE_DEFER.
Bug 3436156
Bug 4496044
Change-Id: I47b77e5a0f2bdb817a832daa305246c8803f456b
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3075237
(cherry picked from commit 61319aef4d)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3075849
Reviewed-by: Brad Griffis <bgriffis@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
