Re: [PATCH] dt-bindings: Fix 'unevaluatedProperties' errors in DT graph users
Hi Rob, Thanks for your work. On 2021-06-23 10:43:44 -0600, Rob Herring wrote: > In testing out under development json-schema 2020-12 support, there's a > few issues with 'unevaluatedProperties' and the graph schema. If > 'graph.yaml#/properties/port' is used, then neither the port nor the > endpoint(s) can have additional properties. 'graph.yaml#/$defs/port-base' > needs to be used instead. > > Cc: Sakari Ailus > Cc: Mauro Carvalho Chehab > Cc: "Paul J. Murphy" > Cc: Daniele Alessandrelli > Cc: "Niklas Söderlund" > Cc: Krzysztof Kozlowski > Cc: Paul Kocialkowski > Cc: dri-devel@lists.freedesktop.org > Cc: linux-me...@vger.kernel.org > Cc: linux-renesas-...@vger.kernel.org > Signed-off-by: Rob Herring > --- > .../devicetree/bindings/display/bridge/lontium,lt8912b.yaml| 3 ++- > Documentation/devicetree/bindings/media/i2c/imx258.yaml| 2 +- > Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml | 2 +- > Documentation/devicetree/bindings/media/i2c/ovti,ov8865.yaml | 2 +- > Documentation/devicetree/bindings/media/i2c/sony,imx334.yaml | 2 +- > Documentation/devicetree/bindings/media/renesas,vin.yaml | 3 ++- For renesas,vin Reviewed-by: Niklas Söderlund > 6 files changed, 8 insertions(+), 6 deletions(-) > > diff --git > a/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml > b/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml > index 735d0233a7d6..674891ee2f8e 100644 > --- a/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml > +++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml > @@ -29,7 +29,8 @@ properties: > > properties: >port@0: > -$ref: /schemas/graph.yaml#/properties/port > +$ref: /schemas/graph.yaml#/$defs/port-base > +unevaluatedProperties: false > description: >Primary MIPI port for MIPI input > > diff --git a/Documentation/devicetree/bindings/media/i2c/imx258.yaml > b/Documentation/devicetree/bindings/media/i2c/imx258.yaml > index 515317eff41a..cde0f7383b2a 100644 > --- a/Documentation/devicetree/bindings/media/i2c/imx258.yaml > +++ b/Documentation/devicetree/bindings/media/i2c/imx258.yaml > @@ -49,7 +49,7 @@ properties: > ># See ../video-interfaces.txt for more details >port: > -$ref: /schemas/graph.yaml#/properties/port > +$ref: /schemas/graph.yaml#/$defs/port-base > additionalProperties: false > > properties: > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml > b/Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml > index 9149f5685688..246dc5fec716 100644 > --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml > @@ -45,7 +45,7 @@ properties: > >port: > description: MIPI CSI-2 transmitter port > -$ref: /schemas/graph.yaml#/properties/port > +$ref: /schemas/graph.yaml#/$defs/port-base > additionalProperties: false > > properties: > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov8865.yaml > b/Documentation/devicetree/bindings/media/i2c/ovti,ov8865.yaml > index 0699c7e4fdeb..b962863e4f65 100644 > --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov8865.yaml > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov8865.yaml > @@ -45,7 +45,7 @@ properties: > >port: > description: MIPI CSI-2 transmitter port > -$ref: /schemas/graph.yaml#/properties/port > +$ref: /schemas/graph.yaml#/$defs/port-base > additionalProperties: false > > properties: > diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx334.yaml > b/Documentation/devicetree/bindings/media/i2c/sony,imx334.yaml > index 27cc5b7ff613..f5055b9db693 100644 > --- a/Documentation/devicetree/bindings/media/i2c/sony,imx334.yaml > +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx334.yaml > @@ -37,7 +37,7 @@ properties: > >port: > additionalProperties: false > -$ref: /schemas/graph.yaml#/properties/port > +$ref: /schemas/graph.yaml#/$defs/port-base > > properties: >endpoint: > diff --git a/Documentation/devicetree/bindings/media/renesas,vin.yaml > b/Documentation/devicetree/bindings/media/renesas,vin.yaml > index dd1a5ce5896c..4945a2f0eca6 100644 > --- a/Documentation/devicetree/bindings/media/renesas,vin.yaml > +++ b/Documentation/devicetree/bindings/media/renesas,vin.yaml > @@ -118,7 +118,8 @@ properties: > > properties: >port@0: > -$ref: /schemas/graph.yaml#/properties/port > +$ref: /schemas/graph.yaml#/$defs/port-base > +unevaluatedProperties: false > description: >Input port node, single endpoint describing a parallel input > source. > > -- > 2.27.0 > -- Regards, Niklas Söderlund
Re: [PATCH] drm/bridge: adv7511: fix support for large EDIDs
Hi Hans,
Thanks for your patch.
On 2021-03-24 09:53:32 +0100, Hans Verkuil wrote:
> While testing support for large (> 256 bytes) EDIDs on the Renesas
> Koelsch board I noticed that the adv7511 bridge driver only read the
> first two blocks.
>
> The media V4L2 version for the adv7511 (drivers/media/i2c/adv7511-v4l2.c)
> handled this correctly.
>
> Besides a simple bug when setting the segment register (it was set to the
> block number instead of block / 2), the logic of the code was also weird.
> In particular reading the DDC_STATUS is odd: this is unrelated to EDID
> reading.
>
> The reworked code just waits for any EDID segment reads to finish (this
> does nothing if the a segment is already read), checks if the desired
> segment matches the read segment, and if not, then it requests the new
> segment and waits again for the EDID segment to be read.
>
> Finally it checks if the currently buffered EDID segment contains the
> desired EDID block, and if not it will update the EDID buffer from
> the adv7511.
>
> Tested with my Koelsch board and with EDIDs of 1, 2, 3 and 4 blocks.
>
> Signed-off-by: Hans Verkuil
Tested-by: Niklas Söderlund
> ---
> Testing on the Renesas board also requires these two adv7604 patches
> if you want to test with an HDMI cable between the HDMI input and output:
>
> https://patchwork.linuxtv.org/project/linux-media/patch/00882808-472a-d429-c565-a701da579...@xs4all.nl/
> https://patchwork.linuxtv.org/project/linux-media/patch/c7093e76-ffb4-b19c-f576-b264f935a...@xs4all.nl/
> ---
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> index 76555ae64e9c..9e8db1c60167 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> @@ -328,6 +328,7 @@ static void adv7511_set_link_config(struct adv7511
> *adv7511,
> static void __adv7511_power_on(struct adv7511 *adv7511)
> {
> adv7511->current_edid_segment = -1;
> + adv7511->edid_read = false;
>
> regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER,
> ADV7511_POWER_POWER_DOWN, 0);
> @@ -529,29 +530,35 @@ static int adv7511_get_edid_block(void *data, u8 *buf,
> unsigned int block,
> struct adv7511 *adv7511 = data;
> struct i2c_msg xfer[2];
> uint8_t offset;
> + unsigned int cur_segment;
> unsigned int i;
> int ret;
>
> if (len > 128)
> return -EINVAL;
>
> - if (adv7511->current_edid_segment != block / 2) {
> - unsigned int status;
> + /* wait for any EDID segment reads to finish */
> + adv7511_wait_for_edid(adv7511, 200);
>
> - ret = regmap_read(adv7511->regmap, ADV7511_REG_DDC_STATUS,
> - );
> + ret = regmap_read(adv7511->regmap, ADV7511_REG_EDID_SEGMENT,
> _segment);
> + if (ret < 0)
> + return ret;
> +
> + /*
> + * If the current read segment does not match what we need, then
> + * write the new segment and wait for it to be read.
> + */
> + if (cur_segment != block / 2) {
> + adv7511->edid_read = false;
> + cur_segment = block / 2;
> + regmap_write(adv7511->regmap, ADV7511_REG_EDID_SEGMENT,
> + cur_segment);
> + ret = adv7511_wait_for_edid(adv7511, 200);
> if (ret < 0)
> return ret;
> + }
>
> - if (status != 2) {
> - adv7511->edid_read = false;
> - regmap_write(adv7511->regmap, ADV7511_REG_EDID_SEGMENT,
> - block);
> - ret = adv7511_wait_for_edid(adv7511, 200);
> - if (ret < 0)
> - return ret;
> - }
> -
> + if (adv7511->current_edid_segment != cur_segment) {
> /* Break this apart, hopefully more I2C controllers will
>* support 64 byte transfers than 256 byte transfers
>*/
> @@ -579,7 +586,7 @@ static int adv7511_get_edid_block(void *data, u8 *buf,
> unsigned int block,
> offset += 64;
> }
>
> - adv7511->current_edid_segment = block / 2;
> + adv7511->current_edid_segment = cur_segment;
> }
>
> if (block % 2 == 0)
--
Regards,
Niklas Söderlund
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/8] dt-bindings: media: renesas,fcp: Make power-domains mandatory
Hi Laurent, Thanks for your work. On 2020-06-21 03:47:28 +0300, Laurent Pinchart wrote: > All DT source files in the kernel tree specify the power-domains > property. Make it mandatory. > > Signed-off-by: Laurent Pinchart > Reviewed-by: Geert Uytterhoeven Reviewed-by: Niklas Söderlund > --- > Changes since v1: > > - Fix typo in commit message > --- > Documentation/devicetree/bindings/media/renesas,fcp.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/media/renesas,fcp.yaml > b/Documentation/devicetree/bindings/media/renesas,fcp.yaml > index 9241bf3c5efc..eeca7e255420 100644 > --- a/Documentation/devicetree/bindings/media/renesas,fcp.yaml > +++ b/Documentation/devicetree/bindings/media/renesas,fcp.yaml > @@ -38,6 +38,7 @@ required: >- compatible >- reg >- clocks > + - power-domains > > additionalProperties: false > > -- > Regards, > > Laurent Pinchart > -- Regards, Niklas Söderlund ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/8] dt-bindings: media: renesas, fdp1: Convert binding to YAML
Hi Laurent,
Thanks for your work.
On 2020-06-21 03:47:30 +0300, Laurent Pinchart wrote:
> Convert the Renesas R-Car FDP1 text binding to YAML.
>
> Signed-off-by: Laurent Pinchart
> Reviewed-by: Geert Uytterhoeven
Reviewed-by: Niklas Söderlund
> ---
> Changes since v1:
>
> - Update MAINTAINERS
> ---
> .../bindings/media/renesas,fdp1.txt | 37 ---
> .../bindings/media/renesas,fdp1.yaml | 63 +++
> MAINTAINERS | 2 +-
> 3 files changed, 64 insertions(+), 38 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/media/renesas,fdp1.txt
> create mode 100644 Documentation/devicetree/bindings/media/renesas,fdp1.yaml
>
> diff --git a/Documentation/devicetree/bindings/media/renesas,fdp1.txt
> b/Documentation/devicetree/bindings/media/renesas,fdp1.txt
> deleted file mode 100644
> index 8dd1007bb573..
> --- a/Documentation/devicetree/bindings/media/renesas,fdp1.txt
> +++ /dev/null
> @@ -1,37 +0,0 @@
> -Renesas R-Car Fine Display Processor (FDP1)
>
> -
> -The FDP1 is a de-interlacing module which converts interlaced video to
> -progressive video. It is capable of performing pixel format conversion
> between
> -YCbCr/YUV formats and RGB formats. Only YCbCr/YUV formats are supported as
> -an input to the module.
> -
> -Required properties:
> -
> - - compatible: must be "renesas,fdp1"
> - - reg: the register base and size for the device registers
> - - interrupts : interrupt specifier for the FDP1 instance
> - - clocks: reference to the functional clock
> -
> -Optional properties:
> -
> - - power-domains: reference to the power domain that the FDP1 belongs to, if
> - any.
> - - renesas,fcp: a phandle referencing the FCP that handles memory accesses
> -for the FDP1. Not needed on Gen2, mandatory on Gen3.
> -
> -Please refer to the binding documentation for the clock and/or power domain
> -providers for more details.
> -
> -
> -Device node example
>
> -
> - fdp1@fe94 {
> - compatible = "renesas,fdp1";
> - reg = <0 0xfe94 0 0x2400>;
> - interrupts = ;
> - clocks = < CPG_MOD 119>;
> - power-domains = < R8A7795_PD_A3VP>;
> - renesas,fcp = <>;
> - };
> diff --git a/Documentation/devicetree/bindings/media/renesas,fdp1.yaml
> b/Documentation/devicetree/bindings/media/renesas,fdp1.yaml
> new file mode 100644
> index ..f4db96a1f53c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/renesas,fdp1.yaml
> @@ -0,0 +1,63 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/renesas,fdp1.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Renesas R-Car Fine Display Processor (FDP1)
> +
> +maintainers:
> + - Laurent Pinchart
> +
> +description:
> + The FDP1 is a de-interlacing module which converts interlaced video to
> + progressive video. It is capable of performing pixel format conversion
> + between YCbCr/YUV formats and RGB formats. Only YCbCr/YUV formats are
> + supported as an input to the module.
> +
> +properties:
> + compatible:
> +enum:
> + - renesas,fdp1
> +
> + reg:
> +maxItems: 1
> +
> + interrupts:
> +maxItems: 1
> +
> + clocks:
> +maxItems: 1
> +
> + power-domains:
> +maxItems: 1
> +
> + renesas,fcp:
> +$ref: /schemas/types.yaml#/definitions/phandle
> +description:
> + A phandle referencing the FCP that handles memory accesses for the
> FDP1.
> + Not allowed on R-Car Gen2, mandatory on R-Car Gen3.
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - clocks
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +#include
> +#include
> +
> +fdp1@fe94 {
> +compatible = "renesas,fdp1";
> +reg = <0xfe94 0x2400>;
> +interrupts = ;
> +clocks = < CPG_MOD 119>;
> +power-domains = < R8A7795_PD_A3VP>;
> +renesas,fcp = <>;
> +};
> +...
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 660ed6606de2..7383dfa510a3 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -10710,7 +10710,7 @@ L:linux-me...@vger.kernel.org
> L: linux-renesas-...@vger.kernel.org
> S: Supported
> T: git git://linuxtv.org/media_tree.git
> -F: Documentation/devicetree/bindings/media/renesas,fdp1.txt
> +F: Documentation/devicetree/bindings/media/renesas,fdp1.yaml
> F: drivers/media/platform/rcar_fdp1.c
>
> MEDIA DRIVERS FOR RENESAS - VIN
> --
> Regards,
>
> Laurent Pinchart
>
--
Regards,
Niklas Söderlund
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 6/8] dt-bindings: media: renesas,fdp1: Add resets property
Hi Laurent, Thanks for your work. On 2020-06-21 03:47:32 +0300, Laurent Pinchart wrote: > The resets property is used in DT sources in the kernel tree. Document > it and make it mandatory. > > Signed-off-by: Laurent Pinchart > Reviewed-by: Geert Uytterhoeven Reviewed-by: Niklas Söderlund > --- > Changes since v1: > > - Fix typo in commit message > --- > Documentation/devicetree/bindings/media/renesas,fdp1.yaml | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/Documentation/devicetree/bindings/media/renesas,fdp1.yaml > b/Documentation/devicetree/bindings/media/renesas,fdp1.yaml > index 39184bd21a27..2a27a7296fea 100644 > --- a/Documentation/devicetree/bindings/media/renesas,fdp1.yaml > +++ b/Documentation/devicetree/bindings/media/renesas,fdp1.yaml > @@ -32,6 +32,9 @@ properties: >power-domains: > maxItems: 1 > > + resets: > +maxItems: 1 > + >renesas,fcp: > $ref: /schemas/types.yaml#/definitions/phandle > description: > @@ -44,6 +47,7 @@ required: >- interrupts >- clocks >- power-domains > + - resets > > additionalProperties: false > > @@ -59,6 +63,7 @@ examples: > interrupts = ; > clocks = < CPG_MOD 119>; > power-domains = < R8A7795_PD_A3VP>; > +resets = < 119>; > renesas,fcp = <>; > }; > ... > -- > Regards, > > Laurent Pinchart > -- Regards, Niklas Söderlund ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 7/8] dt-bindings: media: renesas, vsp1: Convert binding to YAML
Hi Laurent,
Thanks for your patch.
On 2020-06-21 03:47:33 +0300, Laurent Pinchart wrote:
> Convert the Renesas R-Car VSP1 text binding to YAML.
>
> Signed-off-by: Laurent Pinchart
> Reviewed-by: Geert Uytterhoeven
Reviewed-by: Niklas Söderlund
> ---
> Changes since v1:
>
> - Simplify comments on compatible strings
> - Update MAINTAINERS
> ---
> .../bindings/media/renesas,vsp1.txt | 30 ---
> .../bindings/media/renesas,vsp1.yaml | 83 +++
> MAINTAINERS | 2 +-
> 3 files changed, 84 insertions(+), 31 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/media/renesas,vsp1.txt
> create mode 100644 Documentation/devicetree/bindings/media/renesas,vsp1.yaml
>
> diff --git a/Documentation/devicetree/bindings/media/renesas,vsp1.txt
> b/Documentation/devicetree/bindings/media/renesas,vsp1.txt
> deleted file mode 100644
> index cd5a955b2ea0..
> --- a/Documentation/devicetree/bindings/media/renesas,vsp1.txt
> +++ /dev/null
> @@ -1,30 +0,0 @@
> -* Renesas VSP Video Processing Engine
> -
> -The VSP is a video processing engine that supports up-/down-scaling, alpha
> -blending, color space conversion and various other image processing features.
> -It can be found in the Renesas R-Car Gen2, R-Car Gen3, RZ/G1, and RZ/G2 SoCs.
> -
> -Required properties:
> -
> - - compatible: Must contain one of the following values
> -- "renesas,vsp1" for the R-Car Gen2 and RZ/G1 VSP1
> -- "renesas,vsp2" for the R-Car Gen3 and RZ/G2 VSP2
> -
> - - reg: Base address and length of the registers block for the VSP.
> - - interrupts: VSP interrupt specifier.
> - - clocks: A phandle + clock-specifier pair for the VSP functional clock.
> -
> -Optional properties:
> -
> - - renesas,fcp: A phandle referencing the FCP that handles memory accesses
> - for the VSP. Not needed on Gen2, mandatory on Gen3.
> -
> -
> -Example: R8A7790 (R-Car H2) VSP1-S node
> -
> - vsp@fe928000 {
> - compatible = "renesas,vsp1";
> - reg = <0 0xfe928000 0 0x8000>;
> - interrupts = <0 267 IRQ_TYPE_LEVEL_HIGH>;
> - clocks = <_clks R8A7790_CLK_VSP1_S>;
> - };
> diff --git a/Documentation/devicetree/bindings/media/renesas,vsp1.yaml
> b/Documentation/devicetree/bindings/media/renesas,vsp1.yaml
> new file mode 100644
> index ..65e8ee61ce90
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/renesas,vsp1.yaml
> @@ -0,0 +1,83 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/renesas,vsp1.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Renesas VSP Video Processing Engine
> +
> +maintainers:
> + - Laurent Pinchart
> +
> +description:
> + The VSP is a video processing engine that supports up-/down-scaling, alpha
> + blending, color space conversion and various other image processing
> features.
> + It can be found in the Renesas R-Car Gen2, R-Car Gen3, RZ/G1, and RZ/G2
> SoCs.
> +
> +properties:
> + compatible:
> +enum:
> + - renesas,vsp1 # R-Car Gen2 and RZ/G1
> + - renesas,vsp2 # R-Car Gen3 and RZ/G2
> +
> + reg:
> +maxItems: 1
> +
> + interrupts:
> +maxItems: 1
> +
> + clocks:
> +maxItems: 1
> +
> + renesas,fcp:
> +$ref: /schemas/types.yaml#/definitions/phandle
> +description:
> + A phandle referencing the FCP that handles memory accesses for the VSP.
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - clocks
> +
> +additionalProperties: false
> +
> +if:
> + properties:
> +compatible:
> + items:
> +- const: renesas,vsp1
> +then:
> + properties:
> +renesas,fcp: false
> +else:
> + required:
> +- renesas,fcp
> +
> +examples:
> + # R8A7790 (R-Car H2) VSP1-S
> + - |
> +#include
> +#include
> +
> +vsp@fe928000 {
> +compatible = "renesas,vsp1";
> +reg = <0xfe928000 0x8000>;
> +interrupts = ;
> +clocks = < CPG_MOD 131>;
> +};
> +
> + # R8A77951 (R-Car H3) VSP2-BC
> + - |
> +#include
> +#include
> +
> +vsp@fe92 {
> +compatible = "renesas,vsp2";
> +reg = <0xfe92 0x8000>;
> +interrupts = ;
> +clocks = < CPG_MOD 624>;
> +
> +renesas,fcp = <>;
> +};
> +...
> diff --git a/MAINTAINERS b/MAINTAINERS
Re: [PATCH v2 1/8] dt-bindings: media: renesas,fcp: Convert binding to YAML
Hi Laurent,
Thanks for your work.
On 2020-06-21 03:47:27 +0300, Laurent Pinchart wrote:
> Convert the Renesas R-Car FCP text binding to YAML.
>
> Signed-off-by: Laurent Pinchart
> Reviewed-by: Geert Uytterhoeven
> ---
> Changes since v1:
>
> - Simplify comments on compatible strings
> - Update MAINTAINERS
> ---
> .../devicetree/bindings/media/renesas,fcp.txt | 34 ---
> .../bindings/media/renesas,fcp.yaml | 56 +++
> MAINTAINERS | 2 +-
> 3 files changed, 57 insertions(+), 35 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/media/renesas,fcp.txt
> create mode 100644 Documentation/devicetree/bindings/media/renesas,fcp.yaml
>
> diff --git a/Documentation/devicetree/bindings/media/renesas,fcp.txt
> b/Documentation/devicetree/bindings/media/renesas,fcp.txt
> deleted file mode 100644
> index 79c37395b396..
> --- a/Documentation/devicetree/bindings/media/renesas,fcp.txt
> +++ /dev/null
> @@ -1,34 +0,0 @@
> -Renesas R-Car Frame Compression Processor (FCP)
>
> -
> -The FCP is a companion module of video processing modules in the Renesas
> R-Car
> -Gen3 and RZ/G2 SoCs. It provides data compression and decompression, data
> -caching, and conversion of AXI transactions in order to reduce the memory
> -bandwidth.
> -
> -There are three types of FCP: FCP for Codec (FCPC), FCP for VSP (FCPV) and
> FCP
> -for FDP (FCPF). Their configuration and behaviour depend on the module they
> -are paired with. These DT bindings currently support the FCPV and FCPF.
> -
> - - compatible: Must be one or more of the following
> -
> - - "renesas,fcpv" for generic compatible 'FCP for VSP'
> - - "renesas,fcpf" for generic compatible 'FCP for FDP'
> -
> - - reg: the register base and size for the device registers
> - - clocks: Reference to the functional clock
> -
> -Optional properties:
> - - power-domains : power-domain property defined with a power domain
> specifier
> -to respective power domain.
> -
> -
> -Device node example
>
> -
> - fcpvd1: fcp@fea2f000 {
> - compatible = "renesas,fcpv";
> - reg = <0 0xfea2f000 0 0x200>;
> - clocks = < CPG_MOD 602>;
> - power-domains = < R8A7795_PD_A3VP>;
> - };
> diff --git a/Documentation/devicetree/bindings/media/renesas,fcp.yaml
> b/Documentation/devicetree/bindings/media/renesas,fcp.yaml
> new file mode 100644
> index ..9241bf3c5efc
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/renesas,fcp.yaml
> @@ -0,0 +1,56 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/renesas,fcp.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Renesas R-Car Frame Compression Processor (FCP)
> +
> +maintainers:
> + - Laurent Pinchart
> +
> +description: |
> + The FCP is a companion module of video processing modules in the Renesas
> + R-Car Gen3 and RZ/G2 SoCs. It provides data compression and decompression,
> + data caching, and conversion of AXI transactions in order to reduce the
> + memory bandwidth.
> +
> + There are three types of FCP: FCP for Codec (FCPC), FCP for VSP (FCPV) and
> + FCP for FDP (FCPF). Their configuration and behaviour depend on the module
> + they are paired with. These DT bindings currently support the FCPV and
> FCPF.
> +
> +properties:
> + compatible:
> +enum:
> + - renesas,fcpv # FCP for VSP
> + - renesas,fcpf # FCP for FDP
> +
> + reg:
> +maxItems: 1
> +
> + clocks:
> +maxItems: 1
> +
> + power-domains:
> +maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> +
> +additionalProperties: false
> +
> +examples:
> + # R8A7790 (R-Car H2) VSP1-S
Hum, R8A7790 is H2 but the example below is from H3 R8A7795[01] is it
not? With this fixed,
Reviewed-by: Niklas Söderlund
> + - |
> +#include
> +#include
> +
> +fcp@fea2f000 {
> +compatible = "renesas,fcpv";
> +reg = <0xfea2f000 0x200>;
> +clocks = < CPG_MOD 602>;
> +power-domains = < R8A7795_PD_ALWAYS_ON>;
> +};
> +...
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 68f21d46614c..660ed6606de2 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -10700,7 +10700,7 @@ L:linux-me...@vger.kernel.org
> L: linux-renesas-...@vger.kernel.org
> S: Supported
> T: git git://linuxtv.org/media_tree.git
> -F: Documentation/devicetree/bindings/media/renesas,fcp.txt
> +F: Documentation/devicetree/bindings/media/renesas,fcp.yaml
> F: drivers/media/platform/rcar-fcp.c
> F: include/media/rcar-fcp.h
>
> --
> Regards,
>
> Laurent Pinchart
>
--
Regards,
Niklas Söderlund
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 5/8] dt-bindings: media: renesas,fdp1: Make power-domains mandatory
Hi Laurent, Thank for your patch. On 2020-06-21 03:47:31 +0300, Laurent Pinchart wrote: > All DT source files in the kernel tree specify the power-domains > property. Make it mandatory. > > Signed-off-by: Laurent Pinchart > Reviewed-by: Geert Uytterhoeven Reviewed-by: Niklas Söderlund > --- > Changes since v1: > > - Fix typo in comment message > --- > Documentation/devicetree/bindings/media/renesas,fdp1.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/media/renesas,fdp1.yaml > b/Documentation/devicetree/bindings/media/renesas,fdp1.yaml > index f4db96a1f53c..39184bd21a27 100644 > --- a/Documentation/devicetree/bindings/media/renesas,fdp1.yaml > +++ b/Documentation/devicetree/bindings/media/renesas,fdp1.yaml > @@ -43,6 +43,7 @@ required: >- reg >- interrupts >- clocks > + - power-domains > > additionalProperties: false > > -- > Regards, > > Laurent Pinchart > -- Regards, Niklas Söderlund ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 8/8] dt-bindings: media: renesas,vsp1: Add power-domains and resets
Hi Laurent,
Thanks for your patch.
On 2020-06-21 03:47:34 +0300, Laurent Pinchart wrote:
> The power-domains and resets properties are used in all DT sources in
> the kernel but are absent from the bindings. Document them and make them
> mandatory.
>
> Signed-off-by: Laurent Pinchart
> Reviewed-by: Geert Uytterhoeven
Reviewed-by: Niklas Söderlund
> ---
> .../devicetree/bindings/media/renesas,vsp1.yaml| 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/media/renesas,vsp1.yaml
> b/Documentation/devicetree/bindings/media/renesas,vsp1.yaml
> index 65e8ee61ce90..990e9c1dbc43 100644
> --- a/Documentation/devicetree/bindings/media/renesas,vsp1.yaml
> +++ b/Documentation/devicetree/bindings/media/renesas,vsp1.yaml
> @@ -29,6 +29,12 @@ properties:
>clocks:
> maxItems: 1
>
> + power-domains:
> +maxItems: 1
> +
> + resets:
> +maxItems: 1
> +
>renesas,fcp:
> $ref: /schemas/types.yaml#/definitions/phandle
> description:
> @@ -39,6 +45,8 @@ required:
>- reg
>- interrupts
>- clocks
> + - power-domains
> + - resets
>
> additionalProperties: false
>
> @@ -59,24 +67,30 @@ examples:
>- |
> #include
> #include
> +#include
>
> vsp@fe928000 {
> compatible = "renesas,vsp1";
> reg = <0xfe928000 0x8000>;
> interrupts = ;
> clocks = < CPG_MOD 131>;
> +power-domains = < R8A7790_PD_ALWAYS_ON>;
> +resets = < 131>;
> };
>
># R8A77951 (R-Car H3) VSP2-BC
>- |
> #include
> #include
> +#include
>
> vsp@fe92 {
> compatible = "renesas,vsp2";
> reg = <0xfe92 0x8000>;
> interrupts = ;
> clocks = < CPG_MOD 624>;
> +power-domains = < R8A7795_PD_A3VP>;
> +resets = < 624>;
>
> renesas,fcp = <>;
> };
> --
> Regards,
>
> Laurent Pinchart
>
--
Regards,
Niklas Söderlund
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/8] dt-bindings: media: renesas,fcp: Add resets and iommus properties
Hi Laurent, Thanks for your patch. On 2020-06-21 03:47:29 +0300, Laurent Pinchart wrote: > The resets and iommus properties are used in DT sources in the kernel > tree. Document them, and make resets mandatory. The iommus property is > optional as not all platforms wire the FCP to a functional IOMMU. > > Signed-off-by: Laurent Pinchart > Reviewed-by: Geert Uytterhoeven Reviewed-by: Niklas Söderlund > --- > Documentation/devicetree/bindings/media/renesas,fcp.yaml | 9 + > 1 file changed, 9 insertions(+) > > diff --git a/Documentation/devicetree/bindings/media/renesas,fcp.yaml > b/Documentation/devicetree/bindings/media/renesas,fcp.yaml > index eeca7e255420..b6cf2958e6c9 100644 > --- a/Documentation/devicetree/bindings/media/renesas,fcp.yaml > +++ b/Documentation/devicetree/bindings/media/renesas,fcp.yaml > @@ -31,14 +31,21 @@ properties: >clocks: > maxItems: 1 > > + iommus: > +maxItems: 1 > + >power-domains: > maxItems: 1 > > + resets: > +maxItems: 1 > + > required: >- compatible >- reg >- clocks >- power-domains > + - resets > > additionalProperties: false > > @@ -53,5 +60,7 @@ examples: > reg = <0xfea2f000 0x200>; > clocks = < CPG_MOD 602>; > power-domains = < R8A7795_PD_ALWAYS_ON>; > +resets = < 602>; > +iommus = <_vi0 9>; > }; > ... > -- > Regards, > > Laurent Pinchart > -- Regards, Niklas Söderlund ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/fourcc: Add bayer formats and modifiers
Bayer formats are used with cameras and contain green, red and blue
components, with alternating lines of red and green, and blue and green
pixels in different orders. For each block of 2x2 pixels there is one
pixel with a red filter, two with a green filter, and one with a blue
filter. The filters can be arranged in different patterns.
Add DRM fourcc formats to describe the most common Bayer formats. Also
add a modifiers to describe the custom packing layouts used by the Intel
IPU3 and in the MIPI (Mobile Industry Processor Interface) CSI-2
specification.
Signed-off-by: Niklas Söderlund
---
* Changes since v1
- Rename the defines from DRM_FORMAT_SRGGB8 to DRM_FORMAT_BAYER_RGGB8.
- Update the fourcc codes passed to fourcc_code() to avoid a conflict.
- Add diagrams for all Bayer formats memory layout.
- Update documentation.
---
include/uapi/drm/drm_fourcc.h | 205 ++
1 file changed, 205 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 8bc0b31597d80737..d07dd24b49bde6c1 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -285,6 +285,73 @@ extern "C" {
#define DRM_FORMAT_YUV444 fourcc_code('Y', 'U', '2', '4') /*
non-subsampled Cb (1) and Cr (2) planes */
#define DRM_FORMAT_YVU444 fourcc_code('Y', 'V', '2', '4') /*
non-subsampled Cr (1) and Cb (2) planes */
+/*
+ * Bayer formats
+ *
+ * Bayer formats contain green, red and blue components, with alternating lines
+ * of red and green, and blue and green pixels in different orders. For each
+ * block of 2x2 pixels there is one pixel with a red filter, two with a green
+ * filter, and one with a blue filter. The filters can be arranged in different
+ * patterns.
+ *
+ * For example, RGGB:
+ * row0: RGRGRGRG...
+ * row1: GBGBGBGB...
+ * row2: RGRGRGRG...
+ * row3: GBGBGBGB...
+ * ...
+ *
+ * Vendors have different methods to pack the pixel samples. For this reason
the
+ * fourcc only describes pixel sample size and the filter pattern for each
block
+ * of 2x2 pixels. A modifier is needed to describe the memory layout.
+ *
+ * In addition to vendor modifiers for memory layout DRM_FORMAT_MOD_LINEAR may
+ * be used to describe a layout where all samples are placed consecutively in
+ * memory. If the sample does not fit inside a single byte each sample is
stored
+ * in the minimum number of bytes required. Any unused bits in each sample are
+ * defined as padding bits and set to zero.
+ *
+ * For example, DRM_FORMAT_BAYER_RGGB10 with DRM_FORMAT_MOD_LINEAR:
+ *
+ * 0 row 0 (RGRG)
31
+ * + - - - - - - - - + - - - - - - - - + - - - - - - -
- + - - - - - - - - +
+ * | r0 r0 r0 r0 r0 r0 r0 r0 | 0 0 0 0 0 0 r0 r0 | g0 g0 g0 g0 g0 g0 g0
g0 | 0 0 0 0 0 0 g0 g0 |
+ * + - - - - - - - - + - - - - - - - - + - - - - - - -
- + - - - - - - - - +
+ * | r1 r1 r1 r1 r1 r1 r1 r1 | 0 0 0 0 0 0 r1 r1 | g1 g1 g1 g1 g1 g1 g1
g1 | 0 0 0 0 0 0 g1 g1 |
+ * + - - - - - - - - + - - - - - - - - + - - - - - - -
- + - - - - - - - - +
+ *
+ * 0 row 1 (GBGB)
31
+ * + - - - - - - - - + - - - - - - - - + - - - - - - -
- + - - - - - - - - +
+ * | g0 g0 g0 g0 g0 g0 g0 g0 | 0 0 0 0 0 0 g0 g0 | b0 b0 b0 b0 b0 b0 b0
b0 | 0 0 0 0 0 0 b0 b0 |
+ * + - - - - - - - - + - - - - - - - - + - - - - - - -
- + - - - - - - - - +
+ * | g1 g1 g1 g1 g1 g1 g1 g1 | 0 0 0 0 0 0 g1 g1 | b1 b1 b1 b1 b1 b1 b1
b1 | 0 0 0 0 0 0 b1 b1 |
+ * + - - - - - - - - + - - - - - - - - + - - - - - - -
- + - - - - - - - - +
+ */
+
+/* 8-bits Bayer formats */
+#define DRM_FORMAT_BAYER_RGGB8 fourcc_code('R', 'G', 'G', 'B')
+#define DRM_FORMAT_BAYER_GRBG8 fourcc_code('G', 'R', 'B', 'G')
+#define DRM_FORMAT_BAYER_GBRG8 fourcc_code('G', 'B', 'R', 'G')
+#define DRM_FORMAT_BAYER_BGGR8 fourcc_code('B', 'G', 'G', 'R')
+
+/* 10-bit Bayer formats */
+#define DRM_FORMAT_BAYER_RGGB10fourcc_code('R', 'G', '1', '0')
+#define DRM_FORMAT_BAYER_GRBG10fourcc_code('G', 'R', '1', '0')
+#define DRM_FORMAT_BAYER_GBRG10fourcc_code('G', 'B', '1', '0')
+#define DRM_FORMAT_BAYER_BGGR10fourcc_code('B', 'G', '1', '0')
+
+/* 12-bit Bayer formats */
+#define DRM_FORMAT_BAYER_RGGB12fourcc_code('R', 'G', '1', '2')
+#define DRM_FORMAT_BAYER_GRBG12fourcc_code('G', 'R', '1', '2')
+#define DRM_FORMAT_BAYER_GBRG12fourcc_code('G', 'B', '1', '2')
+#define DRM_FORMAT_BAYER_BGGR12fourcc_code('B', 'G', '1', '2')
+
+/* 14-bit Bay
[PATCH] drm/fourcc: Add bayer formats and modifiers
Bayer formats are used with cameras and contain green, red and blue
components, with alternating lines of red and green, and blue and green
pixels in different orders. For each block of 2x2 pixels there is one
pixel with a red filter, two with a green filter, and one with a blue
filter. The filters can be arranged in different patterns.
Add DRM fourcc formats to describe the most common Bayer formats. Also
add a modifiers to describe the custom packing layouts used by the Intel
IPU3 and in the MIPI (Mobile Industry Processor Interface) CSI-2
specification.
Signed-off-by: Niklas Söderlund
---
include/uapi/drm/drm_fourcc.h | 95 +++
1 file changed, 95 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 8bc0b31597d80737..561d5a08ffd16b69 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -286,6 +286,62 @@ extern "C" {
#define DRM_FORMAT_YVU444 fourcc_code('Y', 'V', '2', '4') /*
non-subsampled Cr (1) and Cb (2) planes */
+/*
+ * Bayer formats
+ *
+ * Bayer formats contain green, red and blue components, with alternating lines
+ * of red and green, and blue and green pixels in different orders. For each
+ * block of 2x2 pixels there is one pixel with a red filter, two with a green
+ * filter, and one with a blue filter. The filters can be arranged in different
+ * patterns.
+ *
+ * For example, RGGB:
+ * row0: RGRGRGRG...
+ * row1: GBGBGBGB...
+ * row3: RGRGRGRG...
+ * row4: GBGBGBGB...
+ * ...
+ *
+ * Vendors have different methods to pack the sampling formats to increase data
+ * density. For this reason the fourcc only describes pixel sample size and the
+ * filter pattern for each block of 2x2 pixels. A modifier is needed to
+ * describe the memory layout.
+ *
+ * In addition to vendor modifiers for memory layout DRM_FORMAT_MOD_LINEAR may
+ * be used to describe a layout where all samples are placed consecutively in
+ * memory. If the sample does not fit inside a single byte, the sample storage
+ * is extended to the minimum number of (little endian) bytes that can hold the
+ * sample and any unused most-significant bits are defined as padding.
+ *
+ * For example, SRGGB10:
+ * Each 10-bit sample is contained in 2 consecutive little endian bytes, where
+ * the 6 most-significant bits are unused.
+ */
+
+/* 8-bit Bayer formats */
+#define DRM_FORMAT_SRGGB8 fourcc_code('R', 'G', 'G', 'B')
+#define DRM_FORMAT_SGRBG8 fourcc_code('G', 'R', 'B', 'G')
+#define DRM_FORMAT_SGBRG8 fourcc_code('G', 'B', 'R', 'G')
+#define DRM_FORMAT_SBGGR8 fourcc_code('B', 'A', '8', '1')
+
+/* 10-bit Bayer formats */
+#define DRM_FORMAT_SRGGB10 fourcc_code('R', 'G', '1', '0')
+#define DRM_FORMAT_SGRBG10 fourcc_code('B', 'A', '1', '0')
+#define DRM_FORMAT_SGBRG10 fourcc_code('G', 'B', '1', '0')
+#define DRM_FORMAT_SBGGR10 fourcc_code('B', 'G', '1', '0')
+
+/* 12-bit Bayer formats */
+#define DRM_FORMAT_SRGGB12 fourcc_code('R', 'G', '1', '2')
+#define DRM_FORMAT_SGRBG12 fourcc_code('B', 'A', '1', '2')
+#define DRM_FORMAT_SGBRG12 fourcc_code('G', 'B', '1', '2')
+#define DRM_FORMAT_SBGGR12 fourcc_code('B', 'G', '1', '2')
+
+/* 14-bit Bayer formats */
+#define DRM_FORMAT_SRGGB14 fourcc_code('R', 'G', '1', '4')
+#define DRM_FORMAT_SGRBG14 fourcc_code('B', 'A', '1', '4')
+#define DRM_FORMAT_SGBRG14 fourcc_code('G', 'B', '1', '4')
+#define DRM_FORMAT_SBGGR14 fourcc_code('B', 'G', '1', '4')
+
/*
* Format Modifiers:
*
@@ -309,6 +365,7 @@ extern "C" {
#define DRM_FORMAT_MOD_VENDOR_BROADCOM 0x07
#define DRM_FORMAT_MOD_VENDOR_ARM 0x08
#define DRM_FORMAT_MOD_VENDOR_ALLWINNER 0x09
+#define DRM_FORMAT_MOD_VENDOR_MIPI 0x0a
/* add more to the end as needed */
@@ -434,6 +491,17 @@ extern "C" {
*/
#define I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS fourcc_mod_code(INTEL, 7)
+
+/*
+ * IPU3 Bayer packing layout
+ *
+ * The IPU3 raw Bayer formats use a custom packing layout where there are no
+ * gaps between each 10-bit sample. It packs 25 pixels into 32 bytes leaving
+ * the 6 most significant bits in the last byte unused. The format is little
+ * endian.
+ */
+#define IPU3_FORMAT_MOD_PACKED fourcc_mod_code(INTEL, 8)
+
/*
* Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
*
@@ -804,6 +872,33 @@ extern "C" {
*/
#define DRM_FORMAT_MOD_ALLWINNER_TILED fourcc_mod_code(ALLWINNER, 1)
+/* Mobile Industry Processor Interface (MIPI) modifiers */
+
+/*
+ * MIPI CSI-2 packing layout
+ *
+ * The CSI-2 RAW formats (for example Bayer) use a different packing layout
+ * depenindg on the sample size.
+ *
+ * - 10-bits per sample
+ * Every four consecutive samples are packed into 5 bytes. Each of the first
4
+ * bytes contain the 8 high order bits of the pixels, and the 5th byte
+ * contains the 2 least-significant bits of each pixel, in the same order.
+ *
+ * - 12-bit
Re: [PATCH v5 3/3] arm64: dts: renesas: Add LVDS decoder to R-Car V3M Eagle
Hi Jacopo,
Thanks for your patch.
This one must depend on '[PATCH v2 0/5] arm64: dts: renesas: r8a77970:
enable HDMI output' or something similar not yet in renesas-drivers
repository correct?
In the next version would you care to include the LVDS commit from the
dependency series and squash this change into that one or in some other
good manger stack to two? Laurent told me he did not like 5/5 in that
patch-set as it did not yet have the LVDS decoder node due to no driver
existed at that time when I posted that even if it's not strictly needed
to get the display working :-)
I also think you should split this last patch out to a separate series
as it should go in Simon's tree while the driver and documentation is
going in earlier in a different tree right?
On a side note, do you plan to update the Gen2 boards DTS files which
also have a decoder which are not yet described in DT?
On 2018-03-15 17:11:56 +0100, Jacopo Mondi wrote:
> The R-Car V3M Eagle board includes a transparent THC63LVD1024 LVDS
> decoder, connected to the on-chip LVDS encoder output on one side
> and to HDMI encoder ADV7511w on the other one.
>
> As the decoder does not need any configuration it has been so-far
> omitted from DTS. Now that a driver is available, describe it in DT
> as well.
>
> Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
> Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>
> ---
> arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 33
> +++---
> 1 file changed, 30 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
> b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
> index c0fd144..69f43b8 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
> @@ -42,6 +42,33 @@
> };
> };
> };
> +
> + thc63lvd1024: lvds-decoder {
> + compatible = "thine,thc63lvd1024";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + thc63lvd1024_in_0: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> +
> + port@2{
> + reg = <2>;
> +
> + thc63lvd1024_out_2: endpoint {
> + remote-endpoint = <_in>;
> + };
> +
> + };
> +
> + };
> + };
> };
>
> {
> @@ -98,7 +125,7 @@
> port@0 {
> reg = <0>;
> adv7511_in: endpoint {
> - remote-endpoint = <_out>;
> + remote-endpoint = <_out_2>;
> };
> };
>
> @@ -152,8 +179,8 @@
>
> ports {
> port@1 {
> - endpoint {
> - remote-endpoint = <_in>;
> + lvds0_out: endpoint {
> + remote-endpoint = <_in_0>;
> };
> };
> };
> --
> 2.7.4
>
--
Regards,
Niklas Söderlund
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder
Hi Jacopo,
Thanks for your patch,
On 2018-03-15 17:11:54 +0100, Jacopo Mondi wrote:
> Document Thine THC63LVD1024 LVDS decoder device tree bindings.
>
> Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
> Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
> ---
> .../bindings/display/bridge/thine,thc63lvd1024.txt | 66
> ++
> 1 file changed, 66 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> new file mode 100644
> index 000..8225c6a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> @@ -0,0 +1,66 @@
> +Thine Electronics THC63LVD1024 LVDS decoder
> +---
> +
> +The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS
> streams
> +to parallel data outputs. The chip supports single/dual input/output modes,
> +handling up to two two input LVDS stream and up to two digital CMOS/TTL
> outputs.
> +
> +Single or dual operation modes, output data mapping and DDR output modes are
> +configured through input signals and the chip does not expose any control
> bus.
> +
> +Required properties:
> +- compatible: Shall be "thine,thc63lvd1024"
> +
> +Optional properties:
> +- vcc-supply: Power supply for TTL output and digital circuitry
> +- cvcc-supply: Power supply for TTL CLOCKOUT signal
> +- lvcc-supply: Power supply for LVDS inputs
> +- pvcc-supply: Power supply for PLL circuitry
> +- pdwn-gpios: Power down GPIO signal. Active low
> +- oe-gpios: Output enable GPIO signal. Active high
> +
> +The THC63LVD1024 video port connections are modeled according
> +to OF graph bindings specified by Documentation/devicetree/bindings/graph.txt
> +
> +Required video port nodes:
> +- Port@0: First LVDS input port
> +- Port@2: First digital CMOS/TTL parallel output
> +
> +Optional video port nodes:
> +- Port@1: Second LVDS input port
> +- Port@3: Second digital CMOS/TTL parallel output
> +
> +Example:
> +
> +
> + thc63lvd1024: lvds-decoder {
> + compatible = "thine,thc63lvd1024";
> +
> + vcc-supply = <_lvds_vcc>;
> + lvcc-supply = <_lvds_lvcc>;
> +
> + pdwn-gpio = < 15 GPIO_ACTIVE_LOW>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + lvds_dec_in_0: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> +
> + port@2{
> + reg = <2>;
> +
> + lvds_dec_out_2: endpoint {
> + remote-endpoint = <_in>;
> + };
> +
> + };
> +
> + };
> + };
> --
> 2.7.4
>
--
Regards,
Niklas Söderlund
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver
AY_SIZE(thc63->vccs) - 1; i >= 0; i--) {
> + vcc = thc63->vccs[i];
> + if (!vcc)
> + continue;
> +
> + if (regulator_disable(vcc))
> + dev_dbg(thc63->dev,
> + "Failed to disable regulator %s\n",
> + thc63_reg_names[i]);
> + }
> +}
> +
> +struct drm_bridge_funcs thc63_bridge_func = {
> + .attach = thc63_attach,
> + .enable = thc63_enable,
> + .disable = thc63_disable,
> +};
> +
> +static int thc63_parse_dt(struct thc63_dev *thc63)
> +{
> + struct device_node *thc63_out;
> + struct device_node *remote;
> + int ret = 0;
> +
> + thc63_out = of_graph_get_endpoint_by_regs(thc63->dev->of_node,
> + THC63_DIGITAL_OUT0, -1);
> + if (!thc63_out) {
> + dev_err(thc63->dev, "Missing endpoint in Port@%u\n",
> + THC63_DIGITAL_OUT0);
> + return -ENODEV;
> + }
> +
> + remote = of_graph_get_remote_port_parent(thc63_out);
> + if (!remote) {
> + dev_err(thc63->dev, "Endpoint in Port@%u unconnected\n",
> + THC63_DIGITAL_OUT0);
> + ret = -ENODEV;
> + goto error_put_out_node;
> + }
> +
> + if (!of_device_is_available(remote)) {
> + dev_err(thc63->dev, "Port@%u remote endpoint is disabled\n",
> + THC63_DIGITAL_OUT0);
> + ret = -ENODEV;
> + goto error_put_remote_node;
> + }
> +
> + thc63->next = of_drm_find_bridge(remote);
> + if (!thc63->next)
> + ret = -EPROBE_DEFER;
> +
> +error_put_remote_node:
> + of_node_put(remote);
> +error_put_out_node:
> + of_node_put(thc63_out);
> +
> + return ret;
> +}
> +
> +static int thc63_gpio_init(struct thc63_dev *thc63)
> +{
> + thc63->oe = devm_gpiod_get_optional(thc63->dev, "oe", GPIOD_OUT_LOW);
> + if (IS_ERR(thc63->oe)) {
> + dev_err(thc63->dev, "Unable to get \"oe-gpios\"\n");
> + return PTR_ERR(thc63->oe);
> + }
> +
> + thc63->pdwn = devm_gpiod_get_optional(thc63->dev, "pdwn",
> + GPIOD_OUT_HIGH);
> + if (IS_ERR(thc63->pdwn)) {
> + dev_err(thc63->dev, "Unable to get \"pdwn-gpios\"\n");
> + return PTR_ERR(thc63->pdwn);
> + }
> +
> + return 0;
> +}
> +
> +static int thc63_regulator_init(struct thc63_dev *thc63)
> +{
> + struct regulator **reg;
> + int i;
> +
> + reg = >vccs[0];
> + for (i = 0; i < ARRAY_SIZE(thc63->vccs); i++, reg++) {
> + *reg = devm_regulator_get_optional(thc63->dev,
> +thc63_reg_names[i]);
> + if (IS_ERR(*reg)) {
> + if (PTR_ERR(*reg) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> + *reg = NULL;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static int thc63_probe(struct platform_device *pdev)
> +{
> + struct thc63_dev *thc63;
> + int ret;
> +
> + thc63 = devm_kzalloc(>dev, sizeof(*thc63), GFP_KERNEL);
> + if (!thc63)
> + return -ENOMEM;
> +
> + thc63->dev = >dev;
> + platform_set_drvdata(pdev, thc63);
> +
> + ret = thc63_regulator_init(thc63);
> + if (ret)
> + return ret;
> +
> + ret = thc63_gpio_init(thc63);
> + if (ret)
> + return ret;
> +
> + ret = thc63_parse_dt(thc63);
> + if (ret)
> + return ret;
> +
> + thc63->bridge.driver_private = thc63;
> + thc63->bridge.of_node = pdev->dev.of_node;
> + thc63->bridge.funcs = _bridge_func;
> +
> + drm_bridge_add(>bridge);
> +
> + return 0;
> +}
> +
> +static int thc63_remove(struct platform_device *pdev)
> +{
> + struct thc63_dev *thc63 = platform_get_drvdata(pdev);
> +
> + drm_bridge_remove(>bridge);
> +
> + return 0;
> +}
> +
> +#ifdef CONFIG_OF
> +static const struct of_device_id thc63_match[] = {
> + { .compatible = "thine,thc63lvd1024", },
> + { },
> +};
> +MODULE_DEVICE_TABLE(of, thc63_match);
> +#endif
This driver depends on OF so you don't need the ifdef here. If you
choose to remove the dependency on OF and make it optional you need to
handle .of_match_table bellow in case OF is not defined :-)
With this fixed feel free to add my
Reviewed-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
> +
> +static struct platform_driver thc63_driver = {
> + .probe = thc63_probe,
> + .remove = thc63_remove,
> + .driver = {
> + .name = "thc63lvd1024",
> + .of_match_table = thc63_match,
> + },
> +};
> +module_platform_driver(thc63_driver);
> +
> +MODULE_AUTHOR("Jacopo Mondi <jac...@jmondi.org>");
> +MODULE_DESCRIPTION("Thine THC63LVD1024 LVDS decoder DRM bridge driver");
> +MODULE_LICENSE("GPL v2");
> --
> 2.7.4
>
--
Regards,
Niklas Söderlund
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 1/4] dt-bindings: display: renesas: Add R-Car LVDS encoder DT bindings
Hi Laurent,
Thanks for your patch.
On 2018-02-22 15:13:33 +0200, Laurent Pinchart wrote:
> The Renesas R-Car Gen2 and Gen3 SoCs have internal LVDS encoders. Add
> corresponding device tree bindings.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
> Reviewed-by: Rob Herring <r...@kernel.org>
> ---
> Changes since v1:
>
> - Move the SoC name before the IP name in compatible strings
> - Rename parallel input to parallel RGB input
> - Fixed "renesas,r8a7743-lvds" description
> - Document the resets property
> - Fixed typo
> ---
> .../bindings/display/bridge/renesas,lvds.txt | 56
> ++
> MAINTAINERS| 1 +
> 2 files changed, 57 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> new file mode 100644
> index ..2b19ce51ec07
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> @@ -0,0 +1,56 @@
> +Renesas R-Car LVDS Encoder
> +==
> +
> +These DT bindings describe the LVDS encoder embedded in the Renesas R-Car
> +Gen2, R-Car Gen3 and RZ/G SoCs.
> +
> +Required properties:
> +
> +- compatible : Shall contain one of
> + - "renesas,r8a7743-lvds" for R8A7743 (RZ/G1M) compatible LVDS encoders
> + - "renesas,r8a7790-lvds" for R8A7790 (R-Car H2) compatible LVDS encoders
> + - "renesas,r8a7791-lvds" for R8A7791 (R-Car M2-W) compatible LVDS encoders
> + - "renesas,r8a7793-lvds" for R8A7791 (R-Car M2-N) compatible LVDS encoders
Small typo here s/R8A7791/R8A7793/, with that fixed
Reviewed-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
> + - "renesas,r8a7795-lvds" for R8A7795 (R-Car H3) compatible LVDS encoders
> + - "renesas,r8a7796-lvds" for R8A7796 (R-Car M3-W) compatible LVDS encoders
> +
> +- reg: Base address and length for the memory-mapped registers
> +- clocks: A phandle + clock-specifier pair for the functional clock
> +- resets: A phandle + reset specifier for the module reset
> +
> +Required nodes:
> +
> +The LVDS encoder has two video ports. Their connections are modelled using
> the
> +OF graph bindings specified in Documentation/devicetree/bindings/graph.txt.
> +
> +- Video port 0 corresponds to the parallel RGB input
> +- Video port 1 corresponds to the LVDS output
> +
> +Each port shall have a single endpoint.
> +
> +
> +Example:
> +
> + lvds0: lvds@feb9 {
> + compatible = "renesas,r8a7790-lvds";
> + reg = <0 0xfeb9 0 0x1c>;
> + clocks = < CPG_MOD 726>;
> + resets = < 726>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + lvds0_in: endpoint {
> + remote-endpoint = <_out_lvds0>;
> + };
> + };
> + port@1 {
> + reg = <1>;
> + lvds0_out: endpoint {
> + };
> + };
> + };
> + };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 2afba909724c..13c8ec11135a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4744,6 +4744,7 @@ F: drivers/gpu/drm/rcar-du/
> F: drivers/gpu/drm/shmobile/
> F: include/linux/platform_data/shmob_drm.h
> F: Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
> +F: Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> F: Documentation/devicetree/bindings/display/renesas,du.txt
>
> DRM DRIVERS FOR ROCKCHIP
> --
> Regards,
>
> Laurent Pinchart
>
--
Regards,
Niklas Söderlund
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 4/4] drm: rcar-du: Convert LVDS encoder code to bridge driver
Hi Laurent,
Thanks for your patch.
On 2018-02-22 15:13:36 +0200, Laurent Pinchart wrote:
> The LVDS encoders used to be described in DT as part of the DU. They now
> have their own DT node, linked to the DU using the OF graph bindings.
> This allows moving internal LVDS encoder support to a separate driver
> modelled as a DRM bridge. Backward compatibility is retained as legacy
> DT is patched live to move to the new bindings.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
I'm not so strong when it comes to DRM, but I have done my best to grasp
this patch. Looking at datasheets and what the code looked before feel
free to add.
Reviewed-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
> ---
> Changes since v1:
>
> - Update the SPDX headers to use GPL-2.0 instead of GPL-2.0-only
> - Update to the -lvds compatible string format
> ---
> drivers/gpu/drm/rcar-du/Kconfig | 4 +-
> drivers/gpu/drm/rcar-du/Makefile | 3 +-
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 21 +-
> drivers/gpu/drm/rcar-du/rcar_du_drv.h | 5 -
> drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 175 +-
> drivers/gpu/drm/rcar-du/rcar_du_encoder.h | 12 -
> drivers/gpu/drm/rcar-du/rcar_du_kms.c | 14 +-
> drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c | 93 --
> drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h | 24 --
> drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 238 --
> drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h | 64
> drivers/gpu/drm/rcar-du/rcar_lvds.c | 524
> ++
> 12 files changed, 561 insertions(+), 616 deletions(-)
> delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c
> delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h
> delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
> delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h
> create mode 100644 drivers/gpu/drm/rcar-du/rcar_lvds.c
>
> diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
> index 3f83352a7313..edde8d4b87a3 100644
> --- a/drivers/gpu/drm/rcar-du/Kconfig
> +++ b/drivers/gpu/drm/rcar-du/Kconfig
> @@ -19,8 +19,8 @@ config DRM_RCAR_DW_HDMI
> Enable support for R-Car Gen3 internal HDMI encoder.
>
> config DRM_RCAR_LVDS
> - bool "R-Car DU LVDS Encoder Support"
> - depends on DRM_RCAR_DU
> + tristate "R-Car DU LVDS Encoder Support"
> + depends on DRM && DRM_BRIDGE && OF
> select DRM_PANEL
> select OF_FLATTREE
> select OF_OVERLAY
> diff --git a/drivers/gpu/drm/rcar-du/Makefile
> b/drivers/gpu/drm/rcar-du/Makefile
> index 86b337b4be5d..3e58ed93d5b1 100644
> --- a/drivers/gpu/drm/rcar-du/Makefile
> +++ b/drivers/gpu/drm/rcar-du/Makefile
> @@ -4,10 +4,8 @@ rcar-du-drm-y := rcar_du_crtc.o \
>rcar_du_encoder.o \
>rcar_du_group.o \
>rcar_du_kms.o \
> - rcar_du_lvdscon.o \
>rcar_du_plane.o
>
> -rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS) += rcar_du_lvdsenc.o
> rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS) += rcar_du_of.o \
> rcar_du_of_lvds_r8a7790.dtb.o \
> rcar_du_of_lvds_r8a7791.dtb.o \
> @@ -18,3 +16,4 @@ rcar-du-drm-$(CONFIG_DRM_RCAR_VSP) += rcar_du_vsp.o
>
> obj-$(CONFIG_DRM_RCAR_DU)+= rcar-du-drm.o
> obj-$(CONFIG_DRM_RCAR_DW_HDMI) += rcar_dw_hdmi.o
> +obj-$(CONFIG_DRM_RCAR_LVDS) += rcar_lvds.o
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> index 6e02c762a557..06a3fbdd728a 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -29,6 +29,7 @@
>
> #include "rcar_du_drv.h"
> #include "rcar_du_kms.h"
> +#include "rcar_du_of.h"
> #include "rcar_du_regs.h"
>
> /*
> -
> @@ -74,7 +75,6 @@ static const struct rcar_du_device_info
> rzg1_du_r8a7745_info = {
> .port = 1,
> },
> },
> - .num_lvds = 0,
> };
>
> static const struct rcar_du_device_info rcar_du_r8a7779_info = {
> @@ -95,14 +95,13 @@ static const struct rcar_du_device_info
> rcar_du_r8a7779_info = {
> .port = 1,
> },
> },
> - .num_lvds = 0,
> };
>
> static const struct rcar_du_device_info rcar_du_r8a7790_info = {
> .gen = 2,
> .features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
> | RCAR_DU_FEAT
Re: [PATCH v6 2/4] dt-bindings: display: renesas: Deprecate LVDS support in the DU bindings
Hi Laurent,
Thanks for your patch.
On 2018-02-22 15:13:34 +0200, Laurent Pinchart wrote:
> The internal LVDS encoders now have their own DT bindings, representing
> them as part of the DU is deprecated.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
> Reviewed-by: Rob Herring <r...@kernel.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
> ---
> Changes since v1:
>
> - Remove the LVDS reg range from the example
> - Remove the reg-names property
> ---
> .../devicetree/bindings/display/renesas,du.txt | 31
> --
> 1 file changed, 11 insertions(+), 20 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt
> b/Documentation/devicetree/bindings/display/renesas,du.txt
> index cd48aba3bc8c..e79cf9b0ad38 100644
> --- a/Documentation/devicetree/bindings/display/renesas,du.txt
> +++ b/Documentation/devicetree/bindings/display/renesas,du.txt
> @@ -14,12 +14,7 @@ Required Properties:
> - "renesas,du-r8a7795" for R8A7795 (R-Car H3) compatible DU
> - "renesas,du-r8a7796" for R8A7796 (R-Car M3-W) compatible DU
>
> - - reg: A list of base address and length of each memory resource, one for
> -each entry in the reg-names property.
> - - reg-names: Name of the memory resources. The DU requires one memory
> -resource for the DU core (named "du") and one memory resource for each
> -LVDS encoder (named "lvds.x" with "x" being the LVDS controller numerical
> -index).
> + - reg: the memory-mapped I/O registers base address and length
>
>- interrupt-parent: phandle of the parent interrupt controller.
>- interrupts: Interrupt specifiers for the DU interrupts.
> @@ -29,14 +24,13 @@ Required Properties:
>- clock-names: Name of the clocks. This property is model-dependent.
> - R8A7779 uses a single functional clock. The clock doesn't need to be
>named.
> -- All other DU instances use one functional clock per channel and one
> - clock per LVDS encoder (if available). The functional clocks must be
> - named "du.x" with "x" being the channel numerical index. The LVDS
> clocks
> - must be named "lvds.x" with "x" being the LVDS encoder numerical index.
> -- In addition to the functional and encoder clocks, all DU versions also
> - support externally supplied pixel clocks. Those clocks are optional.
> - When supplied they must be named "dclkin.x" with "x" being the input
> - clock numerical index.
> +- All other DU instances use one functional clock per channel The
> + functional clocks must be named "du.x" with "x" being the channel
> + numerical index.
> +- In addition to the functional clocks, all DU versions also support
> + externally supplied pixel clocks. Those clocks are optional. When
> + supplied they must be named "dclkin.x" with "x" being the input clock
> + numerical index.
>
>- vsps: A list of phandle and channel index tuples to the VSPs that handle
> the memory interfaces for the DU channels. The phandle identifies the VSP
> @@ -69,9 +63,7 @@ Example: R8A7795 (R-Car H3) ES2.0 DU
>
> du: display@feb0 {
> compatible = "renesas,du-r8a7795";
> - reg = <0 0xfeb0 0 0x8>,
> - <0 0xfeb9 0 0x14>;
> - reg-names = "du", "lvds.0";
> + reg = <0 0xfeb0 0 0x8>;
> interrupts = ,
>,
>,
> @@ -79,9 +71,8 @@ Example: R8A7795 (R-Car H3) ES2.0 DU
> clocks = < CPG_MOD 724>,
>< CPG_MOD 723>,
>< CPG_MOD 722>,
> - < CPG_MOD 721>,
> - < CPG_MOD 727>;
> - clock-names = "du.0", "du.1", "du.2", "du.3", "lvds.0";
> + < CPG_MOD 721>;
> + clock-names = "du.0", "du.1", "du.2", "du.3";
> vsps = < 0>, < 0>, < 0>, < 1>;
>
> ports {
> --
> Regards,
>
> Laurent Pinchart
>
--
Regards,
Niklas Söderlund
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
