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>
Camera fsync signal Driver provides following features.
- Configures and runs TSC generator to provide fsync signal to the
camera module
- FSYNC signal is programmed as specified in DT for freq and offset
- Start time of fsync signal can be specified or default
value can be used
- Default value used will be 10ms in future
- If start time is provided, value must be provided in TSC ticks unit
- Read DT, if tsc-gen-groups are specified, init & expose node for
each group
- Each generator in group is configured
- IOCTL interface is exposed to accept start time and start the generator
- Sanity check is done to ensure, no generator is part of multiple groups
- Backward compatibility is maintained
JIRA CAMERASW-11902
Bug 3799488
Change-Id: I4f278eb95b8f85edb2d5e7664c9f2dd694437263
Signed-off-by: Mohit Ingale <mohiti@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2898373
Reviewed-by: Bhushan Rayrikar <brayrikar@nvidia.com>
Reviewed-by: Frank Chen <frankc@nvidia.com>
Reviewed-by: Shiva Dubey <sdubey@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
The tegra_wmark governor can be used e.g. with DRM clients, such as VIC,
NVDEC, NVENC, and NVJPG. This governor tightly collaborates with the
actmon hardware used for monitoring the active time of the underlying
DRM clients.
Bug 3788919
Signed-off-by: Johnny Liu <johnliu@nvidia.com>
Change-Id: Ie4d4c2b173615aa239436fbb1545118435629d38
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2894529
Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Fix build errors when this driver compiled against K6.1 (kernel-oot)
- Remove dma-iommu.h header inclusion as its not present in K6.1
- Define IOVA_RANGE_CACHE_MAX_SIZE if this macro is not defined
- Import DMA_BUF "MODULE_IMPORT_NS(DMA_BUF);" to avoid below error
"ERROR: modpost: module nvscic2c-pcie-epc uses symbol dma_buf_* from
namespace DMA_BUF, but does not import it"
Bug 3978996
Change-Id: Idd9a53b19c63467583b87f64ffa2c2e888ac02e1
Signed-off-by: Shardar Mohammed <smohammed@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2898149
Reviewed-by: Deepak Kumar Badgaiyan <dbadgaiyan@nvidia.com>
Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Issue: skb_vlan_tag_get gives only the VLAN_ID for
the earlier kernel versions (K4.9) and hence added
a logic to take care of adding the VLAN priority
explicitly and hence the VLAN priority getting
modified in a newer kernel version where VLAN PRIO is
already included
Fix: remove the logic of explicit adding of VLAN
priority.
Bug 3788862
Bug 4088361
Change-Id: I0ac9ebfe21d3e696ac1b0f6ba540c010928f775f
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2806468
(cherry picked from commit 799b17fc35f3bc3ec75ea93452c03bd52ed28527)
Signed-off-by: Narayan Reddy <narayanr@nvidia.com>
Signed-off-by: Revanth Kumar Uppala <ruppala@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2895043
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Issue:
During eth0 down case, the link change gets called twice,
1. due to ndo close
2. due to interrupt generated by phy.
The ether_adjust_link callback also configures the EEE settings
and calls phy_init_eee (a phy framework API) for the same.
Here a race condition occur, when ether_close sets phydev to NULL
before the phy_init_eee gets called (from ether_conf_eee) which tries
to deference the phydev causing kernel panic.
[35779.541305] Call trace:
[35779.544018] phy_init_eee+0x24/0x290
[35779.547455] ether_conf_eee+0x110/0x1310 [nvethernet]
[35779.552525] ether_conf_eee+0x4e0/0x1310 [nvethernet]
[35779.557840] phy_link_change+0x40/0x90
[35779.561603] phy_state_machine+0x190/0x240
[35779.565643] process_one_work+0x1c4/0x4d0
[35779.569396] worker_thread+0x54/0x430
[35779.573072] kthread+0x148/0x180
[35779.576586] ret_from_fork+0x10/0x34
[35779.580069] Code: a90153f3 d5384113 a9025bf5 12001c36 (f941b801)
[35779.586195] ---[ end trace 2ea5b6492f36b0cb ]---
[35779.590737] Kernel panic - not syncing: Oops: Fatal exception
Fix:
Add a NULL check and return -ENODEVICE in EEE configuration
Bug 3877272
Bug 3920560
Bug 3865666
Bug 4088361
Change-Id: I2b26c6eeabb7a109b9d14b3bd2a035f5c3b3c6fa
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2854404
(cherry picked from commit 40606dc247eacf2a8987687777874575d9037058)
Signed-off-by: Sushil Kumar Singh <sushilkumars@nvidia.com>
Signed-off-by: Revanth Kumar Uppala <ruppala@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2855237
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
