On 22-08-18 12:51:31, Jacopo Mondi wrote: > <snip> > If I recall correctly there are at least three configurations at play: > > - The CSIS pixel mode selection > > MIPI_CSI_ISP_CONFIG[13:12] Funny enough adding MIPI_CSIS_ISPCFG_PIXEL_MODE_QUAD and MIPI_CSIS_ISPCFG_ALIGN_32BIT to the config(0) register actually produced an image. Highly distorted image, but did not break the image acquisition. MIPI_CSIS_ISPCFG_ALIGN_32BIT seems to be the wrong flag here, but it without it the streaming got blocked. > The driver currently forces dual pixel sampling mode for YUV422 > and report a TODO: > > * TODO: Verify which other formats require DUAL (or QUAD) modes. > > Here you're trying to transfer RAW12 data, which is indicated in the > register documentation as one of the formats suitable for DUAL/QUAD > mode transfer > > - I'm actually not sure how and if RAW12 gets expanded to 16 bit > samples by filling the 16-bit word with 0s or it either gets > packed in 6 bytes with no paddings. Figure "13-33. Pixel > alignment" seems to suggest that, but I'm not sure I really got > that diagram > > - The CSI-bridge > > - CSI_CR3[3] SENSOR_16BITS Actually the driver is always setting this one for raw10/12 formats. > - CSI_CR18[20] MIPI_DOUBLE_CMP Enabling this bit for raw10/12 formats kills the transmission. According to the documentation this flag transfers full pixel per clock cycle as opposed to just half a pixel. > The comment in imx7_csi_configure() explains how different versions of YUYV > (2X8 and 1X16) are handled, and why SENSOR_16BITS and MIPI_DOUBLE_CMP have > to be enabled when the csi-bridge has to be instructed to sample 16 bits > samples from the RX queue. Seems like i have to find a way to make the mipi-csi stream full pixel (iow 16bit), if any such thing exists. And hope this configuration is supported between both parts, mipi & bridge. > I guess the key would be here to find out what combination of SINGLE/DUAL/QUAD > sampling is opportune for RAW12 (I would try with DUAL first and then QUAD) > and then configure the csi-bridge bus sampling mode accordingly (likely in the > same was as it is done for YUYV_1X16) In fact i was mimicking MEDIA_BUS_FMT_YUYV8_1X16 case, but as mentioned, this didn't work. Seems like raw10/12 formats are not so well (if at all) handled by the bridge. > When it comes to bandwidth limitation, can you try to reduce the sensor output > size to make sure you chase one issue at the time ? I used insanely big vblank and hblank values. Obtaining single frame took about 90 seconds. This indeed reduced "FIFO Overflow Error" and "Frame Size Error" to four digit number (the lowest rate i've seen so far), but there was no visible improvement in the captured test pattern image. I doubt i can make the sensor stream slower and i also think it doesn't make sense to go down this path - there are still errors. Any advice on how to debug the CSI bridge? NXP support is as useless as ever. cheers, Petko
