In Linux v6.11, the 'platform_driver' structure 'remove' callback was
updated to return void instead of 'int'. Update the MODS drivers as
necessary to fix this. Note that we can simply remove the mods_dmabuf
'remove' function because it does nothing.
Bug 4749580
Change-Id: I8ac05a7b713916b9aca1694ca828682808df3287
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3235514
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Chris Dragan <kdragan@nvidia.com>
Reviewed-by: Carl Dong <carld@nvidia.com>
Only Tegra234+ devices are currently supported and for these devices the
only DMA drivers that are supported for Linux are the Tegra210 ADMA and
Tegra186 GPCDMA drivers. Neither of these drivers ever supported the
'slave_id' parameter for configuring the DMA request ID for a given
channel. These drivers have always used device-tree to retrieve this
information. Only the Tegra20 APBDMA controller supported the 'slave_id'
field and this was dropped in Linux v5.17. The Tegra20 APBDMA driver was
supported in Tegra devices up until Tegra210, but starting with Tegra186
it is no longer supported.
Given that this is a legacy feature only supported for legacy Tegra
devices and drivers, drop the 'slave_id' support completely.
Bug 4425688
Change-Id: Id9bb6440805826dfb0cf0d862d6b15fd856e61ff
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3038964
Reviewed-by: svcacv <svcacv@nvidia.com>
Reviewed-by: Chris Dragan <kdragan@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
For upstream dma engine slave_id in <struct dma_slave_config> is obsolete.
The Correct way to specify slave_id is
to call dma_request_chan API along with device name defined in dts node.
mods_tegra_dma: mods_tegra_dma {
compatible = "nvidia,mods_tegra_dma";
dmas = <&gpcdma 15>, <&gpcdma 16>;
dma-names = "spi1_rx", "spi2_tx";
status = "okay";
};
To keep kernel ABI compatibility,
add a new ioctl cmd MODS_ESC_DMA_REQUEST_HANDLE_2.
A new struct MODS_DMA_HANDLE_2 is used together with it.
A new function esc_mods_dma_request_channel_2 is implemented accordingly.
JIRA:TM-728
Change-Id: Ic84f294e2248d800b9aacd597a7ce0a84fc94a1d
Signed-off-by: andersm <andersm@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2711537
Signed-off-by: xueyuanb <xueyuanb@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2753148
Reviewed-by: Chris Dragan <kdragan@nvidia.com>
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
Reviewed-by: svc-mobile-cert <svc-mobile-cert@nvidia.com>
Reviewed-by: Bitan Biswas <bbiswas@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
* Add new cl_* macros for printing client-specific messages.
This adds client index to messages in code which is called from
user space. This makes it easier to diagnose errors when multiple
clients (processes) open the driver.
* Use kernel print levels appropriate to messages being printed.
* Print process pid when opening the driver.
* Print information about access token being set or released.
* Print information about PCI devices being enabled or disabled.
PCI device enablement is tied to the driver getting ownership
of the device. It also prevents multiple MODS instances from
owning the same PCI device.
* Print info about device DMA mask, print device DMA mask when DMA
mapping fails.
* Print more info about SRIOV actions.
* Disable SRIOV when the driver is being closed by the process
which enables SRIOV. Leaving SRIOV enabled when disabling PCI
device is an error and leads to stale functions, unusable on
subsequent MODS runs.
* Clean up log messages in a few places.
Change-Id: I51953e984a55c0990e90f89d8260f215c8c58498
Signed-off-by: Chris Dragan <kdragan@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2279439
Tested-by: Ellis Roberts <ellisr@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Bharat Nihalani <bnihalani@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
