Thread (1 message) 1 message, 1 author, 2018-02-15

Re: [PATCH 04/11] soc: renesas: rcar-sysc: add R8A77980 support

From: Sergei Shtylyov <hidden>
Date: 2018-02-15 16:48:28

Hello!

On 02/05/2018 04:23 PM, Geert Uytterhoeven wrote:
quoted
Add support for R-Car V3H (R8A77980) SoC power areas to the R-Car SYSC
driver.

Based on the original (and large) patch by Vladimir Barinov.

Signed-off-by: Vladimir Barinov <vladimir.barinov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
Thanks for your patch!
quoted
--- /dev/null
+++ renesas/drivers/soc/renesas/r8a77980-sysc.c
@@ -0,0 +1,52 @@
[...]
quoted
+static const struct rcar_sysc_area r8a77980_areas[] __initconst = {
+       { "always-on",      0, 0, R8A77980_PD_ALWAYS_ON, -1, PD_ALWAYS_ON },
+       { "ca53-scu",   0x140, 0, R8A77980_PD_CA53_SCU, R8A77980_PD_ALWAYS_ON,
+         PD_SCU },
+       { "ca53-cpu0",  0x200, 0, R8A77980_PD_CA53_CPU0, R8A77980_PD_CA53_SCU,
+         PD_CPU_NOCR },
+       { "ca53-cpu1",  0x200, 1, R8A77980_PD_CA53_CPU1, R8A77980_PD_CA53_SCU,
+         PD_CPU_NOCR },
+       { "ca53-cpu2",  0x200, 2, R8A77980_PD_CA53_CPU2, R8A77980_PD_CA53_SCU,
+         PD_CPU_NOCR },
+       { "ca53-cpu3",  0x200, 3, R8A77980_PD_CA53_CPU3, R8A77980_PD_CA53_SCU,
+         PD_CPU_NOCR },
+       { "cr7",        0x240, 0, R8A77980_PD_CR7,      R8A77980_PD_ALWAYS_ON },
+       { "a3ir",       0x180, 0, R8A77980_PD_A3IR,     R8A77980_PD_ALWAYS_ON },
+       { "a2ir0",      0x400, 0, R8A77980_PD_A2IR0,    R8A77980_PD_ALWAYS_ON },
+       { "a2ir1",      0x400, 1, R8A77980_PD_A2IR1,    R8A77980_PD_A2IR0 },
+       { "a2ir2",      0x400, 2, R8A77980_PD_A2IR2,    R8A77980_PD_A2IR0 },
+       { "a2ir3",      0x400, 3, R8A77980_PD_A2IR3,    R8A77980_PD_A2IR0 },
+       { "a2ir4",      0x400, 4, R8A77980_PD_A2IR4,    R8A77980_PD_A2IR0 },
+       { "a2ir5",      0x400, 5, R8A77980_PD_A2IR5,    R8A77980_PD_A2IR0 },
Shouldn't all a2irN domains have a3ir as their parent?
   Maybe.... I'd looked at the r8a77970-sysc.c and it also had A2IR0 as parent to all
other A2IR<n> clocks.
quoted
+       { "a2sc0",      0x400, 6, R8A77980_PD_A2SC0,    R8A77980_PD_ALWAYS_ON },
+       { "a2sc1",      0x400, 7, R8A77980_PD_A2SC1,    R8A77980_PD_A2SC0 },
+       { "a2sc2",      0x400, 8, R8A77980_PD_A2SC2,    R8A77980_PD_A2SC0 },
+       { "a2sc3",      0x400, 9, R8A77980_PD_A2SC3,    R8A77980_PD_A2SC0 },
+       { "a2sc4",      0x400, 10, R8A77980_PD_A2SC4,   R8A77980_PD_A2SC0 },
Shouldn't all a2scN domains have a3ir as their parent?
   Why A3IR?
quoted
+       { "a2pd0",      0x400, 11, R8A77980_PD_A2PD0,   R8A77980_PD_ALWAYS_ON },
+       { "a2pd1",      0x400, 12, R8A77980_PD_A2PD1,   R8A77980_PD_A2PD0 },
Shouldn't all a2pdN domains have a3ir as their parent?
   Again, why?
quoted
+       { "a2cn",       0x400, 13, R8A77980_PD_A2CN,    R8A77980_PD_ALWAYS_ON },
Shouldn't the a2cn domain have a3ir as its parent?
   ?
quoted
+       { "a3vip",      0x2c0, 0, R8A77980_PD_A3VIP,    R8A77980_PD_ALWAYS_ON },
+       { "a3vip1",     0x300, 0, R8A77980_PD_A3VIP1,   R8A77980_PD_A3VIP },
+       { "a3vip2",     0x280, 0, R8A77980_PD_A3VIP2,   R8A77980_PD_A3VIP },
With the above fixed:
Reviewed-by: Geert Uytterhoeven <redacted>

Gr{oetje,eeting}s,

                        Geert
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help