MIPI-CSI bridge

[PSEE]

Hello,

we would like to interface a camera sensor which is compliant with MIPI-CSI2 using variable frame size and fixed frame period.

The application has allocated large buffers to match the worst case ie. the largest MIPI frame size within the frame period.

MIPI CSI Bridge is configured:

• to swap buffers according to VSYNC, BASEADDR_SWITCH_EN is set and BASEADDR_SWITCH_SEL is cleared.
• to raise an interrupt when SOF is detected, SOF_INTEN is set

We control how many bytes the sensor sends in a frame.
We can determine the frame size in the memory buffer. In other word, how many data have been transferred by the DMA in the memory buffer.

We observe an Interrupt rate corresponding to the frame period which is good.

We observe that ~128B have not been transferred by the DMA. In other word, length of the received frame is smaller (~128B ) than the number of data sent by the sensor.

It seems that the last transfer from the RX buffer to the memory buffer has not been done.

We tried to set  RxFF_LEVEL to 0 (16 double word->4 double word) but data are corrupted.

Is there a way to trigger the DMA to achieve the last transfer?

Best regards,

[SJZ]

We see the same issue using our custom camera and 1080p30, but only for the first frame. This produces a permanent shift in the video frames as the data remains misaligned and we can't find a way to align it.

What is your FCC setting? Could this be causing the data loss (it flushes the RXFIFO on SOF).
 
> configured to switch buffer after a MIPI End Of Frame
what setting did you use for this?

[SJZ]

Did you resolve this?
Did you look at register settings for LAST_DMQ_REQ_SEL, BASE-ADDR_SWITCH, RxFF_LEVEL, DMA_BURST_TYPE_RFF, LINE_STRIDE_EN ?
If you use a frame size of 720x487 did that help?

[jimmychan]

Which version of BSP are you using?

Which chip are you using? What is the part number?

Are you using the EVK board?

Could you tell me how to reproduce the issue on the EVK board?

[PSEE]

The board is an imx8mmevk-bb.

Please find below a photo of the device:

MIMX8MM6DVTLZAA
QN87W
SBBU1924A

 The key point is that our Event BAsed camera is using MIPI variable frame size. The camera can produce some frames with few bytes and other with mega bytes of data. 16 or 32-bits pixels do not comply with standart camera format as carry event information.

We have modified the drivers/media/platform/mxc/capture/mx6s_capture.c file:

• Instead of enabling BIT_FB0/1_DMA_DONE_INTEN, we enable BIT_SOF_INTEN and we have changed the interrupt handler accordingly.

• We have added instructions to align physical buffers on double word boundaries

• We have configured the IP to swap buffers after each start of frame

We set to 0 the DMA buffers before enquing them. We know the size of the frame sent by our sensor.
=> We observe that ~128Bytes are missing at the end of the frames received.

It seems that some RX buffers are not flushed in the MIPI-CSI and the MIPI-bridge or the last DMA burst has not been executed.

• we observe this for every frame

• we tried to play with different config in particular the size of the DMA burst but we did not observe any changes

Please tell us if you want us to try different configurations. I join the 2 files modified in plain text and as a patch to highlight our modifications.

Regards

[PSEE]

When the MIPI-CSI interface is configured to switch buffer after a MIPI End Of Frame, the last DMA transfer does not seem to be executed in all cases before the data are reset in the RxFIFO when an End Of Frame short packet is detected.

According to the TRM, a DMA burst transfer is triggered when a certain amount of data is available in a small RxFIFO. The number of bytes required is configurable in the RxFF_LEVEL field of the CSI_CR3. The minimum burst size is 4 double word (32 bytes) which correspond to the missing data at the end of the frame.

We suspect that when the frame size is variable and is not a multiple of 4 double words, the last DMA burst transfer is not executed and data are lost.

Please could you confirm?

Is there a workaround?  (This behavior shall also be observed with JPEG cameras.)

Thanks