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
