In NUMA system, user can request nvmap to allocate from any particular
node using NvRmMem APIs. Add code to request allocation from such
requested node. While allocating pages from page pool, check if those
pages belong to requested NUMA node. In some cases, we may not need to
use NUMA support e.g. in color pages allocation code, we don't need to
use NUMA, as page coloring is needed only for t19x chips.
JIRA TMM-5287
Bug 4043165
Change-Id: If8043278122068773a802d83723d287d32914e14
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2889707
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
Reviewed-by: svc-mobile-cert <svc-mobile-cert@nvidia.com>
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
CBC carveout is not the correct carveout name, rather compression
carveout is the correct name. Compresssion carveout is used to store the
gpu compressible buffers. While the comptags and other metadata related
to these buffers will be stored in CBC carveout which is a GSC carveout
not created/maintained by nvmap. Hence update carveout naming.
Bug 3956637
Change-Id: I50e01a6a8d8bda66960bdee378a12fde176b682a
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2888397
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
Reviewed-by: svc-mobile-cert <svc-mobile-cert@nvidia.com>
Reviewed-by: svcacv <svcacv@nvidia.com>
Reviewed-by: Krishna Reddy <vdumpa@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Add clock capping driver which can be used to cap the max freq of the
specified clocks via Common Clock Framework (CCF) directly. The exposed
sysfs nodes can be used to ensure the clock running within the
predefined frequency cap in selected power mode.
As bandwidth manager is implemented in BPMP, the EMC max freq capping
request should be approved by BPMP. Therefore, there is MRQ call to BPMP
when there is new EMC max freq capping request.
Please note that the request will be rejected by BPMP when EMC current
freq is higher than requested capping freq. On BPMP MRQ failure, the
driver will try to restore previous EMC max freq in CCF. On CCF failure,
the driver will try to remove the cap on EMC max freq.
Bug 3997304
Bug 3972888
Signed-off-by: Yi-Wei Wang <yiweiw@nvidia.com>
Change-Id: Iff574ff5e529119c65a9af2456241d9102bd7956
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2878601
Reviewed-by: Rajkumar Kasirajan <rkasirajan@nvidia.com>
Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
SOC_THERM is the primary hardware component of Tegra on-die thermal
management strategies. SOC_THERM includes the function of
externally-signaled event detection (SOC_THERM_edp) which centralizes
a few mechanisms for detecting and responding to externally signaled
electrical events, such as overcurrent events, undervoltage events, and
so on. These are known as "OC alarms" because they often indicate an
overcurrent event.
The Jetson Module's on-board power monitor INA3221 is configured to
trigger CPU/GPU hardware clock throttling via Tegra234 SOCTHERM_OC when
the Module input current exceeds the preprogrammed overcurrent threshold
to keep Module power consumption within the TDP power budget.
CPU/GPU performance may drop when hardware clock throttling occurs.
To allow the user to infer whether the performance degradation is
related to the overcurrent event, the Tegra234 OC event driver is
implemented which sends a Message ReQuest (MRQ) to the BPMP firmware to
provide information regarding the overcurrent enable state and the event
count to userspace via the hwmon sysfs interface.
Bug 3571683
Signed-off-by: Yi-Wei Wang <yiweiw@nvidia.com>
Change-Id: I6cc3579944efc92916189f097ccfed2ccba26051
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2862007
Reviewed-by: Rajkumar Kasirajan <rkasirajan@nvidia.com>
Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Issue: MACSEC is not enabled in DT for eqos_1 and mgbe2_1
interfaces which makes macsec_pdata pointer to NULL.
During suspend/resume macsec_pdata pointer accessed without
NULL check which resulted in crash.
Fix:
o Add NULL pointer checks for macsec_pdata in suspend and resume.
o Remove unnecessary checks for macsec in suspend and resume.
Bug 4060718
Change-Id: I00e042d979e115c088696a8964496ed0054360e5
Signed-off-by: Revanth Kumar Uppala <ruppala@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2888289
Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Add ar0234 camera sensor driver code,
max96712 GMSL serializer code, mode tables
and makefile changes. These drivers are copied
from K5.10 camera driver repo. Changes include
svcacv warning fix and eeprom read status is
ignored due to bug 4064490.
Bug 3583587
Bug 4064490
Change-Id: I7ea0ecf959caccafd283c8db5fb7c3be912cf8bb
Signed-off-by: Ankur Pawar <ankurp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2868422
Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Merge the nvdla driver and header sources with change history from
'origin/dev/ldewangan/nvidia-nvdla-dev-main'
into
nvidia-oot-dla-dev-main
Bug 4038415
Change-Id: I2fa6256af1c3d39a17fbb6b00ec97da5113e30cd
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
It is possible that we received the ACK from DCE even before we
start waiting. But currently we are clearing the "complete" state
before start waiting, which may result in missed interrupt.
This patch removes the clearing of complete state before wait.
Also Adds few comments for better understanding.
Bug 3941557
Change-Id: I7d2efb1a64eb6f2d4df1876add07a8f019b449f5
Signed-off-by: Mahesh Kumar <mahkumar@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2845498
Reviewed-by: svcacv <svcacv@nvidia.com>
Reviewed-by: svc_kernel_abi <svc_kernel_abi@nvidia.com>
Reviewed-by: Arun Swain <arswain@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
The current code doesn't notify DCE IPC after DCE IPC is in ACK state
Current Flow:
CPU DCE
1: tegra_ivc_init ---------
2: DCE_ADMIN_CMD_IPC_CREATE tegra_ivc_init
3: --------- tegra_ivc_channel_reset
dce:SIVC_STATE_SYNC
cpu:ESTABLISHED
4: tegra_ivc_reset
dce:SIVC_STATE_SYNC ---------
cpu:SYNC
5: Notify() tegra_ivc_channel_notified
dce:SIVC_STATE_ACK
cpu:SYNC
6: tegra_ivc_notified ---------
dce:SIVC_STATE_ACK
cpu:ESTABLISHED
After Step 6 DCE state is in ACK state and CPU state is in ESTABLISHED
state. As there is no further cpu->dce notification in RM_NOTIFY
channel, dce state stays in the "ACK" state and any attempt to send msg
on RM_NOTIFY channel from dce->cpu fails.
This patch notifies dce after step-6, So dce channel is also in the
"ESTABLISHED" state.
If steps 3-6 get executed in CPU before Step 5 in DCE gets a chance
to execute (DCE is slow), the CPU IPC state will change to "established".
Now when step 5 will execute in DCE, it'll see the CPU state as
"established" so, It'll make the DCE state also "established".
That's how it's working today.
Bug 3861985
Signed-off-by: Mahesh Kumar <mahkumar@nvidia.com>
Change-Id: Ieb13f525d3f81b30aaae848d8d5adb1106856b65
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2840065
Reviewed-by: svcacv <svcacv@nvidia.com>
Reviewed-by: Arun Swain <arswain@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
While MST is used, We get two async msgs from DCE and schedule 2 worker
threads, But during processing (dce_client_process_event_ipc) of these
messages, We are processing all the pending messages in one go. So,
while the second worker thread is scheduled, there is no new message
to read.
This Patch fixes the loop to try reading only when there is a new msg to
read. Also convert info print to debug, to avoid print noise.
Bug 3801736
Signed-off-by: Mahesh Kumar <mahkumar@nvidia.com>
Change-Id: Iddf9ea8f0194539baa8c52616e2f836527400176
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2810440
Reviewed-by: svcacv <svcacv@nvidia.com>
Reviewed-by: svc_kernel_abi <svc_kernel_abi@nvidia.com>
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
Reviewed-by: svc-mobile-cert <svc-mobile-cert@nvidia.com>
Reviewed-by: Arun Swain <arswain@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
of_irq_xxx faimly of functions are not exported by Kernel.
use platform_irq_count and platform_get_irq APIs instead.
This patch also moves dce_platform_data elements to dce_device
struct to keep dce_platform_data constant.
Bug 3581824
Signed-off-by: Mahesh Kumar <mahkumar@nvidia.com>
Change-Id: I5ea13ea039ef1464e678f0604a045a6ab67bc16f
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2755141
Reviewed-by: Santosh Galma <galmar@nvidia.com>
Reviewed-by: svcacv <svcacv@nvidia.com>
Reviewed-by: svc_kernel_abi <svc_kernel_abi@nvidia.com>
Reviewed-by: Arun Swain <arswain@nvidia.com>
GVS: Gerrit_Virtual_Submit
- when there are multiple async events back to back from DCE with very
short time gap between 2 events(for example, in case of DP MST,
2 heads could be sending flip event notification back to back at
almost same time), there is a possibility of 2nd async event getting
processed very late when shared mailbox register is set to zero as part
of processing 1st async event and before processing of 2nd async event.
- current change fixes it by processing all pending IVC frames for IPC
channel when processing an async event.
- change few error logs to info logs as these are not actually errors.
Bug 3582863
Bug 3429668
Change-Id: I29b1813bed50c4583e37f02bf656802081ccf9d3
Signed-off-by: Santosh Reddy Galma <galmar@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2698560
(cherry picked from commit dd1abfa6eaab6e4f599d8c97bdccc7cbb67e1341)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2700438
Reviewed-by: svcacv <svcacv@nvidia.com>
Reviewed-by: svc_kernel_abi <svc_kernel_abi@nvidia.com>
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
Reviewed-by: svc-mobile-cert <svc-mobile-cert@nvidia.com>
Reviewed-by: Arun Swain <arswain@nvidia.com>
GVS: Gerrit_Virtual_Submit
