| Message ID | 20201227121925.8431-1-wsa+renesas@sang-engineering.com (mailing list archive) |
|---|---|
| State | Rejected |
| Delegated to: | Geert Uytterhoeven |
| Headers | show |
| Series | [RFC] arm64: dts: r8a779a0: correct reset values for GPIO | expand |
Hi Wolfram, On Sun, Dec 27, 2020 at 1:19 PM Wolfram Sang <wsa+renesas@sang-engineering.com> wrote: > Because the datasheet is ambigious, copy over the reset values from the > latest BSP. > > Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> > --- > > While looking for a problem when obtaining the reset GPIO for RAVB, I > noticed this difference and so send this patch as a notification. It > sadly did not fix my RAVB problem, so I'll report it with the RAVB > patches there. I didn't find a map from "pfc-clocks" to "GPIO block" > yet, so this is all very confusing without it. AFAIUI, Table 6.2 ("Configuration of Registers in PFC") shows the grouping of the PFC/GPIO blocks, revealing the mapping from 4 module clocks to 4 groups of 2 or 4 GPIO blocks. > --- a/arch/arm64/boot/dts/renesas/r8a779a0.dtsi > +++ b/arch/arm64/boot/dts/renesas/r8a779a0.dtsi > @@ -110,7 +110,7 @@ gpio0: gpio@e6058180 { > interrupts = <GIC_SPI 832 IRQ_TYPE_LEVEL_HIGH>; > clocks = <&cpg CPG_MOD 916>; > power-domains = <&sysc R8A779A0_PD_ALWAYS_ON>; > - resets = <&cpg 916>; > + resets = <&cpg 1331>; I doubt the reset topology differs from the clock topology... Let's hope this will be clarified in a datasheet update soon. Gr{oetje,eeting}s, Geert
Hi Wolfram, On Tue, Jan 5, 2021 at 1:19 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > On Sun, Dec 27, 2020 at 1:19 PM Wolfram Sang > <wsa+renesas@sang-engineering.com> wrote: > > Because the datasheet is ambigious, copy over the reset values from the > > latest BSP. > > > > Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> > > --- a/arch/arm64/boot/dts/renesas/r8a779a0.dtsi > > +++ b/arch/arm64/boot/dts/renesas/r8a779a0.dtsi > > @@ -110,7 +110,7 @@ gpio0: gpio@e6058180 { > > interrupts = <GIC_SPI 832 IRQ_TYPE_LEVEL_HIGH>; > > clocks = <&cpg CPG_MOD 916>; > > power-domains = <&sysc R8A779A0_PD_ALWAYS_ON>; > > - resets = <&cpg 916>; > > + resets = <&cpg 1331>; > > I doubt the reset topology differs from the clock topology... > Let's hope this will be clarified in a datasheet update soon. I wrote a small test to check which reset bits reset the GPIO blocks. I can confirm the original resets values are correct, and using the bits marked PFCx in the Software Reset Registers 12/13/14 do not have any impact on the GPIO registers. So the BSP is wrong, and this patch should be dropped. Gr{oetje,eeting}s, Geert
On Fri, Jan 08, 2021 at 10:06:51AM +0100, Geert Uytterhoeven wrote: > Hi Wolfram, > > On Tue, Jan 5, 2021 at 1:19 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > On Sun, Dec 27, 2020 at 1:19 PM Wolfram Sang > > <wsa+renesas@sang-engineering.com> wrote: > > > Because the datasheet is ambigious, copy over the reset values from the > > > latest BSP. > > > > > > Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> > > > > --- a/arch/arm64/boot/dts/renesas/r8a779a0.dtsi > > > +++ b/arch/arm64/boot/dts/renesas/r8a779a0.dtsi > > > @@ -110,7 +110,7 @@ gpio0: gpio@e6058180 { > > > interrupts = <GIC_SPI 832 IRQ_TYPE_LEVEL_HIGH>; > > > clocks = <&cpg CPG_MOD 916>; > > > power-domains = <&sysc R8A779A0_PD_ALWAYS_ON>; > > > - resets = <&cpg 916>; > > > + resets = <&cpg 1331>; > > > > I doubt the reset topology differs from the clock topology... > > Let's hope this will be clarified in a datasheet update soon. > > I wrote a small test to check which reset bits reset the GPIO blocks. > I can confirm the original resets values are correct, and using the bits > marked PFCx in the Software Reset Registers 12/13/14 do not have any > impact on the GPIO registers. > > So the BSP is wrong, and this patch should be dropped. Thanks for checking!
diff --git a/arch/arm64/boot/dts/renesas/r8a779a0.dtsi b/arch/arm64/boot/dts/renesas/r8a779a0.dtsi index 2c7bb1503cda..16c64ec548df 100644 --- a/arch/arm64/boot/dts/renesas/r8a779a0.dtsi +++ b/arch/arm64/boot/dts/renesas/r8a779a0.dtsi @@ -110,7 +110,7 @@ gpio0: gpio@e6058180 { interrupts = <GIC_SPI 832 IRQ_TYPE_LEVEL_HIGH>; clocks = <&cpg CPG_MOD 916>; power-domains = <&sysc R8A779A0_PD_ALWAYS_ON>; - resets = <&cpg 916>; + resets = <&cpg 1331>; gpio-controller; #gpio-cells = <2>; // gpio-ranges = <&pfc 0 0 28>; @@ -124,7 +124,7 @@ gpio1: gpio@e6050180 { interrupts = <GIC_SPI 836 IRQ_TYPE_LEVEL_HIGH>; clocks = <&cpg CPG_MOD 915>; power-domains = <&sysc R8A779A0_PD_ALWAYS_ON>; - resets = <&cpg 915>; + resets = <&cpg 1330>; gpio-controller; #gpio-cells = <2>; // gpio-ranges = <&pfc 0 32 31>; @@ -138,7 +138,7 @@ gpio2: gpio@e6050980 { interrupts = <GIC_SPI 840 IRQ_TYPE_LEVEL_HIGH>; clocks = <&cpg CPG_MOD 915>; power-domains = <&sysc R8A779A0_PD_ALWAYS_ON>; - resets = <&cpg 915>; + resets = <&cpg 1330>; gpio-controller; #gpio-cells = <2>; // gpio-ranges = <&pfc 0 64 25>; @@ -152,7 +152,7 @@ gpio3: gpio@e6058980 { interrupts = <GIC_SPI 844 IRQ_TYPE_LEVEL_HIGH>; clocks = <&cpg CPG_MOD 916>; power-domains = <&sysc R8A779A0_PD_ALWAYS_ON>; - resets = <&cpg 916>; + resets = <&cpg 1331>; gpio-controller; #gpio-cells = <2>; // gpio-ranges = <&pfc 0 96 17>; @@ -166,7 +166,7 @@ gpio4: gpio@e6060180 { interrupts = <GIC_SPI 848 IRQ_TYPE_LEVEL_HIGH>; clocks = <&cpg CPG_MOD 917>; power-domains = <&sysc R8A779A0_PD_ALWAYS_ON>; - resets = <&cpg 917>; + resets = <&cpg 1400>; gpio-controller; #gpio-cells = <2>; // gpio-ranges = <&pfc 0 128 27>; @@ -180,7 +180,7 @@ gpio5: gpio@e6060980 { interrupts = <GIC_SPI 852 IRQ_TYPE_LEVEL_HIGH>; clocks = <&cpg CPG_MOD 917>; power-domains = <&sysc R8A779A0_PD_ALWAYS_ON>; - resets = <&cpg 917>; + resets = <&cpg 1400>; gpio-controller; #gpio-cells = <2>; // gpio-ranges = <&pfc 0 160 21>; @@ -194,7 +194,7 @@ gpio6: gpio@e6068180 { interrupts = <GIC_SPI 856 IRQ_TYPE_LEVEL_HIGH>; clocks = <&cpg CPG_MOD 918>; power-domains = <&sysc R8A779A0_PD_ALWAYS_ON>; - resets = <&cpg 918>; + resets = <&cpg 1401>; gpio-controller; #gpio-cells = <2>; // gpio-ranges = <&pfc 0 192 21>; @@ -208,7 +208,7 @@ gpio7: gpio@e6068980 { interrupts = <GIC_SPI 860 IRQ_TYPE_LEVEL_HIGH>; clocks = <&cpg CPG_MOD 918>; power-domains = <&sysc R8A779A0_PD_ALWAYS_ON>; - resets = <&cpg 918>; + resets = <&cpg 1401>; gpio-controller; #gpio-cells = <2>; // gpio-ranges = <&pfc 0 224 21>; @@ -222,7 +222,7 @@ gpio8: gpio@e6069180 { interrupts = <GIC_SPI 864 IRQ_TYPE_LEVEL_HIGH>; clocks = <&cpg CPG_MOD 918>; power-domains = <&sysc R8A779A0_PD_ALWAYS_ON>; - resets = <&cpg 918>; + resets = <&cpg 1401>; gpio-controller; #gpio-cells = <2>; // gpio-ranges = <&pfc 0 256 21>; @@ -236,7 +236,7 @@ gpio9: gpio@e6069980 { interrupts = <GIC_SPI 868 IRQ_TYPE_LEVEL_HIGH>; clocks = <&cpg CPG_MOD 918>; power-domains = <&sysc R8A779A0_PD_ALWAYS_ON>; - resets = <&cpg 918>; + resets = <&cpg 1401>; gpio-controller; #gpio-cells = <2>; // gpio-ranges = <&pfc 0 288 21>;
Because the datasheet is ambigious, copy over the reset values from the latest BSP. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> --- While looking for a problem when obtaining the reset GPIO for RAVB, I noticed this difference and so send this patch as a notification. It sadly did not fix my RAVB problem, so I'll report it with the RAVB patches there. I didn't find a map from "pfc-clocks" to "GPIO block" yet, so this is all very confusing without it. arch/arm64/boot/dts/renesas/r8a779a0.dtsi | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-)