[V2, 2/5] Documentation: dt-bindings: Document the Synopsys MIPI DPHY Rx bindings

[V2, 2/5] Documentation: dt-bindings: Document the Synopsys MIPI DPHY Rx bindings

[Luis Oliveira]

Add device-tree bindings documentation for SNPS DesignWare MIPI D-PHY in
RX mode.

Signed-off-by: Luis Oliveira <lolivei@synopsys.com>
---
Changelog
v2:
- no changes

 .../devicetree/bindings/phy/snps,dphy-rx.txt       | 36 ++++++++++++++++++++++
 1 file changed, 36 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/snps,dphy-rx.txt

diff --git a/Documentation/devicetree/bindings/phy/snps,dphy-rx.txt b/Documentation/devicetree/bindings/phy/snps,dphy-rx.txt
new file mode 100644
index 0000000..9079f4a
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/snps,dphy-rx.txt
@@ -0,0 +1,36 @@
+Synopsys DesignWare MIPI Rx D-PHY block details
+
+Description
+-----------
+
+The Synopsys MIPI D-PHY controller supports MIPI-DPHY in receiver mode.
+Please refer to phy-bindings.txt for more information.
+
+Required properties:
+- compatible		: Shall be "snps,dphy-rx".
+- #phy-cells		: Must be 1.
+- snps,dphy-frequency	: Output frequency of the D-PHY.
+- snps,dphy-te-len	: Size of the communication interface (8 bits->8 or 12bits->12).
+- reg			: Physical base address and size of the device memory mapped
+		 	  registers;
+
+Optional properties:
+- snps,compat-mode	: Compatibility mode control
+
+The per-board settings:
+- gpios 		: Synopsys testchip used as reference uses this to change setup
+		  	  configurations.
+
+Example:
+
+	mipi_dphy_rx1: dphy@3040 {
+		compatible = "snps,dphy-rx";
+		#phy-cells = <1>;
+		snps,dphy-frequency = <300000>;
+		snps,dphy-te-len = <12>;
+		snps,compat-mode = <1>;
+		reg = < 0x03040 0x20
+			0x08000 0x100
+			0x09000 0x100>;
+	};
+
-- 
2.9.3

Re: [V2, 2/5] Documentation: dt-bindings: Document the Synopsys MIPI DPHY Rx bindings

[Laurent Pinchart]

Hi Louis,

Thank you for the patch.

On Thursday, 20 September 2018 14:16:40 EEST Luis Oliveira wrote:
> Add device-tree bindings documentation for SNPS DesignWare MIPI D-PHY in
> RX mode.
> 
> Signed-off-by: Luis Oliveira <lolivei@synopsys.com>
> ---
> Changelog
> v2:
> - no changes
> 
>  .../devicetree/bindings/phy/snps,dphy-rx.txt       | 36 +++++++++++++++++++
>  1 file changed, 36 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/snps,dphy-rx.txt
> 
> diff --git a/Documentation/devicetree/bindings/phy/snps,dphy-rx.txt
> b/Documentation/devicetree/bindings/phy/snps,dphy-rx.txt new file mode
> 100644
> index 0000000..9079f4a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/snps,dphy-rx.txt
> @@ -0,0 +1,36 @@
> +Synopsys DesignWare MIPI Rx D-PHY block details
> +
> +Description
> +-----------
> +
> +The Synopsys MIPI D-PHY controller supports MIPI-DPHY in receiver mode.
> +Please refer to phy-bindings.txt for more information.
> +
> +Required properties:
> +- compatible		: Shall be "snps,dphy-rx".
> +- #phy-cells		: Must be 1.
> +- snps,dphy-frequency	: Output frequency of the D-PHY.

If that's the frequency of the clock on the output side of the RX PHY, doesn't 
it depend on the frequency on the CSI-2 (or other) bus ? Can't it vary ? Why 
do you need to have it in DT ?

> +- snps,dphy-te-len	: Size of the communication interface (8 bits->8 or
> 12bits->12).

We have similar properties in various bindings, such as bus-width in video-
interfaces.txt. Couldn't we use a more standard name ?

> +- reg			: Physical base address and size of the device memory mapped
> +		 	  registers;

The example below shows three ranges. Could you document the ranges that are 
expected ?

> +Optional properties:
> +- snps,compat-mode	: Compatibility mode control

What is this ?

> +The per-board settings:
> +- gpios 		: Synopsys testchip used as reference uses this to change 
setup
> +		  	  configurations.

Here too, what is this for ?

> +Example:
> +
> +	mipi_dphy_rx1: dphy@3040 {
> +		compatible = "snps,dphy-rx";
> +		#phy-cells = <1>;
> +		snps,dphy-frequency = <300000>;
> +		snps,dphy-te-len = <12>;
> +		snps,compat-mode = <1>;
> +		reg = < 0x03040 0x20
> +			0x08000 0x100
> +			0x09000 0x100>;

The base addresses are pretty low, what kind of bus does this sit on ?

> +	};
> +

-- 
Regards,

Laurent Pinchart

Re: [V2, 2/5] Documentation: dt-bindings: Document the Synopsys MIPI DPHY Rx bindings

[Luis Oliveira]

On 20-Sep-18 14:11, Laurent Pinchart wrote:
> Hi Louis,
> 
> Thank you for the patch.
> 

Hi Laurent, thank you for your review, my answers are inline.

> On Thursday, 20 September 2018 14:16:40 EEST Luis Oliveira wrote:
>> Add device-tree bindings documentation for SNPS DesignWare MIPI D-PHY in
>> RX mode.
>>
>> Signed-off-by: Luis Oliveira <lolivei@synopsys.com>
>> ---
>> Changelog
>> v2:
>> - no changes
>>
>>  .../devicetree/bindings/phy/snps,dphy-rx.txt       | 36 +++++++++++++++++++
>>  1 file changed, 36 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/phy/snps,dphy-rx.txt
>>
>> diff --git a/Documentation/devicetree/bindings/phy/snps,dphy-rx.txt
>> b/Documentation/devicetree/bindings/phy/snps,dphy-rx.txt new file mode
>> 100644
>> index 0000000..9079f4a
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/snps,dphy-rx.txt
>> @@ -0,0 +1,36 @@
>> +Synopsys DesignWare MIPI Rx D-PHY block details
>> +
>> +Description
>> +-----------
>> +
>> +The Synopsys MIPI D-PHY controller supports MIPI-DPHY in receiver mode.
>> +Please refer to phy-bindings.txt for more information.
>> +
>> +Required properties:
>> +- compatible		: Shall be "snps,dphy-rx".
>> +- #phy-cells		: Must be 1.
>> +- snps,dphy-frequency	: Output frequency of the D-PHY.
> 
> If that's the frequency of the clock on the output side of the RX PHY, doesn't 
> it depend on the frequency on the CSI-2 (or other) bus ? Can't it vary ? Why 
> do you need to have it in DT ?
> 

But you are right, I will move it to the CSI-2 block.
The reason for it to be on the DT is that my use case have a camera with fixed
frequency connected, but of course I can change it after.

>> +- snps,dphy-te-len	: Size of the communication interface (8 bits->8 or
>> 12bits->12).
> 
> We have similar properties in various bindings, such as bus-width in video-
> interfaces.txt. Couldn't we use a more standard name ?

I have read the bus-width property but I don't this is the same.
This is not a video quite a video interface. Our D-PHY is configured using an
control interface, which is called "test interface" and can have 8-bit or 12-bit.

> 
>> +- reg			: Physical base address and size of the device memory mapped
>> +		 	  registers;
> 
> The example below shows three ranges. Could you document the ranges that are 
> expected ?
> 

The three ranges is optional, it can be only two.
- The first is the interface from which we communicate with the d-phy. A small
window the for the referenced above "test interface".
- The second and third reg are regions for configuration for the d-phy before
the d-phy bring up:
a few examples:
 - 4+4 data lanes max, 1 clk
 - 8 data lanes max, 1clk
 - 4+4 data lanes, 2 clk

>> +Optional properties:
>> +- snps,compat-mode	: Compatibility mode control
> 
> What is this ?

This toggles a mode for a specific d-phy that we can't auto-detect. So when we
use it we activate the compatibility mode for it. I can remove it if you think
it's best.

> 
>> +The per-board settings:
>> +- gpios 		: Synopsys testchip used as reference uses this to change 
> setup
>> +		  	  configurations.
> 
> Here too, what is this for ?

Most of our d-phys have a wrapper around that can be controlled by a gpio-driver
that can halt the d-phy.

> 
>> +Example:
>> +
>> +	mipi_dphy_rx1: dphy@3040 {
>> +		compatible = "snps,dphy-rx";
>> +		#phy-cells = <1>;
>> +		snps,dphy-frequency = <300000>;
>> +		snps,dphy-te-len = <12>;
>> +		snps,compat-mode = <1>;
>> +		reg = < 0x03040 0x20
>> +			0x08000 0x100
>> +			0x09000 0x100>;
> 
> The base addresses are pretty low, what kind of bus does this sit on ?
> 

It sits on top of a bus like this for my configuration.

dx_mb {
		compatible = "simple-bus";
		#address-cells = <1>;
		#size-cells = <1>;
		ranges = <0x00000000 0x0 0xD0000000 0x10000000>;
		interrupt-parent = <&he_intc>;
		...

>> +	};
>> +
> 

Re: [V2, 2/5] Documentation: dt-bindings: Document the Synopsys MIPI DPHY Rx bindings

[Rob Herring]

On Thu, Sep 20, 2018 at 01:16:40PM +0200, Luis Oliveira wrote:
> Add device-tree bindings documentation for SNPS DesignWare MIPI D-PHY in
> RX mode.

"dt-bindings: phy: ..." for the subject.

> 
> Signed-off-by: Luis Oliveira <lolivei@synopsys.com>
> ---
> Changelog
> v2:
> - no changes
> 
>  .../devicetree/bindings/phy/snps,dphy-rx.txt       | 36 ++++++++++++++++++++++
>  1 file changed, 36 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/snps,dphy-rx.txt
> 
> diff --git a/Documentation/devicetree/bindings/phy/snps,dphy-rx.txt b/Documentation/devicetree/bindings/phy/snps,dphy-rx.txt
> new file mode 100644
> index 0000000..9079f4a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/snps,dphy-rx.txt
> @@ -0,0 +1,36 @@
> +Synopsys DesignWare MIPI Rx D-PHY block details
> +
> +Description
> +-----------
> +
> +The Synopsys MIPI D-PHY controller supports MIPI-DPHY in receiver mode.
> +Please refer to phy-bindings.txt for more information.
> +
> +Required properties:
> +- compatible		: Shall be "snps,dphy-rx".
> +- #phy-cells		: Must be 1.
> +- snps,dphy-frequency	: Output frequency of the D-PHY.
> +- snps,dphy-te-len	: Size of the communication interface (8 bits->8 or 12bits->12).
> +- reg			: Physical base address and size of the device memory mapped
> +		 	  registers;
> +
> +Optional properties:
> +- snps,compat-mode	: Compatibility mode control

type? values?

> +
> +The per-board settings:
> +- gpios 		: Synopsys testchip used as reference uses this to change setup
> +		  	  configurations.

Preferred to be named (e.g. foo-gpios). How many? What are their 
functions?

> +
> +Example:
> +
> +	mipi_dphy_rx1: dphy@3040 {
> +		compatible = "snps,dphy-rx";
> +		#phy-cells = <1>;
> +		snps,dphy-frequency = <300000>;
> +		snps,dphy-te-len = <12>;
> +		snps,compat-mode = <1>;
> +		reg = < 0x03040 0x20
> +			0x08000 0x100
> +			0x09000 0x100>;
> +	};
> +
> -- 
> 2.9.3
> 

Re: [V2, 2/5] Documentation: dt-bindings: Document the Synopsys MIPI DPHY Rx bindings

[Rob Herring]

On Fri, Oct 12, 2018 at 11:45:48AM -0500, Rob Herring wrote:
> On Thu, Sep 20, 2018 at 01:16:40PM +0200, Luis Oliveira wrote:
> > Add device-tree bindings documentation for SNPS DesignWare MIPI D-PHY in
> > RX mode.
> 
> "dt-bindings: phy: ..." for the subject.
> 
> > 
> > Signed-off-by: Luis Oliveira <lolivei@synopsys.com>

Also, checkpatch.pl complains the author and S-o-b emails don't match.

Rob

Re: [V2, 2/5] Documentation: dt-bindings: Document the Synopsys MIPI DPHY Rx bindings

[Luis Oliveira]

Hi Rob,

On 12-Oct-18 17:45, Rob Herring wrote:
> On Thu, Sep 20, 2018 at 01:16:40PM +0200, Luis Oliveira wrote:
>> Add device-tree bindings documentation for SNPS DesignWare MIPI D-PHY in
>> RX mode.
> 
> "dt-bindings: phy: ..." for the subject.
> 
Yes, you are right.

>>
>> Signed-off-by: Luis Oliveira <lolivei@synopsys.com>
>> ---
>> Changelog
>> v2:
>> - no changes
>>
>>  .../devicetree/bindings/phy/snps,dphy-rx.txt       | 36 ++++++++++++++++++++++
>>  1 file changed, 36 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/phy/snps,dphy-rx.txt
>>
>> diff --git a/Documentation/devicetree/bindings/phy/snps,dphy-rx.txt b/Documentation/devicetree/bindings/phy/snps,dphy-rx.txt
>> new file mode 100644
>> index 0000000..9079f4a
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/snps,dphy-rx.txt
>> @@ -0,0 +1,36 @@
>> +Synopsys DesignWare MIPI Rx D-PHY block details
>> +
>> +Description
>> +-----------
>> +
>> +The Synopsys MIPI D-PHY controller supports MIPI-DPHY in receiver mode.
>> +Please refer to phy-bindings.txt for more information.
>> +
>> +Required properties:
>> +- compatible		: Shall be "snps,dphy-rx".
>> +- #phy-cells		: Must be 1.
>> +- snps,dphy-frequency	: Output frequency of the D-PHY.
>> +- snps,dphy-te-len	: Size of the communication interface (8 bits->8 or 12bits->12).
>> +- reg			: Physical base address and size of the device memory mapped
>> +		 	  registers;
>> +
>> +Optional properties:
>> +- snps,compat-mode	: Compatibility mode control
> 
> type? values?
> 

I will remove this in V3.

>> +
>> +The per-board settings:
>> +- gpios 		: Synopsys testchip used as reference uses this to change setup
>> +		  	  configurations.
> 
> Preferred to be named (e.g. foo-gpios). How many? What are their 
> functions?
> 

Ok, thanks for reviewing this.

>> +
>> +Example:
>> +
>> +	mipi_dphy_rx1: dphy@3040 {
>> +		compatible = "snps,dphy-rx";
>> +		#phy-cells = <1>;
>> +		snps,dphy-frequency = <300000>;
>> +		snps,dphy-te-len = <12>;
>> +		snps,compat-mode = <1>;
>> +		reg = < 0x03040 0x20
>> +			0x08000 0x100
>> +			0x09000 0x100>;
>> +	};
>> +
>> -- 
>> 2.9.3
>>

[V2, 4/5] Documentation: dt-bindings: Document bindings for DW MIPI CSI-2 Host

[Luis Oliveira]

Add bindings for Synopsys DesignWare MIPI CSI-2 host.

Signed-off-by: Luis Oliveira <lolivei@synopsys.com>
---
Changelog
v2:
- no changes

 .../devicetree/bindings/media/snps,dw-csi-plat.txt | 74 ++++++++++++++++++++++
 1 file changed, 74 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/snps,dw-csi-plat.txt

diff --git a/Documentation/devicetree/bindings/media/snps,dw-csi-plat.txt b/Documentation/devicetree/bindings/media/snps,dw-csi-plat.txt
new file mode 100644
index 0000000..028f5eb
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/snps,dw-csi-plat.txt
@@ -0,0 +1,74 @@
+Synopsys DesignWare CSI-2 Host controller
+
+Description
+-----------
+
+This HW block is used to receive image coming from an MIPI CSI-2 compatible
+camera.
+
+Required properties:
+- compatible: shall be "snps,dw-csi-plat"
+- reg			: physical base address and size of the device memory mapped
+  registers;
+- interrupts		: CSI-2 Host interrupt
+- snps,output-type	: Core output to be used (IPI-> 0 or IDI->1 or BOTH->2) These
+			  values choose which of the Core outputs will be used, it
+			  can be Image Data Interface or Image Pixel Interface.
+- phys			: List of one PHY specifier (as defined in
+			  Documentation/devicetree/bindings/phy/phy-bindings.txt).
+			  This PHY is a MIPI DPHY working in RX mode.
+- resets		: Reference to a reset controller (optional)
+
+Optional properties(if in IPI mode):
+- snps,ipi-mode 	: Mode to be used when in IPI(Camera -> 0 or Controller -> 1)
+			  This property defines if the controller will use the video
+			  timings available
+			  in the video stream or if it will use pre-defined ones.
+- snps,ipi-color-mode	: Bus depth to be used in IPI (48 bits -> 0 or 16 bits -> 1)
+			  This property defines the width of the IPI bus.
+- snps,ipi-auto-flush	: Data auto-flush (1 -> Yes or 0 -> No). This property defines
+			  if the data is automatically flushed in each vsync or if
+			  this process is done manually
+- snps,virtual-channel	: Virtual channel where data is present when in IPI mode. This
+			  property chooses the virtual channel which IPI will use to
+			  retrieve the video stream.
+
+The per-board settings:
+ - port sub-node describing a single endpoint connected to the camera as
+   described in video-interfaces.txt[1].
+
+Example:
+
+	csi2_1: csi2@3000 {
+		compatible = "snps,dw-csi-plat";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		reg = < 0x03000 0x7FF>;
+		interrupts = <2>;
+		output-type = <2>;
+		resets = <&dw_rst 1>;
+		phys = <&mipi_dphy_rx1 0>;
+		phy-names = "csi2-dphy";
+
+		/* IPI optional Configurations */
+		snps,ipi-mode = <0>;
+		snps,ipi-color-mode = <0>;
+		snps,ipi-auto-flush = <1>;
+		snps,virtual-channel = <0>;
+
+		/* CSI-2 per-board settings */
+		port@1 {
+			reg = <1>;
+			csi1_ep1: endpoint {
+				remote-endpoint = <&camera_1>;
+				data-lanes = <1 2>;
+			};
+		};
+		port@2 {
+			csi1_ep2: endpoint {
+				remote-endpoint = <&vif1_ep>;
+			};
+		};
+	};
+
+
-- 
2.9.3

Re: [V2, 4/5] Documentation: dt-bindings: Document bindings for DW MIPI CSI-2 Host

[Laurent Pinchart]

Hi Luis,

Thank you for the patch.

On Thursday, 20 September 2018 14:16:42 EEST Luis Oliveira wrote:
> Add bindings for Synopsys DesignWare MIPI CSI-2 host.
> 
> Signed-off-by: Luis Oliveira <lolivei@synopsys.com>
> ---
> Changelog
> v2:
> - no changes
> 
>  .../devicetree/bindings/media/snps,dw-csi-plat.txt | 74 +++++++++++++++++++
>  1 file changed, 74 insertions(+)
>  create mode 100644
> Documentation/devicetree/bindings/media/snps,dw-csi-plat.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/snps,dw-csi-plat.txt
> b/Documentation/devicetree/bindings/media/snps,dw-csi-plat.txt new file
> mode 100644
> index 0000000..028f5eb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/snps,dw-csi-plat.txt
> @@ -0,0 +1,74 @@
> +Synopsys DesignWare CSI-2 Host controller
> +
> +Description
> +-----------
> +
> +This HW block is used to receive image coming from an MIPI CSI-2 compatible
> +camera.
> +
> +Required properties:
> +- compatible: shall be "snps,dw-csi-plat"
> +- reg			: physical base address and size of the device memory mapped
> +  registers;
> +- interrupts		: CSI-2 Host interrupt
> +- snps,output-type	: Core output to be used (IPI-> 0 or IDI->1 or BOTH-
>2)
> These
> +			  values choose which of the Core outputs will be used, it
> +			  can be Image Data Interface or Image Pixel Interface.
> +- phys			: List of one PHY specifier (as defined in
> +			  Documentation/devicetree/bindings/phy/phy-bindings.txt).
> +			  This PHY is a MIPI DPHY working in RX mode.
> +- resets		: Reference to a reset controller (optional)
> +
> +Optional properties(if in IPI mode):
> +- snps,ipi-mode 	: Mode to be used when in IPI(Camera -> 0 or Controller -
>
> 1)
> +			  This property defines if the controller will use the video
> +			  timings available
> +			  in the video stream or if it will use pre-defined ones.

How does one select this ?

> +- snps,ipi-color-mode	: Bus depth to be used in IPI (48 bits -> 0 or 16
> bits -> 1)
> +			  This property defines the width of the IPI bus.

How about using the standard bus-width property in the endpoint of the output 
port ?

> +- snps,ipi-auto-flush	: Data auto-flush (1 -> Yes or 0 -> No). This
> property defines
> +			  if the data is automatically flushed in each vsync
> or if
> +			  this process is done manually

This seems like a configuration option, not a hardware property. I don't think 
it belongs to DT.

> +- snps,virtual-channel	: Virtual channel where data is present when in IPI
> mode. This
> +			  property chooses the virtual channel which IPI will use to
> +			  retrieve the video stream.

The virtual channel doesn't belong to DT, it should be queried from the sensor 
at runtime (and when a sensor can send multiple data streams, that should even 
be configurable).

> +The per-board settings:
> + - port sub-node describing a single endpoint connected to the camera as
> +   described in video-interfaces.txt[1].

You need to explicitly list all the ports for this device, with their number 
and function.

> +Example:
> +
> +	csi2_1: csi2@3000 {
> +		compatible = "snps,dw-csi-plat";
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		reg = < 0x03000 0x7FF>;
> +		interrupts = <2>;
> +		output-type = <2>;
> +		resets = <&dw_rst 1>;
> +		phys = <&mipi_dphy_rx1 0>;
> +		phy-names = "csi2-dphy";
> +
> +		/* IPI optional Configurations */
> +		snps,ipi-mode = <0>;
> +		snps,ipi-color-mode = <0>;
> +		snps,ipi-auto-flush = <1>;
> +		snps,virtual-channel = <0>;
> +
> +		/* CSI-2 per-board settings */
> +		port@1 {
> +			reg = <1>;
> +			csi1_ep1: endpoint {
> +				remote-endpoint = <&camera_1>;
> +				data-lanes = <1 2>;
> +			};
> +		};
> +		port@2 {
> +			csi1_ep2: endpoint {
> +				remote-endpoint = <&vif1_ep>;
> +			};
> +		};
> +	};
> +
> +

Extra blank lines.

-- 
Regards,

Laurent Pinchart

Re: [V2, 4/5] Documentation: dt-bindings: Document bindings for DW MIPI CSI-2 Host

[Luis Oliveira]

On 20-Sep-18 14:24, Laurent Pinchart wrote:
> Hi Luis,
> 
> Thank you for the patch.
> 

Hi Laurent, thank you for your review.
My answers inline.

> On Thursday, 20 September 2018 14:16:42 EEST Luis Oliveira wrote:
>> Add bindings for Synopsys DesignWare MIPI CSI-2 host.
>>
>> Signed-off-by: Luis Oliveira <lolivei@synopsys.com>
>> ---
>> Changelog
>> v2:
>> - no changes
>>
>>  .../devicetree/bindings/media/snps,dw-csi-plat.txt | 74 +++++++++++++++++++
>>  1 file changed, 74 insertions(+)
>>  create mode 100644
>> Documentation/devicetree/bindings/media/snps,dw-csi-plat.txt
>>
>> diff --git a/Documentation/devicetree/bindings/media/snps,dw-csi-plat.txt
>> b/Documentation/devicetree/bindings/media/snps,dw-csi-plat.txt new file
>> mode 100644
>> index 0000000..028f5eb
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/snps,dw-csi-plat.txt
>> @@ -0,0 +1,74 @@
>> +Synopsys DesignWare CSI-2 Host controller
>> +
>> +Description
>> +-----------
>> +
>> +This HW block is used to receive image coming from an MIPI CSI-2 compatible
>> +camera.
>> +
>> +Required properties:
>> +- compatible: shall be "snps,dw-csi-plat"
>> +- reg			: physical base address and size of the device memory mapped
>> +  registers;
>> +- interrupts		: CSI-2 Host interrupt
>> +- snps,output-type	: Core output to be used (IPI-> 0 or IDI->1 or BOTH-
>> 2)
>> These
>> +			  values choose which of the Core outputs will be used, it
>> +			  can be Image Data Interface or Image Pixel Interface.
>> +- phys			: List of one PHY specifier (as defined in
>> +			  Documentation/devicetree/bindings/phy/phy-bindings.txt).
>> +			  This PHY is a MIPI DPHY working in RX mode.
>> +- resets		: Reference to a reset controller (optional)
>> +
>> +Optional properties(if in IPI mode):
>> +- snps,ipi-mode 	: Mode to be used when in IPI(Camera -> 0 or Controller -
>>
>> 1)
>> +			  This property defines if the controller will use the video
>> +			  timings available
>> +			  in the video stream or if it will use pre-defined ones.
> 
> How does one select this ?
> 

This is a hardware setting for timings in IPI (Image Pixel Interface - Synopsys
specific interface), default is Controller mode - 1.

This can be selected in the DT or after by the driver.

>> +- snps,ipi-color-mode	: Bus depth to be used in IPI (48 bits -> 0 or 16
>> bits -> 1)
>> +			  This property defines the width of the IPI bus.
> 
> How about using the standard bus-width property in the endpoint of the output 
> port ?
> 

Here I think It makes sense, I will use your suggestion.

>> +- snps,ipi-auto-flush	: Data auto-flush (1 -> Yes or 0 -> No). This
>> property defines
>> +			  if the data is automatically flushed in each vsync
>> or if
>> +			  this process is done manually
> 
> This seems like a configuration option, not a hardware property. I don't think 
> it belongs to DT.
> 
I see your point,

>> +- snps,virtual-channel	: Virtual channel where data is present when in IPI
>> mode. This
>> +			  property chooses the virtual channel which IPI will use to
>> +			  retrieve the video stream.
> 
> The virtual channel doesn't belong to DT, it should be queried from the sensor 
> at runtime (and when a sensor can send multiple data streams, that should even 
> be configurable).
> 

I will do that.

I made this properties for my tests with cameras, thinking of SoCs that have
fixed HW configurations. But I can remove all this fields from the DT because
all of them can be made after in the driver.

>> +The per-board settings:
>> + - port sub-node describing a single endpoint connected to the camera as
>> +   described in video-interfaces.txt[1].
> 
> You need to explicitly list all the ports for this device, with their number 
> and function.
> 

Ok.

>> +Example:
>> +
>> +	csi2_1: csi2@3000 {
>> +		compatible = "snps,dw-csi-plat";
>> +		#address-cells = <1>;
>> +		#size-cells = <0>;
>> +		reg = < 0x03000 0x7FF>;
>> +		interrupts = <2>;
>> +		output-type = <2>;
>> +		resets = <&dw_rst 1>;
>> +		phys = <&mipi_dphy_rx1 0>;
>> +		phy-names = "csi2-dphy";
>> +
>> +		/* IPI optional Configurations */
>> +		snps,ipi-mode = <0>;
>> +		snps,ipi-color-mode = <0>;
>> +		snps,ipi-auto-flush = <1>;
>> +		snps,virtual-channel = <0>;
>> +
>> +		/* CSI-2 per-board settings */
>> +		port@1 {
>> +			reg = <1>;
>> +			csi1_ep1: endpoint {
>> +				remote-endpoint = <&camera_1>;
>> +				data-lanes = <1 2>;
>> +			};
>> +		};
>> +		port@2 {
>> +			csi1_ep2: endpoint {
>> +				remote-endpoint = <&vif1_ep>;
>> +			};
>> +		};
>> +	};
>> +
>> +
> 
> Extra blank lines.

Thanks.
>