in one single file or three separate file?
dose it matter the output?
could you help me check the proc-devicetree..txt file? this is the output combine all
hello m_o_bz,
media entity function operations must link to the V4L2 subdevice link validation method,
please add some debug prints within v4l2_subdev_link_validate(..) for digging further.
$public_source/kernel_src/kernel/3rdparty/canonical/linux-jammy/kernel-source/drivers/media/v4l2-core/v4l2-subdev.c
I add a line in function validate, but it seems this function is not being call
int v4l2_subdev_link_validate(struct media_link *link)
{
struct v4l2_subdev *sink;
struct v4l2_subdev_format sink_fmt, source_fmt;
int rval;printk("%s %d\n", __FUNCTION__, __LINE__);
hello m_o_bz,
please debug further since it’s your customize driver.
I refer to the official document as below link, which means the IMX390 is already supported in the SDK
and that is why there is imx390 related dtsi in SDK, so there maybe no bug in the sensor and VI/CSI driver as I can tell now
and all the dts setup related to the GMSL and sensor, csi, vi is in /proc/device-tree, current I can’t figure out what will cause this issue that result no media entity
If there is something wrong in the dts config, what’s that would be? How to double check it
As I can tell now， the VI driver probe and call notify, but notifier->waiting is empty, so no media entity generate, the function is in kernel/kernel-jammy-src/drivers/media/v4l2-core/v4l2-async.c
static int
v4l2_async_notifier_try_complete(struct v4l2_async_notifier notifier)
{
/ Quick check whether there are still more sub-devices here. */
if (!list_empty(¬ifier->waiting))
return 0;
hello m_o_bz,
is it due to i2c frequency?
please refer to below..
i2c@3180000 {
clock-frequency = <0x61a80>;
i2c@31e0000 {
clock-frequency = <0x186a0>;
it’s by default using i2c@3180000 as cam_i2c, which has frequency at 400 khz.
however, you’ve configure i2c@31e0000 to 100 khz per your proc-devicetree.txt (341.7 KB),
let’s try adding clock-frequency = <400000>; to configure i2c8 clock frequency for testing.
for instance,
i2c@31e0000 {
clock-frequency = <400000>;
imx390_a@21 {
sensor_model = "imx390";
clock-names = "extperiph1\0pllp_grtba";
...
Modify to 400K also not work, seems not related to this
i2c@31e0000 {
iommus = <0x04 0x04>;
#address-cells = <0x01>;
dma-coherent;
clock-names = "div-clk\0parent";
assigned-clocks = <0x03 0x37>;
assigned-clock-parents = <0x03 0x66>;
resets = <0x03 0x23>;
interrupts = <0x00 0x21 0x04>;
clocks = <0x03 0x37 0x03 0x66>;
#size-cells = <0x00>;
clock-frequency = <0x61a80>;
Is this still an issue to support? Any result can be shared?
I rewrite all the related dts config, and now the video0 can be show as below
current dts :
proc.dts.txt (332.2 KB)
- entity 1: 13e00000.host1x:nvcsi@15a00000- (2 pads, 2 links)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev0
pad0: Sink
<- "imx390 8-001b":0 [ENABLED]
pad1: Source
-> "vi-output, imx390 8-001b":0 [ENABLED]
- entity 4: imx390 8-001b (1 pad, 1 link)
type V4L2 subdev subtype Sensor flags 0
device node name /dev/v4l-subdev1
pad0: Source
[fmt:SRGGB12_1X12/1936x1096 field:none colorspace:srgb]
-> "13e00000.host1x:nvcsi@15a00000-":0 [ENABLED]
- entity 6: vi-output, imx390 8-001b (1 pad, 1 link)
type Node subtype V4L flags 0
device node name /dev/video0
pad0: Sink
<- "13e00000.host1x:nvcsi@15a00000-":1 [ENABLED]
there are other issue while using the command below,what would be the reason or how to debug it
nvargus_nvraw --lps
nvargus_nvraw version 1.16.0
("nvargus_nvraw") Error BadParameter (0x04): getCameraDevices() failed (in capture_nvraw/src/mobile/
ArgusNvRawCapture.cpp, func initialize(), line 70)
(Argus) Error EndOfFile: Unexpected error in reading socket (in src/rpc/socket/client/ClientSocketManager.cpp, function recvThreadCore(), line 277)
(Argus) Error EndOfFile: Receive worker failure, notifying 1 waiting threads (in src/rpc/socket/client/ClientSocketManager.cpp, function recvThreadCore(), line 350)
(Argus) Error InvalidState: Argus client is exiting with 1 outstanding client threads (in src/rpc/socket/client/ClientSocketManager.cpp, function recvThreadCore(), line 366)
(Argus) Error EndOfFile: Receiving thread terminated with error (in src/rpc/socket/client/ClientSocketManager.cpp, function recvThreadWrapper(), line 379)
(Argus) Error EndOfFile: Client thread received an error from socket (in src/rpc/socket/client/ClientSocketManager.cpp, function send(), line 145)
(Argus) Error EndOfFile: (propagating from src/rpc/socket/client/SocketClientDispatch.cpp, function dispatch(), line 92)
("nvargus_nvraw") Error BadParameter (0x04): Unable to initialize (propagating from capture_nvraw/src/mobile/main.cpp,
func main(), line 73)
hello m_o_bz,
please refer to developer guide, Applications Using V4L2 IOCTL Directly.
you may try fetching the camera stream via V4L2 IOCTL to verify basic camera functionality.
using below command get i2c error. what may be the reason? how to debug
v4l2-ctl --set-fmt-video=width=1920,height=1080,pixelformat=RG12
–stream-mmap --stream-count=1 -d /dev/video0 --stream-to=rg12.raw
[ 1469.729866] imx390 8-001b: imx390_write_reg: i2c write failed, 0x2e18 = 0 [61/1981]
[ 1469.729875] imx390 8-001b: imx390_write_reg: try 5
[ 1469.742027] imx390 8-001b: imx390_write_reg: i2c write failed, 0x2e18 = 0
[ 1469.742034] imx390 8-001b: imx390_write_reg: try 4
[ 1469.757852] imx390 8-001b: imx390_write_reg: i2c write failed, 0x2e18 = 0
[ 1469.757869] imx390 8-001b: imx390_write_reg: try 3
[ 1469.773607] imx390 8-001b: imx390_write_reg: i2c write failed, 0x2e18 = 0
[ 1469.773616] imx390 8-001b: imx390_write_reg: try 2
[ 1469.786359] imx390 8-001b: imx390_write_reg: i2c write failed, 0x2e18 = 0
[ 1469.786366] imx390 8-001b: imx390_write_reg: try 1
[ 1469.797094] imx390 8-001b: imx390_set_mode: sensor write table failed with error -22
[ 1469.797103] imx390 8-001b: Error writing mode
i2c device on bus 8
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- UU UU -- -- --
20: -- -- -- -- -- -- -- -- -- UU -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- UU -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
hello m_o_bz,
it’s sensor driver failed to write the register, it sometimes due to an incorrect regulator settings or incorrect register values.
it looks like the failure while calling set_mode?
please check IMX390’s mode table, which should be 1936x1096 instead of 1920x1080.
if yes.. please try v4l2 IOCTL again with the sensor support formats.
yes imx390 only support one format
[0]: 'RG12' (12-bit Bayer RGRG/GBGB)
Size: Discrete 1936x1096
Interval: Discrete 0.033s (30.000 fps)
Size: Discrete 1936x1096
Interval: Discrete 0.033s (30.000 fps)
using 1936x1096 get the same i2c error
v4l2-ctl --set-fmt-video=width=1936,height=1096,pixelformat=RG12 \
--stream-mmap --stream-count=1 -d /dev/video0 --stream-to=rg12.raw
[ 1892.604165] imx390 8-001b: imx390_write_reg: i2c write failed, 0x2e18 = 0
[ 1892.604174] imx390 8-001b: imx390_write_reg: try 5
[ 1892.615813] imx390 8-001b: imx390_write_reg: i2c write failed, 0x2e18 = 0
[ 1892.615819] imx390 8-001b: imx390_write_reg: try 4
[ 1892.628016] imx390 8-001b: imx390_write_reg: i2c write failed, 0x2e18 = 0
[ 1892.628022] imx390 8-001b: imx390_write_reg: try 3
[ 1892.640743] imx390 8-001b: imx390_write_reg: i2c write failed, 0x2e18 = 0
[ 1892.640748] imx390 8-001b: imx390_write_reg: try 2
[ 1892.651843] imx390 8-001b: imx390_write_reg: i2c write failed, 0x2e18 = 0
[ 1892.651848] imx390 8-001b: imx390_write_reg: try 1
[ 1892.663312] imx390 8-001b: imx390_set_mode: sensor write table failed with error -22
[ 1892.663321] imx390 8-001b: Error writing mode
[ 1895.155327] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[ 1895.155342] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[ 1895.155990] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel
hello m_o_bz,
may I have detail error logs.
is the SerDes chip setup correctly? is this error only reported when IMX390’s sensor set mode?
console.txt (80.8 KB)
I issue the command below and the console log begin from line 1164
v4l2-ctl --verbose --device=/dev/video0 --stream-mmap --stream-count=1 --stream-to=frame.raw
I am not sure the SerDes chip setup correctly , any debug method I can try?
I only test the IMX390 , and only see current error which cause by i2c
below is v4l2 compliance test which show only one failed is test VIDIOC_G/S_PARM: FAIL
Format ioctls (Input 0):
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
fail: v4l2-test-formats.cpp(1344): ret && node->has_frmintervals
test VIDIOC_G/S_PARM: FAIL
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK
test VIDIOC_TRY_FMT: OK
test VIDIOC_S_FMT: OK
test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
test Cropping: OK (Not Supported)
test Composing: OK (Not Supported)
test Scaling: OK (Not Supported)
hello m_o_bz,
it looks something wrong while sensor probing.
please add some debug info into your IMX390 sensor driver for tracing the errors.
for instance,
[ 4745.037884] CPU: 5 PID: 156171 Comm: modprobe Tainted: G OE 5.15.148-tegra #34
[ 4745.037888] Hardware name: NVIDIA NVIDIA Jetson AGX Orin Developer Kit/Jetson, BIOS 36.4.3-gcid-38968081 01/08/2025
[ 4745.037891] Call trace:
[ 4745.037892] dump_backtrace+0x0/0x1c0
[ 4745.037900] show_stack+0x34/0x50
[ 4745.037906] dump_stack_lvl+0x68/0x84
[ 4745.037913] dump_stack+0x18/0x34
[ 4745.037917] v4l2_async_match_notify+0x34/0x130 [v4l2_async]
[ 4745.037934] v4l2_async_register_subdev+0x100/0x1b0 [v4l2_async]
[ 4745.037938] tegracam_v4l2subdev_register+0x16c/0x1b0 [tegra_camera]
[ 4745.037975] imx390_probe+0x158/0x17c [nv_imx390]
[ 4745.037983] i2c_device_probe+0x2fc/0x340
[ 4745.037989] really_probe.part.0+0xac/0x320
[ 4745.037995] __driver_probe_device+0xa4/0x170
[ 4745.037999] driver_probe_device+0x58/0x1a0
[ 4745.038002] __driver_attach+0xa8/0x1b0
[ 4745.038004] bus_for_each_dev+0x84/0xe0
[ 4745.038008] driver_attach+0x38/0x50
[ 4745.038013] bus_add_driver+0x118/0x210
[ 4745.038017] driver_register+0x80/0x140
[ 4745.038019] i2c_register_driver+0x58/0xe0
[ 4745.038023] imx390_i2c_driver_init+0x30/0x1000 [nv_imx390]
[ 4745.038027] do_one_initcall+0x54/0x2b0
[ 4745.038029] do_init_module+0x54/0x250
[ 4745.038031] load_module+0x2058/0x24c0
[ 4745.038033] __do_sys_finit_module+0xa4/0xf0
[ 4745.038036] __arm64_sys_finit_module+0x30/0x40
[ 4745.038038] invoke_syscall+0x5c/0x130
[ 4745.038042] el0_svc_common.constprop.0+0x64/0x110
[ 4745.038046] do_el0_svc+0x74/0xa0
[ 4745.038049] el0_svc+0x28/0x80
[ 4745.038054] el0t_64_sync_handler+0xa4/0x130
[ 4745.038058] el0t_64_sync+0x1a4/0x1a8
[ 4745.038105] tegra-camrtc-capture-vi tegra-capture-vi: subdev imx390 8-001b bound
[ 4745.038114] CPU: 5 PID: 156171 Comm: modprobe Tainted: G OE 5.15.148-tegra #34
[ 4745.038117] Hardware name: NVIDIA NVIDIA Jetson AGX Orin Developer Kit/Jetson, BIOS 36.4.3-gcid-38968081 01/08/2025
I manual add the dump stack call in tegracam_v4l2subdev_register function which is debug the video0 not show issue, so the kernel log show as above
[ 4745.037891] Call trace:
[ 4745.037892] dump_backtrace+0x0/0x1c0
[ 4745.037900] show_stack+0x34/0x50
[ 4745.037906] dump_stack_lvl+0x68/0x84
[ 4745.037913] dump_stack+0x18/0x34
[ 4745.037917] v4l2_async_match_notify+0x34/0x130 [v4l2_async]
which I think no related the current issue
More info about current issue:
I using i2c tool to test i2c communication with each part
using i2c tool to retrieve the max96172 is fine
but i2c tool to retrieve the max9295 can not get the right message which get error as below
i2ctransfer -f -y 8 w2@0x62 0x00 0x00 r1
Error: Sending messages failed: Remote I/O error
So I currently suspect that the issue is related to max96172 with max9295 i2c issue
I head for the maxim vendor which says need to check the CFG pins
Is this still an issue to support? Any result can be shared?
It seems that the Serializer and Deserializer need to be config by hardware to achieve speed match before further debug, I’m focusing on fix this issue now and will show more detail after that