* [PATCH/RFC v2 0/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0 @ 2017-03-24 13:37 ` Geert Uytterhoeven 0 siblings, 0 replies; 37+ messages in thread From: Geert Uytterhoeven @ 2017-03-24 13:37 UTC (permalink / raw) To: Simon Horman, Magnus Damm Cc: Yoshihiro Shimoda, Kuninori Morimoto, Laurent Pinchart, Wolfram Sang, Rob Herring, Mark Rutland, linux-renesas-soc, devicetree, linux-arm-kernel, Geert Uytterhoeven Hi all, This patch series adds preliminary support for Renesas Salvator-X development boards equipped with revision ES2.0 of the R-Car H3 Soc. - Patch 1 adds support for the R-Car H3 ES2.0 Soc, While this patch is safe as-is, as it doesn't affect any existing setups, it's probably a bit premature to apply it. - Patch 2 adds support for Salvator-X boards with R-Car H3 ES2.0. This patch does affect existing development setups, as it changes the name of the DTB for Salvator-X boards equipped with ES1.x SoCs. Given most developers have access to ES1.x only, this patch must not be applied yet. Note that for now, it is assumed that all H3ULCB boards are equipped with R-Car H3 ES1.x. For changes compared to v1 (which was not posted), please refer to the individual patches. Dependencies: - renesas-devel-20170324-v4.11-rc3, - [PATCH v2 0/4] clk: renesas: Add support for R-Car H3 ES2.0, - [PATCH v2 0/4] pinctrl: sh-pfc: Add support for R-Car H3 ES2.0, - [PATCH 0/3] soc: renesas: rcar-sysc: Add support for R-Car H3 ES2.0. To do: - Reduce duplication by sharing Salvator-X board description. For testers, this series is available in the topic/r8a7795es2-dt-v2 branch of my renesas-drivers git repository at git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git. An integration branch (incl. all dependencies) for testing is provided as topic/r8a7795es2-integration. I plan to update this branch when any of the dependencies are updated. This has been tested on Salvator-X with R-Car H3 ES1.0 and ES2.0 SoCs. Thanks for your comments! Geert Uytterhoeven (2): arm64: dts: r8a7795: Add support for R-Car H3 ES2.0 arm64: dts: r8a7795: salvator-x: Add support for R-Car H3 ES2.0 arch/arm64/boot/dts/renesas/Makefile | 1 + ...5-salvator-x.dts => r8a7795-es1-salvator-x.dts} | 4 +- arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi | 83 ++++++++++++++++++++++ arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 4 +- arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 2 +- arch/arm64/boot/dts/renesas/r8a7795.dtsi | 70 +----------------- 6 files changed, 90 insertions(+), 74 deletions(-) copy arch/arm64/boot/dts/renesas/{r8a7795-salvator-x.dts => r8a7795-es1-salvator-x.dts} (99%) create mode 100644 arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi -- 2.7.4 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] 37+ messages in thread
* [PATCH/RFC v2 0/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0 @ 2017-03-24 13:37 ` Geert Uytterhoeven 0 siblings, 0 replies; 37+ messages in thread From: Geert Uytterhoeven @ 2017-03-24 13:37 UTC (permalink / raw) To: linux-arm-kernel Hi all, This patch series adds preliminary support for Renesas Salvator-X development boards equipped with revision ES2.0 of the R-Car H3 Soc. - Patch 1 adds support for the R-Car H3 ES2.0 Soc, While this patch is safe as-is, as it doesn't affect any existing setups, it's probably a bit premature to apply it. - Patch 2 adds support for Salvator-X boards with R-Car H3 ES2.0. This patch does affect existing development setups, as it changes the name of the DTB for Salvator-X boards equipped with ES1.x SoCs. Given most developers have access to ES1.x only, this patch must not be applied yet. Note that for now, it is assumed that all H3ULCB boards are equipped with R-Car H3 ES1.x. For changes compared to v1 (which was not posted), please refer to the individual patches. Dependencies: - renesas-devel-20170324-v4.11-rc3, - [PATCH v2 0/4] clk: renesas: Add support for R-Car H3 ES2.0, - [PATCH v2 0/4] pinctrl: sh-pfc: Add support for R-Car H3 ES2.0, - [PATCH 0/3] soc: renesas: rcar-sysc: Add support for R-Car H3 ES2.0. To do: - Reduce duplication by sharing Salvator-X board description. For testers, this series is available in the topic/r8a7795es2-dt-v2 branch of my renesas-drivers git repository at git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git. An integration branch (incl. all dependencies) for testing is provided as topic/r8a7795es2-integration. I plan to update this branch when any of the dependencies are updated. This has been tested on Salvator-X with R-Car H3 ES1.0 and ES2.0 SoCs. Thanks for your comments! Geert Uytterhoeven (2): arm64: dts: r8a7795: Add support for R-Car H3 ES2.0 arm64: dts: r8a7795: salvator-x: Add support for R-Car H3 ES2.0 arch/arm64/boot/dts/renesas/Makefile | 1 + ...5-salvator-x.dts => r8a7795-es1-salvator-x.dts} | 4 +- arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi | 83 ++++++++++++++++++++++ arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 4 +- arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 2 +- arch/arm64/boot/dts/renesas/r8a7795.dtsi | 70 +----------------- 6 files changed, 90 insertions(+), 74 deletions(-) copy arch/arm64/boot/dts/renesas/{r8a7795-salvator-x.dts => r8a7795-es1-salvator-x.dts} (99%) create mode 100644 arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi -- 2.7.4 Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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] 37+ messages in thread
[parent not found: <1490362665-4422-1-git-send-email-geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>]
* [PATCH/RFC v2 1/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0 2017-03-24 13:37 ` Geert Uytterhoeven @ 2017-03-24 13:37 ` Geert Uytterhoeven -1 siblings, 0 replies; 37+ messages in thread From: Geert Uytterhoeven @ 2017-03-24 13:37 UTC (permalink / raw) To: Simon Horman, Magnus Damm Cc: Yoshihiro Shimoda, Kuninori Morimoto, Laurent Pinchart, Wolfram Sang, Rob Herring, Mark Rutland, linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Geert Uytterhoeven Update r8a7795.dtsi so it corresponds to R-Car H3 ES2.0 or later: - The following devices no longer exist on ES2.0, and are thus removed: fcpf2, fcpvd3, fcpvi2, fdp1-2, usb3-if1, vspd3, vspi2. - The DU <-> VSPD topology is different on ES2.0, hence remove the "vsps" property from the DU node until the driver can handle this. Move support for the ES1.x revision of the R-Car H3 SoC into a separate file. To avoid duplication, r8a7795-es1.dtsi includes r8a7795.dtsi, add adds/removes/overrides device nodes and properties where needed. Switch r8a7795-salvator-x.dts and r8a7795-h3ulcb.dts from r8a7795.dtsi to r8a7795-es1.dtsi to preserve compatibility. Signed-off-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org> --- While currently r8a7795-es1.dtsi only adds device nodes, removal of devices nodes and properties can be implemented using the /delete-node/ and /delete-property/ keywords, as shown below: &soc { /delete-node/ <name>@<addr>; }; &<name> { /delete-property/ <prop>; }; v2: - Use a separate file for ES1.x instead of for ES2.0, so r8a7795.dtsi always corresponds to the latest SoC revision, - Add a dash between SoC part number and revision, for compatibility with the BSP, - Enhance the hardware description from basic support to everything already supported on ES1.x (except for DU due VSP), - Let r8a7795-es1.dtsi include r8a7795.dtsi. --- arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi | 83 ++++++++++++++++++++++ arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 4 +- arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 4 +- arch/arm64/boot/dts/renesas/r8a7795.dtsi | 70 +----------------- 4 files changed, 88 insertions(+), 73 deletions(-) create mode 100644 arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi diff --git a/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi b/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi new file mode 100644 index 0000000000000000..f1646334899f08ce --- /dev/null +++ b/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi @@ -0,0 +1,83 @@ +/* + * Device Tree Source for the r8a7795 ES1.x SoC + * + * Copyright (C) 2015 Renesas Electronics Corp. + * + * This file is licensed under the terms of the GNU General Public License + * version 2. This program is licensed "as is" without any warranty of any + * kind, whether express or implied. + */ + +#include "r8a7795.dtsi" + +&soc { + xhci1: usb@ee0400000 { + compatible = "renesas,xhci-r8a7795", "renesas,rcar-gen3-xhci"; + reg = <0 0xee040000 0 0xc00>; + interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 327>; + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; + resets = <&cpg 327>; + status = "disabled"; + }; + + fcpf2: fcp@fe952000 { + compatible = "renesas,fcpf"; + reg = <0 0xfe952000 0 0x200>; + clocks = <&cpg CPG_MOD 613>; + power-domains = <&sysc R8A7795_PD_A3VP>; + resets = <&cpg 613>; + }; + + vspi2: vsp@fe9c0000 { + compatible = "renesas,vsp2"; + reg = <0 0xfe9c0000 0 0x8000>; + interrupts = <GIC_SPI 446 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 629>; + power-domains = <&sysc R8A7795_PD_A3VP>; + resets = <&cpg 629>; + + renesas,fcp = <&fcpvi2>; + }; + + fcpvi2: fcp@fe9cf000 { + compatible = "renesas,fcpv"; + reg = <0 0xfe9cf000 0 0x200>; + clocks = <&cpg CPG_MOD 609>; + power-domains = <&sysc R8A7795_PD_A3VP>; + resets = <&cpg 609>; + }; + + vspd3: vsp@fea38000 { + compatible = "renesas,vsp2"; + reg = <0 0xfea38000 0 0x4000>; + interrupts = <GIC_SPI 469 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 620>; + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; + resets = <&cpg 620>; + + renesas,fcp = <&fcpvd3>; + }; + + fcpvd3: fcp@fea3f000 { + compatible = "renesas,fcpv"; + reg = <0 0xfea3f000 0 0x200>; + clocks = <&cpg CPG_MOD 600>; + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; + resets = <&cpg 600>; + }; + + fdp1@fe948000 { + compatible = "renesas,fdp1"; + reg = <0 0xfe948000 0 0x2400>; + interrupts = <GIC_SPI 264 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 117>; + power-domains = <&sysc R8A7795_PD_A3VP>; + resets = <&cpg 117>; + renesas,fcp = <&fcpf2>; + }; +}; + +&du { + vsps = <&vspd0 &vspd1 &vspd2 &vspd3>; +}; diff --git a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts index ab352159de6572c9..60a1f4356b4b15c7 100644 --- a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts +++ b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts @@ -10,12 +10,12 @@ */ /dts-v1/; -#include "r8a7795.dtsi" +#include "r8a7795-es1.dtsi" #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/input/input.h> / { - model = "Renesas H3ULCB board based on r8a7795"; + model = "Renesas H3ULCB board based on r8a7795 ES1.x"; compatible = "renesas,h3ulcb", "renesas,r8a7795"; aliases { diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts index f25241921067dcef..7758b479dd98d2e9 100644 --- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts +++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts @@ -32,11 +32,11 @@ */ /dts-v1/; -#include "r8a7795.dtsi" +#include "r8a7795-es1.dtsi" #include <dt-bindings/gpio/gpio.h> / { - model = "Renesas Salvator-X board based on r8a7795"; + model = "Renesas Salvator-X board based on r8a7795 ES1.x"; compatible = "renesas,salvator-x", "renesas,r8a7795"; aliases { diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi index e99d6443b3e493a4..e1caa4e14593a299 100644 --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi @@ -182,7 +182,7 @@ clock-frequency = <0>; }; - soc { + soc: soc { compatible = "simple-bus"; interrupt-parent = <&gic>; @@ -1274,16 +1274,6 @@ status = "disabled"; }; - xhci1: usb@ee0400000 { - compatible = "renesas,xhci-r8a7795", "renesas,rcar-gen3-xhci"; - reg = <0 0xee040000 0 0xc00>; - interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&cpg CPG_MOD 327>; - power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; - resets = <&cpg 327>; - status = "disabled"; - }; - usb_dmac0: dma-controller@e65a0000 { compatible = "renesas,r8a7795-usb-dmac", "renesas,usb-dmac"; @@ -1568,14 +1558,6 @@ resets = <&cpg 614>; }; - fcpf2: fcp@fe952000 { - compatible = "renesas,fcpf"; - reg = <0 0xfe952000 0 0x200>; - clocks = <&cpg CPG_MOD 613>; - power-domains = <&sysc R8A7795_PD_A3VP>; - resets = <&cpg 613>; - }; - vspbd: vsp@fe960000 { compatible = "renesas,vsp2"; reg = <0 0xfe960000 0 0x8000>; @@ -1633,25 +1615,6 @@ resets = <&cpg 610>; }; - vspi2: vsp@fe9c0000 { - compatible = "renesas,vsp2"; - reg = <0 0xfe9c0000 0 0x8000>; - interrupts = <GIC_SPI 446 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&cpg CPG_MOD 629>; - power-domains = <&sysc R8A7795_PD_A3VP>; - resets = <&cpg 629>; - - renesas,fcp = <&fcpvi2>; - }; - - fcpvi2: fcp@fe9cf000 { - compatible = "renesas,fcpv"; - reg = <0 0xfe9cf000 0 0x200>; - clocks = <&cpg CPG_MOD 609>; - power-domains = <&sysc R8A7795_PD_A3VP>; - resets = <&cpg 609>; - }; - vspd0: vsp@fea20000 { compatible = "renesas,vsp2"; reg = <0 0xfea20000 0 0x4000>; @@ -1709,25 +1672,6 @@ resets = <&cpg 601>; }; - vspd3: vsp@fea38000 { - compatible = "renesas,vsp2"; - reg = <0 0xfea38000 0 0x4000>; - interrupts = <GIC_SPI 469 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&cpg CPG_MOD 620>; - power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; - resets = <&cpg 620>; - - renesas,fcp = <&fcpvd3>; - }; - - fcpvd3: fcp@fea3f000 { - compatible = "renesas,fcpv"; - reg = <0 0xfea3f000 0 0x200>; - clocks = <&cpg CPG_MOD 600>; - power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; - resets = <&cpg 600>; - }; - fdp1@fe940000 { compatible = "renesas,fdp1"; reg = <0 0xfe940000 0 0x2400>; @@ -1748,16 +1692,6 @@ renesas,fcp = <&fcpf1>; }; - fdp1@fe948000 { - compatible = "renesas,fdp1"; - reg = <0 0xfe948000 0 0x2400>; - interrupts = <GIC_SPI 264 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&cpg CPG_MOD 117>; - power-domains = <&sysc R8A7795_PD_A3VP>; - resets = <&cpg 117>; - renesas,fcp = <&fcpf2>; - }; - du: display@feb00000 { compatible = "renesas,du-r8a7795"; reg = <0 0xfeb00000 0 0x80000>, @@ -1775,8 +1709,6 @@ clock-names = "du.0", "du.1", "du.2", "du.3", "lvds.0"; status = "disabled"; - vsps = <&vspd0 &vspd1 &vspd2 &vspd3>; - ports { #address-cells = <1>; #size-cells = <0>; -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply related [flat|nested] 37+ messages in thread
* [PATCH/RFC v2 1/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0 @ 2017-03-24 13:37 ` Geert Uytterhoeven 0 siblings, 0 replies; 37+ messages in thread From: Geert Uytterhoeven @ 2017-03-24 13:37 UTC (permalink / raw) To: Simon Horman, Magnus Damm Cc: Yoshihiro Shimoda, Kuninori Morimoto, Laurent Pinchart, Wolfram Sang, Rob Herring, Mark Rutland, linux-renesas-soc, devicetree, linux-arm-kernel, Geert Uytterhoeven Update r8a7795.dtsi so it corresponds to R-Car H3 ES2.0 or later: - The following devices no longer exist on ES2.0, and are thus removed: fcpf2, fcpvd3, fcpvi2, fdp1-2, usb3-if1, vspd3, vspi2. - The DU <-> VSPD topology is different on ES2.0, hence remove the "vsps" property from the DU node until the driver can handle this. Move support for the ES1.x revision of the R-Car H3 SoC into a separate file. To avoid duplication, r8a7795-es1.dtsi includes r8a7795.dtsi, add adds/removes/overrides device nodes and properties where needed. Switch r8a7795-salvator-x.dts and r8a7795-h3ulcb.dts from r8a7795.dtsi to r8a7795-es1.dtsi to preserve compatibility. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> --- While currently r8a7795-es1.dtsi only adds device nodes, removal of devices nodes and properties can be implemented using the /delete-node/ and /delete-property/ keywords, as shown below: &soc { /delete-node/ <name>@<addr>; }; &<name> { /delete-property/ <prop>; }; v2: - Use a separate file for ES1.x instead of for ES2.0, so r8a7795.dtsi always corresponds to the latest SoC revision, - Add a dash between SoC part number and revision, for compatibility with the BSP, - Enhance the hardware description from basic support to everything already supported on ES1.x (except for DU due VSP), - Let r8a7795-es1.dtsi include r8a7795.dtsi. --- arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi | 83 ++++++++++++++++++++++ arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 4 +- arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 4 +- arch/arm64/boot/dts/renesas/r8a7795.dtsi | 70 +----------------- 4 files changed, 88 insertions(+), 73 deletions(-) create mode 100644 arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi diff --git a/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi b/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi new file mode 100644 index 0000000000000000..f1646334899f08ce --- /dev/null +++ b/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi @@ -0,0 +1,83 @@ +/* + * Device Tree Source for the r8a7795 ES1.x SoC + * + * Copyright (C) 2015 Renesas Electronics Corp. + * + * This file is licensed under the terms of the GNU General Public License + * version 2. This program is licensed "as is" without any warranty of any + * kind, whether express or implied. + */ + +#include "r8a7795.dtsi" + +&soc { + xhci1: usb@ee0400000 { + compatible = "renesas,xhci-r8a7795", "renesas,rcar-gen3-xhci"; + reg = <0 0xee040000 0 0xc00>; + interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 327>; + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; + resets = <&cpg 327>; + status = "disabled"; + }; + + fcpf2: fcp@fe952000 { + compatible = "renesas,fcpf"; + reg = <0 0xfe952000 0 0x200>; + clocks = <&cpg CPG_MOD 613>; + power-domains = <&sysc R8A7795_PD_A3VP>; + resets = <&cpg 613>; + }; + + vspi2: vsp@fe9c0000 { + compatible = "renesas,vsp2"; + reg = <0 0xfe9c0000 0 0x8000>; + interrupts = <GIC_SPI 446 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 629>; + power-domains = <&sysc R8A7795_PD_A3VP>; + resets = <&cpg 629>; + + renesas,fcp = <&fcpvi2>; + }; + + fcpvi2: fcp@fe9cf000 { + compatible = "renesas,fcpv"; + reg = <0 0xfe9cf000 0 0x200>; + clocks = <&cpg CPG_MOD 609>; + power-domains = <&sysc R8A7795_PD_A3VP>; + resets = <&cpg 609>; + }; + + vspd3: vsp@fea38000 { + compatible = "renesas,vsp2"; + reg = <0 0xfea38000 0 0x4000>; + interrupts = <GIC_SPI 469 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 620>; + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; + resets = <&cpg 620>; + + renesas,fcp = <&fcpvd3>; + }; + + fcpvd3: fcp@fea3f000 { + compatible = "renesas,fcpv"; + reg = <0 0xfea3f000 0 0x200>; + clocks = <&cpg CPG_MOD 600>; + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; + resets = <&cpg 600>; + }; + + fdp1@fe948000 { + compatible = "renesas,fdp1"; + reg = <0 0xfe948000 0 0x2400>; + interrupts = <GIC_SPI 264 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 117>; + power-domains = <&sysc R8A7795_PD_A3VP>; + resets = <&cpg 117>; + renesas,fcp = <&fcpf2>; + }; +}; + +&du { + vsps = <&vspd0 &vspd1 &vspd2 &vspd3>; +}; diff --git a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts index ab352159de6572c9..60a1f4356b4b15c7 100644 --- a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts +++ b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts @@ -10,12 +10,12 @@ */ /dts-v1/; -#include "r8a7795.dtsi" +#include "r8a7795-es1.dtsi" #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/input/input.h> / { - model = "Renesas H3ULCB board based on r8a7795"; + model = "Renesas H3ULCB board based on r8a7795 ES1.x"; compatible = "renesas,h3ulcb", "renesas,r8a7795"; aliases { diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts index f25241921067dcef..7758b479dd98d2e9 100644 --- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts +++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts @@ -32,11 +32,11 @@ */ /dts-v1/; -#include "r8a7795.dtsi" +#include "r8a7795-es1.dtsi" #include <dt-bindings/gpio/gpio.h> / { - model = "Renesas Salvator-X board based on r8a7795"; + model = "Renesas Salvator-X board based on r8a7795 ES1.x"; compatible = "renesas,salvator-x", "renesas,r8a7795"; aliases { diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi index e99d6443b3e493a4..e1caa4e14593a299 100644 --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi @@ -182,7 +182,7 @@ clock-frequency = <0>; }; - soc { + soc: soc { compatible = "simple-bus"; interrupt-parent = <&gic>; @@ -1274,16 +1274,6 @@ status = "disabled"; }; - xhci1: usb@ee0400000 { - compatible = "renesas,xhci-r8a7795", "renesas,rcar-gen3-xhci"; - reg = <0 0xee040000 0 0xc00>; - interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&cpg CPG_MOD 327>; - power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; - resets = <&cpg 327>; - status = "disabled"; - }; - usb_dmac0: dma-controller@e65a0000 { compatible = "renesas,r8a7795-usb-dmac", "renesas,usb-dmac"; @@ -1568,14 +1558,6 @@ resets = <&cpg 614>; }; - fcpf2: fcp@fe952000 { - compatible = "renesas,fcpf"; - reg = <0 0xfe952000 0 0x200>; - clocks = <&cpg CPG_MOD 613>; - power-domains = <&sysc R8A7795_PD_A3VP>; - resets = <&cpg 613>; - }; - vspbd: vsp@fe960000 { compatible = "renesas,vsp2"; reg = <0 0xfe960000 0 0x8000>; @@ -1633,25 +1615,6 @@ resets = <&cpg 610>; }; - vspi2: vsp@fe9c0000 { - compatible = "renesas,vsp2"; - reg = <0 0xfe9c0000 0 0x8000>; - interrupts = <GIC_SPI 446 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&cpg CPG_MOD 629>; - power-domains = <&sysc R8A7795_PD_A3VP>; - resets = <&cpg 629>; - - renesas,fcp = <&fcpvi2>; - }; - - fcpvi2: fcp@fe9cf000 { - compatible = "renesas,fcpv"; - reg = <0 0xfe9cf000 0 0x200>; - clocks = <&cpg CPG_MOD 609>; - power-domains = <&sysc R8A7795_PD_A3VP>; - resets = <&cpg 609>; - }; - vspd0: vsp@fea20000 { compatible = "renesas,vsp2"; reg = <0 0xfea20000 0 0x4000>; @@ -1709,25 +1672,6 @@ resets = <&cpg 601>; }; - vspd3: vsp@fea38000 { - compatible = "renesas,vsp2"; - reg = <0 0xfea38000 0 0x4000>; - interrupts = <GIC_SPI 469 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&cpg CPG_MOD 620>; - power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; - resets = <&cpg 620>; - - renesas,fcp = <&fcpvd3>; - }; - - fcpvd3: fcp@fea3f000 { - compatible = "renesas,fcpv"; - reg = <0 0xfea3f000 0 0x200>; - clocks = <&cpg CPG_MOD 600>; - power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; - resets = <&cpg 600>; - }; - fdp1@fe940000 { compatible = "renesas,fdp1"; reg = <0 0xfe940000 0 0x2400>; @@ -1748,16 +1692,6 @@ renesas,fcp = <&fcpf1>; }; - fdp1@fe948000 { - compatible = "renesas,fdp1"; - reg = <0 0xfe948000 0 0x2400>; - interrupts = <GIC_SPI 264 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&cpg CPG_MOD 117>; - power-domains = <&sysc R8A7795_PD_A3VP>; - resets = <&cpg 117>; - renesas,fcp = <&fcpf2>; - }; - du: display@feb00000 { compatible = "renesas,du-r8a7795"; reg = <0 0xfeb00000 0 0x80000>, @@ -1775,8 +1709,6 @@ clock-names = "du.0", "du.1", "du.2", "du.3", "lvds.0"; status = "disabled"; - vsps = <&vspd0 &vspd1 &vspd2 &vspd3>; - ports { #address-cells = <1>; #size-cells = <0>; -- 2.7.4 ^ permalink raw reply related [flat|nested] 37+ messages in thread
* Re: [PATCH/RFC v2 1/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0 2017-03-24 13:37 ` Geert Uytterhoeven @ 2017-03-27 8:48 ` Laurent Pinchart -1 siblings, 0 replies; 37+ messages in thread From: Laurent Pinchart @ 2017-03-27 8:48 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Simon Horman, Magnus Damm, Yoshihiro Shimoda, Kuninori Morimoto, Wolfram Sang, Rob Herring, Mark Rutland, linux-renesas-soc, devicetree, linux-arm-kernel Hi Geert, Thank you for the patch. On Friday 24 Mar 2017 14:37:44 Geert Uytterhoeven wrote: > Update r8a7795.dtsi so it corresponds to R-Car H3 ES2.0 or later: > - The following devices no longer exist on ES2.0, and are thus removed: > fcpf2, fcpvd3, fcpvi2, fdp1-2, usb3-if1, vspd3, vspi2. > - The DU <-> VSPD topology is different on ES2.0, hence remove the > "vsps" property from the DU node until the driver can handle this. I think I'll need a different compatible string between ES1.x and ES2 for the DU. It could make sense to move the whole DU node to *-es1.dtsi. We can decide about that later when I'll have a DU driver prototype ready. > Move support for the ES1.x revision of the R-Car H3 SoC into a > separate file. To avoid duplication, r8a7795-es1.dtsi includes > r8a7795.dtsi, add adds/removes/overrides device nodes and properties > where needed. > > Switch r8a7795-salvator-x.dts and r8a7795-h3ulcb.dts from r8a7795.dtsi > to r8a7795-es1.dtsi to preserve compatibility. > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> > --- > While currently r8a7795-es1.dtsi only adds device nodes, removal of > devices nodes and properties can be implemented using the /delete-node/ > and /delete-property/ keywords, as shown below: > > &soc { > /delete-node/ <name>@<addr>; > }; > > &<name> { > /delete-property/ <prop>; > }; > > v2: > - Use a separate file for ES1.x instead of for ES2.0, so r8a7795.dtsi > always corresponds to the latest SoC revision, > - Add a dash between SoC part number and revision, for compatibility > with the BSP, > - Enhance the hardware description from basic support to everything > already supported on ES1.x (except for DU due VSP), > - Let r8a7795-es1.dtsi include r8a7795.dtsi. > --- > arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi | 83 +++++++++++++++++++ > arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 4 +- > arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 4 +- > arch/arm64/boot/dts/renesas/r8a7795.dtsi | 70 +----------------- > 4 files changed, 88 insertions(+), 73 deletions(-) > create mode 100644 arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi > > diff --git a/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi > b/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi new file mode 100644 > index 0000000000000000..f1646334899f08ce > --- /dev/null > +++ b/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi > @@ -0,0 +1,83 @@ > +/* > + * Device Tree Source for the r8a7795 ES1.x SoC > + * > + * Copyright (C) 2015 Renesas Electronics Corp. > + * > + * This file is licensed under the terms of the GNU General Public License > + * version 2. This program is licensed "as is" without any warranty of any > + * kind, whether express or implied. > + */ > + > +#include "r8a7795.dtsi" > + > +&soc { > + xhci1: usb@ee0400000 { > + compatible = "renesas,xhci-r8a7795", "renesas,rcar-gen3-xhci"; > + reg = <0 0xee040000 0 0xc00>; > + interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>; > + clocks = <&cpg CPG_MOD 327>; > + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; > + resets = <&cpg 327>; > + status = "disabled"; > + }; > + > + fcpf2: fcp@fe952000 { > + compatible = "renesas,fcpf"; > + reg = <0 0xfe952000 0 0x200>; > + clocks = <&cpg CPG_MOD 613>; > + power-domains = <&sysc R8A7795_PD_A3VP>; > + resets = <&cpg 613>; > + }; > + > + vspi2: vsp@fe9c0000 { > + compatible = "renesas,vsp2"; > + reg = <0 0xfe9c0000 0 0x8000>; > + interrupts = <GIC_SPI 446 IRQ_TYPE_LEVEL_HIGH>; > + clocks = <&cpg CPG_MOD 629>; > + power-domains = <&sysc R8A7795_PD_A3VP>; > + resets = <&cpg 629>; > + > + renesas,fcp = <&fcpvi2>; > + }; > + > + fcpvi2: fcp@fe9cf000 { > + compatible = "renesas,fcpv"; > + reg = <0 0xfe9cf000 0 0x200>; > + clocks = <&cpg CPG_MOD 609>; > + power-domains = <&sysc R8A7795_PD_A3VP>; > + resets = <&cpg 609>; > + }; > + > + vspd3: vsp@fea38000 { > + compatible = "renesas,vsp2"; > + reg = <0 0xfea38000 0 0x4000>; > + interrupts = <GIC_SPI 469 IRQ_TYPE_LEVEL_HIGH>; > + clocks = <&cpg CPG_MOD 620>; > + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; > + resets = <&cpg 620>; > + > + renesas,fcp = <&fcpvd3>; > + }; > + > + fcpvd3: fcp@fea3f000 { > + compatible = "renesas,fcpv"; > + reg = <0 0xfea3f000 0 0x200>; > + clocks = <&cpg CPG_MOD 600>; > + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; > + resets = <&cpg 600>; > + }; > + > + fdp1@fe948000 { > + compatible = "renesas,fdp1"; > + reg = <0 0xfe948000 0 0x2400>; > + interrupts = <GIC_SPI 264 IRQ_TYPE_LEVEL_HIGH>; > + clocks = <&cpg CPG_MOD 117>; > + power-domains = <&sysc R8A7795_PD_A3VP>; > + resets = <&cpg 117>; > + renesas,fcp = <&fcpf2>; > + }; > +}; > + > +&du { > + vsps = <&vspd0 &vspd1 &vspd2 &vspd3>; > +}; > diff --git a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts > b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts index > ab352159de6572c9..60a1f4356b4b15c7 100644 > --- a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts > +++ b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts > @@ -10,12 +10,12 @@ > */ > > /dts-v1/; > -#include "r8a7795.dtsi" > +#include "r8a7795-es1.dtsi" > #include <dt-bindings/gpio/gpio.h> > #include <dt-bindings/input/input.h> > > / { > - model = "Renesas H3ULCB board based on r8a7795"; > + model = "Renesas H3ULCB board based on r8a7795 ES1.x"; > compatible = "renesas,h3ulcb", "renesas,r8a7795"; > > aliases { > diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts > b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts index > f25241921067dcef..7758b479dd98d2e9 100644 > --- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts > +++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts > @@ -32,11 +32,11 @@ > */ > > /dts-v1/; > -#include "r8a7795.dtsi" > +#include "r8a7795-es1.dtsi" > #include <dt-bindings/gpio/gpio.h> > > / { > - model = "Renesas Salvator-X board based on r8a7795"; > + model = "Renesas Salvator-X board based on r8a7795 ES1.x"; > compatible = "renesas,salvator-x", "renesas,r8a7795"; > > aliases { > diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi > b/arch/arm64/boot/dts/renesas/r8a7795.dtsi index > e99d6443b3e493a4..e1caa4e14593a299 100644 > --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi > +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi > @@ -182,7 +182,7 @@ > clock-frequency = <0>; > }; > > - soc { > + soc: soc { > compatible = "simple-bus"; > interrupt-parent = <&gic>; > > @@ -1274,16 +1274,6 @@ > status = "disabled"; > }; > > - xhci1: usb@ee0400000 { > - compatible = "renesas,xhci-r8a7795", "renesas,rcar- gen3-xhci"; > - reg = <0 0xee040000 0 0xc00>; > - interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>; > - clocks = <&cpg CPG_MOD 327>; > - power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; > - resets = <&cpg 327>; > - status = "disabled"; > - }; > - > usb_dmac0: dma-controller@e65a0000 { > compatible = "renesas,r8a7795-usb-dmac", > "renesas,usb-dmac"; > @@ -1568,14 +1558,6 @@ > resets = <&cpg 614>; > }; > > - fcpf2: fcp@fe952000 { > - compatible = "renesas,fcpf"; > - reg = <0 0xfe952000 0 0x200>; > - clocks = <&cpg CPG_MOD 613>; > - power-domains = <&sysc R8A7795_PD_A3VP>; > - resets = <&cpg 613>; > - }; > - > vspbd: vsp@fe960000 { > compatible = "renesas,vsp2"; > reg = <0 0xfe960000 0 0x8000>; > @@ -1633,25 +1615,6 @@ > resets = <&cpg 610>; > }; > > - vspi2: vsp@fe9c0000 { > - compatible = "renesas,vsp2"; > - reg = <0 0xfe9c0000 0 0x8000>; > - interrupts = <GIC_SPI 446 IRQ_TYPE_LEVEL_HIGH>; > - clocks = <&cpg CPG_MOD 629>; > - power-domains = <&sysc R8A7795_PD_A3VP>; > - resets = <&cpg 629>; > - > - renesas,fcp = <&fcpvi2>; > - }; > - > - fcpvi2: fcp@fe9cf000 { > - compatible = "renesas,fcpv"; > - reg = <0 0xfe9cf000 0 0x200>; > - clocks = <&cpg CPG_MOD 609>; > - power-domains = <&sysc R8A7795_PD_A3VP>; > - resets = <&cpg 609>; > - }; > - > vspd0: vsp@fea20000 { > compatible = "renesas,vsp2"; > reg = <0 0xfea20000 0 0x4000>; > @@ -1709,25 +1672,6 @@ > resets = <&cpg 601>; > }; > > - vspd3: vsp@fea38000 { > - compatible = "renesas,vsp2"; > - reg = <0 0xfea38000 0 0x4000>; > - interrupts = <GIC_SPI 469 IRQ_TYPE_LEVEL_HIGH>; > - clocks = <&cpg CPG_MOD 620>; > - power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; > - resets = <&cpg 620>; > - > - renesas,fcp = <&fcpvd3>; > - }; > - > - fcpvd3: fcp@fea3f000 { > - compatible = "renesas,fcpv"; > - reg = <0 0xfea3f000 0 0x200>; > - clocks = <&cpg CPG_MOD 600>; > - power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; > - resets = <&cpg 600>; > - }; > - > fdp1@fe940000 { > compatible = "renesas,fdp1"; > reg = <0 0xfe940000 0 0x2400>; > @@ -1748,16 +1692,6 @@ > renesas,fcp = <&fcpf1>; > }; > > - fdp1@fe948000 { > - compatible = "renesas,fdp1"; > - reg = <0 0xfe948000 0 0x2400>; > - interrupts = <GIC_SPI 264 IRQ_TYPE_LEVEL_HIGH>; > - clocks = <&cpg CPG_MOD 117>; > - power-domains = <&sysc R8A7795_PD_A3VP>; > - resets = <&cpg 117>; > - renesas,fcp = <&fcpf2>; > - }; > - > du: display@feb00000 { > compatible = "renesas,du-r8a7795"; > reg = <0 0xfeb00000 0 0x80000>, > @@ -1775,8 +1709,6 @@ > clock-names = "du.0", "du.1", "du.2", "du.3", "lvds.0"; > status = "disabled"; > > - vsps = <&vspd0 &vspd1 &vspd2 &vspd3>; > - > ports { > #address-cells = <1>; > #size-cells = <0>; -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH/RFC v2 1/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0 @ 2017-03-27 8:48 ` Laurent Pinchart 0 siblings, 0 replies; 37+ messages in thread From: Laurent Pinchart @ 2017-03-27 8:48 UTC (permalink / raw) To: linux-arm-kernel Hi Geert, Thank you for the patch. On Friday 24 Mar 2017 14:37:44 Geert Uytterhoeven wrote: > Update r8a7795.dtsi so it corresponds to R-Car H3 ES2.0 or later: > - The following devices no longer exist on ES2.0, and are thus removed: > fcpf2, fcpvd3, fcpvi2, fdp1-2, usb3-if1, vspd3, vspi2. > - The DU <-> VSPD topology is different on ES2.0, hence remove the > "vsps" property from the DU node until the driver can handle this. I think I'll need a different compatible string between ES1.x and ES2 for the DU. It could make sense to move the whole DU node to *-es1.dtsi. We can decide about that later when I'll have a DU driver prototype ready. > Move support for the ES1.x revision of the R-Car H3 SoC into a > separate file. To avoid duplication, r8a7795-es1.dtsi includes > r8a7795.dtsi, add adds/removes/overrides device nodes and properties > where needed. > > Switch r8a7795-salvator-x.dts and r8a7795-h3ulcb.dts from r8a7795.dtsi > to r8a7795-es1.dtsi to preserve compatibility. > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> > --- > While currently r8a7795-es1.dtsi only adds device nodes, removal of > devices nodes and properties can be implemented using the /delete-node/ > and /delete-property/ keywords, as shown below: > > &soc { > /delete-node/ <name>@<addr>; > }; > > &<name> { > /delete-property/ <prop>; > }; > > v2: > - Use a separate file for ES1.x instead of for ES2.0, so r8a7795.dtsi > always corresponds to the latest SoC revision, > - Add a dash between SoC part number and revision, for compatibility > with the BSP, > - Enhance the hardware description from basic support to everything > already supported on ES1.x (except for DU due VSP), > - Let r8a7795-es1.dtsi include r8a7795.dtsi. > --- > arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi | 83 +++++++++++++++++++ > arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 4 +- > arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 4 +- > arch/arm64/boot/dts/renesas/r8a7795.dtsi | 70 +----------------- > 4 files changed, 88 insertions(+), 73 deletions(-) > create mode 100644 arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi > > diff --git a/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi > b/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi new file mode 100644 > index 0000000000000000..f1646334899f08ce > --- /dev/null > +++ b/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi > @@ -0,0 +1,83 @@ > +/* > + * Device Tree Source for the r8a7795 ES1.x SoC > + * > + * Copyright (C) 2015 Renesas Electronics Corp. > + * > + * This file is licensed under the terms of the GNU General Public License > + * version 2. This program is licensed "as is" without any warranty of any > + * kind, whether express or implied. > + */ > + > +#include "r8a7795.dtsi" > + > +&soc { > + xhci1: usb at ee0400000 { > + compatible = "renesas,xhci-r8a7795", "renesas,rcar-gen3-xhci"; > + reg = <0 0xee040000 0 0xc00>; > + interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>; > + clocks = <&cpg CPG_MOD 327>; > + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; > + resets = <&cpg 327>; > + status = "disabled"; > + }; > + > + fcpf2: fcp at fe952000 { > + compatible = "renesas,fcpf"; > + reg = <0 0xfe952000 0 0x200>; > + clocks = <&cpg CPG_MOD 613>; > + power-domains = <&sysc R8A7795_PD_A3VP>; > + resets = <&cpg 613>; > + }; > + > + vspi2: vsp at fe9c0000 { > + compatible = "renesas,vsp2"; > + reg = <0 0xfe9c0000 0 0x8000>; > + interrupts = <GIC_SPI 446 IRQ_TYPE_LEVEL_HIGH>; > + clocks = <&cpg CPG_MOD 629>; > + power-domains = <&sysc R8A7795_PD_A3VP>; > + resets = <&cpg 629>; > + > + renesas,fcp = <&fcpvi2>; > + }; > + > + fcpvi2: fcp at fe9cf000 { > + compatible = "renesas,fcpv"; > + reg = <0 0xfe9cf000 0 0x200>; > + clocks = <&cpg CPG_MOD 609>; > + power-domains = <&sysc R8A7795_PD_A3VP>; > + resets = <&cpg 609>; > + }; > + > + vspd3: vsp at fea38000 { > + compatible = "renesas,vsp2"; > + reg = <0 0xfea38000 0 0x4000>; > + interrupts = <GIC_SPI 469 IRQ_TYPE_LEVEL_HIGH>; > + clocks = <&cpg CPG_MOD 620>; > + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; > + resets = <&cpg 620>; > + > + renesas,fcp = <&fcpvd3>; > + }; > + > + fcpvd3: fcp at fea3f000 { > + compatible = "renesas,fcpv"; > + reg = <0 0xfea3f000 0 0x200>; > + clocks = <&cpg CPG_MOD 600>; > + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; > + resets = <&cpg 600>; > + }; > + > + fdp1 at fe948000 { > + compatible = "renesas,fdp1"; > + reg = <0 0xfe948000 0 0x2400>; > + interrupts = <GIC_SPI 264 IRQ_TYPE_LEVEL_HIGH>; > + clocks = <&cpg CPG_MOD 117>; > + power-domains = <&sysc R8A7795_PD_A3VP>; > + resets = <&cpg 117>; > + renesas,fcp = <&fcpf2>; > + }; > +}; > + > +&du { > + vsps = <&vspd0 &vspd1 &vspd2 &vspd3>; > +}; > diff --git a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts > b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts index > ab352159de6572c9..60a1f4356b4b15c7 100644 > --- a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts > +++ b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts > @@ -10,12 +10,12 @@ > */ > > /dts-v1/; > -#include "r8a7795.dtsi" > +#include "r8a7795-es1.dtsi" > #include <dt-bindings/gpio/gpio.h> > #include <dt-bindings/input/input.h> > > / { > - model = "Renesas H3ULCB board based on r8a7795"; > + model = "Renesas H3ULCB board based on r8a7795 ES1.x"; > compatible = "renesas,h3ulcb", "renesas,r8a7795"; > > aliases { > diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts > b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts index > f25241921067dcef..7758b479dd98d2e9 100644 > --- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts > +++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts > @@ -32,11 +32,11 @@ > */ > > /dts-v1/; > -#include "r8a7795.dtsi" > +#include "r8a7795-es1.dtsi" > #include <dt-bindings/gpio/gpio.h> > > / { > - model = "Renesas Salvator-X board based on r8a7795"; > + model = "Renesas Salvator-X board based on r8a7795 ES1.x"; > compatible = "renesas,salvator-x", "renesas,r8a7795"; > > aliases { > diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi > b/arch/arm64/boot/dts/renesas/r8a7795.dtsi index > e99d6443b3e493a4..e1caa4e14593a299 100644 > --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi > +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi > @@ -182,7 +182,7 @@ > clock-frequency = <0>; > }; > > - soc { > + soc: soc { > compatible = "simple-bus"; > interrupt-parent = <&gic>; > > @@ -1274,16 +1274,6 @@ > status = "disabled"; > }; > > - xhci1: usb at ee0400000 { > - compatible = "renesas,xhci-r8a7795", "renesas,rcar- gen3-xhci"; > - reg = <0 0xee040000 0 0xc00>; > - interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>; > - clocks = <&cpg CPG_MOD 327>; > - power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; > - resets = <&cpg 327>; > - status = "disabled"; > - }; > - > usb_dmac0: dma-controller at e65a0000 { > compatible = "renesas,r8a7795-usb-dmac", > "renesas,usb-dmac"; > @@ -1568,14 +1558,6 @@ > resets = <&cpg 614>; > }; > > - fcpf2: fcp at fe952000 { > - compatible = "renesas,fcpf"; > - reg = <0 0xfe952000 0 0x200>; > - clocks = <&cpg CPG_MOD 613>; > - power-domains = <&sysc R8A7795_PD_A3VP>; > - resets = <&cpg 613>; > - }; > - > vspbd: vsp at fe960000 { > compatible = "renesas,vsp2"; > reg = <0 0xfe960000 0 0x8000>; > @@ -1633,25 +1615,6 @@ > resets = <&cpg 610>; > }; > > - vspi2: vsp at fe9c0000 { > - compatible = "renesas,vsp2"; > - reg = <0 0xfe9c0000 0 0x8000>; > - interrupts = <GIC_SPI 446 IRQ_TYPE_LEVEL_HIGH>; > - clocks = <&cpg CPG_MOD 629>; > - power-domains = <&sysc R8A7795_PD_A3VP>; > - resets = <&cpg 629>; > - > - renesas,fcp = <&fcpvi2>; > - }; > - > - fcpvi2: fcp at fe9cf000 { > - compatible = "renesas,fcpv"; > - reg = <0 0xfe9cf000 0 0x200>; > - clocks = <&cpg CPG_MOD 609>; > - power-domains = <&sysc R8A7795_PD_A3VP>; > - resets = <&cpg 609>; > - }; > - > vspd0: vsp at fea20000 { > compatible = "renesas,vsp2"; > reg = <0 0xfea20000 0 0x4000>; > @@ -1709,25 +1672,6 @@ > resets = <&cpg 601>; > }; > > - vspd3: vsp at fea38000 { > - compatible = "renesas,vsp2"; > - reg = <0 0xfea38000 0 0x4000>; > - interrupts = <GIC_SPI 469 IRQ_TYPE_LEVEL_HIGH>; > - clocks = <&cpg CPG_MOD 620>; > - power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; > - resets = <&cpg 620>; > - > - renesas,fcp = <&fcpvd3>; > - }; > - > - fcpvd3: fcp at fea3f000 { > - compatible = "renesas,fcpv"; > - reg = <0 0xfea3f000 0 0x200>; > - clocks = <&cpg CPG_MOD 600>; > - power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; > - resets = <&cpg 600>; > - }; > - > fdp1 at fe940000 { > compatible = "renesas,fdp1"; > reg = <0 0xfe940000 0 0x2400>; > @@ -1748,16 +1692,6 @@ > renesas,fcp = <&fcpf1>; > }; > > - fdp1 at fe948000 { > - compatible = "renesas,fdp1"; > - reg = <0 0xfe948000 0 0x2400>; > - interrupts = <GIC_SPI 264 IRQ_TYPE_LEVEL_HIGH>; > - clocks = <&cpg CPG_MOD 117>; > - power-domains = <&sysc R8A7795_PD_A3VP>; > - resets = <&cpg 117>; > - renesas,fcp = <&fcpf2>; > - }; > - > du: display at feb00000 { > compatible = "renesas,du-r8a7795"; > reg = <0 0xfeb00000 0 0x80000>, > @@ -1775,8 +1709,6 @@ > clock-names = "du.0", "du.1", "du.2", "du.3", "lvds.0"; > status = "disabled"; > > - vsps = <&vspd0 &vspd1 &vspd2 &vspd3>; > - > ports { > #address-cells = <1>; > #size-cells = <0>; -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH/RFC v2 1/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0 2017-03-27 8:48 ` Laurent Pinchart @ 2017-03-29 8:13 ` Simon Horman -1 siblings, 0 replies; 37+ messages in thread From: Simon Horman @ 2017-03-29 8:13 UTC (permalink / raw) To: Laurent Pinchart Cc: Geert Uytterhoeven, Magnus Damm, Yoshihiro Shimoda, Kuninori Morimoto, Wolfram Sang, Rob Herring, Mark Rutland, linux-renesas-soc, devicetree, linux-arm-kernel On Mon, Mar 27, 2017 at 11:48:12AM +0300, Laurent Pinchart wrote: > Hi Geert, > > Thank you for the patch. > > On Friday 24 Mar 2017 14:37:44 Geert Uytterhoeven wrote: > > Update r8a7795.dtsi so it corresponds to R-Car H3 ES2.0 or later: > > - The following devices no longer exist on ES2.0, and are thus removed: > > fcpf2, fcpvd3, fcpvi2, fdp1-2, usb3-if1, vspd3, vspi2. > > - The DU <-> VSPD topology is different on ES2.0, hence remove the > > "vsps" property from the DU node until the driver can handle this. > > I think I'll need a different compatible string between ES1.x and ES2 for the > DU. It could make sense to move the whole DU node to *-es1.dtsi. We can decide > about that later when I'll have a DU driver prototype ready. That makes sense to me. Geert, will you respin this? ^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH/RFC v2 1/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0 @ 2017-03-29 8:13 ` Simon Horman 0 siblings, 0 replies; 37+ messages in thread From: Simon Horman @ 2017-03-29 8:13 UTC (permalink / raw) To: linux-arm-kernel On Mon, Mar 27, 2017 at 11:48:12AM +0300, Laurent Pinchart wrote: > Hi Geert, > > Thank you for the patch. > > On Friday 24 Mar 2017 14:37:44 Geert Uytterhoeven wrote: > > Update r8a7795.dtsi so it corresponds to R-Car H3 ES2.0 or later: > > - The following devices no longer exist on ES2.0, and are thus removed: > > fcpf2, fcpvd3, fcpvi2, fdp1-2, usb3-if1, vspd3, vspi2. > > - The DU <-> VSPD topology is different on ES2.0, hence remove the > > "vsps" property from the DU node until the driver can handle this. > > I think I'll need a different compatible string between ES1.x and ES2 for the > DU. It could make sense to move the whole DU node to *-es1.dtsi. We can decide > about that later when I'll have a DU driver prototype ready. That makes sense to me. Geert, will you respin this? ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH/RFC v2 1/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0 2017-03-29 8:13 ` Simon Horman @ 2017-03-29 8:31 ` Geert Uytterhoeven -1 siblings, 0 replies; 37+ messages in thread From: Geert Uytterhoeven @ 2017-03-29 8:31 UTC (permalink / raw) To: Simon Horman Cc: Laurent Pinchart, Geert Uytterhoeven, Magnus Damm, Yoshihiro Shimoda, Kuninori Morimoto, Wolfram Sang, Rob Herring, Mark Rutland, Linux-Renesas, devicetree, linux-arm-kernel Hi Simon, On Wed, Mar 29, 2017 at 10:13 AM, Simon Horman <horms@verge.net.au> wrote: > On Mon, Mar 27, 2017 at 11:48:12AM +0300, Laurent Pinchart wrote: >> On Friday 24 Mar 2017 14:37:44 Geert Uytterhoeven wrote: >> > Update r8a7795.dtsi so it corresponds to R-Car H3 ES2.0 or later: >> > - The following devices no longer exist on ES2.0, and are thus removed: >> > fcpf2, fcpvd3, fcpvi2, fdp1-2, usb3-if1, vspd3, vspi2. >> > - The DU <-> VSPD topology is different on ES2.0, hence remove the >> > "vsps" property from the DU node until the driver can handle this. >> >> I think I'll need a different compatible string between ES1.x and ES2 for the >> DU. It could make sense to move the whole DU node to *-es1.dtsi. We can decide >> about that later when I'll have a DU driver prototype ready. > > That makes sense to me. > > Geert, will you respin this? Sure. The DTS parts are definitely not v4.12 material. - For ES2.0, they depend on clk/pfc/rcar-sysc updates. - For ES1.x, I don't want to break people's setup (scripts copying r8a7795-salvator-x.dtb) prematurely. 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] 37+ messages in thread
* [PATCH/RFC v2 1/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0 @ 2017-03-29 8:31 ` Geert Uytterhoeven 0 siblings, 0 replies; 37+ messages in thread From: Geert Uytterhoeven @ 2017-03-29 8:31 UTC (permalink / raw) To: linux-arm-kernel Hi Simon, On Wed, Mar 29, 2017 at 10:13 AM, Simon Horman <horms@verge.net.au> wrote: > On Mon, Mar 27, 2017 at 11:48:12AM +0300, Laurent Pinchart wrote: >> On Friday 24 Mar 2017 14:37:44 Geert Uytterhoeven wrote: >> > Update r8a7795.dtsi so it corresponds to R-Car H3 ES2.0 or later: >> > - The following devices no longer exist on ES2.0, and are thus removed: >> > fcpf2, fcpvd3, fcpvi2, fdp1-2, usb3-if1, vspd3, vspi2. >> > - The DU <-> VSPD topology is different on ES2.0, hence remove the >> > "vsps" property from the DU node until the driver can handle this. >> >> I think I'll need a different compatible string between ES1.x and ES2 for the >> DU. It could make sense to move the whole DU node to *-es1.dtsi. We can decide >> about that later when I'll have a DU driver prototype ready. > > That makes sense to me. > > Geert, will you respin this? Sure. The DTS parts are definitely not v4.12 material. - For ES2.0, they depend on clk/pfc/rcar-sysc updates. - For ES1.x, I don't want to break people's setup (scripts copying r8a7795-salvator-x.dtb) prematurely. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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] 37+ messages in thread
* Re: [PATCH/RFC v2 1/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0 2017-03-29 8:31 ` Geert Uytterhoeven @ 2017-03-29 8:45 ` Simon Horman -1 siblings, 0 replies; 37+ messages in thread From: Simon Horman @ 2017-03-29 8:45 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Laurent Pinchart, Geert Uytterhoeven, Magnus Damm, Yoshihiro Shimoda, Kuninori Morimoto, Wolfram Sang, Rob Herring, Mark Rutland, Linux-Renesas, devicetree, linux-arm-kernel On Wed, Mar 29, 2017 at 10:31:02AM +0200, Geert Uytterhoeven wrote: > Hi Simon, > > On Wed, Mar 29, 2017 at 10:13 AM, Simon Horman <horms@verge.net.au> wrote: > > On Mon, Mar 27, 2017 at 11:48:12AM +0300, Laurent Pinchart wrote: > >> On Friday 24 Mar 2017 14:37:44 Geert Uytterhoeven wrote: > >> > Update r8a7795.dtsi so it corresponds to R-Car H3 ES2.0 or later: > >> > - The following devices no longer exist on ES2.0, and are thus removed: > >> > fcpf2, fcpvd3, fcpvi2, fdp1-2, usb3-if1, vspd3, vspi2. > >> > - The DU <-> VSPD topology is different on ES2.0, hence remove the > >> > "vsps" property from the DU node until the driver can handle this. > >> > >> I think I'll need a different compatible string between ES1.x and ES2 for the > >> DU. It could make sense to move the whole DU node to *-es1.dtsi. We can decide > >> about that later when I'll have a DU driver prototype ready. > > > > That makes sense to me. > > > > Geert, will you respin this? > > Sure. The DTS parts are definitely not v4.12 material. > - For ES2.0, they depend on clk/pfc/rcar-sysc updates. > - For ES1.x, I don't want to break people's setup (scripts copying > r8a7795-salvator-x.dtb) prematurely. Ok. ^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH/RFC v2 1/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0 @ 2017-03-29 8:45 ` Simon Horman 0 siblings, 0 replies; 37+ messages in thread From: Simon Horman @ 2017-03-29 8:45 UTC (permalink / raw) To: linux-arm-kernel On Wed, Mar 29, 2017 at 10:31:02AM +0200, Geert Uytterhoeven wrote: > Hi Simon, > > On Wed, Mar 29, 2017 at 10:13 AM, Simon Horman <horms@verge.net.au> wrote: > > On Mon, Mar 27, 2017 at 11:48:12AM +0300, Laurent Pinchart wrote: > >> On Friday 24 Mar 2017 14:37:44 Geert Uytterhoeven wrote: > >> > Update r8a7795.dtsi so it corresponds to R-Car H3 ES2.0 or later: > >> > - The following devices no longer exist on ES2.0, and are thus removed: > >> > fcpf2, fcpvd3, fcpvi2, fdp1-2, usb3-if1, vspd3, vspi2. > >> > - The DU <-> VSPD topology is different on ES2.0, hence remove the > >> > "vsps" property from the DU node until the driver can handle this. > >> > >> I think I'll need a different compatible string between ES1.x and ES2 for the > >> DU. It could make sense to move the whole DU node to *-es1.dtsi. We can decide > >> about that later when I'll have a DU driver prototype ready. > > > > That makes sense to me. > > > > Geert, will you respin this? > > Sure. The DTS parts are definitely not v4.12 material. > - For ES2.0, they depend on clk/pfc/rcar-sysc updates. > - For ES1.x, I don't want to break people's setup (scripts copying > r8a7795-salvator-x.dtb) prematurely. Ok. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH/RFC v2 1/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0 2017-03-27 8:48 ` Laurent Pinchart @ 2017-04-20 9:36 ` Geert Uytterhoeven -1 siblings, 0 replies; 37+ messages in thread From: Geert Uytterhoeven @ 2017-04-20 9:36 UTC (permalink / raw) To: Laurent Pinchart Cc: Geert Uytterhoeven, Simon Horman, Magnus Damm, Yoshihiro Shimoda, Kuninori Morimoto, Wolfram Sang, Rob Herring, Mark Rutland, Linux-Renesas, devicetree, linux-arm-kernel Hi Laurent, On Mon, Mar 27, 2017 at 10:48 AM, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > On Friday 24 Mar 2017 14:37:44 Geert Uytterhoeven wrote: >> Update r8a7795.dtsi so it corresponds to R-Car H3 ES2.0 or later: >> - The following devices no longer exist on ES2.0, and are thus removed: >> fcpf2, fcpvd3, fcpvi2, fdp1-2, usb3-if1, vspd3, vspi2. >> - The DU <-> VSPD topology is different on ES2.0, hence remove the >> "vsps" property from the DU node until the driver can handle this. > > I think I'll need a different compatible string between ES1.x and ES2 for the > DU. It could make sense to move the whole DU node to *-es1.dtsi. We can decide > about that later when I'll have a DU driver prototype ready. Why would you need a different compatible string? Can't you use soc_device_match() to handle ES1.x SoCs? The different DU <-> VSPD topology is handled through the vsps property in DTS. Are the ports different, too? That can be handled in DTS. The main reason why I kept the DU node in r8a7795.dtsi is that the board DTS refers to it. Sharing board DTS means there needs to be at least a placeholder node for the DU in r8a7795.dtsi, unless you want to keep on shuffling board overrides around. 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] 37+ messages in thread
* [PATCH/RFC v2 1/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0 @ 2017-04-20 9:36 ` Geert Uytterhoeven 0 siblings, 0 replies; 37+ messages in thread From: Geert Uytterhoeven @ 2017-04-20 9:36 UTC (permalink / raw) To: linux-arm-kernel Hi Laurent, On Mon, Mar 27, 2017 at 10:48 AM, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > On Friday 24 Mar 2017 14:37:44 Geert Uytterhoeven wrote: >> Update r8a7795.dtsi so it corresponds to R-Car H3 ES2.0 or later: >> - The following devices no longer exist on ES2.0, and are thus removed: >> fcpf2, fcpvd3, fcpvi2, fdp1-2, usb3-if1, vspd3, vspi2. >> - The DU <-> VSPD topology is different on ES2.0, hence remove the >> "vsps" property from the DU node until the driver can handle this. > > I think I'll need a different compatible string between ES1.x and ES2 for the > DU. It could make sense to move the whole DU node to *-es1.dtsi. We can decide > about that later when I'll have a DU driver prototype ready. Why would you need a different compatible string? Can't you use soc_device_match() to handle ES1.x SoCs? The different DU <-> VSPD topology is handled through the vsps property in DTS. Are the ports different, too? That can be handled in DTS. The main reason why I kept the DU node in r8a7795.dtsi is that the board DTS refers to it. Sharing board DTS means there needs to be at least a placeholder node for the DU in r8a7795.dtsi, unless you want to keep on shuffling board overrides around. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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] 37+ messages in thread
* Re: [PATCH/RFC v2 1/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0 2017-04-20 9:36 ` Geert Uytterhoeven @ 2017-04-20 10:42 ` Laurent Pinchart -1 siblings, 0 replies; 37+ messages in thread From: Laurent Pinchart @ 2017-04-20 10:42 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Geert Uytterhoeven, Simon Horman, Magnus Damm, Yoshihiro Shimoda, Kuninori Morimoto, Wolfram Sang, Rob Herring, Mark Rutland, Linux-Renesas, devicetree, linux-arm-kernel Hi Geert, On Thursday 20 Apr 2017 11:36:59 Geert Uytterhoeven wrote: > On Mon, Mar 27, 2017 at 10:48 AM, Laurent Pinchart wrote: > > On Friday 24 Mar 2017 14:37:44 Geert Uytterhoeven wrote: > >> Update r8a7795.dtsi so it corresponds to R-Car H3 ES2.0 or later: > >> - The following devices no longer exist on ES2.0, and are thus removed: > >> fcpf2, fcpvd3, fcpvi2, fdp1-2, usb3-if1, vspd3, vspi2. > >> > >> - The DU <-> VSPD topology is different on ES2.0, hence remove the > >> "vsps" property from the DU node until the driver can handle this. > > > > I think I'll need a different compatible string between ES1.x and ES2 for > > the DU. It could make sense to move the whole DU node to *-es1.dtsi. We > > can decide about that later when I'll have a DU driver prototype ready. > > Why would you need a different compatible string? > Can't you use soc_device_match() to handle ES1.x SoCs? > > The different DU <-> VSPD topology is handled through the vsps property in > DTS. Are the ports different, too? That can be handled in DTS. My point (not expressed clearly) was that, as I'll need a different vsps property, I can as well go for a different compatible string. > The main reason why I kept the DU node in r8a7795.dtsi is that the board DTS > refers to it. Sharing board DTS means there needs to be at least a > placeholder node for the DU in r8a7795.dtsi, unless you want to keep on > shuffling board overrides around. As the ports are identical it makes sense to share the same board DTS, I agree with you. We could override the compatible string in r8a7795-es1.dtsi and leave it blank in r8a7795.dtsi for now, as there's no driver support for ES2.0. That's a bit of a workaround as it shouldn't matter to DT whether driver support is available or not. On the other hand, leaving the vsps property out is a workaround too. The current driver will fail probing if the number of VSPs is different than the number of CRTCs, so I believe you can keep the vsps property in r8a7795.dtsi with 3 VSPS without causing any problem. However, there's no DT bindings for the H3 ES2.0 DU yet, so we would end up merging DT without bindings, which is not good. I think that regardless of how we proceed, keeping the DU node in the ES2.0 .dtsi will be a violation of that policy. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH/RFC v2 1/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0 @ 2017-04-20 10:42 ` Laurent Pinchart 0 siblings, 0 replies; 37+ messages in thread From: Laurent Pinchart @ 2017-04-20 10:42 UTC (permalink / raw) To: linux-arm-kernel Hi Geert, On Thursday 20 Apr 2017 11:36:59 Geert Uytterhoeven wrote: > On Mon, Mar 27, 2017 at 10:48 AM, Laurent Pinchart wrote: > > On Friday 24 Mar 2017 14:37:44 Geert Uytterhoeven wrote: > >> Update r8a7795.dtsi so it corresponds to R-Car H3 ES2.0 or later: > >> - The following devices no longer exist on ES2.0, and are thus removed: > >> fcpf2, fcpvd3, fcpvi2, fdp1-2, usb3-if1, vspd3, vspi2. > >> > >> - The DU <-> VSPD topology is different on ES2.0, hence remove the > >> "vsps" property from the DU node until the driver can handle this. > > > > I think I'll need a different compatible string between ES1.x and ES2 for > > the DU. It could make sense to move the whole DU node to *-es1.dtsi. We > > can decide about that later when I'll have a DU driver prototype ready. > > Why would you need a different compatible string? > Can't you use soc_device_match() to handle ES1.x SoCs? > > The different DU <-> VSPD topology is handled through the vsps property in > DTS. Are the ports different, too? That can be handled in DTS. My point (not expressed clearly) was that, as I'll need a different vsps property, I can as well go for a different compatible string. > The main reason why I kept the DU node in r8a7795.dtsi is that the board DTS > refers to it. Sharing board DTS means there needs to be at least a > placeholder node for the DU in r8a7795.dtsi, unless you want to keep on > shuffling board overrides around. As the ports are identical it makes sense to share the same board DTS, I agree with you. We could override the compatible string in r8a7795-es1.dtsi and leave it blank in r8a7795.dtsi for now, as there's no driver support for ES2.0. That's a bit of a workaround as it shouldn't matter to DT whether driver support is available or not. On the other hand, leaving the vsps property out is a workaround too. The current driver will fail probing if the number of VSPs is different than the number of CRTCs, so I believe you can keep the vsps property in r8a7795.dtsi with 3 VSPS without causing any problem. However, there's no DT bindings for the H3 ES2.0 DU yet, so we would end up merging DT without bindings, which is not good. I think that regardless of how we proceed, keeping the DU node in the ES2.0 .dtsi will be a violation of that policy. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH/RFC v2 1/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0 2017-04-20 10:42 ` Laurent Pinchart (?) @ 2017-04-20 10:55 ` Geert Uytterhoeven -1 siblings, 0 replies; 37+ messages in thread From: Geert Uytterhoeven @ 2017-04-20 10:55 UTC (permalink / raw) To: Laurent Pinchart Cc: Mark Rutland, devicetree, Geert Uytterhoeven, Kuninori Morimoto, Yoshihiro Shimoda, Magnus Damm, Rob Herring, Wolfram Sang, Linux-Renesas, Simon Horman, linux-arm-kernel Hi Laurent, On Thu, Apr 20, 2017 at 12:42 PM, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > On Thursday 20 Apr 2017 11:36:59 Geert Uytterhoeven wrote: >> On Mon, Mar 27, 2017 at 10:48 AM, Laurent Pinchart wrote: >> > On Friday 24 Mar 2017 14:37:44 Geert Uytterhoeven wrote: >> >> Update r8a7795.dtsi so it corresponds to R-Car H3 ES2.0 or later: >> >> - The following devices no longer exist on ES2.0, and are thus removed: >> >> fcpf2, fcpvd3, fcpvi2, fdp1-2, usb3-if1, vspd3, vspi2. >> >> >> >> - The DU <-> VSPD topology is different on ES2.0, hence remove the >> >> "vsps" property from the DU node until the driver can handle this. >> > >> > I think I'll need a different compatible string between ES1.x and ES2 for >> > the DU. It could make sense to move the whole DU node to *-es1.dtsi. We >> > can decide about that later when I'll have a DU driver prototype ready. >> >> Why would you need a different compatible string? >> Can't you use soc_device_match() to handle ES1.x SoCs? >> >> The different DU <-> VSPD topology is handled through the vsps property in >> DTS. Are the ports different, too? That can be handled in DTS. > > My point (not expressed clearly) was that, as I'll need a different vsps > property, I can as well go for a different compatible string. Do you need a different vsps property? AFAIK, the current array links each DU channel to a VSPD. When a VSPD is shared between multiple channels, you can still link these channels to the same VSPD. Or is my understanding incorrect? >> The main reason why I kept the DU node in r8a7795.dtsi is that the board DTS >> refers to it. Sharing board DTS means there needs to be at least a >> placeholder node for the DU in r8a7795.dtsi, unless you want to keep on >> shuffling board overrides around. > > As the ports are identical it makes sense to share the same board DTS, I agree > with you. We could override the compatible string in r8a7795-es1.dtsi and > leave it blank in r8a7795.dtsi for now, as there's no driver support for > ES2.0. That's a bit of a workaround as it shouldn't matter to DT whether > driver support is available or not. On the other hand, leaving the vsps > property out is a workaround too. > > The current driver will fail probing if the number of VSPs is different than > the number of CRTCs, so I believe you can keep the vsps property in > r8a7795.dtsi with 3 VSPS without causing any problem. However, there's no DT > bindings for the H3 ES2.0 DU yet, so we would end up merging DT without > bindings, which is not good. I think that regardless of how we proceed, > keeping the DU node in the ES2.0 .dtsi will be a violation of that policy. What does the current driver do if the number of VSPs is the same as the number of CRTCs, but some VSPs are listed more than once? I guess it will break in a subtle way, instead of refusing to probe? 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] 37+ messages in thread
* [PATCH/RFC v2 1/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0 @ 2017-04-20 10:55 ` Geert Uytterhoeven 0 siblings, 0 replies; 37+ messages in thread From: Geert Uytterhoeven @ 2017-04-20 10:55 UTC (permalink / raw) To: linux-arm-kernel Hi Laurent, On Thu, Apr 20, 2017 at 12:42 PM, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > On Thursday 20 Apr 2017 11:36:59 Geert Uytterhoeven wrote: >> On Mon, Mar 27, 2017 at 10:48 AM, Laurent Pinchart wrote: >> > On Friday 24 Mar 2017 14:37:44 Geert Uytterhoeven wrote: >> >> Update r8a7795.dtsi so it corresponds to R-Car H3 ES2.0 or later: >> >> - The following devices no longer exist on ES2.0, and are thus removed: >> >> fcpf2, fcpvd3, fcpvi2, fdp1-2, usb3-if1, vspd3, vspi2. >> >> >> >> - The DU <-> VSPD topology is different on ES2.0, hence remove the >> >> "vsps" property from the DU node until the driver can handle this. >> > >> > I think I'll need a different compatible string between ES1.x and ES2 for >> > the DU. It could make sense to move the whole DU node to *-es1.dtsi. We >> > can decide about that later when I'll have a DU driver prototype ready. >> >> Why would you need a different compatible string? >> Can't you use soc_device_match() to handle ES1.x SoCs? >> >> The different DU <-> VSPD topology is handled through the vsps property in >> DTS. Are the ports different, too? That can be handled in DTS. > > My point (not expressed clearly) was that, as I'll need a different vsps > property, I can as well go for a different compatible string. Do you need a different vsps property? AFAIK, the current array links each DU channel to a VSPD. When a VSPD is shared between multiple channels, you can still link these channels to the same VSPD. Or is my understanding incorrect? >> The main reason why I kept the DU node in r8a7795.dtsi is that the board DTS >> refers to it. Sharing board DTS means there needs to be at least a >> placeholder node for the DU in r8a7795.dtsi, unless you want to keep on >> shuffling board overrides around. > > As the ports are identical it makes sense to share the same board DTS, I agree > with you. We could override the compatible string in r8a7795-es1.dtsi and > leave it blank in r8a7795.dtsi for now, as there's no driver support for > ES2.0. That's a bit of a workaround as it shouldn't matter to DT whether > driver support is available or not. On the other hand, leaving the vsps > property out is a workaround too. > > The current driver will fail probing if the number of VSPs is different than > the number of CRTCs, so I believe you can keep the vsps property in > r8a7795.dtsi with 3 VSPS without causing any problem. However, there's no DT > bindings for the H3 ES2.0 DU yet, so we would end up merging DT without > bindings, which is not good. I think that regardless of how we proceed, > keeping the DU node in the ES2.0 .dtsi will be a violation of that policy. What does the current driver do if the number of VSPs is the same as the number of CRTCs, but some VSPs are listed more than once? I guess it will break in a subtle way, instead of refusing to probe? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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] 37+ messages in thread
* Re: [PATCH/RFC v2 1/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0 @ 2017-04-20 10:55 ` Geert Uytterhoeven 0 siblings, 0 replies; 37+ messages in thread From: Geert Uytterhoeven @ 2017-04-20 10:55 UTC (permalink / raw) To: Laurent Pinchart Cc: Geert Uytterhoeven, Simon Horman, Magnus Damm, Yoshihiro Shimoda, Kuninori Morimoto, Wolfram Sang, Rob Herring, Mark Rutland, Linux-Renesas, devicetree, linux-arm-kernel Hi Laurent, On Thu, Apr 20, 2017 at 12:42 PM, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > On Thursday 20 Apr 2017 11:36:59 Geert Uytterhoeven wrote: >> On Mon, Mar 27, 2017 at 10:48 AM, Laurent Pinchart wrote: >> > On Friday 24 Mar 2017 14:37:44 Geert Uytterhoeven wrote: >> >> Update r8a7795.dtsi so it corresponds to R-Car H3 ES2.0 or later: >> >> - The following devices no longer exist on ES2.0, and are thus removed: >> >> fcpf2, fcpvd3, fcpvi2, fdp1-2, usb3-if1, vspd3, vspi2. >> >> >> >> - The DU <-> VSPD topology is different on ES2.0, hence remove the >> >> "vsps" property from the DU node until the driver can handle this. >> > >> > I think I'll need a different compatible string between ES1.x and ES2 for >> > the DU. It could make sense to move the whole DU node to *-es1.dtsi. We >> > can decide about that later when I'll have a DU driver prototype ready. >> >> Why would you need a different compatible string? >> Can't you use soc_device_match() to handle ES1.x SoCs? >> >> The different DU <-> VSPD topology is handled through the vsps property in >> DTS. Are the ports different, too? That can be handled in DTS. > > My point (not expressed clearly) was that, as I'll need a different vsps > property, I can as well go for a different compatible string. Do you need a different vsps property? AFAIK, the current array links each DU channel to a VSPD. When a VSPD is shared between multiple channels, you can still link these channels to the same VSPD. Or is my understanding incorrect? >> The main reason why I kept the DU node in r8a7795.dtsi is that the board DTS >> refers to it. Sharing board DTS means there needs to be at least a >> placeholder node for the DU in r8a7795.dtsi, unless you want to keep on >> shuffling board overrides around. > > As the ports are identical it makes sense to share the same board DTS, I agree > with you. We could override the compatible string in r8a7795-es1.dtsi and > leave it blank in r8a7795.dtsi for now, as there's no driver support for > ES2.0. That's a bit of a workaround as it shouldn't matter to DT whether > driver support is available or not. On the other hand, leaving the vsps > property out is a workaround too. > > The current driver will fail probing if the number of VSPs is different than > the number of CRTCs, so I believe you can keep the vsps property in > r8a7795.dtsi with 3 VSPS without causing any problem. However, there's no DT > bindings for the H3 ES2.0 DU yet, so we would end up merging DT without > bindings, which is not good. I think that regardless of how we proceed, > keeping the DU node in the ES2.0 .dtsi will be a violation of that policy. What does the current driver do if the number of VSPs is the same as the number of CRTCs, but some VSPs are listed more than once? I guess it will break in a subtle way, instead of refusing to probe? 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] 37+ messages in thread
[parent not found: <CAMuHMdWmvhZjxKfEdGJ3d_w0d2s2kK+8iW1tsEM584qZc+dVEQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH/RFC v2 1/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0 2017-04-20 10:55 ` Geert Uytterhoeven (?) @ 2017-04-20 11:24 ` Laurent Pinchart -1 siblings, 0 replies; 37+ messages in thread From: Laurent Pinchart @ 2017-04-20 11:24 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Geert Uytterhoeven, Simon Horman, Magnus Damm, Yoshihiro Shimoda, Kuninori Morimoto, Wolfram Sang, Rob Herring, Mark Rutland, Linux-Renesas, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r Hi Geert, On Thursday 20 Apr 2017 12:55:28 Geert Uytterhoeven wrote: > On Thu, Apr 20, 2017 at 12:42 PM, Laurent Pinchart wrote: > > On Thursday 20 Apr 2017 11:36:59 Geert Uytterhoeven wrote: > >> On Mon, Mar 27, 2017 at 10:48 AM, Laurent Pinchart wrote: > >>> On Friday 24 Mar 2017 14:37:44 Geert Uytterhoeven wrote: > >>>> Update r8a7795.dtsi so it corresponds to R-Car H3 ES2.0 or later: > >>>> - The following devices no longer exist on ES2.0, and are thus > >>>> removed: > >>>> fcpf2, fcpvd3, fcpvi2, fdp1-2, usb3-if1, vspd3, vspi2. > >>>> > >>>> - The DU <-> VSPD topology is different on ES2.0, hence remove the > >>>> "vsps" property from the DU node until the driver can handle this. > >>> > >>> I think I'll need a different compatible string between ES1.x and ES2 > >>> for the DU. It could make sense to move the whole DU node to *-es1.dtsi. > >>> We can decide about that later when I'll have a DU driver prototype > >>> ready. > >> > >> Why would you need a different compatible string? > >> Can't you use soc_device_match() to handle ES1.x SoCs? > >> > >> The different DU <-> VSPD topology is handled through the vsps property > >> in > >> DTS. Are the ports different, too? That can be handled in DTS. > > > > My point (not expressed clearly) was that, as I'll need a different vsps > > property, I can as well go for a different compatible string. > > Do you need a different vsps property? > AFAIK, the current array links each DU channel to a VSPD. > When a VSPD is shared between multiple channels, you can still link these > channels to the same VSPD. > > Or is my understanding incorrect? Do you mean listing the same VSP multiple times in the vsps array ? Yes, from a bindings point of view I think that would work too. That is, until we get a ES2.1 that will have a completely different hardware topology :-) > >> The main reason why I kept the DU node in r8a7795.dtsi is that the board > >> DTS refers to it. Sharing board DTS means there needs to be at least a > >> placeholder node for the DU in r8a7795.dtsi, unless you want to keep on > >> shuffling board overrides around. > > > > As the ports are identical it makes sense to share the same board DTS, I > > agree with you. We could override the compatible string in > > r8a7795-es1.dtsi and leave it blank in r8a7795.dtsi for now, as there's > > no driver support for ES2.0. That's a bit of a workaround as it shouldn't > > matter to DT whether driver support is available or not. On the other > > hand, leaving the vsps property out is a workaround too. > > > > The current driver will fail probing if the number of VSPs is different > > than the number of CRTCs, so I believe you can keep the vsps property in > > r8a7795.dtsi with 3 VSPS without causing any problem. However, there's no > > DT bindings for the H3 ES2.0 DU yet, so we would end up merging DT > > without bindings, which is not good. I think that regardless of how we > > proceed, keeping the DU node in the ES2.0 .dtsi will be a violation of > > that policy. > > What does the current driver do if the number of VSPs is the same as the > number of CRTCs, but some VSPs are listed more than once? > I guess it will break in a subtle way, instead of refusing to probe? Correct, it will be messy. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH/RFC v2 1/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0 @ 2017-04-20 11:24 ` Laurent Pinchart 0 siblings, 0 replies; 37+ messages in thread From: Laurent Pinchart @ 2017-04-20 11:24 UTC (permalink / raw) To: linux-arm-kernel Hi Geert, On Thursday 20 Apr 2017 12:55:28 Geert Uytterhoeven wrote: > On Thu, Apr 20, 2017 at 12:42 PM, Laurent Pinchart wrote: > > On Thursday 20 Apr 2017 11:36:59 Geert Uytterhoeven wrote: > >> On Mon, Mar 27, 2017 at 10:48 AM, Laurent Pinchart wrote: > >>> On Friday 24 Mar 2017 14:37:44 Geert Uytterhoeven wrote: > >>>> Update r8a7795.dtsi so it corresponds to R-Car H3 ES2.0 or later: > >>>> - The following devices no longer exist on ES2.0, and are thus > >>>> removed: > >>>> fcpf2, fcpvd3, fcpvi2, fdp1-2, usb3-if1, vspd3, vspi2. > >>>> > >>>> - The DU <-> VSPD topology is different on ES2.0, hence remove the > >>>> "vsps" property from the DU node until the driver can handle this. > >>> > >>> I think I'll need a different compatible string between ES1.x and ES2 > >>> for the DU. It could make sense to move the whole DU node to *-es1.dtsi. > >>> We can decide about that later when I'll have a DU driver prototype > >>> ready. > >> > >> Why would you need a different compatible string? > >> Can't you use soc_device_match() to handle ES1.x SoCs? > >> > >> The different DU <-> VSPD topology is handled through the vsps property > >> in > >> DTS. Are the ports different, too? That can be handled in DTS. > > > > My point (not expressed clearly) was that, as I'll need a different vsps > > property, I can as well go for a different compatible string. > > Do you need a different vsps property? > AFAIK, the current array links each DU channel to a VSPD. > When a VSPD is shared between multiple channels, you can still link these > channels to the same VSPD. > > Or is my understanding incorrect? Do you mean listing the same VSP multiple times in the vsps array ? Yes, from a bindings point of view I think that would work too. That is, until we get a ES2.1 that will have a completely different hardware topology :-) > >> The main reason why I kept the DU node in r8a7795.dtsi is that the board > >> DTS refers to it. Sharing board DTS means there needs to be at least a > >> placeholder node for the DU in r8a7795.dtsi, unless you want to keep on > >> shuffling board overrides around. > > > > As the ports are identical it makes sense to share the same board DTS, I > > agree with you. We could override the compatible string in > > r8a7795-es1.dtsi and leave it blank in r8a7795.dtsi for now, as there's > > no driver support for ES2.0. That's a bit of a workaround as it shouldn't > > matter to DT whether driver support is available or not. On the other > > hand, leaving the vsps property out is a workaround too. > > > > The current driver will fail probing if the number of VSPs is different > > than the number of CRTCs, so I believe you can keep the vsps property in > > r8a7795.dtsi with 3 VSPS without causing any problem. However, there's no > > DT bindings for the H3 ES2.0 DU yet, so we would end up merging DT > > without bindings, which is not good. I think that regardless of how we > > proceed, keeping the DU node in the ES2.0 .dtsi will be a violation of > > that policy. > > What does the current driver do if the number of VSPs is the same as the > number of CRTCs, but some VSPs are listed more than once? > I guess it will break in a subtle way, instead of refusing to probe? Correct, it will be messy. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH/RFC v2 1/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0 @ 2017-04-20 11:24 ` Laurent Pinchart 0 siblings, 0 replies; 37+ messages in thread From: Laurent Pinchart @ 2017-04-20 11:24 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Geert Uytterhoeven, Simon Horman, Magnus Damm, Yoshihiro Shimoda, Kuninori Morimoto, Wolfram Sang, Rob Herring, Mark Rutland, Linux-Renesas, devicetree, linux-arm-kernel Hi Geert, On Thursday 20 Apr 2017 12:55:28 Geert Uytterhoeven wrote: > On Thu, Apr 20, 2017 at 12:42 PM, Laurent Pinchart wrote: > > On Thursday 20 Apr 2017 11:36:59 Geert Uytterhoeven wrote: > >> On Mon, Mar 27, 2017 at 10:48 AM, Laurent Pinchart wrote: > >>> On Friday 24 Mar 2017 14:37:44 Geert Uytterhoeven wrote: > >>>> Update r8a7795.dtsi so it corresponds to R-Car H3 ES2.0 or later: > >>>> - The following devices no longer exist on ES2.0, and are thus > >>>> removed: > >>>> fcpf2, fcpvd3, fcpvi2, fdp1-2, usb3-if1, vspd3, vspi2. > >>>> > >>>> - The DU <-> VSPD topology is different on ES2.0, hence remove the > >>>> "vsps" property from the DU node until the driver can handle this. > >>> > >>> I think I'll need a different compatible string between ES1.x and ES2 > >>> for the DU. It could make sense to move the whole DU node to *-es1.dtsi. > >>> We can decide about that later when I'll have a DU driver prototype > >>> ready. > >> > >> Why would you need a different compatible string? > >> Can't you use soc_device_match() to handle ES1.x SoCs? > >> > >> The different DU <-> VSPD topology is handled through the vsps property > >> in > >> DTS. Are the ports different, too? That can be handled in DTS. > > > > My point (not expressed clearly) was that, as I'll need a different vsps > > property, I can as well go for a different compatible string. > > Do you need a different vsps property? > AFAIK, the current array links each DU channel to a VSPD. > When a VSPD is shared between multiple channels, you can still link these > channels to the same VSPD. > > Or is my understanding incorrect? Do you mean listing the same VSP multiple times in the vsps array ? Yes, from a bindings point of view I think that would work too. That is, until we get a ES2.1 that will have a completely different hardware topology :-) > >> The main reason why I kept the DU node in r8a7795.dtsi is that the board > >> DTS refers to it. Sharing board DTS means there needs to be at least a > >> placeholder node for the DU in r8a7795.dtsi, unless you want to keep on > >> shuffling board overrides around. > > > > As the ports are identical it makes sense to share the same board DTS, I > > agree with you. We could override the compatible string in > > r8a7795-es1.dtsi and leave it blank in r8a7795.dtsi for now, as there's > > no driver support for ES2.0. That's a bit of a workaround as it shouldn't > > matter to DT whether driver support is available or not. On the other > > hand, leaving the vsps property out is a workaround too. > > > > The current driver will fail probing if the number of VSPs is different > > than the number of CRTCs, so I believe you can keep the vsps property in > > r8a7795.dtsi with 3 VSPS without causing any problem. However, there's no > > DT bindings for the H3 ES2.0 DU yet, so we would end up merging DT > > without bindings, which is not good. I think that regardless of how we > > proceed, keeping the DU node in the ES2.0 .dtsi will be a violation of > > that policy. > > What does the current driver do if the number of VSPs is the same as the > number of CRTCs, but some VSPs are listed more than once? > I guess it will break in a subtle way, instead of refusing to probe? Correct, it will be messy. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH/RFC v2 1/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0 2017-04-20 11:24 ` Laurent Pinchart @ 2017-04-20 11:36 ` Geert Uytterhoeven -1 siblings, 0 replies; 37+ messages in thread From: Geert Uytterhoeven @ 2017-04-20 11:36 UTC (permalink / raw) To: Laurent Pinchart Cc: Geert Uytterhoeven, Simon Horman, Magnus Damm, Yoshihiro Shimoda, Kuninori Morimoto, Wolfram Sang, Rob Herring, Mark Rutland, Linux-Renesas, devicetree, linux-arm-kernel Hi Laurent, On Thu, Apr 20, 2017 at 1:24 PM, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > On Thursday 20 Apr 2017 12:55:28 Geert Uytterhoeven wrote: >> On Thu, Apr 20, 2017 at 12:42 PM, Laurent Pinchart wrote: >> > On Thursday 20 Apr 2017 11:36:59 Geert Uytterhoeven wrote: >> >> On Mon, Mar 27, 2017 at 10:48 AM, Laurent Pinchart wrote: >> >>> On Friday 24 Mar 2017 14:37:44 Geert Uytterhoeven wrote: >> >>>> Update r8a7795.dtsi so it corresponds to R-Car H3 ES2.0 or later: >> >>>> - The following devices no longer exist on ES2.0, and are thus >> >>>> removed: >> >>>> fcpf2, fcpvd3, fcpvi2, fdp1-2, usb3-if1, vspd3, vspi2. >> >>>> >> >>>> - The DU <-> VSPD topology is different on ES2.0, hence remove the >> >>>> "vsps" property from the DU node until the driver can handle this. >> >>> >> >>> I think I'll need a different compatible string between ES1.x and ES2 >> >>> for the DU. It could make sense to move the whole DU node to *-es1.dtsi. >> >>> We can decide about that later when I'll have a DU driver prototype >> >>> ready. >> >> >> >> Why would you need a different compatible string? >> >> Can't you use soc_device_match() to handle ES1.x SoCs? >> >> >> >> The different DU <-> VSPD topology is handled through the vsps property >> >> in >> >> DTS. Are the ports different, too? That can be handled in DTS. >> > >> > My point (not expressed clearly) was that, as I'll need a different vsps >> > property, I can as well go for a different compatible string. >> >> Do you need a different vsps property? >> AFAIK, the current array links each DU channel to a VSPD. >> When a VSPD is shared between multiple channels, you can still link these >> channels to the same VSPD. >> >> Or is my understanding incorrect? > > Do you mean listing the same VSP multiple times in the vsps array ? Yes, from Yes, that's what I mean. > a bindings point of view I think that would work too. That is, until we get a OK. > ES2.1 that will have a completely different hardware topology :-) We'll fix that after we have received ES2.1 documentation... 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] 37+ messages in thread
* [PATCH/RFC v2 1/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0 @ 2017-04-20 11:36 ` Geert Uytterhoeven 0 siblings, 0 replies; 37+ messages in thread From: Geert Uytterhoeven @ 2017-04-20 11:36 UTC (permalink / raw) To: linux-arm-kernel Hi Laurent, On Thu, Apr 20, 2017 at 1:24 PM, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > On Thursday 20 Apr 2017 12:55:28 Geert Uytterhoeven wrote: >> On Thu, Apr 20, 2017 at 12:42 PM, Laurent Pinchart wrote: >> > On Thursday 20 Apr 2017 11:36:59 Geert Uytterhoeven wrote: >> >> On Mon, Mar 27, 2017 at 10:48 AM, Laurent Pinchart wrote: >> >>> On Friday 24 Mar 2017 14:37:44 Geert Uytterhoeven wrote: >> >>>> Update r8a7795.dtsi so it corresponds to R-Car H3 ES2.0 or later: >> >>>> - The following devices no longer exist on ES2.0, and are thus >> >>>> removed: >> >>>> fcpf2, fcpvd3, fcpvi2, fdp1-2, usb3-if1, vspd3, vspi2. >> >>>> >> >>>> - The DU <-> VSPD topology is different on ES2.0, hence remove the >> >>>> "vsps" property from the DU node until the driver can handle this. >> >>> >> >>> I think I'll need a different compatible string between ES1.x and ES2 >> >>> for the DU. It could make sense to move the whole DU node to *-es1.dtsi. >> >>> We can decide about that later when I'll have a DU driver prototype >> >>> ready. >> >> >> >> Why would you need a different compatible string? >> >> Can't you use soc_device_match() to handle ES1.x SoCs? >> >> >> >> The different DU <-> VSPD topology is handled through the vsps property >> >> in >> >> DTS. Are the ports different, too? That can be handled in DTS. >> > >> > My point (not expressed clearly) was that, as I'll need a different vsps >> > property, I can as well go for a different compatible string. >> >> Do you need a different vsps property? >> AFAIK, the current array links each DU channel to a VSPD. >> When a VSPD is shared between multiple channels, you can still link these >> channels to the same VSPD. >> >> Or is my understanding incorrect? > > Do you mean listing the same VSP multiple times in the vsps array ? Yes, from Yes, that's what I mean. > a bindings point of view I think that would work too. That is, until we get a OK. > ES2.1 that will have a completely different hardware topology :-) We'll fix that after we have received ES2.1 documentation... Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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] 37+ messages in thread
* [PATCH/RFC v2 2/2] arm64: dts: r8a7795: salvator-x: Add support for R-Car H3 ES2.0 2017-03-24 13:37 ` Geert Uytterhoeven (?) @ 2017-03-24 13:37 ` Geert Uytterhoeven -1 siblings, 0 replies; 37+ messages in thread From: Geert Uytterhoeven @ 2017-03-24 13:37 UTC (permalink / raw) To: Simon Horman, Magnus Damm Cc: Yoshihiro Shimoda, Kuninori Morimoto, Laurent Pinchart, Wolfram Sang, Rob Herring, Mark Rutland, linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Geert Uytterhoeven Split off support for Salvator-X boards with the ES1.x revision of the R-Car H3 SoC into a separate file. The main r8a7795-salvator-x.dts file now corresponds to Salvator-X with R-Car H3 ES2.0 or later. Signed-off-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org> --- v2: - Use a separate file for ES1.x instead of for ES2.0, so r8a7795-salvator-x.dts always corresponds to the board with the latest SoC revision, - Add a dash between SoC part number and revision, for compatibility with the BSP, - Enhance the hardware description from basic support to everything already supported on ES1.x. --- arch/arm64/boot/dts/renesas/Makefile | 1 + .../renesas/{r8a7795-salvator-x.dts => r8a7795-es1-salvator-x.dts} | 0 arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 4 ++-- 3 files changed, 3 insertions(+), 2 deletions(-) copy arch/arm64/boot/dts/renesas/{r8a7795-salvator-x.dts => r8a7795-es1-salvator-x.dts} (100%) diff --git a/arch/arm64/boot/dts/renesas/Makefile b/arch/arm64/boot/dts/renesas/Makefile index 1618e0a3c81d48bd..b6c723d8f6875f2d 100644 --- a/arch/arm64/boot/dts/renesas/Makefile +++ b/arch/arm64/boot/dts/renesas/Makefile @@ -1,4 +1,5 @@ dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-salvator-x.dtb r8a7795-h3ulcb.dtb +dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-es1-salvator-x.dtb dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-salvator-x.dtb r8a7796-m3ulcb.dtb always := $(dtb-y) diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts b/arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dts similarity index 100% copy from arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts copy to arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dts diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts index 7758b479dd98d2e9..baf5d34653d27e28 100644 --- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts +++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts @@ -32,11 +32,11 @@ */ /dts-v1/; -#include "r8a7795-es1.dtsi" +#include "r8a7795.dtsi" #include <dt-bindings/gpio/gpio.h> / { - model = "Renesas Salvator-X board based on r8a7795 ES1.x"; + model = "Renesas Salvator-X board based on r8a7795 ES2.0+"; compatible = "renesas,salvator-x", "renesas,r8a7795"; aliases { -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply related [flat|nested] 37+ messages in thread
* [PATCH/RFC v2 2/2] arm64: dts: r8a7795: salvator-x: Add support for R-Car H3 ES2.0 @ 2017-03-24 13:37 ` Geert Uytterhoeven 0 siblings, 0 replies; 37+ messages in thread From: Geert Uytterhoeven @ 2017-03-24 13:37 UTC (permalink / raw) To: linux-arm-kernel Split off support for Salvator-X boards with the ES1.x revision of the R-Car H3 SoC into a separate file. The main r8a7795-salvator-x.dts file now corresponds to Salvator-X with R-Car H3 ES2.0 or later. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> --- v2: - Use a separate file for ES1.x instead of for ES2.0, so r8a7795-salvator-x.dts always corresponds to the board with the latest SoC revision, - Add a dash between SoC part number and revision, for compatibility with the BSP, - Enhance the hardware description from basic support to everything already supported on ES1.x. --- arch/arm64/boot/dts/renesas/Makefile | 1 + .../renesas/{r8a7795-salvator-x.dts => r8a7795-es1-salvator-x.dts} | 0 arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 4 ++-- 3 files changed, 3 insertions(+), 2 deletions(-) copy arch/arm64/boot/dts/renesas/{r8a7795-salvator-x.dts => r8a7795-es1-salvator-x.dts} (100%) diff --git a/arch/arm64/boot/dts/renesas/Makefile b/arch/arm64/boot/dts/renesas/Makefile index 1618e0a3c81d48bd..b6c723d8f6875f2d 100644 --- a/arch/arm64/boot/dts/renesas/Makefile +++ b/arch/arm64/boot/dts/renesas/Makefile @@ -1,4 +1,5 @@ dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-salvator-x.dtb r8a7795-h3ulcb.dtb +dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-es1-salvator-x.dtb dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-salvator-x.dtb r8a7796-m3ulcb.dtb always := $(dtb-y) diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts b/arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dts similarity index 100% copy from arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts copy to arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dts diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts index 7758b479dd98d2e9..baf5d34653d27e28 100644 --- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts +++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts @@ -32,11 +32,11 @@ */ /dts-v1/; -#include "r8a7795-es1.dtsi" +#include "r8a7795.dtsi" #include <dt-bindings/gpio/gpio.h> / { - model = "Renesas Salvator-X board based on r8a7795 ES1.x"; + model = "Renesas Salvator-X board based on r8a7795 ES2.0+"; compatible = "renesas,salvator-x", "renesas,r8a7795"; aliases { -- 2.7.4 ^ permalink raw reply related [flat|nested] 37+ messages in thread
* [PATCH/RFC v2 2/2] arm64: dts: r8a7795: salvator-x: Add support for R-Car H3 ES2.0 @ 2017-03-24 13:37 ` Geert Uytterhoeven 0 siblings, 0 replies; 37+ messages in thread From: Geert Uytterhoeven @ 2017-03-24 13:37 UTC (permalink / raw) To: Simon Horman, Magnus Damm Cc: Yoshihiro Shimoda, Kuninori Morimoto, Laurent Pinchart, Wolfram Sang, Rob Herring, Mark Rutland, linux-renesas-soc, devicetree, linux-arm-kernel, Geert Uytterhoeven Split off support for Salvator-X boards with the ES1.x revision of the R-Car H3 SoC into a separate file. The main r8a7795-salvator-x.dts file now corresponds to Salvator-X with R-Car H3 ES2.0 or later. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> --- v2: - Use a separate file for ES1.x instead of for ES2.0, so r8a7795-salvator-x.dts always corresponds to the board with the latest SoC revision, - Add a dash between SoC part number and revision, for compatibility with the BSP, - Enhance the hardware description from basic support to everything already supported on ES1.x. --- arch/arm64/boot/dts/renesas/Makefile | 1 + .../renesas/{r8a7795-salvator-x.dts => r8a7795-es1-salvator-x.dts} | 0 arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 4 ++-- 3 files changed, 3 insertions(+), 2 deletions(-) copy arch/arm64/boot/dts/renesas/{r8a7795-salvator-x.dts => r8a7795-es1-salvator-x.dts} (100%) diff --git a/arch/arm64/boot/dts/renesas/Makefile b/arch/arm64/boot/dts/renesas/Makefile index 1618e0a3c81d48bd..b6c723d8f6875f2d 100644 --- a/arch/arm64/boot/dts/renesas/Makefile +++ b/arch/arm64/boot/dts/renesas/Makefile @@ -1,4 +1,5 @@ dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-salvator-x.dtb r8a7795-h3ulcb.dtb +dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-es1-salvator-x.dtb dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-salvator-x.dtb r8a7796-m3ulcb.dtb always := $(dtb-y) diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts b/arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dts similarity index 100% copy from arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts copy to arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dts diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts index 7758b479dd98d2e9..baf5d34653d27e28 100644 --- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts +++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts @@ -32,11 +32,11 @@ */ /dts-v1/; -#include "r8a7795-es1.dtsi" +#include "r8a7795.dtsi" #include <dt-bindings/gpio/gpio.h> / { - model = "Renesas Salvator-X board based on r8a7795 ES1.x"; + model = "Renesas Salvator-X board based on r8a7795 ES2.0+"; compatible = "renesas,salvator-x", "renesas,r8a7795"; aliases { -- 2.7.4 ^ permalink raw reply related [flat|nested] 37+ messages in thread
* Re: [PATCH/RFC v2 0/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0 2017-03-24 13:37 ` Geert Uytterhoeven (?) @ 2017-03-30 10:48 ` Sjoerd Simons -1 siblings, 0 replies; 37+ messages in thread From: Sjoerd Simons @ 2017-03-30 10:48 UTC (permalink / raw) To: Geert Uytterhoeven, Simon Horman, Magnus Damm Cc: Yoshihiro Shimoda, Kuninori Morimoto, Laurent Pinchart, Wolfram Sang, Rob Herring, Mark Rutland, linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Fri, 2017-03-24 at 14:37 +0100, Geert Uytterhoeven wrote: > Hi all, > > This patch series adds preliminary support for Renesas Salvator-X > development boards equipped with revision ES2.0 of the R-Car H3 Soc. > > - Patch 1 adds support for the R-Car H3 ES2.0 Soc, > While this patch is safe as-is, as it doesn't affect any existing > setups, it's probably a bit premature to apply it. > - Patch 2 adds support for Salvator-X boards with R-Car H3 ES2.0. > This patch does affect existing development setups, as it changes > the > name of the DTB for Salvator-X boards equipped with ES1.x SoCs. > Given most developers have access to ES1.x only, this patch must > not be > applied yet. Would it make more sense to add a new r8a7795-es2.dtsi and keep the current dtsi for es1? Having to load different device-trees based on which kernel is used would be rather nasty. -- Sjoerd Simons Collabora Ltd. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH/RFC v2 0/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0 @ 2017-03-30 10:48 ` Sjoerd Simons 0 siblings, 0 replies; 37+ messages in thread From: Sjoerd Simons @ 2017-03-30 10:48 UTC (permalink / raw) To: linux-arm-kernel On Fri, 2017-03-24 at 14:37 +0100, Geert Uytterhoeven wrote: > Hi all, > > This patch series adds preliminary support for Renesas Salvator-X > development boards equipped with revision ES2.0 of the R-Car H3 Soc. > > ? - Patch 1 adds support for the R-Car H3 ES2.0 Soc, > ????While this patch is safe as-is, as it doesn't affect any existing > ????setups, it's probably a bit premature to apply it. > ? - Patch 2 adds support for Salvator-X boards with R-Car H3 ES2.0. > ????This patch does affect existing development setups, as it changes > the > ????name of the DTB for Salvator-X boards equipped with ES1.x SoCs. > ????Given most developers have access to ES1.x only, this patch must > not be > ????applied yet. Would it make more sense to add a new r8a7795-es2.dtsi and keep the current dtsi for es1? Having to load different device-trees based on which kernel is used would be rather nasty. -- Sjoerd Simons Collabora Ltd. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH/RFC v2 0/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0 @ 2017-03-30 10:48 ` Sjoerd Simons 0 siblings, 0 replies; 37+ messages in thread From: Sjoerd Simons @ 2017-03-30 10:48 UTC (permalink / raw) To: Geert Uytterhoeven, Simon Horman, Magnus Damm Cc: Yoshihiro Shimoda, Kuninori Morimoto, Laurent Pinchart, Wolfram Sang, Rob Herring, Mark Rutland, linux-renesas-soc, devicetree, linux-arm-kernel On Fri, 2017-03-24 at 14:37 +0100, Geert Uytterhoeven wrote: > Hi all, > > This patch series adds preliminary support for Renesas Salvator-X > development boards equipped with revision ES2.0 of the R-Car H3 Soc. > > - Patch 1 adds support for the R-Car H3 ES2.0 Soc, > While this patch is safe as-is, as it doesn't affect any existing > setups, it's probably a bit premature to apply it. > - Patch 2 adds support for Salvator-X boards with R-Car H3 ES2.0. > This patch does affect existing development setups, as it changes > the > name of the DTB for Salvator-X boards equipped with ES1.x SoCs. > Given most developers have access to ES1.x only, this patch must > not be > applied yet. Would it make more sense to add a new r8a7795-es2.dtsi and keep the current dtsi for es1? Having to load different device-trees based on which kernel is used would be rather nasty. -- Sjoerd Simons Collabora Ltd. ^ permalink raw reply [flat|nested] 37+ messages in thread
[parent not found: <1490870898.3471.3.camel-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>]
* Re: [PATCH/RFC v2 0/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0 2017-03-30 10:48 ` Sjoerd Simons (?) @ 2017-03-30 11:13 ` Geert Uytterhoeven -1 siblings, 0 replies; 37+ messages in thread From: Geert Uytterhoeven @ 2017-03-30 11:13 UTC (permalink / raw) To: Sjoerd Simons Cc: Geert Uytterhoeven, Simon Horman, Magnus Damm, Yoshihiro Shimoda, Kuninori Morimoto, Laurent Pinchart, Wolfram Sang, Rob Herring, Mark Rutland, Linux-Renesas, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r Hi Sjoerd, On Thu, Mar 30, 2017 at 12:48 PM, Sjoerd Simons <sjoerd.simons-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org> wrote: > On Fri, 2017-03-24 at 14:37 +0100, Geert Uytterhoeven wrote: >> This patch series adds preliminary support for Renesas Salvator-X >> development boards equipped with revision ES2.0 of the R-Car H3 Soc. >> >> - Patch 1 adds support for the R-Car H3 ES2.0 Soc, >> While this patch is safe as-is, as it doesn't affect any existing >> setups, it's probably a bit premature to apply it. >> - Patch 2 adds support for Salvator-X boards with R-Car H3 ES2.0. >> This patch does affect existing development setups, as it changes >> the >> name of the DTB for Salvator-X boards equipped with ES1.x SoCs. >> Given most developers have access to ES1.x only, this patch must >> not be >> applied yet. > > Would it make more sense to add a new r8a7795-es2.dtsi and keep the > current dtsi for es1? Having to load different device-trees based on > which kernel is used would be rather nasty. We definitely considered that option. However, we concluded that in the end, we want to mainly support production SoCs. Hence the default files should represent the production version. Using a preproduction SoC can be considered a special case, and thus needs a file with a special esX ID in its name. We do realize this can cause some inconveniences during the transition period, when most developers don't have access to ES2.0 SoCs yet, or have mixed environments of ES1.x and ES2.0. Of course you can keep on using the current DTB (binary) on your H3 ES1.x boards, as long as you don't need to use devices not yet described in that DTB. Thanks! Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH/RFC v2 0/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0 @ 2017-03-30 11:13 ` Geert Uytterhoeven 0 siblings, 0 replies; 37+ messages in thread From: Geert Uytterhoeven @ 2017-03-30 11:13 UTC (permalink / raw) To: linux-arm-kernel Hi Sjoerd, On Thu, Mar 30, 2017 at 12:48 PM, Sjoerd Simons <sjoerd.simons@collabora.co.uk> wrote: > On Fri, 2017-03-24 at 14:37 +0100, Geert Uytterhoeven wrote: >> This patch series adds preliminary support for Renesas Salvator-X >> development boards equipped with revision ES2.0 of the R-Car H3 Soc. >> >> - Patch 1 adds support for the R-Car H3 ES2.0 Soc, >> While this patch is safe as-is, as it doesn't affect any existing >> setups, it's probably a bit premature to apply it. >> - Patch 2 adds support for Salvator-X boards with R-Car H3 ES2.0. >> This patch does affect existing development setups, as it changes >> the >> name of the DTB for Salvator-X boards equipped with ES1.x SoCs. >> Given most developers have access to ES1.x only, this patch must >> not be >> applied yet. > > Would it make more sense to add a new r8a7795-es2.dtsi and keep the > current dtsi for es1? Having to load different device-trees based on > which kernel is used would be rather nasty. We definitely considered that option. However, we concluded that in the end, we want to mainly support production SoCs. Hence the default files should represent the production version. Using a preproduction SoC can be considered a special case, and thus needs a file with a special esX ID in its name. We do realize this can cause some inconveniences during the transition period, when most developers don't have access to ES2.0 SoCs yet, or have mixed environments of ES1.x and ES2.0. Of course you can keep on using the current DTB (binary) on your H3 ES1.x boards, as long as you don't need to use devices not yet described in that DTB. Thanks! Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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] 37+ messages in thread
* Re: [PATCH/RFC v2 0/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0 @ 2017-03-30 11:13 ` Geert Uytterhoeven 0 siblings, 0 replies; 37+ messages in thread From: Geert Uytterhoeven @ 2017-03-30 11:13 UTC (permalink / raw) To: Sjoerd Simons Cc: Geert Uytterhoeven, Simon Horman, Magnus Damm, Yoshihiro Shimoda, Kuninori Morimoto, Laurent Pinchart, Wolfram Sang, Rob Herring, Mark Rutland, Linux-Renesas, devicetree, linux-arm-kernel Hi Sjoerd, On Thu, Mar 30, 2017 at 12:48 PM, Sjoerd Simons <sjoerd.simons@collabora.co.uk> wrote: > On Fri, 2017-03-24 at 14:37 +0100, Geert Uytterhoeven wrote: >> This patch series adds preliminary support for Renesas Salvator-X >> development boards equipped with revision ES2.0 of the R-Car H3 Soc. >> >> - Patch 1 adds support for the R-Car H3 ES2.0 Soc, >> While this patch is safe as-is, as it doesn't affect any existing >> setups, it's probably a bit premature to apply it. >> - Patch 2 adds support for Salvator-X boards with R-Car H3 ES2.0. >> This patch does affect existing development setups, as it changes >> the >> name of the DTB for Salvator-X boards equipped with ES1.x SoCs. >> Given most developers have access to ES1.x only, this patch must >> not be >> applied yet. > > Would it make more sense to add a new r8a7795-es2.dtsi and keep the > current dtsi for es1? Having to load different device-trees based on > which kernel is used would be rather nasty. We definitely considered that option. However, we concluded that in the end, we want to mainly support production SoCs. Hence the default files should represent the production version. Using a preproduction SoC can be considered a special case, and thus needs a file with a special esX ID in its name. We do realize this can cause some inconveniences during the transition period, when most developers don't have access to ES2.0 SoCs yet, or have mixed environments of ES1.x and ES2.0. Of course you can keep on using the current DTB (binary) on your H3 ES1.x boards, as long as you don't need to use devices not yet described in that DTB. Thanks! 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] 37+ messages in thread
* Re: [PATCH/RFC v2 0/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0 2017-03-30 11:13 ` Geert Uytterhoeven @ 2017-03-30 11:50 ` Sjoerd Simons -1 siblings, 0 replies; 37+ messages in thread From: Sjoerd Simons @ 2017-03-30 11:50 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Geert Uytterhoeven, Simon Horman, Magnus Damm, Yoshihiro Shimoda, Kuninori Morimoto, Laurent Pinchart, Wolfram Sang, Rob Herring, Mark Rutland, Linux-Renesas, devicetree, linux-arm-kernel, Daniel Stone, Kevin Hilman On Thu, 2017-03-30 at 13:13 +0200, Geert Uytterhoeven wrote: > Hi Sjoerd, > > On Thu, Mar 30, 2017 at 12:48 PM, Sjoerd Simons > <sjoerd.simons@collabora.co.uk> wrote: > > On Fri, 2017-03-24 at 14:37 +0100, Geert Uytterhoeven wrote: > > > This patch series adds preliminary support for Renesas Salvator-X > > > development boards equipped with revision ES2.0 of the R-Car H3 > > > Soc. > > > > > > - Patch 1 adds support for the R-Car H3 ES2.0 Soc, > > > While this patch is safe as-is, as it doesn't affect any > > > existing > > > setups, it's probably a bit premature to apply it. > > > - Patch 2 adds support for Salvator-X boards with R-Car H3 > > > ES2.0. > > > This patch does affect existing development setups, as it > > > changes > > > the > > > name of the DTB for Salvator-X boards equipped with ES1.x > > > SoCs. > > > Given most developers have access to ES1.x only, this patch > > > must > > > not be > > > applied yet. > > > > Would it make more sense to add a new r8a7795-es2.dtsi and keep the > > current dtsi for es1? Having to load different device-trees based > > on > > which kernel is used would be rather nasty. > > We definitely considered that option. > However, we concluded that in the end, we want to mainly support > production > SoCs. Hence the default files should represent the production > version. > Using a preproduction SoC can be considered a special case, and thus > needs > a file with a special esX ID in its name. The problem is that even though they are pre-production, these are out there and in active use, e.g. kernelci is at least doing automated testing on one of those in Kevins lab and should be an additional soonish in the Collabora lab. And for developers it'll be extra fun if halfway through a bisect the dts name changes.. Having a es2 in your dtb name might be a bit quirky, but it's really just a name without other meaning :). > We do realize this can cause some inconveniences during the > transition period, > when most developers don't have access to ES2.0 SoCs yet, or have > mixed > environments of ES1.x and ES2.0. Heh yeah, i'd expect we'd have a mixed environment for quite a while given these boards are a bit too expensive to just throw in the trash.. > Of course you can keep on using the current DTB (binary) on your H3 > ES1.x > boards, as long as you don't need to use devices not yet described in > that DTB. > > Thanks! > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linu > x-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 -- Sjoerd Simons Collabora Ltd. ^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH/RFC v2 0/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0 @ 2017-03-30 11:50 ` Sjoerd Simons 0 siblings, 0 replies; 37+ messages in thread From: Sjoerd Simons @ 2017-03-30 11:50 UTC (permalink / raw) To: linux-arm-kernel On Thu, 2017-03-30 at 13:13 +0200, Geert Uytterhoeven wrote: > Hi Sjoerd, > > On Thu, Mar 30, 2017 at 12:48 PM, Sjoerd Simons > <sjoerd.simons@collabora.co.uk> wrote: > > On Fri, 2017-03-24 at 14:37 +0100, Geert Uytterhoeven wrote: > > > This patch series adds preliminary support for Renesas Salvator-X > > > development boards equipped with revision ES2.0 of the R-Car H3 > > > Soc. > > > > > > ? - Patch 1 adds support for the R-Car H3 ES2.0 Soc, > > > ????While this patch is safe as-is, as it doesn't affect any > > > existing > > > ????setups, it's probably a bit premature to apply it. > > > ? - Patch 2 adds support for Salvator-X boards with R-Car H3 > > > ES2.0. > > > ????This patch does affect existing development setups, as it > > > changes > > > the > > > ????name of the DTB for Salvator-X boards equipped with ES1.x > > > SoCs. > > > ????Given most developers have access to ES1.x only, this patch > > > must > > > not be > > > ????applied yet. > > > > Would it make more sense to add a new r8a7795-es2.dtsi and keep the > > current dtsi for es1? Having to load different device-trees based > > on > > which kernel is used would be rather nasty. > > We definitely considered that option. > However, we concluded that in the end, we want to mainly support > production > SoCs.??Hence the default files should represent the production > version. > Using a preproduction SoC can be considered a special case, and thus > needs > a file with a special esX ID in its name. The problem is that even though they are pre-production, these are out there and in active use, e.g. kernelci is at least doing automated testing on one of those in Kevins lab and should be an additional soonish in the Collabora lab.? And for developers it'll be extra fun if halfway through a bisect the dts name changes.. Having a es2 in your dtb name might be a bit quirky, but it's really just a name without other meaning :). > We do realize this can cause some inconveniences during the > transition period, > when most developers don't have access to ES2.0 SoCs yet, or have > mixed > environments of ES1.x and ES2.0. Heh yeah, i'd expect we'd have a mixed environment for quite a while given these boards are a bit too expensive to just throw in the trash.. > Of course you can keep on using the current DTB (binary) on your H3 > ES1.x > boards, as long as you don't need to use devices not yet described in > that DTB. > > Thanks! > > Gr{oetje,eeting}s, > > ????????????????????????Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linu > x-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 -- Sjoerd Simons Collabora Ltd. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH/RFC v2 0/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0 2017-03-30 11:50 ` Sjoerd Simons @ 2017-03-30 12:08 ` Geert Uytterhoeven -1 siblings, 0 replies; 37+ messages in thread From: Geert Uytterhoeven @ 2017-03-30 12:08 UTC (permalink / raw) To: Sjoerd Simons Cc: Geert Uytterhoeven, Simon Horman, Magnus Damm, Yoshihiro Shimoda, Kuninori Morimoto, Laurent Pinchart, Wolfram Sang, Rob Herring, Mark Rutland, Linux-Renesas, devicetree, linux-arm-kernel, Daniel Stone, Kevin Hilman Hi Sjoerd, On Thu, Mar 30, 2017 at 1:50 PM, Sjoerd Simons <sjoerd.simons@collabora.co.uk> wrote: > On Thu, 2017-03-30 at 13:13 +0200, Geert Uytterhoeven wrote: >> On Thu, Mar 30, 2017 at 12:48 PM, Sjoerd Simons >> <sjoerd.simons@collabora.co.uk> wrote: >> > On Fri, 2017-03-24 at 14:37 +0100, Geert Uytterhoeven wrote: >> > > This patch series adds preliminary support for Renesas Salvator-X >> > > development boards equipped with revision ES2.0 of the R-Car H3 >> > > Soc. >> > > >> > > - Patch 1 adds support for the R-Car H3 ES2.0 Soc, >> > > While this patch is safe as-is, as it doesn't affect any >> > > existing >> > > setups, it's probably a bit premature to apply it. >> > > - Patch 2 adds support for Salvator-X boards with R-Car H3 >> > > ES2.0. >> > > This patch does affect existing development setups, as it >> > > changes >> > > the >> > > name of the DTB for Salvator-X boards equipped with ES1.x >> > > SoCs. >> > > Given most developers have access to ES1.x only, this patch >> > > must >> > > not be >> > > applied yet. >> > >> > Would it make more sense to add a new r8a7795-es2.dtsi and keep the >> > current dtsi for es1? Having to load different device-trees based >> > on >> > which kernel is used would be rather nasty. >> >> We definitely considered that option. >> However, we concluded that in the end, we want to mainly support >> production >> SoCs. Hence the default files should represent the production >> version. >> Using a preproduction SoC can be considered a special case, and thus >> needs >> a file with a special esX ID in its name. > > The problem is that even though they are pre-production, these are out > there and in active use, e.g. kernelci is at least doing automated > testing on one of those in Kevins lab and should be an additional > soonish in the Collabora lab. > > And for developers it'll be extra fun if halfway through a bisect the > dts name changes.. > > Having a es2 in your dtb name might be a bit quirky, but it's really > just a name without other meaning :). > >> We do realize this can cause some inconveniences during the >> transition period, >> when most developers don't have access to ES2.0 SoCs yet, or have >> mixed >> environments of ES1.x and ES2.0. > > Heh yeah, i'd expect we'd have a mixed environment for quite a while > given these boards are a bit too expensive to just throw in the trash.. > >> Of course you can keep on using the current DTB (binary) on your H3 >> ES1.x >> boards, as long as you don't need to use devices not yet described in >> that DTB. We can keep on discussing this for a while, this is definitely v4.13+ material. 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] 37+ messages in thread
* [PATCH/RFC v2 0/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0 @ 2017-03-30 12:08 ` Geert Uytterhoeven 0 siblings, 0 replies; 37+ messages in thread From: Geert Uytterhoeven @ 2017-03-30 12:08 UTC (permalink / raw) To: linux-arm-kernel Hi Sjoerd, On Thu, Mar 30, 2017 at 1:50 PM, Sjoerd Simons <sjoerd.simons@collabora.co.uk> wrote: > On Thu, 2017-03-30 at 13:13 +0200, Geert Uytterhoeven wrote: >> On Thu, Mar 30, 2017 at 12:48 PM, Sjoerd Simons >> <sjoerd.simons@collabora.co.uk> wrote: >> > On Fri, 2017-03-24 at 14:37 +0100, Geert Uytterhoeven wrote: >> > > This patch series adds preliminary support for Renesas Salvator-X >> > > development boards equipped with revision ES2.0 of the R-Car H3 >> > > Soc. >> > > >> > > - Patch 1 adds support for the R-Car H3 ES2.0 Soc, >> > > While this patch is safe as-is, as it doesn't affect any >> > > existing >> > > setups, it's probably a bit premature to apply it. >> > > - Patch 2 adds support for Salvator-X boards with R-Car H3 >> > > ES2.0. >> > > This patch does affect existing development setups, as it >> > > changes >> > > the >> > > name of the DTB for Salvator-X boards equipped with ES1.x >> > > SoCs. >> > > Given most developers have access to ES1.x only, this patch >> > > must >> > > not be >> > > applied yet. >> > >> > Would it make more sense to add a new r8a7795-es2.dtsi and keep the >> > current dtsi for es1? Having to load different device-trees based >> > on >> > which kernel is used would be rather nasty. >> >> We definitely considered that option. >> However, we concluded that in the end, we want to mainly support >> production >> SoCs. Hence the default files should represent the production >> version. >> Using a preproduction SoC can be considered a special case, and thus >> needs >> a file with a special esX ID in its name. > > The problem is that even though they are pre-production, these are out > there and in active use, e.g. kernelci is at least doing automated > testing on one of those in Kevins lab and should be an additional > soonish in the Collabora lab. > > And for developers it'll be extra fun if halfway through a bisect the > dts name changes.. > > Having a es2 in your dtb name might be a bit quirky, but it's really > just a name without other meaning :). > >> We do realize this can cause some inconveniences during the >> transition period, >> when most developers don't have access to ES2.0 SoCs yet, or have >> mixed >> environments of ES1.x and ES2.0. > > Heh yeah, i'd expect we'd have a mixed environment for quite a while > given these boards are a bit too expensive to just throw in the trash.. > >> Of course you can keep on using the current DTB (binary) on your H3 >> ES1.x >> boards, as long as you don't need to use devices not yet described in >> that DTB. We can keep on discussing this for a while, this is definitely v4.13+ material. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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] 37+ messages in thread
end of thread, other threads:[~2017-04-20 11:36 UTC | newest] Thread overview: 37+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-03-24 13:37 [PATCH/RFC v2 0/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0 Geert Uytterhoeven 2017-03-24 13:37 ` Geert Uytterhoeven [not found] ` <1490362665-4422-1-git-send-email-geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org> 2017-03-24 13:37 ` [PATCH/RFC v2 1/2] " Geert Uytterhoeven 2017-03-24 13:37 ` Geert Uytterhoeven 2017-03-27 8:48 ` Laurent Pinchart 2017-03-27 8:48 ` Laurent Pinchart 2017-03-29 8:13 ` Simon Horman 2017-03-29 8:13 ` Simon Horman 2017-03-29 8:31 ` Geert Uytterhoeven 2017-03-29 8:31 ` Geert Uytterhoeven 2017-03-29 8:45 ` Simon Horman 2017-03-29 8:45 ` Simon Horman 2017-04-20 9:36 ` Geert Uytterhoeven 2017-04-20 9:36 ` Geert Uytterhoeven 2017-04-20 10:42 ` Laurent Pinchart 2017-04-20 10:42 ` Laurent Pinchart 2017-04-20 10:55 ` Geert Uytterhoeven 2017-04-20 10:55 ` Geert Uytterhoeven 2017-04-20 10:55 ` Geert Uytterhoeven [not found] ` <CAMuHMdWmvhZjxKfEdGJ3d_w0d2s2kK+8iW1tsEM584qZc+dVEQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2017-04-20 11:24 ` Laurent Pinchart 2017-04-20 11:24 ` Laurent Pinchart 2017-04-20 11:24 ` Laurent Pinchart 2017-04-20 11:36 ` Geert Uytterhoeven 2017-04-20 11:36 ` Geert Uytterhoeven 2017-03-24 13:37 ` [PATCH/RFC v2 2/2] arm64: dts: r8a7795: salvator-x: " Geert Uytterhoeven 2017-03-24 13:37 ` Geert Uytterhoeven 2017-03-24 13:37 ` Geert Uytterhoeven 2017-03-30 10:48 ` [PATCH/RFC v2 0/2] arm64: dts: r8a7795: " Sjoerd Simons 2017-03-30 10:48 ` Sjoerd Simons 2017-03-30 10:48 ` Sjoerd Simons [not found] ` <1490870898.3471.3.camel-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org> 2017-03-30 11:13 ` Geert Uytterhoeven 2017-03-30 11:13 ` Geert Uytterhoeven 2017-03-30 11:13 ` Geert Uytterhoeven 2017-03-30 11:50 ` Sjoerd Simons 2017-03-30 11:50 ` Sjoerd Simons 2017-03-30 12:08 ` Geert Uytterhoeven 2017-03-30 12:08 ` Geert Uytterhoeven
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.