Configuring Media-ctl pipeline for Two Cameras

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

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

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

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?).

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

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.

Hi Ajith,

As you can see from this post, How to set up Device Tree for second camera on DB820c, 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

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.

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

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.

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.

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.

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

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

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

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.

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

Hi all,

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

Regards,
Ajtih.

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

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.