The state of ADSP is logged by writing to a mailbox
register. Adding support to kernel driver to dump ADSP
state when crash happens.
Jira EMA-404
Bug 1901511
Bug 1893324
Bug 200239577
Change-Id: Ia2beb84a7d5bc871f7062bd6a661333af0b0e24d
Signed-off-by: Hariharan Sivaraman <hariharans@nvidia.com>
Reviewed-on: http://git-master/r/1229864
(cherry picked from commit 0027e7a51f6134b4a7b332c17f7c7c26ac727ebc)
Signed-off-by: Nitin Kumbhar <nkumbhar@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1537327
Reviewed-by: svccoveritychecker <svccoveritychecker@nvidia.com>
GVS: Gerrit_Virtual_Submit
The request irqs are moved just before starting ADSP and freed when
adsp is suspended/stopped.
This is since the new agic driver is based on a device-driver model
and requires all interrupts to be freed before it could suspend.
Bug 200270956
Change-Id: I8ecd05ebe52020f11be79b9a1da37a85fed432ac
Signed-off-by: Ajay Nandakumar <anandakumarm@nvidia.com>
Reviewed-on: http://git-master/r/1478838
Signed-off-by: Nitin Kumbhar <nkumbhar@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1537326
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: svccoveritychecker <svccoveritychecker@nvidia.com>
GVS: Gerrit_Virtual_Submit
Fix following sparse warnings by including header dev-t21x.h, which
has function declarations, in dev-t21x.c.
dev-t21x.c:284:5: warning: symbol 'nvadsp_pm_t21x_init' was not declared.
Should it be static?
dev-t21x.c:296:5: warning: symbol 'nvadsp_reset_t21x_init' was not declared.
Should it be static?
Bug 200299572
Change-Id: I5f16da0852ab9083fba7395cfbd66ec012014663
Signed-off-by: Nitin Kumbhar <nkumbhar@nvidia.com>
Reviewed-on: http://git-master/r/1474440
Signed-off-by: Nitin Kumbhar <nkumbhar@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1537325
Reviewed-by: svccoveritychecker <svccoveritychecker@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Amit Sharma (SW-TEGRA) <amisharma@nvidia.com>
Enable FIQ when ADSP driver is enabled.
An FIQ interrupt is a highest priorty interrupt and used
when ADSP crashes to put ADSP in WFI.
The ADSP needs to be put in WFI, so that all transcations on the
bus are completed.
Bug 200270956
Change-Id: Ifb177ba9e0486ff7b4761d95f68b09265510c55f
Signed-off-by: Ajay Nandakumar <anandakumarm@nvidia.com>
Reviewed-on: http://git-master/r/1468503
Signed-off-by: Nitin Kumbhar <nkumbhar@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1537324
Reviewed-by: svccoveritychecker <svccoveritychecker@nvidia.com>
GVS: Gerrit_Virtual_Submit
Decrease the size of app message(send/receive) queue from 16KB
from 4096 bytes. This is to reduce the foot print of adsp.
Decreasing size of ADSP log buffer from 1MB to 16 KB.
This helps reducing the amount of memory used by ADSP.
Based on:
platform: nvadsp: Decrease size of app msg queue
platform: nvadsp: Reduce the size of adsp logger
Bug 1774702
Bug 200270956
Change-Id: I3b4b5d28d2fe05ad9fe2b1247327497ca63767fe
Signed-off-by: Ajay Nandakumar <anandakumarm@nvidia.com>
Reviewed-on: http://git-master/r/1468350
Signed-off-by: Nitin Kumbhar <nkumbhar@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1537320
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: svccoveritychecker <svccoveritychecker@nvidia.com>
GVS: Gerrit_Virtual_Submit
When ADSP OS is loaded from adsp.elf, it loads two sections : adsp os
and the vector table. The vector table is copied to a local buffer
before writing to the EVP registers.
There is a probability that, if the adsp.elf is hacked / modified by
an attacker, it can write to other APE register spaces. Hence, the
destination address obtained from the elf is checked with evp base
before copying.
Also, this fixes out of array-bound writing to evp buffer.
Bug 1684844
Change-Id: I8981dc5a5db8e0c0653ff46a1576df2c82e420be
Signed-off-by: Ajay Nandakumar <anandakumarm@nvidia.com>
Reviewed-on: http://git-master/r/1118936
(cherry picked from commit 9f7120e03e66b5f6e2bf67f09063da20945be238)
Reviewed-on: http://git-master/r/1458894
Signed-off-by: Nitin Kumbhar <nkumbhar@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1537317
Reviewed-by: svccoveritychecker <svccoveritychecker@nvidia.com>
GVS: Gerrit_Virtual_Submit
The RTCPU driver has a dependency of the following kernel modules:
clk-group
device-group
reset-group
Rather that builds all these source files as individual drivers, which
is bloating the number of kernel modules required, compile these source
files into the main RTCPU kernel module.
Finally, remove any unneeded header files from the ivc-bus driver.
Bug 4078936
Change-Id: I0981a716db7a91556d8c00a291b81dec01dda2e3
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2890896
Reviewed-by: svcacv <svcacv@nvidia.com>
Reviewed-by: Matti Ryttylainen <mryttylainen@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Current mc-utils driver is specific to T234 without any support for
extending it to future SOCs. Add such support so that it can be easily
extended for future chips.
- Create a struct of function pointers of all present operations
- Set these function pointers as per SOCs
Bug 4090660
Change-Id: I93e9da987bce1e563eb03aeeb0ac8bcb9da48023
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2911894
Reviewed-by: Jonathan Hunter <jonathanh@nvidia.com>
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Actmon DFS for EMC has been moved to BPMP side. This driver simply reads
the exponential moving average counter register of the MC_ALL client and
export the value in the sysfs node to let tegrastats read the
utilization value of the EMC.
Bug 4041434
Signed-off-by: Johnny Liu <johnliu@nvidia.com>
Change-Id: I2b7e6592094d27c47f738fc26ee9091ea209f630
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2912315
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
In absence of bl_debug_data parameter passed from Bootloader, value of
tegra_bl_debug_data_start will be 0.
This triggers a kernel panic on systems where parameter is not specified
and the module is loaded.
Fix this by first checking tegra_bl_debug_data_start and
tegra_bl_debug_data_size before accessing them.
Also add a check upfront to check if mandatory bootloader parameter
tegra_bl_prof_start is passed or not. If this parameter is not passed,
bail out the driver initialization.
Bug 3996651
Change-Id: Ibb78d6cefdae1f79ecb09836b833899deacb03ce
Signed-off-by: Deepak Nibade <dnibade@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2900710
Reviewed-by: Bharat Nihalani <bnihalani@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
CERT-C is reporting following issue:
- Casting cvsram_slice_data[1] from unsigned int to int without checking
its value may result in lost or misinterpreted data.
Fix this by changing the data type of slice_size.
CID 490074
Bug 3745813
Change-Id: Ic52fd016798310b69da69247a6eb2d7a626a4146
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2828530
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
In function nvcvnas_power_off casting nvcvsram_readl from unsigned int
to int without checking its value may result in lost or misinterpreted
data. Fix this by changing data type of val to u32.
CID 427418
Bug 3512545
Change-Id: I8be65b1ca73270a4a0d76380207078da745c7057
Signed-off-by: Sagar Gulab Patil <sagargulabp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2747340
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
In function nvcvnas_probe casting cvsram_slice_data[0] from unsigned
int to int without checking its value may result in lost or
misinterpreted data. Fix this by changing data type of variable.
ID 490074
Bug 3512545
Change-Id: Ia9f141f14a540f9c2c436bf605d4aec8f3489fb5
Signed-off-by: Sagar Gulab Patil <sagargulabp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2738506
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
When cvnas driver is build as OOT module, it is required
to set the following config.
CONFIG_TEGRA_FUSE_UPSTREAM
CONFIG_TEGRA_CVNAS
Set these config when CONFIG_TEGRA_OOT_MODULE is set.
Bug 3583599
Change-Id: I8deffa609cfc7abf6c9efd69405295077649c8b1
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2715735
Reviewed-by: Bitan Biswas <bbiswas@nvidia.com>
By exporting cvnas_dev all the internal data of the driver is getting
exposed to any driver that uses it. This could allow drivers to corrupt
this driver data. Hence do not export cvnas_dev, use helper functions to
get it's required member elements from nvmap.
Bug 200722684
Bug 3528414
Change-Id: I17f6fa1e98c777a7ec9118dbc6f0c6359e949f22
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2704698
Reviewed-by: Puneet Saxena <puneets@nvidia.com>
Reviewed-by: Jonathan Hunter <jonathanh@nvidia.com>
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
Handle dependencies between nvmap and cvnas driver:
- nvmap_register_cvsram_carveout function is called by cvnas driver
(builtin driver for 5.10) and it's definition is present in nvmap driver
(builtin driver for 5.10, but we are trying to make LKM). This is
resulting into build issues while making nvmap as LKM for 5.10
- One option to resolve this is by making cvnas driver as LKM for 5.10
But nvhost, nvdla, cbb are not LKM for 5.10 and are calling functions
defined in cvnas driver e.g. nvcvnas_get_cvsram_base, hence we can't
make cvnas as LKM for 5.10
- Second option is to get rid of the call nvmap_register_cvsram_carveout
from cvnas driver. This approach is implemented in this patch.
- Export cvnas_dev from cvnas driver, do not call the above function
from cvnas driver. During nvmap probe, nvmap itself would call the above
function, as cvnas_dev is exported , it's being used in nvmap driver to
get base, size etc. information, which is needed as argument to above
function, which will register the cvnas carveout in case of 5.10
Bug 200722684
Change-Id: I32e5694386de4a7fef65c3f67ffb9b5066f62ab3
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2678685
The CVNAS clock does not support dynamic frequency scaling and
it is always expected to run at max rate. When its frequency is
capped at runtime via clock_cap sysfs node, forcefully change
current rate to capped max rate.
Bug 3510538
Change-Id: I133865dbd8cfe58182dca3e6b2b969b99df393b0
Signed-off-by: Rajkumar Kasirajan <rkasirajan@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2665653
Sparse generates the following warnings for the CVNAS driver ...
drivers/platform/tegra/cvnas/cvnas.c:126:5: warning: symbol
'nvcvnas_busy' was not declared. Should it be static?
drivers/platform/tegra/cvnas/cvnas.c:138:5: warning: symbol
'nvcvnas_idle' was not declared. Should it be static?
drivers/platform/tegra/cvnas/cvnas.c:444:13: warning: symbol
'nvcvnas_get_cvsram_base' was not declared. Should it be static?
drivers/platform/tegra/cvnas/cvnas.c:456:8: warning: symbol
'nvcvnas_get_cvsram_size' was not declared. Should it be static?
drivers/platform/tegra/cvnas/cvnas.c:468:5: warning: symbol
'is_nvcvnas_probed' was not declared. Should it be static?
drivers/platform/tegra/cvnas/cvnas.c:476:5: warning: symbol
'is_nvcvnas_clk_enabled' was not declared. Should it be static?
drivers/platform/tegra/cvnas/cvnas.c:779:5: warning: symbol
'nvcvnas_busy_no_rpm' was not declared. Should it be static?
drivers/platform/tegra/cvnas/cvnas.c:793:5: warning: symbol
'nvcvnas_idle_no_rpm' was not declared. Should it be static?
There are a few problems here which are:
1. The CVNAS driver does not include the 'cvnas.h' header file and so
some of the declarations are not found.
2. Some of the CVNAS functions are not declared in the 'cvnas.h' header
file and need to be added.
3. The Tegra19x CBB driver is a user of these CVNAS functions, but
instead of including the 'cvnas.h' file it defines prototypes for
these functions. This is not necessary and so we can remove these
prototypes and simply include the 'cvnas.h' header file.
4. The function definition nvcvnas_idle_no_rpm() in the CVNAS driver is
incorrect and this function should not have any arguments passed to
it and currently does not match the prototype.
Bug 3528414
Change-Id: I7945f8c66ceb5ca5b158b7ed1b81a50f19c52bb7
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2670149
Reviewed-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
The compatible string for CVNAS devices has been updated from
"nvidia,tegra-cvnas" to "nvidia,tegra194-cvnas" to conform with the
upstream policy of stating the actual device it is supported on. The
'nvidia,tegra-cvnas-hv' has been left as-is because this is a special
case for virtualisation.
The CVNAS driver is only support for Tegra194 devices and so it is not
necessary to check the actual device variant, just the device SKU.
Finally, instead of populating platform data in the device-tree table
we can simply use the compatible string itself to detect if the device
support virtualisation.
Bug 3459526
Change-Id: I9755e8277892445b3e6772b8fa0b1960a34d90f4
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2657909
Reviewed-by: Puneet Saxena <puneets@nvidia.com>
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
When building the CVNAS driver as an external module against upstream
Linux kernels, there are some downstream fuse APIs that are not found.
To fix building CVNAS for upstream kernels ...
1. Use the device-tree machine compatibility string instead of the
downstream fuse function tegra_get_chip_id().
2. For the functions tegra_platform_is_silicon() and
tegra_platform_is_sim() add implementations in a fuse-helper.h
that always assume that platform is silicon and not a simulator.
Note this assumption is only applied to upstream kernels and
downstream kernel still use the downstream implementation. Long
term we need to revisit this.
3. Copy the downstream implementation for function tegra_get_sku_id()
to the fuse-helper.h so that this is available for upstream kernels.
The functions implemented in fuse-helper.h are only used if the compiler
flag CONFIG_TEGRA_FUSE_UPSTREAM is defined.
Bug 3459526
Change-Id: I5bbd08ac2560c236f932606ce5ad0e73dc71205a
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2650491
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
Prepare for building the CVNAS driver as a module by adding the
necessary Kconfig option. In order to build the driver as an
external module, move the source into its own sub-directory and
add it own Makefile so that it can be built independently of other
drivers.
Bug 3459526
Change-Id: I87ce24852c561144313849774d5031821b6c3a47
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2650490
Reviewed-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
