Inotify_event: tag:CHANSEL_NOMATCH channel:0x01

[Kei_Ko]

Hello,

I reviewed the HW according to your advice and succeeded in activing the sensor.
But I couldn’t get raw data and received the following log from trace.

Why does the following log occur?

For 0x249 shown in the log, CTYPE is interpreted as LS = 0x4 and DTYPE is interpreted as 0x12, and the PH of the embedded line of the sensor actually starts as 0x12.
However, the following logs occur regardless of the values that you wrote in the device tree.

embedded_metadata_height = “1”; //or “0”

I would appreciate it if you help.

Thank you.
dtsi.txt (9.3 KB)
trace.txt (14.8 MB)

[JerryChang]

@Kei_Ko

embedded_metadata_height = “1”; //or “0”

hello Kei_Ko,

this is the settings for how many line of embedded metadata need to parse by capture engine.
could you please examine your sensor configuration, is the sensor signaling output with embedded metadata? you may also review the sensor driver to check it’s configured accordingly.

[Kei_Ko]

Hello @JerryChang

Our sensor settings are as follows.

I thought it would be ignored if I set the embedded data line = 3, but the error bits in the log are the same.

Thanks

[Kei_Ko]

Could you tell me why FS/FE’s channel is 0x00 but chansel_nomatch is 0x01 in the trace log?

[JerryChang]

it only support embedded line with data types as 0x12 in the packet header.
those 0x31 and 0x30 should be the culprit, is it able to disable them from the sensor side?

[Kei_Ko]

Thank you for your answer. @JerryChang
I’ll also find out how to disable it, but I can’t currently find it in the sensor register map.

Is there a way to ignore or include the line to get the raw? In the future, we may need ambient data.

Thanks

[JerryChang]

hello Kei_Ko,

you may have a try by adding them into active_h.

@Kei_Ko

In the future, we may need ambient data.

please dig into kernel driver, there’s chan->emb_buf; to allocates private buffer for embedded data storage. you may have some implementation to retrieve the buffer.
however, we don’t have similar sensor to verify that.

[Kei_Ko]

Thanks. I will try that.

Could I know why FS/FE’s channel is 0x00 but chansel_nomatch is 0x01 in the trace log?

Thanks.

[JerryChang]

hello Kei_Ko,

it’s different bits of CHANSEL, bit-0 for PIXEL_SOF; bit-1 for PIXEL_EOF;
hence, FS(0x00), and FE(0x01) that’s indicate a good frame packet has received by VI engine.

bit-0 of NOMATCH is a true/false flag, if chansel_nomatch is 0x01 means there’s a mismatch.
please refer to above comments to examine your sensor configuration, and update the sensor settings accordingly.

[Kei_Ko]

Hello @JerryChang .

I removed the other line as per your advice and there is only active area between FS and FE.

However, Trace logs only change the code to 0x000589 (DTYPE = 0x2C/RAW12) and show the same log.

The case below seems to have a similar problem to ours, but we don’t use the vc-id property.

Received MIPI data, but cannot get any image from video I/F

please refer to a note from GMSL user guide. “Video pipes generate frame start (FS) and frame end (FE) short packets when streaming video. If two video pipes are carrying two different datatypes (i.e image frames + embedded lines) from the same image, only one of the FS/FE pairs is needed. Generating the extra FS/FE pair without mapping will result in a line buffer overflow.” hence… you may review the Ser/Des programming.

Is there any other cause to consider? Still not capturing raw data.

Thanks

[JerryChang]

@Kei_Ko

I removed the other line as per your advice and there is only active area between FS and FE.

did you meant you’ve disable embedded metadata and also configure embedded_metadata_height = "0";?
please also share the pipeline you’re used to fetch the stream, and the complete tracing logs for reference, thanks

[Kei_Ko]

Hello @JerryChang ,

I solved the problem and the cause was SHORT_FRAME and SHORT LINE error at the top of the trace log.

The trace log is still displayed as CHANSEL_NOMATCH, but I can capture the raw image.

And when i set the embedded_metadata_height = "3";, the embedded data line could not ignored the following 0x30 and 0x31 lines even if first line started with 0x12.

On the other hand, There is another problem with the raw image.
The active area of our sensor is 1042x24 and I removed the code to remove the lower bound of active_h in the following file.

Linux_for_Tegra/source/public/kernel/nvidia/drivers/media/platform/tegra/camera/vi/channel.c
//*height = clamp(*height, TEGRA_MIN_HEIGHT, TEGRA_MAX_HEIGHT);

However, when I checked raw data stored through the v4l2 command, I found that each line in the active area has a different length. The length of the active area should always be 1042(2084Bytes(RAW12)), but data loss occurs on some lines and zero padding occurs elsewhere.

I have checked that there is no problem with register settings, and the same problem occurs every frame. Any help would be appreciated.

Thanks.

[JerryChang]

is it possible to disable those 0x31 and 0x30 lines for confirmation?

[Kei_Ko]

I apologize for not explaining this well enough.

I was able to receive RAW by setting "embedded_metadata_height = 1" and disabling lines 0x31, 0x30.

@Kei_Ko

And when i set the embedded_metadata_height = "3";, the embedded data line could not ignored the following 0x30 and 0x31 lines even if first line started with 0x12.

The above sentence means that if 0x30, 0x31 lines was not disable, I could not receive it even if i modified the device tree. You couldn’t need to answer this sentence as it is not relevant to the current issue.

The current problem is that each active line has a different length.

Thanks.

[JerryChang]

hello Kei_Ko,

it’s driver to calculate the size image per plane.
could you please examine bytesperline settings is return as expected.
for example,
$public_sources/kernel_src/kernel/nvidia/drivers/media/platform/tegra/camera/vi/channel.c

static void tegra_channel_fmt_align(
...
        bpl = tegra_core_bytes_per_line(*width, align, vfmt);

[Kei_Ko]

Hello @JerryChang

I’m sorry for the delay in responding.
I don’t understand, but if I add or change the log level in channel.c to errors, the device won’t boot.

278-- dev_dbg(&chan->video->dev,
			"%s: Resolution= %dx%d bytesperline=%d\n",
			__func__, width, height, chan->format.bytesperline);
278++ dev_err(&chan->video->dev,
			"%s: Resolution= %dx%d bytesperline=%d\n",
			__func__, width, height, chan->format.bytesperline);

The Jetson version is 35.2.1 and the device is a Jetson AGX Xavier.
Can you confirm this same error on your end?

Thanks.

[JerryChang]

hello Kei_Ko,

is there a kernel panic? may I know what’s the error messages?
I doubt there’s something wrong in your debug prints.
please replace it with pr_err() or pr_info(), and prints the logs only without parsing device node.
for example,
pr_err("[Debug] %s: Resolution= %dx%d bytesperline=%d\n", __func__, width, height, chan->format.bytesperline);