- Rename dce-os-device to dce-linux-device
- dce-os-device.h header is specific to OS and is only intended
to be internally used within OS. Similarly all it's exposed
functions are OS specific only.
- Therefore instead of having a common name for all OSs for this
header file, make this header internal by including linux
name to it's naming convention.
- Similary rename dce_os_device struct to dce_linux_device and
also rename corresponding functions from this header.
JIRA TDS-16126
Change-Id: I74e2deb17f49065d242bd80d50c5a849b3dfa3a1
Signed-off-by: anupamg <anupamg@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3256403
Reviewed-by: Arun Swain <arswain@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
- I2b8a24f9044bc08e10e5ff8cbf0c3f51fa53ff53 change introduced
an issue of concurrent accesses of admin message buffer
by different admin channel clients.
- This change will fix this issue by adding set of buffers per admin
channel client.
- When a admin channel client wants to use a buffer it will
have to request using it's client ID.
Buffer will be granted only if at least one buffer for that client
is not in use.
- Admin channel clients must release the buffer once done with the
usage so that it's available for other accesses by the same client.
- Do we need a mutex to protect this array?
1) There's no issue if different clients are trying to get/put
buffers concurrently since each query will operate on
separate per client array.
2) We've an assumption that none of the clients will be active
during init. This is also documented as part of function
documentation.
3) Will we ever have a usecase where a same client does
get/put concurrently?
4) Is it possible for a client to be active during de-init?
- If answer to 3 or 4 is yes then we still need a mutex to protect
the buffers.
- Currently we've assumed that there woudn't be concurrent
operations during init/deinit and on same client so
we're not introducing any mutex.
JIRA TDS-16126
Change-Id: I2ab640dc7c8ee6dedc9179dbb726368c3cb7d65f
Signed-off-by: anupamg <anupamg@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3249307
Reviewed-by: svcacv <svcacv@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Mahesh Kumar <mahkumar@nvidia.com>
Reviewed-by: Arun Swain <arswain@nvidia.com>
- This is a follow-up CL to address comment from
I42bfe95aa81823dc077ae0964eb6288a1f25fc17
- Certain utils functions are used in single files so make
them static and move to files in which they are used.
- Rename these from dce_os*() to dce_().
- Delete dce_get_fw_phy_addr() as it's unused.
JIRA TDS-16126
Change-Id: I6049ae1d381ac9c18acbcd3b2584d4d8ab3f2dc0
Signed-off-by: anupamg <anupamg@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3248435
Reviewed-by: Mahesh Kumar <mahkumar@nvidia.com>
Reviewed-by: Arun Swain <arswain@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: svcacv <svcacv@nvidia.com>
- Abstract out iosys_* dependencies for writing/reading to/from
message header and memcpy to os specific implementation.
- Add new dce-os-ipc.c
- Cannot add these functions to existing 'dce-os-ivc.h' as
static inline functions because these functions access
dce_ipc_channel defined in dce_ipc.h.
- Cannot include dce_ipc.h to this file as it creates
a circular dependency.
- Also fix exsisting issue of not defining 'tegra_dce' inside
dce-ipc.h
- This is exposed now because we're including dce-ipc.h to
dce-os-ipc.c which doesn't include any prior headers which
define tegra_dce.
- Fix by doing forward define to avoid circular dependency
with dce.h
- Additionally fix below iosys issues:
1) Change Iabebef33719c38a8aa4db8573a0dd7dd7e5f83f6 introduced
an issue because NV_TEGRA_IVC_STRUCT_HAS_IOSYS_MAP demands
different prototypes for below functions:
- dce_os_ivc_get_next_write_frame()
- dce_os_ivc_get_next_read_frame()
2) Now since dce_ipc_is_data_available() uses
dce_os_ivc_get_next_read_frame(), it needs to define
frame with iosys_map for IOSYS Linux 6.2 usecase. So need
to creata a OS abstraction for this too.
JIRA TDS-16126
Change-Id: I55594d8e34c3b572129119d1f7240cde76cf37bd
Signed-off-by: anupamg <anupamg@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3233117
Reviewed-by: Mahesh Kumar <mahkumar@nvidia.com>
Reviewed-by: Arun Swain <arswain@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Module covered: dce-trace
This is not a functional change. It does the following:
1) Add new os/linux/include/dce-os-trace.h to abstract
trace event functionality. Define static inline
wrappers dce_os_trace_*() to corresponding existing
trace_*() functions.
2) Remove intermediate os header os/include/os-dce-events.h
and replace all includes directly with <dce-os-trace.h>`
JIRA TDS-16126
Change-Id: I800be4a2b9b51214af4c2531e34dbdd41caccaea
Signed-off-by: anupamg <anupamg@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3229379
Reviewed-by: Mahesh Kumar <mahkumar@nvidia.com>
Reviewed-by: Arun Swain <arswain@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Module covered: dce-workqueue
This is not a functional change. It does the following:
1) Move include/dce-workqueue.h to
os/linux/include/dce-os-work.h
2) s/dce_work/dce_os_work/g
3) s/dce_init_work/dce_os_work_init/g
4) s/dce_schedule_work/dce_os_work_schedule/g
5) Remove intermediate os header os/include/os-dce-workqueue.h
and replace all includes directly with <dce-os-work.h>
JIRA TDS-16126
Change-Id: I4d88cf68a187a061fd0c8c084ea074fb9e74d315
Signed-off-by: anupamg <anupamg@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3228552
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Mahesh Kumar <mahkumar@nvidia.com>
Reviewed-by: Arun Swain <arswain@nvidia.com>
Modules covered in this CL: dce-os-ivc
This is not a functional CL. It does the following:
1) Move os/include/linux-kmd/os-ivc.h to
os/linux/include/dce-os-ivc.h
2) s/os_ivc/dce_os_ivc/g
3) Delete old intermediate header os/include/os-ivc.h and include
<dce-os-ivc.h> directly.
JIRA TDS-16126
Change-Id: Ib6264a39910dbb4a107fd2261005c5e593b4b9b7
Signed-off-by: anupamg <anupamg@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3228545
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Arun Swain <arswain@nvidia.com>
Reviewed-by: Mahesh Kumar <mahkumar@nvidia.com>
Module covered in this CL: dce-cond
This is not a functional CL. It does the following.
1) Move os/include/linux-kmd/os-cond.h to
os/linux/include/dce-os-cond.h
2) s/dce_cond/dce_os_cond/g
3) s/DCE_COND/DCE_OS_COND/g
4) Delete intermediate include os/include/os-cond.h and replace
all includes with <dce-os-cond.h>
JIRA TDS-16126
Change-Id: Ib4f3cbe5402b2abe114be89f36e25a6fe47e8b13
Signed-off-by: anupamg <anupamg@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3228543
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Arun Swain <arswain@nvidia.com>
Reviewed-by: Mahesh Kumar <mahkumar@nvidia.com>
Modules covered in this CL: dce-lock
This is not a function CL. It does the following:
1) Move dce-lock.h to os/linux/include/dce-os-lock.h
2) s/dce_mutex/dce_os_mutex/g
3) Remove intermediate includes previously introduced:
a) Delete os/include/os-lock.h
JIRA TDS-16126
Change-Id: I994bcbf75ec87461c0dc2714b300d0ad1e3ee018
Signed-off-by: anupamg <anupamg@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3228541
Reviewed-by: Arun Swain <arswain@nvidia.com>
Reviewed-by: Mahesh Kumar <mahkumar@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Modules covered in this CL:
1) dce-os-log
This is not a functional CL. It does the following:
1) Rename dce_<info/err/debug/warn> to
dce_os_<info/err/debug/warn>
2) Rename dce_log_msg() to dce_os_log_msg()
3) Rename DCE_<WARNING/ERROR/INFO/DEBUG> to
DCE_OS_<WARNING/ERROR/INFO/DEBUG>
4) Move dce-log.h to os/linux/include/dce-os-log.h
5) Stop using old abstraction:
a) Replace <os-dce-log.h> includes with <dce-os-log.h>
6) Delete all related old deprecated log files:
a) os/include/linux-kmd/os-dce-log.h
b) os/include/os-dce-log.h
JIRA TDS-16126
Change-Id: I75ebe98a785c298678d80371184efae6e46932ee
Signed-off-by: anupamg <anupamg@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3228536
Reviewed-by: Arun Swain <arswain@nvidia.com>
Reviewed-by: Mahesh Kumar <mahkumar@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
- 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.8, the 'g_frame_interval' and 's_frame_interval' function
pointers were removed from the 'v4l2_subdev_video_ops' structure and
replaced by 'get_frame_interval' and 'set_frame_interval' that were
added to the 'v4l2_subdev_pad_ops' structure.
This change was previously fixed for the Tegra CSI driver by adding the
necessary conftest changes. A new update to the Tegra Cam V4L2 causes
the build to fail for Linux v6.8+ kernels because of the same issue. Fix
up the Tegra Cam V4L2 driver in the same way as the Tegra CSI driver,
but update the name of the conftest test to indicate that this is
applicable for both the 'get_frame_interval' and 'set_frame_interval'
function pointers.
Bug 4448428
Bug 4807063
Change-Id: Ica47f3aaece0bf81e2adc3c431056ea51b64a893
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3231775
(cherry picked from commit 91416b264c)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3246399
Reviewed-by: Ankur Pawar <ankurp@nvidia.com>
Reviewed-by: Praveen AC <pac@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: Ankur Pawar <ankurp@nvidia.com>
Reviewed-by: Bitan Biswas <bbiswas@nvidia.com>
Reviewed-by: svcacv <svcacv@nvidia.com>
In Linux v6.12, commit 641bb4394f40 ("fs: move FMODE_UNSIGNED_OFFSET to
fop_flags") moves the setting of the FMODE_UNSIGNED_OFFSET into the
various drivers and renames this flag. This change is causing various
tests to fail because opening the DRM device is failing.
Use the presence of the new FOP_UNSIGNED_OFFSET flag in the kernel to
determine if we need to set this flag in the Tegra DRM driver.
Bug 4876974
Change-Id: Ie72a9340187b1c206f0cda6d7e3dab44d603a41c
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3269063
Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
