Hi @igorpadykov ,
Meanwhile, I found this in Chapter 6.2.5 Define MIPI Lanes of iMX 8M Plus Camera Porting Guide (IMX8MPCSPUG.pdf) :
And all stuffs starting with isi, Isi or ISI belong to ISI Layer which is part of the ISP Software Architecture. Could you explain more, please?
Best regards,
Khang
>And all stuffs starting with isi, Isi or ISI belong to ISI Layer which is part of the ISP Software Architecture.
right, but ISI and ISP are different modules. ISP does not use lanes.
Best regards
igor
Dear @igorpadykov ,
I'm afraid that you are referring the ISI which is the Image Sensing Interface hardware block/module while I'm mentioning the ISI layer which is Independent Sensor Interface layer in the ISP Software Architecture as below :
In term of software implementation, one is in kernel-space of linux-imx :
drivers/staging/media/imx/imx8-isi-hw.h
drivers/staging/media/imx/imx8-isi-hw.c
drivers/staging/media/imx/imx8-isi-core.h
drivers/staging/media/imx/imx8-isi-cap.c
drivers/staging/media/imx/imx8-isi-m2m.c
drivers/staging/media/imx/imx8-isi-core.c
and other is in user-space (!?!?) within the isp-imx :
units/isi
units/isi/include_priv/isi_priv.h
units/isi/source/isi.c
units/isi/source/isisup.c
units/isi/include/isi_common.h
units/isi/include/isi_iss.h
units/isi/include/isi.h
I find this ISI a little bit confusing but I don't see that they are relevant each other. Do you agree ?
Just let you know that we were able to fetch data from our 1 lane MIPI-CSI camera sensor to the Image Sensing Interface module then made it appear as standard V4L2 video device (/dev/videoX) by bypassing the ISP block / module. Now with the official release and support of ISP related documentation and source code, we wish to utilize the ISP for advanced processing.
Best regards,
Khang
Dear @igorpadykov ,
I would like to re-launch this question since I'm in the context of ISP-IMX and there's certain definition of number of lanes within units/isi/include/isi_common.h :
#define ISI_MIPI_OFF 0x80000000 //!< MIPI is disabled
#define ISI_MIPI_4LANES 0x00000004
#define ISI_MIPI_2LANES 0x00000002
...
#define ISI_MIPI_LANES 0x00000060
Which then are used in each sensor ISP based driver, for example :
pIsiSensorCaps->MipiLanes = ISI_MIPI_4LANES;
And escalated to units/isi/source/isi.c :
struct vvcam_csi_lane_cfg csi_lane_cfg;
csi_lane_cfg.mipi_lane_num = Caps.MipiLanes;
result = ioctl(pHalCtx->csi_fd,VVCSI_IOC_S_LANE_CFG,&csi_lane_cfg);
if (result != 0)
{
TRACE( ISI_ERROR, "%s: Set csi mipi lane Error\n", __func__);
return ( RET_FAILURE );
}
Also, I have confusion of the relationship of the number of lanes defined in above units/isi/include/isi_common.h and ones defined in device-tree as your suggestion, for example:
imx296_0: imx296_mipi@1a {
compatible = "sony,imx296_mipi_vvcam";
...
port {
imx296_mipi_0_ep: endpoint {
data-lanes = <1>;
clock-lanes = <0>;
remote-endpoint = <&mipi_csi0_ep>;
};
};
};
Are they both programmed in the following register ?
Last thing, since 1-lane definition is missing in above units/isi/include/isi_common.h, I plan to add it as following :
#define ISI_MIPI_OFF 0x80000000 //!< MIPI is disabled
#define ISI_MIPI_4LANES 0x00000004
#define ISI_MIPI_2LANES 0x00000002
#define ISI_MIPI_1LANE 0x00000001 // My definition
What do you think ?
Thanks in advance,
Khang.
