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.
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
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);