How can I capture in resolutions other than 1920x1080 and 1280x720 on 4.14?


#21

No, this is my fault, I did not test PIX interface with the last patch series (only the RDI one).

I pushed a new patch to fix this (tested with RDI and PIX interface):
https://git.linaro.org/people/loic.poulain/linux.git/commit/?h=qcomlt-4.14-d3-mezzanine&id=6cc4af827d98116fd6e5fadd88dd180168cb1a9d


#22

I have tested your latest patch, and I am now able to capture at 1920x1080. I’d like to start working with the media-controller in the “compose” mode to enable scaling to other resolutions. Can you provide an example pipeline for this, are the ones provided in the user manual current?

Edit – I think that I’ve figured out how to apply scaling through compose: https://gist.github.com/RobGries/c6c54b80196cb397c3c6961dba8f5708

Also when listing the controls via yavta, I get some I2C errors when listing the controls for exposure, auto gain, and main gain. I think that perhaps the exposure and gain compensation registers are getting populated with values outside of a supported range, and might be related to an incorrectly calculated pclk? Just a wild guess, but looking at the driver it seems that these values depend on the pclk value.

Here’s a log of the failure: https://gist.github.com/RobGries/fd361c0741f82d9f5affe1f71bb9d200


#23

Hello Loic,

I tried your latest patch and an able to use the D3 mezzanine and OV5640 with this 4,14 kernel on the db410c. Thanks!

I seem only to be able to use the OV5640 as the camera_rear@3b. If I try to use camera_front@3a I get dmesg errors. I think I have the ovti,ov5640 set correctly and the proper status = “ok” for the cci and camss.

After disabling the camera_rear@3b and enabling the camera_front@3a should I be able to use the OV5640 alone on camera_front@3a with the csiphy1_ep or is that not available yet?

Thanks,
David
.


#24

I have same issue on my side, something goes wrong in the I2C/CCI communication with the seconf OV5640 sensor. I’m going to have a look since we should be able to use both sensors.


#25

Well maybe it is those pesky no pop resisters.

While searching, I can see in the schematic that R61 and R62 are DNI for I2C3. I also found this note:

For MIPI CSI0 the companion I2C2 is routed directly from the APQ8016. For MIPI CSI1, the companion I2C is I2C3.
Note: You will need to add R61 and R62, 0 ohm 0201 resistors,to the board to support the routing of I2C3 interface to the High Speed Expansion Connector.


#26

Looks like Maxime Ripard revised his patchset again for the OV5640:
https://patchwork.linuxtv.org/project/linux-media/list/?submitter=7394&state=*

And it looks like they’ve been accepted. I’m going to give these a try on our platform. I’ll post here with my results.


#27

Actually the secondary camera is connected to the BLSP6 i2c, so in the device tree camera_front@3a needs to be a child of i2c@78ba000 instead of cci@1b0c000.


#28

Hi,

I am also trying other resolution with ov5640 but i am not able to capture other resolution only 1920x1080 and 1280x720 is working.

I am using https://releases.linaro.org/96boards/dragonboard410c/linaro/debian/18.01/ release on snapdragon410 based board.

I also tried ov5640 driver from qcomlt-4.14-d3-mezzanine branch, but in this only 1920x1080 is working.

Resolution is applied successfully, checked with media-ctl -d /dev/media0 -p, but when starting preview there is nothing coming on display and getting below logs when terminating command.

Setting pipeline to PAUSED ...
Using mplane plugin for capture 
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
^Chandling interrupt.
Interrupt: Stopping pipeline ...
Execution ended after 0:00:11.193216871
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
[ 1959.299015] qcom-camss 1b0ac00.camss: VFE sof timeout
[ 1959.810980] qcom-camss 1b0ac00.camss: VFE reg update timeout
Setting pipeline to NULL ...
Freeing pipeline ...
linaro@linaro-alip:/root$ 

So currently is there any other resolution supported or not? If anyone has any idea or workaround please let me know.

Thanks,
Hiren