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

[Todor Tomov]

Hi Daniel,

On 16.10.2017 18:01, Daniel Mack wrote:
> 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.
>

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