[PATCH v7 01/25] rcar-vin: add Gen3 devicetree bindings documentation

[PATCH v7 01/25] rcar-vin: add Gen3 devicetree bindings documentation

[Niklas Söderlund]

Document the devicetree bindings for the CSI-2 inputs available on Gen3.

There is a need to add a custom property 'renesas,id' and to define
which CSI-2 input is described in which endpoint under the port@1 node.
This information is needed since there are a set of predefined routes
between each VIN and CSI-2 block. This routing table will be kept
inside the driver but in order for it to act on it it must know which
VIN and CSI-2 is which.

Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
---
 .../devicetree/bindings/media/rcar_vin.txt         | 116 ++++++++++++++++++---
 1 file changed, 104 insertions(+), 12 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt b/Documentation/devicetree/bindings/media/rcar_vin.txt
index 6e4ef8caf759e5d3..df1abd0fb20386f8 100644
--- a/Documentation/devicetree/bindings/media/rcar_vin.txt
+++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
@@ -2,8 +2,12 @@ Renesas R-Car Video Input driver (rcar_vin)
 -------------------------------------------
 
 The rcar_vin device provides video input capabilities for the Renesas R-Car
-family of devices. The current blocks are always slaves and suppot one input
-channel which can be either RGB, YUYV or BT656.
+family of devices.
+
+Each VIN instance has a single parallel input that supports RGB and YUV video,
+with both external synchronization and BT.656 synchronization for the latter.
+Depending on the instance the VIN input is connected to external SoC pins, or
+on Gen3 to a CSI-2 receiver.
 
  - compatible: Must be one or more of the following
    - "renesas,vin-r8a7795" for the R8A7795 device
@@ -28,21 +32,38 @@ channel which can be either RGB, YUYV or BT656.
 Additionally, an alias named vinX will need to be created to specify
 which video input device this is.
 
-The per-board settings:
+The per-board settings Gen2:
  - port sub-node describing a single endpoint connected to the vin
    as described in video-interfaces.txt[1]. Only the first one will
    be considered as each vin interface has one input port.
 
-   These settings are used to work out video input format and widths
-   into the system.
+The per-board settings Gen3:
+
+Gen3 can support both a single connected parallel input source from
+external SoC pins (port0) and/or multiple parallel input sources from
+local SoC CSI-2 receivers (port1) depending on SoC.
 
+- renesas,id - ID number of the VIN, VINx in the documentation.
+- ports
+    - port0 - sub-node describing a single endpoint connected to the VIN
+      from external SoC pins described in video-interfaces.txt[1]. Only
+      the first one will be considered as each VIN interface has at most
+      one set of SoC external input pins.
+    - port1 - sub-nodes describing one or more endpoints connected to
+      the VIN from local SoC CSI-2 receivers. The endpoint numbers must
+      use the following schema.
 
-Device node example
--------------------
+        - Endpoint 0 - sub-node describing the endpoint which is CSI20
+        - Endpoint 1 - sub-node describing the endpoint which is CSI21
+        - Endpoint 2 - sub-node describing the endpoint which is CSI40
+        - Endpoint 3 - sub-node describing the endpoint which is CSI41
 
-	aliases {
-	       vin0 = &vin0;
-	};
+Device node example Gen2
+------------------------
+
+        aliases {
+                vin0 = &vin0;
+        };
 
         vin0: vin@0xe6ef0000 {
                 compatible = "renesas,vin-r8a7790", "renesas,rcar-gen2-vin";
@@ -52,8 +73,8 @@ Device node example
                 status = "disabled";
         };
 
-Board setup example (vin1 composite video input)
-------------------------------------------------
+Board setup example Gen2 (vin1 composite video input)
+-----------------------------------------------------
 
 &i2c2   {
         status = "ok";
@@ -92,6 +113,77 @@ Board setup example (vin1 composite video input)
         };
 };
 
+Device node example Gen3
+------------------------
+
+        vin0: video@e6ef0000 {
+                compatible = "renesas,vin-r8a7795";
+                reg = <0 0xe6ef0000 0 0x1000>;
+                interrupts = <GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>;
+                clocks = <&cpg CPG_MOD 811>;
+                power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
+                resets = <&cpg 811>;
+                renesas,id = <0>;
+
+                ports {
+                        #address-cells = <1>;
+                        #size-cells = <0>;
+
+                        port@1 {
+                                #address-cells = <1>;
+                                #size-cells = <0>;
+
+                                reg = <1>;
+
+                                vin0csi20: endpoint@0 {
+                                        reg = <0>;
+                                        remote-endpoint= <&csi20vin0>;
+                                };
+                                vin0csi21: endpoint@1 {
+                                        reg = <1>;
+                                        remote-endpoint= <&csi21vin0>;
+                                };
+                                vin0csi40: endpoint@2 {
+                                        reg = <2>;
+                                        remote-endpoint= <&csi40vin0>;
+                                };
+                        };
+                };
+        };
+
+        csi20: csi2@fea80000 {
+                compatible = "renesas,r8a7795-csi2", "renesas,rcar-gen3-csi2";
+                reg = <0 0xfea80000 0 0x10000>;
+                interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>;
+                clocks = <&cpg CPG_MOD 714>;
+                power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
+                resets = <&cpg 714>;
+
+                ports {
+                        #address-cells = <1>;
+                        #size-cells = <0>;
+
+                        port@0 {
+                                reg = <0>;
+                                csi20_in: endpoint {
+                                        clock-lanes = <0>;
+                                        data-lanes = <1>;
+                                        remote-endpoint = <&adv7482_txb>;
+                                };
+                        };
+
+                        port@1 {
+                                #address-cells = <1>;
+                                #size-cells = <0>;
 
+                                reg = <1>;
+
+                                csi20vin0: endpoint@0 {
+                                        reg = <0>;
+                                        remote-endpoint = <&vin0csi20>;
+                                };
+                        };
+                };
+        };
 
 [1] video-interfaces.txt common video media interface
-- 
2.15.0

Re: [PATCH v7 25/25] rcar-vin: enable support for r8a7796

[Geert Uytterhoeven]

CC DT

On Sat, Nov 11, 2017 at 1:38 AM, Niklas Söderlund
<niklas.soderlund+renesas-1zkq55x86MTxsAP9Fp7wbw@public.gmane.org> wrote:
> Add the SoC specific information for Renesas r8a7796.
>
> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> Reviewed-by: Hans Verkuil <hans.verkuil-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
> ---
>  .../devicetree/bindings/media/rcar_vin.txt         |  1 +
>  drivers/media/platform/rcar-vin/rcar-core.c        | 64 ++++++++++++++++++++++
>  2 files changed, 65 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt b/Documentation/devicetree/bindings/media/rcar_vin.txt
> index df1abd0fb20386f8..ddf249c2276600d2 100644
> --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> @@ -10,6 +10,7 @@ Depending on the instance the VIN input is connected to external SoC pins, or
>  on Gen3 to a CSI-2 receiver.
>
>   - compatible: Must be one or more of the following
> +   - "renesas,vin-r8a7796" for the R8A7796 device
>     - "renesas,vin-r8a7795" for the R8A7795 device
>     - "renesas,vin-r8a7794" for the R8A7794 device
>     - "renesas,vin-r8a7793" for the R8A7793 device
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c b/drivers/media/platform/rcar-vin/rcar-core.c
> index b22f6596700d2479..e329de4ce0172e8d 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -1084,6 +1084,66 @@ static const struct rvin_info rcar_info_r8a7795es1 = {
>         },
>  };
>
> +static const struct rvin_info rcar_info_r8a7796 = {
> +       .chip = RCAR_GEN3,
> +       .use_mc = true,
> +       .max_width = 4096,
> +       .max_height = 4096,
> +
> +       .num_chsels = 5,
> +       .chsels = {
> +               {
> +                       { .csi = RVIN_CSI40, .chan = 0 },
> +                       { .csi = RVIN_CSI20, .chan = 0 },
> +                       { .csi = RVIN_NC, .chan = 0 },
> +                       { .csi = RVIN_CSI40, .chan = 0 },
> +                       { .csi = RVIN_CSI20, .chan = 0 },
> +               }, {
> +                       { .csi = RVIN_CSI20, .chan = 0 },
> +                       { .csi = RVIN_NC, .chan = 0 },
> +                       { .csi = RVIN_CSI40, .chan = 0 },
> +                       { .csi = RVIN_CSI40, .chan = 1 },
> +                       { .csi = RVIN_CSI20, .chan = 1 },
> +               }, {
> +                       { .csi = RVIN_NC, .chan = 0 },
> +                       { .csi = RVIN_CSI40, .chan = 0 },
> +                       { .csi = RVIN_CSI20, .chan = 0 },
> +                       { .csi = RVIN_CSI40, .chan = 2 },
> +                       { .csi = RVIN_CSI20, .chan = 2 },
> +               }, {
> +                       { .csi = RVIN_CSI40, .chan = 1 },
> +                       { .csi = RVIN_CSI20, .chan = 1 },
> +                       { .csi = RVIN_NC, .chan = 1 },
> +                       { .csi = RVIN_CSI40, .chan = 3 },
> +                       { .csi = RVIN_CSI20, .chan = 3 },
> +               }, {
> +                       { .csi = RVIN_CSI40, .chan = 0 },
> +                       { .csi = RVIN_CSI20, .chan = 0 },
> +                       { .csi = RVIN_NC, .chan = 0 },
> +                       { .csi = RVIN_CSI40, .chan = 0 },
> +                       { .csi = RVIN_CSI20, .chan = 0 },
> +               }, {
> +                       { .csi = RVIN_CSI20, .chan = 0 },
> +                       { .csi = RVIN_NC, .chan = 0 },
> +                       { .csi = RVIN_CSI40, .chan = 0 },
> +                       { .csi = RVIN_CSI40, .chan = 1 },
> +                       { .csi = RVIN_CSI20, .chan = 1 },
> +               }, {
> +                       { .csi = RVIN_NC, .chan = 0 },
> +                       { .csi = RVIN_CSI40, .chan = 0 },
> +                       { .csi = RVIN_CSI20, .chan = 0 },
> +                       { .csi = RVIN_CSI40, .chan = 2 },
> +                       { .csi = RVIN_CSI20, .chan = 2 },
> +               }, {
> +                       { .csi = RVIN_CSI40, .chan = 1 },
> +                       { .csi = RVIN_CSI20, .chan = 1 },
> +                       { .csi = RVIN_NC, .chan = 1 },
> +                       { .csi = RVIN_CSI40, .chan = 3 },
> +                       { .csi = RVIN_CSI20, .chan = 3 },
> +               },
> +       },
> +};
> +
>  static const struct of_device_id rvin_of_id_table[] = {
>         {
>                 .compatible = "renesas,vin-r8a7778",
> @@ -1117,6 +1177,10 @@ static const struct of_device_id rvin_of_id_table[] = {
>                 .compatible = "renesas,vin-r8a7795",
>                 .data = &rcar_info_r8a7795,
>         },
> +       {
> +               .compatible = "renesas,vin-r8a7796",
> +               .data = &rcar_info_r8a7796,
> +       },
>         { },
>  };
>  MODULE_DEVICE_TABLE(of, rvin_of_id_table);
> --
> 2.15.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 01/25] rcar-vin: add Gen3 devicetree bindings documentation

[Rob Herring]

On Sat, Nov 11, 2017 at 01:38:11AM +0100, Niklas Söderlund wrote:
> Document the devicetree bindings for the CSI-2 inputs available on Gen3.
> 
> There is a need to add a custom property 'renesas,id' and to define
> which CSI-2 input is described in which endpoint under the port@1 node.
> This information is needed since there are a set of predefined routes
> between each VIN and CSI-2 block. This routing table will be kept
> inside the driver but in order for it to act on it it must know which
> VIN and CSI-2 is which.
> 
> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> ---
>  .../devicetree/bindings/media/rcar_vin.txt         | 116 ++++++++++++++++++---
>  1 file changed, 104 insertions(+), 12 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt b/Documentation/devicetree/bindings/media/rcar_vin.txt
> index 6e4ef8caf759e5d3..df1abd0fb20386f8 100644
> --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> @@ -2,8 +2,12 @@ Renesas R-Car Video Input driver (rcar_vin)
>  -------------------------------------------
>  
>  The rcar_vin device provides video input capabilities for the Renesas R-Car
> -family of devices. The current blocks are always slaves and suppot one input
> -channel which can be either RGB, YUYV or BT656.
> +family of devices.
> +
> +Each VIN instance has a single parallel input that supports RGB and YUV video,
> +with both external synchronization and BT.656 synchronization for the latter.
> +Depending on the instance the VIN input is connected to external SoC pins, or
> +on Gen3 to a CSI-2 receiver.
>  
>   - compatible: Must be one or more of the following
>     - "renesas,vin-r8a7795" for the R8A7795 device
> @@ -28,21 +32,38 @@ channel which can be either RGB, YUYV or BT656.
>  Additionally, an alias named vinX will need to be created to specify
>  which video input device this is.
>  
> -The per-board settings:
> +The per-board settings Gen2:
>   - port sub-node describing a single endpoint connected to the vin
>     as described in video-interfaces.txt[1]. Only the first one will
>     be considered as each vin interface has one input port.
>  
> -   These settings are used to work out video input format and widths
> -   into the system.
> +The per-board settings Gen3:
> +
> +Gen3 can support both a single connected parallel input source from
> +external SoC pins (port0) and/or multiple parallel input sources from
> +local SoC CSI-2 receivers (port1) depending on SoC.
>  
> +- renesas,id - ID number of the VIN, VINx in the documentation.

Why is this needed? We try to avoid indexes unless that's the only way a 
device is addressed (and then we use reg).

Re: [PATCH v7 01/25] rcar-vin: add Gen3 devicetree bindings documentation

[Niklas Söderlund]

Hi Rob,

Thanks for your feedback, much appreciated!

On 2017-11-15 14:02:26 -0600, Rob Herring wrote:
> On Sat, Nov 11, 2017 at 01:38:11AM +0100, Niklas Söderlund wrote:
> > Document the devicetree bindings for the CSI-2 inputs available on Gen3.
> > 
> > There is a need to add a custom property 'renesas,id' and to define
> > which CSI-2 input is described in which endpoint under the port@1 node.
> > This information is needed since there are a set of predefined routes
> > between each VIN and CSI-2 block. This routing table will be kept
> > inside the driver but in order for it to act on it it must know which
> > VIN and CSI-2 is which.
> > 
> > Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> > ---
> >  .../devicetree/bindings/media/rcar_vin.txt         | 116 ++++++++++++++++++---
> >  1 file changed, 104 insertions(+), 12 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt b/Documentation/devicetree/bindings/media/rcar_vin.txt
> > index 6e4ef8caf759e5d3..df1abd0fb20386f8 100644
> > --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> > +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> > @@ -2,8 +2,12 @@ Renesas R-Car Video Input driver (rcar_vin)
> >  -------------------------------------------
> >  
> >  The rcar_vin device provides video input capabilities for the Renesas R-Car
> > -family of devices. The current blocks are always slaves and suppot one input
> > -channel which can be either RGB, YUYV or BT656.
> > +family of devices.
> > +
> > +Each VIN instance has a single parallel input that supports RGB and YUV video,
> > +with both external synchronization and BT.656 synchronization for the latter.
> > +Depending on the instance the VIN input is connected to external SoC pins, or
> > +on Gen3 to a CSI-2 receiver.
> >  
> >   - compatible: Must be one or more of the following
> >     - "renesas,vin-r8a7795" for the R8A7795 device
> > @@ -28,21 +32,38 @@ channel which can be either RGB, YUYV or BT656.
> >  Additionally, an alias named vinX will need to be created to specify
> >  which video input device this is.
> >  
> > -The per-board settings:
> > +The per-board settings Gen2:
> >   - port sub-node describing a single endpoint connected to the vin
> >     as described in video-interfaces.txt[1]. Only the first one will
> >     be considered as each vin interface has one input port.
> >  
> > -   These settings are used to work out video input format and widths
> > -   into the system.
> > +The per-board settings Gen3:
> > +
> > +Gen3 can support both a single connected parallel input source from
> > +external SoC pins (port0) and/or multiple parallel input sources from
> > +local SoC CSI-2 receivers (port1) depending on SoC.
> >  
> > +- renesas,id - ID number of the VIN, VINx in the documentation.
> 
> Why is this needed? We try to avoid indexes unless that's the only way a 
> device is addressed (and then we use reg).

This is unfortunately needed (or something similar) as there is a 
register in one VIN instance which controls the routing of the incoming 
CSI-2 video streams, not only to itself, but also to other VIN instances 
inside the same SoC.

To be more specific I will try to clarify this using the R-Car H3 as an 
example. On the H3 there are 8 instances of the capture hardware (VIN0 - 
VIN7) and 3 instances off CSI-2 receivers (CSI20, CSI40 and CSI41) which 
receives CSI-2 streams, split the possible multiple virtual channels 
(VC) encoded in CSI-2 streams and forwards it to the VIN's.

The problem is that VIN0 and VIN4 are different from the other VIN's, 
they have one register (CHSEL) which controls the limited number of 
possible routes of video streams between a CSI-2 + VC to a specific VIN.  
The CHSEL register in VIN0 controls the routing for VIN0-3 and the one 
in VIN4 controls VIN4-7 (the two subgroups are similar so lets only 
consider VIN0-3).

There are only a handful of routes possible and the kicker is that 
changing the CHSEL value in VIN0, directly reflects all routes for 
VIN0-VIN3 per this table:

CHSEL reg in VIN0:  0         1         2         3         4
Video sent to VIN0: CSI40/VC0 CSI20/VC0 CSI40/VC1 CSI40/VC0 CSI20/VC0
Video sent to VIN1: CSI20/VC0 CSI40/VC1 CSI40/VC0 CSI40/VC1 CSI20/VC1
Video sent to VIN2: CSI20/VC1 CSI40/VC0 CSI20/VC0 CSI40/VC2 CSI20/VC2
Video sent to VIN3: CSI40/VC1 CSI20/VC1 CSI20/VC1 CSI40/VC3 CSI20/VC3

So if CHSEL in VIN0 is set to 2 the following routes are active: VIN0: 
CSI40/VC1, VIN1: CSI40/VC0, VIN2: CSI20/VC0, CSI20/VC1. These routing 
tables are different for most SoCs in the R-Car Gen3 family, and are 
kept inside the driver code.

So the renesas,id properly is used so that the rcar-vin driver knows 
which of the driver instances corresponds to a specific VINx number from 
the documentation so that using the media device API the correct links 
can be added and that the routing table is enforced so a user can't try 
to activate a CSI-2 + VC to a VIN link which is not possible due to 
other routes already being active.

I agree that if possible I would like to not have the need for this 
property, but I can't think of another way on how to give this knowledge 
to the driver in a better way. I'm happy to try out other ideas :-)

Dose this explanation make sens to you?

-- 
Regards,
Niklas Söderlund

Re: [PATCH v7 01/25] rcar-vin: add Gen3 devicetree bindings documentation

[Rob Herring]

On Wed, Nov 15, 2017 at 4:58 PM, Niklas Söderlund
<niklas.soderlund-1zkq55x86MTxsAP9Fp7wbw@public.gmane.org> wrote:
> Hi Rob,
>
> Thanks for your feedback, much appreciated!
>
> On 2017-11-15 14:02:26 -0600, Rob Herring wrote:
>> On Sat, Nov 11, 2017 at 01:38:11AM +0100, Niklas Söderlund wrote:
>> > Document the devicetree bindings for the CSI-2 inputs available on Gen3.
>> >
>> > There is a need to add a custom property 'renesas,id' and to define
>> > which CSI-2 input is described in which endpoint under the port@1 node.
>> > This information is needed since there are a set of predefined routes
>> > between each VIN and CSI-2 block. This routing table will be kept
>> > inside the driver but in order for it to act on it it must know which
>> > VIN and CSI-2 is which.
>> >
>> > Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas-1zkq55x86MTxsAP9Fp7wbw@public.gmane.org>
>> > ---
>> >  .../devicetree/bindings/media/rcar_vin.txt         | 116 ++++++++++++++++++---
>> >  1 file changed, 104 insertions(+), 12 deletions(-)
>> >
>> > diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt b/Documentation/devicetree/bindings/media/rcar_vin.txt
>> > index 6e4ef8caf759e5d3..df1abd0fb20386f8 100644
>> > --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
>> > +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
>> > @@ -2,8 +2,12 @@ Renesas R-Car Video Input driver (rcar_vin)
>> >  -------------------------------------------
>> >
>> >  The rcar_vin device provides video input capabilities for the Renesas R-Car
>> > -family of devices. The current blocks are always slaves and suppot one input
>> > -channel which can be either RGB, YUYV or BT656.
>> > +family of devices.
>> > +
>> > +Each VIN instance has a single parallel input that supports RGB and YUV video,
>> > +with both external synchronization and BT.656 synchronization for the latter.
>> > +Depending on the instance the VIN input is connected to external SoC pins, or
>> > +on Gen3 to a CSI-2 receiver.
>> >
>> >   - compatible: Must be one or more of the following
>> >     - "renesas,vin-r8a7795" for the R8A7795 device
>> > @@ -28,21 +32,38 @@ channel which can be either RGB, YUYV or BT656.
>> >  Additionally, an alias named vinX will need to be created to specify
>> >  which video input device this is.
>> >
>> > -The per-board settings:
>> > +The per-board settings Gen2:
>> >   - port sub-node describing a single endpoint connected to the vin
>> >     as described in video-interfaces.txt[1]. Only the first one will
>> >     be considered as each vin interface has one input port.
>> >
>> > -   These settings are used to work out video input format and widths
>> > -   into the system.
>> > +The per-board settings Gen3:
>> > +
>> > +Gen3 can support both a single connected parallel input source from
>> > +external SoC pins (port0) and/or multiple parallel input sources from
>> > +local SoC CSI-2 receivers (port1) depending on SoC.
>> >
>> > +- renesas,id - ID number of the VIN, VINx in the documentation.
>>
>> Why is this needed? We try to avoid indexes unless that's the only way a
>> device is addressed (and then we use reg).
>
> This is unfortunately needed (or something similar) as there is a
> register in one VIN instance which controls the routing of the incoming
> CSI-2 video streams, not only to itself, but also to other VIN instances
> inside the same SoC.
>
> To be more specific I will try to clarify this using the R-Car H3 as an
> example. On the H3 there are 8 instances of the capture hardware (VIN0 -
> VIN7) and 3 instances off CSI-2 receivers (CSI20, CSI40 and CSI41) which
> receives CSI-2 streams, split the possible multiple virtual channels
> (VC) encoded in CSI-2 streams and forwards it to the VIN's.
>
> The problem is that VIN0 and VIN4 are different from the other VIN's,
> they have one register (CHSEL) which controls the limited number of
> possible routes of video streams between a CSI-2 + VC to a specific VIN.
> The CHSEL register in VIN0 controls the routing for VIN0-3 and the one
> in VIN4 controls VIN4-7 (the two subgroups are similar so lets only
> consider VIN0-3).
>
> There are only a handful of routes possible and the kicker is that
> changing the CHSEL value in VIN0, directly reflects all routes for
> VIN0-VIN3 per this table:
>
> CHSEL reg in VIN0:  0         1         2         3         4
> Video sent to VIN0: CSI40/VC0 CSI20/VC0 CSI40/VC1 CSI40/VC0 CSI20/VC0
> Video sent to VIN1: CSI20/VC0 CSI40/VC1 CSI40/VC0 CSI40/VC1 CSI20/VC1
> Video sent to VIN2: CSI20/VC1 CSI40/VC0 CSI20/VC0 CSI40/VC2 CSI20/VC2
> Video sent to VIN3: CSI40/VC1 CSI20/VC1 CSI20/VC1 CSI40/VC3 CSI20/VC3
>
> So if CHSEL in VIN0 is set to 2 the following routes are active: VIN0:
> CSI40/VC1, VIN1: CSI40/VC0, VIN2: CSI20/VC0, CSI20/VC1. These routing
> tables are different for most SoCs in the R-Car Gen3 family, and are
> kept inside the driver code.
>
> So the renesas,id properly is used so that the rcar-vin driver knows
> which of the driver instances corresponds to a specific VINx number from
> the documentation so that using the media device API the correct links
> can be added and that the routing table is enforced so a user can't try
> to activate a CSI-2 + VC to a VIN link which is not possible due to
> other routes already being active.
>
> I agree that if possible I would like to not have the need for this
> property, but I can't think of another way on how to give this knowledge
> to the driver in a better way. I'm happy to try out other ideas :-)
>
> Dose this explanation make sens to you?

Yes. Thank you. It would be could to summarize this in the binding and
perhaps capture all of this information in the driver if you haven't
already.

Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html