Problem enabling D3 camera on db410c


#21

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.


#22

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.


#23

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.


#24

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] https://git.linaro.org/people/loic.poulain/linux.git/log/?h=qcomlt-4.14-ov5640
[2] https://fileserver.linaro.org/owncloud/index.php/s/PFIe2WWtVKLZ6fH