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?
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
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.
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.
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.