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

[Sergei Shtylyov <sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>]

Hello!

On 02/05/2018 04:23 PM, Geert Uytterhoeven wrote:

>> 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!
> 
>> --- /dev/null
>> +++ renesas/drivers/soc/renesas/r8a77980-sysc.c
>> @@ -0,0 +1,52 @@
[...]
>> +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.

>> +       { "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?

>> +       { "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?

> 
>> +       { "a2cn",       0x400, 13, R8A77980_PD_A2CN,    R8A77980_PD_ALWAYS_ON },
> 
> Shouldn't the a2cn domain have a3ir as its parent?

   ?

>> +       { "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 <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
> 
> 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