- Add check for params arg in dce_admin_handle_ipc_received_event().
- dce_admin_handle_ipc_received_event() is a one of the FSM event
functions which shares common FSM event function prototype:
int (*fsm_event_handle)(struct tegra_dce *d, void *params);
- But dce_admin_handle_ipc_received_event() implementation doesn't
need 'params' argument and therefore callers are expected to
pass NULL.
- This change will add a check inside this function to check
if the params are NULL and print a warning message otherwise.
JIRA TDS-16126
Change-Id: I70b73d195d866b7b6bb43b5430dccfb0bc3cb486
Signed-off-by: anupamg <anupamg@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3225248
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Arun Swain <arswain@nvidia.com>
Reviewed-by: svcacv <svcacv@nvidia.com>
Reviewed-by: Mahesh Kumar <mahkumar@nvidia.com>
- This change will add new DCE OS interface for types.h.
- This DCE OS interface layer will act as entry point to OS layer
from core DCE-KMD code.
- The intended usage is as follows.
- DCE-KMD core will include respective OS header file from
DCE OS interface.
Eg. In dce-fsm.c
#include <dce-os-types.h>
- DCE OS interface will further include OS specific files
Eg. In dce-os-types.h
#include <os-types.h>
- OS specific files will reside in respective OS specific paths.
Eg. for Linux the path will be
kernel/nvidia-oot/../dce/os/include/linux/os-types.h
For HVRTOS the path will be
display/server/os/include/hvrtos/os-types.h
- The OS specific paths will be directly included in respective
OS makefiles during compilation so that we don't need to use
ifdefs within DCE OS interface layer.
- This is first change to follow this convention for types.h.
We will have follow-up CLs to follow this suite for all other
OS dependencies for DCE-KMD.
JIRA TDS-16126
Change-Id: Ied7bee6eac5de9134b973e74020df200707afa10
Signed-off-by: anupamg <anupamg@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3224052
Reviewed-by: Mahesh Kumar <mahkumar@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Arun Swain <arswain@nvidia.com>
- Move resource init specific to PM and bootstrap modules
to respective PM and bootstrap init functions.
- Motivation here is 2 fold:
1) To keep common code common across OSs.
2) Move resource init to respective sub-modules.
- We will have separate PM module for HVRTOS.
- We will have separate dce-worker module for HVRTOS.
JIRA TDS-16052
Change-Id: I40f6943eb4173a0da7201dc58afb19aee2a0d04e
Signed-off-by: anupamg <anupamg@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3190873
Reviewed-by: Arun Swain <arswain@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: svcacv <svcacv@nvidia.com>
Reviewed-by: Mahesh Kumar <mahkumar@nvidia.com>
- Move IPC region alloc/free calls to OS layer because
they mean different for different OSs.
- For Linux it will allocate/dma map memory for IVC comm.
- For HVRTOS it will simply fetch pre-allocated memory details
since the memory allocation is only allowed in hypervisor module.
- Accordingly, rename the API dce_ipc_allocate_region() ->
dce_ipc_init_region_info(). Similarly for free as well.
JIRA TDS-16052
Change-Id: I201cb5b1bc7384a9b0ccdbf5bc72bbd78d6b1506
Signed-off-by: anupamg <anupamg@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3180405
Reviewed-by: svcacv <svcacv@nvidia.com>
Reviewed-by: Arun Swain <arswain@nvidia.com>
Reviewed-by: Mahesh Kumar <mahkumar@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
- In DCE_KMD, dce_fsm_start() schedules start of state machine
functionality which involves the waiting for DCE-FW boot completion,
IPC admin setup and communication etc.
- HVRTOS restricts certain functionalities like waiting on events,
acquiring locks, etc in initialize phase.
- Also for HVRTOS we are executing worker queue work in same
thread context directly from where it's called from.
- For above reasons, we need to decouple SW resource allocation and
init logic and actual execution start logic which was part of
dce_driver_init() earlier into 2 phases:
- dce_driver_init()
- This will do all resource allocation/init and will be called
during resource initialization phase.
- Module probe for Linux
- Initialize() context for HVRTOS.
- dce_driver_start()
- This will start actual DCE logic execution after all
resources are allocated and initialized and will be executed
separately.
- In Linux, both will be executed from the same probe
while in HVRTOS, the former is in process initialize
stage and dce_driver_start is run in the
Thread initialize stage.
JIRA TDS-16052
Change-Id: I1176d748bc705106bb0c8ca7e647713abf2d4a00
Signed-off-by: anupamg <anupamg@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3192613
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: svcacv <svcacv@nvidia.com>
Reviewed-by: Arun Swain <arswain@nvidia.com>
Reviewed-by: Mahesh Kumar <mahkumar@nvidia.com>
Dont't acquire locks during init/deinit.
- FSM init/deinit is expected to be called during init/deinit phase
when everything else and FSM itself is inactive.
- FSM mutex is just initialized/deinit in the same functions where
we're trying to acquire lock/release.
- While it is techically ok in general but not requried.
- Also HVRTOS restriction prevents to acquire mutexes in
initialization phase.
- Deinit can be called in Initization context to deinit
if init fails.
JIRA TDS-16052
Change-Id: I19e10bb890a4ab6d011df4380ab3a6d5fe92c696
Signed-off-by: anupamg <anupamg@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3178697
Reviewed-by: Arun Swain <arswain@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: svcacv <svcacv@nvidia.com>
Reviewed-by: Mahesh Kumar <mahkumar@nvidia.com>
- Add define for USE(x) for Linux. It's required to resolve
warnings for unused variables across DCE-KMD codebase.
For HVRTOS such warnings are treated as errors so this is
a must.
- For HVRTOS the define comes from os_port.h
- USE(x) is removed in Ic22ca046a036e8c9883d2857a8de325ee1874980
after replacing the USE(x) usages with appropriate checks.
JIRA TDS-16052
Change-Id: Icb2c14036a4194bcff89ede3a5f500f71568a2a7
Signed-off-by: anupamg <anupamg@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3188577
Reviewed-by: Arun Swain <arswain@nvidia.com>
Reviewed-by: Mahesh Kumar <mahkumar@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: svcacv <svcacv@nvidia.com>
- DCE-KMD code is only compiled on Linux Kernel today. So it has
some linux specific dependencies.
- We will be compiling the same code for new DispalySerer HVRTOS
process. To support this we will need to abstract out OS
specific dependencies from DCE-KMD.
- Common OS abstraction code will be developed under display/drivers/
server/ repo.
- DCE-KMD will start using that os abtsaction and this is the first
CL towards that effort.
JIRA TDS-16052
Change-Id: I51fba684ac285139225a2999338e73c724d9d499
Signed-off-by: anupamg <anupamg@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3167249
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: svcacv <svcacv@nvidia.com>
Reviewed-by: Arun Swain <arswain@nvidia.com>
Reviewed-by: Mahesh Kumar <mahkumar@nvidia.com>
- Add OS abstraction for DCE-KMD driver as it will be used
for Linux as well as HVRTOS.
- The original OS abstraction headers are maintined under
display/drivers repo (display/drivers/server/os/include/).
- From that copy, only linux-kmd relevant headers
are mirrored here as there's no need to mirror HVRTOS
related headers.
- But we need a copy here as we cannot include external paths
in kernel builds.
JIRA TDS-16126
Change-Id: Iabebef33719c38a8aa4db8573a0dd7dd7e5f83f6
Signed-off-by: anupamg <anupamg@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3194862
Reviewed-by: Arun Swain <arswain@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
In Linux v6.12 the definition 'no_llseek' was finally removed. Since
Linux v6.0 it had been redefined as NULL. Add a test to conftest to
determine if 'no_llseek' is present and if not then it is no longer
necessary to populate this and we can leave as NULL.
Bug 4876974
Change-Id: Idc0f5eff6f95f404a24b6d795f6a9460b99639e4
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3261670
Reviewed-by: svcacv <svcacv@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Pushpesh Pranjal <ppranjal@nvidia.com>
With Linux v6.13, the Tegra264 NVADSP driver fails to build and the
following errors are observed:
In file included from drivers/platform/tegra/nvadsp/dev-t264.c:4:
include/linux/reset.h:30:49: error: implicit declaration of function
‘BIT’ [-Werror=implicit-function-declaration]
30 | #define RESET_CONTROL_FLAGS_BIT_ACQUIRED BIT(2)
| ^~~
In file included from drivers/platform/tegra/nvadsp/dev-t264-aon.c:4:
/include/linux/reset.h:30:49: error: implicit declaration of function
‘BIT’ [-Werror=implicit-function-declaration]
30 | #define RESET_CONTROL_FLAGS_BIT_ACQUIRED BIT(2)
| ^~~
Fix this by adding the missing 'bits.h' header.
Bug 4991705
Change-Id: I08a6cb59339f8e5221fdc3f39b2a7323cae0cd1f
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3261688
Reviewed-by: svcacv <svcacv@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Viswanath L <viswanathl@nvidia.com>
- added a device node to fetch the raw traces
- keeping both option available: existing worker method,
using device node to fetch raw traces
- both blocking & non-blocking call support,
user can decide it
- multiple file open support, each file descriptor
context have its own read pointer of trace memory
Jira CAMERASW-27486
Jira CAMERASW-27487
Jira CAMERASW-27774
Change-Id: I93942d273570857b0073e0e863e41c221c36ebb7
Signed-off-by: Pushpesh Pranjal <ppranjal@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3215749
(cherry picked from commit 21a9c245ea4be51117c379d77c45de1ddc3a167c)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3241811
Reviewed-by: Evgeny Kornev <ekornev@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
- Define boot log related HSP message ID's.
- Call camrtc_hsp_vm_read_boot_log as the first step during the HSP
handshake.
- The read_boot_log function will wait for 2000 ms for a boot log
message. If the RCE has hung during boot, this will timeout, and return
with error.
- Move dev_set_drvdata to before camrtc_hsp_probe in camrtc_hsp_create.
Explanation: The RCE, during a normal boot sequence, will boot before
the RTCPU KMD starts probing, so the mailbox will already be full
when the HSP driver is initializing. The RTCPU HSP full interrupt
handler will be called immediately after the handlers are registered
by the mailbox driver. The interrupt handler will reference the HSP
device's drvdata, and it was a race condition as to whether the
interrupt handler would be called before the drvdata was set.
Thus, this change sets drvdata before the interrupt handlers are
installed to prevent this race condition.
- Update the full interrupt handler to return if camhsp is null.
Jira CAMERASW-27443
Change-Id: Ibb7ed41771d2178e0d06adb94ae1955db61b9d92
Signed-off-by: Akihiro Mizusawa <amizusawa@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3239620
Reviewed-by: Chinniah Poosapadi <cpoosapadi@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Semi Malinen <smalinen@nvidia.com>
Reviewed-by: Frank Chen <frankc@nvidia.com>
This patch fixes a race condition between
tegra_dce_unregister_ipc_client and dce_client_ipc_wakeup.
If dce_client_ipc_wakeup is called just after unregistering
it'll result in accessing already freed data structures and
kernel crash. This patch adds a check to validate if the client_ipc
struct is valid before accessing its members.
Bug 4913921
Change-Id: Ie7f25379d7254d1f1ad4fb17baafee353f6d9eca
Signed-off-by: Mahesh Kumar <mahkumar@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3239873
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Vinod Gopalakrishnakurup <vinodg@nvidia.com>
- Add compatible and chip data for T264 ADSP[1:0] and AON
- Add T264 dev files to build makefile
DNS
Bug 3682950
Bug 4165898
Change-Id: Idbaef1950ff2f736c7844ee0525d55b596b11132
Signed-off-by: Viswanath L <viswanathl@nvidia.com>
Added t264 specific pdata struct to
use r5_ctrl and pwr_status registers
values.
Jira CAMERASW-11038
Change-Id: I4ae6b3ffee48eff61a6b7a7309c251c38d68bf30
Signed-off-by: fraunak <fraunak@nvidia.com>
