Hi Daniel,

On 16.10.2017 18:01, Daniel Mack wrote:

Hi,

On 28.08.2017 09:10, Todor Tomov wrote:

quoted

On 25.08.2017 17:10, Daniel Mack wrote:

quoted

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.

Everything that you have described seems correct.

As you say that frames do not contain any data, do
VFE_0_IRQ_STATUS_0_IMAGE_MASTER_n_PING_PONG
fire at all or not?

Do you see any interrupts on the ISPIF? Which?

Could you please share what hardware setup you have - mezzanine and camera module.


-- 
Best regards,
Todor Tomov