From: Andre Przywara <andre.przywara@arm.com>
To: Thomas Gleixner <tglx@linutronix.de>
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 16:43:05 +0100 [thread overview]
Message-ID: <d87ce7ad-4f85-d7c1-11d1-fa6fb6c3481b@arm.com> (raw)
In-Reply-To: <alpine.DEB.2.21.1807041704570.1752@nanos.tec.linutronix.de>
Hi,
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 ...
>> 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 ;-)
Cheers,
Andre.
[1]
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0500g/BABIGHII.html
next prev parent reply other threads:[~2018-07-04 15:43 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-11 2:27 Samuel Holland
2018-05-11 2:27 ` [PATCH 1/2] arm64: arch_timer: Workaround for Allwinner A64 timer instability Samuel Holland
2018-05-11 8:26 ` Maxime Ripard
2018-05-11 8:48 ` Marc Zyngier
2018-05-11 15:08 ` Samuel Holland
2018-05-26 15:15 ` André Przywara
2018-05-11 2:27 ` [PATCH 2/2] arm64: dts: allwinner: a64: Enable A64 timer workaround Samuel Holland
2018-05-11 9:24 ` [PATCH 0/2] Allwinner " Andre Przywara
2018-07-03 15:09 ` Marc Zyngier
2018-07-03 18:42 ` Samuel Holland
2018-07-04 8:16 ` Marc Zyngier
2018-07-04 8:19 ` Chen-Yu Tsai
2018-07-04 8:23 ` Daniel Lezcano
2018-07-04 8:39 ` Marc Zyngier
2018-07-04 10:00 ` Thomas Gleixner
2018-07-04 13:08 ` [linux-sunxi] " Andre Przywara
2018-07-04 14:31 ` Thomas Gleixner
2018-07-04 14:44 ` Andre Przywara
2018-07-04 15:01 ` Marc Zyngier
2018-07-04 15:15 ` Andre Przywara
2018-07-04 15:30 ` Marc Zyngier
2018-07-04 15:23 ` Samuel Holland
2018-07-04 15:14 ` Thomas Gleixner
2018-07-04 15:43 ` Andre Przywara [this message]
2018-07-04 19:49 ` Thomas Gleixner
2018-07-04 8:41 ` Daniel Lezcano
2018-07-12 2:23 ` Samuel Holland
2018-07-04 9:06 ` Maxime Ripard
2018-07-04 8:41 ` Daniel Lezcano
2018-07-04 12:52 ` [linux-sunxi] " Andre Przywara
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=d87ce7ad-4f85-d7c1-11d1-fa6fb6c3481b@arm.com \
--to=andre.przywara@arm.com \
--cc=Mark.Rutland@arm.com \
--cc=catalin.marinas@arm.com \
--cc=daniel.lezcano@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sunxi@googlegroups.com \
--cc=marc.zyngier@arm.com \
--cc=maxime.ripard@bootlin.com \
--cc=samuel@sholland.org \
--cc=tglx@linutronix.de \
--cc=wens@csie.org \
--cc=will.deacon@arm.com \
/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
all inboxes | Powered by JetHome®