Re: [linux-sunxi] Re: [PATCH 0/2] Allwinner A64 timer workaround

From: Thomas Gleixner <tglx@linutronix.de>
To: Andre Przywara <andre.przywara@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	Samuel Holland <samuel@sholland.org>,
	Maxime Ripard <maxime.ripard@bootlin.com>,
	Chen-Yu Tsai <wens@csie.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-sunxi@googlegroups.com,
	Mark Rutland <Mark.Rutland@arm.com>
Subject: Re: [linux-sunxi] Re: [PATCH 0/2] Allwinner A64 timer workaround
Date: Wed, 4 Jul 2018 21:49:07 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.21.1807042141440.28271@nanos.tec.linutronix.de> (raw)
In-Reply-To: <d87ce7ad-4f85-d7c1-11d1-fa6fb6c3481b@arm.com>

On Wed, 4 Jul 2018, Andre Przywara wrote:
> On 04/07/18 16:14, Thomas Gleixner wrote:
> > On Wed, 4 Jul 2018, Andre Przywara wrote:
> >> On 04/07/18 15:31, Thomas Gleixner wrote:
> >>> If that's the case then you need to find a different functional timer for
> >>> time keeping. Having an erratic behaving timer for time keeping is not an
> >>> option at all.
> >>
> >> That's not an option on arm64. There are other usable time sources in
> >> the SoC, but the arch timer is somewhat mandatory for all practical
> >> purposes on arm64. We rely on it in some many places that it's not
> >> feasible to run without it. That's why we call it "architected" timer
> >> after all ;-)
> > 
> > The argument that it has to be used just because someone defined it as
> > 'architected' is bullshit and doesn't change the fact that it's broken and
> > not usable for timekeeping. There is no wiggle room. Either it works or
> > not, but works mostly is not an option.
> 
> The "architected" part of the arch timer is fine, it's just that
> eventually someone has to implement that at some point. And as you
> mention below, this is where Murphy's law is kicking in ;-) Especially
> for such seemingly simple tasks as connecting a counter in the "uncore"
> part of the chip (Allwinner SoC) to the counter register interface in
> the core (ARM Cortex-A53) [1]. Apparently the propagation is not really
> atomic for all bits here ...

I've immediately spotted the fail in that document:

  The Cortex-A53 processor does not include the system counter. This
  resides in the SoC.

> >> But I am quite confident that we can find a correct workaround. Maybe
> >> it's really the TVAL (the downcounter) write which is the culprit here,
> >> since the hardware actually writes "now() + TVAL" into the CVAL
> >> (upcounter) register. This internal counter access may be flawed as well.
> > 
> > If the write to the event device is wreckaging the counter which provides
> > time, then there is something seriously wrong either in the design or in
> > that particular piece of silicon.
> 
> Apologies, that was my lousy wording: There is one 64-bit comparison
> register (CVAL), which signals when the counter (an independent
> register) is greater or equal. TVAL is just a different *view* of that
> same relation. So this part is fine, it's really that the "strictly
> monotonic counter" nature of CNTPCT is not really observed by the chip.
> 
> > Yet another proof for the theory that timers are implemented by janitors
> > and that silicon/IP vendors have a competition running who can create the
> > most subtly broken timers. Intel surely had a head start with that, but ARM
> > is definitely catching up.
> 
> ARM is trying really hard to be actually better ;-)

Better in terms of subtle brokenness? I surely can do consulting for
that. I've seen most of it in all colours, but I surely can come up with
new even subtler ways to wreckage them. You know how to reach me.

Thanks,

	tglx