Messages in this thread | | | Date | Wed, 4 Jul 2018 21:49:07 +0200 (CEST) | From | Thomas Gleixner <> | Subject | Re: [linux-sunxi] Re: [PATCH 0/2] Allwinner A64 timer workaround |
| |
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
| |