From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sergei Shtylyov Subject: Re: [PATCH 04/11] soc: renesas: rcar-sysc: add R8A77980 support Date: Thu, 15 Feb 2018 19:48:28 +0300 Message-ID: References: <46fca582-220d-e5a7-62cd-2fc77a29846b@cogentembedded.com> <0309d18d-d5d8-ab59-9c15-79b4093e0a51@cogentembedded.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Language: en-MW Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Geert Uytterhoeven Cc: Rob Herring , Simon Horman , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Mark Rutland , Magnus Damm List-Id: devicetree@vger.kernel.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 >> Signed-off-by: Sergei Shtylyov > > 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 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 > > 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