On Fri, Sep 15, 2017 at 08:57:53AM +0000, Fabrizio Castro wrote: > Hi Simon, Geert, > > > -----Original Message----- > > From: [email protected] > > [mailto:[email protected]] On Behalf Of Geert > > Uytterhoeven > > Sent: 15 September 2017 09:05 > > To: Simon Horman <[email protected]>; Fabrizio Castro > > <[email protected]> > > Cc: Chris Paterson <[email protected]>; Rob Herring > > <[email protected]>; Mark Rutland <[email protected]>; > > Magnus Damm <[email protected]>; Russell King <[email protected]>; > > [email protected]; Linux-Renesas > > <[email protected]>; [email protected]; > > Geert Uytterhoeven <[email protected]> > > Subject: Re: [PATCH 1/8] ARM: dts: r8a7745: Add APMU node and second CPU > > core > > > > Hi Simon, Fabrizio, > > > > On Fri, Sep 15, 2017 at 9:45 AM, Simon Horman <[email protected]> wrote: > > > On Wed, Sep 13, 2017 at 06:05:34PM +0100, Chris Paterson wrote: > > >> From: Fabrizio Castro <[email protected]> > > >> > > >> Add DT node for the Advanced Power Management Unit (APMU), add the > > >> second CPU core, and use "renesas,apmu" as "enable-method". > > >> > > >> Signed-off-by: Fabrizio Castro <[email protected]> > > >> Signed-off-by: Chris Paterson <[email protected]> > > >> --- > > >> This patch is based on renesas-devel-20170913-v4.13. > > > > > > Hi, > > > > > > with reference to "[PATCH v3 0/3] ARM: renesas: Enable SMP on R-Car E2" > > > is the CNTVOFF initialised in the boot loader of boards (in upstream) > > > for this SoC? If not I expect you will have trouble with the arch timer > > > on secondary CPU cores. > > I can confirm that this patch relies on: > * "ARM: Add definition for monitor mode", and > * "ARM: shmobile: rcar-gen2: Make sure CNTVOFF is initialized on CA7/15 " > as the bootloader doesn't initialize CNTVOFF. > > > > > Exactly my question. > > > > Fabrizio: Given your feedback on "[PATCH v3 0/3] ARM: renesas: Enable SMP on > > R-Car E2", I think SMP enablement on RZ/G1E has to be postponed until "ARM: > > shmobile: rcar-gen2: Make sure CNTVOFF is initialized on CA7/15" has been > > accepted upstream. > > You are right, somehow we missed the comment made by Simon on Monday: > > " I would like to deffer the third and last patch until v4.16 to avoid > an awkward branch dependency on the above - the branches are different > even though the tree is the same. Please resubmit this patch once the > above dependencies are present in an rc release, which at this stage > I expect to be v4.15-rc1." > > Apologies for this, we will send this patch later on, once both patches have > been > accepted upstream.
No problem, I will mark this one as deferred. > Simon, is this going to make the application of the remaining patches > problematic? Please, let me (or Chris) know if you want us to rebase and > resend without this patch. No, I don't think you need to rebase and repost due to this.
