Configuring Media-ctl pipeline for Two Cameras

Products Support DragonBoard 820c
#1

Hi. I have two cameras connected to a custom board with a snapdragon 820 chip. One camera uses two mipi data lanes. The other camera uses four mipi data lanes. The default is two data lanes but I use device tree overlays to configure each camera. If I issue the below commands, when I try to open Cam1 /dev/videoX, it fails to do so (Cam1 is using 4 mipi data lanes)
If I swap the configuring of Cam1 with the configuring of Cam0 (so Cam1s pipeline is set up first), both /dev/videoX devices can be opened and I get good video. Can someone explain this? To be clear, Cam1 uses csiphy0 and 4 mipi data lanes. Cam0 uses csiphy2 and 2 mipi data lanes.

Thanks,
Kim

// apply Cam0 overlay
sudo mkdir -p /sys/kernel/config/device-tree/overlays/cam0
sudo sh -c “cat /home/slroot/sl/bin/dtbo/Cam0_mt9034.dtbo >> /sys/kernel/config/device-tree/overlays/cam0/dtbo”
// apply Cam1 overlay
sudo mkdir -p /sys/kernel/config/device-tree/overlays/cam1
sudo sh -c “cat /home/slroot/sl/bin/dtbo/Cam1_imx412.dtbo >> /sys/kernel/config/device-tree/overlays/cam1/dtbo”
sudo modprobe qcom_camss

// configure cam0 pipeline using csiphy2
sudo media-ctl -d /dev/media0 -l ‘“msm_csiphy2”:1->“msm_csid1”:0[1],“msm_csid1”:1->“msm_ispif1”:0[1],“msm_ispif1”:1->“msm_vfe0_rdi1”:0[1]’

sudo media-ctl -d /dev/media0 -V ‘“mt9034 5-003a”:0[fmt:UYVY8_2X8/640x480],“msm_csiphy2”:0[fmt:UYVY8_2X8/640x480],“msm_csid1”:0[fmt:UYVY8_2X8/640x480],“msm_ispif1”:0[fmt:UYVY8_2X8/640x480],“msm_vfe0_rdi1”:0[fmt:UYVY8_2X8/640x480]’

[open /dev/videoX] // cam0

// configure cam1 pipeline using csiphy0
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 5-001a”:0[fmt:SRGGB10_1X10/4056x3040],“msm_csiphy0”:0[fmt:SRGGB10_1X10/4056x3040],“msm_csid0”:0[fmt:SRGGB10_1X10/4056x3040],“msm_ispif0”:0[fmt:SRGGB10_1X10/4056x3040],“msm_vfe0_rdi0”:0[fmt:SRGGB10_1X10/4056x3040]’

[open /dev/videoX] // cam1…fails here

#2

Can you directly modify the devicetree (not using overlay) and check if issue is reproducible?

#3

Hi Loic,

Thanks for the response. I tried not using device tree overlays (by hardcoding camera settings in the device tree). The open /dev/videoX still fails. I still see these messages in dmesg when I try to open the video device for Cam1 (which usese 4 mipi data lanes):
[ 92.344044] qcom-camss a34000.camss: CSIPHY 3PH HW Version = 0x10000000
[ 92.344257] qcom-camss a34000.camss: Failed to power up pipeline: -16

Another thing I tried was setting Cam0 to use 4 mipi data lanes, but I still get the same messages in dmesg when opening the /dev/videoX for Cam1.

In any of the setups I’ve tried, if I skip over opening the of Cam0 /dev/videoX, then configure the cam1 pipeline, cam1’s video device opens without error.

Thanks,
Kim

#4

This happens when one of the pipeline elements (v4l2 subdev) fails in its s_power() callback. However the log does not indicate which subdev has failed. I suggest to add some debug in the different subdev driver to locate the one failing (maybe the sensor driver?).

#5

Hi Loic,
thanks for the suggestion! With more print statements, I see what is happening. The vfe_set_power is failing for the 4 mipi data lane Cam1. Cam0 (2 mipi data lanes) has a pixel_clock of 74MHz and Cam1 has a pixel_clock of 492MHz. When vfe_set_power is called (open /dev/VideoX), first, by Cam0, it calls vfe_get with vfe->power_count== 0 and calculates a clock rate of 75MHz.

Then Cam1 opens /dev/VideoX, vfe_set_power function is called, but in vfe_get vfe->power_count is no longer 0, so a check of the clock_rate occurs and fails because vfe_check_clock_rate calculates a higher rate (80MHz) than the current clock rate (75MHz, set by Cam0).

If Cam1 opens it’s video device first, it will sets a clock rate of 100MHz. Then when Cam0 opens it’s video device the vfe_check_clock_rate function is successful because 75MHz is less than 100MHz.

I worked around the issue by setting up the media pipeline for Cam1 first and opening it’s video device first. Then setting up Cam0 and opening it’s device.

If you have a better workaround, let me know :slight_smile:

Thanks,
Kim

#7

Hi,

I was trying to add second mipi camera support in DB820c custom board,
Can you suggest any pointers or reference to adding this support?

Regards,
Ajith.

#8

Hi Ajith,

As you can see from this post, How to set up Device Tree for second camera on DB820c - #2 by Loic, there is only one CCI/I2c bus. You set up your device-tree for whichever ports the two cameras are on. On my custom board, the cameras are on ports 0 and 2, so I use csiphy0 and csiphy2. You then configure the pipe line for /dev/media0 using one of the msm_csiphyX (and other subdev devices/modules) for one camera and a different msm_csiphyY for the other camera. You can see this in the above pipeline configurations. Look at this diagram (bottom of the page, showing media pipeline graph for 8x96 ) https://linuxtv.org/downloads/v4l-dvb-apis/v4l-drivers/qcom_camss.html

Thanks,
Kim

#9

Hi Kim,
Thanks for your response.
I want to use a separate CCI/I2C bus for the secondary camera. Is it possible to configure the secondary camera on CCI1?. @kimbo

Regards,
Ajith.

#10

Hi Ajith,
Not according the this post: How to set up Device Tree for second camera on DB820c - #2 by Loic
Thanks,
Kim

#11

Hi @kimbo

Thanks for your response.

I have configured the CCI1 and now the CCI1 bus is getting registered.
I was testing the ov5645 camera in CCI1 bus with the following commands.

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 ‘“ov5645 5-003c”:0[fmt:UYVY8_2X8/19201080 field:none],
“msm_csiphy0”:0[fmt:UYVY8_2X8/19201080 field:none],“msm_csid0”:0[fmt:UYVY8_2X8//
19201080 field:none],“msm_ispif0”:0[fmt:UYVY8_2X8/19201080 field:none],“msm_vff
e0_rdi0”>:0[fmt:UYVY8_2X8/19201080 field:none]’

gst-launch-1.0 v4l2src device=/dev/video0 ! ‘video/x-raw,format=UYVY,width=19200
,height=1080’ ! glimagesink

i am getting the following message
[ 949.919338] qcom-camss a34000.camss: VFE HW Version = 0x70020000
[ 949.925352] qcom-camss a34000.camss: VFE HW Version = 0x70020000
[ 949.931331] qcom-camss a34000.camss: VFE HW Version = 0x70020000
[ 949.937259] qcom-camss a34000.camss: VFE HW Version = 0x70020000
[ 950.045192] qcom-camss a34000.camss: CSIPHY 3PH HW Version = 0x10000000
[ 950.045529] qcom-camss a34000.camss: VFE HW Version = 0x70020000
[ 957.602314] qcom-camss a34000.camss: VFE sof timeout
[ 958.114265] qcom-camss a34000.camss: VFE reg update timeout

But i didn’t get the camera preview.

can you suggest a command or procedure to test the camera preview in CCI1.
@Loic @kimbo

Regards,
Ajith.

#12

On which CSI port your camera is connected? look like you configure pipeline for CSI0 here. If your’re using CSI1 for this secondary? sensor, maybe you should have something like:

media-ctl -d /dev/media0 -l '"msm_csiphy1":1->"msm_csid1":0[1],"msm_csid1":1->"msm_ispif1":0[1],"msm_ispif1":1->"msm_vfe0_rdi1":0[1]';

And configure format accordingly as well. Then you should be able to use rdi1 (/dev/video1) to retrieve stream.

#13

Hi @Loic

In my design CCI1 is connected to CSI1 and I tried with the CSI1 commands

sudo media-ctl -d /dev/media0 -l ‘“msm_csiphy1”:1->“msm_csid1”:0[1],“msm_csid1”:1->“msm_ispif1”:0[1],“msm_ispif1”:1->“msm_vfe0_rdi1”:0[1]’

sudo media-ctl -d /dev/media0 ‘“ov5645 5-003c”:0[fmt:UYVY8_2X8/1920×1080 field:none],“msm_csiphy1”:0[fmt:UYVY8_2X8/1920×1080 field:none],“msm_csid1”:0[fmt:UYVY8_2X8/1920×1080 field:none],“msm_ispif1”:0[fmt:UYVY8_2X8/1920×1080 field:none],“msm_vfe0_rdi1”>:0[fmt:UYVY8_2X8/1920×1080 field:none]’

sudo gst-launch-1.0 v4l2src device=/dev/video1 ! ‘video/x-raw,format=UYVY,width=1920,height=1080’ ! glimagesink

I didn’t get the preview. I am getting the following logs
[ 181.769900] qcom-camss a34000.camss: VFE HW Version = 0x70020000
[ 181.917129] i2c-qcom-cci a0c000.cci: master 1 queue 0 timeout
[ 181.962784] qcom-camss a34000.camss: CSIPHY 3PH HW Version = 0x10000000
[ 181.963257] qcom-camss a34000.camss: VFE HW Version = 0x70020000
[ 181.969175] qcom-camss a34000.camss: VFE HW Version = 0x70020000
[ 181.975037] qcom-camss a34000.camss: VFE HW Version = 0x70020000
[ 181.980879] qcom-camss a34000.camss: VFE HW Version = 0x70020000
[ 181.986783] qcom-camss a34000.camss: VFE HW Version = 0x70020000
[ 181.992766] qcom-camss a34000.camss: VFE HW Version = 0x70020000
[ 181.998750] qcom-camss a34000.camss: VFE HW Version = 0x70020000
[ 182.324501] qcom-camss a34000.camss: VFE HW Version = 0x70020000
[ 182.406981] qcom-camss a34000.camss: CSIPHY 3PH HW Version = 0x10000000
[ 182.407381] qcom-camss a34000.camss: VFE HW Version = 0x70020000
[ 182.414406] qcom-camss a34000.camss: VFE HW Version = 0x70020000
[ 182.419657] qcom-camss a34000.camss: VFE HW Version = 0x70020000
[ 182.425306] qcom-camss a34000.camss: VFE HW Version = 0x70020000
[ 182.431062] qcom-camss a34000.camss: VFE HW Version = 0x70020000
[ 182.437065] qcom-camss a34000.camss: VFE HW Version = 0x70020000
[ 182.443022] qcom-camss a34000.camss: VFE HW Version = 0x70020000
[ 182.745752] qcom-camss a34000.camss: CSIPHY 3PH HW Version = 0x10000000
[ 182.746147] qcom-camss a34000.camss: VFE HW Version = 0x70020000

Setting pipeline to PAUSED …
error: XDG_RUNTIME_DIR not set in the environment.
Pipeline is live and does not need PREROLL …
Got context from element ‘sink’: gst.gl.GLDisplay=context, gst.gl.GLDisplay=(GstGLDisplay)"(GstGLDisplayX11)\ gldisplayx11-0";
Setting pipeline to PLAYING …
New clock: GstSystemClock

Regards,
Ajith.

#14

Hi Ajith,

I don’t have an answer for why this isn’t working. I am curious what the output of these two commands are though:
media-ctl -p -d /dev/media0
i2cdetect -l

Thanks,
Kim

#15

Hi @kimbo

These are the output of the above commands.

i2c-3 i2c QUP I2C adapter I2C adapter
i2c-6 i2c QUP I2C adapter I2C adapter
i2c-4 i2c Qualcomm Camera Control Interface: 0 I2C adapter
i2c-2 i2c QUP I2C adapter I2C adapter
i2c-7 i2c msm hdmi i2c I2C adapter
i2c-5 i2c Qualcomm Camera Control Interface: 1 I2C adapter

Media controller API version 4.14.89

Media device information

driver qcom-camss
model Qualcomm Camera Subsystem
serial
bus info
hw revision 0x0
driver version 4.14.89

Device topology

  • entity 1: msm_csiphy0 (2 pads, 4 links)
    type Node subtype V4L flags 0
    device node name /dev/v4l-subdev0
    pad0: Sink
    pad1: Source
    → “msm_csid0”:0 []
    → “msm_csid1”:0 []
    → “msm_csid2”:0 []
    → “msm_csid3”:0 []

  • entity 4: msm_csiphy1 (2 pads, 5 links)
    type Node subtype V4L flags 0
    device node name /dev/v4l-subdev1
    pad0: Sink
    ← “ov5645 5-003c”:0 [ENABLED,IMMUTABLE]
    pad1: Source
    → “msm_csid0”:0 []
    → “msm_csid1”:0 [ENABLED]
    → “msm_csid2”:0 []
    → “msm_csid3”:0 []

  • entity 7: msm_csiphy2 (2 pads, 4 links)
    type Node subtype V4L flags 0
    device node name /dev/v4l-subdev2
    pad0: Sink
    pad1: Source
    → “msm_csid0”:0 []
    → “msm_csid1”:0 []
    → “msm_csid2”:0 []
    → “msm_csid3”:0 []

  • entity 10: msm_csid0 (2 pads, 7 links)
    type Node subtype V4L flags 0
    device node name /dev/v4l-subdev3
    pad0: Sink
    ← “msm_csiphy0”:1 []
    ← “msm_csiphy1”:1 []
    ← “msm_csiphy2”:1 []
    pad1: Source
    → “msm_ispif0”:0 []
    → “msm_ispif1”:0 []
    → “msm_ispif2”:0 []
    → “msm_ispif3”:0 []

  • entity 13: msm_csid1 (2 pads, 7 links)
    type Node subtype V4L flags 0
    device node name /dev/v4l-subdev4
    pad0: Sink
    ← “msm_csiphy0”:1 []
    ← “msm_csiphy1”:1 [ENABLED]
    ← “msm_csiphy2”:1 []
    pad1: Source
    → “msm_ispif0”:0 []
    → “msm_ispif1”:0 [ENABLED]
    → “msm_ispif2”:0 []
    → “msm_ispif3”:0 []

  • entity 16: msm_csid2 (2 pads, 7 links)
    type Node subtype V4L flags 0
    device node name /dev/v4l-subdev5
    pad0: Sink
    ← “msm_csiphy0”:1 []
    ← “msm_csiphy1”:1 []
    ← “msm_csiphy2”:1 []
    pad1: Source
    → “msm_ispif0”:0 []
    → “msm_ispif1”:0 []
    → “msm_ispif2”:0 []
    → “msm_ispif3”:0 []

  • entity 19: msm_csid3 (2 pads, 7 links)
    type Node subtype V4L flags 0
    device node name /dev/v4l-subdev6
    pad0: Sink
    ← “msm_csiphy0”:1 []
    ← “msm_csiphy1”:1 []
    ← “msm_csiphy2”:1 []
    pad1: Source
    → “msm_ispif0”:0 []
    → “msm_ispif1”:0 []
    → “msm_ispif2”:0 []
    → “msm_ispif3”:0 []

  • entity 22: msm_ispif0 (2 pads, 12 links)
    type Node subtype V4L flags 0
    device node name /dev/v4l-subdev7
    pad0: Sink
    ← “msm_csid0”:1 []
    ← “msm_csid1”:1 []
    ← “msm_csid2”:1 []
    ← “msm_csid3”:1 []
    pad1: Source
    → “msm_vfe0_rdi0”:0 []
    → “msm_vfe0_rdi1”:0 []
    → “msm_vfe0_rdi2”:0 []
    → “msm_vfe0_pix”:0 []
    → “msm_vfe1_rdi0”:0 []
    → “msm_vfe1_rdi1”:0 []
    → “msm_vfe1_rdi2”:0 []
    → “msm_vfe1_pix”:0 []

  • entity 25: msm_ispif1 (2 pads, 12 links)
    type Node subtype V4L flags 0
    device node name /dev/v4l-subdev8
    pad0: Sink
    ← “msm_csid0”:1 []
    ← “msm_csid1”:1 [ENABLED]
    ← “msm_csid2”:1 []
    ← “msm_csid3”:1 []
    pad1: Source
    → “msm_vfe0_rdi0”:0 []
    → “msm_vfe0_rdi1”:0 [ENABLED]
    → “msm_vfe0_rdi2”:0 []
    → “msm_vfe0_pix”:0 []
    → “msm_vfe1_rdi0”:0 []
    → “msm_vfe1_rdi1”:0 []
    → “msm_vfe1_rdi2”:0 []
    → “msm_vfe1_pix”:0 []

  • entity 28: msm_ispif2 (2 pads, 12 links)
    type Node subtype V4L flags 0
    device node name /dev/v4l-subdev9
    pad0: Sink
    ← “msm_csid0”:1 []
    ← “msm_csid1”:1 []
    ← “msm_csid2”:1 []
    ← “msm_csid3”:1 []
    pad1: Source
    → “msm_vfe0_rdi0”:0 []
    → “msm_vfe0_rdi1”:0 []
    → “msm_vfe0_rdi2”:0 []
    → “msm_vfe0_pix”:0 []
    → “msm_vfe1_rdi0”:0 []
    → “msm_vfe1_rdi1”:0 []
    → “msm_vfe1_rdi2”:0 []
    → “msm_vfe1_pix”:0 []

  • entity 31: msm_ispif3 (2 pads, 12 links)
    type Node subtype V4L flags 0
    device node name /dev/v4l-subdev10
    pad0: Sink
    ← “msm_csid0”:1 []
    ← “msm_csid1”:1 []
    ← “msm_csid2”:1 []
    ← “msm_csid3”:1 []
    pad1: Source
    → “msm_vfe0_rdi0”:0 []
    → “msm_vfe0_rdi1”:0 []
    → “msm_vfe0_rdi2”:0 []
    → “msm_vfe0_pix”:0 []
    → “msm_vfe1_rdi0”:0 []
    → “msm_vfe1_rdi1”:0 []
    → “msm_vfe1_rdi2”:0 []
    → “msm_vfe1_pix”:0 []

  • entity 34: msm_vfe0_rdi0 (2 pads, 5 links)
    type V4L2 subdev subtype Unknown flags 0
    device node name /dev/v4l-subdev11
    pad0: Sink
    [fmt:UYVY8_2X8/1920x1080 field:none colorspace:srgb]
    ← “msm_ispif0”:1 []
    ← “msm_ispif1”:1 []
    ← “msm_ispif2”:1 []
    ← “msm_ispif3”:1 []
    pad1: Source
    [fmt:UYVY8_2X8/1920x1080 field:none colorspace:srgb]
    → “msm_vfe0_video0”:0 [ENABLED,IMMUTABLE]

  • entity 37: msm_vfe0_video0 (1 pad, 1 link)
    type Node subtype V4L flags 0
    device node name /dev/video0
    pad0: Sink
    ← “msm_vfe0_rdi0”:1 [ENABLED,IMMUTABLE]

  • entity 43: msm_vfe0_rdi1 (2 pads, 5 links)
    type V4L2 subdev subtype Unknown flags 0
    device node name /dev/v4l-subdev12
    pad0: Sink
    [fmt:UYVY8_2X8/1920x1080 field:none colorspace:srgb]
    ← “msm_ispif0”:1 []
    ← “msm_ispif1”:1 [ENABLED]
    ← “msm_ispif2”:1 []
    ← “msm_ispif3”:1 []
    pad1: Source
    [fmt:UYVY8_2X8/1920x1080 field:none colorspace:srgb]
    → “msm_vfe0_video1”:0 [ENABLED,IMMUTABLE]

  • entity 46: msm_vfe0_video1 (1 pad, 1 link)
    type Node subtype V4L flags 0
    device node name /dev/video1
    pad0: Sink
    ← “msm_vfe0_rdi1”:1 [ENABLED,IMMUTABLE]

  • entity 52: msm_vfe0_rdi2 (2 pads, 5 links)
    type V4L2 subdev subtype Unknown flags 0
    device node name /dev/v4l-subdev13
    pad0: Sink
    [fmt:UYVY8_2X8/1920x1080 field:none colorspace:srgb]
    ← “msm_ispif0”:1 []
    ← “msm_ispif1”:1 []
    ← “msm_ispif2”:1 []
    ← “msm_ispif3”:1 []
    pad1: Source
    [fmt:UYVY8_2X8/1920x1080 field:none colorspace:srgb]
    → “msm_vfe0_video2”:0 [ENABLED,IMMUTABLE]

  • entity 55: msm_vfe0_video2 (1 pad, 1 link)
    type Node subtype V4L flags 0
    device node name /dev/video2
    pad0: Sink
    ← “msm_vfe0_rdi2”:1 [ENABLED,IMMUTABLE]

  • entity 61: msm_vfe0_pix (2 pads, 5 links)
    type V4L2 subdev subtype Unknown flags 0
    device node name /dev/v4l-subdev14
    pad0: Sink
    [fmt:UYVY8_2X8/1920x1080 field:none colorspace:srgb
    compose.bounds:(0,0)/1920x1080
    compose:(0,0)/1920x1080]
    ← “msm_ispif0”:1 []
    ← “msm_ispif1”:1 []
    ← “msm_ispif2”:1 []
    ← “msm_ispif3”:1 []
    pad1: Source
    [fmt:UYVY8_2X8/1920x1080 field:none colorspace:srgb
    crop.bounds:(0,0)/1920x1080
    crop:(0,0)/1920x1080]
    → “msm_vfe0_video3”:0 [ENABLED,IMMUTABLE]

  • entity 64: msm_vfe0_video3 (1 pad, 1 link)
    type Node subtype V4L flags 0
    device node name /dev/video3
    pad0: Sink
    ← “msm_vfe0_pix”:1 [ENABLED,IMMUTABLE]

  • entity 70: msm_vfe1_rdi0 (2 pads, 5 links)
    type V4L2 subdev subtype Unknown flags 0
    device node name /dev/v4l-subdev15
    pad0: Sink
    [fmt:UYVY8_2X8/1920x1080 field:none colorspace:srgb]
    ← “msm_ispif0”:1 []
    ← “msm_ispif1”:1 []
    ← “msm_ispif2”:1 []
    ← “msm_ispif3”:1 []
    pad1: Source
    [fmt:UYVY8_2X8/1920x1080 field:none colorspace:srgb]
    → “msm_vfe1_video0”:0 [ENABLED,IMMUTABLE]

  • entity 73: msm_vfe1_video0 (1 pad, 1 link)
    type Node subtype V4L flags 0
    device node name /dev/video4
    pad0: Sink
    ← “msm_vfe1_rdi0”:1 [ENABLED,IMMUTABLE]

  • entity 79: msm_vfe1_rdi1 (2 pads, 5 links)
    type V4L2 subdev subtype Unknown flags 0
    device node name /dev/v4l-subdev16
    pad0: Sink
    [fmt:UYVY8_2X8/1920x1080 field:none colorspace:srgb]
    ← “msm_ispif0”:1 []
    ← “msm_ispif1”:1 []
    ← “msm_ispif2”:1 []
    ← “msm_ispif3”:1 []
    pad1: Source
    [fmt:UYVY8_2X8/1920x1080 field:none colorspace:srgb]
    → “msm_vfe1_video1”:0 [ENABLED,IMMUTABLE]

  • entity 82: msm_vfe1_video1 (1 pad, 1 link)
    type Node subtype V4L flags 0
    device node name /dev/video5
    pad0: Sink
    ← “msm_vfe1_rdi1”:1 [ENABLED,IMMUTABLE]

  • entity 88: msm_vfe1_rdi2 (2 pads, 5 links)
    type V4L2 subdev subtype Unknown flags 0
    device node name /dev/v4l-subdev17
    pad0: Sink
    [fmt:UYVY8_2X8/1920x1080 field:none colorspace:srgb]
    ← “msm_ispif0”:1 []
    ← “msm_ispif1”:1 []
    ← “msm_ispif2”:1 []
    ← “msm_ispif3”:1 []
    pad1: Source
    [fmt:UYVY8_2X8/1920x1080 field:none colorspace:srgb]
    → “msm_vfe1_video2”:0 [ENABLED,IMMUTABLE]

  • entity 91: msm_vfe1_video2 (1 pad, 1 link)
    type Node subtype V4L flags 0
    device node name /dev/video6
    pad0: Sink
    ← “msm_vfe1_rdi2”:1 [ENABLED,IMMUTABLE]

  • entity 97: msm_vfe1_pix (2 pads, 5 links)
    type V4L2 subdev subtype Unknown flags 0
    device node name /dev/v4l-subdev18
    pad0: Sink
    [fmt:UYVY8_2X8/1920x1080 field:none colorspace:srgb
    compose.bounds:(0,0)/1920x1080
    compose:(0,0)/1920x1080]
    ← “msm_ispif0”:1 []
    ← “msm_ispif1”:1 []
    ← “msm_ispif2”:1 []
    ← “msm_ispif3”:1 []
    pad1: Source
    [fmt:UYVY8_2X8/1920x1080 field:none colorspace:srgb
    crop.bounds:(0,0)/1920x1080
    crop:(0,0)/1920x1080]
    → “msm_vfe1_video3”:0 [ENABLED,IMMUTABLE]

  • entity 100: msm_vfe1_video3 (1 pad, 1 link)
    type Node subtype V4L flags 0
    device node name /dev/video7
    pad0: Sink
    ← “msm_vfe1_pix”:1 [ENABLED,IMMUTABLE]

  • entity 226: ov5645 5-003c (1 pad, 1 link)
    type V4L2 subdev subtype Sensor flags 0
    device node name /dev/v4l-subdev19
    pad0: Source
    [fmt:UYVY8_2X8/1920x1080 field:none colorspace:srgb
    crop:(0,0)/1920x1080]
    → “msm_csiphy1”:0 [ENABLED,IMMUTABLE]

Regards,
Ajith

#16

Hi Ajith,

The connections look correct. I’m not very familiar with gstreamer. I use v4l2 mostly when I’m trying to get camera capture working. After you set up the media-ctl pipeline, does this command give you anything?

v4l2-ctl --stream-mmap=4 --verbose -d /dev/video1

It could be that SOF is not happening. Can you probe the mipi data lines? Is there any data?

Thanks,
Kim

#17

Hi @kimbo

I checked the above command, These are the output of the above command.

VIDIOC_QUERYCAP: ok

i2c-qcom-cci a0c000.cci: master 1 queue 0 timeout
[ 388.315894] qcom-camss a34000.camss: CSIPHY 3PH HW Version = 0x10000000
[ 388.316285] qcom-camss a34000.camss: VFE HW Version = 0x70020000
[ 393.154183] qcom-camss a34000.camss: VFE sof timeout
[ 393.666190] qcom-camss a34000.camss: VFE reg update timeout

And I probed the data lines, the data is coming in these lines.

Regards,
Ajith.

#18

Hi Ajith,

Did you ever get the ov5645 camera working on CCI0?
If not, could you try CCI0?
Is there a source file driver for this sensor? Can you send me a link to it?
Thanks,
Kim

#19

Hi all,

I got the ov5645 camera working in CCI1. Thanks for your support.

Regards,
Ajtih.

#20

Hi Ajith,
That’s good! Can you describe what the fix was to get it to work?
thanks,
Kim

#21

Hi kimbo,

In my case the issue was clock-frequency of cci node.
I have changed the clock-frequency into standard mode then i got the camera preview.

Regards,
Ajith.