Re: [PATCH v4 04/21] doc: media/v4l-drivers: Add Qualcomm Camera Subsystem driver document

[Daniel Mack <daniel@zonque.org>]

Hi,

On 28.08.2017 09:10, Todor Tomov wrote:
> On 25.08.2017 17:10, Daniel Mack wrote:
>> Could you explain how ISPIF, CSID and CSIPHY are related?
>>
>> I have a userspace test setup that works fine for USB webcams, but when
>> operating on any of the video devices exposed by this driver, the
>> lowlevel functions such as .s_power of the ISPIF, CSID, CSIPHY and the
>> sensor driver layers aren't called into.
> 
> Have you activated the media controller links? The s_power is called
> when the subdev is part of a pipeline in which the video device node
> is opened. You can see example configurations for the Qualcomm CAMSS
> driver on:
> https://github.com/96boards/documentation/blob/master/ConsumerEdition/DragonBoard-410c/Guides/CameraModule.md
> This will probably answer most of your questions.

It did in fact, yes. Thanks again for the pointer.

I am however struggling getting a 4-lane OV13855 camera to work with
this camss driver, and I'd be happy to hear about similar setups that work.

In short, here's what my setup looks like:

1. I wrote a driver for the OV13855 sensor, based on the one for OV13858
but with updated register values. It announces
MEDIA_BUS_FMT_SBGGR10_1X10 as bus format which is what the sensor should
be sending, if I understand the specs correctly.


2. The DTS snippet for the endpoint connection look like this:

&blsp_i2c6 {
	cam0: ov13855@16 {
		/* ... */
		port {
			cam0_ep: endpoint {
				clock-lanes = <1>;
				data-lanes = <0 2 3 4>;
				remote-endpoint = <&csiphy0_ep>;
			};
		};
	};
};

&camss {
	ports {
		port@0 {
			reg = <0>;
			csiphy0_ep: endpoint {
				clock-lanes = <1>;
				data-lanes = <0 2 3 4>;
				remote-endpoint = <&cam0_ep>;
			};
		};
	};
};

There are also no lane swaps or any intermediate components in hardware.
We've checked the electrical bits many times, and that end seems alright.


3. The pads and links are set up like this:

# 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]'

# media-ctl -d /dev/media0 -V '"ov13855
1-0010":0[fmt:SBGGR10_1X10/4224x3136
field:none],"msm_csiphy0":0[fmt:SBGGR10_1X10/4224x3136
field:none],"msm_csid0":0[fmt:SBGGR10_1X10/4224x3136
field:none],"msm_ispif0":0[fmt:SBGGR10_1X10/4224x3136
field:none],"msm_vfe0_rdi0":0[fmt:SBGGR10_1X10/4224x3136 field:none]'

Both commands succeed.


4. When streaming is started, the power consumption of the device goes
up, all necessary external clocks and voltages are provided and are
stable, and I can see a continuous stream of data on all 4 MIPI lanes
using an oscilloscope.


5. Capturing frames with the following yavta command doesn't work
though. The task is mostly stuck in the buffer dequeing ioctl:

# yavta -B capture-mplane -c10 -I -n 5 -f SBGGR10P -s 4224x3136 /dev/video0

vfe_isr() does fire sometimes with VFE_0_IRQ_STATUS_1_RDIn_SOF(0) set,
but very occasionally only, and the frames do not contain data.

FWIW, an ov6540 is connected to port 1 of the camss, and this sensor
works fine.

I'd be grateful for any pointer about what I could investigate on.


Thanks,
Daniel