devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vincent Whitchurch <vincent.whitchurch@axis.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Cc: "tglx@linutronix.de" <tglx@linutronix.de>,
	"daniel.lezcano@linaro.org" <daniel.lezcano@linaro.org>,
	kernel <kernel@axis.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-samsung-soc@vger.kernel.org" 
	<linux-samsung-soc@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"alim.akhtar@samsung.com" <alim.akhtar@samsung.com>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>
Subject: Re: [PATCH v2 3/4] clocksource/drivers/exynos_mct: Support local-timer-index property
Date: Fri, 11 Mar 2022 12:35:43 +0100	[thread overview]
Message-ID: <20220311113543.GA17877@axis.com> (raw)
In-Reply-To: <226dcb1b-d141-f0d3-68c4-11d2466ca571@canonical.com>

On Tue, Mar 08, 2022 at 03:57:55PM +0100, Krzysztof Kozlowski wrote:
> On 08/03/2022 15:24, Vincent Whitchurch wrote:
> > diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
> > index f29c812b70c9..5f8b516614eb 100644
> > --- a/drivers/clocksource/exynos_mct.c
> > +++ b/drivers/clocksource/exynos_mct.c
> > @@ -33,7 +33,7 @@
> >  #define EXYNOS4_MCT_G_INT_ENB		EXYNOS4_MCTREG(0x248)
> >  #define EXYNOS4_MCT_G_WSTAT		EXYNOS4_MCTREG(0x24C)
> >  #define _EXYNOS4_MCT_L_BASE		EXYNOS4_MCTREG(0x300)
> > -#define EXYNOS4_MCT_L_BASE(x)		(_EXYNOS4_MCT_L_BASE + (0x100 * x))
> > +#define EXYNOS4_MCT_L_BASE(x)		(_EXYNOS4_MCT_L_BASE + (0x100 * (x)))
> >  #define EXYNOS4_MCT_L_MASK		(0xffffff00)
> >  
> >  #define MCT_L_TCNTB_OFFSET		(0x00)
> > @@ -75,6 +75,7 @@ enum {
> >  static void __iomem *reg_base;
> >  static unsigned long clk_rate;
> >  static unsigned int mct_int_type;
> > +static unsigned int mct_local_idx;
> 
> No more static variables. This was wrong design, happens, but let's not
> grow the list.
> 
> I propose to conditionally (depending on property samsung,frc-shared)
> assign .resume callback to NULL or exynos4_frc_resume. The init can
> receive an argument whether to call frc_start().

Could we just add the skip-write-register-if-already-started change in
exynos4_mct_frc_start() uncondtionally?  Perhaps it could be in a
separate patch too?  I was probably being over-cautious when I did it
conditionally on mct_local_idx.  Doing it uncondtionally would make it
easier to remove the global variable.

On my system the FRC is actually started long before Linux, and I assume
it's similar on other chips.

> 
> >  static int mct_irqs[MCT_NR_IRQS];
> >  
> >  struct mct_clock_event_device {
> > @@ -157,6 +158,17 @@ static void exynos4_mct_frc_start(void)
> >  	u32 reg;
> >  
> >  	reg = readl_relaxed(reg_base + EXYNOS4_MCT_G_TCON);
> > +
> > +	/*
> > +	 * If the FRC is already running, we don't need to start it again.  We
> > +	 * could probably just do this on all systems, but, to avoid any risk
> > +	 * for regressions, we only do it on systems where it's absolutely
> > +	 * necessary (i.e., on systems where writes to the global registers
> > +	 * need to be avoided).
> > +	 */
> > +	if (mct_local_idx && (reg & MCT_G_TCON_START))
> 
> This contradicts your intentions in commit #2 msg, where you described
> that A53 will be started first.

Yes, you're right.  The case of the FRC not being running when the A5
starts up is only ever hit in our simulation environment where we are
able to start Linux on the A5 directly, without having to go via the
A53.

> 1. If A53 is always started first, is it possible to be here from A5?
> 2. If above is possible, how do you handle locking? For example:
> a. A53 started with some delay, entered exynos4_mct_frc_start() pass
> this check;
> b. A5 gets to exynos4_mct_frc_start(), check is still false, so A5
> enables the FRC,
> c. A53 also enables the FRC.

The A5 is normally started from Linux on the A53 (using the remoteproc
framework).  This is long after exynos4_mct_frc_start() has been called
on the A53.

  reply	other threads:[~2022-03-11 11:35 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-08 14:24 [PATCH v2 0/4] clocksource: Add MCT support for ARTPEC-8 Vincent Whitchurch
2022-03-08 14:24 ` [PATCH v2 1/4] dt-bindings: timer: exynos4210-mct: Add ARTPEC-8 MCT Vincent Whitchurch
2022-03-08 14:37   ` Krzysztof Kozlowski
2022-03-08 14:24 ` [PATCH v2 2/4] dt-bindings: timer: exynos4210-mct: Support using only local timer Vincent Whitchurch
2022-03-08 14:44   ` Krzysztof Kozlowski
2022-03-08 14:24 ` [PATCH v2 3/4] clocksource/drivers/exynos_mct: Support local-timer-index property Vincent Whitchurch
2022-03-08 14:57   ` Krzysztof Kozlowski
2022-03-11 11:35     ` Vincent Whitchurch [this message]
2022-03-11 12:51       ` Krzysztof Kozlowski
2022-03-21  8:00         ` Marek Szyprowski
2022-03-30  8:21           ` Vincent Whitchurch
2022-04-07  7:48             ` Vincent Whitchurch
2022-03-08 14:24 ` [PATCH v2 4/4] clocksource/drivers/exynos_mct: Enable building on ARTPEC Vincent Whitchurch
2022-03-08 14:58   ` Krzysztof Kozlowski

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=20220311113543.GA17877@axis.com \
    --to=vincent.whitchurch@axis.com \
    --cc=alim.akhtar@samsung.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=kernel@axis.com \
    --cc=krzysztof.kozlowski@canonical.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=tglx@linutronix.de \
    /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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).