| Message ID | 20180220231046.32638-1-laurent.pinchart+renesas@ideasonboard.com |
|---|---|
| Headers | show |
| Series | R-Car DU: Convert LVDS code to bridge driver | expand |
On Wed, Feb 21, 2018 at 01:10:37AM +0200, Laurent Pinchart wrote: > From: Pantelis Antoniou <pantelis.antoniou@konsulko.com> > > The changeset helpers are easier to use, use them instead of > using the static property. > > Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com> > Acked-by: Wolfram Sang <wsa@the-dreams.de> My ack still holds. Good luck pushing this series!
On Wed, Feb 21, 2018 at 01:10:30AM +0200, Laurent Pinchart wrote: > Hello, > > This patch series addresses a design mistake that dates back from the initial > DU support. Support for the LVDS encoders, which are IP cores separate from > the DU, was bundled in the DU driver. Worse, both the DU and LVDS were > described through a single DT node. > > To fix the, patches 01/16 and 02/16 define new DT bindings for the LVDS > encoders, and deprecate their description inside the DU bindings. To retain > backward compatibility with existing DT, patches 03/16 to 08/16 then patch the > device tree at runtime to convert the legacy bindings to the new ones. > > With the DT side addressed, patch 09/16 converts the LVDS support code to a > separate bridge driver. Patches 11/16 to 16/16 then update all the device tree > sources to the new DU and LVDS encoders bindings. > > I decided to go for live DT patching in patch 08/16 because implementing > support for both the legacy and new bindings in the driver would have been > very intrusive, and prevented further cleanups. This version relies more > heavily on overlays to avoid touching the internals of the OF core compared to > v2, even if manual fixes to the device tree are still needed. > > Compared to v3, this series uses the OF changeset API to update properties > instead of accessing the internals of the property structure. This removes the > local implementation of functions to look up nodes by path and update > properties. In order to do this, I pulled in Pantelis' patch series titled > "[PATCH v2 0/5] of: dynamic: Changesets helpers & fixes" at Rob's request, and > rebased it while taking two small review comments into account. > > Rob, I'd like this series to be merged in v4.17. As the changeset helpers are > now a dependency, I'd need you to merge them early (ideally on top of > v4.16-rc1) and provide a stable branch, or get your ack to merge them through > Dave's tree if they don't conflict with what you have and will queue for > v4.17. > > This version also drops the small fix to the Porter board device tree that has > been queued for v4.17 already. > > Compared to v2, the biggest change is in patch 03/16. Following Rob's and > Frank's reviews it was clear that modifying the unflattened DT structure of > the overlay before applying it wasn't popular. I have thus decided to use one > overlay source per SoC to move as much of the DT changes to the overlay as > possible, and only perform manual modifications (that are still needed as some > of the information is board-specific) on the system DT after applying the > overlay. As a result the overlay is parsed and applied without being modified. > > Compared to v1, this series update the r8a7792 and r8a7794 device tree sources > and incorporate review feedback as described by the changelogs of individual > patches. > > > Laurent Pinchart (11): > dt-bindings: display: renesas: Add R-Car LVDS encoder DT bindings > dt-bindings: display: renesas: Deprecate LVDS support in the DU > bindings > drm: rcar-du: Fix legacy DT to create LVDS encoder nodes > drm: rcar-du: Convert LVDS encoder code to bridge driver > ARM: dts: r8a7790: Convert to new LVDS DT bindings > ARM: dts: r8a7791: Convert to new LVDS DT bindings > ARM: dts: r8a7792: Convert to new DU DT bindings > ARM: dts: r8a7793: Convert to new LVDS DT bindings > ARM: dts: r8a7794: Convert to new DU DT bindings > arm64: dts: renesas: r8a7795: Convert to new LVDS DT bindings > arm64: dts: renesas: r8a7796: Convert to new LVDS DT bindings I have marked the dts patches above as deferred as they depend on the driver changes not to cause a regression. Please repost them or otherwise ping me once the driver dependencies are present in an rc release. I am assuming that the other patches in this series are not targeted at the renesas tree. > > Pantelis Antoniou (5): > of: dynamic: Add __of_node_dupv() > of: changesets: Introduce changeset helper methods > of: changeset: Add of_changeset_node_move method > of: unittest: changeset helpers > i2c: demux: Use changeset helpers for clarity ... -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Feb 20, 2018 at 5:10 PM, Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> wrote: > The internal LVDS encoders now have their own DT bindings. Before > switching the driver infrastructure to those new bindings, implement > backward-compatibility through live DT patching. > > Patching is disabled and will be enabled along with support for the new > DT bindings in the DU driver. > > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> > --- [...] > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dts b/drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dts > new file mode 100644 > index 000000000000..6ebb355b652a > --- /dev/null > +++ b/drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dts > @@ -0,0 +1,81 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * rcar_du_of_lvds_r8a7790.dts - Legacy LVDS DT bindings conversion for R8A7790 > + * > + * Copyright (C) 2018 Laurent Pinchart <laurent.pinchart@ideasonboard.com> > + * > + * Based on work from Jyri Sarha <jsarha@ti.com> > + * Copyright (C) 2015 Texas Instruments > + */ > + > +#include <dt-bindings/clock/renesas-cpg-mssr.h> Doesn't seem to be used in any of these. Otherwise, Reviewed-by: Rob Herring <robh@kernel.org> > + > +/dts-v1/; > +/plugin/; > +/ { > + fragment@0 { > + target-path = "/"; > + __overlay__ { > + #address-cells = <2>; > + #size-cells = <2>; > + > + lvds@feb90000 { > + compatible = "renesas,r8a7790-lvds"; > + reg = <0 0xfeb90000 0 0x1c>; > + > + ports { > + #address-cells = <1>; > + #size-cells = <0>; > + > + port@0 { > + reg = <0>; > + lvds0_input: endpoint { > + }; > + }; > + port@1 { > + reg = <1>; > + lvds0_out: endpoint { > + }; > + }; > + }; > + }; > + > + lvds@feb94000 { > + compatible = "renesas,r8a7790-lvds"; > + reg = <0 0xfeb94000 0 0x1c>; > + > + ports { > + #address-cells = <1>; > + #size-cells = <0>; > + > + port@0 { > + reg = <0>; > + lvds1_input: endpoint { > + }; > + }; > + port@1 { > + reg = <1>; > + lvds1_out: endpoint { > + }; > + }; > + }; > + }; > + }; > + }; > + > + fragment@1 { > + target-path = "/display@feb00000/ports"; > + __overlay__ { > + port@1 { > + endpoint { > + remote-endpoint = <&lvds0_input>; > + }; > + }; > + port@2 { > + endpoint { > + remote-endpoint = <&lvds1_input>; > + }; > + }; > + }; > + }; > +}; -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Rob, On Thursday, 22 February 2018 01:28:48 EET Rob Herring wrote: > On Tue, Feb 20, 2018 at 5:10 PM, Laurent Pinchart wrote: > > The internal LVDS encoders now have their own DT bindings. Before > > switching the driver infrastructure to those new bindings, implement > > backward-compatibility through live DT patching. > > > > Patching is disabled and will be enabled along with support for the new > > DT bindings in the DU driver. > > > > Signed-off-by: Laurent Pinchart > > <laurent.pinchart+renesas@ideasonboard.com> > > --- > > [...] > > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dts > > b/drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dts new file mode > > 100644 > > index 000000000000..6ebb355b652a > > --- /dev/null > > +++ b/drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dts > > @@ -0,0 +1,81 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * rcar_du_of_lvds_r8a7790.dts - Legacy LVDS DT bindings conversion for > > R8A7790 > > + * > > + * Copyright (C) 2018 Laurent Pinchart > > <laurent.pinchart@ideasonboard.com> > > + * > > + * Based on work from Jyri Sarha <jsarha@ti.com> > > + * Copyright (C) 2015 Texas Instruments > > + */ > > + > > +#include <dt-bindings/clock/renesas-cpg-mssr.h> > > Doesn't seem to be used in any of these. It's a leftover from a previous test. I'll remove it in all the .dts files. > Otherwise, > > Reviewed-by: Rob Herring <robh@kernel.org> > > > + > > +/dts-v1/; > > +/plugin/; > > +/ { > > + fragment@0 { > > + target-path = "/"; > > + __overlay__ { > > + #address-cells = <2>; > > + #size-cells = <2>; > > + > > + lvds@feb90000 { > > + compatible = "renesas,r8a7790-lvds"; > > + reg = <0 0xfeb90000 0 0x1c>; > > + > > + ports { > > + #address-cells = <1>; > > + #size-cells = <0>; > > + > > + port@0 { > > + reg = <0>; > > + lvds0_input: endpoint { > > + }; > > + }; > > + port@1 { > > + reg = <1>; > > + lvds0_out: endpoint { > > + }; > > + }; > > + }; > > + }; > > + > > + lvds@feb94000 { > > + compatible = "renesas,r8a7790-lvds"; > > + reg = <0 0xfeb94000 0 0x1c>; > > + > > + ports { > > + #address-cells = <1>; > > + #size-cells = <0>; > > + > > + port@0 { > > + reg = <0>; > > + lvds1_input: endpoint { > > + }; > > + }; > > + port@1 { > > + reg = <1>; > > + lvds1_out: endpoint { > > + }; > > + }; > > + }; > > + }; > > + }; > > + }; > > + > > + fragment@1 { > > + target-path = "/display@feb00000/ports"; > > + __overlay__ { > > + port@1 { > > + endpoint { > > + remote-endpoint = <&lvds0_input>; > > + }; > > + }; > > + port@2 { > > + endpoint { > > + remote-endpoint = <&lvds1_input>; > > + }; > > + }; > > + }; > > + }; > > +};
On 02/20/18 15:10, Laurent Pinchart wrote: > Hello, > > This patch series addresses a design mistake that dates back from the initial > DU support. Support for the LVDS encoders, which are IP cores separate from > the DU, was bundled in the DU driver. Worse, both the DU and LVDS were > described through a single DT node. > > To fix the, patches 01/16 and 02/16 define new DT bindings for the LVDS > encoders, and deprecate their description inside the DU bindings. To retain > backward compatibility with existing DT, patches 03/16 to 08/16 then patch the > device tree at runtime to convert the legacy bindings to the new ones. > > With the DT side addressed, patch 09/16 converts the LVDS support code to a > separate bridge driver. Patches 11/16 to 16/16 then update all the device tree > sources to the new DU and LVDS encoders bindings. > > I decided to go for live DT patching in patch 08/16 because implementing > support for both the legacy and new bindings in the driver would have been > very intrusive, and prevented further cleanups. This version relies more > heavily on overlays to avoid touching the internals of the OF core compared to > v2, even if manual fixes to the device tree are still needed. > > Compared to v3, this series uses the OF changeset API to update properties > instead of accessing the internals of the property structure. This removes the > local implementation of functions to look up nodes by path and update > properties. In order to do this, I pulled in Pantelis' patch series titled > "[PATCH v2 0/5] of: dynamic: Changesets helpers & fixes" at Rob's request, and > rebased it while taking two small review comments into account. Wait a minute! Why are you putting a patch set to modify core devicetree in the middle of a driver series. Please pull it out to a separate series. I'll try to look at the patches, as they are in this series, sometime tomorrow. I have a vague memory of unresolved issues from the last time they were proposed. Thanks, Frank > > Rob, I'd like this series to be merged in v4.17. As the changeset helpers are > now a dependency, I'd need you to merge them early (ideally on top of > v4.16-rc1) and provide a stable branch, or get your ack to merge them through > Dave's tree if they don't conflict with what you have and will queue for > v4.17. > > This version also drops the small fix to the Porter board device tree that has > been queued for v4.17 already. > > Compared to v2, the biggest change is in patch 03/16. Following Rob's and > Frank's reviews it was clear that modifying the unflattened DT structure of > the overlay before applying it wasn't popular. I have thus decided to use one > overlay source per SoC to move as much of the DT changes to the overlay as > possible, and only perform manual modifications (that are still needed as some > of the information is board-specific) on the system DT after applying the > overlay. As a result the overlay is parsed and applied without being modified. > > Compared to v1, this series update the r8a7792 and r8a7794 device tree sources > and incorporate review feedback as described by the changelogs of individual > patches. > > > Laurent Pinchart (11): > dt-bindings: display: renesas: Add R-Car LVDS encoder DT bindings > dt-bindings: display: renesas: Deprecate LVDS support in the DU > bindings > drm: rcar-du: Fix legacy DT to create LVDS encoder nodes > drm: rcar-du: Convert LVDS encoder code to bridge driver > ARM: dts: r8a7790: Convert to new LVDS DT bindings > ARM: dts: r8a7791: Convert to new LVDS DT bindings > ARM: dts: r8a7792: Convert to new DU DT bindings > ARM: dts: r8a7793: Convert to new LVDS DT bindings > ARM: dts: r8a7794: Convert to new DU DT bindings > arm64: dts: renesas: r8a7795: Convert to new LVDS DT bindings > arm64: dts: renesas: r8a7796: Convert to new LVDS DT bindings > > Pantelis Antoniou (5): > of: dynamic: Add __of_node_dupv() > of: changesets: Introduce changeset helper methods > of: changeset: Add of_changeset_node_move method > of: unittest: changeset helpers > i2c: demux: Use changeset helpers for clarity > > .../bindings/display/bridge/renesas,lvds.txt | 56 +++ > .../devicetree/bindings/display/renesas,du.txt | 31 +- > MAINTAINERS | 1 + > arch/arm/boot/dts/r8a7790-lager.dts | 22 +- > arch/arm/boot/dts/r8a7790.dtsi | 64 ++- > arch/arm/boot/dts/r8a7791-koelsch.dts | 10 +- > arch/arm/boot/dts/r8a7791-porter.dts | 16 +- > arch/arm/boot/dts/r8a7791.dtsi | 36 +- > arch/arm/boot/dts/r8a7792.dtsi | 1 - > arch/arm/boot/dts/r8a7793-gose.dts | 10 +- > arch/arm/boot/dts/r8a7793.dtsi | 37 +- > arch/arm/boot/dts/r8a7794.dtsi | 1 - > .../boot/dts/renesas/r8a7795-es1-salvator-x.dts | 3 +- > arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 3 +- > arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 3 +- > .../arm64/boot/dts/renesas/r8a7795-salvator-xs.dts | 3 +- > arch/arm64/boot/dts/renesas/r8a7795.dtsi | 36 +- > arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts | 3 +- > arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 3 +- > arch/arm64/boot/dts/renesas/r8a7796.dtsi | 36 +- > drivers/gpu/drm/rcar-du/Kconfig | 6 +- > drivers/gpu/drm/rcar-du/Makefile | 10 +- > drivers/gpu/drm/rcar-du/rcar_du_drv.c | 21 +- > drivers/gpu/drm/rcar-du/rcar_du_drv.h | 5 - > drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 175 +------ > drivers/gpu/drm/rcar-du/rcar_du_encoder.h | 12 - > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 14 +- > drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c | 93 ---- > drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h | 24 - > drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 238 ---------- > drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h | 64 --- > drivers/gpu/drm/rcar-du/rcar_du_of.c | 307 ++++++++++++ > drivers/gpu/drm/rcar-du/rcar_du_of.h | 20 + > .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dts | 81 ++++ > .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dts | 55 +++ > .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dts | 55 +++ > .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dts | 55 +++ > .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dts | 55 +++ > drivers/gpu/drm/rcar-du/rcar_lvds.c | 524 +++++++++++++++++++++ > drivers/i2c/muxes/i2c-demux-pinctrl.c | 12 +- > drivers/of/dynamic.c | 317 ++++++++++++- > drivers/of/unittest.c | 54 +++ > include/linux/of.h | 337 +++++++++++++ > 43 files changed, 2199 insertions(+), 710 deletions(-) > create mode 100644 Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt > delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c > delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h > delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c > delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h > create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of.c > create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of.h > create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dts > create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dts > create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dts > create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dts > create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dts > create mode 100644 drivers/gpu/drm/rcar-du/rcar_lvds.c > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Frank, On Thursday, 22 February 2018 08:07:14 EET Frank Rowand wrote: > On 02/20/18 15:10, Laurent Pinchart wrote: > > Hello, > > > > This patch series addresses a design mistake that dates back from the > > initial DU support. Support for the LVDS encoders, which are IP cores > > separate from the DU, was bundled in the DU driver. Worse, both the DU > > and LVDS were described through a single DT node. > > > > To fix the, patches 01/16 and 02/16 define new DT bindings for the LVDS > > encoders, and deprecate their description inside the DU bindings. To > > retain backward compatibility with existing DT, patches 03/16 to 08/16 > > then patch the device tree at runtime to convert the legacy bindings to > > the new ones. > > > > With the DT side addressed, patch 09/16 converts the LVDS support code to > > a separate bridge driver. Patches 11/16 to 16/16 then update all the > > device tree sources to the new DU and LVDS encoders bindings. > > > > I decided to go for live DT patching in patch 08/16 because implementing > > support for both the legacy and new bindings in the driver would have been > > very intrusive, and prevented further cleanups. This version relies more > > heavily on overlays to avoid touching the internals of the OF core > > compared to v2, even if manual fixes to the device tree are still needed. > > > > Compared to v3, this series uses the OF changeset API to update properties > > instead of accessing the internals of the property structure. This removes > > the local implementation of functions to look up nodes by path and update > > properties. In order to do this, I pulled in Pantelis' patch series > > titled "[PATCH v2 0/5] of: dynamic: Changesets helpers & fixes" at Rob's > > request, and rebased it while taking two small review comments into > > account. > > Wait a minute! Why are you putting a patch set to modify core devicetree > in the middle of a driver series. Please pull it out to a separate series. Because Rob asked for the driver-local implementation of the property add function to be replaced by Pantelis' series. I want to get the LVDS changes in v4.17 and asked Rob whether I could then take the OF changeset patches merged through the DRM tree, and he didn't object. If that causes an issue I'll switch back to the driver-local implementation to get the driver changes merged, split the OF changeset series out, and then move to the OF changeset API once merged. Would you prefer that ? > I'll try to look at the patches, as they are in this series, sometime > tomorrow. I have a vague memory of unresolved issues from the last > time they were proposed. > > > Rob, I'd like this series to be merged in v4.17. As the changeset helpers > > are now a dependency, I'd need you to merge them early (ideally on top of > > v4.16-rc1) and provide a stable branch, or get your ack to merge them > > through Dave's tree if they don't conflict with what you have and will > > queue for v4.17. > > > > This version also drops the small fix to the Porter board device tree that > > has been queued for v4.17 already. > > > > Compared to v2, the biggest change is in patch 03/16. Following Rob's and > > Frank's reviews it was clear that modifying the unflattened DT structure > > of the overlay before applying it wasn't popular. I have thus decided to > > use one overlay source per SoC to move as much of the DT changes to the > > overlay as possible, and only perform manual modifications (that are > > still needed as some of the information is board-specific) on the system > > DT after applying the overlay. As a result the overlay is parsed and > > applied without being modified. > > > > Compared to v1, this series update the r8a7792 and r8a7794 device tree > > sources and incorporate review feedback as described by the changelogs of > > individual patches. > > > > Laurent Pinchart (11): > > dt-bindings: display: renesas: Add R-Car LVDS encoder DT bindings > > dt-bindings: display: renesas: Deprecate LVDS support in the DU > > bindings > > drm: rcar-du: Fix legacy DT to create LVDS encoder nodes > > drm: rcar-du: Convert LVDS encoder code to bridge driver > > ARM: dts: r8a7790: Convert to new LVDS DT bindings > > ARM: dts: r8a7791: Convert to new LVDS DT bindings > > ARM: dts: r8a7792: Convert to new DU DT bindings > > ARM: dts: r8a7793: Convert to new LVDS DT bindings > > ARM: dts: r8a7794: Convert to new DU DT bindings > > arm64: dts: renesas: r8a7795: Convert to new LVDS DT bindings > > arm64: dts: renesas: r8a7796: Convert to new LVDS DT bindings > > > > Pantelis Antoniou (5): > > of: dynamic: Add __of_node_dupv() > > of: changesets: Introduce changeset helper methods > > of: changeset: Add of_changeset_node_move method > > of: unittest: changeset helpers > > i2c: demux: Use changeset helpers for clarity > > > > .../bindings/display/bridge/renesas,lvds.txt | 56 +++ > > .../devicetree/bindings/display/renesas,du.txt | 31 +- > > MAINTAINERS | 1 + > > arch/arm/boot/dts/r8a7790-lager.dts | 22 +- > > arch/arm/boot/dts/r8a7790.dtsi | 64 ++- > > arch/arm/boot/dts/r8a7791-koelsch.dts | 10 +- > > arch/arm/boot/dts/r8a7791-porter.dts | 16 +- > > arch/arm/boot/dts/r8a7791.dtsi | 36 +- > > arch/arm/boot/dts/r8a7792.dtsi | 1 - > > arch/arm/boot/dts/r8a7793-gose.dts | 10 +- > > arch/arm/boot/dts/r8a7793.dtsi | 37 +- > > arch/arm/boot/dts/r8a7794.dtsi | 1 - > > .../boot/dts/renesas/r8a7795-es1-salvator-x.dts | 3 +- > > arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 3 +- > > arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 3 +- > > .../arm64/boot/dts/renesas/r8a7795-salvator-xs.dts | 3 +- > > arch/arm64/boot/dts/renesas/r8a7795.dtsi | 36 +- > > arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts | 3 +- > > arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 3 +- > > arch/arm64/boot/dts/renesas/r8a7796.dtsi | 36 +- > > drivers/gpu/drm/rcar-du/Kconfig | 6 +- > > drivers/gpu/drm/rcar-du/Makefile | 10 +- > > drivers/gpu/drm/rcar-du/rcar_du_drv.c | 21 +- > > drivers/gpu/drm/rcar-du/rcar_du_drv.h | 5 - > > drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 175 +------ > > drivers/gpu/drm/rcar-du/rcar_du_encoder.h | 12 - > > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 14 +- > > drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c | 93 ---- > > drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h | 24 - > > drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 238 ---------- > > drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h | 64 --- > > drivers/gpu/drm/rcar-du/rcar_du_of.c | 307 ++++++++++++ > > drivers/gpu/drm/rcar-du/rcar_du_of.h | 20 + > > .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dts | 81 ++++ > > .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dts | 55 +++ > > .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dts | 55 +++ > > .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dts | 55 +++ > > .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dts | 55 +++ > > drivers/gpu/drm/rcar-du/rcar_lvds.c | 524 ++++++++++++++++ > > drivers/i2c/muxes/i2c-demux-pinctrl.c | 12 +- > > drivers/of/dynamic.c | 317 ++++++++++++- > > drivers/of/unittest.c | 54 +++ > > include/linux/of.h | 337 +++++++++++++ > > 43 files changed, 2199 insertions(+), 710 deletions(-) > > create mode 100644 > > Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt delete > > mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c > > delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h > > delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c > > delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h > > create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of.c > > create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of.h > > create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dts > > create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dts > > create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dts > > create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dts > > create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dts > > create mode 100644 drivers/gpu/drm/rcar-du/rcar_lvds.c
Hi Laurent, On 02/22/18 02:25, Laurent Pinchart wrote: > Hi Frank, > > On Thursday, 22 February 2018 08:07:14 EET Frank Rowand wrote: >> On 02/20/18 15:10, Laurent Pinchart wrote: >>> Hello, >>> >>> This patch series addresses a design mistake that dates back from the >>> initial DU support. Support for the LVDS encoders, which are IP cores >>> separate from the DU, was bundled in the DU driver. Worse, both the DU >>> and LVDS were described through a single DT node. >>> >>> To fix the, patches 01/16 and 02/16 define new DT bindings for the LVDS >>> encoders, and deprecate their description inside the DU bindings. To >>> retain backward compatibility with existing DT, patches 03/16 to 08/16 >>> then patch the device tree at runtime to convert the legacy bindings to >>> the new ones. >>> >>> With the DT side addressed, patch 09/16 converts the LVDS support code to >>> a separate bridge driver. Patches 11/16 to 16/16 then update all the >>> device tree sources to the new DU and LVDS encoders bindings. >>> >>> I decided to go for live DT patching in patch 08/16 because implementing >>> support for both the legacy and new bindings in the driver would have been >>> very intrusive, and prevented further cleanups. This version relies more >>> heavily on overlays to avoid touching the internals of the OF core >>> compared to v2, even if manual fixes to the device tree are still needed. >>> >>> Compared to v3, this series uses the OF changeset API to update properties >>> instead of accessing the internals of the property structure. This removes >>> the local implementation of functions to look up nodes by path and update >>> properties. In order to do this, I pulled in Pantelis' patch series >>> titled "[PATCH v2 0/5] of: dynamic: Changesets helpers & fixes" at Rob's >>> request, and rebased it while taking two small review comments into >>> account. >> >> Wait a minute! Why are you putting a patch set to modify core devicetree >> in the middle of a driver series. Please pull it out to a separate series. > > Because Rob asked for the driver-local implementation of the property add > function to be replaced by Pantelis' series. I want to get the LVDS changes in > v4.17 and asked Rob whether I could then take the OF changeset patches merged > through the DRM tree, and he didn't object. If that causes an issue I'll > switch back to the driver-local implementation to get the driver changes > merged, split the OF changeset series out, and then move to the OF changeset > API once merged. Would you prefer that ? You have already created a new version of the R-Car patches without the set of patches that I was objecting to here. So this is somewhat just an academic comment. As I mentioned in the v6 thread, I am coming back here to clean up loose ends, and explain why I had the reaction I had. Basically, this is a process issue to me. (1) The patch set from Pantelis is "hidden" in the driver patch series. When viewing collapsed threads (which is my normal mode to avoid getting overwhelmed by the vast volume of email I scan), the Pantelis patch set is totally invisible. If the R-Car driver patch series had not had me on the to: list, there is a very good chance I would not have noticed it. Or noticed in a more delayed time frame. And the same applies to anyone else who might be subscribed to the devicetree mail list. If the Pantelis patch series was split out into a separate patch set then it would be more visible on the list. (2) There is no good way to indicate in the email subject lines for the Pantelis patches that they are version 3 of the series, since they are also version 4 of the R-Car patch series. If one reads the patch 0/0 header carefully, and/or the other Pantelis patch comment headers carefully, and then does a little detective work, it is possible to find version 2 of the Pantelis patch series, and thus be able to track the full history. If just glancing at each individual patch email subject, scanning the patch comment, and spending more time reading the body of the patch, it would be very easy to overlook the existence of the previous versions on the mail list. (2b) Small quibble: if the Pantelis patches were in a separate series, with v3 in the subject header, then you would have normally put a "changes since v2" section in the patch comment header, which would have been more visible and less cryptic than what you wrote, which was: ... Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com> [Fixed memory leak in __of_changeset_add_update_property_copy()] Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> --- drivers/of/dynamic.c | 222 ++++++++++++++++++++++++++++++++++ include/linux/of.h | 328 +++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 550 insertions(+) My original scan of version 2 and then the email in this series had me questioning whether the two open issues from patch 2 had been addressed (yes, patch 0/16 did explicitly mention that 2 review comments had been taken into account, so you can point at my poor reading comprehension). (3) This is totally unrelated to your patch series, but I'm leaving a bread crumb trail here. Rob pointed you at a patch series that was not the most recent version. When this patch series appears again, there already is a version 3 subset of it, but it is still labeled as being version 2, and also has outstanding un-addressed issues. ("[PATCH v2 1/2] of: dynamic: Add __of_node_dupv()", 11/04/16) -Frank -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Frank, On Friday, 23 February 2018 05:20:43 EET Frank Rowand wrote: > On 02/22/18 02:25, Laurent Pinchart wrote: > > On Thursday, 22 February 2018 08:07:14 EET Frank Rowand wrote: > >> On 02/20/18 15:10, Laurent Pinchart wrote: > >>> Hello, > >>> > >>> This patch series addresses a design mistake that dates back from the > >>> initial DU support. Support for the LVDS encoders, which are IP cores > >>> separate from the DU, was bundled in the DU driver. Worse, both the DU > >>> and LVDS were described through a single DT node. > >>> > >>> To fix the, patches 01/16 and 02/16 define new DT bindings for the LVDS > >>> encoders, and deprecate their description inside the DU bindings. To > >>> retain backward compatibility with existing DT, patches 03/16 to 08/16 > >>> then patch the device tree at runtime to convert the legacy bindings to > >>> the new ones. > >>> > >>> With the DT side addressed, patch 09/16 converts the LVDS support code > >>> to a separate bridge driver. Patches 11/16 to 16/16 then update all the > >>> device tree sources to the new DU and LVDS encoders bindings. > >>> > >>> I decided to go for live DT patching in patch 08/16 because implementing > >>> support for both the legacy and new bindings in the driver would have > >>> been very intrusive, and prevented further cleanups. This version relies > >>> more heavily on overlays to avoid touching the internals of the OF core > >>> compared to v2, even if manual fixes to the device tree are still > >>> needed. > >>> > >>> Compared to v3, this series uses the OF changeset API to update > >>> properties instead of accessing the internals of the property structure. > >>> This removes the local implementation of functions to look up nodes by > >>> path and update properties. In order to do this, I pulled in Pantelis' > >>> patch series titled "[PATCH v2 0/5] of: dynamic: Changesets helpers & > >>> fixes" at Rob's request, and rebased it while taking two small review > >>> comments into account. > >> > >> Wait a minute! Why are you putting a patch set to modify core devicetree > >> in the middle of a driver series. Please pull it out to a separate > >> series. > > > > Because Rob asked for the driver-local implementation of the property add > > function to be replaced by Pantelis' series. I want to get the LVDS > > changes in v4.17 and asked Rob whether I could then take the OF changeset > > patches merged through the DRM tree, and he didn't object. If that causes > > an issue I'll switch back to the driver-local implementation to get the > > driver changes merged, split the OF changeset series out, and then move > > to the OF changeset API once merged. Would you prefer that ? > > You have already created a new version of the R-Car patches without the > set of patches that I was objecting to here. So this is somewhat just > an academic comment. > > As I mentioned in the v6 thread, I am coming back here to clean up loose > ends, and explain why I had the reaction I had. Basically, this is a > process issue to me. > > (1) The patch set from Pantelis is "hidden" in the driver patch series. > When viewing collapsed threads (which is my normal mode to avoid getting > overwhelmed by the vast volume of email I scan), the Pantelis patch set > is totally invisible. If the R-Car driver patch series had not had me > on the to: list, there is a very good chance I would not have noticed > it. Or noticed in a more delayed time frame. And the same applies to > anyone else who might be subscribed to the devicetree mail list. If > the Pantelis patch series was split out into a separate patch set then > it would be more visible on the list. > > (2) There is no good way to indicate in the email subject lines for > the Pantelis patches that they are version 3 of the series, since > they are also version 4 of the R-Car patch series. If one reads the > patch 0/0 header carefully, and/or the other Pantelis patch comment > headers carefully, and then does a little detective work, it is > possible to find version 2 of the Pantelis patch series, and thus > be able to track the full history. If just glancing at each > individual patch email subject, scanning the patch comment, and > spending more time reading the body of the patch, it would be > very easy to overlook the existence of the previous versions on > the mail list. > > (2b) Small quibble: if the Pantelis patches were in a separate series, > with v3 in the subject header, then you would have normally put > a "changes since v2" section in the patch comment header, which would > have been more visible and less cryptic than what you wrote, which was: > > ... > > Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com> > [Fixed memory leak in __of_changeset_add_update_property_copy()] > Signed-off-by: Laurent Pinchart > <laurent.pinchart+renesas@ideasonboard.com> > --- > drivers/of/dynamic.c | 222 ++++++++++++++++++++++++++++++++++ > include/linux/of.h | 328 +++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 550 insertions(+) > > My original scan of version 2 and then the email in this series had me > questioning whether the two open issues from patch 2 had been addressed > (yes, patch 0/16 did explicitly mention that 2 review comments had been > taken into account, so you can point at my poor reading comprehension). All points dully noted, I'll make sure not to include similar patches in the middle of a driver series should I need to rework a patch series previously posted by someone else. I assume your comments also apply to patches to drivers/of/ that are developed as part of a drivers series, not merely pulled in it ? I have mixed feelings about this, as in many subsystems changes to the core require at least one user. Always splitting core and driver changes in separate series would thus often be impractical. I doubt we will find a single process that will suit all subsystem maintainers, so maybe this should be a per-subsystem decision ? > (3) This is totally unrelated to your patch series, but I'm leaving a bread > crumb trail here. Rob pointed you at a patch series that was not the most > recent version. When this patch series appears again, there already is > a version 3 subset of it, but it is still labeled as being version 2, and > also has outstanding un-addressed issues. ("[PATCH v2 1/2] of: dynamic: > Add __of_node_dupv()", 11/04/16) Ah, thank you for the information. I was looking for a v3 but missed that one as it was labeled v2.
On 02/23/18 01:25, Laurent Pinchart wrote: > Hi Frank, > > On Friday, 23 February 2018 05:20:43 EET Frank Rowand wrote: >> On 02/22/18 02:25, Laurent Pinchart wrote: >>> On Thursday, 22 February 2018 08:07:14 EET Frank Rowand wrote: >>>> On 02/20/18 15:10, Laurent Pinchart wrote: >>>>> Hello, >>>>> >>>>> This patch series addresses a design mistake that dates back from the >>>>> initial DU support. Support for the LVDS encoders, which are IP cores >>>>> separate from the DU, was bundled in the DU driver. Worse, both the DU >>>>> and LVDS were described through a single DT node. >>>>> >>>>> To fix the, patches 01/16 and 02/16 define new DT bindings for the LVDS >>>>> encoders, and deprecate their description inside the DU bindings. To >>>>> retain backward compatibility with existing DT, patches 03/16 to 08/16 >>>>> then patch the device tree at runtime to convert the legacy bindings to >>>>> the new ones. >>>>> >>>>> With the DT side addressed, patch 09/16 converts the LVDS support code >>>>> to a separate bridge driver. Patches 11/16 to 16/16 then update all the >>>>> device tree sources to the new DU and LVDS encoders bindings. >>>>> >>>>> I decided to go for live DT patching in patch 08/16 because implementing >>>>> support for both the legacy and new bindings in the driver would have >>>>> been very intrusive, and prevented further cleanups. This version relies >>>>> more heavily on overlays to avoid touching the internals of the OF core >>>>> compared to v2, even if manual fixes to the device tree are still >>>>> needed. >>>>> >>>>> Compared to v3, this series uses the OF changeset API to update >>>>> properties instead of accessing the internals of the property structure. >>>>> This removes the local implementation of functions to look up nodes by >>>>> path and update properties. In order to do this, I pulled in Pantelis' >>>>> patch series titled "[PATCH v2 0/5] of: dynamic: Changesets helpers & >>>>> fixes" at Rob's request, and rebased it while taking two small review >>>>> comments into account. >>>> >>>> Wait a minute! Why are you putting a patch set to modify core devicetree >>>> in the middle of a driver series. Please pull it out to a separate >>>> series. >>> >>> Because Rob asked for the driver-local implementation of the property add >>> function to be replaced by Pantelis' series. I want to get the LVDS >>> changes in v4.17 and asked Rob whether I could then take the OF changeset >>> patches merged through the DRM tree, and he didn't object. If that causes >>> an issue I'll switch back to the driver-local implementation to get the >>> driver changes merged, split the OF changeset series out, and then move >>> to the OF changeset API once merged. Would you prefer that ? >> >> You have already created a new version of the R-Car patches without the >> set of patches that I was objecting to here. So this is somewhat just >> an academic comment. >> >> As I mentioned in the v6 thread, I am coming back here to clean up loose >> ends, and explain why I had the reaction I had. Basically, this is a >> process issue to me. >> >> (1) The patch set from Pantelis is "hidden" in the driver patch series. >> When viewing collapsed threads (which is my normal mode to avoid getting >> overwhelmed by the vast volume of email I scan), the Pantelis patch set >> is totally invisible. If the R-Car driver patch series had not had me >> on the to: list, there is a very good chance I would not have noticed >> it. Or noticed in a more delayed time frame. And the same applies to >> anyone else who might be subscribed to the devicetree mail list. If >> the Pantelis patch series was split out into a separate patch set then >> it would be more visible on the list. >> >> (2) There is no good way to indicate in the email subject lines for >> the Pantelis patches that they are version 3 of the series, since >> they are also version 4 of the R-Car patch series. If one reads the >> patch 0/0 header carefully, and/or the other Pantelis patch comment >> headers carefully, and then does a little detective work, it is >> possible to find version 2 of the Pantelis patch series, and thus >> be able to track the full history. If just glancing at each >> individual patch email subject, scanning the patch comment, and >> spending more time reading the body of the patch, it would be >> very easy to overlook the existence of the previous versions on >> the mail list. >> >> (2b) Small quibble: if the Pantelis patches were in a separate series, >> with v3 in the subject header, then you would have normally put >> a "changes since v2" section in the patch comment header, which would >> have been more visible and less cryptic than what you wrote, which was: >> >> ... >> >> Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com> >> [Fixed memory leak in __of_changeset_add_update_property_copy()] >> Signed-off-by: Laurent Pinchart >> <laurent.pinchart+renesas@ideasonboard.com> >> --- >> drivers/of/dynamic.c | 222 ++++++++++++++++++++++++++++++++++ >> include/linux/of.h | 328 +++++++++++++++++++++++++++++++++++++++++++++ >> 2 files changed, 550 insertions(+) >> >> My original scan of version 2 and then the email in this series had me >> questioning whether the two open issues from patch 2 had been addressed >> (yes, patch 0/16 did explicitly mention that 2 review comments had been >> taken into account, so you can point at my poor reading comprehension). > > All points dully noted, I'll make sure not to include similar patches in the > middle of a driver series should I need to rework a patch series previously > posted by someone else. > > I assume your comments also apply to patches to drivers/of/ that are developed > as part of a drivers series, not merely pulled in it ? Yes, as a normal process. Of course we find cases where following normal process causes problems, and it can be better to do something different in those cases. > I have mixed feelings > about this, as in many subsystems changes to the core require at least one > user. Always splitting core and driver changes in separate series would thus > often be impractical. If at all reasonable, I would still prefer to see two patch series for this case. I would expect both series to be upstreamed by a single maintainer (with the two involved maintainers coordinating this process). I have not thought this through in any detail, so I don't know if I'm missing a bunch of issues. One issue that I can think of is clearly documenting which version of the subsystem patch series any given version of the driver patch series depends upon. That should be easy to note in patch 0 of the driver series. Do you have experience with any other issues in this scenario? This sounds like a good topic to include in the "Guide to Being A Linux Kernel Maintainer". > I doubt we will find a single process that will suit all subsystem > maintainers, so maybe this should be a per-subsystem decision ? Totally agree. And even for me, I see it as a guideline or normal process, with exceptions made where it makes sense. >> (3) This is totally unrelated to your patch series, but I'm leaving a bread >> crumb trail here. Rob pointed you at a patch series that was not the most >> recent version. When this patch series appears again, there already is >> a version 3 subset of it, but it is still labeled as being version 2, and >> also has outstanding un-addressed issues. ("[PATCH v2 1/2] of: dynamic: >> Add __of_node_dupv()", 11/04/16) > > Ah, thank you for the information. I was looking for a v3 but missed that one > as it was labeled v2. > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello, This patch series addresses a design mistake that dates back from the initial DU support. Support for the LVDS encoders, which are IP cores separate from the DU, was bundled in the DU driver. Worse, both the DU and LVDS were described through a single DT node. To fix the, patches 01/16 and 02/16 define new DT bindings for the LVDS encoders, and deprecate their description inside the DU bindings. To retain backward compatibility with existing DT, patches 03/16 to 08/16 then patch the device tree at runtime to convert the legacy bindings to the new ones. With the DT side addressed, patch 09/16 converts the LVDS support code to a separate bridge driver. Patches 11/16 to 16/16 then update all the device tree sources to the new DU and LVDS encoders bindings. I decided to go for live DT patching in patch 08/16 because implementing support for both the legacy and new bindings in the driver would have been very intrusive, and prevented further cleanups. This version relies more heavily on overlays to avoid touching the internals of the OF core compared to v2, even if manual fixes to the device tree are still needed. Compared to v3, this series uses the OF changeset API to update properties instead of accessing the internals of the property structure. This removes the local implementation of functions to look up nodes by path and update properties. In order to do this, I pulled in Pantelis' patch series titled "[PATCH v2 0/5] of: dynamic: Changesets helpers & fixes" at Rob's request, and rebased it while taking two small review comments into account. Rob, I'd like this series to be merged in v4.17. As the changeset helpers are now a dependency, I'd need you to merge them early (ideally on top of v4.16-rc1) and provide a stable branch, or get your ack to merge them through Dave's tree if they don't conflict with what you have and will queue for v4.17. This version also drops the small fix to the Porter board device tree that has been queued for v4.17 already. Compared to v2, the biggest change is in patch 03/16. Following Rob's and Frank's reviews it was clear that modifying the unflattened DT structure of the overlay before applying it wasn't popular. I have thus decided to use one overlay source per SoC to move as much of the DT changes to the overlay as possible, and only perform manual modifications (that are still needed as some of the information is board-specific) on the system DT after applying the overlay. As a result the overlay is parsed and applied without being modified. Compared to v1, this series update the r8a7792 and r8a7794 device tree sources and incorporate review feedback as described by the changelogs of individual patches. Laurent Pinchart (11): dt-bindings: display: renesas: Add R-Car LVDS encoder DT bindings dt-bindings: display: renesas: Deprecate LVDS support in the DU bindings drm: rcar-du: Fix legacy DT to create LVDS encoder nodes drm: rcar-du: Convert LVDS encoder code to bridge driver ARM: dts: r8a7790: Convert to new LVDS DT bindings ARM: dts: r8a7791: Convert to new LVDS DT bindings ARM: dts: r8a7792: Convert to new DU DT bindings ARM: dts: r8a7793: Convert to new LVDS DT bindings ARM: dts: r8a7794: Convert to new DU DT bindings arm64: dts: renesas: r8a7795: Convert to new LVDS DT bindings arm64: dts: renesas: r8a7796: Convert to new LVDS DT bindings Pantelis Antoniou (5): of: dynamic: Add __of_node_dupv() of: changesets: Introduce changeset helper methods of: changeset: Add of_changeset_node_move method of: unittest: changeset helpers i2c: demux: Use changeset helpers for clarity .../bindings/display/bridge/renesas,lvds.txt | 56 +++ .../devicetree/bindings/display/renesas,du.txt | 31 +- MAINTAINERS | 1 + arch/arm/boot/dts/r8a7790-lager.dts | 22 +- arch/arm/boot/dts/r8a7790.dtsi | 64 ++- arch/arm/boot/dts/r8a7791-koelsch.dts | 10 +- arch/arm/boot/dts/r8a7791-porter.dts | 16 +- arch/arm/boot/dts/r8a7791.dtsi | 36 +- arch/arm/boot/dts/r8a7792.dtsi | 1 - arch/arm/boot/dts/r8a7793-gose.dts | 10 +- arch/arm/boot/dts/r8a7793.dtsi | 37 +- arch/arm/boot/dts/r8a7794.dtsi | 1 - .../boot/dts/renesas/r8a7795-es1-salvator-x.dts | 3 +- arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 3 +- arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 3 +- .../arm64/boot/dts/renesas/r8a7795-salvator-xs.dts | 3 +- arch/arm64/boot/dts/renesas/r8a7795.dtsi | 36 +- arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts | 3 +- arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 3 +- arch/arm64/boot/dts/renesas/r8a7796.dtsi | 36 +- drivers/gpu/drm/rcar-du/Kconfig | 6 +- drivers/gpu/drm/rcar-du/Makefile | 10 +- drivers/gpu/drm/rcar-du/rcar_du_drv.c | 21 +- drivers/gpu/drm/rcar-du/rcar_du_drv.h | 5 - drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 175 +------ drivers/gpu/drm/rcar-du/rcar_du_encoder.h | 12 - drivers/gpu/drm/rcar-du/rcar_du_kms.c | 14 +- drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c | 93 ---- drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h | 24 - drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 238 ---------- drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h | 64 --- drivers/gpu/drm/rcar-du/rcar_du_of.c | 307 ++++++++++++ drivers/gpu/drm/rcar-du/rcar_du_of.h | 20 + .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dts | 81 ++++ .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dts | 55 +++ .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dts | 55 +++ .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dts | 55 +++ .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dts | 55 +++ drivers/gpu/drm/rcar-du/rcar_lvds.c | 524 +++++++++++++++++++++ drivers/i2c/muxes/i2c-demux-pinctrl.c | 12 +- drivers/of/dynamic.c | 317 ++++++++++++- drivers/of/unittest.c | 54 +++ include/linux/of.h | 337 +++++++++++++ 43 files changed, 2199 insertions(+), 710 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of.c create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of.h create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dts create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dts create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dts create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dts create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dts create mode 100644 drivers/gpu/drm/rcar-du/rcar_lvds.c