| Message ID | 2539026.OyU5nvpxa6@wasted.cogentembedded.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Simon Horman |
| Headers | show |
On Wed, Jun 01, 2016 at 01:24:21AM +0300, Sergei Shtylyov wrote: > The initial R8A7792 SoC device tree including 2 CPU cores, GIC, timer, SYSC, > and the required clock descriptions. > > Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> This is rather large for an initial DTSI. Did you give any consideration to splitting it up: e.g. only providing what is needed to get to a serial console? With regards to SMP. Have you checked to make sure CPU hotplug works on all CPUs? And that the system behaves sanely on suspend/resume. If it is not possible to verify this at this stage then I would recommend only enabling one CPU at this stage.
On Wed, Jun 1, 2016 at 12:24 AM, Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> wrote: > The initial R8A7792 SoC device tree including 2 CPU cores, GIC, timer, SYSC, > and the required clock descriptions. > > Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> > > --- > arch/arm/boot/dts/r8a7792.dtsi | 423 +++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 423 insertions(+) > > Index: renesas/arch/arm/boot/dts/r8a7792.dtsi > =================================================================== > --- /dev/null > +++ renesas/arch/arm/boot/dts/r8a7792.dtsi > @@ -0,0 +1,423 @@ > +/* > + * Device Tree Source for the r8a7792 SoC > + * > + * Copyright (C) 2016 Cogent Embedded Inc. > + * > + * 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 <dt-bindings/clock/r8a7792-clock.h> > +#include <dt-bindings/interrupt-controller/arm-gic.h> #include <dt-bindings/interrupt-controller/irq.h> is included implicitly by the above. > +#include <dt-bindings/power/r8a7792-sysc.h> > + > +/ { > + compatible = "renesas,r8a7792"; > + interrupt-parent = <&gic>; > + #address-cells = <2>; > + #size-cells = <2>; > + > + cpus { > + #address-cells = <1>; > + #size-cells = <0>; > + > + cpu0: cpu@0 { > + device_type = "cpu"; > + compatible = "arm,cortex-a15"; > + reg = <0>; > + clock-frequency = <1000000000>; > + clocks = <&cpg_clocks R8A7792_CLK_Z>; > + power-domains = <&sysc R8A7792_PD_CA15_CPU0>; > + next-level-cache = <&L2_CA15>; > + }; > + > + cpu1: cpu@1 { > + device_type = "cpu"; > + compatible = "arm,cortex-a15"; > + reg = <1>; > + clock-frequency = <1000000000>; > + power-domains = <&sysc R8A7792_PD_CA15_CPU1>; > + next-level-cache = <&L2_CA15>; > + }; > + > + L2_CA15: cache-controller@0 { > + compatible = "cache"; > + reg = <0>; > + cache-unified; > + cache-level = <2>; > + power-domains = <&sysc R8A7792_PD_CA15_SCU>; > + }; > + }; > + > + gic: interrupt-controller@f1001000 { It would be good to group all on-SoC devices under an "soc" node, like we started doing for r8a7795. > + clocks { > + #address-cells = <2>; > + #size-cells = <2>; > + ranges; > + > + /* External root clock */ > + extal_clk: extal { > + compatible = "fixed-clock"; > + #clock-cells = <0>; > + /* This value must be overridden by the board. */ > + clock-frequency = <0>; > + }; The fixed clocks should be at the root level these days. > + /* Special CPG clocks */ > + cpg_clocks: cpg_clocks@e6150000 { > + compatible = "renesas,r8a7792-cpg-clocks", > + "renesas,rcar-gen2-cpg-clocks"; > + reg = <0 0xe6150000 0 0x1000>; > + clocks = <&extal_clk>; > + #clock-cells = <1>; > + clock-output-names = "main", "pll0", "pll1", "pll3", > + "lb", "qspi", "sdh", "sd0", "sd1", > + "z"; "sdh", "sd0", and "sd1" do not exist. Please remove them. > + z2_clk: z2 { > + compatible = "fixed-factor-clock"; > + clocks = <&cpg_clocks R8A7792_CLK_PLL1>; > + #clock-cells = <0>; > + clock-div = <2>; > + clock-mult = <1>; > + }; V2H doesn't have Z2. > + i_clk: i { > + compatible = "fixed-factor-clock"; > + clocks = <&cpg_clocks R8A7792_CLK_PLL1>; > + #clock-cells = <0>; > + clock-div = <2>; > + clock-mult = <1>; > + }; clock-div = <3>; > + cp_clk: cp { > + compatible = "fixed-factor-clock"; > + clocks = <&extal_clk>; > + #clock-cells = <0>; > + clock-div = <2>; > + clock-mult = <1>; > + }; On V2H, CP is derived from PLL1, cfr. CL. The clock derived from EXTAL is called CPEX. > + mstp1_clks: mstp1_clks@e6150134 { > + compatible = "renesas,r8a7792-mstp-clocks", > + "renesas,cpg-mstp-clocks"; > + reg = <0 0xe6150134 0 4>, <0 0xe6150038 0 4>; > + clocks = <&p_clk>, <&p_clk>, <&p_clk>, <&rclk_clk>, > + <&cp_clk>, <&zs_clk>, <&zs_clk>, <&zs_clk>; > + #clock-cells = <1>; > + clock-indices = < > + R8A7792_CLK_TMU1 R8A7792_CLK_TMU3 > + R8A7792_CLK_TMU2 R8A7792_CLK_CMT0 > + R8A7792_CLK_TMU0 R8A7792_CLK_VSP1DU1 > + R8A7792_CLK_VSP1DU0 R8A7792_CLK_VSP1_SY > + >; > + clock-output-names = "tmu1", "tmu3", "tmu2", "cmt0", > + "tmu0", "vsp1du1", "vsp1du0", These are called "vsp1-du1", "vsp1-du0" in all other R-Car Gen2 dtsis. > + "vsp1-sy"; > + }; > + mstp2_clks: mstp2_clks@e6150138 { > + compatible = "renesas,r8a7792-mstp-clocks", > + "renesas,cpg-mstp-clocks"; > + reg = <0 0xe6150138 0 4>, <0 0xe6150040 0 4>; > + clocks = <&mp_clk>, <&zs_clk>, <&zs_clk>; > + #clock-cells = <1>; > + clock-indices = < > + R8A7792_CLK_MSIOF1 > + R8A7792_CLK_SYS_DMAC0 R8A7792_CLK_SYS_DMAC1 Wrong order of the DMACs. > + >; > + clock-output-names = "msiof1", "sys-dmac0", "sys-dmac1"; Wrong order of the DMACs. > + }; > + mstp3_clks: mstp3_clks@e615013c { > + compatible = "renesas,r8a7792-mstp-clocks", > + "renesas,cpg-mstp-clocks"; > + reg = <0 0xe615013c 0 4>, <0 0xe6150048 0 4>; > + clocks = <&cp_clk>, <&cpg_clocks R8A7792_CLK_SD0>, As there's no SD0, this can't be correct. > + <&rclk_clk>; > + #clock-cells = <1>; > + clock-indices = < > + R8A7792_CLK_TPU0 R8A7792_CLK_SDHI0 > + R8A7792_CLK_CMT1 > + >; > + clock-output-names = "tpu0", "sdhi0", "cmt1"; > + }; > + mstp5_clks: mstp5_clks@e6150144 { > + compatible = "renesas,r8a7792-mstp-clocks", > + "renesas,cpg-mstp-clocks"; > + reg = <0 0xe6150144 0 4>, <0 0xe615003c 0 4>; > + clocks = <&hp_clk>, <&extal_clk>, <&p_clk>; > + #clock-cells = <1>; > + clock-indices = < > + R8A7792_CLK_AUDIO_DMAC0 > + R8A7792_CLK_THERMAL R8A7792_CLK_PWM > + >; > + clock-output-names = "thermal", "pwm", "audmac0"; clock-output-names = "audmac0", "thermal", "pwm"; > + }; > + mstp9_clks: mstp9_clks@e6150994 { > + compatible = "renesas,r8a7792-mstp-clocks", > + "renesas,cpg-mstp-clocks"; > + reg = <0 0xe6150994 0 4>, <0 0xe61509a4 0 4>; > + clocks = <&cp_clk>, <&cp_clk>, <&cp_clk>, <&cp_clk>, > + <&cp_clk>, <&cp_clk>, <&cp_clk>, <&cp_clk>, > + <&cp_clk>, <&cp_clk>, <&p_clk>, <&p_clk>, > + <&cpg_clocks R8A7792_CLK_QSPI>, <&cp_clk>, > + <&cp_clk>, <&hp_clk>, <&cp_clk>, <&hp_clk>, > + <&hp_clk>, <&hp_clk>, <&hp_clk>, <&hp_clk>; > + #clock-cells = <1>; > + clock-indices = < > + R8A7792_CLK_GPIO7 R8A7792_CLK_GPIO6 > + R8A7792_CLK_GPIO5 R8A7792_CLK_GPIO4 > + R8A7792_CLK_GPIO3 R8A7792_CLK_GPIO2 > + R8A7792_CLK_GPIO1 R8A7792_CLK_GPIO0 > + R8A7792_CLK_GPIO11 R8A7792_CLK_GPIO10 > + R8A7792_CLK_CAN1 R8A7792_CLK_CAN0 > + R8A7792_CLK_QSPI_MOD R8A7792_CLK_GPIO9 > + R8A7792_CLK_GPIO8 R8A7792_CLK_I2C5 > + R8A7792_CLK_IICDVFS R8A7792_CLK_I2C4 > + R8A7792_CLK_I2C3 R8A7792_CLK_I2C2 > + R8A7792_CLK_I2C1 R8A7792_CLK_I2C0 > + >; > + clock-output-names = "gpio7", "gpio6", "gpio5", "gpio4", > + "gpio3", "gpio2", "gpio1", "gpio0", > + "gpio11", "gpio10", "can1", "can0", These are called "rcan1", "rcan0" in other dtsis. > + "qspi_mod", "gpio9", "gpio8", > + "i2c5", "iic3", "i2c4", "i2c3", > + "i2c2", "i2c1", "i2c0"; > + }; 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
On 06/01/2016 03:57 AM, Simon Horman wrote: >> The initial R8A7792 SoC device tree including 2 CPU cores, GIC, timer, SYSC, >> and the required clock descriptions. >> >> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> > > This is rather large for an initial DTSI. Did you give any consideration > to splitting it up: e.g. only providing what is needed to get to a serial > console? You mean dropping the majority of clocks, right? > With regards to SMP. Have you checked to make sure CPU hotplug works > on all CPUs? And that the system behaves sanely on suspend/resume. > If it is not possible to verify this at this stage then I would recommend > only enabling one CPU at this stage. No, the SMP support isn't ready yet. And I'll have to enable SMP on R8A7794 as well... MBR, Sergei
Hello. On 06/01/2016 03:57 AM, Simon Horman wrote: >> The initial R8A7792 SoC device tree including 2 CPU cores, GIC, timer, SYSC, >> and the required clock descriptions. >> >> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> > > This is rather large for an initial DTSI. Did you give any consideration > to splitting it up: e.g. only providing what is needed to get to a serial > console? Was done in the v2 patchset... > With regards to SMP. Have you checked to make sure CPU hotplug works > on all CPUs? How to test the CPU hotplug? I've now added the SMP support and made sure both CPUs are online and serve IRQs... > And that the system behaves sanely on suspend/resume. I'd be thankful if you told me how to test that. :-) > If it is not possible to verify this at this stage then I would recommend > only enabling one CPU at this stage. Had a hard time debugging SMP until I realized I'd removed CPU1 from the device tree. :-) MBR, Sergei
Hi Sergei, On Tue, Jun 7, 2016 at 12:26 AM, Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> wrote: >> With regards to SMP. Have you checked to make sure CPU hotplug works >> on all CPUs? > > How to test the CPU hotplug? I've now added the SMP support and made sure > both CPUs are online and serve IRQs... Off/online all CPUs: for i in /sys/*/*/cpu/cpu[0-9]*; do echo 0 > $i/online; echo 1 > $i/online; done Offline all CPUs: for i in /sys/*/*/cpu/cpu[0-9]*; do echo 0 > $i/online; done; cat /proc/cpuinfo Online all CPUs: for i in /sys/*/*/cpu/cpu[0-9]*; do echo 1 > $i/online; done; cat /proc/cpuinfo >> And that the system behaves sanely on suspend/resume. > > I'd be thankful if you told me how to test that. :-) System suspend: echo mem > /sys/power/state System resume: You're gonna need a "wakeup-source" in your DTS, e.g. gpio-keys. Serial should work too, echo "enabled" to the corresponding wakeup file in /sys first. In case of issues, try "echo 0 > /sys/module/printk/parameters/console_suspend". Good luck! 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
On 06/07/2016 10:13 AM, Geert Uytterhoeven wrote: [...] >>> And that the system behaves sanely on suspend/resume. >> >> I'd be thankful if you told me how to test that. :-) > > System suspend: > > echo mem > /sys/power/state Oh. I know that one! :-) > System resume: You're gonna need a "wakeup-source" in your DTS, e.g. gpio-keys. > Serial should work too, echo "enabled" to the corresponding wakeup > file in /sys first. I'm afraid I couldn't find that file. All I saw were RPM controls... > In case of issues, try "echo 0 > /sys/module/printk/parameters/console_suspend". There's no problems suspending, it's the resuming that's a problem for me. > Good luck! As usual, there was no luck. :-) WBR, Sergei
On Tue, Jun 07, 2016 at 11:58:45PM +0300, Sergei Shtylyov wrote: > On 06/07/2016 10:13 AM, Geert Uytterhoeven wrote: > > [...] > > >>>And that the system behaves sanely on suspend/resume. > >> > >> I'd be thankful if you told me how to test that. :-) > > > >System suspend: > > > > echo mem > /sys/power/state > > Oh. I know that one! :-) > > >System resume: You're gonna need a "wakeup-source" in your DTS, e.g. gpio-keys. > >Serial should work too, echo "enabled" to the corresponding wakeup > >file in /sys first. > > I'm afraid I couldn't find that file. All I saw were RPM controls... > > >In case of issues, try "echo 0 > /sys/module/printk/parameters/console_suspend". > > There's no problems suspending, it's the resuming that's a problem for me. > > >Good luck! > > As usual, there was no luck. :-) > > WBR, Sergei Does resume work for UP (i.e. without SMP)? How did testing CPU hotplug go? Did it work for all CPUs? If things work less well for SMP than UP I am inclined to ask you to defer adding SMP support.
On 06/10/2016 04:02 AM, Simon Horman wrote: >> [...] >> >>>>> And that the system behaves sanely on suspend/resume. >>>> >>>> I'd be thankful if you told me how to test that. :-) >>> >>> System suspend: >>> >>> echo mem > /sys/power/state >> >> Oh. I know that one! :-) >> >>> System resume: You're gonna need a "wakeup-source" in your DTS, e.g. gpio-keys. >>> Serial should work too, echo "enabled" to the corresponding wakeup >>> file in /sys first. >> >> I'm afraid I couldn't find that file. All I saw were RPM controls... >> >>> In case of issues, try "echo 0 > /sys/module/printk/parameters/console_suspend". >> >> There's no problems suspending, it's the resuming that's a problem for me. >> >>> Good luck! >> >> As usual, there was no luck. :-) >> >> WBR, Sergei > > Does resume work for UP (i.e. without SMP)? No. My problem with resume is I can't wake up the remote system. I don't see the needed 'wakeup' file in /sys/devices/platform/soc/e6e60000.serial/... However, if I enable CONFIG_PM_[ADVANCED_]DEBUG and do $ echo -n core /sys/.power/pm_test the system happily wakes up after a small delay (5 s), w/either SMP or UP kernel. > How did testing CPU hotplug go? Did it work for all CPUs? Sure! The only problem I'm seeing (again) is the RCAN clock failing to register: rcar_gen2_cpg_clocks_init: failed to register cpg_clocks rcan clock (-12) I was going to look at it yesterday but (wrongly) thought it somehow cured itself... I'll look at it now. MBR, Sergei
Hi Sergei, On Fri, Jun 10, 2016 at 9:29 PM, Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> wrote: > The only problem I'm seeing (again) is the RCAN clock failing to > register: > > rcar_gen2_cpg_clocks_init: failed to register cpg_clocks rcan clock (-12) > > I was going to look at it yesterday but (wrongly) thought it somehow > cured itself... I'll look at it now. The RCAN parent is the second clock in the CPG node's "clocks" property, which you didn't provide. 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
On 06/10/2016 11:42 PM, Geert Uytterhoeven wrote: >> The only problem I'm seeing (again) is the RCAN clock failing to >> register: >> >> rcar_gen2_cpg_clocks_init: failed to register cpg_clocks rcan clock (-12) >> >> I was going to look at it yesterday but (wrongly) thought it somehow >> cured itself... I'll look at it now. > > The RCAN parent is the second clock in the CPG node's "clocks" property, > which you didn't provide. Actually, the things are more complex. The figure 7.1c suggests that the RCAN clock has different parent on R8A7792 than on the other SoCs -- namely PLL1/VCO 1/4. That may be, since there's just no USB_EXTAL signal on this SoC (it doesn't seem to support any USB IPs). Which means the 'clk-rcar-gen2' driver can't work with the RCAN clock in its current form. > Gr{oetje,eeting}s, > > Geert MBR, Sergei
Hi Sergei, On Fri, Jun 10, 2016 at 10:50 PM, Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> wrote: > On 06/10/2016 11:42 PM, Geert Uytterhoeven wrote: >>> The only problem I'm seeing (again) is the RCAN clock failing to >>> register: >>> >>> rcar_gen2_cpg_clocks_init: failed to register cpg_clocks rcan clock (-12) >>> >>> I was going to look at it yesterday but (wrongly) thought it somehow >>> cured itself... I'll look at it now. >> >> The RCAN parent is the second clock in the CPG node's "clocks" property, >> which you didn't provide. > > Actually, the things are more complex. The figure 7.1c suggests that the > RCAN clock has different parent on R8A7792 than on the other SoCs -- namely > PLL1/VCO 1/4. That may be, since there's just no USB_EXTAL signal on this > SoC (it doesn't seem to support any USB IPs). Which means the > 'clk-rcar-gen2' driver can't work with the RCAN clock in its current form. Right, I had forgotten about that. Fortunately the clk-rcar-gen2 driver has a sane failure mode for this case ;-) it seems the RCAN clock can just be modeled as a fixed clock. However, its divider value isn't clear to me, as 15.9 MHz cannot be generated from PLL1 using an integer divider. Morimoto-san, can you please ask for clarification? 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
On 6/13/2016 10:12 AM, Geert Uytterhoeven wrote: >>>> The only problem I'm seeing (again) is the RCAN clock failing to >>>> register: >>>> >>>> rcar_gen2_cpg_clocks_init: failed to register cpg_clocks rcan clock (-12) >>>> >>>> I was going to look at it yesterday but (wrongly) thought it somehow >>>> cured itself... I'll look at it now. >>> >>> The RCAN parent is the second clock in the CPG node's "clocks" property, >>> which you didn't provide. >> >> Actually, the things are more complex. The figure 7.1c suggests that the >> RCAN clock has different parent on R8A7792 than on the other SoCs -- namely >> PLL1/VCO 1/4. That may be, since there's just no USB_EXTAL signal on this >> SoC (it doesn't seem to support any USB IPs). Which means the >> 'clk-rcar-gen2' driver can't work with the RCAN clock in its current form. > > Right, I had forgotten about that. > Fortunately the clk-rcar-gen2 driver has a sane failure mode for this case ;-) What do you mean? > it seems the RCAN clock can just be modeled as a fixed clock. However, > its divider value isn't clear to me, IIRC, the fixed RCAN divisor was equal to 6. [...] > Gr{oetje,eeting}s, > > Geert MBR, Sergei
Hi Sergei, On Mon, Jun 13, 2016 at 1:24 PM, Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> wrote: > On 6/13/2016 10:12 AM, Geert Uytterhoeven wrote: >>>>> The only problem I'm seeing (again) is the RCAN clock failing to >>>>> register: >>>>> >>>>> rcar_gen2_cpg_clocks_init: failed to register cpg_clocks rcan clock >>>>> (-12) >>>>> >>>>> I was going to look at it yesterday but (wrongly) thought it somehow >>>>> cured itself... I'll look at it now. >>>> >>>> >>>> The RCAN parent is the second clock in the CPG node's "clocks" property, >>>> which you didn't provide. >>> >>> >>> Actually, the things are more complex. The figure 7.1c suggests that >>> the >>> RCAN clock has different parent on R8A7792 than on the other SoCs -- >>> namely >>> PLL1/VCO 1/4. That may be, since there's just no USB_EXTAL signal on this >>> SoC (it doesn't seem to support any USB IPs). Which means the >>> 'clk-rcar-gen2' driver can't work with the RCAN clock in its current >>> form. >> >> Right, I had forgotten about that. >> Fortunately the clk-rcar-gen2 driver has a sane failure mode for this case >> ;-) > > What do you mean? I mean that it failed due to the missing parent clock, instead of continuing silently with a wrong clock rate. >> it seems the RCAN clock can just be modeled as a fixed clock. However, >> its divider value isn't clear to me, > > IIRC, the fixed RCAN divisor was equal to 6. 1560 / 6 != 15.9. 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
On Fri, Jun 10, 2016 at 10:29:17PM +0300, Sergei Shtylyov wrote: > On 06/10/2016 04:02 AM, Simon Horman wrote: > > >>[...] > >> > >>>>>And that the system behaves sanely on suspend/resume. > >>>> > >>>> I'd be thankful if you told me how to test that. :-) > >>> > >>>System suspend: > >>> > >>> echo mem > /sys/power/state > >> > >> Oh. I know that one! :-) > >> > >>>System resume: You're gonna need a "wakeup-source" in your DTS, e.g. gpio-keys. > >>>Serial should work too, echo "enabled" to the corresponding wakeup > >>>file in /sys first. > >> > >> I'm afraid I couldn't find that file. All I saw were RPM controls... > >> > >>>In case of issues, try "echo 0 > /sys/module/printk/parameters/console_suspend". > >> > >> There's no problems suspending, it's the resuming that's a problem for me. > >> > >>>Good luck! > >> > >> As usual, there was no luck. :-) > >> > >>WBR, Sergei > > > >Does resume work for UP (i.e. without SMP)? > > No. My problem with resume is I can't wake up the remote system. I don't > see the needed 'wakeup' file in > /sys/devices/platform/soc/e6e60000.serial/... > However, if I enable CONFIG_PM_[ADVANCED_]DEBUG and do > > $ echo -n core /sys/.power/pm_test > > the system happily wakes up after a small delay (5 s), w/either SMP or UP kernel. That seems promising but it seems curious that there is no wakeup file. On Lager the following procedure works for me using renesas-devel-20160613-v4.7-rc3 and shmobile defconfig. 0. Add wakeup-source property to serial@e6ce0000 node in DT 1. echo enabled > /sys/devices/platform/e6e60000.serial/tty/ttySC0/power/wakeup 2. echo mem > /sys/power/state 3. Provide input on serial console * Success! * > >How did testing CPU hotplug go? Did it work for all CPUs? > > Sure! Great! > The only problem I'm seeing (again) is the RCAN clock failing to register: > > rcar_gen2_cpg_clocks_init: failed to register cpg_clocks rcan clock (-12) > > I was going to look at it yesterday but (wrongly) thought it somehow > cured itself... I'll look at it now. Is this resolved? If not perhaps you could consider removing the node in question for now.
Hi Geert > Right, I had forgotten about that. > Fortunately the clk-rcar-gen2 driver has a sane failure mode for this case ;-) > > it seems the RCAN clock can just be modeled as a fixed clock. However, > its divider value isn't clear to me, as 15.9 MHz cannot be generated from PLL1 > using an integer divider. Morimoto-san, can you please ask for clarification? OK. Now, I asked to HW team about that. Please wait.
Hello. On 06/14/2016 03:43 AM, Simon Horman wrote: >>>> [...] >>>> >>>>>>> And that the system behaves sanely on suspend/resume. >>>>>> >>>>>> I'd be thankful if you told me how to test that. :-) >>>>> >>>>> System suspend: >>>>> >>>>> echo mem > /sys/power/state >>>> >>>> Oh. I know that one! :-) >>>> >>>>> System resume: You're gonna need a "wakeup-source" in your DTS, e.g. gpio-keys. >>>>> Serial should work too, echo "enabled" to the corresponding wakeup >>>>> file in /sys first. >>>> >>>> I'm afraid I couldn't find that file. All I saw were RPM controls... >>>> >>>>> In case of issues, try "echo 0 > /sys/module/printk/parameters/console_suspend". >>>> >>>> There's no problems suspending, it's the resuming that's a problem for me. >>>> >>>>> Good luck! >>>> >>>> As usual, there was no luck. :-) >>>> >>>> WBR, Sergei >>> >>> Does resume work for UP (i.e. without SMP)? >> >> No. My problem with resume is I can't wake up the remote system. I don't >> see the needed 'wakeup' file in >> /sys/devices/platform/soc/e6e60000.serial/... >> However, if I enable CONFIG_PM_[ADVANCED_]DEBUG and do >> >> $ echo -n core /sys/.power/pm_test >> >> the system happily wakes up after a small delay (5 s), w/either SMP or UP kernel. > > That seems promising but it seems curious that there is no wakeup file. > > On Lager the following procedure works for me using > renesas-devel-20160613-v4.7-rc3 and shmobile defconfig. > > 0. Add wakeup-source property to serial@e6ce0000 node in DT Ah, stupid me, it was the piece that I'd overlooked! > 1. echo enabled > /sys/devices/platform/e6e60000.serial/tty/ttySC0/power/wakeup > 2. echo mem > /sys/power/state > 3. Provide input on serial console > > * Success! * Yeah, works now! Sorry, I had no previous experience with the PM. Was unsupported feature back in MontaVista... :-) >>> How did testing CPU hotplug go? Did it work for all CPUs? >> >> Sure! > > Great! > >> The only problem I'm seeing (again) is the RCAN clock failing to register: >> >> rcar_gen2_cpg_clocks_init: failed to register cpg_clocks rcan clock (-12) >> >> I was going to look at it yesterday but (wrongly) thought it somehow >> cured itself... I'll look at it now. > > Is this resolved? If not perhaps you could consider removing the node > in question for now. That's what I did in v5, i.e. removed the RCAN CPG clock (not the whole node)... MBR, Sergei
On Wed, Jun 15, 2016 at 12:08:21AM +0300, Sergei Shtylyov wrote: > Hello. > > On 06/14/2016 03:43 AM, Simon Horman wrote: > > >>>>[...] > >>>> > >>>>>>>And that the system behaves sanely on suspend/resume. > >>>>>> > >>>>>> I'd be thankful if you told me how to test that. :-) > >>>>> > >>>>>System suspend: > >>>>> > >>>>> echo mem > /sys/power/state > >>>> > >>>> Oh. I know that one! :-) > >>>> > >>>>>System resume: You're gonna need a "wakeup-source" in your DTS, e.g. gpio-keys. > >>>>>Serial should work too, echo "enabled" to the corresponding wakeup > >>>>>file in /sys first. > >>>> > >>>> I'm afraid I couldn't find that file. All I saw were RPM controls... > >>>> > >>>>>In case of issues, try "echo 0 > /sys/module/printk/parameters/console_suspend". > >>>> > >>>> There's no problems suspending, it's the resuming that's a problem for me. > >>>> > >>>>>Good luck! > >>>> > >>>> As usual, there was no luck. :-) > >>>> > >>>>WBR, Sergei > >>> > >>>Does resume work for UP (i.e. without SMP)? > >> > >> No. My problem with resume is I can't wake up the remote system. I don't > >>see the needed 'wakeup' file in > >>/sys/devices/platform/soc/e6e60000.serial/... > >> However, if I enable CONFIG_PM_[ADVANCED_]DEBUG and do > >> > >>$ echo -n core /sys/.power/pm_test > >> > >>the system happily wakes up after a small delay (5 s), w/either SMP or UP kernel. > > > >That seems promising but it seems curious that there is no wakeup file. > > > >On Lager the following procedure works for me using > >renesas-devel-20160613-v4.7-rc3 and shmobile defconfig. > > > >0. Add wakeup-source property to serial@e6ce0000 node in DT > > Ah, stupid me, it was the piece that I'd overlooked! > > >1. echo enabled > /sys/devices/platform/e6e60000.serial/tty/ttySC0/power/wakeup > >2. echo mem > /sys/power/state > >3. Provide input on serial console > > > >* Success! * > > Yeah, works now! > Sorry, I had no previous experience with the PM. Was unsupported feature > back in MontaVista... :-) Great, thanks for your persistence. FWIW, I always have to refer to some notes in order to exercise PM. > >>>How did testing CPU hotplug go? Did it work for all CPUs? > >> > >> Sure! > > > >Great! > > > >> The only problem I'm seeing (again) is the RCAN clock failing to register: > >> > >>rcar_gen2_cpg_clocks_init: failed to register cpg_clocks rcan clock (-12) > >> > >> I was going to look at it yesterday but (wrongly) thought it somehow > >>cured itself... I'll look at it now. > > > >Is this resolved? If not perhaps you could consider removing the node > >in question for now. > > That's what I did in v5, i.e. removed the RCAN CPG clock (not the whole > node)... Great.
Hi Geert > > Right, I had forgotten about that. > > Fortunately the clk-rcar-gen2 driver has a sane failure mode for this case ;-) > > > > it seems the RCAN clock can just be modeled as a fixed clock. However, > > its divider value isn't clear to me, as 15.9 MHz cannot be generated from PLL1 > > using an integer divider. Morimoto-san, can you please ask for clarification? > > OK. > Now, I asked to HW team about that. > Please wait. RCAN divider is fixed for 1/49 PLL1 (= 1560MHz) -> 1/2 (= 780MHz) -> RCAN divider 1/49 (= 15.9183..MHz) Is this clear for you ?
Hi Morimoto-san, On Fri, Jun 17, 2016 at 4:14 AM, Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> wrote: >> > Right, I had forgotten about that. >> > Fortunately the clk-rcar-gen2 driver has a sane failure mode for this case ;-) >> > >> > it seems the RCAN clock can just be modeled as a fixed clock. However, >> > its divider value isn't clear to me, as 15.9 MHz cannot be generated from PLL1 >> > using an integer divider. Morimoto-san, can you please ask for clarification? >> >> OK. >> Now, I asked to HW team about that. >> Please wait. > > RCAN divider is fixed for 1/49 > > PLL1 (= 1560MHz) > -> 1/2 (= 780MHz) > -> RCAN divider 1/49 (= 15.9183..MHz) > > Is this clear for you ? Thanks, that's exactly what we need to know. 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
Index: renesas/arch/arm/boot/dts/r8a7792.dtsi =================================================================== --- /dev/null +++ renesas/arch/arm/boot/dts/r8a7792.dtsi @@ -0,0 +1,423 @@ +/* + * Device Tree Source for the r8a7792 SoC + * + * Copyright (C) 2016 Cogent Embedded Inc. + * + * 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 <dt-bindings/clock/r8a7792-clock.h> +#include <dt-bindings/interrupt-controller/arm-gic.h> +#include <dt-bindings/power/r8a7792-sysc.h> + +/ { + compatible = "renesas,r8a7792"; + interrupt-parent = <&gic>; + #address-cells = <2>; + #size-cells = <2>; + + cpus { + #address-cells = <1>; + #size-cells = <0>; + + cpu0: cpu@0 { + device_type = "cpu"; + compatible = "arm,cortex-a15"; + reg = <0>; + clock-frequency = <1000000000>; + clocks = <&cpg_clocks R8A7792_CLK_Z>; + power-domains = <&sysc R8A7792_PD_CA15_CPU0>; + next-level-cache = <&L2_CA15>; + }; + + cpu1: cpu@1 { + device_type = "cpu"; + compatible = "arm,cortex-a15"; + reg = <1>; + clock-frequency = <1000000000>; + power-domains = <&sysc R8A7792_PD_CA15_CPU1>; + next-level-cache = <&L2_CA15>; + }; + + L2_CA15: cache-controller@0 { + compatible = "cache"; + reg = <0>; + cache-unified; + cache-level = <2>; + power-domains = <&sysc R8A7792_PD_CA15_SCU>; + }; + }; + + gic: interrupt-controller@f1001000 { + compatible = "arm,gic-400"; + #interrupt-cells = <3>; + interrupt-controller; + reg = <0 0xf1001000 0 0x1000>, + <0 0xf1002000 0 0x1000>, + <0 0xf1004000 0 0x2000>, + <0 0xf1006000 0 0x2000>; + interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(2) | + IRQ_TYPE_LEVEL_HIGH)>; + }; + + timer { + compatible = "arm,armv7-timer"; + interrupts = <GIC_PPI 13 + (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>, + <GIC_PPI 14 + (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>, + <GIC_PPI 11 + (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>, + <GIC_PPI 10 + (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>; + }; + + sysc: system-controller@e6180000 { + compatible = "renesas,r8a7792-sysc"; + reg = <0 0xe6180000 0 0x0200>; + #power-domain-cells = <1>; + }; + + clocks { + #address-cells = <2>; + #size-cells = <2>; + ranges; + + /* External root clock */ + extal_clk: extal { + compatible = "fixed-clock"; + #clock-cells = <0>; + /* This value must be overridden by the board. */ + clock-frequency = <0>; + }; + + /* External PCIe clock - can be overridden by the board */ + pcie_bus_clk: pcie_bus { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <0>; + }; + + /* External SCIF clock */ + scif_clk: scif { + compatible = "fixed-clock"; + #clock-cells = <0>; + /* This value must be overridden by the board. */ + clock-frequency = <0>; + }; + + /* + * The external audio clocks are configured as 0 Hz fixed + * frequency clocks by default. Boards that provide audio + * clocks should override them. + */ + audio_clka: audio_clka { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <0>; + }; + audio_clkb: audio_clkb { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <0>; + }; + audio_clkc: audio_clkc { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <0>; + }; + + /* Special CPG clocks */ + cpg_clocks: cpg_clocks@e6150000 { + compatible = "renesas,r8a7792-cpg-clocks", + "renesas,rcar-gen2-cpg-clocks"; + reg = <0 0xe6150000 0 0x1000>; + clocks = <&extal_clk>; + #clock-cells = <1>; + clock-output-names = "main", "pll0", "pll1", "pll3", + "lb", "qspi", "sdh", "sd0", "sd1", + "z"; + #power-domain-cells = <0>; + }; + + /* Fixed factor clocks */ + pll1_div2_clk: pll1_div2 { + compatible = "fixed-factor-clock"; + clocks = <&cpg_clocks R8A7792_CLK_PLL1>; + #clock-cells = <0>; + clock-div = <2>; + clock-mult = <1>; + }; + z2_clk: z2 { + compatible = "fixed-factor-clock"; + clocks = <&cpg_clocks R8A7792_CLK_PLL1>; + #clock-cells = <0>; + clock-div = <2>; + clock-mult = <1>; + }; + zg_clk: zg { + compatible = "fixed-factor-clock"; + clocks = <&cpg_clocks R8A7792_CLK_PLL1>; + #clock-cells = <0>; + clock-div = <3>; + clock-mult = <1>; + }; + zx_clk: zx { + compatible = "fixed-factor-clock"; + clocks = <&cpg_clocks R8A7792_CLK_PLL1>; + #clock-cells = <0>; + clock-div = <3>; + clock-mult = <1>; + }; + zs_clk: zs { + compatible = "fixed-factor-clock"; + clocks = <&cpg_clocks R8A7792_CLK_PLL1>; + #clock-cells = <0>; + clock-div = <6>; + clock-mult = <1>; + }; + hp_clk: hp { + compatible = "fixed-factor-clock"; + clocks = <&cpg_clocks R8A7792_CLK_PLL1>; + #clock-cells = <0>; + clock-div = <12>; + clock-mult = <1>; + }; + i_clk: i { + compatible = "fixed-factor-clock"; + clocks = <&cpg_clocks R8A7792_CLK_PLL1>; + #clock-cells = <0>; + clock-div = <2>; + clock-mult = <1>; + }; + b_clk: b { + compatible = "fixed-factor-clock"; + clocks = <&cpg_clocks R8A7792_CLK_PLL1>; + #clock-cells = <0>; + clock-div = <12>; + clock-mult = <1>; + }; + p_clk: p { + compatible = "fixed-factor-clock"; + clocks = <&cpg_clocks R8A7792_CLK_PLL1>; + #clock-cells = <0>; + clock-div = <24>; + clock-mult = <1>; + }; + cl_clk: cl { + compatible = "fixed-factor-clock"; + clocks = <&cpg_clocks R8A7792_CLK_PLL1>; + #clock-cells = <0>; + clock-div = <48>; + clock-mult = <1>; + }; + m2_clk: m2 { + compatible = "fixed-factor-clock"; + clocks = <&cpg_clocks R8A7792_CLK_PLL1>; + #clock-cells = <0>; + clock-div = <8>; + clock-mult = <1>; + }; + rclk_clk: rclk { + compatible = "fixed-factor-clock"; + clocks = <&cpg_clocks R8A7792_CLK_PLL1>; + #clock-cells = <0>; + clock-div = <(48 * 1024)>; + clock-mult = <1>; + }; + oscclk_clk: oscclk { + compatible = "fixed-factor-clock"; + clocks = <&cpg_clocks R8A7792_CLK_PLL1>; + #clock-cells = <0>; + clock-div = <(12 * 1024)>; + clock-mult = <1>; + }; + zb3_clk: zb3 { + compatible = "fixed-factor-clock"; + clocks = <&cpg_clocks R8A7792_CLK_PLL3>; + #clock-cells = <0>; + clock-div = <4>; + clock-mult = <1>; + }; + zb3d2_clk: zb3d2 { + compatible = "fixed-factor-clock"; + clocks = <&cpg_clocks R8A7792_CLK_PLL3>; + #clock-cells = <0>; + clock-div = <8>; + clock-mult = <1>; + }; + ddr_clk: ddr { + compatible = "fixed-factor-clock"; + clocks = <&cpg_clocks R8A7792_CLK_PLL3>; + #clock-cells = <0>; + clock-div = <8>; + clock-mult = <1>; + }; + mp_clk: mp { + compatible = "fixed-factor-clock"; + clocks = <&pll1_div2_clk>; + #clock-cells = <0>; + clock-div = <15>; + clock-mult = <1>; + }; + cp_clk: cp { + compatible = "fixed-factor-clock"; + clocks = <&extal_clk>; + #clock-cells = <0>; + clock-div = <2>; + clock-mult = <1>; + }; + + /* Gate clocks */ + mstp0_clks: mstp0_clks@e6150130 { + compatible = "renesas,r8a7792-mstp-clocks", + "renesas,cpg-mstp-clocks"; + reg = <0 0xe6150130 0 4>, <0 0xe6150030 0 4>; + clocks = <&mp_clk>; + #clock-cells = <1>; + clock-indices = <R8A7792_CLK_MSIOF0>; + clock-output-names = "msiof0"; + }; + mstp1_clks: mstp1_clks@e6150134 { + compatible = "renesas,r8a7792-mstp-clocks", + "renesas,cpg-mstp-clocks"; + reg = <0 0xe6150134 0 4>, <0 0xe6150038 0 4>; + clocks = <&p_clk>, <&p_clk>, <&p_clk>, <&rclk_clk>, + <&cp_clk>, <&zs_clk>, <&zs_clk>, <&zs_clk>; + #clock-cells = <1>; + clock-indices = < + R8A7792_CLK_TMU1 R8A7792_CLK_TMU3 + R8A7792_CLK_TMU2 R8A7792_CLK_CMT0 + R8A7792_CLK_TMU0 R8A7792_CLK_VSP1DU1 + R8A7792_CLK_VSP1DU0 R8A7792_CLK_VSP1_SY + >; + clock-output-names = "tmu1", "tmu3", "tmu2", "cmt0", + "tmu0", "vsp1du1", "vsp1du0", + "vsp1-sy"; + }; + mstp2_clks: mstp2_clks@e6150138 { + compatible = "renesas,r8a7792-mstp-clocks", + "renesas,cpg-mstp-clocks"; + reg = <0 0xe6150138 0 4>, <0 0xe6150040 0 4>; + clocks = <&mp_clk>, <&zs_clk>, <&zs_clk>; + #clock-cells = <1>; + clock-indices = < + R8A7792_CLK_MSIOF1 + R8A7792_CLK_SYS_DMAC0 R8A7792_CLK_SYS_DMAC1 + >; + clock-output-names = "msiof1", "sys-dmac0", "sys-dmac1"; + }; + mstp3_clks: mstp3_clks@e615013c { + compatible = "renesas,r8a7792-mstp-clocks", + "renesas,cpg-mstp-clocks"; + reg = <0 0xe615013c 0 4>, <0 0xe6150048 0 4>; + clocks = <&cp_clk>, <&cpg_clocks R8A7792_CLK_SD0>, + <&rclk_clk>; + #clock-cells = <1>; + clock-indices = < + R8A7792_CLK_TPU0 R8A7792_CLK_SDHI0 + R8A7792_CLK_CMT1 + >; + clock-output-names = "tpu0", "sdhi0", "cmt1"; + }; + mstp4_clks: mstp4_clks@e6150140 { + compatible = "renesas,r8a7792-mstp-clocks", + "renesas,cpg-mstp-clocks"; + reg = <0 0xe6150140 0 4>, <0 0xe615004c 0 4>; + clocks = <&cp_clk>; + #clock-cells = <1>; + clock-indices = <R8A7792_CLK_IRQC>; + clock-output-names = "irqc"; + }; + mstp5_clks: mstp5_clks@e6150144 { + compatible = "renesas,r8a7792-mstp-clocks", + "renesas,cpg-mstp-clocks"; + reg = <0 0xe6150144 0 4>, <0 0xe615003c 0 4>; + clocks = <&hp_clk>, <&extal_clk>, <&p_clk>; + #clock-cells = <1>; + clock-indices = < + R8A7792_CLK_AUDIO_DMAC0 + R8A7792_CLK_THERMAL R8A7792_CLK_PWM + >; + clock-output-names = "thermal", "pwm", "audmac0"; + }; + mstp7_clks: mstp7_clks@e615014c { + compatible = "renesas,r8a7792-mstp-clocks", + "renesas,cpg-mstp-clocks"; + reg = <0 0xe615014c 0 4>, <0 0xe61501c4 0 4>; + clocks = <&zs_clk>, <&zs_clk>, <&p_clk>, <&p_clk>, + <&p_clk>, <&p_clk>, <&zx_clk>, <&zx_clk>; + #clock-cells = <1>; + clock-indices = < + R8A7792_CLK_HSCIF1 R8A7792_CLK_HSCIF0 + R8A7792_CLK_SCIF3 R8A7792_CLK_SCIF2 + R8A7792_CLK_SCIF1 R8A7792_CLK_SCIF0 + R8A7792_CLK_DU1 R8A7792_CLK_DU0 + >; + clock-output-names = "hscif1", "hscif0", "scif3", + "scif2", "scif1", "scif0", + "du1", "du0"; + }; + mstp8_clks: mstp8_clks@e6150990 { + compatible = "renesas,r8a7792-mstp-clocks", + "renesas,cpg-mstp-clocks"; + reg = <0 0xe6150990 0 4>, <0 0xe61509a0 0 4>; + clocks = <&zg_clk>, <&zg_clk>, <&zg_clk>, <&zg_clk>, + <&zg_clk>, <&zg_clk>, <&hp_clk>; + #clock-cells = <1>; + clock-indices = < + R8A7792_CLK_VIN5 R8A7792_CLK_VIN4 + R8A7792_CLK_VIN3 R8A7792_CLK_VIN2 + R8A7792_CLK_VIN1 R8A7792_CLK_VIN0 + R8A7792_CLK_ETHERAVB + >; + clock-output-names = "vin5", "vin4", "vin3", "vin2", + "vin1", "vin0", "etheravb"; + }; + mstp9_clks: mstp9_clks@e6150994 { + compatible = "renesas,r8a7792-mstp-clocks", + "renesas,cpg-mstp-clocks"; + reg = <0 0xe6150994 0 4>, <0 0xe61509a4 0 4>; + clocks = <&cp_clk>, <&cp_clk>, <&cp_clk>, <&cp_clk>, + <&cp_clk>, <&cp_clk>, <&cp_clk>, <&cp_clk>, + <&cp_clk>, <&cp_clk>, <&p_clk>, <&p_clk>, + <&cpg_clocks R8A7792_CLK_QSPI>, <&cp_clk>, + <&cp_clk>, <&hp_clk>, <&cp_clk>, <&hp_clk>, + <&hp_clk>, <&hp_clk>, <&hp_clk>, <&hp_clk>; + #clock-cells = <1>; + clock-indices = < + R8A7792_CLK_GPIO7 R8A7792_CLK_GPIO6 + R8A7792_CLK_GPIO5 R8A7792_CLK_GPIO4 + R8A7792_CLK_GPIO3 R8A7792_CLK_GPIO2 + R8A7792_CLK_GPIO1 R8A7792_CLK_GPIO0 + R8A7792_CLK_GPIO11 R8A7792_CLK_GPIO10 + R8A7792_CLK_CAN1 R8A7792_CLK_CAN0 + R8A7792_CLK_QSPI_MOD R8A7792_CLK_GPIO9 + R8A7792_CLK_GPIO8 R8A7792_CLK_I2C5 + R8A7792_CLK_IICDVFS R8A7792_CLK_I2C4 + R8A7792_CLK_I2C3 R8A7792_CLK_I2C2 + R8A7792_CLK_I2C1 R8A7792_CLK_I2C0 + >; + clock-output-names = "gpio7", "gpio6", "gpio5", "gpio4", + "gpio3", "gpio2", "gpio1", "gpio0", + "gpio11", "gpio10", "can1", "can0", + "qspi_mod", "gpio9", "gpio8", + "i2c5", "iic3", "i2c4", "i2c3", + "i2c2", "i2c1", "i2c0"; + }; + mstp10_clks: mstp10_clks@e6150998 { + compatible = "renesas,r8a7792-mstp-clocks", + "renesas,cpg-mstp-clocks"; + reg = <0 0xe6150998 0 4>, <0 0xe61509a8 0 4>; + clocks = <&p_clk>, <&p_clk>, <&p_clk>; + #clock-cells = <1>; + clock-indices = < + R8A7792_CLK_SSI_ALL + R8A7792_CLK_SSI4 R8A7792_CLK_SSI3 + >; + clock-output-names = "ssi", "ssi4", "ssi3"; + }; + }; +};
The initial R8A7792 SoC device tree including 2 CPU cores, GIC, timer, SYSC, and the required clock descriptions. Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> --- arch/arm/boot/dts/r8a7792.dtsi | 423 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 423 insertions(+)