From: "Mylène Josserand" <mylene.josserand@bootlin.com> To: Chen-Yu Tsai <wens@csie.org> Cc: Maxime Ripard <maxime.ripard@bootlin.com>, Russell King <linux@armlinux.org.uk>, Rob Herring <robh+dt@kernel.org>, Mark Rutland <mark.rutland@arm.com>, devicetree <devicetree@vger.kernel.org>, linux-arm-kernel <linux-arm-kernel@lists.infradead.org>, linux-kernel <linux-kernel@vger.kernel.org>, LABBE Corentin <clabbe.montjoie@gmail.com>, Thomas Petazzoni <thomas.petazzoni@bootlin.com>, quentin.schulz@bootlin.com Subject: Re: [PATCH v4 10/10] ARM: sunxi: smp: Add initialization of CNTVOFF Date: Mon, 5 Mar 2018 08:51:48 +0100 [thread overview] Message-ID: <20180305085148.1de2a99c@dell-desktop.home> (raw) In-Reply-To: <CAGb2v64SaBR-_nL9S20eXe57r_kJTiqSg-di=_mZrv3Yx2-2JA@mail.gmail.com> Hello, On Mon, 26 Feb 2018 18:25:10 +0800 Chen-Yu Tsai <wens@csie.org> wrote: > On Mon, Feb 26, 2018 at 6:12 PM, Maxime Ripard > <maxime.ripard@bootlin.com> wrote: > > On Sat, Feb 24, 2018 at 12:17:13AM +0800, Chen-Yu Tsai wrote: > >> On Fri, Feb 23, 2018 at 9:37 PM, Mylène Josserand > >> <mylene.josserand@bootlin.com> wrote: > >> > On Cortex-A7, the CNTVOFF register from arch timer is uninitialized. > >> > It should be done by the bootloader but it is currently not the case, > >> > even for boot CPU because this SoC is booting in secure mode. > >> > It leads to an random offset value meaning that each CPU will have a > >> > different time, which isn't working very well. > >> > > >> > Add assembly code used for boot CPU and secondary CPU cores to make > >> > sure that the CNTVOFF register is initialized. > >> > > >> > Signed-off-by: Mylène Josserand <mylene.josserand@bootlin.com> > >> > --- > >> > arch/arm/mach-sunxi/headsmp.S | 21 +++++++++++++++++++++ > >> > arch/arm/mach-sunxi/sunxi.c | 4 ++++ > >> > 2 files changed, 25 insertions(+) > >> > > >> > diff --git a/arch/arm/mach-sunxi/headsmp.S b/arch/arm/mach-sunxi/headsmp.S > >> > index d5c97e945e69..605896251927 100644 > >> > --- a/arch/arm/mach-sunxi/headsmp.S > >> > +++ b/arch/arm/mach-sunxi/headsmp.S > >> > @@ -65,9 +65,30 @@ ENTRY(sunxi_mc_smp_cluster_cache_enable) > >> > first: .word sunxi_mc_smp_first_comer - . > >> > ENDPROC(sunxi_mc_smp_cluster_cache_enable) > >> > > >> > +ENTRY(sunxi_init_cntvoff) > >> > + /* > >> > + * CNTVOFF has to be initialized either from non-secure Hypervisor > >> > + * mode or secure Monitor mode with SCR.NS==1. If TrustZone is enabled > >> > + * then it should be handled by the secure code > >> > + */ > >> > + cps #MON_MODE > >> > + mrc p15, 0, r1, c1, c1, 0 /* Get Secure Config */ > >> > + orr r0, r1, #1 > >> > + mcr p15, 0, r0, c1, c1, 0 /* Set Non Secure bit */ > >> > + instr_sync > >> > + mov r0, #0 > >> > + mcrr p15, 4, r0, r0, c14 /* CNTVOFF = 0 */ > >> > + instr_sync > >> > + mcr p15, 0, r1, c1, c1, 0 /* Set Secure bit */ > >> > + instr_sync > >> > + cps #SVC_MODE > >> > + ret lr > >> > +ENDPROC(sunxi_init_cntvoff) > >> > >> There is no need to move all the assembly into a separate file, just > >> to add this function. Everything can be inlined as a naked function. > >> The "instr_sync" macro can be replaced with "isb", which is what it > >> expands to anyway. > >> > >> I really want to keep everything self-contained without global symbols, > >> and in C files if possible. > > > > What is the rationale for keeping it in C files (beside the global > > symbols)? Because the syntax is quite ugly, and it's much easier to > > read, review and amend using a separate file. > > Global symbols and keeping everything in one place I guess. > This symbol would be used in a few places, so I suppose having it > in a separate assembly file would be OK. Okay so I will keep it in a separate file. > > >> > #ifdef CONFIG_SMP > >> > ENTRY(sunxi_boot) > >> > bl sunxi_mc_smp_cluster_cache_enable > >> > + bl sunxi_init_cntvoff > >> > b secondary_startup > >> > ENDPROC(sunxi_boot) > >> > > >> > diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c > >> > index 5e9602ce1573..4bb041492b54 100644 > >> > --- a/arch/arm/mach-sunxi/sunxi.c > >> > +++ b/arch/arm/mach-sunxi/sunxi.c > >> > @@ -37,8 +37,12 @@ static const char * const sun6i_board_dt_compat[] = { > >> > }; > >> > > >> > extern void __init sun6i_reset_init(void); > >> > +extern void sunxi_init_cntvoff(void); > >> > + > >> > static void __init sun6i_timer_init(void) > >> > { > >> > + sunxi_init_cntvoff(); > >> > >> You should check the enable-method to see if PSCI is set or not, > >> as an indicator whether the kernel is booted secure or non-secure. > > > > It's an indicator, but it's not really a perfect one. You could very > > well have your kernel booted in non-secure, without PSCI. Or even with > > PSCI, but without the SMP ops. > > > > We have a quite big number of these cases already, where, depending on > > the configuration, we might not have access to the device we write to, > > the number of hacks to just enable that device for non-secure is a > > good example of that. > > I wouldn't consider them hacks though. The hardware gives the option > to have control of many devices delegated solely to secure-only, or > secure/non-secure. Our present model is to support everything we can > in Linux directly, instead of through some firmware interface to a > non-existent firmware. I am not sure to understand what is the conclusion about it. Should I use "psci"/enable-method or should I use another mechanism to detect we are in secure/non-secure (if it exists)? Otherwise, for the moment, I can use machine-compatible on sun8i-a83t and we will see later how we can handle it in a better way. Thank you in advance, Best regards, Mylène -- Mylène Josserand, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering http://bootlin.com > > ChenYu > > >> AFAIK trying to set CNTVOFF under non-secure would be very bad. > > > > Just like any other access we do :/ > > > > Maxime > > > > -- > > Maxime Ripard, Bootlin (formerly Free Electrons) > > Embedded Linux and Kernel engineering > > https://bootlin.com
WARNING: multiple messages have this Message-ID (diff)
From: mylene.josserand@bootlin.com (Mylène Josserand) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v4 10/10] ARM: sunxi: smp: Add initialization of CNTVOFF Date: Mon, 5 Mar 2018 08:51:48 +0100 [thread overview] Message-ID: <20180305085148.1de2a99c@dell-desktop.home> (raw) In-Reply-To: <CAGb2v64SaBR-_nL9S20eXe57r_kJTiqSg-di=_mZrv3Yx2-2JA@mail.gmail.com> Hello, On Mon, 26 Feb 2018 18:25:10 +0800 Chen-Yu Tsai <wens@csie.org> wrote: > On Mon, Feb 26, 2018 at 6:12 PM, Maxime Ripard > <maxime.ripard@bootlin.com> wrote: > > On Sat, Feb 24, 2018 at 12:17:13AM +0800, Chen-Yu Tsai wrote: > >> On Fri, Feb 23, 2018 at 9:37 PM, Myl?ne Josserand > >> <mylene.josserand@bootlin.com> wrote: > >> > On Cortex-A7, the CNTVOFF register from arch timer is uninitialized. > >> > It should be done by the bootloader but it is currently not the case, > >> > even for boot CPU because this SoC is booting in secure mode. > >> > It leads to an random offset value meaning that each CPU will have a > >> > different time, which isn't working very well. > >> > > >> > Add assembly code used for boot CPU and secondary CPU cores to make > >> > sure that the CNTVOFF register is initialized. > >> > > >> > Signed-off-by: Myl?ne Josserand <mylene.josserand@bootlin.com> > >> > --- > >> > arch/arm/mach-sunxi/headsmp.S | 21 +++++++++++++++++++++ > >> > arch/arm/mach-sunxi/sunxi.c | 4 ++++ > >> > 2 files changed, 25 insertions(+) > >> > > >> > diff --git a/arch/arm/mach-sunxi/headsmp.S b/arch/arm/mach-sunxi/headsmp.S > >> > index d5c97e945e69..605896251927 100644 > >> > --- a/arch/arm/mach-sunxi/headsmp.S > >> > +++ b/arch/arm/mach-sunxi/headsmp.S > >> > @@ -65,9 +65,30 @@ ENTRY(sunxi_mc_smp_cluster_cache_enable) > >> > first: .word sunxi_mc_smp_first_comer - . > >> > ENDPROC(sunxi_mc_smp_cluster_cache_enable) > >> > > >> > +ENTRY(sunxi_init_cntvoff) > >> > + /* > >> > + * CNTVOFF has to be initialized either from non-secure Hypervisor > >> > + * mode or secure Monitor mode with SCR.NS==1. If TrustZone is enabled > >> > + * then it should be handled by the secure code > >> > + */ > >> > + cps #MON_MODE > >> > + mrc p15, 0, r1, c1, c1, 0 /* Get Secure Config */ > >> > + orr r0, r1, #1 > >> > + mcr p15, 0, r0, c1, c1, 0 /* Set Non Secure bit */ > >> > + instr_sync > >> > + mov r0, #0 > >> > + mcrr p15, 4, r0, r0, c14 /* CNTVOFF = 0 */ > >> > + instr_sync > >> > + mcr p15, 0, r1, c1, c1, 0 /* Set Secure bit */ > >> > + instr_sync > >> > + cps #SVC_MODE > >> > + ret lr > >> > +ENDPROC(sunxi_init_cntvoff) > >> > >> There is no need to move all the assembly into a separate file, just > >> to add this function. Everything can be inlined as a naked function. > >> The "instr_sync" macro can be replaced with "isb", which is what it > >> expands to anyway. > >> > >> I really want to keep everything self-contained without global symbols, > >> and in C files if possible. > > > > What is the rationale for keeping it in C files (beside the global > > symbols)? Because the syntax is quite ugly, and it's much easier to > > read, review and amend using a separate file. > > Global symbols and keeping everything in one place I guess. > This symbol would be used in a few places, so I suppose having it > in a separate assembly file would be OK. Okay so I will keep it in a separate file. > > >> > #ifdef CONFIG_SMP > >> > ENTRY(sunxi_boot) > >> > bl sunxi_mc_smp_cluster_cache_enable > >> > + bl sunxi_init_cntvoff > >> > b secondary_startup > >> > ENDPROC(sunxi_boot) > >> > > >> > diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c > >> > index 5e9602ce1573..4bb041492b54 100644 > >> > --- a/arch/arm/mach-sunxi/sunxi.c > >> > +++ b/arch/arm/mach-sunxi/sunxi.c > >> > @@ -37,8 +37,12 @@ static const char * const sun6i_board_dt_compat[] = { > >> > }; > >> > > >> > extern void __init sun6i_reset_init(void); > >> > +extern void sunxi_init_cntvoff(void); > >> > + > >> > static void __init sun6i_timer_init(void) > >> > { > >> > + sunxi_init_cntvoff(); > >> > >> You should check the enable-method to see if PSCI is set or not, > >> as an indicator whether the kernel is booted secure or non-secure. > > > > It's an indicator, but it's not really a perfect one. You could very > > well have your kernel booted in non-secure, without PSCI. Or even with > > PSCI, but without the SMP ops. > > > > We have a quite big number of these cases already, where, depending on > > the configuration, we might not have access to the device we write to, > > the number of hacks to just enable that device for non-secure is a > > good example of that. > > I wouldn't consider them hacks though. The hardware gives the option > to have control of many devices delegated solely to secure-only, or > secure/non-secure. Our present model is to support everything we can > in Linux directly, instead of through some firmware interface to a > non-existent firmware. I am not sure to understand what is the conclusion about it. Should I use "psci"/enable-method or should I use another mechanism to detect we are in secure/non-secure (if it exists)? Otherwise, for the moment, I can use machine-compatible on sun8i-a83t and we will see later how we can handle it in a better way. Thank you in advance, Best regards, Myl?ne -- Myl?ne Josserand, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering http://bootlin.com > > ChenYu > > >> AFAIK trying to set CNTVOFF under non-secure would be very bad. > > > > Just like any other access we do :/ > > > > Maxime > > > > -- > > Maxime Ripard, Bootlin (formerly Free Electrons) > > Embedded Linux and Kernel engineering > > https://bootlin.com
next prev parent reply other threads:[~2018-03-05 7:51 UTC|newest] Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-02-23 13:37 [PATCH v4 00/10] Sunxi: Add SMP support on A83T Mylène Josserand 2018-02-23 13:37 ` Mylène Josserand 2018-02-23 13:37 ` Mylène Josserand 2018-02-23 13:37 ` [PATCH v4 01/10] ARM: sun9i: smp: Add sun9i dt parsing function Mylène Josserand 2018-02-23 13:37 ` Mylène Josserand 2018-02-23 13:37 ` Mylène Josserand 2018-02-23 14:54 ` Maxime Ripard 2018-02-23 14:54 ` Maxime Ripard 2018-02-23 14:54 ` Maxime Ripard 2018-02-25 15:19 ` Mylène Josserand 2018-02-25 15:19 ` Mylène Josserand 2018-02-25 15:19 ` Mylène Josserand 2018-02-23 13:37 ` [PATCH v4 02/10] ARM: sun9i: smp: Rename clusters's power-off register Mylène Josserand 2018-02-23 13:37 ` Mylène Josserand 2018-02-23 13:37 ` Mylène Josserand 2018-02-23 14:56 ` Maxime Ripard 2018-02-23 14:56 ` Maxime Ripard 2018-02-23 14:56 ` Maxime Ripard 2018-02-25 15:20 ` Mylène Josserand 2018-02-25 15:20 ` Mylène Josserand 2018-02-25 15:20 ` Mylène Josserand 2018-02-23 13:37 ` [PATCH v4 03/10] ARM: sun8i: smp: Add support for A83T Mylène Josserand 2018-02-23 13:37 ` Mylène Josserand 2018-02-23 13:37 ` Mylène Josserand 2018-02-23 15:03 ` Maxime Ripard 2018-02-23 15:03 ` Maxime Ripard 2018-02-23 15:03 ` Maxime Ripard 2018-02-25 15:25 ` Mylène Josserand 2018-02-25 15:25 ` Mylène Josserand 2018-02-25 15:25 ` Mylène Josserand 2018-02-23 13:37 ` [PATCH v4 04/10] ARM: sun8i: smp: Add hotplug support for sun8i-a83t Mylène Josserand 2018-02-23 13:37 ` Mylène Josserand 2018-02-23 13:37 ` Mylène Josserand 2018-02-23 13:37 ` [PATCH v4 05/10] ARM: dts: sun8i: Add CPUCFG device node for A83T dtsi Mylène Josserand 2018-02-23 13:37 ` Mylène Josserand 2018-02-23 13:37 ` Mylène Josserand 2018-02-23 13:37 ` [PATCH v4 06/10] ARM: dts: sun8i: Add R_CPUCFG device node for the " Mylène Josserand 2018-02-23 13:37 ` Mylène Josserand 2018-02-23 13:37 ` Mylène Josserand 2018-02-23 13:37 ` [PATCH v4 07/10] ARM: dts: sun8i: a83t: Add CCI-400 node Mylène Josserand 2018-02-23 13:37 ` Mylène Josserand 2018-02-23 13:37 ` Mylène Josserand 2018-02-23 13:37 ` [PATCH v4 08/10] ARM: sunxi: smp: Move assembly code into a file Mylène Josserand 2018-02-23 13:37 ` Mylène Josserand 2018-02-23 13:37 ` Mylène Josserand 2018-02-23 15:09 ` Maxime Ripard 2018-02-23 15:09 ` Maxime Ripard 2018-02-23 15:09 ` Maxime Ripard 2018-03-01 8:21 ` Mylène Josserand 2018-03-01 8:21 ` Mylène Josserand 2018-02-26 6:22 ` kbuild test robot 2018-02-26 6:22 ` kbuild test robot 2018-02-26 6:22 ` kbuild test robot 2018-02-23 13:37 ` [PATCH v4 09/10] ARM: sunxi: smp: Move cpu_resume assembly entry into file Mylène Josserand 2018-02-23 13:37 ` Mylène Josserand 2018-02-23 13:37 ` Mylène Josserand 2018-02-23 13:37 ` [PATCH v4 10/10] ARM: sunxi: smp: Add initialization of CNTVOFF Mylène Josserand 2018-02-23 13:37 ` Mylène Josserand 2018-02-23 13:37 ` Mylène Josserand 2018-02-23 15:12 ` Maxime Ripard 2018-02-23 15:12 ` Maxime Ripard 2018-02-23 15:12 ` Maxime Ripard 2018-02-23 16:17 ` Chen-Yu Tsai 2018-02-23 16:17 ` Chen-Yu Tsai 2018-02-23 16:17 ` Chen-Yu Tsai 2018-02-26 10:12 ` Maxime Ripard 2018-02-26 10:12 ` Maxime Ripard 2018-02-26 10:25 ` Chen-Yu Tsai 2018-02-26 10:25 ` Chen-Yu Tsai 2018-03-05 7:51 ` Mylène Josserand [this message] 2018-03-05 7:51 ` Mylène Josserand 2018-03-05 8:31 ` Maxime Ripard 2018-03-05 8:31 ` Maxime Ripard 2018-03-05 13:51 ` Mylène Josserand 2018-03-05 13:51 ` Mylène Josserand 2018-03-07 12:09 ` Marc Zyngier 2018-03-07 12:09 ` Marc Zyngier 2018-03-07 12:18 ` Marc Zyngier 2018-03-07 12:18 ` Marc Zyngier 2018-03-18 19:07 ` Mylène Josserand 2018-03-18 19:07 ` Mylène Josserand 2018-03-19 2:14 ` Chen-Yu Tsai 2018-03-19 2:14 ` Chen-Yu Tsai 2018-03-19 13:55 ` Maxime Ripard 2018-03-19 13:55 ` Maxime Ripard 2018-03-19 9:21 ` Marc Zyngier 2018-03-19 9:21 ` Marc Zyngier 2018-03-19 10:59 ` Maxime Ripard 2018-03-19 10:59 ` Maxime Ripard
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20180305085148.1de2a99c@dell-desktop.home \ --to=mylene.josserand@bootlin.com \ --cc=clabbe.montjoie@gmail.com \ --cc=devicetree@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@armlinux.org.uk \ --cc=mark.rutland@arm.com \ --cc=maxime.ripard@bootlin.com \ --cc=quentin.schulz@bootlin.com \ --cc=robh+dt@kernel.org \ --cc=thomas.petazzoni@bootlin.com \ --cc=wens@csie.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.