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.
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.
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?
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.
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.
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
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.
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 was able to receive RAW by setting "embedded_metadata_height = 1" and disabling lines 0x31, 0x30.
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.
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
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);