Image sensor driver unable to receive images

[d_zebec]

Hi,

I am porting an image sensor driver that works on another platfrom to DragonBoard.
Image sensor produces raw Bayer 10bit data in four lane mode.

Here is the yavta command that I use for testing:
yavta -Bcapture-mplane -c100 -n 10 --requeue-last -fSRGGB10P -s692x520 /dev/video0
It starts stream and initializes buffers, but never receives any frams. It is just stuck and I have to exit with Ctrl-C.

Configuration commands I use:

sudo media-ctl -d /dev/media0 -l '"msm_csiphy0":1->"msm_csid0":0[1],"msm_csid0":1->"msm_ispif0":0[1],"msm_ispif0":1->"msm_vfe0_rdi0":0[1]'

sudo media-ctl -d /dev/media0 -V '"imx412 4-001a":0[fmt:SRGGB10_1X10/692x520 field:none],"msm_csiphy0":0[fmt:SRGGB10_1X10/692x520 field:none],"msm_csid0":0[fmt:SRGGB10_1X10/692x520 field:none],"msm_ispif0":0[fmt:SRGGB10_1X10/692x520 field:none],"msm_vfe0_rdi0":0[fmt:SRGGB10_1X10/692x520 field:none]'

Here is what I know so far:

• Sensor outputs images (measured with an osciloscope)
• lots of csiphy_isr interrupts
• no csid_isr interrupts (only one at the start of the stream)
• some ispif_isr interrupts, followed by vfe_isr interrupts that call vfe_isr_sof function

Any hints for further steps would be greatly appreciated.

[Ramesh]

HI d_zebec,

Current release have support for YUV Sensor only,
If you are expecting Bayer data from RDI path definitely it will failed. Because RDI path is reserves for YUV path.

thanks
Ramesh

[d_zebec]

I would like to get raw data from sensor, debayering can be done in software.

Is this also not supported?

Previous threads on the forum, like the one below, would suggest otherwise:

Broken pipe error when trying to develop a driver for OV4689 MIPI sensor for APQ8016 using CAMSS & CCI

Hi Mathieu, I have modified reg 0x4300 to 0xf8 and media bus format to MEDIA_BUS_FMT_SBGGR8_1X8 and I’m able to capture 8-bit raw from OV5645.

Edit: also, from official website:

RDI interface of VFE - raw dump of the input data to memory. Supported formats:

• YUYV/UYVY/YVYU/VYUY (packed YUV 4:2:2)
• MIPI RAW8 (8bit Bayer RAW)
• MIPI RAW10 (10bit packed Bayer RAW)
• MIPI RAW12 (12bit packed Bayer RAW)

Source:

Using CSI camera with a Dragonboard-410c

[todortomov]

@Ramesh

Current release have support for YUV Sensor only,
If you are expecting Bayer data from RDI path definitely it will failed. Because RDI path is reserves for YUV path.

This is not true. RDI can dump raw data too - it just doesn’t do any processing - it will be raw data as output from the sensor. d_zebec has shown an excerpt of the formats supported.

@d_zebec

• Sensor outputs images (measured with an osciloscope)
• lots of csiphy_isr interrupts
• no csid_isr interrupts (only one at the start of the stream)
• some ispif_isr interrupts, followed by vfe_isr interrupts that call vfe_isr_sof function

Edit: Sorry, my previous comment about settle count value was not correct. If you receive ispif interrupts, then settle count is already ok.

Which release / kernel version do you use?
Are you sure that the CSI2 lane configuration is correct - for the sensor (it streams on the expected lanes) and for the camss driver (correct lanes are configured to receive the data from).
Which lanes do you use and what is the lane configuration for the camss driver (from dtsi file)?

[d_zebec]

I use Linaro Debian Desktop that is part of the image dragonboard-410c-sdcard-installer-buster-359 (downloaded from here). Output of uname -r is 4.14.0-qcomlt-arm64.

After setting the settle_cnt variable to a lower value than the one calculated by csiphy_settle_cnt_calc, I was able to capture some frames using yavta. However, there are still no csid_isr interrupts, does this mean that the acquisition is not working after all?

The sensor I’m using is in four lane mode, data-lanes are set to < 0x00 0x02 0x03 0x04 > in the device tree. Value of num_lanes in csiphy_settle_cnt_calc is 4. I will also try to capture frames in two lane mode.

[todortomov]

@d_zebec

I was able to capture some frames using yavta. However, there are still no csid_isr interrupts, does this mean that the acquisition is not working after all?

Interrupts on csid are not enabled, so there will be only one interrupt for reset completed. If you are able to capture the frames, then it is ok. What makes you think it is not working, are the frames correct?
Thank you for the report.

[d_zebec]

There are few issues with the frames:

• There are CSI2 packet headers (4 bytes) at the start of raw frame and throughout the buffer. Is this by design? Should I remove them manually in software?
• Frames only partially fill the buffer with data. Last part of the buffer doesn’t get filled.

There are no errors in the dmesg that would give a hint.

Edit: after outputing and analysing test patterns, it seems that the lines in the buffer are shorther than expected. What could cause this issue?

Two lane mode has the same issues. Buffers are filled even less than in the four lane mode. There are also following error messages in the two lane mode:

qcom-iommu_fault
qcim-iommu-ctx Unhandlel context fault
qcom-camss: Active buffer mismatch!

[d_zebec]

I was able to solve the problems mentioned in the previous post by reducing sensor’s internal pixel rate.

Big thanks for all the help!