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

[Thomas Gleixner]

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