Problem enabling D3 camera on db410c

Mani · January 10, 2019, 10:24am

/dev/media0 link will only get created if all the cameras defined in DT probed successfully.

Abrahamon · January 10, 2019, 1:18pm

Thanks about this suggestion, I am following this configuration for the jumpers:
J13: 19-20 for CSI0 CCI SCL
J13: 21-22 for CSI0 CCI SDA
J14: 5-6 for 24MHz OSC clock for camera module of CSI0
CSI1/CAM1 Jumpers:
J13: 15-16 for CSI1 CCI SCL
J13: 17-18 for CSI1 CCI SDA
J14: 3-4 for 24MHz OSC clock for camera module of CSI1
With the AistarVision MIPI Adapter V2.1 but the same error.

ljking · January 10, 2019, 3:32pm

Hi @Abrahamon

My AiStarVision board is V2.0, but it looks like we have the same jumpers. When I had dual cameras on the board and all of the jumpers installed it failed, when I removed the CSI1 camera and the CSI1 jumpers it works for a single camera.

ljking · January 10, 2019, 3:34pm

Hi @Mani

The script that @loic provided doesn’t seem to have options for 1 or 2 cameras. it works for a single camera, but not dual cameras.

Abrahamon · January 11, 2019, 3:11pm

Hi @ljking
Which version of the Linaro Releases are you using?
I am using with the lastest Linaro Debian alip.

Loic · January 16, 2019, 8:15am

Release 18.01 is supposed to work.

ljking · January 18, 2019, 5:33pm

Hi @Abrahamon, I am not using a “release”, I am using the bleeding edge snapshot #491. Linaro Snapshots

Abrahamon · February 2, 2019, 11:25pm

Hi

I have tried the releases 17.06, 18.01, 19.01. I have compiled the kernel with the change from this commit and used this dt-update tool.
Just by removing the disabled status from those 4 lines in the .dtsi file is it supposed to work?

But still have the error I mentioned before. My kernel has more errors than the kernel from @ljking :

[ 9.550623] media: Linux media interface: v0.10
[ 9.566673] Linux video capture interface: v2.00
[ 9.615740] qcom-venus 1d00000.video-codec: Linked as a consumer to 1ef0000.iommu
[ 9.615835] iommu: Adding device 1d00000.video-codec to group 0

[ 9.641882] i2c-qcom-cci 1b0c000.cci: Master 0 error 0x08000000
[ 9.645956] i2c-qcom-cci 1b0c000.cci: master 0 queue 0 error -5
[ 9.648406] qcom,pm8916-wcd-spmi-codec 200f000.spmi:pm8916@1:codec@f000: DT property missing, MBHC btn detection disabled
[ 9.653101] i2c-qcom-cci 1b0c000.cci: cci i2c xfer error -5
[ 9.653110] ov5645 4-003b: ov5645_write_reg_to: write reg error -5 on addr 0x3a: reg=0x3100, val=0x76
[ 9.669386] ov5645 4-003b: could not change i2c address
[ 9.681644] ov5645 4-003b: could not power up OV5645
[ 9.685988] ov5645: probe of 4-003b failed with error -5

[ 9.828917] qcom-camss 1b0ac00.camss: Linked as a consumer to 1ef0000.iommu
[ 9.829007] iommu: Adding device 1b0ac00.camss to group 1
…

More information about the current state of the system:
A loaded kernel module called: ov5645
/dev/i2c-0, /dev/i2c-1, /dev/i2c-3, /dev/i2c-4

ls /proc/iomem:

01b00020-01b0002f : csi_clk_mux
01b00030-01b00033 : csiphy0_clk_mux
01b00038-01b0003b : csiphy1_clk_mux
01b08000-01b080ff : csid0
01b08400-01b084ff : csid1
01b0a000-01b0a4ff : ispif
01b0ac00-01b0adff : csiphy0
01b0b000-01b0b1ff : csiphy1
01b0c000-01b0cfff : /soc/cci@1b0c000
01b10000-01b10fff : vfe0

Does the MIPI Aistarvision V2.1 has been tested by someone else?
Could this be related to ADV HDMI? As mentioned here.

Beforehand, thanks for nay help.

Rob_Gries · March 20, 2019, 6:03pm

Hey Loic,

I’ve tried this with the 19.01 tag and I’m getting VFE0 pix0 overflow messages. I believe that this might be due to an improper pixel rate calculated in on line 1650 in ov5640.c in the ov5640_set_mode function. When checking yavta for the calculated pixel rate, it returns 42002400 which I believe is out of range for this particular camera 42 MHz pixel rate is compatible with the camera – the issue must be somewhere else, CAMSS perhaps?
Some particulars about my setup of the camera – 1280x720 @ 15FPS in NV12 is fed into a Gstreamer pipeline to gain H.264 encoded video.

These are a small sample of what I am seeing in the dmesg logs:
[ 2074.094064] ispif_isr_8x16: 140 callbacks suppressed
[ 2074.094073] qcom-camss 1b0ac00.camss: VFE0 pix0 overflow
[ 2074.127647] qcom-camss 1b0ac00.camss: VFE0 pix0 overflow
[ 2074.161157] qcom-camss 1b0ac00.camss: VFE0 pix0 overflow
[ 2074.194662] qcom-camss 1b0ac00.camss: VFE0 pix0 overflow
[ 2074.228174] qcom-camss 1b0ac00.camss: VFE0 pix0 overflow
[ 2074.261674] qcom-camss 1b0ac00.camss: VFE0 pix0 overflow
[ 2074.295091] qcom-camss 1b0ac00.camss: VFE0 pix0 overflow
[ 2074.328581] qcom-camss 1b0ac00.camss: VFE0 pix0 overflow
[ 2074.362082] qcom-camss 1b0ac00.camss: VFE0 pix0 overflow
[ 2074.395584] qcom-camss 1b0ac00.camss: VFE0 pix0 overflow
[ 2074.488818] qcom-camss 1b0ac00.camss: VFE sof timeout
[ 2075.000809] qcom-camss 1b0ac00.camss: VFE reg update timeout
[ 2076.001879] qcom-camss 1b0ac00.camss: vfe_camif_wait_for_stop: camif stop timeout

This is what I’m seeing in yavta:
— Image Processing Controls (class 0x009f0001) —
control 0x009f0902 `Pixel Rate’ min 0 max 0 step 0 default 0 current 42002400.

~~I’m going to try to see what I can do to get that pixel rate into a more “sane” range and see if there’s any noticeable differences in performance.~~

Rob_Gries · March 11, 2019, 12:42pm

I attempted to hard set the pixel rate to 96000000 and it appeared to allow the camera to work, but when attempting to engage the video codec I get the following error:

qcom-venus 1d00000.video-codec: HW is overloaded, needed: 432000 max: 352800

When the above error is seen it stops the encoder and shuts down my h.264 gstreamer encode pipeline. I’m a little stumped at this point. I haven’t seen that error before in the previous 18.01 kernel.

Loic · March 11, 2019, 3:04pm

Hi Rob, I’m going to try finding time to test this this week, did you try to revert the full ov5640 driver to 18.01 state (with ov5640 patch on top)? to check if problem is related to the ov5640 driver or the venus encoder.

Rob_Gries · March 11, 2019, 4:32pm

I haven’t tried that yet. But when I get a chance later tonight I’ll give it a shot and will post back to the forum.

Rob_Gries · March 12, 2019, 1:39pm

Hey Loic, I was able to successfully bring up the OV5640 camera by doing the following:

Revert 19.01 driver back to 18.01 baselines – Revert to: "media: ov5640: Remove unneeded gpiod NULL check " in ov5640.c
Add in Mani’s patch to publish hardset pixel rate to CAMSS via V4L2 API - https://github.com/RobGries/testing-linaro-19.01/commit/690928debb9ef02b0075b77e2b3b518693453c5f#diff-22c3c9331e9d564945443891f27bf1bf
In the encoder make every frame IDR (Might just be a dependency on my pipeline for h.264 RTP video) - https://github.com/RobGries/testing-linaro-19.01/commit/4f4d2caeb7554080cefe3b18e422fa0a6f88fe9a

Some observations –

qcom-venus 1d00000.video-codec: HW is overloaded, needed: 432000 max: 352800 error is no longer seen with the downstream driver + Mani’s pixel rate hack.
Framerate from the camera is not fixed - The camera should be running at 15 FPS but ranges between 10 - 24 FPS. Is this due to the pixel rate hack?
Encoder framerate when probed through h264parse in gstreamer returns an insane number (returns 120/1 framerate), when explicitly setting caps it locks into a more reasonable number (I explicitly set 15 FPS).
With all that said, it appears that the camera and codec are functional, but still have some strange issues surrounding frame rate stability.

My progress is tracked here if you’re interested: https://github.com/RobGries/testing-linaro-19.01/tree/18.01_ov5640_baseline

Loic · March 20, 2019, 9:09am

Did you try the ov5640 driver availale in this branch: loic.poulain/linux.git - [no description]

Rob_Gries · March 20, 2019, 6:00pm

Yes I’ve tried this in my previous post, results were not quite right.

~~If I recall correctly, the result was that the pixel clock was getting set to 42002400, which as far as I can tell is incompatible with the camera or camss and causes the following errors~~ 42002400 Hz = 42 MHz, 42 MHz should be a compatible pixel clock for this camera:

[ 2074.395584] qcom-camss 1b0ac00.camss: VFE0 pix0 overflow
[ 2074.488818] qcom-camss 1b0ac00.camss: VFE sof timeout
[ 2075.000809] qcom-camss 1b0ac00.camss: VFE reg update timeout
[ 2076.001879] qcom-camss 1b0ac00.camss: vfe_camif_wait_for_stop: camif stop timeout

If 42 MHz is compatible why is this not working? I’m going to give your branch another look tonight.

Rob_Gries · March 20, 2019, 5:57pm

Loic,

I just realized that the value of 42002400 is almost exactly 42MHz but in hertz and is most likely a compatible pixel clock value for the camera. I believe that this is true due it being mentioned in the application notes readily available from Arducam’s website here. The register map on page 23 shows that 42MHz is an acceptable pixel clock from the camera. Since the error is being raised from CAMSS and not the camera driver itself this leads me to think that perhaps CAMSS is the culprit here.

My question is — does pixel clock == pixel rate? Perhaps we’re conflating two different clocks and CAMSS is getting confused and generating these errors and not allowing us to stream from the camera properly? I’m going to give your branch another look tonight to see what I come up with.

Loic · April 9, 2019, 2:26pm

Well, pixel clock rate is the frequency of pixel latching. It depends on sensor configuration (resolution, framerate…) but is typically equal to HTOT x VTOT x FPS where VTOT is the total number of vertical pixels, HTOT the total number of horizontal pixels and FPS the framerate. CAMSS uses this pixel clock to configure its own frequency, including CSI interface (wich also depends on bits per pixel and number of lanes). So the sensor pixel clock varies depending the format, which explains why the reported static one (e.g. 96MHz) can mislead camss.

Loic · April 9, 2019, 4:11pm

I reworked and rebased my ov5640 branch [1], mainly backporting upstream ov5640 driver.
I successfully tested the camera with Debian 19.01.

I share the test script I use [2] (preview, record, rtp…). example:

sh ov5640-test.sh preview UYVY8_1_5X8 vga

[1] loic.poulain/linux.git - [no description]
[2] https://fileserver.linaro.org/owncloud/index.php/s/PFIe2WWtVKLZ6fH

Rob_Gries · April 30, 2019, 4:27pm

Hey Loic,

I gave your branch another look today and I am glad to say that it works in UYVY1_5X8 (NV12) mode via msm_vfe0_pix, but I cannot seem to get raw bayer (SBGGR_1X8) mode to set up properly.

When running through the media-ctl commands (replaced variables with their values for clarity) I get the following errors:

media-ctl -v -d /dev/media0 -V '"ov5640 2-003b":0[fmt:SBGGR8_1X8/1280x720@1/15 field:none]'
Opening media device /dev/media0
Enumerating entities
Found 15 entities
Enumerating pads and links
Invalid pixel code 'SBGGR8_1X8'

 "ov5640 2-003b":0[fmt:SBGGR8_1X8/1280x720@1/15 field:none]
                  ^
Unable to parse format
Unable to setup formats: Invalid argument (22)

Loic · May 1, 2019, 9:20am

Weird, it works on my side, at least format is correctly applied. Does the following command return SBGGR8_1X8 as a known format?

media-ctl --known-mbus-fmts

Did you try with the script I previously attached:

DISPLAY=:0 ./ov5640-test.sh preview SBGGR8_1X8 vga 30

Note: output is fuzzy on my side I think I need to adjust the pixel clock or other register since SBGGR8_1X8 uses 1 byte per pixel contrary to yuv formats.