Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1720100 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v4 04/21] doc: media/v4l-drivers: Add Qualcomm Camera  Subsystem driver document Daniel Mack <daniel@zonque.org> - 2017-08-25 16:20 +0200
    Re: [PATCH v4 04/21] doc: media/v4l-drivers: Add Qualcomm Camera  Subsystem driver document Todor Tomov <todor.tomov@linaro.org> - 2017-08-28 09:20 +0200
      Re: [PATCH v4 04/21] doc: media/v4l-drivers: Add Qualcomm Camera  Subsystem driver document Daniel Mack <daniel@zonque.org> - 2017-08-29 19:10 +0200

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

Hi Todor,

Thanks a lot for working on the upstream support for this!

On 08/08/2017 03:30 PM, Todor Tomov wrote:
> +The Camera Subsystem hardware found on 8x16 processors and supported by the
> +driver consists of:
> +
> +- 2 CSIPHY modules. They handle the Physical layer of the CSI2 receivers.
> +  A separate camera sensor can be connected to each of the CSIPHY module;
> +- 2 CSID (CSI Decoder) modules. They handle the Protocol and Application layer
> +  of the CSI2 receivers. A CSID can decode data stream from any of the CSIPHY.
> +  Each CSID also contains a TG (Test Generator) block which can generate
> +  artificial input data for test purposes;
> +- ISPIF (ISP Interface) module. Handles the routing of the data streams from
> +  the CSIDs to the inputs of the VFE;
> +- VFE (Video Front End) module. Contains a pipeline of image processing hardware
> +  blocks. The VFE has different input interfaces. The PIX input interface feeds
> +  the input data to the image processing pipeline. Three RDI input interfaces
> +  bypass the image processing pipeline. The VFE also contains the AXI bus
> +  interface which writes the output data to memory.

[I'm based on the 4.9 Linaro downstream version of this code right now,
but at a glance the driver version there looks very much identical to
this one.]

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.

The general setup seems to work fine though. The sensor is probed,
camss_subdev_notifier_complete() is called, and the v4l2 subdevices
exist. But the stream start is not propagated to the other layers, and
I'm trying to understand why.

My DTS looks something like this right now, and the hardware is an
APQ8016 board (Variscite DART SD410).

&i2c {
	cam0: ov5640@3c {
		compatible = "ovti,ov5640";
		reg = <0x3c>;

		// clocks, regulators, gpios etc are omitted

		port {
			cam0_ep: endpoint {
				clock-lanes = <1>;
				data-lanes = <0 2>;
				remote-endpoint = <&csiphy0_ep>;
			};
		};
	};
};

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

Also, which video device should be opened when accessing the cameras on
each of the hardware ports? And what are the other two devices doing?

I'm sure I'm missing something trivial, but at least I can't find this
information in the documentation.


Thanks,
Daniel

[toc] | [next] | [standalone]

#1721122

Hi Daniel,

On 25.08.2017 17:10, Daniel Mack wrote:
> Hi Todor,
> 
> Thanks a lot for working on the upstream support for this!
> 
> On 08/08/2017 03:30 PM, Todor Tomov wrote:
>> +The Camera Subsystem hardware found on 8x16 processors and supported by the
>> +driver consists of:
>> +
>> +- 2 CSIPHY modules. They handle the Physical layer of the CSI2 receivers.
>> +  A separate camera sensor can be connected to each of the CSIPHY module;
>> +- 2 CSID (CSI Decoder) modules. They handle the Protocol and Application layer
>> +  of the CSI2 receivers. A CSID can decode data stream from any of the CSIPHY.
>> +  Each CSID also contains a TG (Test Generator) block which can generate
>> +  artificial input data for test purposes;
>> +- ISPIF (ISP Interface) module. Handles the routing of the data streams from
>> +  the CSIDs to the inputs of the VFE;
>> +- VFE (Video Front End) module. Contains a pipeline of image processing hardware
>> +  blocks. The VFE has different input interfaces. The PIX input interface feeds
>> +  the input data to the image processing pipeline. Three RDI input interfaces
>> +  bypass the image processing pipeline. The VFE also contains the AXI bus
>> +  interface which writes the output data to memory.
> 
> [I'm based on the 4.9 Linaro downstream version of this code right now,
> but at a glance the driver version there looks very much identical to
> this one.]
> 
> 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.

> 
> The general setup seems to work fine though. The sensor is probed,
> camss_subdev_notifier_complete() is called, and the v4l2 subdevices
> exist. But the stream start is not propagated to the other layers, and
> I'm trying to understand why.
> 
> My DTS looks something like this right now, and the hardware is an
> APQ8016 board (Variscite DART SD410).
> 
> &i2c {
> 	cam0: ov5640@3c {
> 		compatible = "ovti,ov5640";
> 		reg = <0x3c>;
> 
> 		// clocks, regulators, gpios etc are omitted
> 
> 		port {
> 			cam0_ep: endpoint {
> 				clock-lanes = <1>;
> 				data-lanes = <0 2>;
> 				remote-endpoint = <&csiphy0_ep>;
> 			};
> 		};
> 	};
> };
> 
> &camss {
> 	ports {
> 		port@0 {
> 			reg = <0>;
> 			csiphy0_ep: endpoint {
> 				clock-lanes = <1>;
> 				data-lanes = <0 1 2 3>;

As far as I know the OV5640 has a two data lane CSI2 interface so
this will probably look like:
data-lanes = <0 2>;

> 				qcom,settle-cnt = <0xe>;
> 				remote-endpoint = <&cam0_ep>;
> 			};
> 		};
> 	};
> };
> 
> Also, which video device should be opened when accessing the cameras on
> each of the hardware ports? And what are the other two devices doing?
> 
> I'm sure I'm missing something trivial, but at least I can't find this
> information in the documentation.
> 
> 
> Thanks,
> Daniel
> 

-- 
Best regards,
Todor Tomov

[toc] | [prev] | [next] | [standalone]

#1722617

Hi Todor,

On 08/28/2017 09:10 AM, Todor Tomov wrote:
> On 25.08.2017 17:10, Daniel Mack wrote:
>> 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.

Yes, it does, thank you! I didn't expect the necessity for any manual
setup on this level due to this sentence in the documentation:

> Runtime configuration of the hardware (updating settings while
> streaming) is not required to implement the currently supported
> functionality.

I hence assumed there is a fixed mapping that is partly derived from DTS
information etc. Anyway, this seems to work now, so thanks a bunch for
the pointer!

Another thing that confused me for a while is the CCI driver, which also
exposes media pads. I have the cameras connected to a regular I2C bus
however, and it seems to work fine. That just leaves the question why
this CCI driver exists at all.

I also have some more questions, but they are even more platform
specific, so I'll rather post them in the 96boards forum.


Thanks again!
Daniel

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web