Enabling extperiph1/2 output

Hello,

I’m working with an Orin Nano, L4T version 35.4.1, custom carrier board.

I try to get the following clock outputs:

  • pin 116: CAM0_MCLK = EXTPERIPH1_CLK
  • pin 122: CAM1_MCLK = EXTPERIPH2_CLK

If I use the debugfs interface and run:

echo 3187500 > /sys/kernel/debug/bpmp/debug/clk/extperiph1/rate # 3187500 is the min_rate value
echo 1 > state

Then the output of /sys/kernel/debug/bpmp/debug/clk/clk_treeis:

clock on rate bpmp mrq vdd
extperiph1 1 3187500 1 0 vdd_core@644734

But when I probe with the scope, I see no signal.

I tried from a custom kernel module to run:
devm_clk_get(dev, "extperiph1")
But I always get an an invalid pointer, containing the error code -2 (No entry).
The kernel log does not report any message otherwise.

Same overall situation with extperiph2.

There is no extra circuitry on the carrier board: I measure directly the signal which comes out of the Jetson module.

  • Is the debugfs effective to enable and update the frequency of these clocks? If yes, any idea why I get no output?
  • Any idea why I fail to get the clock from the kernel API?

Best regards

hello maxe777,

is it dual camera use-case?
please refer to Jetson Orin NX Series and Orin Nano Series Design Guide,
you may see-also [Table 10-2], [Figure 10-1], and [Figure 10-2] to review camera hardware pin connections.

furthermore,
you may also check dual-cam reference driver for software implementation.
for example,
$public_sources/kernel_src/hardware/nvidia/platform/t23x/p3768/kernel-dts/cvb/tegra234-camera-rbpcv2-imx219.dtsi

Hi @JerryChang ,

Ultimately, we will most likely use these clocks in a dual camera configuration, but one of the clock may be use to clock a different chip.

At the moment, irrespectively of connecting a camera, we wanted to validate if the target frequencies can be reached, and be able to check the waveforms.

Even if a typical use case if to use the extperiph clock as mclk for cameras, our understanding is that they can be used independently of MIPI operation.

This is what we a trying to do and we are a bit confused that we could not get a signal on the pin.

Please let me know if our understanding is not correct.

Thank you

For reference, this is the NVidia materials I used: Clocks — Jetson Linux Developer Guide documentation

I tried both:

  • the debugfs interface
  • the kernel API

without success.

Please note that the question is only about enabling the clock on the output pin, not about it’s integration in the tegra camera framework.

Looking forward to your inputs.

hello maxe777,

for evaluation,
could you please try 40-Pin Expansion Header, it’s pin-29 as extperiph3 and pin-31 as extperiph4.
you may also have Pinmux and GPIO Configuration to update the pin settings.

Hi @JerryChang,

Thanks for this suggestion, but I do not have an eval kit at hand and it does not answer any of the questions.

For whoever who may wonder the same, here are my findings:

  • to go over the kernel API, add the required entries to the device tree. For instance:
clocks = <&bpmp_clks TEGRA234_CLK_EXTPERIPH1>, <&bpmp_clks TEGRA234_CLK_PLLP_OUT0>;
clock-names = "mclk", "parent";
  • Then you can use these entries as follow (I’m omitting the error checking here for conciseness):
struct clk* mclk = devm_clk_get(dev, "mclk");
struct clk* pclk = devm_clk_get(dev, "parent");

clk_prepare(mclk);
clk_set_parent(mclk, pclk);
clk_set_rate(mclk, 37125000);
clk_enable(mclk);
  • the sysfs interface does allow to control the settings. Setting in a sequence parent, then rate and finally state to 1 gives the expected results.

In my initial test, it could be that the camera framework interfered. I since made sure to not have any camera registration happening, since the tegra camera framework can claim some clocks.

I got the signal on extperiph1/GPIO PP0, not on extperiph2/GPIO PP1. This may be a pinmux issue, even though it does not look obvious to me what the difference is in the config.

Since I could reply to the initial question of this ticket, I will mark it as solved.