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>
Remove some of the files which were added as optional for
non-existing of T264 patches. As T264 OOT drivers are
collapsing into the core tree, remove such optional files.
Change-Id: I83116585369f4893d14b527356752fbf2a9a80c8
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
- Revamp the core logic to use the portability layer.
- Introduce ping debugfs node.
Bug:
- Update the abort retry logic for -EAGAIN error code. In
the absence of this logic, the queue becomes unavailable
due to race between the reset and the flush command.
Jira DLA-7294
Jira DLA-7310
Change-Id: I9f54f14334736189a00d2236f374188c2bac6155
Signed-off-by: Arvind M <am@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3196673
Reviewed-by: Akshata Bhat <akshatab@nvidia.com>
Reviewed-by: Ken Adams <kadams@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
[1] In the event of busy CPU, the delayed interrupt or the
delayed callback from nvhost will result in the submission
failure.
[2] This commit fixes the issue by performing mandatory and controlled
cleanups.
- Atmost 2 slots are cleaned up prior to the submission.
- Complete queue cleanup during the suspend preparation.
- Complete queue cleanup after successful abort operation.
[3] Additionally, the commit fixes some potential leaks in the error
path.
Bug 4503438
Bug 4414867
Change-Id: Ic40f0c4b1f3c653d5d5e613adab01d3cbc3b9722
Signed-off-by: Arvind M <am@nvidia.com>
Signed-off-by: Akshata Bhat <akshatab@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3105861
(cherry picked from commit 438e8f8e96483971798e2d9014ed4a999143d082)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3120798
(cherry picked from commit 5668f6439643d44b3384bcd750a645d8db6ee0c9)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3196672
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Ken Adams <kadams@nvidia.com>
Skip T264 PCIE drivers for the few kernels like jammy-src, rhivos-1 and
stable.
Bug 4911768
Change-Id: I198fb279712594a69950b72d6b8f14a9ef151e5f
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
To avoid the duplicate function defintion between the header and
source, use the proper config to protect it.
Bug 4911768
Change-Id: I8d6880833c122eb2eb7194929eb5ea2cb78a9c45
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Add support for handling the PEX WAKE GPIO (pex_wake_gpiod) by
parsing the pex-wake GPIO from the device tree and setup the
interrupt line.
Enable and disable the wake-up interrupt during system
suspend/resume.
Bug 4788812
Change-Id: Ie8936aa9cc551db1a5d24b277b091de5fbc0439e
Signed-off-by: Revanth Kumar Uppala <ruppala@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-t264/+/3212875
Reviewed-by: Bibek Basu <bbasu@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
When Root port applies secondary bus reset(SBR) or link disable, EP_RESET
interrupt is received at Endpoint. On EP_RESET poll for detect reset LTSSM
state which confirms that SBR reset released or link disable is cleared.
After polling perform Endpoint controller cold reset.
Due to HW bug 4777981, C2 x2/x1 LTSSM state doesn't move to detect reset
when SBR reset is released, instead it stays in hot reset state. In this
case perform Endpoint controller cold reset after poll timeout. PCIe link
still comes up in this case.
Bug 4777981
Bug 4785875
Change-Id: I89402aa7c963082510170b88a1f7a4ec481162be
Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-t264/+/3197116
Reviewed-by: Nagarjuna Kristam <nkristam@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Bibek Basu <bbasu@nvidia.com>
Issue:
When XDMA interrupt is received and only error is set, interrupt is not
processed resulting in DMA HW halt and no further transfers working.
Fix:
Process XDMA irq, when either transfer complete or error status is set.
Bug 4747322
Change-Id: Ic71f3bf93343e986a1f4be9b570bcc36f03afeeb
Signed-off-by: Nagarjuna Kristam <nkristam@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-t264/+/3175952
Reviewed-by: Bitan Biswas <bbiswas@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Tegra DMA driver functions are defined in nvidia-t264 repo and these
functions are used in nvidia-oot repo. Prototypes of these functions
are defined in nvidia-oot repo header file tegra-pcie-dma.h. Enable
CONFIG_PCIE_TEGRA_DMA flag to expose the function prototypes to the
drivers in nvidia-oot repo. This functions should be exposed only if
nvidia-t264 drivers are included in kernel compilation.
Bug 4712065
Change-Id: I74bb98bd9efbf2e36ed05aae866760a92a4ee7dd
Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-t264/+/3164961
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Nagarjuna Kristam <nkristam@nvidia.com>
Reviewed-by: Bibek Basu <bbasu@nvidia.com>
When PCIe link is disabled or secondary bus reset is done by RP,
EP LTSSM state goes to link disable or hot reset respectively.
Update the LTSSM state check accordingly to support link disable
and secondary bus reset.
XTL_EP_PRI_BAR_CONFIG and XTL_EP_PRI_RESIZE_BAR1 are part of
hot reset domain, when link is going through hot reset, these
registers are not accessible. So, remove these register programming
in tegra264_pcie_ep_clear_bar(). After hot reset these registers
come back with reset values.
Bug 4712053
Change-Id: Ieaf37ed9fed6722db8a16027947121b1cfd1ef4c
Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-t264/+/3163927
Reviewed-by: Bibek Basu <bbasu@nvidia.com>
Reviewed-by: Nagarjuna Kristam <nkristam@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
When XDMA error is observed driver resets the XDMA engine.
xdma_ll_ch_init() function is called to reinitialize the
XDMA engine. Incorrect value is passed as the argument for
channel type. Fix this issue by using correct variable for
channel type.
Bug 4707453
Change-Id: Ic06563d599bfd7c0979c9db0a20cebeaa18fe3c8
Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-t264/+/3163925
Reviewed-by: Nagarjuna Kristam <nkristam@nvidia.com>
Reviewed-by: Bibek Basu <bbasu@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
