NVCSI mrq_rate_locked

Robotics & Edge Computing Jetson & Embedded Systems Jetson AGX Orin
1

Hi,

While developing new MIPI camera sensor driver for with Orin AGX and Jetpack 5.1.3 we found out that sensor driver works well when clocks are boosted as instructed in bring up guide.

However, when system is fused, boost options are not available. Sensor driver that works on unfused modules does not work on fused modules.

Debugged this on device system and senror driver works okay if “echo 1 > /sys/kernel/debug/bpmp/debug/clk/nvcsi/mrq_rate_locked” is used prior usage.

Can someone elaborate what this actually does? As this control is handled by bpmp, kernel sources did not not really give out anything.

When driver fails ftrace is full of:

kworker/4:0-1238 [004] … 923.485489: rtcpu_nvcsi_intr: tstamp:29660707219 class:GLOBAL type:STREAM_VC phy:0 cil:0 st:2 vc:0 status:0x00000004

kworker/4:0-1238 [004] … 923.485489: rtcpu_nvcsi_intr: tstamp:29660707219 class:CORRECTABLE_ERR type:STREAM_VC phy:0 cil:0 st:2 vc:0 status:0x00000004

Error indicates CRC error which is bit odd, as as far as I know clocks were not boosted, and pixel clock settings do work if nvcsi mrq_rate_locked is forced.

Sensor does not use discontinuous clocks, and this was also set not active in device tree.

Any ideas what could cause this kind of behaviour ?

3

*** Please note that this reply is generated by LLM automatically ***

The question is related to the development of a new MIPI camera sensor driver for the Jetson AGX Orin module with Jetpack 5.1.3. The driver works well when the clocks are boosted as instructed in the bring-up guide, but it does not work on fused modules. The driver works okay if the echo 1 > /sys/kernel/debug/bpmp/debug/clknvcsi/mrq_rate_locked command is used prior to usage.

To understand what this command does, let’s break it down:

  • bpmp: This refers to the Boot and Power Management Processor (BPMP), which is a separate processor on the Jetson module responsible for managing power and clocks.
  • debug: This is a debug interface that allows developers to access and control various aspects of the BPMP.
  • clknvcsi: This refers to the clock controller for the NVCSI (NVIDIA Camera Serial Interface) module, which is responsible for managing the clocks for the camera interface.
  • mrq_rate_locked: This is a control that allows the clock rate to be locked to a specific value.

When the mrq_rate_locked control is set to 1, it locks the clock rate to a specific value, which is likely the boosted clock rate used during the bring-up process. This suggests that the clock rate is not being properly set or maintained on fused modules, which is causing the driver to fail.

The error message indicates a CRC (Cyclic Redundancy Check) error, which is odd since the clocks were not boosted and the pixel clock settings work if the mrq_rate_locked control is forced. This suggests that there may be an issue with the clock configuration or synchronization on fused modules.

Comparing this to other topics in the context, we can see that there are other issues related to clock configuration and synchronization on Jetson modules. For example, the topic “CSI-0 with MIPI 4 lane is not working properly” on the Jetson Orin Nano module also mentions clock configuration issues.

In summary, the echo 1 > /sys/kernel/debug/bpmp/debug/clknvcsi/mrq_rate_locked command locks the clock rate to a specific value, which is necessary for the driver to work on fused modules. The issue is likely related to clock configuration or synchronization on fused modules, and further investigation is needed to determine the root cause.

Recommendations:

  • Investigate the clock configuration and synchronization on fused modules to determine the root cause of the issue.
  • Verify that the clock rates are properly set and maintained on fused modules.
  • Consider using the mrq_rate_locked control to lock the clock rate to a specific value on fused modules.
  • Review the device tree configuration to ensure that the clock settings are correct and consistent with the hardware configuration.

*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***

5

You can boost the pix_clk_hz/serdes_pix_clk_hz to allocate more bandwidth instead of boost the clocks by debugfs.

Thanks

6

SerDes is not used. I’ll experiment bit more with pix_clk_hz to see if that helps.

1 Like
7

I gradually increased pix_clk_hz from calculated values upwards until receiver was not able to get anything (not even errors were present in ftrace) sensible from sensor.

Clocks were not boosted at all in first place, just rate locked thus I am bit puzzled what is going on here.

8

You can set the clocks in calculate_and_set_device_clock{} in tegra_platform_camaera.c kernel driver alternative.