We have same issue about MIPI-CSI green image. But we use ov10633 and Toshiba TC358746XBG parallel to mipi bridge output YUV422 8bit data to TK1. Please help to confirm the issue, any suggestion or direction will be appreciated. Thanks.
From the register status, looks like the real height of sensor/bridge output is not(should be smaller than) 1080, which subsequently triggered lane error and header error.
Could you please check the active pixel array of sensor/bridge output?
As RiteshPanchal memtion, “After modprobe of tegra_camera first yavta capture not giving any CSI error but output green image.” We also face green image issue when use yavta or V4L2 API to capture TK1 MIPI-CSI image. Is the issue from hardware, soc_camera driver or tegra_camera driver?
Should we need to set TK1 MIPI-CSI parameters ?
For example, TLPX (Length of any low power state period), THS-PREPARE, THS-ZERO, etc.
Or other parameters need to adjust according to different sensor/bridge ?
If available, please let us know to overcome this issue. thanks.
The attached file is Toshiba TC358746XBG colorbar, non-continuous mode, 720p, YUV422 parameter setting.
I’m not sure this table suitable TK1 MIPI-CSI. Could you help to confirm this table? Thanks.
I just checked our vi driver for TK1 R21 release, and found it doesn’t support YUV422 yet
(mainly in vi2_capture_setup_csi_0, vi2_capture_setup_csi_1).
So, you can refer to the implementation in TX1 R23 release to add support for YUV422.
Regarding the MIPI timing you post, I think it should be fine as the receiver(tegra) and transmitter(your bridger) are expected to follow the MIPI spec.
I download TX1 R23.2 kernel source and follow drivers/media/platform/soc_camera/tegra_camera/vi2.c “vi2_channel_capture_setup” function to implement YUV422 format in vi2_capture_setup_csi_0 and vi2_capture_setup_csi_1 as follow,
else if ((icd->current_fmt->code == V4L2_MBUS_FMT_UYVY8_2X8) ||
(icd->current_fmt->code == V4L2_MBUS_FMT_VYUY8_2X8) ||
(icd->current_fmt->code == V4L2_MBUS_FMT_YUYV8_2X8) ||
(icd->current_fmt->code == V4L2_MBUS_FMT_YVYU8_2X8)) {
switch (icd->current_fmt->code) {
case V4L2_MBUS_FMT_UYVY8_2X8:
format = TEGRA_IMAGE_FORMAT_T_U8_Y8__V8_Y8;
break;
case V4L2_MBUS_FMT_VYUY8_2X8:
format = TEGRA_IMAGE_FORMAT_T_V8_Y8__U8_Y8;
break;
case V4L2_MBUS_FMT_YUYV8_2X8:
format = TEGRA_IMAGE_FORMAT_T_Y8_U8__Y8_V8;
break;
case V4L2_MBUS_FMT_YVYU8_2X8:
format = TEGRA_IMAGE_FORMAT_T_Y8_V8__Y8_U8;
break;
}
data_type = TEGRA_IMAGE_DT_YUV422_8;
image_size = icd->user_width * 2;
But I am still getting green image using yavta and V4L2 API.
Do I miss something ?
So i compiled and used there whole kernel with my tc358748 parallel to mipi driver added.
i have tested my tc358748 driver on TX1 and its working fine.
According to TK1 TRM, the TEGRA_VI_CSI_0_ERROR_STATUS 0x8 look like FRAME_HEIGHT_LONG_ERROR: Flagged if frame height is larger than HEIGHT. But we confirmed with OV and Toshiba, the OV10633 and TC358746XBG output 720p image size correctly. I’m getting confuse, why color bar OK but ov10633 NG. Is this dunny pixel or blanking issue? Do we need to adjust MIPI-CSI parameters? Do I miss something?
Be glad to know that tegra can receive the color bar from Toshiba bridge:)
If there are some embedded lines in vertical before frame start or after frame end, we should also take it into account as tegra didn’t know how to skip those embedded data(such as if we have extra 8 lines, then the size should be 1280x728). Seems you didn’t get any ctrl error or parse error, which means mipi timing should be expected.
still i am getting the same error first yavta capture no error and on second yavta capture tk1 hangs. And the image of first capture is same as previous image that i have attached in old message.
R21.5 solves TK1 hang problem on 2nd yavta capture.
But still i am getting green image and CSI error as posted in previous post.
But if i comment “tegra_io_dpd_disable / enable” in board-ardbeg-sensor.c file. I got now CSI error but only suncpt error.
Drexler got success in YUV colorbar on TC358746.
So can you tell me what changes have you done to get this color bar?
Is there any changes you made in kernel tegra_camera or vi2.c source file taking reference of TX1 source? or any other changes in driver source file?
Auvidea has made us aware that an updated firmware/driver file for their B102/J120 carrier boards to support the Toshiba TC358743 is available via the auvidea.eu website.