Messages in this thread | | | Date | Wed, 4 Jul 2018 16:31:04 +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 11:00, Thomas Gleixner wrote: > > On Wed, 4 Jul 2018, Marc Zyngier wrote: > >> On 04/07/18 09:23, Daniel Lezcano wrote: > >>> > >>> If the patches fix a bug which already exist, it makes sense to > >>> propagated the fix back to the stable versions. > >> > >> That's your call, but I'm not supportive of that decision, specially as > >> we have information from the person developing the workaround that this > >> doesn't fully address the issue. > > > > The patches should not be applied at all. Simply because they don't fix the > > issue completely. > > > > From a quick glance at various links and information about this, this very > > much smells like the FSL_ERRATUM_A008585. > > Has that been tried? It looks way more robust than the magic 11 bit > > crystal ball logic. > > The Freescale erratum is similar, but not identical [1]. > It seems like the A64 is less variable, so we can use a cheaper > workaround, which gets away with normally just one sysreg read. But then > again the newer error reports may actually suggest otherwise ... > > And as it currently stands, the Freescale erratum has the drawback of > relying on the CPU running much faster than the timer. The A64 can run > at 24 MHz (for power savings, or possibly during DVFS transitions), > which is the timer frequency. So subsequent counter reads will never > return the same value and the workaround times out.
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.
Thanks,
tglx
| |