* [PATCH v2 0/6] Convert adi,adv7511.txt DT bindings to yaml
@ 2020-05-11 11:06 ` Ricardo Cañuelo
0 siblings, 0 replies; 66+ messages in thread
From: Ricardo Cañuelo @ 2020-05-11 11:06 UTC (permalink / raw)
To: laurent.pinchart
Cc: devicetree, geert+renesas, xuwei5, robh+dt, kernel, linux-arm-kernel
Hi,
This series convert the adi,adv7511.txt DT bindings to json-schema. As a
result of the conversion some dts files needed to be updated.
The changes to the dts files are of three types:
- Reordering of the I2C slave addresses list of the ADV75xx node. The
addresses in the 'reg' property and the matching names in
'reg-names' for an I2C slave don't need to be in any particular
order, but the DT schema defines these properties as a cell array
and a string array respectively, which are ordered, so the
definitions in the dts files must match the order in the binding.
- Filling the minimum binding requirements. Most of the time this
means creating a 'ports' node in the boards that don't define
them. Note, however, that the purpose of this is simply to make the
definition compliant with the binding. I didn't define any endpoints
for the ports.
- Removing unneeded properties.
About the binding conversion:
- The original binding covered five different devices: ADV7511,
ADV7511W, ADV7513, ADV7533 and ADV7535. They all share a common set
of properties but ADV7533 and ADV7535 have enough differences from
the rest to warrant their own binding file. In v1 I modelled all the
properties constraints for all five devices in a single file but it
turned out a bit too complex. Splitting the binding into one for
ADV7511/11W/13 and another for ADV7533/35 makes them much easier to
read and maintain.
Patches 1/6 to 5/6 contain the dts changes. Patch 6/6 contains the
binding conversion.
NOTE: the bindings have been tested with:
make dt_binding_check ARCH=<arch> DT_SCHEMA_FILES=<...adi,adv7511.yaml>
make dtbs_check ARCH=<arch> DT_SCHEMA_FILES=<...adi,adv7511.yaml>
for <arch> = arm and arm64. dts changes haven't been tested in hardware.
Changes in v2:
- [Rob] adi,adv7511.yaml split into two files: adi,adv7511.yaml and
adi,adv7533.yaml.
- [Rob] Remove maxItems from supplies.
- Additional DTs fixes:
- iwg20d-q7-dbcm-ca.dtsi
- r8a7745-iwg22d-sodimm-dbhd-ca.dts
- r8a7790-lager.dts
- r8a7790-stout.dts
- r8a7791-koelsch.dts
- r8a7791-porter.dts
- r8a7792-blanche.dts
- r8a7793-gose.dts
- r8a7794-silk.dts
- hi6220-hikey.dts
- r8a77970-eagle.dts
- r8a77970-v3msk.dts
- r8a77980-condor.dts
- r8a77980-v3hsk.dts
- r8a77990-ebisu.dts
Kind regards,
Ricardo
Ricardo Cañuelo (6):
arm64: dts: renesas: make hdmi encoder nodes compliant with DT
bindings
ARM: dts: renesas: make hdmi encoder nodes compliant with DT bindings
ARM: dts: zynq: add port definitions to hdmi-tx@39
arm64: dts: hisilicon: hikey: fixes to comply with adi,adv7533 DT
binding
ARM: dts: iwg20d-q7-dbcm-ca: remove unneeded properties in hdmi@39
dt-bindings: drm: bridge: adi,adv7511.txt: convert to yaml
.../bindings/display/bridge/adi,adv7511.txt | 143 -----------
.../bindings/display/bridge/adi,adv7511.yaml | 230 ++++++++++++++++++
.../bindings/display/bridge/adi,adv7533.yaml | 166 +++++++++++++
arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi | 2 -
.../dts/r8a7745-iwg22d-sodimm-dbhd-ca.dts | 2 -
arch/arm/boot/dts/r8a7790-lager.dts | 2 -
arch/arm/boot/dts/r8a7790-stout.dts | 2 -
arch/arm/boot/dts/r8a7791-koelsch.dts | 2 -
arch/arm/boot/dts/r8a7791-porter.dts | 2 -
arch/arm/boot/dts/r8a7792-blanche.dts | 2 -
arch/arm/boot/dts/r8a7792-wheat.dts | 12 +-
arch/arm/boot/dts/r8a7793-gose.dts | 2 -
arch/arm/boot/dts/r8a7794-silk.dts | 2 -
arch/arm/boot/dts/zynq-zc702.dts | 10 +
arch/arm/boot/dts/zynq-zc706.dts | 10 +
.../boot/dts/hisilicon/hi3660-hikey960.dts | 11 +
.../arm64/boot/dts/hisilicon/hi6220-hikey.dts | 2 +-
.../arm64/boot/dts/renesas/r8a77970-eagle.dts | 2 -
.../arm64/boot/dts/renesas/r8a77970-v3msk.dts | 2 -
.../boot/dts/renesas/r8a77980-condor.dts | 2 -
.../arm64/boot/dts/renesas/r8a77980-v3hsk.dts | 2 -
.../arm64/boot/dts/renesas/r8a77990-ebisu.dts | 2 -
.../arm64/boot/dts/renesas/r8a77995-draak.dts | 6 +-
23 files changed, 434 insertions(+), 184 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
create mode 100644 Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml
create mode 100644 Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH v2 1/6] arm64: dts: renesas: make hdmi encoder nodes compliant with DT bindings
2020-05-11 11:06 ` Ricardo Cañuelo
@ 2020-05-11 11:06 ` Ricardo Cañuelo
-1 siblings, 0 replies; 66+ messages in thread
From: Ricardo Cañuelo @ 2020-05-11 11:06 UTC (permalink / raw)
To: laurent.pinchart
Cc: kernel, devicetree, linux-arm-kernel, geert+renesas, robh+dt, xuwei5
Small fixes to make these DTs compliant with the adi,adv7511w binding.
r8a77970-eagle.dts,
r8a77970-v3msk.dts,
r8a77980-condor.dts,
r8a77980-v3hsk.dts,
r8a77990-ebisu.dts:
remove the adi,input-style and adi,input-justification properties.
r8a77995-draak.dts:
Reorder the I2C slave addresses of the hdmi-encoder@39 node and remove
the adi,input-style and adi,input-justification properties.
Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
---
arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 2 --
arch/arm64/boot/dts/renesas/r8a77970-v3msk.dts | 2 --
arch/arm64/boot/dts/renesas/r8a77980-condor.dts | 2 --
arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts | 2 --
arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts | 2 --
arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 6 ++----
6 files changed, 2 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
index 2afb91ec9c8d..ac2156ab3e62 100644
--- a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
@@ -137,8 +137,6 @@
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
adi,input-clock = "1x";
- adi,input-style = <1>;
- adi,input-justification = "evenly";
ports {
#address-cells = <1>;
diff --git a/arch/arm64/boot/dts/renesas/r8a77970-v3msk.dts b/arch/arm64/boot/dts/renesas/r8a77970-v3msk.dts
index d7c7b9156e08..01c4ba0f7be1 100644
--- a/arch/arm64/boot/dts/renesas/r8a77970-v3msk.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77970-v3msk.dts
@@ -150,8 +150,6 @@
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
adi,input-clock = "1x";
- adi,input-style = <1>;
- adi,input-justification = "evenly";
ports {
#address-cells = <1>;
diff --git a/arch/arm64/boot/dts/renesas/r8a77980-condor.dts b/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
index 3dde028e22a6..ef8350a062af 100644
--- a/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
@@ -174,8 +174,6 @@
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
adi,input-clock = "1x";
- adi,input-style = <1>;
- adi,input-justification = "evenly";
ports {
#address-cells = <1>;
diff --git a/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts b/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts
index adbfd8f07d06..6dff04693223 100644
--- a/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts
@@ -141,8 +141,6 @@
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
adi,input-clock = "1x";
- adi,input-style = <1>;
- adi,input-justification = "evenly";
ports {
#address-cells = <1>;
diff --git a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
index 4fd2b14fbb8b..dc24cec46ae1 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
@@ -360,8 +360,6 @@
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
adi,input-clock = "1x";
- adi,input-style = <1>;
- adi,input-justification = "evenly";
ports {
#address-cells = <1>;
diff --git a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
index 67634cb01d6b..79c73a99d2fe 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
@@ -272,8 +272,8 @@
hdmi-encoder@39 {
compatible = "adi,adv7511w";
- reg = <0x39>, <0x3f>, <0x38>, <0x3c>;
- reg-names = "main", "edid", "packet", "cec";
+ reg = <0x39>, <0x3f>, <0x3c>, <0x38>;
+ reg-names = "main", "edid", "cec", "packet";
interrupt-parent = <&gpio1>;
interrupts = <28 IRQ_TYPE_LEVEL_LOW>;
@@ -284,8 +284,6 @@
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
adi,input-clock = "1x";
- adi,input-style = <1>;
- adi,input-justification = "evenly";
ports {
#address-cells = <1>;
--
2.18.0
^ permalink raw reply related [flat|nested] 66+ messages in thread* [PATCH v2 1/6] arm64: dts: renesas: make hdmi encoder nodes compliant with DT bindings
@ 2020-05-11 11:06 ` Ricardo Cañuelo
0 siblings, 0 replies; 66+ messages in thread
From: Ricardo Cañuelo @ 2020-05-11 11:06 UTC (permalink / raw)
To: laurent.pinchart
Cc: devicetree, geert+renesas, xuwei5, robh+dt, kernel, linux-arm-kernel
Small fixes to make these DTs compliant with the adi,adv7511w binding.
r8a77970-eagle.dts,
r8a77970-v3msk.dts,
r8a77980-condor.dts,
r8a77980-v3hsk.dts,
r8a77990-ebisu.dts:
remove the adi,input-style and adi,input-justification properties.
r8a77995-draak.dts:
Reorder the I2C slave addresses of the hdmi-encoder@39 node and remove
the adi,input-style and adi,input-justification properties.
Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
---
arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 2 --
arch/arm64/boot/dts/renesas/r8a77970-v3msk.dts | 2 --
arch/arm64/boot/dts/renesas/r8a77980-condor.dts | 2 --
arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts | 2 --
arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts | 2 --
arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 6 ++----
6 files changed, 2 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
index 2afb91ec9c8d..ac2156ab3e62 100644
--- a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
@@ -137,8 +137,6 @@
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
adi,input-clock = "1x";
- adi,input-style = <1>;
- adi,input-justification = "evenly";
ports {
#address-cells = <1>;
diff --git a/arch/arm64/boot/dts/renesas/r8a77970-v3msk.dts b/arch/arm64/boot/dts/renesas/r8a77970-v3msk.dts
index d7c7b9156e08..01c4ba0f7be1 100644
--- a/arch/arm64/boot/dts/renesas/r8a77970-v3msk.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77970-v3msk.dts
@@ -150,8 +150,6 @@
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
adi,input-clock = "1x";
- adi,input-style = <1>;
- adi,input-justification = "evenly";
ports {
#address-cells = <1>;
diff --git a/arch/arm64/boot/dts/renesas/r8a77980-condor.dts b/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
index 3dde028e22a6..ef8350a062af 100644
--- a/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
@@ -174,8 +174,6 @@
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
adi,input-clock = "1x";
- adi,input-style = <1>;
- adi,input-justification = "evenly";
ports {
#address-cells = <1>;
diff --git a/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts b/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts
index adbfd8f07d06..6dff04693223 100644
--- a/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts
@@ -141,8 +141,6 @@
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
adi,input-clock = "1x";
- adi,input-style = <1>;
- adi,input-justification = "evenly";
ports {
#address-cells = <1>;
diff --git a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
index 4fd2b14fbb8b..dc24cec46ae1 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
@@ -360,8 +360,6 @@
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
adi,input-clock = "1x";
- adi,input-style = <1>;
- adi,input-justification = "evenly";
ports {
#address-cells = <1>;
diff --git a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
index 67634cb01d6b..79c73a99d2fe 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
@@ -272,8 +272,8 @@
hdmi-encoder@39 {
compatible = "adi,adv7511w";
- reg = <0x39>, <0x3f>, <0x38>, <0x3c>;
- reg-names = "main", "edid", "packet", "cec";
+ reg = <0x39>, <0x3f>, <0x3c>, <0x38>;
+ reg-names = "main", "edid", "cec", "packet";
interrupt-parent = <&gpio1>;
interrupts = <28 IRQ_TYPE_LEVEL_LOW>;
@@ -284,8 +284,6 @@
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
adi,input-clock = "1x";
- adi,input-style = <1>;
- adi,input-justification = "evenly";
ports {
#address-cells = <1>;
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 66+ messages in thread* Re: [PATCH v2 1/6] arm64: dts: renesas: make hdmi encoder nodes compliant with DT bindings
2020-05-11 11:06 ` Ricardo Cañuelo
@ 2020-05-11 11:51 ` Geert Uytterhoeven
-1 siblings, 0 replies; 66+ messages in thread
From: Geert Uytterhoeven @ 2020-05-11 11:51 UTC (permalink / raw)
To: Ricardo Cañuelo
Cc: Laurent Pinchart, Collabora Kernel ML,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, Geert Uytterhoeven, Rob Herring, Wei Xu
On Mon, May 11, 2020 at 1:06 PM Ricardo Cañuelo
<ricardo.canuelo@collabora.com> wrote:
> Small fixes to make these DTs compliant with the adi,adv7511w binding.
>
> r8a77970-eagle.dts,
> r8a77970-v3msk.dts,
> r8a77980-condor.dts,
> r8a77980-v3hsk.dts,
> r8a77990-ebisu.dts:
> remove the adi,input-style and adi,input-justification properties.
>
> r8a77995-draak.dts:
> Reorder the I2C slave addresses of the hdmi-encoder@39 node and remove
> the adi,input-style and adi,input-justification properties.
>
> Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 66+ messages in thread* Re: [PATCH v2 1/6] arm64: dts: renesas: make hdmi encoder nodes compliant with DT bindings
@ 2020-05-11 11:51 ` Geert Uytterhoeven
0 siblings, 0 replies; 66+ messages in thread
From: Geert Uytterhoeven @ 2020-05-11 11:51 UTC (permalink / raw)
To: Ricardo Cañuelo
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Geert Uytterhoeven, Wei Xu, Rob Herring, Laurent Pinchart,
Collabora Kernel ML, Linux ARM
On Mon, May 11, 2020 at 1:06 PM Ricardo Cañuelo
<ricardo.canuelo@collabora.com> wrote:
> Small fixes to make these DTs compliant with the adi,adv7511w binding.
>
> r8a77970-eagle.dts,
> r8a77970-v3msk.dts,
> r8a77980-condor.dts,
> r8a77980-v3hsk.dts,
> r8a77990-ebisu.dts:
> remove the adi,input-style and adi,input-justification properties.
>
> r8a77995-draak.dts:
> Reorder the I2C slave addresses of the hdmi-encoder@39 node and remove
> the adi,input-style and adi,input-justification properties.
>
> Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCH v2 1/6] arm64: dts: renesas: make hdmi encoder nodes compliant with DT bindings
2020-05-11 11:06 ` Ricardo Cañuelo
@ 2020-05-14 1:33 ` Laurent Pinchart
-1 siblings, 0 replies; 66+ messages in thread
From: Laurent Pinchart @ 2020-05-14 1:33 UTC (permalink / raw)
To: Ricardo Cañuelo
Cc: kernel, devicetree, linux-arm-kernel, geert+renesas, robh+dt, xuwei5
Hi Ricardo,
Thank you for the patch.
On Mon, May 11, 2020 at 01:06:06PM +0200, Ricardo Cañuelo wrote:
> Small fixes to make these DTs compliant with the adi,adv7511w binding.
>
> r8a77970-eagle.dts,
> r8a77970-v3msk.dts,
> r8a77980-condor.dts,
> r8a77980-v3hsk.dts,
> r8a77990-ebisu.dts:
> remove the adi,input-style and adi,input-justification properties.
>
> r8a77995-draak.dts:
> Reorder the I2C slave addresses of the hdmi-encoder@39 node and remove
> the adi,input-style and adi,input-justification properties.
>
> Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 2 --
> arch/arm64/boot/dts/renesas/r8a77970-v3msk.dts | 2 --
> arch/arm64/boot/dts/renesas/r8a77980-condor.dts | 2 --
> arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts | 2 --
> arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts | 2 --
> arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 6 ++----
> 6 files changed, 2 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
> index 2afb91ec9c8d..ac2156ab3e62 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
> @@ -137,8 +137,6 @@
> adi,input-depth = <8>;
> adi,input-colorspace = "rgb";
> adi,input-clock = "1x";
> - adi,input-style = <1>;
> - adi,input-justification = "evenly";
>
> ports {
> #address-cells = <1>;
> diff --git a/arch/arm64/boot/dts/renesas/r8a77970-v3msk.dts b/arch/arm64/boot/dts/renesas/r8a77970-v3msk.dts
> index d7c7b9156e08..01c4ba0f7be1 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77970-v3msk.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a77970-v3msk.dts
> @@ -150,8 +150,6 @@
> adi,input-depth = <8>;
> adi,input-colorspace = "rgb";
> adi,input-clock = "1x";
> - adi,input-style = <1>;
> - adi,input-justification = "evenly";
>
> ports {
> #address-cells = <1>;
> diff --git a/arch/arm64/boot/dts/renesas/r8a77980-condor.dts b/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
> index 3dde028e22a6..ef8350a062af 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
> @@ -174,8 +174,6 @@
> adi,input-depth = <8>;
> adi,input-colorspace = "rgb";
> adi,input-clock = "1x";
> - adi,input-style = <1>;
> - adi,input-justification = "evenly";
>
> ports {
> #address-cells = <1>;
> diff --git a/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts b/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts
> index adbfd8f07d06..6dff04693223 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts
> @@ -141,8 +141,6 @@
> adi,input-depth = <8>;
> adi,input-colorspace = "rgb";
> adi,input-clock = "1x";
> - adi,input-style = <1>;
> - adi,input-justification = "evenly";
>
> ports {
> #address-cells = <1>;
> diff --git a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
> index 4fd2b14fbb8b..dc24cec46ae1 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
> @@ -360,8 +360,6 @@
> adi,input-depth = <8>;
> adi,input-colorspace = "rgb";
> adi,input-clock = "1x";
> - adi,input-style = <1>;
> - adi,input-justification = "evenly";
>
> ports {
> #address-cells = <1>;
> diff --git a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> index 67634cb01d6b..79c73a99d2fe 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> @@ -272,8 +272,8 @@
>
> hdmi-encoder@39 {
> compatible = "adi,adv7511w";
> - reg = <0x39>, <0x3f>, <0x38>, <0x3c>;
> - reg-names = "main", "edid", "packet", "cec";
> + reg = <0x39>, <0x3f>, <0x3c>, <0x38>;
> + reg-names = "main", "edid", "cec", "packet";
> interrupt-parent = <&gpio1>;
> interrupts = <28 IRQ_TYPE_LEVEL_LOW>;
>
> @@ -284,8 +284,6 @@
> adi,input-depth = <8>;
> adi,input-colorspace = "rgb";
> adi,input-clock = "1x";
> - adi,input-style = <1>;
> - adi,input-justification = "evenly";
>
> ports {
> #address-cells = <1>;
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 66+ messages in thread* Re: [PATCH v2 1/6] arm64: dts: renesas: make hdmi encoder nodes compliant with DT bindings
@ 2020-05-14 1:33 ` Laurent Pinchart
0 siblings, 0 replies; 66+ messages in thread
From: Laurent Pinchart @ 2020-05-14 1:33 UTC (permalink / raw)
To: Ricardo Cañuelo
Cc: devicetree, geert+renesas, xuwei5, robh+dt, kernel, linux-arm-kernel
Hi Ricardo,
Thank you for the patch.
On Mon, May 11, 2020 at 01:06:06PM +0200, Ricardo Cañuelo wrote:
> Small fixes to make these DTs compliant with the adi,adv7511w binding.
>
> r8a77970-eagle.dts,
> r8a77970-v3msk.dts,
> r8a77980-condor.dts,
> r8a77980-v3hsk.dts,
> r8a77990-ebisu.dts:
> remove the adi,input-style and adi,input-justification properties.
>
> r8a77995-draak.dts:
> Reorder the I2C slave addresses of the hdmi-encoder@39 node and remove
> the adi,input-style and adi,input-justification properties.
>
> Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 2 --
> arch/arm64/boot/dts/renesas/r8a77970-v3msk.dts | 2 --
> arch/arm64/boot/dts/renesas/r8a77980-condor.dts | 2 --
> arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts | 2 --
> arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts | 2 --
> arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 6 ++----
> 6 files changed, 2 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
> index 2afb91ec9c8d..ac2156ab3e62 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
> @@ -137,8 +137,6 @@
> adi,input-depth = <8>;
> adi,input-colorspace = "rgb";
> adi,input-clock = "1x";
> - adi,input-style = <1>;
> - adi,input-justification = "evenly";
>
> ports {
> #address-cells = <1>;
> diff --git a/arch/arm64/boot/dts/renesas/r8a77970-v3msk.dts b/arch/arm64/boot/dts/renesas/r8a77970-v3msk.dts
> index d7c7b9156e08..01c4ba0f7be1 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77970-v3msk.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a77970-v3msk.dts
> @@ -150,8 +150,6 @@
> adi,input-depth = <8>;
> adi,input-colorspace = "rgb";
> adi,input-clock = "1x";
> - adi,input-style = <1>;
> - adi,input-justification = "evenly";
>
> ports {
> #address-cells = <1>;
> diff --git a/arch/arm64/boot/dts/renesas/r8a77980-condor.dts b/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
> index 3dde028e22a6..ef8350a062af 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
> @@ -174,8 +174,6 @@
> adi,input-depth = <8>;
> adi,input-colorspace = "rgb";
> adi,input-clock = "1x";
> - adi,input-style = <1>;
> - adi,input-justification = "evenly";
>
> ports {
> #address-cells = <1>;
> diff --git a/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts b/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts
> index adbfd8f07d06..6dff04693223 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts
> @@ -141,8 +141,6 @@
> adi,input-depth = <8>;
> adi,input-colorspace = "rgb";
> adi,input-clock = "1x";
> - adi,input-style = <1>;
> - adi,input-justification = "evenly";
>
> ports {
> #address-cells = <1>;
> diff --git a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
> index 4fd2b14fbb8b..dc24cec46ae1 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
> @@ -360,8 +360,6 @@
> adi,input-depth = <8>;
> adi,input-colorspace = "rgb";
> adi,input-clock = "1x";
> - adi,input-style = <1>;
> - adi,input-justification = "evenly";
>
> ports {
> #address-cells = <1>;
> diff --git a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> index 67634cb01d6b..79c73a99d2fe 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> @@ -272,8 +272,8 @@
>
> hdmi-encoder@39 {
> compatible = "adi,adv7511w";
> - reg = <0x39>, <0x3f>, <0x38>, <0x3c>;
> - reg-names = "main", "edid", "packet", "cec";
> + reg = <0x39>, <0x3f>, <0x3c>, <0x38>;
> + reg-names = "main", "edid", "cec", "packet";
> interrupt-parent = <&gpio1>;
> interrupts = <28 IRQ_TYPE_LEVEL_LOW>;
>
> @@ -284,8 +284,6 @@
> adi,input-depth = <8>;
> adi,input-colorspace = "rgb";
> adi,input-clock = "1x";
> - adi,input-style = <1>;
> - adi,input-justification = "evenly";
>
> ports {
> #address-cells = <1>;
--
Regards,
Laurent Pinchart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCH v2 2/6] ARM: dts: renesas: make hdmi encoder nodes compliant with DT bindings
2020-05-11 11:06 ` Ricardo Cañuelo
@ 2020-05-11 11:06 ` Ricardo Cañuelo
-1 siblings, 0 replies; 66+ messages in thread
From: Ricardo Cañuelo @ 2020-05-11 11:06 UTC (permalink / raw)
To: laurent.pinchart
Cc: kernel, devicetree, linux-arm-kernel, geert+renesas, robh+dt, xuwei5
Small fixes to make these DTs compliant with the adi,adv7511w and
adiadv7513 bindings:
r8a7745-iwg22d-sodimm-dbhd-ca.dts
r8a7790-lager.dts
r8a7790-stout.dts
r8a7791-koelsch.dts
r8a7791-porter.dts
r8a7792-blanche.dts
r8a7793-gose.dts
r8a7794-silk.dts:
Remove the adi,input-style and adi,input-justification properties
r8a7792-wheat.dts:
Reorder the I2C slave addresses of hdmi@3d and hdmi@39 and remove the
adi,input-style and adi,input-justification properties.
Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
---
arch/arm/boot/dts/r8a7745-iwg22d-sodimm-dbhd-ca.dts | 2 --
arch/arm/boot/dts/r8a7790-lager.dts | 2 --
arch/arm/boot/dts/r8a7790-stout.dts | 2 --
arch/arm/boot/dts/r8a7791-koelsch.dts | 2 --
arch/arm/boot/dts/r8a7791-porter.dts | 2 --
arch/arm/boot/dts/r8a7792-blanche.dts | 2 --
arch/arm/boot/dts/r8a7792-wheat.dts | 12 ++++--------
arch/arm/boot/dts/r8a7793-gose.dts | 2 --
arch/arm/boot/dts/r8a7794-silk.dts | 2 --
9 files changed, 4 insertions(+), 24 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7745-iwg22d-sodimm-dbhd-ca.dts b/arch/arm/boot/dts/r8a7745-iwg22d-sodimm-dbhd-ca.dts
index 92aa26ba423c..b1f679da36b2 100644
--- a/arch/arm/boot/dts/r8a7745-iwg22d-sodimm-dbhd-ca.dts
+++ b/arch/arm/boot/dts/r8a7745-iwg22d-sodimm-dbhd-ca.dts
@@ -84,8 +84,6 @@
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
adi,input-clock = "1x";
- adi,input-style = <1>;
- adi,input-justification = "evenly";
ports {
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/r8a7790-lager.dts b/arch/arm/boot/dts/r8a7790-lager.dts
index 69745def44d4..bfe778c4c47b 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -364,8 +364,6 @@
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
adi,input-clock = "1x";
- adi,input-style = <1>;
- adi,input-justification = "evenly";
ports {
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/r8a7790-stout.dts b/arch/arm/boot/dts/r8a7790-stout.dts
index 4138efb2766d..6a457bc9280a 100644
--- a/arch/arm/boot/dts/r8a7790-stout.dts
+++ b/arch/arm/boot/dts/r8a7790-stout.dts
@@ -297,8 +297,6 @@
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
adi,input-clock = "1x";
- adi,input-style = <1>;
- adi,input-justification = "evenly";
ports {
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts b/arch/arm/boot/dts/r8a7791-koelsch.dts
index 687167b70cb6..fc74c6cd6def 100644
--- a/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -387,8 +387,6 @@
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
adi,input-clock = "1x";
- adi,input-style = <1>;
- adi,input-justification = "evenly";
ports {
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/r8a7791-porter.dts b/arch/arm/boot/dts/r8a7791-porter.dts
index a8e0335148a5..114bf1c4199b 100644
--- a/arch/arm/boot/dts/r8a7791-porter.dts
+++ b/arch/arm/boot/dts/r8a7791-porter.dts
@@ -181,8 +181,6 @@
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
adi,input-clock = "1x";
- adi,input-style = <1>;
- adi,input-justification = "evenly";
ports {
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/r8a7792-blanche.dts b/arch/arm/boot/dts/r8a7792-blanche.dts
index 248eb717eb35..9368ac2cf508 100644
--- a/arch/arm/boot/dts/r8a7792-blanche.dts
+++ b/arch/arm/boot/dts/r8a7792-blanche.dts
@@ -289,8 +289,6 @@
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
adi,input-clock = "1x";
- adi,input-style = <1>;
- adi,input-justification = "evenly";
ports {
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/r8a7792-wheat.dts b/arch/arm/boot/dts/r8a7792-wheat.dts
index bd2a63bdab3d..ba2d2a589012 100644
--- a/arch/arm/boot/dts/r8a7792-wheat.dts
+++ b/arch/arm/boot/dts/r8a7792-wheat.dts
@@ -249,14 +249,12 @@
*/
hdmi@3d {
compatible = "adi,adv7513";
- reg = <0x3d>, <0x2d>, <0x4d>, <0x5d>;
- reg-names = "main", "cec", "edid", "packet";
+ reg = <0x3d>, <0x4d>, <0x2d>, <0x5d>;
+ reg-names = "main", "edid", "cec", "packet";
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
adi,input-clock = "1x";
- adi,input-style = <1>;
- adi,input-justification = "evenly";
ports {
#address-cells = <1>;
@@ -280,14 +278,12 @@
hdmi@39 {
compatible = "adi,adv7513";
- reg = <0x39>, <0x29>, <0x49>, <0x59>;
- reg-names = "main", "cec", "edid", "packet";
+ reg = <0x39>, <0x49>, <0x29>, <0x59>;
+ reg-names = "main", "edid", "cec", "packet";
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
adi,input-clock = "1x";
- adi,input-style = <1>;
- adi,input-justification = "evenly";
ports {
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/r8a7793-gose.dts b/arch/arm/boot/dts/r8a7793-gose.dts
index cfe06a74ce89..79baf06019f5 100644
--- a/arch/arm/boot/dts/r8a7793-gose.dts
+++ b/arch/arm/boot/dts/r8a7793-gose.dts
@@ -366,8 +366,6 @@
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
adi,input-clock = "1x";
- adi,input-style = <1>;
- adi,input-justification = "evenly";
ports {
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/r8a7794-silk.dts b/arch/arm/boot/dts/r8a7794-silk.dts
index 9aaa96ea9943..b8b0941f677c 100644
--- a/arch/arm/boot/dts/r8a7794-silk.dts
+++ b/arch/arm/boot/dts/r8a7794-silk.dts
@@ -255,8 +255,6 @@
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
adi,input-clock = "1x";
- adi,input-style = <1>;
- adi,input-justification = "evenly";
ports {
#address-cells = <1>;
--
2.18.0
^ permalink raw reply related [flat|nested] 66+ messages in thread* [PATCH v2 2/6] ARM: dts: renesas: make hdmi encoder nodes compliant with DT bindings
@ 2020-05-11 11:06 ` Ricardo Cañuelo
0 siblings, 0 replies; 66+ messages in thread
From: Ricardo Cañuelo @ 2020-05-11 11:06 UTC (permalink / raw)
To: laurent.pinchart
Cc: devicetree, geert+renesas, xuwei5, robh+dt, kernel, linux-arm-kernel
Small fixes to make these DTs compliant with the adi,adv7511w and
adiadv7513 bindings:
r8a7745-iwg22d-sodimm-dbhd-ca.dts
r8a7790-lager.dts
r8a7790-stout.dts
r8a7791-koelsch.dts
r8a7791-porter.dts
r8a7792-blanche.dts
r8a7793-gose.dts
r8a7794-silk.dts:
Remove the adi,input-style and adi,input-justification properties
r8a7792-wheat.dts:
Reorder the I2C slave addresses of hdmi@3d and hdmi@39 and remove the
adi,input-style and adi,input-justification properties.
Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
---
arch/arm/boot/dts/r8a7745-iwg22d-sodimm-dbhd-ca.dts | 2 --
arch/arm/boot/dts/r8a7790-lager.dts | 2 --
arch/arm/boot/dts/r8a7790-stout.dts | 2 --
arch/arm/boot/dts/r8a7791-koelsch.dts | 2 --
arch/arm/boot/dts/r8a7791-porter.dts | 2 --
arch/arm/boot/dts/r8a7792-blanche.dts | 2 --
arch/arm/boot/dts/r8a7792-wheat.dts | 12 ++++--------
arch/arm/boot/dts/r8a7793-gose.dts | 2 --
arch/arm/boot/dts/r8a7794-silk.dts | 2 --
9 files changed, 4 insertions(+), 24 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7745-iwg22d-sodimm-dbhd-ca.dts b/arch/arm/boot/dts/r8a7745-iwg22d-sodimm-dbhd-ca.dts
index 92aa26ba423c..b1f679da36b2 100644
--- a/arch/arm/boot/dts/r8a7745-iwg22d-sodimm-dbhd-ca.dts
+++ b/arch/arm/boot/dts/r8a7745-iwg22d-sodimm-dbhd-ca.dts
@@ -84,8 +84,6 @@
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
adi,input-clock = "1x";
- adi,input-style = <1>;
- adi,input-justification = "evenly";
ports {
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/r8a7790-lager.dts b/arch/arm/boot/dts/r8a7790-lager.dts
index 69745def44d4..bfe778c4c47b 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -364,8 +364,6 @@
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
adi,input-clock = "1x";
- adi,input-style = <1>;
- adi,input-justification = "evenly";
ports {
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/r8a7790-stout.dts b/arch/arm/boot/dts/r8a7790-stout.dts
index 4138efb2766d..6a457bc9280a 100644
--- a/arch/arm/boot/dts/r8a7790-stout.dts
+++ b/arch/arm/boot/dts/r8a7790-stout.dts
@@ -297,8 +297,6 @@
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
adi,input-clock = "1x";
- adi,input-style = <1>;
- adi,input-justification = "evenly";
ports {
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts b/arch/arm/boot/dts/r8a7791-koelsch.dts
index 687167b70cb6..fc74c6cd6def 100644
--- a/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -387,8 +387,6 @@
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
adi,input-clock = "1x";
- adi,input-style = <1>;
- adi,input-justification = "evenly";
ports {
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/r8a7791-porter.dts b/arch/arm/boot/dts/r8a7791-porter.dts
index a8e0335148a5..114bf1c4199b 100644
--- a/arch/arm/boot/dts/r8a7791-porter.dts
+++ b/arch/arm/boot/dts/r8a7791-porter.dts
@@ -181,8 +181,6 @@
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
adi,input-clock = "1x";
- adi,input-style = <1>;
- adi,input-justification = "evenly";
ports {
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/r8a7792-blanche.dts b/arch/arm/boot/dts/r8a7792-blanche.dts
index 248eb717eb35..9368ac2cf508 100644
--- a/arch/arm/boot/dts/r8a7792-blanche.dts
+++ b/arch/arm/boot/dts/r8a7792-blanche.dts
@@ -289,8 +289,6 @@
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
adi,input-clock = "1x";
- adi,input-style = <1>;
- adi,input-justification = "evenly";
ports {
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/r8a7792-wheat.dts b/arch/arm/boot/dts/r8a7792-wheat.dts
index bd2a63bdab3d..ba2d2a589012 100644
--- a/arch/arm/boot/dts/r8a7792-wheat.dts
+++ b/arch/arm/boot/dts/r8a7792-wheat.dts
@@ -249,14 +249,12 @@
*/
hdmi@3d {
compatible = "adi,adv7513";
- reg = <0x3d>, <0x2d>, <0x4d>, <0x5d>;
- reg-names = "main", "cec", "edid", "packet";
+ reg = <0x3d>, <0x4d>, <0x2d>, <0x5d>;
+ reg-names = "main", "edid", "cec", "packet";
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
adi,input-clock = "1x";
- adi,input-style = <1>;
- adi,input-justification = "evenly";
ports {
#address-cells = <1>;
@@ -280,14 +278,12 @@
hdmi@39 {
compatible = "adi,adv7513";
- reg = <0x39>, <0x29>, <0x49>, <0x59>;
- reg-names = "main", "cec", "edid", "packet";
+ reg = <0x39>, <0x49>, <0x29>, <0x59>;
+ reg-names = "main", "edid", "cec", "packet";
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
adi,input-clock = "1x";
- adi,input-style = <1>;
- adi,input-justification = "evenly";
ports {
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/r8a7793-gose.dts b/arch/arm/boot/dts/r8a7793-gose.dts
index cfe06a74ce89..79baf06019f5 100644
--- a/arch/arm/boot/dts/r8a7793-gose.dts
+++ b/arch/arm/boot/dts/r8a7793-gose.dts
@@ -366,8 +366,6 @@
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
adi,input-clock = "1x";
- adi,input-style = <1>;
- adi,input-justification = "evenly";
ports {
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/r8a7794-silk.dts b/arch/arm/boot/dts/r8a7794-silk.dts
index 9aaa96ea9943..b8b0941f677c 100644
--- a/arch/arm/boot/dts/r8a7794-silk.dts
+++ b/arch/arm/boot/dts/r8a7794-silk.dts
@@ -255,8 +255,6 @@
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
adi,input-clock = "1x";
- adi,input-style = <1>;
- adi,input-justification = "evenly";
ports {
#address-cells = <1>;
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 66+ messages in thread* Re: [PATCH v2 2/6] ARM: dts: renesas: make hdmi encoder nodes compliant with DT bindings
2020-05-11 11:06 ` Ricardo Cañuelo
@ 2020-05-11 11:51 ` Geert Uytterhoeven
-1 siblings, 0 replies; 66+ messages in thread
From: Geert Uytterhoeven @ 2020-05-11 11:51 UTC (permalink / raw)
To: Ricardo Cañuelo
Cc: Laurent Pinchart, Collabora Kernel ML,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, Rob Herring, Wei Xu
On Mon, May 11, 2020 at 1:06 PM Ricardo Cañuelo
<ricardo.canuelo@collabora.com> wrote:
> Small fixes to make these DTs compliant with the adi,adv7511w and
> adiadv7513 bindings:
>
> r8a7745-iwg22d-sodimm-dbhd-ca.dts
> r8a7790-lager.dts
> r8a7790-stout.dts
> r8a7791-koelsch.dts
> r8a7791-porter.dts
> r8a7792-blanche.dts
> r8a7793-gose.dts
> r8a7794-silk.dts:
> Remove the adi,input-style and adi,input-justification properties
>
> r8a7792-wheat.dts:
> Reorder the I2C slave addresses of hdmi@3d and hdmi@39 and remove the
> adi,input-style and adi,input-justification properties.
>
> Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 66+ messages in thread* Re: [PATCH v2 2/6] ARM: dts: renesas: make hdmi encoder nodes compliant with DT bindings
@ 2020-05-11 11:51 ` Geert Uytterhoeven
0 siblings, 0 replies; 66+ messages in thread
From: Geert Uytterhoeven @ 2020-05-11 11:51 UTC (permalink / raw)
To: Ricardo Cañuelo
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Wei Xu, Rob Herring, Laurent Pinchart, Collabora Kernel ML,
Linux ARM
On Mon, May 11, 2020 at 1:06 PM Ricardo Cañuelo
<ricardo.canuelo@collabora.com> wrote:
> Small fixes to make these DTs compliant with the adi,adv7511w and
> adiadv7513 bindings:
>
> r8a7745-iwg22d-sodimm-dbhd-ca.dts
> r8a7790-lager.dts
> r8a7790-stout.dts
> r8a7791-koelsch.dts
> r8a7791-porter.dts
> r8a7792-blanche.dts
> r8a7793-gose.dts
> r8a7794-silk.dts:
> Remove the adi,input-style and adi,input-justification properties
>
> r8a7792-wheat.dts:
> Reorder the I2C slave addresses of hdmi@3d and hdmi@39 and remove the
> adi,input-style and adi,input-justification properties.
>
> Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCH v2 2/6] ARM: dts: renesas: make hdmi encoder nodes compliant with DT bindings
2020-05-11 11:06 ` Ricardo Cañuelo
@ 2020-05-14 1:34 ` Laurent Pinchart
-1 siblings, 0 replies; 66+ messages in thread
From: Laurent Pinchart @ 2020-05-14 1:34 UTC (permalink / raw)
To: Ricardo Cañuelo
Cc: kernel, devicetree, linux-arm-kernel, geert+renesas, robh+dt, xuwei5
Hi Ricardo,
Thank you for the patch.
On Mon, May 11, 2020 at 01:06:07PM +0200, Ricardo Cañuelo wrote:
> Small fixes to make these DTs compliant with the adi,adv7511w and
> adiadv7513 bindings:
>
> r8a7745-iwg22d-sodimm-dbhd-ca.dts
> r8a7790-lager.dts
> r8a7790-stout.dts
> r8a7791-koelsch.dts
> r8a7791-porter.dts
> r8a7792-blanche.dts
> r8a7793-gose.dts
> r8a7794-silk.dts:
> Remove the adi,input-style and adi,input-justification properties
>
> r8a7792-wheat.dts:
> Reorder the I2C slave addresses of hdmi@3d and hdmi@39 and remove the
> adi,input-style and adi,input-justification properties.
>
> Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> arch/arm/boot/dts/r8a7745-iwg22d-sodimm-dbhd-ca.dts | 2 --
> arch/arm/boot/dts/r8a7790-lager.dts | 2 --
> arch/arm/boot/dts/r8a7790-stout.dts | 2 --
> arch/arm/boot/dts/r8a7791-koelsch.dts | 2 --
> arch/arm/boot/dts/r8a7791-porter.dts | 2 --
> arch/arm/boot/dts/r8a7792-blanche.dts | 2 --
> arch/arm/boot/dts/r8a7792-wheat.dts | 12 ++++--------
> arch/arm/boot/dts/r8a7793-gose.dts | 2 --
> arch/arm/boot/dts/r8a7794-silk.dts | 2 --
> 9 files changed, 4 insertions(+), 24 deletions(-)
>
> diff --git a/arch/arm/boot/dts/r8a7745-iwg22d-sodimm-dbhd-ca.dts b/arch/arm/boot/dts/r8a7745-iwg22d-sodimm-dbhd-ca.dts
> index 92aa26ba423c..b1f679da36b2 100644
> --- a/arch/arm/boot/dts/r8a7745-iwg22d-sodimm-dbhd-ca.dts
> +++ b/arch/arm/boot/dts/r8a7745-iwg22d-sodimm-dbhd-ca.dts
> @@ -84,8 +84,6 @@
> adi,input-depth = <8>;
> adi,input-colorspace = "rgb";
> adi,input-clock = "1x";
> - adi,input-style = <1>;
> - adi,input-justification = "evenly";
>
> ports {
> #address-cells = <1>;
> diff --git a/arch/arm/boot/dts/r8a7790-lager.dts b/arch/arm/boot/dts/r8a7790-lager.dts
> index 69745def44d4..bfe778c4c47b 100644
> --- a/arch/arm/boot/dts/r8a7790-lager.dts
> +++ b/arch/arm/boot/dts/r8a7790-lager.dts
> @@ -364,8 +364,6 @@
> adi,input-depth = <8>;
> adi,input-colorspace = "rgb";
> adi,input-clock = "1x";
> - adi,input-style = <1>;
> - adi,input-justification = "evenly";
>
> ports {
> #address-cells = <1>;
> diff --git a/arch/arm/boot/dts/r8a7790-stout.dts b/arch/arm/boot/dts/r8a7790-stout.dts
> index 4138efb2766d..6a457bc9280a 100644
> --- a/arch/arm/boot/dts/r8a7790-stout.dts
> +++ b/arch/arm/boot/dts/r8a7790-stout.dts
> @@ -297,8 +297,6 @@
> adi,input-depth = <8>;
> adi,input-colorspace = "rgb";
> adi,input-clock = "1x";
> - adi,input-style = <1>;
> - adi,input-justification = "evenly";
>
> ports {
> #address-cells = <1>;
> diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts b/arch/arm/boot/dts/r8a7791-koelsch.dts
> index 687167b70cb6..fc74c6cd6def 100644
> --- a/arch/arm/boot/dts/r8a7791-koelsch.dts
> +++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
> @@ -387,8 +387,6 @@
> adi,input-depth = <8>;
> adi,input-colorspace = "rgb";
> adi,input-clock = "1x";
> - adi,input-style = <1>;
> - adi,input-justification = "evenly";
>
> ports {
> #address-cells = <1>;
> diff --git a/arch/arm/boot/dts/r8a7791-porter.dts b/arch/arm/boot/dts/r8a7791-porter.dts
> index a8e0335148a5..114bf1c4199b 100644
> --- a/arch/arm/boot/dts/r8a7791-porter.dts
> +++ b/arch/arm/boot/dts/r8a7791-porter.dts
> @@ -181,8 +181,6 @@
> adi,input-depth = <8>;
> adi,input-colorspace = "rgb";
> adi,input-clock = "1x";
> - adi,input-style = <1>;
> - adi,input-justification = "evenly";
>
> ports {
> #address-cells = <1>;
> diff --git a/arch/arm/boot/dts/r8a7792-blanche.dts b/arch/arm/boot/dts/r8a7792-blanche.dts
> index 248eb717eb35..9368ac2cf508 100644
> --- a/arch/arm/boot/dts/r8a7792-blanche.dts
> +++ b/arch/arm/boot/dts/r8a7792-blanche.dts
> @@ -289,8 +289,6 @@
> adi,input-depth = <8>;
> adi,input-colorspace = "rgb";
> adi,input-clock = "1x";
> - adi,input-style = <1>;
> - adi,input-justification = "evenly";
>
> ports {
> #address-cells = <1>;
> diff --git a/arch/arm/boot/dts/r8a7792-wheat.dts b/arch/arm/boot/dts/r8a7792-wheat.dts
> index bd2a63bdab3d..ba2d2a589012 100644
> --- a/arch/arm/boot/dts/r8a7792-wheat.dts
> +++ b/arch/arm/boot/dts/r8a7792-wheat.dts
> @@ -249,14 +249,12 @@
> */
> hdmi@3d {
> compatible = "adi,adv7513";
> - reg = <0x3d>, <0x2d>, <0x4d>, <0x5d>;
> - reg-names = "main", "cec", "edid", "packet";
> + reg = <0x3d>, <0x4d>, <0x2d>, <0x5d>;
> + reg-names = "main", "edid", "cec", "packet";
>
> adi,input-depth = <8>;
> adi,input-colorspace = "rgb";
> adi,input-clock = "1x";
> - adi,input-style = <1>;
> - adi,input-justification = "evenly";
>
> ports {
> #address-cells = <1>;
> @@ -280,14 +278,12 @@
>
> hdmi@39 {
> compatible = "adi,adv7513";
> - reg = <0x39>, <0x29>, <0x49>, <0x59>;
> - reg-names = "main", "cec", "edid", "packet";
> + reg = <0x39>, <0x49>, <0x29>, <0x59>;
> + reg-names = "main", "edid", "cec", "packet";
>
> adi,input-depth = <8>;
> adi,input-colorspace = "rgb";
> adi,input-clock = "1x";
> - adi,input-style = <1>;
> - adi,input-justification = "evenly";
>
> ports {
> #address-cells = <1>;
> diff --git a/arch/arm/boot/dts/r8a7793-gose.dts b/arch/arm/boot/dts/r8a7793-gose.dts
> index cfe06a74ce89..79baf06019f5 100644
> --- a/arch/arm/boot/dts/r8a7793-gose.dts
> +++ b/arch/arm/boot/dts/r8a7793-gose.dts
> @@ -366,8 +366,6 @@
> adi,input-depth = <8>;
> adi,input-colorspace = "rgb";
> adi,input-clock = "1x";
> - adi,input-style = <1>;
> - adi,input-justification = "evenly";
>
> ports {
> #address-cells = <1>;
> diff --git a/arch/arm/boot/dts/r8a7794-silk.dts b/arch/arm/boot/dts/r8a7794-silk.dts
> index 9aaa96ea9943..b8b0941f677c 100644
> --- a/arch/arm/boot/dts/r8a7794-silk.dts
> +++ b/arch/arm/boot/dts/r8a7794-silk.dts
> @@ -255,8 +255,6 @@
> adi,input-depth = <8>;
> adi,input-colorspace = "rgb";
> adi,input-clock = "1x";
> - adi,input-style = <1>;
> - adi,input-justification = "evenly";
>
> ports {
> #address-cells = <1>;
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 66+ messages in thread* Re: [PATCH v2 2/6] ARM: dts: renesas: make hdmi encoder nodes compliant with DT bindings
@ 2020-05-14 1:34 ` Laurent Pinchart
0 siblings, 0 replies; 66+ messages in thread
From: Laurent Pinchart @ 2020-05-14 1:34 UTC (permalink / raw)
To: Ricardo Cañuelo
Cc: devicetree, geert+renesas, xuwei5, robh+dt, kernel, linux-arm-kernel
Hi Ricardo,
Thank you for the patch.
On Mon, May 11, 2020 at 01:06:07PM +0200, Ricardo Cañuelo wrote:
> Small fixes to make these DTs compliant with the adi,adv7511w and
> adiadv7513 bindings:
>
> r8a7745-iwg22d-sodimm-dbhd-ca.dts
> r8a7790-lager.dts
> r8a7790-stout.dts
> r8a7791-koelsch.dts
> r8a7791-porter.dts
> r8a7792-blanche.dts
> r8a7793-gose.dts
> r8a7794-silk.dts:
> Remove the adi,input-style and adi,input-justification properties
>
> r8a7792-wheat.dts:
> Reorder the I2C slave addresses of hdmi@3d and hdmi@39 and remove the
> adi,input-style and adi,input-justification properties.
>
> Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> arch/arm/boot/dts/r8a7745-iwg22d-sodimm-dbhd-ca.dts | 2 --
> arch/arm/boot/dts/r8a7790-lager.dts | 2 --
> arch/arm/boot/dts/r8a7790-stout.dts | 2 --
> arch/arm/boot/dts/r8a7791-koelsch.dts | 2 --
> arch/arm/boot/dts/r8a7791-porter.dts | 2 --
> arch/arm/boot/dts/r8a7792-blanche.dts | 2 --
> arch/arm/boot/dts/r8a7792-wheat.dts | 12 ++++--------
> arch/arm/boot/dts/r8a7793-gose.dts | 2 --
> arch/arm/boot/dts/r8a7794-silk.dts | 2 --
> 9 files changed, 4 insertions(+), 24 deletions(-)
>
> diff --git a/arch/arm/boot/dts/r8a7745-iwg22d-sodimm-dbhd-ca.dts b/arch/arm/boot/dts/r8a7745-iwg22d-sodimm-dbhd-ca.dts
> index 92aa26ba423c..b1f679da36b2 100644
> --- a/arch/arm/boot/dts/r8a7745-iwg22d-sodimm-dbhd-ca.dts
> +++ b/arch/arm/boot/dts/r8a7745-iwg22d-sodimm-dbhd-ca.dts
> @@ -84,8 +84,6 @@
> adi,input-depth = <8>;
> adi,input-colorspace = "rgb";
> adi,input-clock = "1x";
> - adi,input-style = <1>;
> - adi,input-justification = "evenly";
>
> ports {
> #address-cells = <1>;
> diff --git a/arch/arm/boot/dts/r8a7790-lager.dts b/arch/arm/boot/dts/r8a7790-lager.dts
> index 69745def44d4..bfe778c4c47b 100644
> --- a/arch/arm/boot/dts/r8a7790-lager.dts
> +++ b/arch/arm/boot/dts/r8a7790-lager.dts
> @@ -364,8 +364,6 @@
> adi,input-depth = <8>;
> adi,input-colorspace = "rgb";
> adi,input-clock = "1x";
> - adi,input-style = <1>;
> - adi,input-justification = "evenly";
>
> ports {
> #address-cells = <1>;
> diff --git a/arch/arm/boot/dts/r8a7790-stout.dts b/arch/arm/boot/dts/r8a7790-stout.dts
> index 4138efb2766d..6a457bc9280a 100644
> --- a/arch/arm/boot/dts/r8a7790-stout.dts
> +++ b/arch/arm/boot/dts/r8a7790-stout.dts
> @@ -297,8 +297,6 @@
> adi,input-depth = <8>;
> adi,input-colorspace = "rgb";
> adi,input-clock = "1x";
> - adi,input-style = <1>;
> - adi,input-justification = "evenly";
>
> ports {
> #address-cells = <1>;
> diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts b/arch/arm/boot/dts/r8a7791-koelsch.dts
> index 687167b70cb6..fc74c6cd6def 100644
> --- a/arch/arm/boot/dts/r8a7791-koelsch.dts
> +++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
> @@ -387,8 +387,6 @@
> adi,input-depth = <8>;
> adi,input-colorspace = "rgb";
> adi,input-clock = "1x";
> - adi,input-style = <1>;
> - adi,input-justification = "evenly";
>
> ports {
> #address-cells = <1>;
> diff --git a/arch/arm/boot/dts/r8a7791-porter.dts b/arch/arm/boot/dts/r8a7791-porter.dts
> index a8e0335148a5..114bf1c4199b 100644
> --- a/arch/arm/boot/dts/r8a7791-porter.dts
> +++ b/arch/arm/boot/dts/r8a7791-porter.dts
> @@ -181,8 +181,6 @@
> adi,input-depth = <8>;
> adi,input-colorspace = "rgb";
> adi,input-clock = "1x";
> - adi,input-style = <1>;
> - adi,input-justification = "evenly";
>
> ports {
> #address-cells = <1>;
> diff --git a/arch/arm/boot/dts/r8a7792-blanche.dts b/arch/arm/boot/dts/r8a7792-blanche.dts
> index 248eb717eb35..9368ac2cf508 100644
> --- a/arch/arm/boot/dts/r8a7792-blanche.dts
> +++ b/arch/arm/boot/dts/r8a7792-blanche.dts
> @@ -289,8 +289,6 @@
> adi,input-depth = <8>;
> adi,input-colorspace = "rgb";
> adi,input-clock = "1x";
> - adi,input-style = <1>;
> - adi,input-justification = "evenly";
>
> ports {
> #address-cells = <1>;
> diff --git a/arch/arm/boot/dts/r8a7792-wheat.dts b/arch/arm/boot/dts/r8a7792-wheat.dts
> index bd2a63bdab3d..ba2d2a589012 100644
> --- a/arch/arm/boot/dts/r8a7792-wheat.dts
> +++ b/arch/arm/boot/dts/r8a7792-wheat.dts
> @@ -249,14 +249,12 @@
> */
> hdmi@3d {
> compatible = "adi,adv7513";
> - reg = <0x3d>, <0x2d>, <0x4d>, <0x5d>;
> - reg-names = "main", "cec", "edid", "packet";
> + reg = <0x3d>, <0x4d>, <0x2d>, <0x5d>;
> + reg-names = "main", "edid", "cec", "packet";
>
> adi,input-depth = <8>;
> adi,input-colorspace = "rgb";
> adi,input-clock = "1x";
> - adi,input-style = <1>;
> - adi,input-justification = "evenly";
>
> ports {
> #address-cells = <1>;
> @@ -280,14 +278,12 @@
>
> hdmi@39 {
> compatible = "adi,adv7513";
> - reg = <0x39>, <0x29>, <0x49>, <0x59>;
> - reg-names = "main", "cec", "edid", "packet";
> + reg = <0x39>, <0x49>, <0x29>, <0x59>;
> + reg-names = "main", "edid", "cec", "packet";
>
> adi,input-depth = <8>;
> adi,input-colorspace = "rgb";
> adi,input-clock = "1x";
> - adi,input-style = <1>;
> - adi,input-justification = "evenly";
>
> ports {
> #address-cells = <1>;
> diff --git a/arch/arm/boot/dts/r8a7793-gose.dts b/arch/arm/boot/dts/r8a7793-gose.dts
> index cfe06a74ce89..79baf06019f5 100644
> --- a/arch/arm/boot/dts/r8a7793-gose.dts
> +++ b/arch/arm/boot/dts/r8a7793-gose.dts
> @@ -366,8 +366,6 @@
> adi,input-depth = <8>;
> adi,input-colorspace = "rgb";
> adi,input-clock = "1x";
> - adi,input-style = <1>;
> - adi,input-justification = "evenly";
>
> ports {
> #address-cells = <1>;
> diff --git a/arch/arm/boot/dts/r8a7794-silk.dts b/arch/arm/boot/dts/r8a7794-silk.dts
> index 9aaa96ea9943..b8b0941f677c 100644
> --- a/arch/arm/boot/dts/r8a7794-silk.dts
> +++ b/arch/arm/boot/dts/r8a7794-silk.dts
> @@ -255,8 +255,6 @@
> adi,input-depth = <8>;
> adi,input-colorspace = "rgb";
> adi,input-clock = "1x";
> - adi,input-style = <1>;
> - adi,input-justification = "evenly";
>
> ports {
> #address-cells = <1>;
--
Regards,
Laurent Pinchart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCH v2 3/6] ARM: dts: zynq: add port definitions to hdmi-tx@39
2020-05-11 11:06 ` Ricardo Cañuelo
@ 2020-05-11 11:06 ` Ricardo Cañuelo
-1 siblings, 0 replies; 66+ messages in thread
From: Ricardo Cañuelo @ 2020-05-11 11:06 UTC (permalink / raw)
To: laurent.pinchart
Cc: kernel, devicetree, linux-arm-kernel, geert+renesas, robh+dt, xuwei5
Define a 'ports' node for 'adv7511: hdmi-tx@39' to make it compliant with
the adi,adv7511 DT binding.
This fills the minimum requirements to meet the binding requirements,
remote endpoints are not defined.
Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
---
arch/arm/boot/dts/zynq-zc702.dts | 10 ++++++++++
arch/arm/boot/dts/zynq-zc706.dts | 10 ++++++++++
2 files changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/zynq-zc702.dts b/arch/arm/boot/dts/zynq-zc702.dts
index 27cd6cb52f1b..79fd236edded 100644
--- a/arch/arm/boot/dts/zynq-zc702.dts
+++ b/arch/arm/boot/dts/zynq-zc702.dts
@@ -135,6 +135,16 @@
adi,input-clock = "1x";
adi,input-style = <3>;
adi,input-justification = "right";
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ };
+ port@1 {
+ reg = <1>;
+ };
+ };
};
};
diff --git a/arch/arm/boot/dts/zynq-zc706.dts b/arch/arm/boot/dts/zynq-zc706.dts
index 77943c16d33f..99fa51ba6e93 100644
--- a/arch/arm/boot/dts/zynq-zc706.dts
+++ b/arch/arm/boot/dts/zynq-zc706.dts
@@ -93,6 +93,16 @@
adi,input-clock = "1x";
adi,input-style = <3>;
adi,input-justification = "evenly";
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ };
+ port@1 {
+ reg = <1>;
+ };
+ };
};
};
--
2.18.0
^ permalink raw reply related [flat|nested] 66+ messages in thread* [PATCH v2 3/6] ARM: dts: zynq: add port definitions to hdmi-tx@39
@ 2020-05-11 11:06 ` Ricardo Cañuelo
0 siblings, 0 replies; 66+ messages in thread
From: Ricardo Cañuelo @ 2020-05-11 11:06 UTC (permalink / raw)
To: laurent.pinchart
Cc: devicetree, geert+renesas, xuwei5, robh+dt, kernel, linux-arm-kernel
Define a 'ports' node for 'adv7511: hdmi-tx@39' to make it compliant with
the adi,adv7511 DT binding.
This fills the minimum requirements to meet the binding requirements,
remote endpoints are not defined.
Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
---
arch/arm/boot/dts/zynq-zc702.dts | 10 ++++++++++
arch/arm/boot/dts/zynq-zc706.dts | 10 ++++++++++
2 files changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/zynq-zc702.dts b/arch/arm/boot/dts/zynq-zc702.dts
index 27cd6cb52f1b..79fd236edded 100644
--- a/arch/arm/boot/dts/zynq-zc702.dts
+++ b/arch/arm/boot/dts/zynq-zc702.dts
@@ -135,6 +135,16 @@
adi,input-clock = "1x";
adi,input-style = <3>;
adi,input-justification = "right";
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ };
+ port@1 {
+ reg = <1>;
+ };
+ };
};
};
diff --git a/arch/arm/boot/dts/zynq-zc706.dts b/arch/arm/boot/dts/zynq-zc706.dts
index 77943c16d33f..99fa51ba6e93 100644
--- a/arch/arm/boot/dts/zynq-zc706.dts
+++ b/arch/arm/boot/dts/zynq-zc706.dts
@@ -93,6 +93,16 @@
adi,input-clock = "1x";
adi,input-style = <3>;
adi,input-justification = "evenly";
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ };
+ port@1 {
+ reg = <1>;
+ };
+ };
};
};
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 66+ messages in thread* Re: [PATCH v2 3/6] ARM: dts: zynq: add port definitions to hdmi-tx@39
2020-05-11 11:06 ` Ricardo Cañuelo
@ 2020-05-11 12:24 ` Ezequiel Garcia
-1 siblings, 0 replies; 66+ messages in thread
From: Ezequiel Garcia @ 2020-05-11 12:24 UTC (permalink / raw)
To: Michal Simek
Cc: kernel, devicetree, linux-arm-kernel, geert+renesas, robh+dt,
xuwei5, Ricardo Cañuelo, Laurent Pinchart
(Adding Michal)
On Mon, 2020-05-11 at 13:06 +0200, Ricardo Cañuelo wrote:
> Define a 'ports' node for 'adv7511: hdmi-tx@39' to make it compliant with
> the adi,adv7511 DT binding.
>
> This fills the minimum requirements to meet the binding requirements,
> remote endpoints are not defined.
>
> Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
> ---
> arch/arm/boot/dts/zynq-zc702.dts | 10 ++++++++++
> arch/arm/boot/dts/zynq-zc706.dts | 10 ++++++++++
> 2 files changed, 20 insertions(+)
>
> diff --git a/arch/arm/boot/dts/zynq-zc702.dts b/arch/arm/boot/dts/zynq-zc702.dts
> index 27cd6cb52f1b..79fd236edded 100644
> --- a/arch/arm/boot/dts/zynq-zc702.dts
> +++ b/arch/arm/boot/dts/zynq-zc702.dts
> @@ -135,6 +135,16 @@
> adi,input-clock = "1x";
> adi,input-style = <3>;
> adi,input-justification = "right";
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port@0 {
> + reg = <0>;
> + };
> + port@1 {
> + reg = <1>;
> + };
> + };
> };
> };
>
> diff --git a/arch/arm/boot/dts/zynq-zc706.dts b/arch/arm/boot/dts/zynq-zc706.dts
> index 77943c16d33f..99fa51ba6e93 100644
> --- a/arch/arm/boot/dts/zynq-zc706.dts
> +++ b/arch/arm/boot/dts/zynq-zc706.dts
> @@ -93,6 +93,16 @@
> adi,input-clock = "1x";
> adi,input-style = <3>;
> adi,input-justification = "evenly";
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port@0 {
> + reg = <0>;
> + };
> + port@1 {
> + reg = <1>;
> + };
> + };
> };
> };
>
> --
> 2.18.0
>
>
^ permalink raw reply [flat|nested] 66+ messages in thread* Re: [PATCH v2 3/6] ARM: dts: zynq: add port definitions to hdmi-tx@39
@ 2020-05-11 12:24 ` Ezequiel Garcia
0 siblings, 0 replies; 66+ messages in thread
From: Ezequiel Garcia @ 2020-05-11 12:24 UTC (permalink / raw)
To: Michal Simek
Cc: devicetree, geert+renesas, xuwei5, robh+dt, Laurent Pinchart,
kernel, Ricardo Cañuelo, linux-arm-kernel
(Adding Michal)
On Mon, 2020-05-11 at 13:06 +0200, Ricardo Cañuelo wrote:
> Define a 'ports' node for 'adv7511: hdmi-tx@39' to make it compliant with
> the adi,adv7511 DT binding.
>
> This fills the minimum requirements to meet the binding requirements,
> remote endpoints are not defined.
>
> Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
> ---
> arch/arm/boot/dts/zynq-zc702.dts | 10 ++++++++++
> arch/arm/boot/dts/zynq-zc706.dts | 10 ++++++++++
> 2 files changed, 20 insertions(+)
>
> diff --git a/arch/arm/boot/dts/zynq-zc702.dts b/arch/arm/boot/dts/zynq-zc702.dts
> index 27cd6cb52f1b..79fd236edded 100644
> --- a/arch/arm/boot/dts/zynq-zc702.dts
> +++ b/arch/arm/boot/dts/zynq-zc702.dts
> @@ -135,6 +135,16 @@
> adi,input-clock = "1x";
> adi,input-style = <3>;
> adi,input-justification = "right";
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port@0 {
> + reg = <0>;
> + };
> + port@1 {
> + reg = <1>;
> + };
> + };
> };
> };
>
> diff --git a/arch/arm/boot/dts/zynq-zc706.dts b/arch/arm/boot/dts/zynq-zc706.dts
> index 77943c16d33f..99fa51ba6e93 100644
> --- a/arch/arm/boot/dts/zynq-zc706.dts
> +++ b/arch/arm/boot/dts/zynq-zc706.dts
> @@ -93,6 +93,16 @@
> adi,input-clock = "1x";
> adi,input-style = <3>;
> adi,input-justification = "evenly";
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port@0 {
> + reg = <0>;
> + };
> + port@1 {
> + reg = <1>;
> + };
> + };
> };
> };
>
> --
> 2.18.0
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 66+ messages in thread* Re: [PATCH v2 3/6] ARM: dts: zynq: add port definitions to hdmi-tx@39
2020-05-11 12:24 ` Ezequiel Garcia
@ 2020-05-11 12:52 ` Michal Simek
-1 siblings, 0 replies; 66+ messages in thread
From: Michal Simek @ 2020-05-11 12:52 UTC (permalink / raw)
To: Ezequiel Garcia, Michal Simek
Cc: kernel, devicetree, linux-arm-kernel, geert+renesas, robh+dt,
xuwei5, Ricardo Cañuelo, Laurent Pinchart
On 11. 05. 20 14:24, Ezequiel Garcia wrote:
> (Adding Michal)
>
> On Mon, 2020-05-11 at 13:06 +0200, Ricardo Cañuelo wrote:
>> Define a 'ports' node for 'adv7511: hdmi-tx@39' to make it compliant with
>> the adi,adv7511 DT binding.
>>
>> This fills the minimum requirements to meet the binding requirements,
>> remote endpoints are not defined.
>>
>> Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
>> ---
>> arch/arm/boot/dts/zynq-zc702.dts | 10 ++++++++++
>> arch/arm/boot/dts/zynq-zc706.dts | 10 ++++++++++
>> 2 files changed, 20 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/zynq-zc702.dts b/arch/arm/boot/dts/zynq-zc702.dts
>> index 27cd6cb52f1b..79fd236edded 100644
>> --- a/arch/arm/boot/dts/zynq-zc702.dts
>> +++ b/arch/arm/boot/dts/zynq-zc702.dts
>> @@ -135,6 +135,16 @@
>> adi,input-clock = "1x";
>> adi,input-style = <3>;
>> adi,input-justification = "right";
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + port@0 {
>> + reg = <0>;
>> + };
>> + port@1 {
>> + reg = <1>;
>> + };
>> + };
>> };
>> };
>>
>> diff --git a/arch/arm/boot/dts/zynq-zc706.dts b/arch/arm/boot/dts/zynq-zc706.dts
>> index 77943c16d33f..99fa51ba6e93 100644
>> --- a/arch/arm/boot/dts/zynq-zc706.dts
>> +++ b/arch/arm/boot/dts/zynq-zc706.dts
>> @@ -93,6 +93,16 @@
>> adi,input-clock = "1x";
>> adi,input-style = <3>;
>> adi,input-justification = "evenly";
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + port@0 {
>> + reg = <0>;
>> + };
>> + port@1 {
>> + reg = <1>;
>> + };
>> + };
>> };
>> };
>>
>> --
>> 2.18.0
>>
>>
>
>
Just c&p Laurent's reply to Ricardo about it.
"Completing the board definition is best I believe. Sometimes the
endpoint is related to an add-on board that isn't described as part of
the base DTS. The ports are required as they describe hardware
interfaces, but having no endpoint in a port shouldn't be a problem, it
just means the port is not connected."
I am ok with it too that's why
Acked-by: Michal Simek <michal.simek@xilinx.com>
Thanks,
Michalt
^ permalink raw reply [flat|nested] 66+ messages in thread* Re: [PATCH v2 3/6] ARM: dts: zynq: add port definitions to hdmi-tx@39
@ 2020-05-11 12:52 ` Michal Simek
0 siblings, 0 replies; 66+ messages in thread
From: Michal Simek @ 2020-05-11 12:52 UTC (permalink / raw)
To: Ezequiel Garcia, Michal Simek
Cc: devicetree, geert+renesas, xuwei5, robh+dt, Laurent Pinchart,
kernel, Ricardo Cañuelo, linux-arm-kernel
On 11. 05. 20 14:24, Ezequiel Garcia wrote:
> (Adding Michal)
>
> On Mon, 2020-05-11 at 13:06 +0200, Ricardo Cañuelo wrote:
>> Define a 'ports' node for 'adv7511: hdmi-tx@39' to make it compliant with
>> the adi,adv7511 DT binding.
>>
>> This fills the minimum requirements to meet the binding requirements,
>> remote endpoints are not defined.
>>
>> Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
>> ---
>> arch/arm/boot/dts/zynq-zc702.dts | 10 ++++++++++
>> arch/arm/boot/dts/zynq-zc706.dts | 10 ++++++++++
>> 2 files changed, 20 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/zynq-zc702.dts b/arch/arm/boot/dts/zynq-zc702.dts
>> index 27cd6cb52f1b..79fd236edded 100644
>> --- a/arch/arm/boot/dts/zynq-zc702.dts
>> +++ b/arch/arm/boot/dts/zynq-zc702.dts
>> @@ -135,6 +135,16 @@
>> adi,input-clock = "1x";
>> adi,input-style = <3>;
>> adi,input-justification = "right";
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + port@0 {
>> + reg = <0>;
>> + };
>> + port@1 {
>> + reg = <1>;
>> + };
>> + };
>> };
>> };
>>
>> diff --git a/arch/arm/boot/dts/zynq-zc706.dts b/arch/arm/boot/dts/zynq-zc706.dts
>> index 77943c16d33f..99fa51ba6e93 100644
>> --- a/arch/arm/boot/dts/zynq-zc706.dts
>> +++ b/arch/arm/boot/dts/zynq-zc706.dts
>> @@ -93,6 +93,16 @@
>> adi,input-clock = "1x";
>> adi,input-style = <3>;
>> adi,input-justification = "evenly";
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + port@0 {
>> + reg = <0>;
>> + };
>> + port@1 {
>> + reg = <1>;
>> + };
>> + };
>> };
>> };
>>
>> --
>> 2.18.0
>>
>>
>
>
Just c&p Laurent's reply to Ricardo about it.
"Completing the board definition is best I believe. Sometimes the
endpoint is related to an add-on board that isn't described as part of
the base DTS. The ports are required as they describe hardware
interfaces, but having no endpoint in a port shouldn't be a problem, it
just means the port is not connected."
I am ok with it too that's why
Acked-by: Michal Simek <michal.simek@xilinx.com>
Thanks,
Michalt
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 66+ messages in thread* Re: [PATCH v2 3/6] ARM: dts: zynq: add port definitions to hdmi-tx@39
2020-05-11 12:52 ` Michal Simek
@ 2020-05-14 1:36 ` Laurent Pinchart
-1 siblings, 0 replies; 66+ messages in thread
From: Laurent Pinchart @ 2020-05-14 1:36 UTC (permalink / raw)
To: Michal Simek
Cc: Ezequiel Garcia, kernel, devicetree, linux-arm-kernel,
geert+renesas, robh+dt, xuwei5, Ricardo Cañuelo
Hello,
On Mon, May 11, 2020 at 02:52:50PM +0200, Michal Simek wrote:
> On 11. 05. 20 14:24, Ezequiel Garcia wrote:
> > (Adding Michal)
> >
> > On Mon, 2020-05-11 at 13:06 +0200, Ricardo Cañuelo wrote:
> >> Define a 'ports' node for 'adv7511: hdmi-tx@39' to make it compliant with
> >> the adi,adv7511 DT binding.
> >>
> >> This fills the minimum requirements to meet the binding requirements,
> >> remote endpoints are not defined.
> >>
> >> Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
> >> ---
> >> arch/arm/boot/dts/zynq-zc702.dts | 10 ++++++++++
> >> arch/arm/boot/dts/zynq-zc706.dts | 10 ++++++++++
> >> 2 files changed, 20 insertions(+)
> >>
> >> diff --git a/arch/arm/boot/dts/zynq-zc702.dts b/arch/arm/boot/dts/zynq-zc702.dts
> >> index 27cd6cb52f1b..79fd236edded 100644
> >> --- a/arch/arm/boot/dts/zynq-zc702.dts
> >> +++ b/arch/arm/boot/dts/zynq-zc702.dts
> >> @@ -135,6 +135,16 @@
> >> adi,input-clock = "1x";
> >> adi,input-style = <3>;
> >> adi,input-justification = "right";
> >> + ports {
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> + port@0 {
> >> + reg = <0>;
> >> + };
> >> + port@1 {
> >> + reg = <1>;
> >> + };
> >> + };
> >> };
> >> };
> >>
> >> diff --git a/arch/arm/boot/dts/zynq-zc706.dts b/arch/arm/boot/dts/zynq-zc706.dts
> >> index 77943c16d33f..99fa51ba6e93 100644
> >> --- a/arch/arm/boot/dts/zynq-zc706.dts
> >> +++ b/arch/arm/boot/dts/zynq-zc706.dts
> >> @@ -93,6 +93,16 @@
> >> adi,input-clock = "1x";
> >> adi,input-style = <3>;
> >> adi,input-justification = "evenly";
> >> + ports {
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> + port@0 {
> >> + reg = <0>;
> >> + };
> >> + port@1 {
> >> + reg = <1>;
> >> + };
> >> + };
> >> };
> >> };
> >>
>
> Just c&p Laurent's reply to Ricardo about it.
>
> "Completing the board definition is best I believe. Sometimes the
> endpoint is related to an add-on board that isn't described as part of
> the base DTS. The ports are required as they describe hardware
> interfaces, but having no endpoint in a port shouldn't be a problem, it
> just means the port is not connected."
>
> I am ok with it too that's why
>
> Acked-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 66+ messages in thread* Re: [PATCH v2 3/6] ARM: dts: zynq: add port definitions to hdmi-tx@39
@ 2020-05-14 1:36 ` Laurent Pinchart
0 siblings, 0 replies; 66+ messages in thread
From: Laurent Pinchart @ 2020-05-14 1:36 UTC (permalink / raw)
To: Michal Simek
Cc: devicetree, geert+renesas, Ricardo Cañuelo, xuwei5, robh+dt,
kernel, Ezequiel Garcia, linux-arm-kernel
Hello,
On Mon, May 11, 2020 at 02:52:50PM +0200, Michal Simek wrote:
> On 11. 05. 20 14:24, Ezequiel Garcia wrote:
> > (Adding Michal)
> >
> > On Mon, 2020-05-11 at 13:06 +0200, Ricardo Cañuelo wrote:
> >> Define a 'ports' node for 'adv7511: hdmi-tx@39' to make it compliant with
> >> the adi,adv7511 DT binding.
> >>
> >> This fills the minimum requirements to meet the binding requirements,
> >> remote endpoints are not defined.
> >>
> >> Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
> >> ---
> >> arch/arm/boot/dts/zynq-zc702.dts | 10 ++++++++++
> >> arch/arm/boot/dts/zynq-zc706.dts | 10 ++++++++++
> >> 2 files changed, 20 insertions(+)
> >>
> >> diff --git a/arch/arm/boot/dts/zynq-zc702.dts b/arch/arm/boot/dts/zynq-zc702.dts
> >> index 27cd6cb52f1b..79fd236edded 100644
> >> --- a/arch/arm/boot/dts/zynq-zc702.dts
> >> +++ b/arch/arm/boot/dts/zynq-zc702.dts
> >> @@ -135,6 +135,16 @@
> >> adi,input-clock = "1x";
> >> adi,input-style = <3>;
> >> adi,input-justification = "right";
> >> + ports {
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> + port@0 {
> >> + reg = <0>;
> >> + };
> >> + port@1 {
> >> + reg = <1>;
> >> + };
> >> + };
> >> };
> >> };
> >>
> >> diff --git a/arch/arm/boot/dts/zynq-zc706.dts b/arch/arm/boot/dts/zynq-zc706.dts
> >> index 77943c16d33f..99fa51ba6e93 100644
> >> --- a/arch/arm/boot/dts/zynq-zc706.dts
> >> +++ b/arch/arm/boot/dts/zynq-zc706.dts
> >> @@ -93,6 +93,16 @@
> >> adi,input-clock = "1x";
> >> adi,input-style = <3>;
> >> adi,input-justification = "evenly";
> >> + ports {
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> + port@0 {
> >> + reg = <0>;
> >> + };
> >> + port@1 {
> >> + reg = <1>;
> >> + };
> >> + };
> >> };
> >> };
> >>
>
> Just c&p Laurent's reply to Ricardo about it.
>
> "Completing the board definition is best I believe. Sometimes the
> endpoint is related to an add-on board that isn't described as part of
> the base DTS. The ports are required as they describe hardware
> interfaces, but having no endpoint in a port shouldn't be a problem, it
> just means the port is not connected."
>
> I am ok with it too that's why
>
> Acked-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
--
Regards,
Laurent Pinchart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCH v2 4/6] arm64: dts: hisilicon: hikey: fixes to comply with adi,adv7533 DT binding
2020-05-11 11:06 ` Ricardo Cañuelo
@ 2020-05-11 11:06 ` Ricardo Cañuelo
-1 siblings, 0 replies; 66+ messages in thread
From: Ricardo Cañuelo @ 2020-05-11 11:06 UTC (permalink / raw)
To: laurent.pinchart
Cc: kernel, devicetree, linux-arm-kernel, geert+renesas, robh+dt, xuwei5
hi3660-hikey960.dts:
Define a 'ports' node for 'adv7533: adv7533@39' and the
'adi,dsi-lanes' property to make it compliant with the adi,adv7533 DT
binding.
This fills the requirements to meet the binding requirements,
remote endpoints are not defined.
hi6220-hikey.dts:
Change property name s/pd-gpio/pd-gpios, gpio properties should be
plural. This is just a cosmetic change.
Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
---
arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts | 11 +++++++++++
arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 2 +-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
index e035cf195b19..8c4bfbaf3a80 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
@@ -530,6 +530,17 @@
status = "ok";
compatible = "adi,adv7533";
reg = <0x39>;
+ adi,dsi-lanes = <4>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ };
+ port@1 {
+ reg = <1>;
+ };
+ };
};
};
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
index c14205cd6bf5..3e47150c05ec 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
@@ -516,7 +516,7 @@
reg = <0x39>;
interrupt-parent = <&gpio1>;
interrupts = <1 2>;
- pd-gpio = <&gpio0 4 0>;
+ pd-gpios = <&gpio0 4 0>;
adi,dsi-lanes = <4>;
#sound-dai-cells = <0>;
--
2.18.0
^ permalink raw reply related [flat|nested] 66+ messages in thread* [PATCH v2 4/6] arm64: dts: hisilicon: hikey: fixes to comply with adi, adv7533 DT binding
@ 2020-05-11 11:06 ` Ricardo Cañuelo
0 siblings, 0 replies; 66+ messages in thread
From: Ricardo Cañuelo @ 2020-05-11 11:06 UTC (permalink / raw)
To: laurent.pinchart
Cc: devicetree, geert+renesas, xuwei5, robh+dt, kernel, linux-arm-kernel
hi3660-hikey960.dts:
Define a 'ports' node for 'adv7533: adv7533@39' and the
'adi,dsi-lanes' property to make it compliant with the adi,adv7533 DT
binding.
This fills the requirements to meet the binding requirements,
remote endpoints are not defined.
hi6220-hikey.dts:
Change property name s/pd-gpio/pd-gpios, gpio properties should be
plural. This is just a cosmetic change.
Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
---
arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts | 11 +++++++++++
arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 2 +-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
index e035cf195b19..8c4bfbaf3a80 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
@@ -530,6 +530,17 @@
status = "ok";
compatible = "adi,adv7533";
reg = <0x39>;
+ adi,dsi-lanes = <4>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ };
+ port@1 {
+ reg = <1>;
+ };
+ };
};
};
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
index c14205cd6bf5..3e47150c05ec 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
@@ -516,7 +516,7 @@
reg = <0x39>;
interrupt-parent = <&gpio1>;
interrupts = <1 2>;
- pd-gpio = <&gpio0 4 0>;
+ pd-gpios = <&gpio0 4 0>;
adi,dsi-lanes = <4>;
#sound-dai-cells = <0>;
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 66+ messages in thread* Re: [PATCH v2 4/6] arm64: dts: hisilicon: hikey: fixes to comply with adi,adv7533 DT binding
2020-05-11 11:06 ` [PATCH v2 4/6] arm64: dts: hisilicon: hikey: fixes to comply with adi, adv7533 " Ricardo Cañuelo
@ 2020-05-14 1:37 ` Laurent Pinchart
-1 siblings, 0 replies; 66+ messages in thread
From: Laurent Pinchart @ 2020-05-14 1:37 UTC (permalink / raw)
To: Ricardo Cañuelo
Cc: kernel, devicetree, linux-arm-kernel, geert+renesas, robh+dt, xuwei5
Hi Ricardo,
Thank you for the patch.
On Mon, May 11, 2020 at 01:06:09PM +0200, Ricardo Cañuelo wrote:
> hi3660-hikey960.dts:
> Define a 'ports' node for 'adv7533: adv7533@39' and the
> 'adi,dsi-lanes' property to make it compliant with the adi,adv7533 DT
> binding.
>
> This fills the requirements to meet the binding requirements,
> remote endpoints are not defined.
>
> hi6220-hikey.dts:
> Change property name s/pd-gpio/pd-gpios, gpio properties should be
> plural. This is just a cosmetic change.
>
> Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts | 11 +++++++++++
> arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 2 +-
> 2 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
> index e035cf195b19..8c4bfbaf3a80 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
> +++ b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
> @@ -530,6 +530,17 @@
> status = "ok";
> compatible = "adi,adv7533";
> reg = <0x39>;
> + adi,dsi-lanes = <4>;
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port@0 {
> + reg = <0>;
> + };
> + port@1 {
> + reg = <1>;
> + };
> + };
> };
> };
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
> index c14205cd6bf5..3e47150c05ec 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
> +++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
> @@ -516,7 +516,7 @@
> reg = <0x39>;
> interrupt-parent = <&gpio1>;
> interrupts = <1 2>;
> - pd-gpio = <&gpio0 4 0>;
> + pd-gpios = <&gpio0 4 0>;
> adi,dsi-lanes = <4>;
> #sound-dai-cells = <0>;
>
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 66+ messages in thread* Re: [PATCH v2 4/6] arm64: dts: hisilicon: hikey: fixes to comply with adi,adv7533 DT binding
@ 2020-05-14 1:37 ` Laurent Pinchart
0 siblings, 0 replies; 66+ messages in thread
From: Laurent Pinchart @ 2020-05-14 1:37 UTC (permalink / raw)
To: Ricardo Cañuelo
Cc: devicetree, geert+renesas, xuwei5, robh+dt, kernel, linux-arm-kernel
Hi Ricardo,
Thank you for the patch.
On Mon, May 11, 2020 at 01:06:09PM +0200, Ricardo Cañuelo wrote:
> hi3660-hikey960.dts:
> Define a 'ports' node for 'adv7533: adv7533@39' and the
> 'adi,dsi-lanes' property to make it compliant with the adi,adv7533 DT
> binding.
>
> This fills the requirements to meet the binding requirements,
> remote endpoints are not defined.
>
> hi6220-hikey.dts:
> Change property name s/pd-gpio/pd-gpios, gpio properties should be
> plural. This is just a cosmetic change.
>
> Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts | 11 +++++++++++
> arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 2 +-
> 2 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
> index e035cf195b19..8c4bfbaf3a80 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
> +++ b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
> @@ -530,6 +530,17 @@
> status = "ok";
> compatible = "adi,adv7533";
> reg = <0x39>;
> + adi,dsi-lanes = <4>;
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port@0 {
> + reg = <0>;
> + };
> + port@1 {
> + reg = <1>;
> + };
> + };
> };
> };
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
> index c14205cd6bf5..3e47150c05ec 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
> +++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
> @@ -516,7 +516,7 @@
> reg = <0x39>;
> interrupt-parent = <&gpio1>;
> interrupts = <1 2>;
> - pd-gpio = <&gpio0 4 0>;
> + pd-gpios = <&gpio0 4 0>;
> adi,dsi-lanes = <4>;
> #sound-dai-cells = <0>;
>
--
Regards,
Laurent Pinchart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCH v2 4/6] arm64: dts: hisilicon: hikey: fixes to comply with adi, adv7533 DT binding
2020-05-11 11:06 ` [PATCH v2 4/6] arm64: dts: hisilicon: hikey: fixes to comply with adi, adv7533 " Ricardo Cañuelo
@ 2020-08-04 20:57 ` John Stultz
-1 siblings, 0 replies; 66+ messages in thread
From: John Stultz @ 2020-08-04 20:57 UTC (permalink / raw)
To: Ricardo Cañuelo
Cc: Laurent Pinchart,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Geert Uytterhoeven, Wei Xu, Rob Herring, kernel,
linux-arm-kernel, Mauro Carvalho Chehab
On Mon, May 11, 2020 at 4:07 AM Ricardo Cañuelo
<ricardo.canuelo@collabora.com> wrote:
>
> hi3660-hikey960.dts:
> Define a 'ports' node for 'adv7533: adv7533@39' and the
> 'adi,dsi-lanes' property to make it compliant with the adi,adv7533 DT
> binding.
>
> This fills the requirements to meet the binding requirements,
> remote endpoints are not defined.
>
> hi6220-hikey.dts:
> Change property name s/pd-gpio/pd-gpios, gpio properties should be
> plural. This is just a cosmetic change.
>
> Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
As a heads up.
So this change sounds sane, but I just bisected it down as the cause
of a regression on HiKey960 where the adv7511 driver doesn't probe.
I'll dig a bit more on what is going on (the DRM driver is still out
of tree, so maybe the DTS bits for that are not quite right?), but if
you have any suggestions, I'll give those a try.
If anyone is curious, my latest patches for the board is here:
https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/hikey960-mainline-WIP&id=4e6cefcc9bc1c13a503fdcb3768b3fd6479d8655
thanks
-john
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCH v2 4/6] arm64: dts: hisilicon: hikey: fixes to comply with adi, adv7533 DT binding
@ 2020-08-04 20:57 ` John Stultz
0 siblings, 0 replies; 66+ messages in thread
From: John Stultz @ 2020-08-04 20:57 UTC (permalink / raw)
To: Ricardo Cañuelo
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Geert Uytterhoeven, Mauro Carvalho Chehab, Wei Xu, Rob Herring,
Laurent Pinchart, kernel, linux-arm-kernel
On Mon, May 11, 2020 at 4:07 AM Ricardo Cañuelo
<ricardo.canuelo@collabora.com> wrote:
>
> hi3660-hikey960.dts:
> Define a 'ports' node for 'adv7533: adv7533@39' and the
> 'adi,dsi-lanes' property to make it compliant with the adi,adv7533 DT
> binding.
>
> This fills the requirements to meet the binding requirements,
> remote endpoints are not defined.
>
> hi6220-hikey.dts:
> Change property name s/pd-gpio/pd-gpios, gpio properties should be
> plural. This is just a cosmetic change.
>
> Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
As a heads up.
So this change sounds sane, but I just bisected it down as the cause
of a regression on HiKey960 where the adv7511 driver doesn't probe.
I'll dig a bit more on what is going on (the DRM driver is still out
of tree, so maybe the DTS bits for that are not quite right?), but if
you have any suggestions, I'll give those a try.
If anyone is curious, my latest patches for the board is here:
https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/hikey960-mainline-WIP&id=4e6cefcc9bc1c13a503fdcb3768b3fd6479d8655
thanks
-john
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCH v2 4/6] arm64: dts: hisilicon: hikey: fixes to comply with adi, adv7533 DT binding
2020-08-04 20:57 ` John Stultz
@ 2020-08-04 21:24 ` John Stultz
-1 siblings, 0 replies; 66+ messages in thread
From: John Stultz @ 2020-08-04 21:24 UTC (permalink / raw)
To: Ricardo Cañuelo
Cc: Laurent Pinchart,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Geert Uytterhoeven, Wei Xu, Rob Herring, kernel,
linux-arm-kernel, Mauro Carvalho Chehab
On Tue, Aug 4, 2020 at 1:57 PM John Stultz <john.stultz@linaro.org> wrote:
>
> On Mon, May 11, 2020 at 4:07 AM Ricardo Cañuelo
> <ricardo.canuelo@collabora.com> wrote:
> >
> > hi3660-hikey960.dts:
> > Define a 'ports' node for 'adv7533: adv7533@39' and the
> > 'adi,dsi-lanes' property to make it compliant with the adi,adv7533 DT
> > binding.
> >
> > This fills the requirements to meet the binding requirements,
> > remote endpoints are not defined.
> >
> > hi6220-hikey.dts:
> > Change property name s/pd-gpio/pd-gpios, gpio properties should be
> > plural. This is just a cosmetic change.
> >
> > Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
>
> As a heads up.
> So this change sounds sane, but I just bisected it down as the cause
> of a regression on HiKey960 where the adv7511 driver doesn't probe.
>
> I'll dig a bit more on what is going on (the DRM driver is still out
> of tree, so maybe the DTS bits for that are not quite right?), but if
> you have any suggestions, I'll give those a try.
Yes. It ends up the DRM driver dts changes were being done in the
wrong file so it was adding adv7511 bits in the dtsi, which were then
being overridden by your tweak. I'll fixup the pending DRM driver dts
bits. Apologies for the noise.
thanks
-john
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCH v2 4/6] arm64: dts: hisilicon: hikey: fixes to comply with adi, adv7533 DT binding
@ 2020-08-04 21:24 ` John Stultz
0 siblings, 0 replies; 66+ messages in thread
From: John Stultz @ 2020-08-04 21:24 UTC (permalink / raw)
To: Ricardo Cañuelo
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Geert Uytterhoeven, Mauro Carvalho Chehab, Wei Xu, Rob Herring,
Laurent Pinchart, kernel, linux-arm-kernel
On Tue, Aug 4, 2020 at 1:57 PM John Stultz <john.stultz@linaro.org> wrote:
>
> On Mon, May 11, 2020 at 4:07 AM Ricardo Cañuelo
> <ricardo.canuelo@collabora.com> wrote:
> >
> > hi3660-hikey960.dts:
> > Define a 'ports' node for 'adv7533: adv7533@39' and the
> > 'adi,dsi-lanes' property to make it compliant with the adi,adv7533 DT
> > binding.
> >
> > This fills the requirements to meet the binding requirements,
> > remote endpoints are not defined.
> >
> > hi6220-hikey.dts:
> > Change property name s/pd-gpio/pd-gpios, gpio properties should be
> > plural. This is just a cosmetic change.
> >
> > Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
>
> As a heads up.
> So this change sounds sane, but I just bisected it down as the cause
> of a regression on HiKey960 where the adv7511 driver doesn't probe.
>
> I'll dig a bit more on what is going on (the DRM driver is still out
> of tree, so maybe the DTS bits for that are not quite right?), but if
> you have any suggestions, I'll give those a try.
Yes. It ends up the DRM driver dts changes were being done in the
wrong file so it was adding adv7511 bits in the dtsi, which were then
being overridden by your tweak. I'll fixup the pending DRM driver dts
bits. Apologies for the noise.
thanks
-john
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCH v2 5/6] ARM: dts: iwg20d-q7-dbcm-ca: remove unneeded properties in hdmi@39
2020-05-11 11:06 ` Ricardo Cañuelo
@ 2020-05-11 11:06 ` Ricardo Cañuelo
-1 siblings, 0 replies; 66+ messages in thread
From: Ricardo Cañuelo @ 2020-05-11 11:06 UTC (permalink / raw)
To: laurent.pinchart
Cc: kernel, devicetree, linux-arm-kernel, geert+renesas, robh+dt, xuwei5
Remove the adi,input-style and adi,input-justification properties of
hdmi@39 to make it compliant with the "adi,adv7511w" DT binding.
Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
---
arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi b/arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi
index ede2e0c999b1..e10f99278c77 100644
--- a/arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi
+++ b/arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi
@@ -72,8 +72,6 @@
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
adi,input-clock = "1x";
- adi,input-style = <1>;
- adi,input-justification = "evenly";
ports {
#address-cells = <1>;
--
2.18.0
^ permalink raw reply related [flat|nested] 66+ messages in thread* [PATCH v2 5/6] ARM: dts: iwg20d-q7-dbcm-ca: remove unneeded properties in hdmi@39
@ 2020-05-11 11:06 ` Ricardo Cañuelo
0 siblings, 0 replies; 66+ messages in thread
From: Ricardo Cañuelo @ 2020-05-11 11:06 UTC (permalink / raw)
To: laurent.pinchart
Cc: devicetree, geert+renesas, xuwei5, robh+dt, kernel, linux-arm-kernel
Remove the adi,input-style and adi,input-justification properties of
hdmi@39 to make it compliant with the "adi,adv7511w" DT binding.
Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
---
arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi b/arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi
index ede2e0c999b1..e10f99278c77 100644
--- a/arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi
+++ b/arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi
@@ -72,8 +72,6 @@
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
adi,input-clock = "1x";
- adi,input-style = <1>;
- adi,input-justification = "evenly";
ports {
#address-cells = <1>;
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 66+ messages in thread* Re: [PATCH v2 5/6] ARM: dts: iwg20d-q7-dbcm-ca: remove unneeded properties in hdmi@39
2020-05-11 11:06 ` Ricardo Cañuelo
@ 2020-05-11 11:52 ` Geert Uytterhoeven
-1 siblings, 0 replies; 66+ messages in thread
From: Geert Uytterhoeven @ 2020-05-11 11:52 UTC (permalink / raw)
To: Ricardo Cañuelo
Cc: Laurent Pinchart, Collabora Kernel ML,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, Rob Herring, Wei Xu
On Mon, May 11, 2020 at 1:06 PM Ricardo Cañuelo
<ricardo.canuelo@collabora.com> wrote:
> Remove the adi,input-style and adi,input-justification properties of
> hdmi@39 to make it compliant with the "adi,adv7511w" DT binding.
>
> Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 66+ messages in thread* Re: [PATCH v2 5/6] ARM: dts: iwg20d-q7-dbcm-ca: remove unneeded properties in hdmi@39
@ 2020-05-11 11:52 ` Geert Uytterhoeven
0 siblings, 0 replies; 66+ messages in thread
From: Geert Uytterhoeven @ 2020-05-11 11:52 UTC (permalink / raw)
To: Ricardo Cañuelo
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Wei Xu, Rob Herring, Laurent Pinchart, Collabora Kernel ML,
Linux ARM
On Mon, May 11, 2020 at 1:06 PM Ricardo Cañuelo
<ricardo.canuelo@collabora.com> wrote:
> Remove the adi,input-style and adi,input-justification properties of
> hdmi@39 to make it compliant with the "adi,adv7511w" DT binding.
>
> Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCH v2 5/6] ARM: dts: iwg20d-q7-dbcm-ca: remove unneeded properties in hdmi@39
2020-05-11 11:06 ` Ricardo Cañuelo
@ 2020-05-14 1:37 ` Laurent Pinchart
-1 siblings, 0 replies; 66+ messages in thread
From: Laurent Pinchart @ 2020-05-14 1:37 UTC (permalink / raw)
To: Ricardo Cañuelo
Cc: kernel, devicetree, linux-arm-kernel, geert+renesas, robh+dt, xuwei5
Hi Ricardo,
Thank you for the patch.
On Mon, May 11, 2020 at 01:06:10PM +0200, Ricardo Cañuelo wrote:
> Remove the adi,input-style and adi,input-justification properties of
> hdmi@39 to make it compliant with the "adi,adv7511w" DT binding.
>
> Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi b/arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi
> index ede2e0c999b1..e10f99278c77 100644
> --- a/arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi
> +++ b/arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi
> @@ -72,8 +72,6 @@
> adi,input-depth = <8>;
> adi,input-colorspace = "rgb";
> adi,input-clock = "1x";
> - adi,input-style = <1>;
> - adi,input-justification = "evenly";
>
> ports {
> #address-cells = <1>;
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 66+ messages in thread* Re: [PATCH v2 5/6] ARM: dts: iwg20d-q7-dbcm-ca: remove unneeded properties in hdmi@39
@ 2020-05-14 1:37 ` Laurent Pinchart
0 siblings, 0 replies; 66+ messages in thread
From: Laurent Pinchart @ 2020-05-14 1:37 UTC (permalink / raw)
To: Ricardo Cañuelo
Cc: devicetree, geert+renesas, xuwei5, robh+dt, kernel, linux-arm-kernel
Hi Ricardo,
Thank you for the patch.
On Mon, May 11, 2020 at 01:06:10PM +0200, Ricardo Cañuelo wrote:
> Remove the adi,input-style and adi,input-justification properties of
> hdmi@39 to make it compliant with the "adi,adv7511w" DT binding.
>
> Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi b/arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi
> index ede2e0c999b1..e10f99278c77 100644
> --- a/arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi
> +++ b/arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi
> @@ -72,8 +72,6 @@
> adi,input-depth = <8>;
> adi,input-colorspace = "rgb";
> adi,input-clock = "1x";
> - adi,input-style = <1>;
> - adi,input-justification = "evenly";
>
> ports {
> #address-cells = <1>;
--
Regards,
Laurent Pinchart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCH v2 6/6] dt-bindings: drm: bridge: adi,adv7511.txt: convert to yaml
2020-05-11 11:06 ` Ricardo Cañuelo
@ 2020-05-11 11:06 ` Ricardo Cañuelo
-1 siblings, 0 replies; 66+ messages in thread
From: Ricardo Cañuelo @ 2020-05-11 11:06 UTC (permalink / raw)
To: laurent.pinchart
Cc: kernel, devicetree, linux-arm-kernel, geert+renesas, robh+dt, xuwei5
Convert the ADV7511/11w/13/33/35 DT bindings to json-schema. The
original binding has been split into two files: adi,adv7511.yaml for
ADV7511/11W/13 and adi,adv7533.yaml for ADV7533/35.
Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
---
.../bindings/display/bridge/adi,adv7511.txt | 143 -----------
.../bindings/display/bridge/adi,adv7511.yaml | 230 ++++++++++++++++++
.../bindings/display/bridge/adi,adv7533.yaml | 166 +++++++++++++
3 files changed, 396 insertions(+), 143 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
create mode 100644 Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml
create mode 100644 Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml
diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
deleted file mode 100644
index 659523f538bf..000000000000
--- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
+++ /dev/null
@@ -1,143 +0,0 @@
-Analog Devices ADV7511(W)/13/33/35 HDMI Encoders
-------------------------------------------------
-
-The ADV7511, ADV7511W, ADV7513, ADV7533 and ADV7535 are HDMI audio and video
-transmitters compatible with HDMI 1.4 and DVI 1.0. They support color space
-conversion, S/PDIF, CEC and HDCP. ADV7533/5 supports the DSI interface for input
-pixels, while the others support RGB interface.
-
-Required properties:
-
-- compatible: Should be one of:
- "adi,adv7511"
- "adi,adv7511w"
- "adi,adv7513"
- "adi,adv7533"
- "adi,adv7535"
-
-- reg: I2C slave addresses
- The ADV7511 internal registers are split into four pages exposed through
- different I2C addresses, creating four register maps. Each map has it own
- I2C address and acts as a standard slave device on the I2C bus. The main
- address is mandatory, others are optional and revert to defaults if not
- specified.
-
-
-The ADV7511 supports a large number of input data formats that differ by their
-color depth, color format, clock mode, bit justification and random
-arrangement of components on the data bus. The combination of the following
-properties describe the input and map directly to the video input tables of the
-ADV7511 datasheet that document all the supported combinations.
-
-- adi,input-depth: Number of bits per color component at the input (8, 10 or
- 12).
-- adi,input-colorspace: The input color space, one of "rgb", "yuv422" or
- "yuv444".
-- adi,input-clock: The input clock type, one of "1x" (one clock cycle per
- pixel), "2x" (two clock cycles per pixel), "ddr" (one clock cycle per pixel,
- data driven on both edges).
-
-The following input format properties are required except in "rgb 1x" and
-"yuv444 1x" modes, in which case they must not be specified.
-
-- adi,input-style: The input components arrangement variant (1, 2 or 3), as
- listed in the input format tables in the datasheet.
-- adi,input-justification: The input bit justification ("left", "evenly",
- "right").
-
-- avdd-supply: A 1.8V supply that powers up the AVDD pin on the chip.
-- dvdd-supply: A 1.8V supply that powers up the DVDD pin on the chip.
-- pvdd-supply: A 1.8V supply that powers up the PVDD pin on the chip.
-- dvdd-3v-supply: A 3.3V supply that powers up the pin called DVDD_3V
- on the chip.
-- bgvdd-supply: A 1.8V supply that powers up the BGVDD pin. This is
- needed only for ADV7511.
-
-The following properties are required for ADV7533 and ADV7535:
-
-- adi,dsi-lanes: Number of DSI data lanes connected to the DSI host. It should
- be one of 1, 2, 3 or 4.
-- a2vdd-supply: 1.8V supply that powers up the A2VDD pin on the chip.
-- v3p3-supply: A 3.3V supply that powers up the V3P3 pin on the chip.
-- v1p2-supply: A supply that powers up the V1P2 pin on the chip. It can be
- either 1.2V or 1.8V for ADV7533 but only 1.8V for ADV7535.
-
-Optional properties:
-
-- interrupts: Specifier for the ADV7511 interrupt
-- pd-gpios: Specifier for the GPIO connected to the power down signal
-
-- adi,clock-delay: Video data clock delay relative to the pixel clock, in ps
- (-1200 ps .. 1600 ps). Defaults to no delay.
-- adi,embedded-sync: The input uses synchronization signals embedded in the
- data stream (similar to BT.656). Defaults to separate H/V synchronization
- signals.
-- adi,disable-timing-generator: Only for ADV7533 and ADV7535. Disables the
- internal timing generator. The chip will rely on the sync signals in the
- DSI data lanes, rather than generate its own timings for HDMI output.
-- clocks: from common clock binding: reference to the CEC clock.
-- clock-names: from common clock binding: must be "cec".
-- reg-names : Names of maps with programmable addresses.
- It can contain any map needing a non-default address.
- Possible maps names are : "main", "edid", "cec", "packet"
-
-Required nodes:
-
-The ADV7511 has two video ports. Their connections are modelled using the OF
-graph bindings specified in Documentation/devicetree/bindings/graph.txt.
-
-- Video port 0 for the RGB, YUV or DSI input. In the case of ADV7533/5, the
- remote endpoint phandle should be a reference to a valid mipi_dsi_host device
- node.
-- Video port 1 for the HDMI output
-- Audio port 2 for the HDMI audio input
-
-
-Example
--------
-
- adv7511w: hdmi@39 {
- compatible = "adi,adv7511w";
- /*
- * The EDID page will be accessible on address 0x66 on the I2C
- * bus. All other maps continue to use their default addresses.
- */
- reg = <0x39>, <0x66>;
- reg-names = "main", "edid";
- interrupt-parent = <&gpio3>;
- interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
- clocks = <&cec_clock>;
- clock-names = "cec";
-
- adi,input-depth = <8>;
- adi,input-colorspace = "rgb";
- adi,input-clock = "1x";
- adi,input-style = <1>;
- adi,input-justification = "evenly";
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
- adv7511w_in: endpoint {
- remote-endpoint = <&dpi_out>;
- };
- };
-
- port@1 {
- reg = <1>;
- adv7511_out: endpoint {
- remote-endpoint = <&hdmi_connector_in>;
- };
- };
-
- port@2 {
- reg = <2>;
- codec_endpoint: endpoint {
- remote-endpoint = <&i2s0_cpu_endpoint>;
- };
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml
new file mode 100644
index 000000000000..a306adba105f
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml
@@ -0,0 +1,233 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/adi,adv7511.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices ADV7511/11W/13 HDMI Encoders
+
+maintainers:
+ - Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+
+description: |
+ The ADV7511, ADV7511W and ADV7513 are HDMI audio and video
+ transmitters compatible with HDMI 1.4 and DVI 1.0. They support color
+ space conversion, S/PDIF, CEC and HDCP. They support RGB input
+ interface.
+
+properties:
+ compatible:
+ enum:
+ - adi,adv7511
+ - adi,adv7511w
+ - adi,adv7513
+
+ reg:
+ description: |
+ I2C slave addresses.
+
+ The ADV7511/11W/13 internal registers are split into four pages
+ exposed through different I2C addresses, creating four register
+ maps. Each map has it own I2C address and acts as a standard slave
+ device on the I2C bus. The main address is mandatory, others are
+ optional and revert to defaults if not specified.
+ minItems: 1
+ maxItems: 4
+
+ reg-names:
+ description:
+ Names of maps with programmable addresses. It can contain any map
+ needing a non-default address.
+ minItems: 1
+ items:
+ - const: main
+ - const: edid
+ - const: cec
+ - const: packet
+
+ clocks:
+ description: Reference to the CEC clock.
+ maxItems: 1
+
+ clock-names:
+ const: cec
+
+ interrupts:
+ maxItems: 1
+
+ pd-gpios:
+ description: GPIO connected to the power down signal.
+ maxItems: 1
+
+ avdd-supply:
+ description: A 1.8V supply that powers up the AVDD pin.
+
+ dvdd-supply:
+ description: A 1.8V supply that powers up the DVDD pin.
+
+ pvdd-supply:
+ description: A 1.8V supply that powers up the PVDD pin.
+
+ dvdd-3v-supply:
+ description: A 3.3V supply that powers up the DVDD_3V pin.
+
+ bgvdd-supply:
+ description: A 1.8V supply that powers up the BGVDD pin.
+
+ adi,input-depth:
+ description: Number of bits per color component at the input.
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32
+ - enum: [ 8, 10, 12 ]
+
+ adi,input-colorspace:
+ description: Input color space.
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/string
+ - enum: [ rgb, yuv422, yuv444 ]
+
+ adi,input-clock:
+ description: |
+ Input clock type.
+ "1x": one clock cycle per pixel
+ "2x": two clock cycles per pixel
+ "dd": one clock cycle per pixel, data driven on both edges
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/string
+ - enum: [ 1x, 2x, dd ]
+
+ adi,clock-delay:
+ description:
+ Video data clock delay relative to the pixel clock, in ps
+ (-1200ps .. 1600 ps).
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32
+ - default: 0
+
+ adi,embedded-sync:
+ description:
+ The input uses synchronization signals embedded in the data
+ stream (similar to BT.656). Defaults to 0 (separate H/V
+ synchronization signals).
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32
+ - enum: [ 0, 1 ]
+ - default: 0
+
+ adi,input-style:
+ description:
+ Input components arrangement variant as listed in the input
+ format tables in the datasheet.
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32
+ - enum: [ 1, 2, 3 ]
+
+ adi,input-justification:
+ description: Input bit justification.
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/string
+ - enum: [ left, evenly, right ]
+
+ ports:
+ description:
+ The ADV7511(W)/13 has two video ports and one audio port. This node
+ models their connections as documented in
+ Documentation/devicetree/bindings/media/video-interfaces.txt
+ Documentation/devicetree/bindings/graph.txt
+ type: object
+ properties:
+ port@0:
+ description: Video port for the RGB, YUV or DSI input.
+ type: object
+
+ port@1:
+ description: Video port for the HDMI output.
+ type: object
+
+ port@2:
+ description: Audio port for the HDMI output.
+ type: object
+
+# adi,input-colorspace and adi,input-clock are required except in
+# "rgb 1x" and "yuv444 1x" modes, in which case they must not be
+# specified.
+if:
+ not:
+ properties:
+ adi,input-colorspace:
+ contains:
+ enum: [ rgb, yuv444 ]
+ adi,input-clock:
+ contains:
+ const: 1x
+
+then:
+ required:
+ - adi,input-style
+ - adi,input-justification
+
+else:
+ properties:
+ adi,input-style: false
+ adi,input-justification: false
+
+
+required:
+ - compatible
+ - reg
+ - ports
+ - adi,input-depth
+ - adi,input-colorspace
+ - adi,input-clock
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ adv7511w: hdmi@39 {
+ compatible = "adi,adv7511w";
+ /*
+ * The EDID page will be accessible on address 0x66 on the I2C
+ * bus. All other maps continue to use their default addresses.
+ */
+ reg = <0x39>, <0x66>;
+ reg-names = "main", "edid";
+ interrupt-parent = <&gpio3>;
+ interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
+ clocks = <&cec_clock>;
+ clock-names = "cec";
+
+ adi,input-depth = <8>;
+ adi,input-colorspace = "yuv422";
+ adi,input-clock = "1x";
+
+ adi,input-style = <3>;
+ adi,input-justification = "right";
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ adv7511w_in: endpoint {
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ adv7511_out: endpoint {
+ remote-endpoint = <&hdmi_connector_in>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+ codec_endpoint: endpoint {
+ remote-endpoint = <&i2s0_cpu_endpoint>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml b/Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml
new file mode 100644
index 000000000000..dfcc63dfc5c5
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml
@@ -0,0 +1,166 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/adi,adv7533.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices ADV7533/35 HDMI Encoders
+
+maintainers:
+ - Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+
+description: |
+ The ADV7533 and ADV7535 are HDMI audio and video transmitters
+ compatible with HDMI 1.4 and DVI 1.0. They support color space
+ conversion, S/PDIF, CEC and HDCP. They support DSI for input pixels.
+
+properties:
+ compatible:
+ enum:
+ - adi,adv7533
+ - adi,adv7535
+
+ reg:
+ description: |
+ I2C slave addresses.
+
+ The ADV7533/35 internal registers are split into four pages
+ exposed through different I2C addresses, creating four register
+ maps. Each map has it own I2C address and acts as a standard slave
+ device on the I2C bus. The main address is mandatory, others are
+ optional and revert to defaults if not specified.
+ minItems: 1
+ maxItems: 4
+
+ reg-names:
+ description:
+ Names of maps with programmable addresses. It can contain any map
+ needing a non-default address.
+ minItems: 1
+ items:
+ - const: main
+ - const: edid
+ - const: cec
+ - const: packet
+
+ clocks:
+ description: Reference to the CEC clock.
+ maxItems: 1
+
+ clock-names:
+ const: cec
+
+ interrupts:
+ maxItems: 1
+
+ pd-gpios:
+ description: GPIO connected to the power down signal.
+ maxItems: 1
+
+ avdd-supply:
+ description: A 1.8V supply that powers up the AVDD pin.
+
+ dvdd-supply:
+ description: A 1.8V supply that powers up the DVDD pin.
+
+ pvdd-supply:
+ description: A 1.8V supply that powers up the PVDD pin.
+
+ a2vdd-supply:
+ description: A 1.8V supply that powers up the A2VDD pin.
+
+ v3p3-supply:
+ description: A 3.3V supply that powers up the V3P3 pin.
+
+ v1p2-supply:
+ description:
+ A supply that powers up the V1P2 pin. It can be either 1.2V
+ or 1.8V for ADV7533 but only 1.8V for ADV7535.
+
+ adi,disable-timing-generator:
+ description:
+ Disables the interal timing generator. The chip will rely on the
+ sync signals in the DSI data lanes, rather than generate its own
+ timings for HDMI output.
+ type: boolean
+
+ adi,dsi-lanes:
+ description: Number of DSI data lanes connected to the DSI host.
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32
+ - enum: [ 1, 2, 3, 4 ]
+
+ ports:
+ description:
+ The ADV7533/35 has two video ports and one audio port. This node
+ models their connections as documented in
+ Documentation/devicetree/bindings/media/video-interfaces.txt
+ Documentation/devicetree/bindings/graph.txt
+ type: object
+ properties:
+ port@0:
+ description:
+ Video port for the RGB, YUV or DSI input. The remote endpoint
+ phandle should be a reference to a valid mipi_dsi_host_device.
+ type: object
+
+ port@1:
+ description: Video port for the HDMI output.
+ type: object
+
+ port@2:
+ description: Audio port for the HDMI output.
+ type: object
+
+required:
+ - compatible
+ - reg
+ - ports
+ - adi,dsi-lanes
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ adv7533: hdmi@39 {
+ compatible = "adi,adv7533";
+ /*
+ * The EDID page will be accessible on address 0x66 on the I2C
+ * bus. All other maps continue to use their default addresses.
+ */
+ reg = <0x39>, <0x66>;
+ reg-names = "main", "edid";
+ interrupt-parent = <&gpio3>;
+ interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
+ clocks = <&cec_clock>;
+ clock-names = "cec";
+ adi,dsi-lanes = <4>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ adv7511w_in: endpoint {
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ adv7511_out: endpoint {
+ remote-endpoint = <&hdmi_connector_in>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+ codec_endpoint: endpoint {
+ remote-endpoint = <&i2s0_cpu_endpoint>;
+ };
+ };
+ };
+ };
+
+...
--
2.18.0
^ permalink raw reply related [flat|nested] 66+ messages in thread* [PATCH v2 6/6] dt-bindings: drm: bridge: adi, adv7511.txt: convert to yaml
@ 2020-05-11 11:06 ` Ricardo Cañuelo
0 siblings, 0 replies; 66+ messages in thread
From: Ricardo Cañuelo @ 2020-05-11 11:06 UTC (permalink / raw)
To: laurent.pinchart
Cc: devicetree, geert+renesas, xuwei5, robh+dt, kernel, linux-arm-kernel
Convert the ADV7511/11w/13/33/35 DT bindings to json-schema. The
original binding has been split into two files: adi,adv7511.yaml for
ADV7511/11W/13 and adi,adv7533.yaml for ADV7533/35.
Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
---
.../bindings/display/bridge/adi,adv7511.txt | 143 -----------
.../bindings/display/bridge/adi,adv7511.yaml | 230 ++++++++++++++++++
.../bindings/display/bridge/adi,adv7533.yaml | 166 +++++++++++++
3 files changed, 396 insertions(+), 143 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
create mode 100644 Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml
create mode 100644 Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml
diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
deleted file mode 100644
index 659523f538bf..000000000000
--- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
+++ /dev/null
@@ -1,143 +0,0 @@
-Analog Devices ADV7511(W)/13/33/35 HDMI Encoders
-------------------------------------------------
-
-The ADV7511, ADV7511W, ADV7513, ADV7533 and ADV7535 are HDMI audio and video
-transmitters compatible with HDMI 1.4 and DVI 1.0. They support color space
-conversion, S/PDIF, CEC and HDCP. ADV7533/5 supports the DSI interface for input
-pixels, while the others support RGB interface.
-
-Required properties:
-
-- compatible: Should be one of:
- "adi,adv7511"
- "adi,adv7511w"
- "adi,adv7513"
- "adi,adv7533"
- "adi,adv7535"
-
-- reg: I2C slave addresses
- The ADV7511 internal registers are split into four pages exposed through
- different I2C addresses, creating four register maps. Each map has it own
- I2C address and acts as a standard slave device on the I2C bus. The main
- address is mandatory, others are optional and revert to defaults if not
- specified.
-
-
-The ADV7511 supports a large number of input data formats that differ by their
-color depth, color format, clock mode, bit justification and random
-arrangement of components on the data bus. The combination of the following
-properties describe the input and map directly to the video input tables of the
-ADV7511 datasheet that document all the supported combinations.
-
-- adi,input-depth: Number of bits per color component at the input (8, 10 or
- 12).
-- adi,input-colorspace: The input color space, one of "rgb", "yuv422" or
- "yuv444".
-- adi,input-clock: The input clock type, one of "1x" (one clock cycle per
- pixel), "2x" (two clock cycles per pixel), "ddr" (one clock cycle per pixel,
- data driven on both edges).
-
-The following input format properties are required except in "rgb 1x" and
-"yuv444 1x" modes, in which case they must not be specified.
-
-- adi,input-style: The input components arrangement variant (1, 2 or 3), as
- listed in the input format tables in the datasheet.
-- adi,input-justification: The input bit justification ("left", "evenly",
- "right").
-
-- avdd-supply: A 1.8V supply that powers up the AVDD pin on the chip.
-- dvdd-supply: A 1.8V supply that powers up the DVDD pin on the chip.
-- pvdd-supply: A 1.8V supply that powers up the PVDD pin on the chip.
-- dvdd-3v-supply: A 3.3V supply that powers up the pin called DVDD_3V
- on the chip.
-- bgvdd-supply: A 1.8V supply that powers up the BGVDD pin. This is
- needed only for ADV7511.
-
-The following properties are required for ADV7533 and ADV7535:
-
-- adi,dsi-lanes: Number of DSI data lanes connected to the DSI host. It should
- be one of 1, 2, 3 or 4.
-- a2vdd-supply: 1.8V supply that powers up the A2VDD pin on the chip.
-- v3p3-supply: A 3.3V supply that powers up the V3P3 pin on the chip.
-- v1p2-supply: A supply that powers up the V1P2 pin on the chip. It can be
- either 1.2V or 1.8V for ADV7533 but only 1.8V for ADV7535.
-
-Optional properties:
-
-- interrupts: Specifier for the ADV7511 interrupt
-- pd-gpios: Specifier for the GPIO connected to the power down signal
-
-- adi,clock-delay: Video data clock delay relative to the pixel clock, in ps
- (-1200 ps .. 1600 ps). Defaults to no delay.
-- adi,embedded-sync: The input uses synchronization signals embedded in the
- data stream (similar to BT.656). Defaults to separate H/V synchronization
- signals.
-- adi,disable-timing-generator: Only for ADV7533 and ADV7535. Disables the
- internal timing generator. The chip will rely on the sync signals in the
- DSI data lanes, rather than generate its own timings for HDMI output.
-- clocks: from common clock binding: reference to the CEC clock.
-- clock-names: from common clock binding: must be "cec".
-- reg-names : Names of maps with programmable addresses.
- It can contain any map needing a non-default address.
- Possible maps names are : "main", "edid", "cec", "packet"
-
-Required nodes:
-
-The ADV7511 has two video ports. Their connections are modelled using the OF
-graph bindings specified in Documentation/devicetree/bindings/graph.txt.
-
-- Video port 0 for the RGB, YUV or DSI input. In the case of ADV7533/5, the
- remote endpoint phandle should be a reference to a valid mipi_dsi_host device
- node.
-- Video port 1 for the HDMI output
-- Audio port 2 for the HDMI audio input
-
-
-Example
--------
-
- adv7511w: hdmi@39 {
- compatible = "adi,adv7511w";
- /*
- * The EDID page will be accessible on address 0x66 on the I2C
- * bus. All other maps continue to use their default addresses.
- */
- reg = <0x39>, <0x66>;
- reg-names = "main", "edid";
- interrupt-parent = <&gpio3>;
- interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
- clocks = <&cec_clock>;
- clock-names = "cec";
-
- adi,input-depth = <8>;
- adi,input-colorspace = "rgb";
- adi,input-clock = "1x";
- adi,input-style = <1>;
- adi,input-justification = "evenly";
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
- adv7511w_in: endpoint {
- remote-endpoint = <&dpi_out>;
- };
- };
-
- port@1 {
- reg = <1>;
- adv7511_out: endpoint {
- remote-endpoint = <&hdmi_connector_in>;
- };
- };
-
- port@2 {
- reg = <2>;
- codec_endpoint: endpoint {
- remote-endpoint = <&i2s0_cpu_endpoint>;
- };
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml
new file mode 100644
index 000000000000..a306adba105f
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml
@@ -0,0 +1,233 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/adi,adv7511.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices ADV7511/11W/13 HDMI Encoders
+
+maintainers:
+ - Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+
+description: |
+ The ADV7511, ADV7511W and ADV7513 are HDMI audio and video
+ transmitters compatible with HDMI 1.4 and DVI 1.0. They support color
+ space conversion, S/PDIF, CEC and HDCP. They support RGB input
+ interface.
+
+properties:
+ compatible:
+ enum:
+ - adi,adv7511
+ - adi,adv7511w
+ - adi,adv7513
+
+ reg:
+ description: |
+ I2C slave addresses.
+
+ The ADV7511/11W/13 internal registers are split into four pages
+ exposed through different I2C addresses, creating four register
+ maps. Each map has it own I2C address and acts as a standard slave
+ device on the I2C bus. The main address is mandatory, others are
+ optional and revert to defaults if not specified.
+ minItems: 1
+ maxItems: 4
+
+ reg-names:
+ description:
+ Names of maps with programmable addresses. It can contain any map
+ needing a non-default address.
+ minItems: 1
+ items:
+ - const: main
+ - const: edid
+ - const: cec
+ - const: packet
+
+ clocks:
+ description: Reference to the CEC clock.
+ maxItems: 1
+
+ clock-names:
+ const: cec
+
+ interrupts:
+ maxItems: 1
+
+ pd-gpios:
+ description: GPIO connected to the power down signal.
+ maxItems: 1
+
+ avdd-supply:
+ description: A 1.8V supply that powers up the AVDD pin.
+
+ dvdd-supply:
+ description: A 1.8V supply that powers up the DVDD pin.
+
+ pvdd-supply:
+ description: A 1.8V supply that powers up the PVDD pin.
+
+ dvdd-3v-supply:
+ description: A 3.3V supply that powers up the DVDD_3V pin.
+
+ bgvdd-supply:
+ description: A 1.8V supply that powers up the BGVDD pin.
+
+ adi,input-depth:
+ description: Number of bits per color component at the input.
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32
+ - enum: [ 8, 10, 12 ]
+
+ adi,input-colorspace:
+ description: Input color space.
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/string
+ - enum: [ rgb, yuv422, yuv444 ]
+
+ adi,input-clock:
+ description: |
+ Input clock type.
+ "1x": one clock cycle per pixel
+ "2x": two clock cycles per pixel
+ "dd": one clock cycle per pixel, data driven on both edges
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/string
+ - enum: [ 1x, 2x, dd ]
+
+ adi,clock-delay:
+ description:
+ Video data clock delay relative to the pixel clock, in ps
+ (-1200ps .. 1600 ps).
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32
+ - default: 0
+
+ adi,embedded-sync:
+ description:
+ The input uses synchronization signals embedded in the data
+ stream (similar to BT.656). Defaults to 0 (separate H/V
+ synchronization signals).
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32
+ - enum: [ 0, 1 ]
+ - default: 0
+
+ adi,input-style:
+ description:
+ Input components arrangement variant as listed in the input
+ format tables in the datasheet.
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32
+ - enum: [ 1, 2, 3 ]
+
+ adi,input-justification:
+ description: Input bit justification.
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/string
+ - enum: [ left, evenly, right ]
+
+ ports:
+ description:
+ The ADV7511(W)/13 has two video ports and one audio port. This node
+ models their connections as documented in
+ Documentation/devicetree/bindings/media/video-interfaces.txt
+ Documentation/devicetree/bindings/graph.txt
+ type: object
+ properties:
+ port@0:
+ description: Video port for the RGB, YUV or DSI input.
+ type: object
+
+ port@1:
+ description: Video port for the HDMI output.
+ type: object
+
+ port@2:
+ description: Audio port for the HDMI output.
+ type: object
+
+# adi,input-colorspace and adi,input-clock are required except in
+# "rgb 1x" and "yuv444 1x" modes, in which case they must not be
+# specified.
+if:
+ not:
+ properties:
+ adi,input-colorspace:
+ contains:
+ enum: [ rgb, yuv444 ]
+ adi,input-clock:
+ contains:
+ const: 1x
+
+then:
+ required:
+ - adi,input-style
+ - adi,input-justification
+
+else:
+ properties:
+ adi,input-style: false
+ adi,input-justification: false
+
+
+required:
+ - compatible
+ - reg
+ - ports
+ - adi,input-depth
+ - adi,input-colorspace
+ - adi,input-clock
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ adv7511w: hdmi@39 {
+ compatible = "adi,adv7511w";
+ /*
+ * The EDID page will be accessible on address 0x66 on the I2C
+ * bus. All other maps continue to use their default addresses.
+ */
+ reg = <0x39>, <0x66>;
+ reg-names = "main", "edid";
+ interrupt-parent = <&gpio3>;
+ interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
+ clocks = <&cec_clock>;
+ clock-names = "cec";
+
+ adi,input-depth = <8>;
+ adi,input-colorspace = "yuv422";
+ adi,input-clock = "1x";
+
+ adi,input-style = <3>;
+ adi,input-justification = "right";
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ adv7511w_in: endpoint {
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ adv7511_out: endpoint {
+ remote-endpoint = <&hdmi_connector_in>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+ codec_endpoint: endpoint {
+ remote-endpoint = <&i2s0_cpu_endpoint>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml b/Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml
new file mode 100644
index 000000000000..dfcc63dfc5c5
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml
@@ -0,0 +1,166 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/adi,adv7533.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices ADV7533/35 HDMI Encoders
+
+maintainers:
+ - Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+
+description: |
+ The ADV7533 and ADV7535 are HDMI audio and video transmitters
+ compatible with HDMI 1.4 and DVI 1.0. They support color space
+ conversion, S/PDIF, CEC and HDCP. They support DSI for input pixels.
+
+properties:
+ compatible:
+ enum:
+ - adi,adv7533
+ - adi,adv7535
+
+ reg:
+ description: |
+ I2C slave addresses.
+
+ The ADV7533/35 internal registers are split into four pages
+ exposed through different I2C addresses, creating four register
+ maps. Each map has it own I2C address and acts as a standard slave
+ device on the I2C bus. The main address is mandatory, others are
+ optional and revert to defaults if not specified.
+ minItems: 1
+ maxItems: 4
+
+ reg-names:
+ description:
+ Names of maps with programmable addresses. It can contain any map
+ needing a non-default address.
+ minItems: 1
+ items:
+ - const: main
+ - const: edid
+ - const: cec
+ - const: packet
+
+ clocks:
+ description: Reference to the CEC clock.
+ maxItems: 1
+
+ clock-names:
+ const: cec
+
+ interrupts:
+ maxItems: 1
+
+ pd-gpios:
+ description: GPIO connected to the power down signal.
+ maxItems: 1
+
+ avdd-supply:
+ description: A 1.8V supply that powers up the AVDD pin.
+
+ dvdd-supply:
+ description: A 1.8V supply that powers up the DVDD pin.
+
+ pvdd-supply:
+ description: A 1.8V supply that powers up the PVDD pin.
+
+ a2vdd-supply:
+ description: A 1.8V supply that powers up the A2VDD pin.
+
+ v3p3-supply:
+ description: A 3.3V supply that powers up the V3P3 pin.
+
+ v1p2-supply:
+ description:
+ A supply that powers up the V1P2 pin. It can be either 1.2V
+ or 1.8V for ADV7533 but only 1.8V for ADV7535.
+
+ adi,disable-timing-generator:
+ description:
+ Disables the interal timing generator. The chip will rely on the
+ sync signals in the DSI data lanes, rather than generate its own
+ timings for HDMI output.
+ type: boolean
+
+ adi,dsi-lanes:
+ description: Number of DSI data lanes connected to the DSI host.
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32
+ - enum: [ 1, 2, 3, 4 ]
+
+ ports:
+ description:
+ The ADV7533/35 has two video ports and one audio port. This node
+ models their connections as documented in
+ Documentation/devicetree/bindings/media/video-interfaces.txt
+ Documentation/devicetree/bindings/graph.txt
+ type: object
+ properties:
+ port@0:
+ description:
+ Video port for the RGB, YUV or DSI input. The remote endpoint
+ phandle should be a reference to a valid mipi_dsi_host_device.
+ type: object
+
+ port@1:
+ description: Video port for the HDMI output.
+ type: object
+
+ port@2:
+ description: Audio port for the HDMI output.
+ type: object
+
+required:
+ - compatible
+ - reg
+ - ports
+ - adi,dsi-lanes
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ adv7533: hdmi@39 {
+ compatible = "adi,adv7533";
+ /*
+ * The EDID page will be accessible on address 0x66 on the I2C
+ * bus. All other maps continue to use their default addresses.
+ */
+ reg = <0x39>, <0x66>;
+ reg-names = "main", "edid";
+ interrupt-parent = <&gpio3>;
+ interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
+ clocks = <&cec_clock>;
+ clock-names = "cec";
+ adi,dsi-lanes = <4>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ adv7511w_in: endpoint {
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ adv7511_out: endpoint {
+ remote-endpoint = <&hdmi_connector_in>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+ codec_endpoint: endpoint {
+ remote-endpoint = <&i2s0_cpu_endpoint>;
+ };
+ };
+ };
+ };
+
+...
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 66+ messages in thread* Re: [PATCH v2 6/6] dt-bindings: drm: bridge: adi,adv7511.txt: convert to yaml
2020-05-11 11:06 ` [PATCH v2 6/6] dt-bindings: drm: bridge: adi, adv7511.txt: " Ricardo Cañuelo
@ 2020-05-14 1:54 ` Laurent Pinchart
-1 siblings, 0 replies; 66+ messages in thread
From: Laurent Pinchart @ 2020-05-14 1:54 UTC (permalink / raw)
To: Ricardo Cañuelo
Cc: kernel, devicetree, linux-arm-kernel, geert+renesas, robh+dt, xuwei5
Hi Ricardo,
Thank you for the patch.
On Mon, May 11, 2020 at 01:06:11PM +0200, Ricardo Cañuelo wrote:
> Convert the ADV7511/11w/13/33/35 DT bindings to json-schema. The
> original binding has been split into two files: adi,adv7511.yaml for
> ADV7511/11W/13 and adi,adv7533.yaml for ADV7533/35.
>
> Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
> ---
> .../bindings/display/bridge/adi,adv7511.txt | 143 -----------
> .../bindings/display/bridge/adi,adv7511.yaml | 230 ++++++++++++++++++
> .../bindings/display/bridge/adi,adv7533.yaml | 166 +++++++++++++
> 3 files changed, 396 insertions(+), 143 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
> create mode 100644 Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml
> create mode 100644 Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
> deleted file mode 100644
> index 659523f538bf..000000000000
> --- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
> +++ /dev/null
> @@ -1,143 +0,0 @@
> -Analog Devices ADV7511(W)/13/33/35 HDMI Encoders
> -------------------------------------------------
> -
> -The ADV7511, ADV7511W, ADV7513, ADV7533 and ADV7535 are HDMI audio and video
> -transmitters compatible with HDMI 1.4 and DVI 1.0. They support color space
> -conversion, S/PDIF, CEC and HDCP. ADV7533/5 supports the DSI interface for input
> -pixels, while the others support RGB interface.
> -
> -Required properties:
> -
> -- compatible: Should be one of:
> - "adi,adv7511"
> - "adi,adv7511w"
> - "adi,adv7513"
> - "adi,adv7533"
> - "adi,adv7535"
> -
> -- reg: I2C slave addresses
> - The ADV7511 internal registers are split into four pages exposed through
> - different I2C addresses, creating four register maps. Each map has it own
> - I2C address and acts as a standard slave device on the I2C bus. The main
> - address is mandatory, others are optional and revert to defaults if not
> - specified.
> -
> -
> -The ADV7511 supports a large number of input data formats that differ by their
> -color depth, color format, clock mode, bit justification and random
> -arrangement of components on the data bus. The combination of the following
> -properties describe the input and map directly to the video input tables of the
> -ADV7511 datasheet that document all the supported combinations.
> -
> -- adi,input-depth: Number of bits per color component at the input (8, 10 or
> - 12).
> -- adi,input-colorspace: The input color space, one of "rgb", "yuv422" or
> - "yuv444".
> -- adi,input-clock: The input clock type, one of "1x" (one clock cycle per
> - pixel), "2x" (two clock cycles per pixel), "ddr" (one clock cycle per pixel,
> - data driven on both edges).
> -
> -The following input format properties are required except in "rgb 1x" and
> -"yuv444 1x" modes, in which case they must not be specified.
> -
> -- adi,input-style: The input components arrangement variant (1, 2 or 3), as
> - listed in the input format tables in the datasheet.
> -- adi,input-justification: The input bit justification ("left", "evenly",
> - "right").
> -
> -- avdd-supply: A 1.8V supply that powers up the AVDD pin on the chip.
> -- dvdd-supply: A 1.8V supply that powers up the DVDD pin on the chip.
> -- pvdd-supply: A 1.8V supply that powers up the PVDD pin on the chip.
> -- dvdd-3v-supply: A 3.3V supply that powers up the pin called DVDD_3V
> - on the chip.
> -- bgvdd-supply: A 1.8V supply that powers up the BGVDD pin. This is
> - needed only for ADV7511.
> -
> -The following properties are required for ADV7533 and ADV7535:
> -
> -- adi,dsi-lanes: Number of DSI data lanes connected to the DSI host. It should
> - be one of 1, 2, 3 or 4.
> -- a2vdd-supply: 1.8V supply that powers up the A2VDD pin on the chip.
> -- v3p3-supply: A 3.3V supply that powers up the V3P3 pin on the chip.
> -- v1p2-supply: A supply that powers up the V1P2 pin on the chip. It can be
> - either 1.2V or 1.8V for ADV7533 but only 1.8V for ADV7535.
> -
> -Optional properties:
> -
> -- interrupts: Specifier for the ADV7511 interrupt
> -- pd-gpios: Specifier for the GPIO connected to the power down signal
> -
> -- adi,clock-delay: Video data clock delay relative to the pixel clock, in ps
> - (-1200 ps .. 1600 ps). Defaults to no delay.
> -- adi,embedded-sync: The input uses synchronization signals embedded in the
> - data stream (similar to BT.656). Defaults to separate H/V synchronization
> - signals.
> -- adi,disable-timing-generator: Only for ADV7533 and ADV7535. Disables the
> - internal timing generator. The chip will rely on the sync signals in the
> - DSI data lanes, rather than generate its own timings for HDMI output.
> -- clocks: from common clock binding: reference to the CEC clock.
> -- clock-names: from common clock binding: must be "cec".
> -- reg-names : Names of maps with programmable addresses.
> - It can contain any map needing a non-default address.
> - Possible maps names are : "main", "edid", "cec", "packet"
> -
> -Required nodes:
> -
> -The ADV7511 has two video ports. Their connections are modelled using the OF
> -graph bindings specified in Documentation/devicetree/bindings/graph.txt.
> -
> -- Video port 0 for the RGB, YUV or DSI input. In the case of ADV7533/5, the
> - remote endpoint phandle should be a reference to a valid mipi_dsi_host device
> - node.
> -- Video port 1 for the HDMI output
> -- Audio port 2 for the HDMI audio input
> -
> -
> -Example
> --------
> -
> - adv7511w: hdmi@39 {
> - compatible = "adi,adv7511w";
> - /*
> - * The EDID page will be accessible on address 0x66 on the I2C
> - * bus. All other maps continue to use their default addresses.
> - */
> - reg = <0x39>, <0x66>;
> - reg-names = "main", "edid";
> - interrupt-parent = <&gpio3>;
> - interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
> - clocks = <&cec_clock>;
> - clock-names = "cec";
> -
> - adi,input-depth = <8>;
> - adi,input-colorspace = "rgb";
> - adi,input-clock = "1x";
> - adi,input-style = <1>;
> - adi,input-justification = "evenly";
> -
> - ports {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - port@0 {
> - reg = <0>;
> - adv7511w_in: endpoint {
> - remote-endpoint = <&dpi_out>;
> - };
> - };
> -
> - port@1 {
> - reg = <1>;
> - adv7511_out: endpoint {
> - remote-endpoint = <&hdmi_connector_in>;
> - };
> - };
> -
> - port@2 {
> - reg = <2>;
> - codec_endpoint: endpoint {
> - remote-endpoint = <&i2s0_cpu_endpoint>;
> - };
> - };
> - };
> - };
> diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml
> new file mode 100644
> index 000000000000..a306adba105f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml
> @@ -0,0 +1,233 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/adi,adv7511.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Analog Devices ADV7511/11W/13 HDMI Encoders
> +
> +maintainers:
> + - Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> +
> +description: |
> + The ADV7511, ADV7511W and ADV7513 are HDMI audio and video
> + transmitters compatible with HDMI 1.4 and DVI 1.0. They support color
> + space conversion, S/PDIF, CEC and HDCP. They support RGB input
> + interface.
I would write the last sentence as "The transmitter input is parallel
RGB or YUV data." as YUV is also supported.
> +
> +properties:
> + compatible:
> + enum:
> + - adi,adv7511
> + - adi,adv7511w
> + - adi,adv7513
> +
> + reg:
> + description: |
> + I2C slave addresses.
> +
> + The ADV7511/11W/13 internal registers are split into four pages
> + exposed through different I2C addresses, creating four register
> + maps. Each map has it own I2C address and acts as a standard slave
> + device on the I2C bus. The main address is mandatory, others are
> + optional and revert to defaults if not specified.
> + minItems: 1
> + maxItems: 4
> +
> + reg-names:
> + description:
> + Names of maps with programmable addresses. It can contain any map
> + needing a non-default address.
> + minItems: 1
> + items:
> + - const: main
> + - const: edid
> + - const: cec
> + - const: packet
> +
> + clocks:
> + description: Reference to the CEC clock.
> + maxItems: 1
> +
> + clock-names:
> + const: cec
> +
> + interrupts:
> + maxItems: 1
> +
> + pd-gpios:
> + description: GPIO connected to the power down signal.
> + maxItems: 1
> +
> + avdd-supply:
> + description: A 1.8V supply that powers up the AVDD pin.
> +
> + dvdd-supply:
> + description: A 1.8V supply that powers up the DVDD pin.
> +
> + pvdd-supply:
> + description: A 1.8V supply that powers up the PVDD pin.
> +
> + dvdd-3v-supply:
> + description: A 3.3V supply that powers up the DVDD_3V pin.
> +
> + bgvdd-supply:
> + description: A 1.8V supply that powers up the BGVDD pin.
> +
> + adi,input-depth:
> + description: Number of bits per color component at the input.
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32
> + - enum: [ 8, 10, 12 ]
> +
> + adi,input-colorspace:
> + description: Input color space.
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/string
> + - enum: [ rgb, yuv422, yuv444 ]
Isn't string implied ? Can't you write
adi,input-colorspace:
description: Input color space.
enum: [ rgb, yuv422, yuv444 ]
Same for the other properties below.
> +
> + adi,input-clock:
> + description: |
> + Input clock type.
> + "1x": one clock cycle per pixel
> + "2x": two clock cycles per pixel
> + "dd": one clock cycle per pixel, data driven on both edges
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/string
> + - enum: [ 1x, 2x, dd ]
> +
> + adi,clock-delay:
> + description:
> + Video data clock delay relative to the pixel clock, in ps
> + (-1200ps .. 1600 ps).
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32
> + - default: 0
> +
> + adi,embedded-sync:
> + description:
> + The input uses synchronization signals embedded in the data
> + stream (similar to BT.656). Defaults to 0 (separate H/V
> + synchronization signals).
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32
> + - enum: [ 0, 1 ]
> + - default: 0
This be a boolean property (it is read as a bool by the driver, the
property being absent means false, the property being present means
true).
> +
> + adi,input-style:
> + description:
> + Input components arrangement variant as listed in the input
> + format tables in the datasheet.
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32
> + - enum: [ 1, 2, 3 ]
> +
> + adi,input-justification:
> + description: Input bit justification.
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/string
> + - enum: [ left, evenly, right ]
> +
> + ports:
> + description:
> + The ADV7511(W)/13 has two video ports and one audio port. This node
> + models their connections as documented in
> + Documentation/devicetree/bindings/media/video-interfaces.txt
> + Documentation/devicetree/bindings/graph.txt
> + type: object
> + properties:
> + port@0:
> + description: Video port for the RGB, YUV or DSI input.
s/RGB, YUV or DSI/RGB or YUV/
> + type: object
> +
> + port@1:
> + description: Video port for the HDMI output.
> + type: object
> +
> + port@2:
> + description: Audio port for the HDMI output.
> + type: object
> +
> +# adi,input-colorspace and adi,input-clock are required except in
> +# "rgb 1x" and "yuv444 1x" modes, in which case they must not be
> +# specified.
> +if:
> + not:
> + properties:
> + adi,input-colorspace:
> + contains:
> + enum: [ rgb, yuv444 ]
> + adi,input-clock:
> + contains:
> + const: 1x
As both properties take a single value, I think you can omit
"contains:".
> +
> +then:
> + required:
> + - adi,input-style
> + - adi,input-justification
> +
> +else:
> + properties:
> + adi,input-style: false
> + adi,input-justification: false
> +
> +
> +required:
> + - compatible
> + - reg
> + - ports
> + - adi,input-depth
> + - adi,input-colorspace
> + - adi,input-clock
Shouldn't the power supplies be required ?
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/irq.h>
> +
> + adv7511w: hdmi@39 {
> + compatible = "adi,adv7511w";
> + /*
> + * The EDID page will be accessible on address 0x66 on the I2C
> + * bus. All other maps continue to use their default addresses.
> + */
> + reg = <0x39>, <0x66>;
> + reg-names = "main", "edid";
> + interrupt-parent = <&gpio3>;
> + interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
> + clocks = <&cec_clock>;
> + clock-names = "cec";
> +
> + adi,input-depth = <8>;
> + adi,input-colorspace = "yuv422";
> + adi,input-clock = "1x";
> +
> + adi,input-style = <3>;
> + adi,input-justification = "right";
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + adv7511w_in: endpoint {
> + remote-endpoint = <&dpi_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + adv7511_out: endpoint {
> + remote-endpoint = <&hdmi_connector_in>;
> + };
> + };
> +
> + port@2 {
> + reg = <2>;
> + codec_endpoint: endpoint {
> + remote-endpoint = <&i2s0_cpu_endpoint>;
> + };
> + };
> + };
> + };
> +
> +...
> diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml b/Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml
> new file mode 100644
> index 000000000000..dfcc63dfc5c5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml
> @@ -0,0 +1,166 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/adi,adv7533.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Analog Devices ADV7533/35 HDMI Encoders
> +
> +maintainers:
> + - Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> +
> +description: |
> + The ADV7533 and ADV7535 are HDMI audio and video transmitters
> + compatible with HDMI 1.4 and DVI 1.0. They support color space
> + conversion, S/PDIF, CEC and HDCP. They support DSI for input pixels.
I would write the last sentence as "The transmitter input is MIPI DSI.".
> +
> +properties:
> + compatible:
> + enum:
> + - adi,adv7533
> + - adi,adv7535
> +
> + reg:
> + description: |
> + I2C slave addresses.
> +
> + The ADV7533/35 internal registers are split into four pages
> + exposed through different I2C addresses, creating four register
> + maps. Each map has it own I2C address and acts as a standard slave
> + device on the I2C bus. The main address is mandatory, others are
> + optional and revert to defaults if not specified.
> + minItems: 1
> + maxItems: 4
> +
> + reg-names:
> + description:
> + Names of maps with programmable addresses. It can contain any map
> + needing a non-default address.
> + minItems: 1
> + items:
> + - const: main
> + - const: edid
> + - const: cec
> + - const: packet
> +
> + clocks:
> + description: Reference to the CEC clock.
> + maxItems: 1
> +
> + clock-names:
> + const: cec
> +
> + interrupts:
> + maxItems: 1
> +
> + pd-gpios:
> + description: GPIO connected to the power down signal.
> + maxItems: 1
> +
> + avdd-supply:
> + description: A 1.8V supply that powers up the AVDD pin.
> +
> + dvdd-supply:
> + description: A 1.8V supply that powers up the DVDD pin.
> +
> + pvdd-supply:
> + description: A 1.8V supply that powers up the PVDD pin.
> +
> + a2vdd-supply:
> + description: A 1.8V supply that powers up the A2VDD pin.
> +
> + v3p3-supply:
> + description: A 3.3V supply that powers up the V3P3 pin.
> +
> + v1p2-supply:
> + description:
> + A supply that powers up the V1P2 pin. It can be either 1.2V
> + or 1.8V for ADV7533 but only 1.8V for ADV7535.
> +
> + adi,disable-timing-generator:
> + description:
> + Disables the interal timing generator. The chip will rely on the
s/interal/internal/
> + sync signals in the DSI data lanes, rather than generate its own
s/generate/generating/
> + timings for HDMI output.
> + type: boolean
> +
> + adi,dsi-lanes:
> + description: Number of DSI data lanes connected to the DSI host.
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32
> + - enum: [ 1, 2, 3, 4 ]
> +
> + ports:
> + description:
> + The ADV7533/35 has two video ports and one audio port. This node
> + models their connections as documented in
> + Documentation/devicetree/bindings/media/video-interfaces.txt
> + Documentation/devicetree/bindings/graph.txt
> + type: object
> + properties:
> + port@0:
> + description:
> + Video port for the RGB, YUV or DSI input. The remote endpoint
s/RGB, YUV or //
> + phandle should be a reference to a valid mipi_dsi_host_device.
> + type: object
> +
> + port@1:
> + description: Video port for the HDMI output.
> + type: object
> +
> + port@2:
> + description: Audio port for the HDMI output.
> + type: object
> +
> +required:
> + - compatible
> + - reg
> + - ports
> + - adi,dsi-lanes
Shouldn't the power supplies be required ?
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/irq.h>
> +
> + adv7533: hdmi@39 {
> + compatible = "adi,adv7533";
> + /*
> + * The EDID page will be accessible on address 0x66 on the I2C
> + * bus. All other maps continue to use their default addresses.
> + */
> + reg = <0x39>, <0x66>;
> + reg-names = "main", "edid";
> + interrupt-parent = <&gpio3>;
> + interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
> + clocks = <&cec_clock>;
> + clock-names = "cec";
> + adi,dsi-lanes = <4>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + adv7511w_in: endpoint {
> + remote-endpoint = <&dpi_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + adv7511_out: endpoint {
> + remote-endpoint = <&hdmi_connector_in>;
> + };
> + };
The name of the two endpoints doesn't match the adv7533. The remote
endpoint phandle for port 0 should have dsi in its name.
> +
> + port@2 {
> + reg = <2>;
> + codec_endpoint: endpoint {
> + remote-endpoint = <&i2s0_cpu_endpoint>;
> + };
> + };
> + };
> + };
> +
> +...
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 66+ messages in thread* Re: [PATCH v2 6/6] dt-bindings: drm: bridge: adi,adv7511.txt: convert to yaml
@ 2020-05-14 1:54 ` Laurent Pinchart
0 siblings, 0 replies; 66+ messages in thread
From: Laurent Pinchart @ 2020-05-14 1:54 UTC (permalink / raw)
To: Ricardo Cañuelo
Cc: devicetree, geert+renesas, xuwei5, robh+dt, kernel, linux-arm-kernel
Hi Ricardo,
Thank you for the patch.
On Mon, May 11, 2020 at 01:06:11PM +0200, Ricardo Cañuelo wrote:
> Convert the ADV7511/11w/13/33/35 DT bindings to json-schema. The
> original binding has been split into two files: adi,adv7511.yaml for
> ADV7511/11W/13 and adi,adv7533.yaml for ADV7533/35.
>
> Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
> ---
> .../bindings/display/bridge/adi,adv7511.txt | 143 -----------
> .../bindings/display/bridge/adi,adv7511.yaml | 230 ++++++++++++++++++
> .../bindings/display/bridge/adi,adv7533.yaml | 166 +++++++++++++
> 3 files changed, 396 insertions(+), 143 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
> create mode 100644 Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml
> create mode 100644 Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
> deleted file mode 100644
> index 659523f538bf..000000000000
> --- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
> +++ /dev/null
> @@ -1,143 +0,0 @@
> -Analog Devices ADV7511(W)/13/33/35 HDMI Encoders
> -------------------------------------------------
> -
> -The ADV7511, ADV7511W, ADV7513, ADV7533 and ADV7535 are HDMI audio and video
> -transmitters compatible with HDMI 1.4 and DVI 1.0. They support color space
> -conversion, S/PDIF, CEC and HDCP. ADV7533/5 supports the DSI interface for input
> -pixels, while the others support RGB interface.
> -
> -Required properties:
> -
> -- compatible: Should be one of:
> - "adi,adv7511"
> - "adi,adv7511w"
> - "adi,adv7513"
> - "adi,adv7533"
> - "adi,adv7535"
> -
> -- reg: I2C slave addresses
> - The ADV7511 internal registers are split into four pages exposed through
> - different I2C addresses, creating four register maps. Each map has it own
> - I2C address and acts as a standard slave device on the I2C bus. The main
> - address is mandatory, others are optional and revert to defaults if not
> - specified.
> -
> -
> -The ADV7511 supports a large number of input data formats that differ by their
> -color depth, color format, clock mode, bit justification and random
> -arrangement of components on the data bus. The combination of the following
> -properties describe the input and map directly to the video input tables of the
> -ADV7511 datasheet that document all the supported combinations.
> -
> -- adi,input-depth: Number of bits per color component at the input (8, 10 or
> - 12).
> -- adi,input-colorspace: The input color space, one of "rgb", "yuv422" or
> - "yuv444".
> -- adi,input-clock: The input clock type, one of "1x" (one clock cycle per
> - pixel), "2x" (two clock cycles per pixel), "ddr" (one clock cycle per pixel,
> - data driven on both edges).
> -
> -The following input format properties are required except in "rgb 1x" and
> -"yuv444 1x" modes, in which case they must not be specified.
> -
> -- adi,input-style: The input components arrangement variant (1, 2 or 3), as
> - listed in the input format tables in the datasheet.
> -- adi,input-justification: The input bit justification ("left", "evenly",
> - "right").
> -
> -- avdd-supply: A 1.8V supply that powers up the AVDD pin on the chip.
> -- dvdd-supply: A 1.8V supply that powers up the DVDD pin on the chip.
> -- pvdd-supply: A 1.8V supply that powers up the PVDD pin on the chip.
> -- dvdd-3v-supply: A 3.3V supply that powers up the pin called DVDD_3V
> - on the chip.
> -- bgvdd-supply: A 1.8V supply that powers up the BGVDD pin. This is
> - needed only for ADV7511.
> -
> -The following properties are required for ADV7533 and ADV7535:
> -
> -- adi,dsi-lanes: Number of DSI data lanes connected to the DSI host. It should
> - be one of 1, 2, 3 or 4.
> -- a2vdd-supply: 1.8V supply that powers up the A2VDD pin on the chip.
> -- v3p3-supply: A 3.3V supply that powers up the V3P3 pin on the chip.
> -- v1p2-supply: A supply that powers up the V1P2 pin on the chip. It can be
> - either 1.2V or 1.8V for ADV7533 but only 1.8V for ADV7535.
> -
> -Optional properties:
> -
> -- interrupts: Specifier for the ADV7511 interrupt
> -- pd-gpios: Specifier for the GPIO connected to the power down signal
> -
> -- adi,clock-delay: Video data clock delay relative to the pixel clock, in ps
> - (-1200 ps .. 1600 ps). Defaults to no delay.
> -- adi,embedded-sync: The input uses synchronization signals embedded in the
> - data stream (similar to BT.656). Defaults to separate H/V synchronization
> - signals.
> -- adi,disable-timing-generator: Only for ADV7533 and ADV7535. Disables the
> - internal timing generator. The chip will rely on the sync signals in the
> - DSI data lanes, rather than generate its own timings for HDMI output.
> -- clocks: from common clock binding: reference to the CEC clock.
> -- clock-names: from common clock binding: must be "cec".
> -- reg-names : Names of maps with programmable addresses.
> - It can contain any map needing a non-default address.
> - Possible maps names are : "main", "edid", "cec", "packet"
> -
> -Required nodes:
> -
> -The ADV7511 has two video ports. Their connections are modelled using the OF
> -graph bindings specified in Documentation/devicetree/bindings/graph.txt.
> -
> -- Video port 0 for the RGB, YUV or DSI input. In the case of ADV7533/5, the
> - remote endpoint phandle should be a reference to a valid mipi_dsi_host device
> - node.
> -- Video port 1 for the HDMI output
> -- Audio port 2 for the HDMI audio input
> -
> -
> -Example
> --------
> -
> - adv7511w: hdmi@39 {
> - compatible = "adi,adv7511w";
> - /*
> - * The EDID page will be accessible on address 0x66 on the I2C
> - * bus. All other maps continue to use their default addresses.
> - */
> - reg = <0x39>, <0x66>;
> - reg-names = "main", "edid";
> - interrupt-parent = <&gpio3>;
> - interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
> - clocks = <&cec_clock>;
> - clock-names = "cec";
> -
> - adi,input-depth = <8>;
> - adi,input-colorspace = "rgb";
> - adi,input-clock = "1x";
> - adi,input-style = <1>;
> - adi,input-justification = "evenly";
> -
> - ports {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - port@0 {
> - reg = <0>;
> - adv7511w_in: endpoint {
> - remote-endpoint = <&dpi_out>;
> - };
> - };
> -
> - port@1 {
> - reg = <1>;
> - adv7511_out: endpoint {
> - remote-endpoint = <&hdmi_connector_in>;
> - };
> - };
> -
> - port@2 {
> - reg = <2>;
> - codec_endpoint: endpoint {
> - remote-endpoint = <&i2s0_cpu_endpoint>;
> - };
> - };
> - };
> - };
> diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml
> new file mode 100644
> index 000000000000..a306adba105f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml
> @@ -0,0 +1,233 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/adi,adv7511.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Analog Devices ADV7511/11W/13 HDMI Encoders
> +
> +maintainers:
> + - Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> +
> +description: |
> + The ADV7511, ADV7511W and ADV7513 are HDMI audio and video
> + transmitters compatible with HDMI 1.4 and DVI 1.0. They support color
> + space conversion, S/PDIF, CEC and HDCP. They support RGB input
> + interface.
I would write the last sentence as "The transmitter input is parallel
RGB or YUV data." as YUV is also supported.
> +
> +properties:
> + compatible:
> + enum:
> + - adi,adv7511
> + - adi,adv7511w
> + - adi,adv7513
> +
> + reg:
> + description: |
> + I2C slave addresses.
> +
> + The ADV7511/11W/13 internal registers are split into four pages
> + exposed through different I2C addresses, creating four register
> + maps. Each map has it own I2C address and acts as a standard slave
> + device on the I2C bus. The main address is mandatory, others are
> + optional and revert to defaults if not specified.
> + minItems: 1
> + maxItems: 4
> +
> + reg-names:
> + description:
> + Names of maps with programmable addresses. It can contain any map
> + needing a non-default address.
> + minItems: 1
> + items:
> + - const: main
> + - const: edid
> + - const: cec
> + - const: packet
> +
> + clocks:
> + description: Reference to the CEC clock.
> + maxItems: 1
> +
> + clock-names:
> + const: cec
> +
> + interrupts:
> + maxItems: 1
> +
> + pd-gpios:
> + description: GPIO connected to the power down signal.
> + maxItems: 1
> +
> + avdd-supply:
> + description: A 1.8V supply that powers up the AVDD pin.
> +
> + dvdd-supply:
> + description: A 1.8V supply that powers up the DVDD pin.
> +
> + pvdd-supply:
> + description: A 1.8V supply that powers up the PVDD pin.
> +
> + dvdd-3v-supply:
> + description: A 3.3V supply that powers up the DVDD_3V pin.
> +
> + bgvdd-supply:
> + description: A 1.8V supply that powers up the BGVDD pin.
> +
> + adi,input-depth:
> + description: Number of bits per color component at the input.
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32
> + - enum: [ 8, 10, 12 ]
> +
> + adi,input-colorspace:
> + description: Input color space.
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/string
> + - enum: [ rgb, yuv422, yuv444 ]
Isn't string implied ? Can't you write
adi,input-colorspace:
description: Input color space.
enum: [ rgb, yuv422, yuv444 ]
Same for the other properties below.
> +
> + adi,input-clock:
> + description: |
> + Input clock type.
> + "1x": one clock cycle per pixel
> + "2x": two clock cycles per pixel
> + "dd": one clock cycle per pixel, data driven on both edges
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/string
> + - enum: [ 1x, 2x, dd ]
> +
> + adi,clock-delay:
> + description:
> + Video data clock delay relative to the pixel clock, in ps
> + (-1200ps .. 1600 ps).
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32
> + - default: 0
> +
> + adi,embedded-sync:
> + description:
> + The input uses synchronization signals embedded in the data
> + stream (similar to BT.656). Defaults to 0 (separate H/V
> + synchronization signals).
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32
> + - enum: [ 0, 1 ]
> + - default: 0
This be a boolean property (it is read as a bool by the driver, the
property being absent means false, the property being present means
true).
> +
> + adi,input-style:
> + description:
> + Input components arrangement variant as listed in the input
> + format tables in the datasheet.
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32
> + - enum: [ 1, 2, 3 ]
> +
> + adi,input-justification:
> + description: Input bit justification.
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/string
> + - enum: [ left, evenly, right ]
> +
> + ports:
> + description:
> + The ADV7511(W)/13 has two video ports and one audio port. This node
> + models their connections as documented in
> + Documentation/devicetree/bindings/media/video-interfaces.txt
> + Documentation/devicetree/bindings/graph.txt
> + type: object
> + properties:
> + port@0:
> + description: Video port for the RGB, YUV or DSI input.
s/RGB, YUV or DSI/RGB or YUV/
> + type: object
> +
> + port@1:
> + description: Video port for the HDMI output.
> + type: object
> +
> + port@2:
> + description: Audio port for the HDMI output.
> + type: object
> +
> +# adi,input-colorspace and adi,input-clock are required except in
> +# "rgb 1x" and "yuv444 1x" modes, in which case they must not be
> +# specified.
> +if:
> + not:
> + properties:
> + adi,input-colorspace:
> + contains:
> + enum: [ rgb, yuv444 ]
> + adi,input-clock:
> + contains:
> + const: 1x
As both properties take a single value, I think you can omit
"contains:".
> +
> +then:
> + required:
> + - adi,input-style
> + - adi,input-justification
> +
> +else:
> + properties:
> + adi,input-style: false
> + adi,input-justification: false
> +
> +
> +required:
> + - compatible
> + - reg
> + - ports
> + - adi,input-depth
> + - adi,input-colorspace
> + - adi,input-clock
Shouldn't the power supplies be required ?
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/irq.h>
> +
> + adv7511w: hdmi@39 {
> + compatible = "adi,adv7511w";
> + /*
> + * The EDID page will be accessible on address 0x66 on the I2C
> + * bus. All other maps continue to use their default addresses.
> + */
> + reg = <0x39>, <0x66>;
> + reg-names = "main", "edid";
> + interrupt-parent = <&gpio3>;
> + interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
> + clocks = <&cec_clock>;
> + clock-names = "cec";
> +
> + adi,input-depth = <8>;
> + adi,input-colorspace = "yuv422";
> + adi,input-clock = "1x";
> +
> + adi,input-style = <3>;
> + adi,input-justification = "right";
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + adv7511w_in: endpoint {
> + remote-endpoint = <&dpi_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + adv7511_out: endpoint {
> + remote-endpoint = <&hdmi_connector_in>;
> + };
> + };
> +
> + port@2 {
> + reg = <2>;
> + codec_endpoint: endpoint {
> + remote-endpoint = <&i2s0_cpu_endpoint>;
> + };
> + };
> + };
> + };
> +
> +...
> diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml b/Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml
> new file mode 100644
> index 000000000000..dfcc63dfc5c5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml
> @@ -0,0 +1,166 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/adi,adv7533.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Analog Devices ADV7533/35 HDMI Encoders
> +
> +maintainers:
> + - Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> +
> +description: |
> + The ADV7533 and ADV7535 are HDMI audio and video transmitters
> + compatible with HDMI 1.4 and DVI 1.0. They support color space
> + conversion, S/PDIF, CEC and HDCP. They support DSI for input pixels.
I would write the last sentence as "The transmitter input is MIPI DSI.".
> +
> +properties:
> + compatible:
> + enum:
> + - adi,adv7533
> + - adi,adv7535
> +
> + reg:
> + description: |
> + I2C slave addresses.
> +
> + The ADV7533/35 internal registers are split into four pages
> + exposed through different I2C addresses, creating four register
> + maps. Each map has it own I2C address and acts as a standard slave
> + device on the I2C bus. The main address is mandatory, others are
> + optional and revert to defaults if not specified.
> + minItems: 1
> + maxItems: 4
> +
> + reg-names:
> + description:
> + Names of maps with programmable addresses. It can contain any map
> + needing a non-default address.
> + minItems: 1
> + items:
> + - const: main
> + - const: edid
> + - const: cec
> + - const: packet
> +
> + clocks:
> + description: Reference to the CEC clock.
> + maxItems: 1
> +
> + clock-names:
> + const: cec
> +
> + interrupts:
> + maxItems: 1
> +
> + pd-gpios:
> + description: GPIO connected to the power down signal.
> + maxItems: 1
> +
> + avdd-supply:
> + description: A 1.8V supply that powers up the AVDD pin.
> +
> + dvdd-supply:
> + description: A 1.8V supply that powers up the DVDD pin.
> +
> + pvdd-supply:
> + description: A 1.8V supply that powers up the PVDD pin.
> +
> + a2vdd-supply:
> + description: A 1.8V supply that powers up the A2VDD pin.
> +
> + v3p3-supply:
> + description: A 3.3V supply that powers up the V3P3 pin.
> +
> + v1p2-supply:
> + description:
> + A supply that powers up the V1P2 pin. It can be either 1.2V
> + or 1.8V for ADV7533 but only 1.8V for ADV7535.
> +
> + adi,disable-timing-generator:
> + description:
> + Disables the interal timing generator. The chip will rely on the
s/interal/internal/
> + sync signals in the DSI data lanes, rather than generate its own
s/generate/generating/
> + timings for HDMI output.
> + type: boolean
> +
> + adi,dsi-lanes:
> + description: Number of DSI data lanes connected to the DSI host.
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32
> + - enum: [ 1, 2, 3, 4 ]
> +
> + ports:
> + description:
> + The ADV7533/35 has two video ports and one audio port. This node
> + models their connections as documented in
> + Documentation/devicetree/bindings/media/video-interfaces.txt
> + Documentation/devicetree/bindings/graph.txt
> + type: object
> + properties:
> + port@0:
> + description:
> + Video port for the RGB, YUV or DSI input. The remote endpoint
s/RGB, YUV or //
> + phandle should be a reference to a valid mipi_dsi_host_device.
> + type: object
> +
> + port@1:
> + description: Video port for the HDMI output.
> + type: object
> +
> + port@2:
> + description: Audio port for the HDMI output.
> + type: object
> +
> +required:
> + - compatible
> + - reg
> + - ports
> + - adi,dsi-lanes
Shouldn't the power supplies be required ?
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/irq.h>
> +
> + adv7533: hdmi@39 {
> + compatible = "adi,adv7533";
> + /*
> + * The EDID page will be accessible on address 0x66 on the I2C
> + * bus. All other maps continue to use their default addresses.
> + */
> + reg = <0x39>, <0x66>;
> + reg-names = "main", "edid";
> + interrupt-parent = <&gpio3>;
> + interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
> + clocks = <&cec_clock>;
> + clock-names = "cec";
> + adi,dsi-lanes = <4>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + adv7511w_in: endpoint {
> + remote-endpoint = <&dpi_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + adv7511_out: endpoint {
> + remote-endpoint = <&hdmi_connector_in>;
> + };
> + };
The name of the two endpoints doesn't match the adv7533. The remote
endpoint phandle for port 0 should have dsi in its name.
> +
> + port@2 {
> + reg = <2>;
> + codec_endpoint: endpoint {
> + remote-endpoint = <&i2s0_cpu_endpoint>;
> + };
> + };
> + };
> + };
> +
> +...
--
Regards,
Laurent Pinchart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 66+ messages in thread* Re: [PATCH v2 6/6] dt-bindings: drm: bridge: adi,adv7511.txt: convert to yaml
2020-05-14 1:54 ` Laurent Pinchart
@ 2020-05-14 9:36 ` Ricardo Cañuelo
-1 siblings, 0 replies; 66+ messages in thread
From: Ricardo Cañuelo @ 2020-05-14 9:36 UTC (permalink / raw)
To: Laurent Pinchart
Cc: kernel, devicetree, linux-arm-kernel, geert+renesas, robh+dt, xuwei5
Hi Laurent, thanks for the thorough review. Some comments below:
On jue 14-05-2020 04:54:12, Laurent Pinchart wrote:
> > +description: |
> > + The ADV7511, ADV7511W and ADV7513 are HDMI audio and video
> > + transmitters compatible with HDMI 1.4 and DVI 1.0. They support color
> > + space conversion, S/PDIF, CEC and HDCP. They support RGB input
> > + interface.
>
> I would write the last sentence as "The transmitter input is parallel
> RGB or YUV data." as YUV is also supported.
Ok.
> > + adi,input-colorspace:
> > + description: Input color space.
> > + allOf:
> > + - $ref: /schemas/types.yaml#/definitions/string
> > + - enum: [ rgb, yuv422, yuv444 ]
>
> Isn't string implied ? Can't you write
>
> adi,input-colorspace:
> description: Input color space.
> enum: [ rgb, yuv422, yuv444 ]
example-schema.yaml says that
Vendor specific properties have slightly different schema
requirements than common properties. They must have at least a type
definition and 'description'.
However, dt_binding_check doesn't seem to enforce this rule for string
properties, and I saw a couple of vendor-specific string properties in
other bindings that don't define the type either, so I'm going to follow
your suggestion but only for string properties, the rest need a type
definition.
I noticed I can remove the "allOf" keywords from these too.
> > + adi,embedded-sync:
> > + description:
> > + The input uses synchronization signals embedded in the data
> > + stream (similar to BT.656). Defaults to 0 (separate H/V
> > + synchronization signals).
> > + allOf:
> > + - $ref: /schemas/types.yaml#/definitions/uint32
> > + - enum: [ 0, 1 ]
> > + - default: 0
>
> This be a boolean property (it is read as a bool by the driver, the
> property being absent means false, the property being present means
> true).
You're completely right.
> > + ports:
> > + description:
> > + The ADV7511(W)/13 has two video ports and one audio port. This node
> > + models their connections as documented in
> > + Documentation/devicetree/bindings/media/video-interfaces.txt
> > + Documentation/devicetree/bindings/graph.txt
> > + type: object
> > + properties:
> > + port@0:
> > + description: Video port for the RGB, YUV or DSI input.
>
> s/RGB, YUV or DSI/RGB or YUV/
Ok.
> > +if:
> > + not:
> > + properties:
> > + adi,input-colorspace:
> > + contains:
> > + enum: [ rgb, yuv444 ]
> > + adi,input-clock:
> > + contains:
> > + const: 1x
>
> As both properties take a single value, I think you can omit
> "contains:".
I think it's required here, removing it makes the test fail.
> > +required:
> > + - compatible
> > + - reg
> > + - ports
> > + - adi,input-depth
> > + - adi,input-colorspace
> > + - adi,input-clock
>
> Shouldn't the power supplies be required ?
Good question. The original binding is not completely clear on
this. There's a "Required properties" section at the top that doesn't
include the supplies, the supplies block for the ADV7511/11w/13 looks
like a gray area in that regard, while the same block for ADV7533/35 is
more explicit in that they are required, and they are not listed in the
"Optional properties" section.
However, most of the DTs that use this binding don't define any
supplies. And AFAICT from looking at the code, regulator_get() will use
a dummy regulator and show a warning for every expected regulator that's
not defined in the DT.
If we want to be more strict and require the definition of all the
supplies, there will be many more DTs changes in the series, and I'm not
sure I'll be able to do that in a reasonable amount of time. I'm looking
at them and it's not always clear which regulators to use or if they are
even defined.
> > +description: |
> > + The ADV7533 and ADV7535 are HDMI audio and video transmitters
> > + compatible with HDMI 1.4 and DVI 1.0. They support color space
> > + conversion, S/PDIF, CEC and HDCP. They support DSI for input pixels.
>
> I would write the last sentence as "The transmitter input is MIPI DSI.".
>
> ...
>
> > + Disables the interal timing generator. The chip will rely on the
>
> s/interal/internal/
>
> > + sync signals in the DSI data lanes, rather than generate its own
>
> s/generate/generating/
>
> ...
>
> > + properties:
> > + port@0:
> > + description:
> > + Video port for the RGB, YUV or DSI input. The remote endpoint
>
> s/RGB, YUV or //
Ok.
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@0 {
> > + reg = <0>;
> > + adv7511w_in: endpoint {
> > + remote-endpoint = <&dpi_out>;
> > + };
> > + };
> > +
> > + port@1 {
> > + reg = <1>;
> > + adv7511_out: endpoint {
> > + remote-endpoint = <&hdmi_connector_in>;
> > + };
> > + };
>
> The name of the two endpoints doesn't match the adv7533. The remote
> endpoint phandle for port 0 should have dsi in its name.
Oops, thanks for catching these.
Cheers,
Ricardo
^ permalink raw reply [flat|nested] 66+ messages in thread* Re: [PATCH v2 6/6] dt-bindings: drm: bridge: adi,adv7511.txt: convert to yaml
@ 2020-05-14 9:36 ` Ricardo Cañuelo
0 siblings, 0 replies; 66+ messages in thread
From: Ricardo Cañuelo @ 2020-05-14 9:36 UTC (permalink / raw)
To: Laurent Pinchart
Cc: devicetree, geert+renesas, xuwei5, robh+dt, kernel, linux-arm-kernel
Hi Laurent, thanks for the thorough review. Some comments below:
On jue 14-05-2020 04:54:12, Laurent Pinchart wrote:
> > +description: |
> > + The ADV7511, ADV7511W and ADV7513 are HDMI audio and video
> > + transmitters compatible with HDMI 1.4 and DVI 1.0. They support color
> > + space conversion, S/PDIF, CEC and HDCP. They support RGB input
> > + interface.
>
> I would write the last sentence as "The transmitter input is parallel
> RGB or YUV data." as YUV is also supported.
Ok.
> > + adi,input-colorspace:
> > + description: Input color space.
> > + allOf:
> > + - $ref: /schemas/types.yaml#/definitions/string
> > + - enum: [ rgb, yuv422, yuv444 ]
>
> Isn't string implied ? Can't you write
>
> adi,input-colorspace:
> description: Input color space.
> enum: [ rgb, yuv422, yuv444 ]
example-schema.yaml says that
Vendor specific properties have slightly different schema
requirements than common properties. They must have at least a type
definition and 'description'.
However, dt_binding_check doesn't seem to enforce this rule for string
properties, and I saw a couple of vendor-specific string properties in
other bindings that don't define the type either, so I'm going to follow
your suggestion but only for string properties, the rest need a type
definition.
I noticed I can remove the "allOf" keywords from these too.
> > + adi,embedded-sync:
> > + description:
> > + The input uses synchronization signals embedded in the data
> > + stream (similar to BT.656). Defaults to 0 (separate H/V
> > + synchronization signals).
> > + allOf:
> > + - $ref: /schemas/types.yaml#/definitions/uint32
> > + - enum: [ 0, 1 ]
> > + - default: 0
>
> This be a boolean property (it is read as a bool by the driver, the
> property being absent means false, the property being present means
> true).
You're completely right.
> > + ports:
> > + description:
> > + The ADV7511(W)/13 has two video ports and one audio port. This node
> > + models their connections as documented in
> > + Documentation/devicetree/bindings/media/video-interfaces.txt
> > + Documentation/devicetree/bindings/graph.txt
> > + type: object
> > + properties:
> > + port@0:
> > + description: Video port for the RGB, YUV or DSI input.
>
> s/RGB, YUV or DSI/RGB or YUV/
Ok.
> > +if:
> > + not:
> > + properties:
> > + adi,input-colorspace:
> > + contains:
> > + enum: [ rgb, yuv444 ]
> > + adi,input-clock:
> > + contains:
> > + const: 1x
>
> As both properties take a single value, I think you can omit
> "contains:".
I think it's required here, removing it makes the test fail.
> > +required:
> > + - compatible
> > + - reg
> > + - ports
> > + - adi,input-depth
> > + - adi,input-colorspace
> > + - adi,input-clock
>
> Shouldn't the power supplies be required ?
Good question. The original binding is not completely clear on
this. There's a "Required properties" section at the top that doesn't
include the supplies, the supplies block for the ADV7511/11w/13 looks
like a gray area in that regard, while the same block for ADV7533/35 is
more explicit in that they are required, and they are not listed in the
"Optional properties" section.
However, most of the DTs that use this binding don't define any
supplies. And AFAICT from looking at the code, regulator_get() will use
a dummy regulator and show a warning for every expected regulator that's
not defined in the DT.
If we want to be more strict and require the definition of all the
supplies, there will be many more DTs changes in the series, and I'm not
sure I'll be able to do that in a reasonable amount of time. I'm looking
at them and it's not always clear which regulators to use or if they are
even defined.
> > +description: |
> > + The ADV7533 and ADV7535 are HDMI audio and video transmitters
> > + compatible with HDMI 1.4 and DVI 1.0. They support color space
> > + conversion, S/PDIF, CEC and HDCP. They support DSI for input pixels.
>
> I would write the last sentence as "The transmitter input is MIPI DSI.".
>
> ...
>
> > + Disables the interal timing generator. The chip will rely on the
>
> s/interal/internal/
>
> > + sync signals in the DSI data lanes, rather than generate its own
>
> s/generate/generating/
>
> ...
>
> > + properties:
> > + port@0:
> > + description:
> > + Video port for the RGB, YUV or DSI input. The remote endpoint
>
> s/RGB, YUV or //
Ok.
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@0 {
> > + reg = <0>;
> > + adv7511w_in: endpoint {
> > + remote-endpoint = <&dpi_out>;
> > + };
> > + };
> > +
> > + port@1 {
> > + reg = <1>;
> > + adv7511_out: endpoint {
> > + remote-endpoint = <&hdmi_connector_in>;
> > + };
> > + };
>
> The name of the two endpoints doesn't match the adv7533. The remote
> endpoint phandle for port 0 should have dsi in its name.
Oops, thanks for catching these.
Cheers,
Ricardo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 66+ messages in thread* Re: [PATCH v2 6/6] dt-bindings: drm: bridge: adi,adv7511.txt: convert to yaml
2020-05-14 9:36 ` Ricardo Cañuelo
@ 2020-05-14 15:22 ` Laurent Pinchart
-1 siblings, 0 replies; 66+ messages in thread
From: Laurent Pinchart @ 2020-05-14 15:22 UTC (permalink / raw)
To: Ricardo Cañuelo
Cc: kernel, devicetree, linux-arm-kernel, geert+renesas, robh+dt, xuwei5
Hi Ricardo,
On Thu, May 14, 2020 at 11:36:17AM +0200, Ricardo Cañuelo wrote:
> Hi Laurent, thanks for the thorough review. Some comments below:
>
> On jue 14-05-2020 04:54:12, Laurent Pinchart wrote:
> > > +description: |
> > > + The ADV7511, ADV7511W and ADV7513 are HDMI audio and video
> > > + transmitters compatible with HDMI 1.4 and DVI 1.0. They support color
> > > + space conversion, S/PDIF, CEC and HDCP. They support RGB input
> > > + interface.
> >
> > I would write the last sentence as "The transmitter input is parallel
> > RGB or YUV data." as YUV is also supported.
>
> Ok.
>
> > > + adi,input-colorspace:
> > > + description: Input color space.
> > > + allOf:
> > > + - $ref: /schemas/types.yaml#/definitions/string
> > > + - enum: [ rgb, yuv422, yuv444 ]
> >
> > Isn't string implied ? Can't you write
> >
> > adi,input-colorspace:
> > description: Input color space.
> > enum: [ rgb, yuv422, yuv444 ]
>
> example-schema.yaml says that
>
> Vendor specific properties have slightly different schema
> requirements than common properties. They must have at least a type
> definition and 'description'.
>
> However, dt_binding_check doesn't seem to enforce this rule for string
> properties, and I saw a couple of vendor-specific string properties in
> other bindings that don't define the type either, so I'm going to follow
> your suggestion but only for string properties, the rest need a type
> definition.
I'll defer to Rob to tell the law here :-)
> I noticed I can remove the "allOf" keywords from these too.
>
> > > + adi,embedded-sync:
> > > + description:
> > > + The input uses synchronization signals embedded in the data
> > > + stream (similar to BT.656). Defaults to 0 (separate H/V
> > > + synchronization signals).
> > > + allOf:
> > > + - $ref: /schemas/types.yaml#/definitions/uint32
> > > + - enum: [ 0, 1 ]
> > > + - default: 0
> >
> > This be a boolean property (it is read as a bool by the driver, the
> > property being absent means false, the property being present means
> > true).
>
> You're completely right.
>
> > > + ports:
> > > + description:
> > > + The ADV7511(W)/13 has two video ports and one audio port. This node
> > > + models their connections as documented in
> > > + Documentation/devicetree/bindings/media/video-interfaces.txt
> > > + Documentation/devicetree/bindings/graph.txt
> > > + type: object
> > > + properties:
> > > + port@0:
> > > + description: Video port for the RGB, YUV or DSI input.
> >
> > s/RGB, YUV or DSI/RGB or YUV/
>
> Ok.
>
> > > +if:
> > > + not:
> > > + properties:
> > > + adi,input-colorspace:
> > > + contains:
> > > + enum: [ rgb, yuv444 ]
> > > + adi,input-clock:
> > > + contains:
> > > + const: 1x
> >
> > As both properties take a single value, I think you can omit
> > "contains:".
>
> I think it's required here, removing it makes the test fail.
I thought the following could work:
if:
not:
properties:
adi,input-colorspace:
enum: [ rgb, yuv444 ]
adi,input-clock:
items:
- const: 1x
But no big deal, contains: is ok too.
> > > +required:
> > > + - compatible
> > > + - reg
> > > + - ports
> > > + - adi,input-depth
> > > + - adi,input-colorspace
> > > + - adi,input-clock
> >
> > Shouldn't the power supplies be required ?
>
> Good question. The original binding is not completely clear on
> this. There's a "Required properties" section at the top that doesn't
> include the supplies, the supplies block for the ADV7511/11w/13 looks
> like a gray area in that regard, while the same block for ADV7533/35 is
> more explicit in that they are required, and they are not listed in the
> "Optional properties" section.
>
> However, most of the DTs that use this binding don't define any
> supplies. And AFAICT from looking at the code, regulator_get() will use
> a dummy regulator and show a warning for every expected regulator that's
> not defined in the DT.
>
> If we want to be more strict and require the definition of all the
> supplies, there will be many more DTs changes in the series, and I'm not
> sure I'll be able to do that in a reasonable amount of time. I'm looking
> at them and it's not always clear which regulators to use or if they are
> even defined.
We can decouple the two though (I think). The bindings should reflect
what we consider right, and the dts files could be fixed on top.
> > > +description: |
> > > + The ADV7533 and ADV7535 are HDMI audio and video transmitters
> > > + compatible with HDMI 1.4 and DVI 1.0. They support color space
> > > + conversion, S/PDIF, CEC and HDCP. They support DSI for input pixels.
> >
> > I would write the last sentence as "The transmitter input is MIPI DSI.".
> >
> > ...
> >
> > > + Disables the interal timing generator. The chip will rely on the
> >
> > s/interal/internal/
> >
> > > + sync signals in the DSI data lanes, rather than generate its own
> >
> > s/generate/generating/
> >
> > ...
> >
> > > + properties:
> > > + port@0:
> > > + description:
> > > + Video port for the RGB, YUV or DSI input. The remote endpoint
> >
> > s/RGB, YUV or //
>
> Ok.
>
> > > + ports {
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + port@0 {
> > > + reg = <0>;
> > > + adv7511w_in: endpoint {
> > > + remote-endpoint = <&dpi_out>;
> > > + };
> > > + };
> > > +
> > > + port@1 {
> > > + reg = <1>;
> > > + adv7511_out: endpoint {
> > > + remote-endpoint = <&hdmi_connector_in>;
> > > + };
> > > + };
> >
> > The name of the two endpoints doesn't match the adv7533. The remote
> > endpoint phandle for port 0 should have dsi in its name.
>
> Oops, thanks for catching these.
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 66+ messages in thread* Re: [PATCH v2 6/6] dt-bindings: drm: bridge: adi,adv7511.txt: convert to yaml
@ 2020-05-14 15:22 ` Laurent Pinchart
0 siblings, 0 replies; 66+ messages in thread
From: Laurent Pinchart @ 2020-05-14 15:22 UTC (permalink / raw)
To: Ricardo Cañuelo
Cc: devicetree, geert+renesas, xuwei5, robh+dt, kernel, linux-arm-kernel
Hi Ricardo,
On Thu, May 14, 2020 at 11:36:17AM +0200, Ricardo Cañuelo wrote:
> Hi Laurent, thanks for the thorough review. Some comments below:
>
> On jue 14-05-2020 04:54:12, Laurent Pinchart wrote:
> > > +description: |
> > > + The ADV7511, ADV7511W and ADV7513 are HDMI audio and video
> > > + transmitters compatible with HDMI 1.4 and DVI 1.0. They support color
> > > + space conversion, S/PDIF, CEC and HDCP. They support RGB input
> > > + interface.
> >
> > I would write the last sentence as "The transmitter input is parallel
> > RGB or YUV data." as YUV is also supported.
>
> Ok.
>
> > > + adi,input-colorspace:
> > > + description: Input color space.
> > > + allOf:
> > > + - $ref: /schemas/types.yaml#/definitions/string
> > > + - enum: [ rgb, yuv422, yuv444 ]
> >
> > Isn't string implied ? Can't you write
> >
> > adi,input-colorspace:
> > description: Input color space.
> > enum: [ rgb, yuv422, yuv444 ]
>
> example-schema.yaml says that
>
> Vendor specific properties have slightly different schema
> requirements than common properties. They must have at least a type
> definition and 'description'.
>
> However, dt_binding_check doesn't seem to enforce this rule for string
> properties, and I saw a couple of vendor-specific string properties in
> other bindings that don't define the type either, so I'm going to follow
> your suggestion but only for string properties, the rest need a type
> definition.
I'll defer to Rob to tell the law here :-)
> I noticed I can remove the "allOf" keywords from these too.
>
> > > + adi,embedded-sync:
> > > + description:
> > > + The input uses synchronization signals embedded in the data
> > > + stream (similar to BT.656). Defaults to 0 (separate H/V
> > > + synchronization signals).
> > > + allOf:
> > > + - $ref: /schemas/types.yaml#/definitions/uint32
> > > + - enum: [ 0, 1 ]
> > > + - default: 0
> >
> > This be a boolean property (it is read as a bool by the driver, the
> > property being absent means false, the property being present means
> > true).
>
> You're completely right.
>
> > > + ports:
> > > + description:
> > > + The ADV7511(W)/13 has two video ports and one audio port. This node
> > > + models their connections as documented in
> > > + Documentation/devicetree/bindings/media/video-interfaces.txt
> > > + Documentation/devicetree/bindings/graph.txt
> > > + type: object
> > > + properties:
> > > + port@0:
> > > + description: Video port for the RGB, YUV or DSI input.
> >
> > s/RGB, YUV or DSI/RGB or YUV/
>
> Ok.
>
> > > +if:
> > > + not:
> > > + properties:
> > > + adi,input-colorspace:
> > > + contains:
> > > + enum: [ rgb, yuv444 ]
> > > + adi,input-clock:
> > > + contains:
> > > + const: 1x
> >
> > As both properties take a single value, I think you can omit
> > "contains:".
>
> I think it's required here, removing it makes the test fail.
I thought the following could work:
if:
not:
properties:
adi,input-colorspace:
enum: [ rgb, yuv444 ]
adi,input-clock:
items:
- const: 1x
But no big deal, contains: is ok too.
> > > +required:
> > > + - compatible
> > > + - reg
> > > + - ports
> > > + - adi,input-depth
> > > + - adi,input-colorspace
> > > + - adi,input-clock
> >
> > Shouldn't the power supplies be required ?
>
> Good question. The original binding is not completely clear on
> this. There's a "Required properties" section at the top that doesn't
> include the supplies, the supplies block for the ADV7511/11w/13 looks
> like a gray area in that regard, while the same block for ADV7533/35 is
> more explicit in that they are required, and they are not listed in the
> "Optional properties" section.
>
> However, most of the DTs that use this binding don't define any
> supplies. And AFAICT from looking at the code, regulator_get() will use
> a dummy regulator and show a warning for every expected regulator that's
> not defined in the DT.
>
> If we want to be more strict and require the definition of all the
> supplies, there will be many more DTs changes in the series, and I'm not
> sure I'll be able to do that in a reasonable amount of time. I'm looking
> at them and it's not always clear which regulators to use or if they are
> even defined.
We can decouple the two though (I think). The bindings should reflect
what we consider right, and the dts files could be fixed on top.
> > > +description: |
> > > + The ADV7533 and ADV7535 are HDMI audio and video transmitters
> > > + compatible with HDMI 1.4 and DVI 1.0. They support color space
> > > + conversion, S/PDIF, CEC and HDCP. They support DSI for input pixels.
> >
> > I would write the last sentence as "The transmitter input is MIPI DSI.".
> >
> > ...
> >
> > > + Disables the interal timing generator. The chip will rely on the
> >
> > s/interal/internal/
> >
> > > + sync signals in the DSI data lanes, rather than generate its own
> >
> > s/generate/generating/
> >
> > ...
> >
> > > + properties:
> > > + port@0:
> > > + description:
> > > + Video port for the RGB, YUV or DSI input. The remote endpoint
> >
> > s/RGB, YUV or //
>
> Ok.
>
> > > + ports {
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + port@0 {
> > > + reg = <0>;
> > > + adv7511w_in: endpoint {
> > > + remote-endpoint = <&dpi_out>;
> > > + };
> > > + };
> > > +
> > > + port@1 {
> > > + reg = <1>;
> > > + adv7511_out: endpoint {
> > > + remote-endpoint = <&hdmi_connector_in>;
> > > + };
> > > + };
> >
> > The name of the two endpoints doesn't match the adv7533. The remote
> > endpoint phandle for port 0 should have dsi in its name.
>
> Oops, thanks for catching these.
--
Regards,
Laurent Pinchart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 66+ messages in thread* Re: [PATCH v2 6/6] dt-bindings: drm: bridge: adi,adv7511.txt: convert to yaml
2020-05-14 15:22 ` Laurent Pinchart
@ 2020-05-18 21:27 ` Rob Herring
-1 siblings, 0 replies; 66+ messages in thread
From: Rob Herring @ 2020-05-18 21:27 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Ricardo Cañuelo, kernel, devicetree, linux-arm-kernel,
geert+renesas, xuwei5
On Thu, May 14, 2020 at 06:22:39PM +0300, Laurent Pinchart wrote:
> Hi Ricardo,
>
> On Thu, May 14, 2020 at 11:36:17AM +0200, Ricardo Cañuelo wrote:
> > Hi Laurent, thanks for the thorough review. Some comments below:
> >
> > On jue 14-05-2020 04:54:12, Laurent Pinchart wrote:
> > > > +description: |
> > > > + The ADV7511, ADV7511W and ADV7513 are HDMI audio and video
> > > > + transmitters compatible with HDMI 1.4 and DVI 1.0. They support color
> > > > + space conversion, S/PDIF, CEC and HDCP. They support RGB input
> > > > + interface.
> > >
> > > I would write the last sentence as "The transmitter input is parallel
> > > RGB or YUV data." as YUV is also supported.
> >
> > Ok.
> >
> > > > + adi,input-colorspace:
> > > > + description: Input color space.
> > > > + allOf:
> > > > + - $ref: /schemas/types.yaml#/definitions/string
> > > > + - enum: [ rgb, yuv422, yuv444 ]
> > >
> > > Isn't string implied ? Can't you write
> > >
> > > adi,input-colorspace:
> > > description: Input color space.
> > > enum: [ rgb, yuv422, yuv444 ]
> >
> > example-schema.yaml says that
> >
> > Vendor specific properties have slightly different schema
> > requirements than common properties. They must have at least a type
> > definition and 'description'.
> >
> > However, dt_binding_check doesn't seem to enforce this rule for string
> > properties, and I saw a couple of vendor-specific string properties in
> > other bindings that don't define the type either, so I'm going to follow
> > your suggestion but only for string properties, the rest need a type
> > definition.
>
> I'll defer to Rob to tell the law here :-)
Yes, if you have a string with defined values, then a type isn't needed.
That only applies to strings as numeric values need a size.
>
> > I noticed I can remove the "allOf" keywords from these too.
Yes, that's a recent change. Both forms still work.
> > > > + adi,embedded-sync:
> > > > + description:
> > > > + The input uses synchronization signals embedded in the data
> > > > + stream (similar to BT.656). Defaults to 0 (separate H/V
> > > > + synchronization signals).
> > > > + allOf:
> > > > + - $ref: /schemas/types.yaml#/definitions/uint32
> > > > + - enum: [ 0, 1 ]
> > > > + - default: 0
> > >
> > > This be a boolean property (it is read as a bool by the driver, the
> > > property being absent means false, the property being present means
> > > true).
> >
> > You're completely right.
> >
> > > > + ports:
> > > > + description:
> > > > + The ADV7511(W)/13 has two video ports and one audio port. This node
> > > > + models their connections as documented in
> > > > + Documentation/devicetree/bindings/media/video-interfaces.txt
> > > > + Documentation/devicetree/bindings/graph.txt
> > > > + type: object
> > > > + properties:
> > > > + port@0:
> > > > + description: Video port for the RGB, YUV or DSI input.
> > >
> > > s/RGB, YUV or DSI/RGB or YUV/
> >
> > Ok.
> >
> > > > +if:
> > > > + not:
> > > > + properties:
> > > > + adi,input-colorspace:
> > > > + contains:
> > > > + enum: [ rgb, yuv444 ]
> > > > + adi,input-clock:
> > > > + contains:
> > > > + const: 1x
> > >
> > > As both properties take a single value, I think you can omit
> > > "contains:".
> >
> > I think it's required here, removing it makes the test fail.
>
> I thought the following could work:
>
> if:
> not:
> properties:
> adi,input-colorspace:
> enum: [ rgb, yuv444 ]
> adi,input-clock:
> items:
> - const: 1x
>
> But no big deal, contains: is ok too.
In theory the above should work. However, this is probably a case where
we don't fix-up the properties. If you look at the DT yaml encoding,
everything is an array (as dtc doesn't know). For schemas, the tooling
expands scalars to arrays.
Rob
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCH v2 6/6] dt-bindings: drm: bridge: adi,adv7511.txt: convert to yaml
@ 2020-05-18 21:27 ` Rob Herring
0 siblings, 0 replies; 66+ messages in thread
From: Rob Herring @ 2020-05-18 21:27 UTC (permalink / raw)
To: Laurent Pinchart
Cc: devicetree, geert+renesas, xuwei5, kernel, Ricardo Cañuelo,
linux-arm-kernel
On Thu, May 14, 2020 at 06:22:39PM +0300, Laurent Pinchart wrote:
> Hi Ricardo,
>
> On Thu, May 14, 2020 at 11:36:17AM +0200, Ricardo Cañuelo wrote:
> > Hi Laurent, thanks for the thorough review. Some comments below:
> >
> > On jue 14-05-2020 04:54:12, Laurent Pinchart wrote:
> > > > +description: |
> > > > + The ADV7511, ADV7511W and ADV7513 are HDMI audio and video
> > > > + transmitters compatible with HDMI 1.4 and DVI 1.0. They support color
> > > > + space conversion, S/PDIF, CEC and HDCP. They support RGB input
> > > > + interface.
> > >
> > > I would write the last sentence as "The transmitter input is parallel
> > > RGB or YUV data." as YUV is also supported.
> >
> > Ok.
> >
> > > > + adi,input-colorspace:
> > > > + description: Input color space.
> > > > + allOf:
> > > > + - $ref: /schemas/types.yaml#/definitions/string
> > > > + - enum: [ rgb, yuv422, yuv444 ]
> > >
> > > Isn't string implied ? Can't you write
> > >
> > > adi,input-colorspace:
> > > description: Input color space.
> > > enum: [ rgb, yuv422, yuv444 ]
> >
> > example-schema.yaml says that
> >
> > Vendor specific properties have slightly different schema
> > requirements than common properties. They must have at least a type
> > definition and 'description'.
> >
> > However, dt_binding_check doesn't seem to enforce this rule for string
> > properties, and I saw a couple of vendor-specific string properties in
> > other bindings that don't define the type either, so I'm going to follow
> > your suggestion but only for string properties, the rest need a type
> > definition.
>
> I'll defer to Rob to tell the law here :-)
Yes, if you have a string with defined values, then a type isn't needed.
That only applies to strings as numeric values need a size.
>
> > I noticed I can remove the "allOf" keywords from these too.
Yes, that's a recent change. Both forms still work.
> > > > + adi,embedded-sync:
> > > > + description:
> > > > + The input uses synchronization signals embedded in the data
> > > > + stream (similar to BT.656). Defaults to 0 (separate H/V
> > > > + synchronization signals).
> > > > + allOf:
> > > > + - $ref: /schemas/types.yaml#/definitions/uint32
> > > > + - enum: [ 0, 1 ]
> > > > + - default: 0
> > >
> > > This be a boolean property (it is read as a bool by the driver, the
> > > property being absent means false, the property being present means
> > > true).
> >
> > You're completely right.
> >
> > > > + ports:
> > > > + description:
> > > > + The ADV7511(W)/13 has two video ports and one audio port. This node
> > > > + models their connections as documented in
> > > > + Documentation/devicetree/bindings/media/video-interfaces.txt
> > > > + Documentation/devicetree/bindings/graph.txt
> > > > + type: object
> > > > + properties:
> > > > + port@0:
> > > > + description: Video port for the RGB, YUV or DSI input.
> > >
> > > s/RGB, YUV or DSI/RGB or YUV/
> >
> > Ok.
> >
> > > > +if:
> > > > + not:
> > > > + properties:
> > > > + adi,input-colorspace:
> > > > + contains:
> > > > + enum: [ rgb, yuv444 ]
> > > > + adi,input-clock:
> > > > + contains:
> > > > + const: 1x
> > >
> > > As both properties take a single value, I think you can omit
> > > "contains:".
> >
> > I think it's required here, removing it makes the test fail.
>
> I thought the following could work:
>
> if:
> not:
> properties:
> adi,input-colorspace:
> enum: [ rgb, yuv444 ]
> adi,input-clock:
> items:
> - const: 1x
>
> But no big deal, contains: is ok too.
In theory the above should work. However, this is probably a case where
we don't fix-up the properties. If you look at the DT yaml encoding,
everything is an array (as dtc doesn't know). For schemas, the tooling
expands scalars to arrays.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCH v2 6/6] dt-bindings: drm: bridge: adi,adv7511.txt: convert to yaml
2020-05-14 15:22 ` Laurent Pinchart
@ 2020-05-25 7:43 ` Ricardo Cañuelo
-1 siblings, 0 replies; 66+ messages in thread
From: Ricardo Cañuelo @ 2020-05-25 7:43 UTC (permalink / raw)
To: Laurent Pinchart
Cc: kernel, devicetree, linux-arm-kernel, geert+renesas, robh+dt, xuwei5
Hi Laurent,
On jue 14-05-2020 18:22:39, Laurent Pinchart wrote:
> > If we want to be more strict and require the definition of all the
> > supplies, there will be many more DTs changes in the series, and I'm not
> > sure I'll be able to do that in a reasonable amount of time. I'm looking
> > at them and it's not always clear which regulators to use or if they are
> > even defined.
>
> We can decouple the two though (I think). The bindings should reflect
> what we consider right, and the dts files could be fixed on top.
Do you have a suggestion on how to do this? If we decouple the two
tasks most of the work would be searching for DTs to fix and finding a
way to fix each one of them, and unless I do this _before_ the binding
conversion I'll get a lot of dtbs_check errors.
The binding conversion itself is done, if we go this route the only
additional change would be to make the supplies required.
Cheers,
Ricardo
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCH v2 6/6] dt-bindings: drm: bridge: adi,adv7511.txt: convert to yaml
@ 2020-05-25 7:43 ` Ricardo Cañuelo
0 siblings, 0 replies; 66+ messages in thread
From: Ricardo Cañuelo @ 2020-05-25 7:43 UTC (permalink / raw)
To: Laurent Pinchart
Cc: devicetree, geert+renesas, xuwei5, robh+dt, kernel, linux-arm-kernel
Hi Laurent,
On jue 14-05-2020 18:22:39, Laurent Pinchart wrote:
> > If we want to be more strict and require the definition of all the
> > supplies, there will be many more DTs changes in the series, and I'm not
> > sure I'll be able to do that in a reasonable amount of time. I'm looking
> > at them and it's not always clear which regulators to use or if they are
> > even defined.
>
> We can decouple the two though (I think). The bindings should reflect
> what we consider right, and the dts files could be fixed on top.
Do you have a suggestion on how to do this? If we decouple the two
tasks most of the work would be searching for DTs to fix and finding a
way to fix each one of them, and unless I do this _before_ the binding
conversion I'll get a lot of dtbs_check errors.
The binding conversion itself is done, if we go this route the only
additional change would be to make the supplies required.
Cheers,
Ricardo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCH v2 6/6] dt-bindings: drm: bridge: adi,adv7511.txt: convert to yaml
2020-05-25 7:43 ` Ricardo Cañuelo
@ 2020-05-26 1:44 ` Laurent Pinchart
-1 siblings, 0 replies; 66+ messages in thread
From: Laurent Pinchart @ 2020-05-26 1:44 UTC (permalink / raw)
To: Ricardo Cañuelo
Cc: kernel, devicetree, linux-arm-kernel, geert+renesas, robh+dt, xuwei5
Hi Ricardo,
On Mon, May 25, 2020 at 09:43:35AM +0200, Ricardo Cañuelo wrote:
> On jue 14-05-2020 18:22:39, Laurent Pinchart wrote:
> > > If we want to be more strict and require the definition of all the
> > > supplies, there will be many more DTs changes in the series, and I'm not
> > > sure I'll be able to do that in a reasonable amount of time. I'm looking
> > > at them and it's not always clear which regulators to use or if they are
> > > even defined.
> >
> > We can decouple the two though (I think). The bindings should reflect
> > what we consider right, and the dts files could be fixed on top.
>
> Do you have a suggestion on how to do this? If we decouple the two
> tasks most of the work would be searching for DTs to fix and finding a
> way to fix each one of them, and unless I do this _before_ the binding
> conversion I'll get a lot of dtbs_check errors.
Rob should answer this question as it will be his decision, but I've
personally never considered non-compliant DT sources to be an obstacle
to bindings conversion to YAML. The DT sources should be fixed, but I
don't see it as a prerequisite (although it's a good practice).
> The binding conversion itself is done, if we go this route the only
> additional change would be to make the supplies required.
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCH v2 6/6] dt-bindings: drm: bridge: adi,adv7511.txt: convert to yaml
@ 2020-05-26 1:44 ` Laurent Pinchart
0 siblings, 0 replies; 66+ messages in thread
From: Laurent Pinchart @ 2020-05-26 1:44 UTC (permalink / raw)
To: Ricardo Cañuelo
Cc: devicetree, geert+renesas, xuwei5, robh+dt, kernel, linux-arm-kernel
Hi Ricardo,
On Mon, May 25, 2020 at 09:43:35AM +0200, Ricardo Cañuelo wrote:
> On jue 14-05-2020 18:22:39, Laurent Pinchart wrote:
> > > If we want to be more strict and require the definition of all the
> > > supplies, there will be many more DTs changes in the series, and I'm not
> > > sure I'll be able to do that in a reasonable amount of time. I'm looking
> > > at them and it's not always clear which regulators to use or if they are
> > > even defined.
> >
> > We can decouple the two though (I think). The bindings should reflect
> > what we consider right, and the dts files could be fixed on top.
>
> Do you have a suggestion on how to do this? If we decouple the two
> tasks most of the work would be searching for DTs to fix and finding a
> way to fix each one of them, and unless I do this _before_ the binding
> conversion I'll get a lot of dtbs_check errors.
Rob should answer this question as it will be his decision, but I've
personally never considered non-compliant DT sources to be an obstacle
to bindings conversion to YAML. The DT sources should be fixed, but I
don't see it as a prerequisite (although it's a good practice).
> The binding conversion itself is done, if we go this route the only
> additional change would be to make the supplies required.
--
Regards,
Laurent Pinchart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCH v2 6/6] dt-bindings: drm: bridge: adi,adv7511.txt: convert to yaml
2020-05-26 1:44 ` Laurent Pinchart
@ 2020-05-26 7:03 ` Geert Uytterhoeven
-1 siblings, 0 replies; 66+ messages in thread
From: Geert Uytterhoeven @ 2020-05-26 7:03 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Ricardo Cañuelo, Collabora Kernel ML,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, Geert Uytterhoeven, Rob Herring, Wei Xu
Hi Laurent,
On Tue, May 26, 2020 at 3:44 AM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Mon, May 25, 2020 at 09:43:35AM +0200, Ricardo Cañuelo wrote:
> > On jue 14-05-2020 18:22:39, Laurent Pinchart wrote:
> > > > If we want to be more strict and require the definition of all the
> > > > supplies, there will be many more DTs changes in the series, and I'm not
> > > > sure I'll be able to do that in a reasonable amount of time. I'm looking
> > > > at them and it's not always clear which regulators to use or if they are
> > > > even defined.
> > >
> > > We can decouple the two though (I think). The bindings should reflect
> > > what we consider right, and the dts files could be fixed on top.
> >
> > Do you have a suggestion on how to do this? If we decouple the two
> > tasks most of the work would be searching for DTs to fix and finding a
> > way to fix each one of them, and unless I do this _before_ the binding
> > conversion I'll get a lot of dtbs_check errors.
>
> Rob should answer this question as it will be his decision, but I've
> personally never considered non-compliant DT sources to be an obstacle
> to bindings conversion to YAML. The DT sources should be fixed, but I
> don't see it as a prerequisite (although it's a good practice).
I do my best to avoid introducing regressions when the binding conversions
go upstream.
FTR, hence patches 1-3 are already in v5.7-rc7.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 66+ messages in thread* Re: [PATCH v2 6/6] dt-bindings: drm: bridge: adi, adv7511.txt: convert to yaml
@ 2020-05-26 7:03 ` Geert Uytterhoeven
0 siblings, 0 replies; 66+ messages in thread
From: Geert Uytterhoeven @ 2020-05-26 7:03 UTC (permalink / raw)
To: Laurent Pinchart
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Geert Uytterhoeven, Wei Xu, Rob Herring, Collabora Kernel ML,
Ricardo Cañuelo, Linux ARM
Hi Laurent,
On Tue, May 26, 2020 at 3:44 AM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Mon, May 25, 2020 at 09:43:35AM +0200, Ricardo Cañuelo wrote:
> > On jue 14-05-2020 18:22:39, Laurent Pinchart wrote:
> > > > If we want to be more strict and require the definition of all the
> > > > supplies, there will be many more DTs changes in the series, and I'm not
> > > > sure I'll be able to do that in a reasonable amount of time. I'm looking
> > > > at them and it's not always clear which regulators to use or if they are
> > > > even defined.
> > >
> > > We can decouple the two though (I think). The bindings should reflect
> > > what we consider right, and the dts files could be fixed on top.
> >
> > Do you have a suggestion on how to do this? If we decouple the two
> > tasks most of the work would be searching for DTs to fix and finding a
> > way to fix each one of them, and unless I do this _before_ the binding
> > conversion I'll get a lot of dtbs_check errors.
>
> Rob should answer this question as it will be his decision, but I've
> personally never considered non-compliant DT sources to be an obstacle
> to bindings conversion to YAML. The DT sources should be fixed, but I
> don't see it as a prerequisite (although it's a good practice).
I do my best to avoid introducing regressions when the binding conversions
go upstream.
FTR, hence patches 1-3 are already in v5.7-rc7.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 66+ messages in thread* Re: [PATCH v2 6/6] dt-bindings: drm: bridge: adi,adv7511.txt: convert to yaml
2020-05-26 7:03 ` [PATCH v2 6/6] dt-bindings: drm: bridge: adi, adv7511.txt: " Geert Uytterhoeven
@ 2020-05-26 10:11 ` Laurent Pinchart
-1 siblings, 0 replies; 66+ messages in thread
From: Laurent Pinchart @ 2020-05-26 10:11 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Ricardo Cañuelo, Collabora Kernel ML,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, Geert Uytterhoeven, Rob Herring, Wei Xu
Hi Geert,
On Tue, May 26, 2020 at 09:03:09AM +0200, Geert Uytterhoeven wrote:
> On Tue, May 26, 2020 at 3:44 AM Laurent Pinchart wrote:
> > On Mon, May 25, 2020 at 09:43:35AM +0200, Ricardo Cañuelo wrote:
> > > On jue 14-05-2020 18:22:39, Laurent Pinchart wrote:
> > > > > If we want to be more strict and require the definition of all the
> > > > > supplies, there will be many more DTs changes in the series, and I'm not
> > > > > sure I'll be able to do that in a reasonable amount of time. I'm looking
> > > > > at them and it's not always clear which regulators to use or if they are
> > > > > even defined.
> > > >
> > > > We can decouple the two though (I think). The bindings should reflect
> > > > what we consider right, and the dts files could be fixed on top.
> > >
> > > Do you have a suggestion on how to do this? If we decouple the two
> > > tasks most of the work would be searching for DTs to fix and finding a
> > > way to fix each one of them, and unless I do this _before_ the binding
> > > conversion I'll get a lot of dtbs_check errors.
> >
> > Rob should answer this question as it will be his decision, but I've
> > personally never considered non-compliant DT sources to be an obstacle
> > to bindings conversion to YAML. The DT sources should be fixed, but I
> > don't see it as a prerequisite (although it's a good practice).
>
> I do my best to avoid introducing regressions when the binding conversions
> go upstream.
Please note that we're not talking about runtime regressions, as drivers
are not updated. It's "only" dtbs_check that would produce new errors.
> FTR, hence patches 1-3 are already in v5.7-rc7.
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCH v2 6/6] dt-bindings: drm: bridge: adi,adv7511.txt: convert to yaml
@ 2020-05-26 10:11 ` Laurent Pinchart
0 siblings, 0 replies; 66+ messages in thread
From: Laurent Pinchart @ 2020-05-26 10:11 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Geert Uytterhoeven, Wei Xu, Rob Herring, Collabora Kernel ML,
Ricardo Cañuelo, Linux ARM
Hi Geert,
On Tue, May 26, 2020 at 09:03:09AM +0200, Geert Uytterhoeven wrote:
> On Tue, May 26, 2020 at 3:44 AM Laurent Pinchart wrote:
> > On Mon, May 25, 2020 at 09:43:35AM +0200, Ricardo Cañuelo wrote:
> > > On jue 14-05-2020 18:22:39, Laurent Pinchart wrote:
> > > > > If we want to be more strict and require the definition of all the
> > > > > supplies, there will be many more DTs changes in the series, and I'm not
> > > > > sure I'll be able to do that in a reasonable amount of time. I'm looking
> > > > > at them and it's not always clear which regulators to use or if they are
> > > > > even defined.
> > > >
> > > > We can decouple the two though (I think). The bindings should reflect
> > > > what we consider right, and the dts files could be fixed on top.
> > >
> > > Do you have a suggestion on how to do this? If we decouple the two
> > > tasks most of the work would be searching for DTs to fix and finding a
> > > way to fix each one of them, and unless I do this _before_ the binding
> > > conversion I'll get a lot of dtbs_check errors.
> >
> > Rob should answer this question as it will be his decision, but I've
> > personally never considered non-compliant DT sources to be an obstacle
> > to bindings conversion to YAML. The DT sources should be fixed, but I
> > don't see it as a prerequisite (although it's a good practice).
>
> I do my best to avoid introducing regressions when the binding conversions
> go upstream.
Please note that we're not talking about runtime regressions, as drivers
are not updated. It's "only" dtbs_check that would produce new errors.
> FTR, hence patches 1-3 are already in v5.7-rc7.
--
Regards,
Laurent Pinchart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCH v2 6/6] dt-bindings: drm: bridge: adi,adv7511.txt: convert to yaml
2020-05-26 10:11 ` Laurent Pinchart
@ 2020-05-26 10:39 ` Geert Uytterhoeven
-1 siblings, 0 replies; 66+ messages in thread
From: Geert Uytterhoeven @ 2020-05-26 10:39 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Ricardo Cañuelo, Collabora Kernel ML,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, Geert Uytterhoeven, Rob Herring, Wei Xu
Hi Laurent,
On Tue, May 26, 2020 at 12:12 PM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Tue, May 26, 2020 at 09:03:09AM +0200, Geert Uytterhoeven wrote:
> > On Tue, May 26, 2020 at 3:44 AM Laurent Pinchart wrote:
> > > On Mon, May 25, 2020 at 09:43:35AM +0200, Ricardo Cañuelo wrote:
> > > > On jue 14-05-2020 18:22:39, Laurent Pinchart wrote:
> > > > > > If we want to be more strict and require the definition of all the
> > > > > > supplies, there will be many more DTs changes in the series, and I'm not
> > > > > > sure I'll be able to do that in a reasonable amount of time. I'm looking
> > > > > > at them and it's not always clear which regulators to use or if they are
> > > > > > even defined.
> > > > >
> > > > > We can decouple the two though (I think). The bindings should reflect
> > > > > what we consider right, and the dts files could be fixed on top.
> > > >
> > > > Do you have a suggestion on how to do this? If we decouple the two
> > > > tasks most of the work would be searching for DTs to fix and finding a
> > > > way to fix each one of them, and unless I do this _before_ the binding
> > > > conversion I'll get a lot of dtbs_check errors.
> > >
> > > Rob should answer this question as it will be his decision, but I've
> > > personally never considered non-compliant DT sources to be an obstacle
> > > to bindings conversion to YAML. The DT sources should be fixed, but I
> > > don't see it as a prerequisite (although it's a good practice).
> >
> > I do my best to avoid introducing regressions when the binding conversions
> > go upstream.
>
> Please note that we're not talking about runtime regressions, as drivers
> are not updated. It's "only" dtbs_check that would produce new errors.
Exactly. I was talking about "make dtbs_check" regressions, too.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 66+ messages in thread* Re: [PATCH v2 6/6] dt-bindings: drm: bridge: adi, adv7511.txt: convert to yaml
@ 2020-05-26 10:39 ` Geert Uytterhoeven
0 siblings, 0 replies; 66+ messages in thread
From: Geert Uytterhoeven @ 2020-05-26 10:39 UTC (permalink / raw)
To: Laurent Pinchart
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Geert Uytterhoeven, Wei Xu, Rob Herring, Collabora Kernel ML,
Ricardo Cañuelo, Linux ARM
Hi Laurent,
On Tue, May 26, 2020 at 12:12 PM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Tue, May 26, 2020 at 09:03:09AM +0200, Geert Uytterhoeven wrote:
> > On Tue, May 26, 2020 at 3:44 AM Laurent Pinchart wrote:
> > > On Mon, May 25, 2020 at 09:43:35AM +0200, Ricardo Cañuelo wrote:
> > > > On jue 14-05-2020 18:22:39, Laurent Pinchart wrote:
> > > > > > If we want to be more strict and require the definition of all the
> > > > > > supplies, there will be many more DTs changes in the series, and I'm not
> > > > > > sure I'll be able to do that in a reasonable amount of time. I'm looking
> > > > > > at them and it's not always clear which regulators to use or if they are
> > > > > > even defined.
> > > > >
> > > > > We can decouple the two though (I think). The bindings should reflect
> > > > > what we consider right, and the dts files could be fixed on top.
> > > >
> > > > Do you have a suggestion on how to do this? If we decouple the two
> > > > tasks most of the work would be searching for DTs to fix and finding a
> > > > way to fix each one of them, and unless I do this _before_ the binding
> > > > conversion I'll get a lot of dtbs_check errors.
> > >
> > > Rob should answer this question as it will be his decision, but I've
> > > personally never considered non-compliant DT sources to be an obstacle
> > > to bindings conversion to YAML. The DT sources should be fixed, but I
> > > don't see it as a prerequisite (although it's a good practice).
> >
> > I do my best to avoid introducing regressions when the binding conversions
> > go upstream.
>
> Please note that we're not talking about runtime regressions, as drivers
> are not updated. It's "only" dtbs_check that would produce new errors.
Exactly. I was talking about "make dtbs_check" regressions, too.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 66+ messages in thread* Re: [PATCH v2 6/6] dt-bindings: drm: bridge: adi,adv7511.txt: convert to yaml
2020-05-26 10:39 ` [PATCH v2 6/6] dt-bindings: drm: bridge: adi, adv7511.txt: " Geert Uytterhoeven
@ 2020-05-26 19:45 ` Ezequiel Garcia
-1 siblings, 0 replies; 66+ messages in thread
From: Ezequiel Garcia @ 2020-05-26 19:45 UTC (permalink / raw)
To: Geert Uytterhoeven, Laurent Pinchart
Cc: Ricardo Cañuelo, Collabora Kernel ML,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, Geert Uytterhoeven, Rob Herring, Wei Xu
On Tue, 2020-05-26 at 12:39 +0200, Geert Uytterhoeven wrote:
> Hi Laurent,
>
> On Tue, May 26, 2020 at 12:12 PM Laurent Pinchart
> <laurent.pinchart@ideasonboard.com> wrote:
> > On Tue, May 26, 2020 at 09:03:09AM +0200, Geert Uytterhoeven wrote:
> > > On Tue, May 26, 2020 at 3:44 AM Laurent Pinchart wrote:
> > > > On Mon, May 25, 2020 at 09:43:35AM +0200, Ricardo Cañuelo wrote:
> > > > > On jue 14-05-2020 18:22:39, Laurent Pinchart wrote:
> > > > > > > If we want to be more strict and require the definition of all the
> > > > > > > supplies, there will be many more DTs changes in the series, and I'm not
> > > > > > > sure I'll be able to do that in a reasonable amount of time. I'm looking
> > > > > > > at them and it's not always clear which regulators to use or if they are
> > > > > > > even defined.
> > > > > >
> > > > > > We can decouple the two though (I think). The bindings should reflect
> > > > > > what we consider right, and the dts files could be fixed on top.
> > > > >
> > > > > Do you have a suggestion on how to do this? If we decouple the two
> > > > > tasks most of the work would be searching for DTs to fix and finding a
> > > > > way to fix each one of them, and unless I do this _before_ the binding
> > > > > conversion I'll get a lot of dtbs_check errors.
> > > >
> > > > Rob should answer this question as it will be his decision, but I've
> > > > personally never considered non-compliant DT sources to be an obstacle
> > > > to bindings conversion to YAML. The DT sources should be fixed, but I
> > > > don't see it as a prerequisite (although it's a good practice).
> > >
> > > I do my best to avoid introducing regressions when the binding conversions
> > > go upstream.
> >
> > Please note that we're not talking about runtime regressions, as drivers
> > are not updated. It's "only" dtbs_check that would produce new errors.
>
> Exactly. I was talking about "make dtbs_check" regressions, too.
>
A "make dtbs_check" failure, due to some foo.dts that fails the check
due to a correct YAML conversion, can't be considered a regression.
I strongly agree with Laurent here, we want to convert the bindings
to YAML and we can't consider non-compliant DT sources to prevent them.
Regards,
Ezequiel
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCH v2 6/6] dt-bindings: drm: bridge: adi,adv7511.txt: convert to yaml
@ 2020-05-26 19:45 ` Ezequiel Garcia
0 siblings, 0 replies; 66+ messages in thread
From: Ezequiel Garcia @ 2020-05-26 19:45 UTC (permalink / raw)
To: Geert Uytterhoeven, Laurent Pinchart
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Geert Uytterhoeven, Wei Xu, Rob Herring, Collabora Kernel ML,
Ricardo Cañuelo, Linux ARM
On Tue, 2020-05-26 at 12:39 +0200, Geert Uytterhoeven wrote:
> Hi Laurent,
>
> On Tue, May 26, 2020 at 12:12 PM Laurent Pinchart
> <laurent.pinchart@ideasonboard.com> wrote:
> > On Tue, May 26, 2020 at 09:03:09AM +0200, Geert Uytterhoeven wrote:
> > > On Tue, May 26, 2020 at 3:44 AM Laurent Pinchart wrote:
> > > > On Mon, May 25, 2020 at 09:43:35AM +0200, Ricardo Cañuelo wrote:
> > > > > On jue 14-05-2020 18:22:39, Laurent Pinchart wrote:
> > > > > > > If we want to be more strict and require the definition of all the
> > > > > > > supplies, there will be many more DTs changes in the series, and I'm not
> > > > > > > sure I'll be able to do that in a reasonable amount of time. I'm looking
> > > > > > > at them and it's not always clear which regulators to use or if they are
> > > > > > > even defined.
> > > > > >
> > > > > > We can decouple the two though (I think). The bindings should reflect
> > > > > > what we consider right, and the dts files could be fixed on top.
> > > > >
> > > > > Do you have a suggestion on how to do this? If we decouple the two
> > > > > tasks most of the work would be searching for DTs to fix and finding a
> > > > > way to fix each one of them, and unless I do this _before_ the binding
> > > > > conversion I'll get a lot of dtbs_check errors.
> > > >
> > > > Rob should answer this question as it will be his decision, but I've
> > > > personally never considered non-compliant DT sources to be an obstacle
> > > > to bindings conversion to YAML. The DT sources should be fixed, but I
> > > > don't see it as a prerequisite (although it's a good practice).
> > >
> > > I do my best to avoid introducing regressions when the binding conversions
> > > go upstream.
> >
> > Please note that we're not talking about runtime regressions, as drivers
> > are not updated. It's "only" dtbs_check that would produce new errors.
>
> Exactly. I was talking about "make dtbs_check" regressions, too.
>
A "make dtbs_check" failure, due to some foo.dts that fails the check
due to a correct YAML conversion, can't be considered a regression.
I strongly agree with Laurent here, we want to convert the bindings
to YAML and we can't consider non-compliant DT sources to prevent them.
Regards,
Ezequiel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCH v2 6/6] dt-bindings: drm: bridge: adi,adv7511.txt: convert to yaml
2020-05-26 7:03 ` [PATCH v2 6/6] dt-bindings: drm: bridge: adi, adv7511.txt: " Geert Uytterhoeven
@ 2020-05-27 17:29 ` Rob Herring
-1 siblings, 0 replies; 66+ messages in thread
From: Rob Herring @ 2020-05-27 17:29 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Laurent Pinchart, Ricardo Cañuelo, Collabora Kernel ML,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, Geert Uytterhoeven, Wei Xu
On Tue, May 26, 2020 at 1:03 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Laurent,
>
> On Tue, May 26, 2020 at 3:44 AM Laurent Pinchart
> <laurent.pinchart@ideasonboard.com> wrote:
> > On Mon, May 25, 2020 at 09:43:35AM +0200, Ricardo Cañuelo wrote:
> > > On jue 14-05-2020 18:22:39, Laurent Pinchart wrote:
> > > > > If we want to be more strict and require the definition of all the
> > > > > supplies, there will be many more DTs changes in the series, and I'm not
> > > > > sure I'll be able to do that in a reasonable amount of time. I'm looking
> > > > > at them and it's not always clear which regulators to use or if they are
> > > > > even defined.
> > > >
> > > > We can decouple the two though (I think). The bindings should reflect
> > > > what we consider right, and the dts files could be fixed on top.
> > >
> > > Do you have a suggestion on how to do this? If we decouple the two
> > > tasks most of the work would be searching for DTs to fix and finding a
> > > way to fix each one of them, and unless I do this _before_ the binding
> > > conversion I'll get a lot of dtbs_check errors.
> >
> > Rob should answer this question as it will be his decision, but I've
> > personally never considered non-compliant DT sources to be an obstacle
> > to bindings conversion to YAML. The DT sources should be fixed, but I
> > don't see it as a prerequisite (although it's a good practice).
There's currently no requirement that binding schema don't introduce
warnings in dts files. That should change when/if we get to a warning
free state (probably per platform/family). I don't think we're close
on any platform? (If we are, I'd like to start tracking that). It is
good to pay attention to the warnings you get though as the schema may
not be doing what you expect or the binding really doesn't match
reality.
> I do my best to avoid introducing regressions when the binding conversions
> go upstream.
Meaning you fix the dts files or massage the schema to match? If we
just adjust schema to match, what's the point in this effort? We
should find things wrong or ill defined.
Rob
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCH v2 6/6] dt-bindings: drm: bridge: adi, adv7511.txt: convert to yaml
@ 2020-05-27 17:29 ` Rob Herring
0 siblings, 0 replies; 66+ messages in thread
From: Rob Herring @ 2020-05-27 17:29 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Geert Uytterhoeven, Wei Xu, Laurent Pinchart,
Collabora Kernel ML, Ricardo Cañuelo, Linux ARM
On Tue, May 26, 2020 at 1:03 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Laurent,
>
> On Tue, May 26, 2020 at 3:44 AM Laurent Pinchart
> <laurent.pinchart@ideasonboard.com> wrote:
> > On Mon, May 25, 2020 at 09:43:35AM +0200, Ricardo Cañuelo wrote:
> > > On jue 14-05-2020 18:22:39, Laurent Pinchart wrote:
> > > > > If we want to be more strict and require the definition of all the
> > > > > supplies, there will be many more DTs changes in the series, and I'm not
> > > > > sure I'll be able to do that in a reasonable amount of time. I'm looking
> > > > > at them and it's not always clear which regulators to use or if they are
> > > > > even defined.
> > > >
> > > > We can decouple the two though (I think). The bindings should reflect
> > > > what we consider right, and the dts files could be fixed on top.
> > >
> > > Do you have a suggestion on how to do this? If we decouple the two
> > > tasks most of the work would be searching for DTs to fix and finding a
> > > way to fix each one of them, and unless I do this _before_ the binding
> > > conversion I'll get a lot of dtbs_check errors.
> >
> > Rob should answer this question as it will be his decision, but I've
> > personally never considered non-compliant DT sources to be an obstacle
> > to bindings conversion to YAML. The DT sources should be fixed, but I
> > don't see it as a prerequisite (although it's a good practice).
There's currently no requirement that binding schema don't introduce
warnings in dts files. That should change when/if we get to a warning
free state (probably per platform/family). I don't think we're close
on any platform? (If we are, I'd like to start tracking that). It is
good to pay attention to the warnings you get though as the schema may
not be doing what you expect or the binding really doesn't match
reality.
> I do my best to avoid introducing regressions when the binding conversions
> go upstream.
Meaning you fix the dts files or massage the schema to match? If we
just adjust schema to match, what's the point in this effort? We
should find things wrong or ill defined.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCH v2 6/6] dt-bindings: drm: bridge: adi,adv7511.txt: convert to yaml
2020-05-27 17:29 ` [PATCH v2 6/6] dt-bindings: drm: bridge: adi, adv7511.txt: " Rob Herring
@ 2020-05-27 18:18 ` Geert Uytterhoeven
-1 siblings, 0 replies; 66+ messages in thread
From: Geert Uytterhoeven @ 2020-05-27 18:18 UTC (permalink / raw)
To: Rob Herring
Cc: Laurent Pinchart, Ricardo Cañuelo, Collabora Kernel ML,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, Geert Uytterhoeven, Wei Xu
Hi Rob,
On Wed, May 27, 2020 at 7:30 PM Rob Herring <robh+dt@kernel.org> wrote:
> On Tue, May 26, 2020 at 1:03 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Tue, May 26, 2020 at 3:44 AM Laurent Pinchart
> > <laurent.pinchart@ideasonboard.com> wrote:
> > > On Mon, May 25, 2020 at 09:43:35AM +0200, Ricardo Cañuelo wrote:
> > > > On jue 14-05-2020 18:22:39, Laurent Pinchart wrote:
> > > > > > If we want to be more strict and require the definition of all the
> > > > > > supplies, there will be many more DTs changes in the series, and I'm not
> > > > > > sure I'll be able to do that in a reasonable amount of time. I'm looking
> > > > > > at them and it's not always clear which regulators to use or if they are
> > > > > > even defined.
> > > > >
> > > > > We can decouple the two though (I think). The bindings should reflect
> > > > > what we consider right, and the dts files could be fixed on top.
> > > >
> > > > Do you have a suggestion on how to do this? If we decouple the two
> > > > tasks most of the work would be searching for DTs to fix and finding a
> > > > way to fix each one of them, and unless I do this _before_ the binding
> > > > conversion I'll get a lot of dtbs_check errors.
> > >
> > > Rob should answer this question as it will be his decision, but I've
> > > personally never considered non-compliant DT sources to be an obstacle
> > > to bindings conversion to YAML. The DT sources should be fixed, but I
> > > don't see it as a prerequisite (although it's a good practice).
>
> There's currently no requirement that binding schema don't introduce
> warnings in dts files. That should change when/if we get to a warning
> free state (probably per platform/family). I don't think we're close
> on any platform? (If we are, I'd like to start tracking that). It is
> good to pay attention to the warnings you get though as the schema may
> not be doing what you expect or the binding really doesn't match
> reality.
OK.
> > I do my best to avoid introducing regressions when the binding conversions
> > go upstream.
>
> Meaning you fix the dts files or massage the schema to match? If we
> just adjust schema to match, what's the point in this effort? We
> should find things wrong or ill defined.
I fix up DTS files, and fast-track those fixes, so they appear upstream before
the DT binding conversion, where possible.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 66+ messages in thread* Re: [PATCH v2 6/6] dt-bindings: drm: bridge: adi, adv7511.txt: convert to yaml
@ 2020-05-27 18:18 ` Geert Uytterhoeven
0 siblings, 0 replies; 66+ messages in thread
From: Geert Uytterhoeven @ 2020-05-27 18:18 UTC (permalink / raw)
To: Rob Herring
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Geert Uytterhoeven, Wei Xu, Laurent Pinchart,
Collabora Kernel ML, Ricardo Cañuelo, Linux ARM
Hi Rob,
On Wed, May 27, 2020 at 7:30 PM Rob Herring <robh+dt@kernel.org> wrote:
> On Tue, May 26, 2020 at 1:03 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Tue, May 26, 2020 at 3:44 AM Laurent Pinchart
> > <laurent.pinchart@ideasonboard.com> wrote:
> > > On Mon, May 25, 2020 at 09:43:35AM +0200, Ricardo Cañuelo wrote:
> > > > On jue 14-05-2020 18:22:39, Laurent Pinchart wrote:
> > > > > > If we want to be more strict and require the definition of all the
> > > > > > supplies, there will be many more DTs changes in the series, and I'm not
> > > > > > sure I'll be able to do that in a reasonable amount of time. I'm looking
> > > > > > at them and it's not always clear which regulators to use or if they are
> > > > > > even defined.
> > > > >
> > > > > We can decouple the two though (I think). The bindings should reflect
> > > > > what we consider right, and the dts files could be fixed on top.
> > > >
> > > > Do you have a suggestion on how to do this? If we decouple the two
> > > > tasks most of the work would be searching for DTs to fix and finding a
> > > > way to fix each one of them, and unless I do this _before_ the binding
> > > > conversion I'll get a lot of dtbs_check errors.
> > >
> > > Rob should answer this question as it will be his decision, but I've
> > > personally never considered non-compliant DT sources to be an obstacle
> > > to bindings conversion to YAML. The DT sources should be fixed, but I
> > > don't see it as a prerequisite (although it's a good practice).
>
> There's currently no requirement that binding schema don't introduce
> warnings in dts files. That should change when/if we get to a warning
> free state (probably per platform/family). I don't think we're close
> on any platform? (If we are, I'd like to start tracking that). It is
> good to pay attention to the warnings you get though as the schema may
> not be doing what you expect or the binding really doesn't match
> reality.
OK.
> > I do my best to avoid introducing regressions when the binding conversions
> > go upstream.
>
> Meaning you fix the dts files or massage the schema to match? If we
> just adjust schema to match, what's the point in this effort? We
> should find things wrong or ill defined.
I fix up DTS files, and fast-track those fixes, so they appear upstream before
the DT binding conversion, where possible.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 66+ messages in thread* Re: [PATCH v2 6/6] dt-bindings: drm: bridge: adi,adv7511.txt: convert to yaml
2020-05-27 18:18 ` [PATCH v2 6/6] dt-bindings: drm: bridge: adi, adv7511.txt: " Geert Uytterhoeven
@ 2020-05-28 6:36 ` Ricardo Cañuelo
-1 siblings, 0 replies; 66+ messages in thread
From: Ricardo Cañuelo @ 2020-05-28 6:36 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Rob Herring, Laurent Pinchart, Collabora Kernel ML,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, Geert Uytterhoeven, Wei Xu, michal.simek
Hi all,
On mié 27-05-2020 20:18:07, Geert Uytterhoeven wrote:
> > There's currently no requirement that binding schema don't introduce
> > warnings in dts files. That should change when/if we get to a warning
> > free state (probably per platform/family). I don't think we're close
> > on any platform? (If we are, I'd like to start tracking that). It is
> > good to pay attention to the warnings you get though as the schema may
> > not be doing what you expect or the binding really doesn't match
> > reality.
>
> OK.
>
> > > I do my best to avoid introducing regressions when the binding conversions
> > > go upstream.
> >
> > Meaning you fix the dts files or massage the schema to match? If we
> > just adjust schema to match, what's the point in this effort? We
> > should find things wrong or ill defined.
>
> I fix up DTS files, and fast-track those fixes, so they appear upstream before
> the DT binding conversion, where possible.
Thank you everyone for pitching in and for clarifying the procedure,
I'll prepare a new series with the changes that Laurent proposed
(without the patches that Geert already merged).
Cheers,
Ricardo
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCH v2 6/6] dt-bindings: drm: bridge: adi,adv7511.txt: convert to yaml
@ 2020-05-28 6:36 ` Ricardo Cañuelo
0 siblings, 0 replies; 66+ messages in thread
From: Ricardo Cañuelo @ 2020-05-28 6:36 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Geert Uytterhoeven, michal.simek, Wei Xu, Rob Herring,
Laurent Pinchart, Collabora Kernel ML, Linux ARM
Hi all,
On mié 27-05-2020 20:18:07, Geert Uytterhoeven wrote:
> > There's currently no requirement that binding schema don't introduce
> > warnings in dts files. That should change when/if we get to a warning
> > free state (probably per platform/family). I don't think we're close
> > on any platform? (If we are, I'd like to start tracking that). It is
> > good to pay attention to the warnings you get though as the schema may
> > not be doing what you expect or the binding really doesn't match
> > reality.
>
> OK.
>
> > > I do my best to avoid introducing regressions when the binding conversions
> > > go upstream.
> >
> > Meaning you fix the dts files or massage the schema to match? If we
> > just adjust schema to match, what's the point in this effort? We
> > should find things wrong or ill defined.
>
> I fix up DTS files, and fast-track those fixes, so they appear upstream before
> the DT binding conversion, where possible.
Thank you everyone for pitching in and for clarifying the procedure,
I'll prepare a new series with the changes that Laurent proposed
(without the patches that Geert already merged).
Cheers,
Ricardo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCH v2 0/6] Convert adi,adv7511.txt DT bindings to yaml
2020-05-11 11:06 ` Ricardo Cañuelo
@ 2020-05-11 11:55 ` Geert Uytterhoeven
-1 siblings, 0 replies; 66+ messages in thread
From: Geert Uytterhoeven @ 2020-05-11 11:55 UTC (permalink / raw)
To: Ricardo Cañuelo
Cc: Laurent Pinchart, Collabora Kernel ML,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, Rob Herring, Wei Xu
Hi Ricardo,
On Mon, May 11, 2020 at 1:06 PM Ricardo Cañuelo
<ricardo.canuelo@collabora.com> wrote:
> This series convert the adi,adv7511.txt DT bindings to json-schema. As a
> result of the conversion some dts files needed to be updated.
>
> The changes to the dts files are of three types:
>
> - Reordering of the I2C slave addresses list of the ADV75xx node. The
> addresses in the 'reg' property and the matching names in
> 'reg-names' for an I2C slave don't need to be in any particular
> order, but the DT schema defines these properties as a cell array
> and a string array respectively, which are ordered, so the
> definitions in the dts files must match the order in the binding.
>
> - Filling the minimum binding requirements. Most of the time this
> means creating a 'ports' node in the boards that don't define
> them. Note, however, that the purpose of this is simply to make the
> definition compliant with the binding. I didn't define any endpoints
> for the ports.
>
> - Removing unneeded properties.
>
> About the binding conversion:
>
> - The original binding covered five different devices: ADV7511,
> ADV7511W, ADV7513, ADV7533 and ADV7535. They all share a common set
> of properties but ADV7533 and ADV7535 have enough differences from
> the rest to warrant their own binding file. In v1 I modelled all the
> properties constraints for all five devices in a single file but it
> turned out a bit too complex. Splitting the binding into one for
> ADV7511/11W/13 and another for ADV7533/35 makes them much easier to
> read and maintain.
Thanks for your series!
> Patches 1/6 to 5/6 contain the dts changes. Patch 6/6 contains the
> binding conversion.
If the binding conversion is accepted, I can queue the below in
renesas-fix-for-v5.7, to avoid the conversion introducing a regression.
> arm64: dts: renesas: make hdmi encoder nodes compliant with DT
> bindings
> ARM: dts: renesas: make hdmi encoder nodes compliant with DT bindings
> ARM: dts: iwg20d-q7-dbcm-ca: remove unneeded properties in hdmi@39
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 66+ messages in thread* Re: [PATCH v2 0/6] Convert adi,adv7511.txt DT bindings to yaml
@ 2020-05-11 11:55 ` Geert Uytterhoeven
0 siblings, 0 replies; 66+ messages in thread
From: Geert Uytterhoeven @ 2020-05-11 11:55 UTC (permalink / raw)
To: Ricardo Cañuelo
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Wei Xu, Rob Herring, Laurent Pinchart, Collabora Kernel ML,
Linux ARM
Hi Ricardo,
On Mon, May 11, 2020 at 1:06 PM Ricardo Cañuelo
<ricardo.canuelo@collabora.com> wrote:
> This series convert the adi,adv7511.txt DT bindings to json-schema. As a
> result of the conversion some dts files needed to be updated.
>
> The changes to the dts files are of three types:
>
> - Reordering of the I2C slave addresses list of the ADV75xx node. The
> addresses in the 'reg' property and the matching names in
> 'reg-names' for an I2C slave don't need to be in any particular
> order, but the DT schema defines these properties as a cell array
> and a string array respectively, which are ordered, so the
> definitions in the dts files must match the order in the binding.
>
> - Filling the minimum binding requirements. Most of the time this
> means creating a 'ports' node in the boards that don't define
> them. Note, however, that the purpose of this is simply to make the
> definition compliant with the binding. I didn't define any endpoints
> for the ports.
>
> - Removing unneeded properties.
>
> About the binding conversion:
>
> - The original binding covered five different devices: ADV7511,
> ADV7511W, ADV7513, ADV7533 and ADV7535. They all share a common set
> of properties but ADV7533 and ADV7535 have enough differences from
> the rest to warrant their own binding file. In v1 I modelled all the
> properties constraints for all five devices in a single file but it
> turned out a bit too complex. Splitting the binding into one for
> ADV7511/11W/13 and another for ADV7533/35 makes them much easier to
> read and maintain.
Thanks for your series!
> Patches 1/6 to 5/6 contain the dts changes. Patch 6/6 contains the
> binding conversion.
If the binding conversion is accepted, I can queue the below in
renesas-fix-for-v5.7, to avoid the conversion introducing a regression.
> arm64: dts: renesas: make hdmi encoder nodes compliant with DT
> bindings
> ARM: dts: renesas: make hdmi encoder nodes compliant with DT bindings
> ARM: dts: iwg20d-q7-dbcm-ca: remove unneeded properties in hdmi@39
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 66+ messages in thread