| Message ID | 20180914091046.483-1-laurent.pinchart+renesas@ideasonboard.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | R-Car D3/E3 display support (with LVDS PLL) | expand |
Hi Simon, On Monday, 17 September 2018 11:14:20 EEST Simon Horman wrote: > On Mon, Sep 17, 2018 at 09:50:55AM +0200, Simon Horman wrote: > > On Fri, Sep 14, 2018 at 12:10:43PM +0300, Laurent Pinchart wrote: > > > The R8A77990 (E3) platform has one RGB output and two LVDS outputs > > > connected to the DU. Add the DT nodes for the DU, LVDS encoders and > > > supporting VSP and FCP. > > > > > > Signed-off-by: Laurent Pinchart > > > <laurent.pinchart+renesas@ideasonboard.com> > > > Tested-by: Jacopo Mondi <jacopo+renesas@jmondi.org> > > > --- > > > > > > arch/arm64/boot/dts/renesas/r8a77990.dtsi | 167 +++++++++++++++++++++++ > > > 1 file changed, 167 insertions(+) > > > > > > diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi > > > b/arch/arm64/boot/dts/renesas/r8a77990.dtsi index > > > abb14af76c0e..600074ca3ee5 100644 > > > --- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi > > > +++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi > > > @@ -537,6 +537,173 @@ > > > > > > resets = <&cpg 408>; > > > > > > }; > > > > These nodes should be placed after the gic to preserve the sorting > > of nodes by bus address and then IP block. > > > > > + vspb0: vsp@fe960000 { > > > + compatible = "renesas,vsp2"; > > > + reg = <0 0xfe960000 0 0x8000>; > > > + interrupts = <GIC_SPI 266 IRQ_TYPE_LEVEL_HIGH>; > > > + clocks = <&cpg CPG_MOD 626>; > > > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; > > > + resets = <&cpg 626>; > > > + renesas,fcp = <&fcpvb0>; > > > + }; > > > + > > > + fcpvb0: fcp@fe96f000 { > > > + compatible = "renesas,fcpv"; > > > + reg = <0 0xfe96f000 0 0x200>; > > > + clocks = <&cpg CPG_MOD 607>; > > > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; > > > + resets = <&cpg 607>; > > > + iommus = <&ipmmu_vp0 5>; > > > + }; > > > + > > > + vspi0: vsp@fe9a0000 { > > > + compatible = "renesas,vsp2"; > > > + reg = <0 0xfe9a0000 0 0x8000>; > > > + interrupts = <GIC_SPI 444 IRQ_TYPE_LEVEL_HIGH>; > > > + clocks = <&cpg CPG_MOD 622>; > > > > R-Car Series, 3rd Generation, v1.00, Table Table 8A.21 indicates > > that this clock should be <&cpg CPG_MOD 631>. The clock above is > > (according to my reading of the documentation) correctly > > used for vspd1 below. > > > > > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; > > > + resets = <&cpg 631>; > > > + renesas,fcp = <&fcpvi0>; > > > + }; > > > + > > > + fcpvi0: fcp@fe9af000 { > > > + compatible = "renesas,fcpv"; > > > + reg = <0 0xfe9af000 0 0x200>; > > > + clocks = <&cpg CPG_MOD 611>; > > > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; > > > + resets = <&cpg 611>; > > > + iommus = <&ipmmu_vp0 8>; > > > + }; > > > + > > > + vspd0: vsp@fea20000 { > > > + compatible = "renesas,vsp2"; > > > + reg = <0 0xfea20000 0 0x7000>; > > > + interrupts = <GIC_SPI 466 IRQ_TYPE_LEVEL_HIGH>; > > > + clocks = <&cpg CPG_MOD 623>; > > > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; > > > + resets = <&cpg 623>; > > > + renesas,fcp = <&fcpvd0>; > > > + }; > > > + > > > + fcpvd0: fcp@fea27000 { > > > + compatible = "renesas,fcpv"; > > > + reg = <0 0xfea27000 0 0x200>; > > > + clocks = <&cpg CPG_MOD 603>; > > > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; > > > + resets = <&cpg 603>; > > > + iommus = <&ipmmu_vi0 8>; > > > + }; > > > + > > > + vspd1: vsp@fea28000 { > > > + compatible = "renesas,vsp2"; > > > + reg = <0 0xfea28000 0 0x7000>; > > > + interrupts = <GIC_SPI 467 IRQ_TYPE_LEVEL_HIGH>; > > > + clocks = <&cpg CPG_MOD 622>; > > > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; > > > + resets = <&cpg 622>; > > > + renesas,fcp = <&fcpvd1>; > > > + }; > > > + > > > + fcpvd1: fcp@fea2f000 { > > > + compatible = "renesas,fcpv"; > > > + reg = <0 0xfea2f000 0 0x200>; > > > + clocks = <&cpg CPG_MOD 602>; > > > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; > > > + resets = <&cpg 602>; > > > + iommus = <&ipmmu_vi0 9>; > > > + }; > > > + > > > + du: display@feb00000 { > > > + compatible = "renesas,du-r8a77990"; > > > + reg = <0 0xfeb00000 0 0x80000>; > > > + interrupts = <GIC_SPI 256 IRQ_TYPE_LEVEL_HIGH>, > > > + <GIC_SPI 268 IRQ_TYPE_LEVEL_HIGH>; > > > + clocks = <&cpg CPG_MOD 724>, > > > + <&cpg CPG_MOD 723>; > > > + clock-names = "du.0", "du.1"; > > > + vsps = <&vspd0 0 &vspd1 0>; > > > + status = "disabled"; > > > + > > > + ports { > > > + #address-cells = <1>; > > > + #size-cells = <0>; > > > + > > > + port@0 { > > > + reg = <0>; > > > + du_out_rgb: endpoint { > > > + }; > > > + }; > > > + > > > + port@1 { > > > + reg = <1>; > > > + du_out_lvds0: endpoint { > > > + remote-endpoint = <&lvds0_in>; > > > + }; > > > + }; > > > + > > > + port@2 { > > > + reg = <2>; > > > + du_out_lvds1: endpoint { > > > + remote-endpoint = <&lvds1_in>; > > > + }; > > > + }; > > > + }; > > > + }; > > > + > > > + lvds0: lvds-encoder@feb90000 { > > > + compatible = "renesas,r8a77990-lvds"; > > > + reg = <0 0xfeb90000 0 0x20>; > > > + clocks = <&cpg CPG_MOD 727>; > > > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; > > > + resets = <&cpg 727>; > > > + status = "disabled"; > > > + > > > + ports { > > > + #address-cells = <1>; > > > + #size-cells = <0>; > > > + > > > + port@0 { > > > + reg = <0>; > > > + lvds0_in: endpoint { > > > + remote-endpoint = <&du_out_lvds0>; > > > + }; > > > + }; > > > + > > > + port@1 { > > > + reg = <1>; > > > + lvds0_out: endpoint { > > > + }; > > > + }; > > > + }; > > > + }; > > > + > > > + lvds1: lvds-encoder@feb90100 { > > > + compatible = "renesas,r8a77990-lvds"; > > > + reg = <0 0xfeb90100 0 0x20>; > > > + clocks = <&cpg CPG_MOD 727>; > > > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; > > > + resets = <&cpg 726>; > > Also, is the missmatch between the index for the clock and reset > intentional? It is. According to the datasheet, the two LVDS encoders have different module stop bits, but share the same reset (lovely hardware design, it will be fun to support that in the driver :-S). > > > + status = "disabled"; > > > + > > > + ports { > > > + #address-cells = <1>; > > > + #size-cells = <0>; > > > + > > > + port@0 { > > > + reg = <0>; > > > + lvds1_in: endpoint { > > > + remote-endpoint = <&du_out_lvds1>; > > > + }; > > > + }; > > > + > > > + port@1 { > > > + reg = <1>; > > > + lvds1_out: endpoint { > > > + }; > > > + }; > > > + }; > > > + }; > > > + > > > prr: chipid@fff00044 { > > > compatible = "renesas,prr"; > > > reg = <0 0xfff00044 0 4>;
Hi Simon, On Monday, 17 September 2018 11:47:15 EEST Laurent Pinchart wrote: > On Monday, 17 September 2018 11:14:20 EEST Simon Horman wrote: > > On Mon, Sep 17, 2018 at 09:50:55AM +0200, Simon Horman wrote: > > > On Fri, Sep 14, 2018 at 12:10:43PM +0300, Laurent Pinchart wrote: > > > > The R8A77990 (E3) platform has one RGB output and two LVDS outputs > > > > connected to the DU. Add the DT nodes for the DU, LVDS encoders and > > > > supporting VSP and FCP. > > > > > > > > Signed-off-by: Laurent Pinchart > > > > <laurent.pinchart+renesas@ideasonboard.com> > > > > Tested-by: Jacopo Mondi <jacopo+renesas@jmondi.org> > > > > --- > > > > > > > > arch/arm64/boot/dts/renesas/r8a77990.dtsi | 167 > > > > +++++++++++++++++++++++ > > > > 1 file changed, 167 insertions(+) > > > > > > > > diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi > > > > b/arch/arm64/boot/dts/renesas/r8a77990.dtsi index > > > > abb14af76c0e..600074ca3ee5 100644 > > > > --- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi > > > > +++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi > > > > @@ -537,6 +537,173 @@ > > > > > > > > resets = <&cpg 408>; > > > > > > > > }; > > > > > > These nodes should be placed after the gic to preserve the sorting > > > of nodes by bus address and then IP block. > > > > > > > + vspb0: vsp@fe960000 { > > > > + compatible = "renesas,vsp2"; > > > > + reg = <0 0xfe960000 0 0x8000>; > > > > + interrupts = <GIC_SPI 266 IRQ_TYPE_LEVEL_HIGH>; > > > > + clocks = <&cpg CPG_MOD 626>; > > > > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; > > > > + resets = <&cpg 626>; > > > > + renesas,fcp = <&fcpvb0>; > > > > + }; > > > > + > > > > + fcpvb0: fcp@fe96f000 { > > > > + compatible = "renesas,fcpv"; > > > > + reg = <0 0xfe96f000 0 0x200>; > > > > + clocks = <&cpg CPG_MOD 607>; > > > > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; > > > > + resets = <&cpg 607>; > > > > + iommus = <&ipmmu_vp0 5>; > > > > + }; > > > > + > > > > + vspi0: vsp@fe9a0000 { > > > > + compatible = "renesas,vsp2"; > > > > + reg = <0 0xfe9a0000 0 0x8000>; > > > > + interrupts = <GIC_SPI 444 IRQ_TYPE_LEVEL_HIGH>; > > > > + clocks = <&cpg CPG_MOD 622>; > > > > > > R-Car Series, 3rd Generation, v1.00, Table Table 8A.21 indicates > > > that this clock should be <&cpg CPG_MOD 631>. The clock above is > > > (according to my reading of the documentation) correctly > > > used for vspd1 below. > > > > > > > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; > > > > + resets = <&cpg 631>; > > > > + renesas,fcp = <&fcpvi0>; > > > > + }; > > > > + > > > > + fcpvi0: fcp@fe9af000 { > > > > + compatible = "renesas,fcpv"; > > > > + reg = <0 0xfe9af000 0 0x200>; > > > > + clocks = <&cpg CPG_MOD 611>; > > > > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; > > > > + resets = <&cpg 611>; > > > > + iommus = <&ipmmu_vp0 8>; > > > > + }; > > > > + > > > > + vspd0: vsp@fea20000 { > > > > + compatible = "renesas,vsp2"; > > > > + reg = <0 0xfea20000 0 0x7000>; > > > > + interrupts = <GIC_SPI 466 IRQ_TYPE_LEVEL_HIGH>; > > > > + clocks = <&cpg CPG_MOD 623>; > > > > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; > > > > + resets = <&cpg 623>; > > > > + renesas,fcp = <&fcpvd0>; > > > > + }; > > > > + > > > > + fcpvd0: fcp@fea27000 { > > > > + compatible = "renesas,fcpv"; > > > > + reg = <0 0xfea27000 0 0x200>; > > > > + clocks = <&cpg CPG_MOD 603>; > > > > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; > > > > + resets = <&cpg 603>; > > > > + iommus = <&ipmmu_vi0 8>; > > > > + }; > > > > + > > > > + vspd1: vsp@fea28000 { > > > > + compatible = "renesas,vsp2"; > > > > + reg = <0 0xfea28000 0 0x7000>; > > > > + interrupts = <GIC_SPI 467 IRQ_TYPE_LEVEL_HIGH>; > > > > + clocks = <&cpg CPG_MOD 622>; > > > > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; > > > > + resets = <&cpg 622>; > > > > + renesas,fcp = <&fcpvd1>; > > > > + }; > > > > + > > > > + fcpvd1: fcp@fea2f000 { > > > > + compatible = "renesas,fcpv"; > > > > + reg = <0 0xfea2f000 0 0x200>; > > > > + clocks = <&cpg CPG_MOD 602>; > > > > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; > > > > + resets = <&cpg 602>; > > > > + iommus = <&ipmmu_vi0 9>; > > > > + }; > > > > + > > > > + du: display@feb00000 { > > > > + compatible = "renesas,du-r8a77990"; > > > > + reg = <0 0xfeb00000 0 0x80000>; > > > > + interrupts = <GIC_SPI 256 IRQ_TYPE_LEVEL_HIGH>, > > > > + <GIC_SPI 268 IRQ_TYPE_LEVEL_HIGH>; > > > > + clocks = <&cpg CPG_MOD 724>, > > > > + <&cpg CPG_MOD 723>; > > > > + clock-names = "du.0", "du.1"; > > > > + vsps = <&vspd0 0 &vspd1 0>; > > > > + status = "disabled"; > > > > + > > > > + ports { > > > > + #address-cells = <1>; > > > > + #size-cells = <0>; > > > > + > > > > + port@0 { > > > > + reg = <0>; > > > > + du_out_rgb: endpoint { > > > > + }; > > > > + }; > > > > + > > > > + port@1 { > > > > + reg = <1>; > > > > + du_out_lvds0: endpoint { > > > > + remote-endpoint = <&lvds0_in>; > > > > + }; > > > > + }; > > > > + > > > > + port@2 { > > > > + reg = <2>; > > > > + du_out_lvds1: endpoint { > > > > + remote-endpoint = <&lvds1_in>; > > > > + }; > > > > + }; > > > > + }; > > > > + }; > > > > + > > > > + lvds0: lvds-encoder@feb90000 { > > > > + compatible = "renesas,r8a77990-lvds"; > > > > + reg = <0 0xfeb90000 0 0x20>; > > > > + clocks = <&cpg CPG_MOD 727>; > > > > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; > > > > + resets = <&cpg 727>; > > > > + status = "disabled"; > > > > + > > > > + ports { > > > > + #address-cells = <1>; > > > > + #size-cells = <0>; > > > > + > > > > + port@0 { > > > > + reg = <0>; > > > > + lvds0_in: endpoint { > > > > + remote-endpoint = <&du_out_lvds0>; > > > > + }; > > > > + }; > > > > + > > > > + port@1 { > > > > + reg = <1>; > > > > + lvds0_out: endpoint { > > > > + }; > > > > + }; > > > > + }; > > > > + }; > > > > + > > > > + lvds1: lvds-encoder@feb90100 { > > > > + compatible = "renesas,r8a77990-lvds"; > > > > + reg = <0 0xfeb90100 0 0x20>; > > > > + clocks = <&cpg CPG_MOD 727>; > > > > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; > > > > + resets = <&cpg 726>; > > > > Also, is the missmatch between the index for the clock and reset > > intentional? > > It is. According to the datasheet, the two LVDS encoders have different > module stop bits, but share the same reset (lovely hardware design, it will > be fun to support that in the driver :-S). Sorry, I got it wrong. it's bit 725 that is shared between the two LVDS encoders, to reset the two LVDS PLLs together. The encoders themselves still have independent reset bits. I'll fix this. > > > > + status = "disabled"; > > > > + > > > > + ports { > > > > + #address-cells = <1>; > > > > + #size-cells = <0>; > > > > + > > > > + port@0 { > > > > + reg = <0>; > > > > + lvds1_in: endpoint { > > > > + remote-endpoint = <&du_out_lvds1>; > > > > + }; > > > > + }; > > > > + > > > > + port@1 { > > > > + reg = <1>; > > > > + lvds1_out: endpoint { > > > > + }; > > > > + }; > > > > + }; > > > > + }; > > > > + > > > > prr: chipid@fff00044 { > > > > compatible = "renesas,prr"; > > > > reg = <0 0xfff00044 0 4>;
On Monday, 17 September 2018 11:54:04 EEST Laurent Pinchart wrote: > Hi Simon, > > On Monday, 17 September 2018 11:47:15 EEST Laurent Pinchart wrote: > > On Monday, 17 September 2018 11:14:20 EEST Simon Horman wrote: > > > On Mon, Sep 17, 2018 at 09:50:55AM +0200, Simon Horman wrote: > > > > On Fri, Sep 14, 2018 at 12:10:43PM +0300, Laurent Pinchart wrote: > > > > > The R8A77990 (E3) platform has one RGB output and two LVDS outputs > > > > > connected to the DU. Add the DT nodes for the DU, LVDS encoders and > > > > > supporting VSP and FCP. > > > > > > > > > > Signed-off-by: Laurent Pinchart > > > > > <laurent.pinchart+renesas@ideasonboard.com> > > > > > Tested-by: Jacopo Mondi <jacopo+renesas@jmondi.org> > > > > > --- > > > > > > > > > > arch/arm64/boot/dts/renesas/r8a77990.dtsi | 167 > > > > > +++++++++++++++++++++++ > > > > > 1 file changed, 167 insertions(+) > > > > > > > > > > diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi > > > > > b/arch/arm64/boot/dts/renesas/r8a77990.dtsi index > > > > > abb14af76c0e..600074ca3ee5 100644 > > > > > --- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi > > > > > +++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi > > > > > @@ -537,6 +537,173 @@ > > > > > > > > > > resets = <&cpg 408>; > > > > > > > > > > }; > > > > > > > > These nodes should be placed after the gic to preserve the sorting > > > > of nodes by bus address and then IP block. > > > > > > > > > + vspb0: vsp@fe960000 { > > > > > + compatible = "renesas,vsp2"; > > > > > + reg = <0 0xfe960000 0 0x8000>; > > > > > + interrupts = <GIC_SPI 266 IRQ_TYPE_LEVEL_HIGH>; > > > > > + clocks = <&cpg CPG_MOD 626>; > > > > > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; > > > > > + resets = <&cpg 626>; > > > > > + renesas,fcp = <&fcpvb0>; > > > > > + }; > > > > > + > > > > > + fcpvb0: fcp@fe96f000 { > > > > > + compatible = "renesas,fcpv"; > > > > > + reg = <0 0xfe96f000 0 0x200>; > > > > > + clocks = <&cpg CPG_MOD 607>; > > > > > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; > > > > > + resets = <&cpg 607>; > > > > > + iommus = <&ipmmu_vp0 5>; > > > > > + }; > > > > > + > > > > > + vspi0: vsp@fe9a0000 { > > > > > + compatible = "renesas,vsp2"; > > > > > + reg = <0 0xfe9a0000 0 0x8000>; > > > > > + interrupts = <GIC_SPI 444 IRQ_TYPE_LEVEL_HIGH>; > > > > > + clocks = <&cpg CPG_MOD 622>; > > > > > > > > R-Car Series, 3rd Generation, v1.00, Table Table 8A.21 indicates > > > > that this clock should be <&cpg CPG_MOD 631>. The clock above is > > > > (according to my reading of the documentation) correctly > > > > used for vspd1 below. > > > > > > > > > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; > > > > > + resets = <&cpg 631>; > > > > > + renesas,fcp = <&fcpvi0>; > > > > > + }; > > > > > + > > > > > + fcpvi0: fcp@fe9af000 { > > > > > + compatible = "renesas,fcpv"; > > > > > + reg = <0 0xfe9af000 0 0x200>; > > > > > + clocks = <&cpg CPG_MOD 611>; > > > > > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; > > > > > + resets = <&cpg 611>; > > > > > + iommus = <&ipmmu_vp0 8>; > > > > > + }; > > > > > + > > > > > + vspd0: vsp@fea20000 { > > > > > + compatible = "renesas,vsp2"; > > > > > + reg = <0 0xfea20000 0 0x7000>; > > > > > + interrupts = <GIC_SPI 466 IRQ_TYPE_LEVEL_HIGH>; > > > > > + clocks = <&cpg CPG_MOD 623>; > > > > > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; > > > > > + resets = <&cpg 623>; > > > > > + renesas,fcp = <&fcpvd0>; > > > > > + }; > > > > > + > > > > > + fcpvd0: fcp@fea27000 { > > > > > + compatible = "renesas,fcpv"; > > > > > + reg = <0 0xfea27000 0 0x200>; > > > > > + clocks = <&cpg CPG_MOD 603>; > > > > > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; > > > > > + resets = <&cpg 603>; > > > > > + iommus = <&ipmmu_vi0 8>; > > > > > + }; > > > > > + > > > > > + vspd1: vsp@fea28000 { > > > > > + compatible = "renesas,vsp2"; > > > > > + reg = <0 0xfea28000 0 0x7000>; > > > > > + interrupts = <GIC_SPI 467 IRQ_TYPE_LEVEL_HIGH>; > > > > > + clocks = <&cpg CPG_MOD 622>; > > > > > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; > > > > > + resets = <&cpg 622>; > > > > > + renesas,fcp = <&fcpvd1>; > > > > > + }; > > > > > + > > > > > + fcpvd1: fcp@fea2f000 { > > > > > + compatible = "renesas,fcpv"; > > > > > + reg = <0 0xfea2f000 0 0x200>; > > > > > + clocks = <&cpg CPG_MOD 602>; > > > > > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; > > > > > + resets = <&cpg 602>; > > > > > + iommus = <&ipmmu_vi0 9>; > > > > > + }; > > > > > + > > > > > + du: display@feb00000 { > > > > > + compatible = "renesas,du-r8a77990"; > > > > > + reg = <0 0xfeb00000 0 0x80000>; > > > > > + interrupts = <GIC_SPI 256 IRQ_TYPE_LEVEL_HIGH>, > > > > > + <GIC_SPI 268 IRQ_TYPE_LEVEL_HIGH>; > > > > > + clocks = <&cpg CPG_MOD 724>, > > > > > + <&cpg CPG_MOD 723>; > > > > > + clock-names = "du.0", "du.1"; > > > > > + vsps = <&vspd0 0 &vspd1 0>; > > > > > + status = "disabled"; > > > > > + > > > > > + ports { > > > > > + #address-cells = <1>; > > > > > + #size-cells = <0>; > > > > > + > > > > > + port@0 { > > > > > + reg = <0>; > > > > > + du_out_rgb: endpoint { > > > > > + }; > > > > > + }; > > > > > + > > > > > + port@1 { > > > > > + reg = <1>; > > > > > + du_out_lvds0: endpoint { > > > > > + remote-endpoint = <&lvds0_in>; > > > > > + }; > > > > > + }; > > > > > + > > > > > + port@2 { > > > > > + reg = <2>; > > > > > + du_out_lvds1: endpoint { > > > > > + remote-endpoint = <&lvds1_in>; > > > > > + }; > > > > > + }; > > > > > + }; > > > > > + }; > > > > > + > > > > > + lvds0: lvds-encoder@feb90000 { > > > > > + compatible = "renesas,r8a77990-lvds"; > > > > > + reg = <0 0xfeb90000 0 0x20>; > > > > > + clocks = <&cpg CPG_MOD 727>; > > > > > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; > > > > > + resets = <&cpg 727>; > > > > > + status = "disabled"; > > > > > + > > > > > + ports { > > > > > + #address-cells = <1>; > > > > > + #size-cells = <0>; > > > > > + > > > > > + port@0 { > > > > > + reg = <0>; > > > > > + lvds0_in: endpoint { > > > > > + remote-endpoint = <&du_out_lvds0>; > > > > > + }; > > > > > + }; > > > > > + > > > > > + port@1 { > > > > > + reg = <1>; > > > > > + lvds0_out: endpoint { > > > > > + }; > > > > > + }; > > > > > + }; > > > > > + }; > > > > > + > > > > > + lvds1: lvds-encoder@feb90100 { > > > > > + compatible = "renesas,r8a77990-lvds"; > > > > > + reg = <0 0xfeb90100 0 0x20>; > > > > > + clocks = <&cpg CPG_MOD 727>; > > > > > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; > > > > > + resets = <&cpg 726>; > > > > > > Also, is the missmatch between the index for the clock and reset > > > intentional? > > > > It is. According to the datasheet, the two LVDS encoders have different > > module stop bits, but share the same reset (lovely hardware design, it > > will be fun to support that in the driver :-S). > > Sorry, I got it wrong. it's bit 725 that is shared between the two LVDS > encoders, to reset the two LVDS PLLs together. The encoders themselves still > have independent reset bits. I'll fix this. And of course it's the clock you were commenting on, not the reset. *sigh* According to the datasheets the two LVDS encoders share one MSTP. Whether that's a mistake in the documentation or not I can't tell yet, as I have only tested LVDS0. > > > > > + status = "disabled"; > > > > > + > > > > > + ports { > > > > > + #address-cells = <1>; > > > > > + #size-cells = <0>; > > > > > + > > > > > + port@0 { > > > > > + reg = <0>; > > > > > + lvds1_in: endpoint { > > > > > + remote-endpoint = <&du_out_lvds1>; > > > > > + }; > > > > > + }; > > > > > + > > > > > + port@1 { > > > > > + reg = <1>; > > > > > + lvds1_out: endpoint { > > > > > + }; > > > > > + }; > > > > > + }; > > > > > + }; > > > > > + > > > > > > > > > > prr: chipid@fff00044 { > > > > > > > > > > compatible = "renesas,prr"; > > > > > reg = <0 0xfff00044 0 4>;
On Mon, Sep 17, 2018 at 11:59:32AM +0300, Laurent Pinchart wrote: > On Monday, 17 September 2018 11:54:04 EEST Laurent Pinchart wrote: > > Hi Simon, > > > > On Monday, 17 September 2018 11:47:15 EEST Laurent Pinchart wrote: > > > On Monday, 17 September 2018 11:14:20 EEST Simon Horman wrote: > > > > On Mon, Sep 17, 2018 at 09:50:55AM +0200, Simon Horman wrote: > > > > > On Fri, Sep 14, 2018 at 12:10:43PM +0300, Laurent Pinchart wrote: > > > > > > The R8A77990 (E3) platform has one RGB output and two LVDS outputs > > > > > > connected to the DU. Add the DT nodes for the DU, LVDS encoders and > > > > > > supporting VSP and FCP. > > > > > > > > > > > > Signed-off-by: Laurent Pinchart > > > > > > <laurent.pinchart+renesas@ideasonboard.com> > > > > > > Tested-by: Jacopo Mondi <jacopo+renesas@jmondi.org> > > > > > > --- > > > > > > > > > > > > arch/arm64/boot/dts/renesas/r8a77990.dtsi | 167 > > > > > > +++++++++++++++++++++++ > > > > > > 1 file changed, 167 insertions(+) > > > > > > > > > > > > diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi > > > > > > b/arch/arm64/boot/dts/renesas/r8a77990.dtsi index > > > > > > abb14af76c0e..600074ca3ee5 100644 > > > > > > --- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi > > > > > > +++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi > > > > > > @@ -537,6 +537,173 @@ > > > > > > > > > > > > resets = <&cpg 408>; > > > > > > > > > > > > }; > > > > > > > > > > These nodes should be placed after the gic to preserve the sorting > > > > > of nodes by bus address and then IP block. > > > > > > > > > > > + vspb0: vsp@fe960000 { > > > > > > + compatible = "renesas,vsp2"; > > > > > > + reg = <0 0xfe960000 0 0x8000>; > > > > > > + interrupts = <GIC_SPI 266 IRQ_TYPE_LEVEL_HIGH>; > > > > > > + clocks = <&cpg CPG_MOD 626>; > > > > > > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; > > > > > > + resets = <&cpg 626>; > > > > > > + renesas,fcp = <&fcpvb0>; > > > > > > + }; > > > > > > + > > > > > > + fcpvb0: fcp@fe96f000 { > > > > > > + compatible = "renesas,fcpv"; > > > > > > + reg = <0 0xfe96f000 0 0x200>; > > > > > > + clocks = <&cpg CPG_MOD 607>; > > > > > > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; > > > > > > + resets = <&cpg 607>; > > > > > > + iommus = <&ipmmu_vp0 5>; > > > > > > + }; > > > > > > + > > > > > > + vspi0: vsp@fe9a0000 { > > > > > > + compatible = "renesas,vsp2"; > > > > > > + reg = <0 0xfe9a0000 0 0x8000>; > > > > > > + interrupts = <GIC_SPI 444 IRQ_TYPE_LEVEL_HIGH>; > > > > > > + clocks = <&cpg CPG_MOD 622>; > > > > > > > > > > R-Car Series, 3rd Generation, v1.00, Table Table 8A.21 indicates > > > > > that this clock should be <&cpg CPG_MOD 631>. The clock above is > > > > > (according to my reading of the documentation) correctly > > > > > used for vspd1 below. > > > > > > > > > > > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; > > > > > > + resets = <&cpg 631>; > > > > > > + renesas,fcp = <&fcpvi0>; > > > > > > + }; > > > > > > + > > > > > > + fcpvi0: fcp@fe9af000 { > > > > > > + compatible = "renesas,fcpv"; > > > > > > + reg = <0 0xfe9af000 0 0x200>; > > > > > > + clocks = <&cpg CPG_MOD 611>; > > > > > > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; > > > > > > + resets = <&cpg 611>; > > > > > > + iommus = <&ipmmu_vp0 8>; > > > > > > + }; > > > > > > + > > > > > > + vspd0: vsp@fea20000 { > > > > > > + compatible = "renesas,vsp2"; > > > > > > + reg = <0 0xfea20000 0 0x7000>; > > > > > > + interrupts = <GIC_SPI 466 IRQ_TYPE_LEVEL_HIGH>; > > > > > > + clocks = <&cpg CPG_MOD 623>; > > > > > > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; > > > > > > + resets = <&cpg 623>; > > > > > > + renesas,fcp = <&fcpvd0>; > > > > > > + }; > > > > > > + > > > > > > + fcpvd0: fcp@fea27000 { > > > > > > + compatible = "renesas,fcpv"; > > > > > > + reg = <0 0xfea27000 0 0x200>; > > > > > > + clocks = <&cpg CPG_MOD 603>; > > > > > > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; > > > > > > + resets = <&cpg 603>; > > > > > > + iommus = <&ipmmu_vi0 8>; > > > > > > + }; > > > > > > + > > > > > > + vspd1: vsp@fea28000 { > > > > > > + compatible = "renesas,vsp2"; > > > > > > + reg = <0 0xfea28000 0 0x7000>; > > > > > > + interrupts = <GIC_SPI 467 IRQ_TYPE_LEVEL_HIGH>; > > > > > > + clocks = <&cpg CPG_MOD 622>; > > > > > > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; > > > > > > + resets = <&cpg 622>; > > > > > > + renesas,fcp = <&fcpvd1>; > > > > > > + }; > > > > > > + > > > > > > + fcpvd1: fcp@fea2f000 { > > > > > > + compatible = "renesas,fcpv"; > > > > > > + reg = <0 0xfea2f000 0 0x200>; > > > > > > + clocks = <&cpg CPG_MOD 602>; > > > > > > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; > > > > > > + resets = <&cpg 602>; > > > > > > + iommus = <&ipmmu_vi0 9>; > > > > > > + }; > > > > > > + > > > > > > + du: display@feb00000 { > > > > > > + compatible = "renesas,du-r8a77990"; > > > > > > + reg = <0 0xfeb00000 0 0x80000>; > > > > > > + interrupts = <GIC_SPI 256 IRQ_TYPE_LEVEL_HIGH>, > > > > > > + <GIC_SPI 268 IRQ_TYPE_LEVEL_HIGH>; > > > > > > + clocks = <&cpg CPG_MOD 724>, > > > > > > + <&cpg CPG_MOD 723>; > > > > > > + clock-names = "du.0", "du.1"; > > > > > > + vsps = <&vspd0 0 &vspd1 0>; > > > > > > + status = "disabled"; > > > > > > + > > > > > > + ports { > > > > > > + #address-cells = <1>; > > > > > > + #size-cells = <0>; > > > > > > + > > > > > > + port@0 { > > > > > > + reg = <0>; > > > > > > + du_out_rgb: endpoint { > > > > > > + }; > > > > > > + }; > > > > > > + > > > > > > + port@1 { > > > > > > + reg = <1>; > > > > > > + du_out_lvds0: endpoint { > > > > > > + remote-endpoint = <&lvds0_in>; > > > > > > + }; > > > > > > + }; > > > > > > + > > > > > > + port@2 { > > > > > > + reg = <2>; > > > > > > + du_out_lvds1: endpoint { > > > > > > + remote-endpoint = <&lvds1_in>; > > > > > > + }; > > > > > > + }; > > > > > > + }; > > > > > > + }; > > > > > > + > > > > > > + lvds0: lvds-encoder@feb90000 { > > > > > > + compatible = "renesas,r8a77990-lvds"; > > > > > > + reg = <0 0xfeb90000 0 0x20>; > > > > > > + clocks = <&cpg CPG_MOD 727>; > > > > > > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; > > > > > > + resets = <&cpg 727>; > > > > > > + status = "disabled"; > > > > > > + > > > > > > + ports { > > > > > > + #address-cells = <1>; > > > > > > + #size-cells = <0>; > > > > > > + > > > > > > + port@0 { > > > > > > + reg = <0>; > > > > > > + lvds0_in: endpoint { > > > > > > + remote-endpoint = <&du_out_lvds0>; > > > > > > + }; > > > > > > + }; > > > > > > + > > > > > > + port@1 { > > > > > > + reg = <1>; > > > > > > + lvds0_out: endpoint { > > > > > > + }; > > > > > > + }; > > > > > > + }; > > > > > > + }; > > > > > > + > > > > > > + lvds1: lvds-encoder@feb90100 { > > > > > > + compatible = "renesas,r8a77990-lvds"; > > > > > > + reg = <0 0xfeb90100 0 0x20>; > > > > > > + clocks = <&cpg CPG_MOD 727>; > > > > > > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; > > > > > > + resets = <&cpg 726>; > > > > > > > > Also, is the missmatch between the index for the clock and reset > > > > intentional? > > > > > > It is. According to the datasheet, the two LVDS encoders have different > > > module stop bits, but share the same reset (lovely hardware design, it > > > will be fun to support that in the driver :-S). > > > > Sorry, I got it wrong. it's bit 725 that is shared between the two LVDS > > encoders, to reset the two LVDS PLLs together. The encoders themselves still > > have independent reset bits. I'll fix this. > > And of course it's the clock you were commenting on, not the reset. *sigh* > > According to the datasheets the two LVDS encoders share one MSTP. Whether > that's a mistake in the documentation or not I can't tell yet, as I have only > tested LVDS0. Could we follow-up with the HW team? I'm not opposed to taking the patch with this portion as-is but it would be good to clarify this somehow. > > > > > > + status = "disabled"; > > > > > > + > > > > > > + ports { > > > > > > + #address-cells = <1>; > > > > > > + #size-cells = <0>; > > > > > > + > > > > > > + port@0 { > > > > > > + reg = <0>; > > > > > > + lvds1_in: endpoint { > > > > > > + remote-endpoint = <&du_out_lvds1>; > > > > > > + }; > > > > > > + }; > > > > > > + > > > > > > + port@1 { > > > > > > + reg = <1>; > > > > > > + lvds1_out: endpoint { > > > > > > + }; > > > > > > + }; > > > > > > + }; > > > > > > + }; > > > > > > + > > > > > > > > > > > > prr: chipid@fff00044 { > > > > > > > > > > > > compatible = "renesas,prr"; > > > > > > reg = <0 0xfff00044 0 4>; > > > -- > Regards, > > Laurent Pinchart > > >
Hi Simon, On Wednesday, 19 September 2018 11:35:07 EEST Simon Horman wrote: > On Mon, Sep 17, 2018 at 11:59:32AM +0300, Laurent Pinchart wrote: > > On Monday, 17 September 2018 11:54:04 EEST Laurent Pinchart wrote: > >> On Monday, 17 September 2018 11:47:15 EEST Laurent Pinchart wrote: > >>> On Monday, 17 September 2018 11:14:20 EEST Simon Horman wrote: > >>>> On Mon, Sep 17, 2018 at 09:50:55AM +0200, Simon Horman wrote: > >>>>> On Fri, Sep 14, 2018 at 12:10:43PM +0300, Laurent Pinchart wrote: > >>>>>> The R8A77990 (E3) platform has one RGB output and two LVDS > >>>>>> outputs connected to the DU. Add the DT nodes for the DU, LVDS > >>>>>> encoders and supporting VSP and FCP. > >>>>>> > >>>>>> Signed-off-by: Laurent Pinchart > >>>>>> <laurent.pinchart+renesas@ideasonboard.com> > >>>>>> Tested-by: Jacopo Mondi <jacopo+renesas@jmondi.org> > >>>>>> --- > >>>>>> > >>>>>> arch/arm64/boot/dts/renesas/r8a77990.dtsi | 167 ++++++++++++++++++++ > >>>>>> 1 file changed, 167 insertions(+) > >>>>>> > >>>>>> diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi > >>>>>> b/arch/arm64/boot/dts/renesas/r8a77990.dtsi index > >>>>>> abb14af76c0e..600074ca3ee5 100644 > >>>>>> --- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi > >>>>>> +++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi [snip] > >>>>>> + lvds0: lvds-encoder@feb90000 { > >>>>>> + compatible = "renesas,r8a77990-lvds"; > >>>>>> + reg = <0 0xfeb90000 0 0x20>; > >>>>>> + clocks = <&cpg CPG_MOD 727>; > >>>>>> + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; > >>>>>> + resets = <&cpg 727>; > >>>>>> + status = "disabled"; > >>>>>> + > >>>>>> + ports { > >>>>>> + #address-cells = <1>; > >>>>>> + #size-cells = <0>; > >>>>>> + > >>>>>> + port@0 { > >>>>>> + reg = <0>; > >>>>>> + lvds0_in: endpoint { > >>>>>> + remote-endpoint = <&du_out_lvds0>; > >>>>>> + }; > >>>>>> + }; > >>>>>> + > >>>>>> + port@1 { > >>>>>> + reg = <1>; > >>>>>> + lvds0_out: endpoint { > >>>>>> + }; > >>>>>> + }; > >>>>>> + }; > >>>>>> + }; > >>>>>> + > >>>>>> + lvds1: lvds-encoder@feb90100 { > >>>>>> + compatible = "renesas,r8a77990-lvds"; > >>>>>> + reg = <0 0xfeb90100 0 0x20>; > >>>>>> + clocks = <&cpg CPG_MOD 727>; > >>>>>> + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; > >>>>>> + resets = <&cpg 726>; > >>>> > >>>> Also, is the missmatch between the index for the clock and reset > >>>> intentional? > >>> > >>> It is. According to the datasheet, the two LVDS encoders have > >>> different module stop bits, but share the same reset (lovely hardware > >>> design, it will be fun to support that in the driver :-S). > >> > >> Sorry, I got it wrong. it's bit 725 that is shared between the two LVDS > >> encoders, to reset the two LVDS PLLs together. The encoders themselves > >> still have independent reset bits. I'll fix this. > > > > And of course it's the clock you were commenting on, not the reset. *sigh* > > > > According to the datasheets the two LVDS encoders share one MSTP. Whether > > that's a mistake in the documentation or not I can't tell yet, as I have > > only tested LVDS0. > > Could we follow-up with the HW team? > I'm not opposed to taking the patch with this portion as-is > but it would be good to clarify this somehow. I tried setting the clock to MSTP 726, and I then get vblank interrupt timeouts. Furthermore I've now tested the LVDS1 output with a display panel, and while I still can't get the backlight to work, the panel displays the correct image with MSTP 727. I thus conclude that the above is correct. > >>>>>> + status = "disabled"; > >>>>>> + > >>>>>> + ports { > >>>>>> + #address-cells = <1>; > >>>>>> + #size-cells = <0>; > >>>>>> + > >>>>>> + port@0 { > >>>>>> + reg = <0>; > >>>>>> + lvds1_in: endpoint { > >>>>>> + remote-endpoint = <&du_out_lvds1>; > >>>>>> + }; > >>>>>> + }; > >>>>>> + > >>>>>> + port@1 { > >>>>>> + reg = <1>; > >>>>>> + lvds1_out: endpoint { > >>>>>> + }; > >>>>>> + }; > >>>>>> + }; > >>>>>> + };
On Wed, Sep 19, 2018 at 04:11:36PM +0300, Laurent Pinchart wrote: > Hi Simon, > > On Wednesday, 19 September 2018 11:35:07 EEST Simon Horman wrote: > > On Mon, Sep 17, 2018 at 11:59:32AM +0300, Laurent Pinchart wrote: > > > On Monday, 17 September 2018 11:54:04 EEST Laurent Pinchart wrote: > > >> On Monday, 17 September 2018 11:47:15 EEST Laurent Pinchart wrote: > > >>> On Monday, 17 September 2018 11:14:20 EEST Simon Horman wrote: > > >>>> On Mon, Sep 17, 2018 at 09:50:55AM +0200, Simon Horman wrote: > > >>>>> On Fri, Sep 14, 2018 at 12:10:43PM +0300, Laurent Pinchart wrote: > > >>>>>> The R8A77990 (E3) platform has one RGB output and two LVDS > > >>>>>> outputs connected to the DU. Add the DT nodes for the DU, LVDS > > >>>>>> encoders and supporting VSP and FCP. > > >>>>>> > > >>>>>> Signed-off-by: Laurent Pinchart > > >>>>>> <laurent.pinchart+renesas@ideasonboard.com> > > >>>>>> Tested-by: Jacopo Mondi <jacopo+renesas@jmondi.org> > > >>>>>> --- > > >>>>>> > > >>>>>> arch/arm64/boot/dts/renesas/r8a77990.dtsi | 167 ++++++++++++++++++++ > > >>>>>> 1 file changed, 167 insertions(+) > > >>>>>> > > >>>>>> diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi > > >>>>>> b/arch/arm64/boot/dts/renesas/r8a77990.dtsi index > > >>>>>> abb14af76c0e..600074ca3ee5 100644 > > >>>>>> --- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi > > >>>>>> +++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi > > [snip] > > > >>>>>> + lvds0: lvds-encoder@feb90000 { > > >>>>>> + compatible = "renesas,r8a77990-lvds"; > > >>>>>> + reg = <0 0xfeb90000 0 0x20>; > > >>>>>> + clocks = <&cpg CPG_MOD 727>; > > >>>>>> + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; > > >>>>>> + resets = <&cpg 727>; > > >>>>>> + status = "disabled"; > > >>>>>> + > > >>>>>> + ports { > > >>>>>> + #address-cells = <1>; > > >>>>>> + #size-cells = <0>; > > >>>>>> + > > >>>>>> + port@0 { > > >>>>>> + reg = <0>; > > >>>>>> + lvds0_in: endpoint { > > >>>>>> + remote-endpoint = <&du_out_lvds0>; > > >>>>>> + }; > > >>>>>> + }; > > >>>>>> + > > >>>>>> + port@1 { > > >>>>>> + reg = <1>; > > >>>>>> + lvds0_out: endpoint { > > >>>>>> + }; > > >>>>>> + }; > > >>>>>> + }; > > >>>>>> + }; > > >>>>>> + > > >>>>>> + lvds1: lvds-encoder@feb90100 { > > >>>>>> + compatible = "renesas,r8a77990-lvds"; > > >>>>>> + reg = <0 0xfeb90100 0 0x20>; > > >>>>>> + clocks = <&cpg CPG_MOD 727>; > > >>>>>> + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; > > >>>>>> + resets = <&cpg 726>; > > >>>> > > >>>> Also, is the missmatch between the index for the clock and reset > > >>>> intentional? > > >>> > > >>> It is. According to the datasheet, the two LVDS encoders have > > >>> different module stop bits, but share the same reset (lovely hardware > > >>> design, it will be fun to support that in the driver :-S). > > >> > > >> Sorry, I got it wrong. it's bit 725 that is shared between the two LVDS > > >> encoders, to reset the two LVDS PLLs together. The encoders themselves > > >> still have independent reset bits. I'll fix this. > > > > > > And of course it's the clock you were commenting on, not the reset. *sigh* > > > > > > According to the datasheets the two LVDS encoders share one MSTP. Whether > > > that's a mistake in the documentation or not I can't tell yet, as I have > > > only tested LVDS0. > > > > Could we follow-up with the HW team? > > I'm not opposed to taking the patch with this portion as-is > > but it would be good to clarify this somehow. > > I tried setting the clock to MSTP 726, and I then get vblank interrupt > timeouts. Furthermore I've now tested the LVDS1 output with a display panel, > and while I still can't get the backlight to work, the panel displays the > correct image with MSTP 727. I thus conclude that the above is correct. Thanks for the follow-up, that sounds reasonable to me. Am I correct in thinking a v3 of this patchset is on its way regardless? > > > >>>>>> + status = "disabled"; > > >>>>>> + > > >>>>>> + ports { > > >>>>>> + #address-cells = <1>; > > >>>>>> + #size-cells = <0>; > > >>>>>> + > > >>>>>> + port@0 { > > >>>>>> + reg = <0>; > > >>>>>> + lvds1_in: endpoint { > > >>>>>> + remote-endpoint = <&du_out_lvds1>; > > >>>>>> + }; > > >>>>>> + }; > > >>>>>> + > > >>>>>> + port@1 { > > >>>>>> + reg = <1>; > > >>>>>> + lvds1_out: endpoint { > > >>>>>> + }; > > >>>>>> + }; > > >>>>>> + }; > > >>>>>> + }; > > -- > Regards, > > Laurent Pinchart > > >
Hi Simon, On Friday, 21 September 2018 10:16:44 EEST Simon Horman wrote: > On Wed, Sep 19, 2018 at 04:11:36PM +0300, Laurent Pinchart wrote: > > On Wednesday, 19 September 2018 11:35:07 EEST Simon Horman wrote: > >> On Mon, Sep 17, 2018 at 11:59:32AM +0300, Laurent Pinchart wrote: > >>> On Monday, 17 September 2018 11:54:04 EEST Laurent Pinchart wrote: > >>>> On Monday, 17 September 2018 11:47:15 EEST Laurent Pinchart wrote: > >>>>> On Monday, 17 September 2018 11:14:20 EEST Simon Horman wrote: > >>>>>> On Mon, Sep 17, 2018 at 09:50:55AM +0200, Simon Horman wrote: > >>>>>>> On Fri, Sep 14, 2018 at 12:10:43PM +0300, Laurent Pinchart wrote: > >>>>>>>> The R8A77990 (E3) platform has one RGB output and two LVDS > >>>>>>>> outputs connected to the DU. Add the DT nodes for the DU, LVDS > >>>>>>>> encoders and supporting VSP and FCP. > >>>>>>>> > >>>>>>>> Signed-off-by: Laurent Pinchart > >>>>>>>> <laurent.pinchart+renesas@ideasonboard.com> > >>>>>>>> Tested-by: Jacopo Mondi <jacopo+renesas@jmondi.org> > >>>>>>>> --- > >>>>>>>> > >>>>>>>> arch/arm64/boot/dts/renesas/r8a77990.dtsi | 167 +++++++++++++++++ > >>>>>>>> 1 file changed, 167 insertions(+) > >>>>>>>> > >>>>>>>> diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi > >>>>>>>> b/arch/arm64/boot/dts/renesas/r8a77990.dtsi index > >>>>>>>> abb14af76c0e..600074ca3ee5 100644 > >>>>>>>> --- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi > >>>>>>>> +++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi > > > > [snip] > > > >>>>>>>> + lvds0: lvds-encoder@feb90000 { > >>>>>>>> + compatible = "renesas,r8a77990-lvds"; > >>>>>>>> + reg = <0 0xfeb90000 0 0x20>; > >>>>>>>> + clocks = <&cpg CPG_MOD 727>; > >>>>>>>> + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; > >>>>>>>> + resets = <&cpg 727>; > >>>>>>>> + status = "disabled"; > >>>>>>>> + > >>>>>>>> + ports { > >>>>>>>> + #address-cells = <1>; > >>>>>>>> + #size-cells = <0>; > >>>>>>>> + > >>>>>>>> + port@0 { > >>>>>>>> + reg = <0>; > >>>>>>>> + lvds0_in: endpoint { > >>>>>>>> + remote-endpoint = <&du_out_lvds0>; > >>>>>>>> + }; > >>>>>>>> + }; > >>>>>>>> + > >>>>>>>> + port@1 { > >>>>>>>> + reg = <1>; > >>>>>>>> + lvds0_out: endpoint { > >>>>>>>> + }; > >>>>>>>> + }; > >>>>>>>> + }; > >>>>>>>> + }; > >>>>>>>> + > >>>>>>>> + lvds1: lvds-encoder@feb90100 { > >>>>>>>> + compatible = "renesas,r8a77990-lvds"; > >>>>>>>> + reg = <0 0xfeb90100 0 0x20>; > >>>>>>>> + clocks = <&cpg CPG_MOD 727>; > >>>>>>>> + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; > >>>>>>>> + resets = <&cpg 726>; > >>>>>> > >>>>>> Also, is the missmatch between the index for the clock and reset > >>>>>> intentional? > >>>>> > >>>>> It is. According to the datasheet, the two LVDS encoders have > >>>>> different module stop bits, but share the same reset (lovely > >>>>> hardware design, it will be fun to support that in the driver :-S). > >>>> > >>>> Sorry, I got it wrong. it's bit 725 that is shared between the two > >>>> LVDS encoders, to reset the two LVDS PLLs together. The encoders > >>>> themselves still have independent reset bits. I'll fix this. > >>> > >>> And of course it's the clock you were commenting on, not the reset. > >>> *sigh* > >>> > >>> According to the datasheets the two LVDS encoders share one MSTP. > >>> Whether that's a mistake in the documentation or not I can't tell yet, > >>> as I have only tested LVDS0. > >> > >> Could we follow-up with the HW team? > >> I'm not opposed to taking the patch with this portion as-is > >> but it would be good to clarify this somehow. > > > > I tried setting the clock to MSTP 726, and I then get vblank interrupt > > timeouts. Furthermore I've now tested the LVDS1 output with a display > > panel, and while I still can't get the backlight to work, the panel > > displays the correct image with MSTP 727. I thus conclude that the above > > is correct. > > Thanks for the follow-up, that sounds reasonable to me. > > Am I correct in thinking a v3 of this patchset is on its way regardless? Yes, you're correct. > >>>>>>>> + status = "disabled"; > >>>>>>>> + > >>>>>>>> + ports { > >>>>>>>> + #address-cells = <1>; > >>>>>>>> + #size-cells = <0>; > >>>>>>>> + > >>>>>>>> + port@0 { > >>>>>>>> + reg = <0>; > >>>>>>>> + lvds1_in: endpoint { > >>>>>>>> + remote-endpoint = <&du_out_lvds1>; > >>>>>>>> + }; > >>>>>>>> + }; > >>>>>>>> + > >>>>>>>> + port@1 { > >>>>>>>> + reg = <1>; > >>>>>>>> + lvds1_out: endpoint { > >>>>>>>> + }; > >>>>>>>> + }; > >>>>>>>> + }; > >>>>>>>> + };
Hello everybody, This patch series adds display support for the D3 and E3 SoCs, and in particular the Draak and Ebisu boards. The code is based on Ulrich's "[PROTO][PATCH 00/10] R-Car D3 LVDS/HDMI support (with PLL)" series previously posted to the dri-devel and linux-renesas-soc mailing lists. It has been extensively reworked and partly rewritten, and support for E3 and Ebisu has been added. The DU in the D3 and E3 SoCs has no internal PLL. In order to achieve precise pixel clock rates (required, among other use cases, for HDMI operation), the PLL from the internal LVDS encoder must be programmed and its output clock routed back to the DU. The series starts with update to the DU and LVDS encoder DT bindings to add E3 (R8A77990) support (patches 01/16 and 02/16) and new clock sources for the LVDS encoder (patch 03/16). The next patch (04/16) adds a .mode_valid() operation to the thc63lvd1024 driver, to reject modes outside of the LVDS decoder's pixel clock operating range (8 MHz to 135 MHz). The patch can be merged on its own separately from this series. Patch (05/16) adds support for D3 and E3 to the LVDS encoder driver. Compared to the already supported SoCs, D3 and E3 use a different initialization sequence and have a different PLL architecture, with more options for the input clock. The next five patches (06/16 to 10/16) perform small reworks or add support for miscellaneous missing features and limitations of the DU, to be followed by patch 11/16 that adds support for the D3 and E3 to the DU driver. Finally patches 12/16 to 16/16 enable display for the D3 and E3 boards in DT. Patch 12/16 adds support for the I2C controllers in the E3 DT, and will likely be merged separately from this series. Patch 13/16 adds all the display IP cores (FCP, VSP, DU and LVDS encoders) to the E3 DT, while patch 14/16 adds (and wires up) the missing LVDS encoders to the D3 DT. Patches 15/16 and 16/16 then enable display output for the Ebisu and Draak boards respectively. I believe the patch series to be ready for upstreaming (after fixing the issues found during review of course). There is no big hack in the code, and I haven't noticed any regression. A few issues are still unsolved, such as how to disable display outputs independently on D3 and E3, and usage of the LVDS PLL for the RGB output, but those are not regressions and shouldn't in my opinion be considered as show stoppers. The patches are available from git://linuxtv.org/pinchartl/media.git drm/du/lvds-pll with an additional patch for E3 pinctrl that is required for testing and has been queued by Geert for v4.20 already. Please see individual patches for changelogs since v1. Kieran Bingham (1): arm64: dts: renesas: r8a77995: Add LVDS support Laurent Pinchart (12): dt-bindings: display: renesas: du: Document r8a77990 bindings dt-bindings: display: renesas: lvds: Document r8a77990 bindings dt-bindings: display: renesas: lvds: Add EXTAL and DU_DOTCLKIN clocks drm: bridge: thc63: Restrict modes based on hardware operating frequency drm: rcar-du: lvds: D3/E3 support drm: rcar-du: Perform the initial CRTC setup from rcar_du_crtc_get() drm: rcar-du: Use LVDS PLL clock as dot clock when possible drm: rcar-du: Enable configurable DPAD0 routing on Gen3 drm: rcar-du: Cache DSYSR value to ensure known initial value drm: rcar-du: Don't use TV sync mode when not supported by the hardware arm64: dts: renesas: r8a77990: Add display output support arm64: dts: renesas: r8a77990: ebisu: Enable VGA and HDMI outputs Takeshi Kihara (1): arm64: dts: renesas: r8a77990: Add I2C device nodes Ulrich Hecht (2): drm: rcar-du: Add r8a77990 and r8a77995 device support arm64: dts: renesas: r8a77995: draak: Enable HDMI display output .../bindings/display/bridge/renesas,lvds.txt | 13 +- .../devicetree/bindings/display/renesas,du.txt | 2 + arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts | 166 ++++++++++ arch/arm64/boot/dts/renesas/r8a77990.dtsi | 290 +++++++++++++++++ arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 98 +++++- arch/arm64/boot/dts/renesas/r8a77995.dtsi | 56 ++++ drivers/gpu/drm/bridge/thc63lvd1024.c | 18 ++ drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 136 ++++---- drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 5 + drivers/gpu/drm/rcar-du/rcar_du_drv.c | 63 +++- drivers/gpu/drm/rcar-du/rcar_du_drv.h | 3 + drivers/gpu/drm/rcar-du/rcar_du_group.c | 88 +++-- drivers/gpu/drm/rcar-du/rcar_du_kms.c | 12 + drivers/gpu/drm/rcar-du/rcar_lvds.c | 355 ++++++++++++++++++--- drivers/gpu/drm/rcar-du/rcar_lvds_regs.h | 43 ++- 15 files changed, 1200 insertions(+), 148 deletions(-)