Problem enabling D3 camera on db410c

[Rob_Gries]

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

Problem enabling D3 camera on db410c

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 – …

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]

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]

@Rob_Gries

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.

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]

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]

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]

@Rob_Gries

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

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.