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>
In Linux v6.11, the 'platform_driver' structure 'remove' callback was
updated to return void instead of 'int'. Update the Tegra264 memory
drivers as necessary to ensure that they can be built for Linux v6.11+
kernels.
The mem-qual driver is missing the vmalloc.h header file and this also
causes the build to fail for Linux v6.10+ kernels to fail.
Finally, remove the version.h file from the mem-qual driver as this is
not needed.
Bug 4749580
Change-Id: I2f6273dff68fddf0d4eff4c2f4d57c445b3de291
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3235930
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Brad Griffis <bgriffis@nvidia.com>
Allocate the buffer based on the request instead of a fixed buffer
length. In operations which may require larger buffer size, a fixed
buffer may fail. Similar patch was added for AES algorithms. Fix the
same for HASH algorithms as well.
Bug 4908156
Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
Change-Id: Idd2c1ceae1a85434a5a51154a17dce8c927bb66c
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3233718
Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
The 'core_init_notifier' has been removed from the pci_epc_features
structure in Linux v6.10. Given that this is a static structure and it
is initialised as 'false', we don't need to explicitly initialise this
because it will always be initialised as 'false' by default for kernels
that support this.
Bug 4787193
Bug 4593750
Change-Id: Ic2abaa3d2ab1a5c766a805936fd8ab394214bf42
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3233999
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Add support to query handle parameters For a foreign fd pointing to a
buffer created by OpenRM. Protect the code inside a config. Minimal info
is provided like buffer size and alignment. Other info is not required
as per the discussion with VIC and NvMM team.
Bug 4699600
Change-Id: I286a7f13d5ce33290b72748c9a745164fdff78ea
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3181574
Reviewed-by: Pritesh Raithatha <praithatha@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
In Linux v6.4, the module pointer argument is removed from the
class_create() function. Add a test to the conftest script that checks
if this argument for the class_create() function has been removed and
use the definition created by conftest to select which version of the
function is used.
Bug 4183168
Bug 4221847
Change-Id: Ic1aef0216eae64b32273dc085b8b8306d1235d9b
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3234808
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Add a loadable module for mem-qual STG IP client.
- This driver exposes following device nodes under /dev.
qualdev-0, qualdev-1, qualdev-2, qualdev-3, qualdev-4
- This driver provides 2 ioctls, one is to alloc a buffer and create
IOVA for it by mapping the buffer into the IOVA space of the respective
device.
- Second ioctl is to free the IOVA mapping and pages associated with the
buffer.
- Users of this driver will open the mem qual device node and then call
the first ioctl with size of the buffer as input during init time and
receive the IOVA.
- During deinit time, users will call the second ioctl with the IOVA as
input and the ioctl will free the IOVA mapping and buffer.
Bug 4546339
Change-Id: Idc7279ecf5118de5dbde100d40877150fef29ca5
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-t264/+/3145175
Reviewed-by: Pritesh Raithatha <praithatha@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
MCB aperture is already ioremapped in MC driver using
devm_ioremap_resource(). This doesn't allow other driver to ioremap
this aperture using devm_ioremap* calls.
mc-t26x driver need to access MCB aperture to get carveout info.
So, fix this by using just ioremap on aperture without using devm*
APIs.
Also, fix the carveout apertures.
Bug 4707077
Change-Id: Ie7426ad3519306dd4dffdf54e4c58e81f3c8fb34
Signed-off-by: Ashish Mhetre <amhetre@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-t264/+/3158697
Reviewed-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Update compatible string in mc-utils driver to use
nvidia,tegra264-mc-utils instead of nvidia,tegra-t26x-mc, as we want a
separate DT node for mc-utils and dram_channels property would be added
in that DT node, which is required for HV+L case.
Bug 4090660
Change-Id: I9f988da4b264738d66b329d478b231bf36e71a18
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-t264/+/3138031
Tested-by: Richard Zhao <rizhao@nvidia.com>
Reviewed-by: Pritesh Raithatha <praithatha@nvidia.com>
Reviewed-by: Ashish Mhetre <amhetre@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Update mc-err driver for t264 as per the latest flow provided by HW
team.
- Correct register offsets.
- Add mc-error handling flow for MCF, HUB, HUBC, SBS and MC Channel.
- Register interrupt handlers for interrupts from these different
MSS components.
Bug 4345191
Change-Id: Ic0746949a92bebd545bf69f585d48b5c5818cd13
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-t264/+/3131096
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
No client need the dram_clk_to_mc_clk, tegra_dram_types functions from
mc-utils. Hence remove these functions.
get_dram_num_channels is needed by resman team, hence update it to
return number of channels for t264.
Bug 4090660
Change-Id: I3e7571be73cfd94b3e2feebb6320a57b46b5fd48
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-t264/+/3047611
Reviewed-by: Pritesh Raithatha <praithatha@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
The compiler option -Wmissing-prototypes is being enabled globally in
the upstream Linux kernel and this causes build failures. The build
failures occur because either the driver is missing an include file
which has the prototype or because the function is not declared
statically when it should be (ie. there are no external users).
Fix the various build failures that are seen when enabling
-Wmissing-prototypes.
Bug 4404965
Change-Id: I0f9189250655c3b3006909e51ffe3aca7fbf763b
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-t264/+/3028738
Reviewed-by: Akhil R <akhilrajeev@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Cert-C is flagging following issue in mc-err code:
cert_exp33_c_violation: Using uninitialized value status_reg when
calling mc_ch_readl.
Fix the above issue by adding a default case for MC interrupt mask and
return from there by printing the error.
CID 681739
Change-Id: I6dfaa8e830b6b3545c0018a3ebaf2d1f208a1347
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-t264/+/2950862
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Add support for mc-err driver on T264. Maintain driver similar to
current upstream mc-err driver, so that upstreaming diff for T264 would
be straight forward. Current IRQ handling logic is as follows:
- Read MCF int status from MCB
- Find out the MC channel responsible for generating error
- Read address register from that MC channel block to get the address
- Find out type of error from status register
Current implementation is as per the information received so far,
further updates will be made once HW team provide programming
guidelines.
Bug 3846055
Change-Id: I71508a88521e8b5c3d046b087efe4baf2769ceb3
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-t264/+/2929112
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
Reviewed-by: Ashish Mhetre <amhetre@nvidia.com>
Reviewed-by: Pritesh Raithatha <praithatha@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
mc-t26x driver was not getting built because it's entry was missing in
kernel-src-files-copy-list.txt. Add files required for mc-t26x in
kernel-src-files-copy-list.txt.
Also, move the mc-t26x driver to a private-soc directory to build
separately from existing files in memory/tegra directory.
Bug 3960743
Change-Id: I71a6271dcc5c962630a3c939f84ba0b511cae4dd
Signed-off-by: Ashish Mhetre <amhetre@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-t264/+/2914088
Reviewed-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
As per info received from HW team, we should not hardcode 1600 in DRAM
clock to MC clock conversion function. DRAM clk to EMC clk ratio is
always 4:1 while EMC clk to MC clk ratio can be found in CAR register
CLK_RST_CONTROLLER_CLK_SOURCE_EMC_0.MC_EMC_SAME_FREQ bit.
If it's 0 then MC frequency is half of EMC frequency, otherwise MC freq
is same as EMC freq. Hence update DRAM clock to MC clock function as per
above logic.
Bug 4090660
Change-Id: I5a7586aeee29fe1c98437cf0dd5b820d8f540072
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-t264/+/2915138
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
mc-utils driver should support the following functionality on T264.
Update mc-utils driver for these functionalities for T264:
- EMC freq to BW conversion
- BW to freq conversion
- DRAM clock to MC clock coversion
Bug 4090660
Change-Id: If5ee54d49024d03620dad01049fe35bbcaf3f812
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-t264/+/2900181
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
mc-utils driver support is needed on T264, and it should be present in
nvidia-t264 repo, so as to avoid leaking any information. Also, we need
to make sure once T264 is public the existing mc-utils driver can be
updated easily for T264 support.
Hence first copy the existing mc-utils driver from nvidia-oot into
nvidia-t264, then make changes for T264 and finally when T264 is public,
just cherry-pick the addional changes in nvidia-oot and clean up driver
from nvidia-t264. This change is doing the first step i.e. copying
existing mc-utils driver code from nvidia-oot into nvidia-t264.
Bug 4090660
Change-Id: I95eff8d3f7fef267a5c0f0e2137c4343a615d4aa
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-t264/+/2911970
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
