lkml.org 
[lkml]   [2018]   [Jul]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 0/2] Allwinner A64 timer workaround
    From
    Date
    On 04/07/2018 10:16, Marc Zyngier wrote:
    > On 03/07/18 19:42, Samuel Holland wrote:
    >> On 07/03/18 10:09, Marc Zyngier wrote:
    >>> On 11/05/18 03:27, Samuel Holland wrote:
    >>>> Hello,
    >>>>
    >>>> Several people (including me) have experienced extremely large system
    >>>> clock jumps on their A64-based devices, apparently due to the architectural
    >>>> timer going backward, which is interpreted by Linux as the timer wrapping
    >>>> around after 2^56 cycles.
    >>>>
    >>>> Investigation led to discovery of some obvious problems with this SoC's
    >>>> architectural timer, and this patch series introduces what I believe is
    >>>> the simplest workaround. More details are in the commit message for patch
    >>>> 1. Patch 2 simply enables the workaround in the device tree.
    >>>
    >>> What's the deal with this series? There was a couple of nits to address, and
    >>> I was more or less expecting a v2.
    >>
    >> I got reports that people were still occasionally having clock jumps after
    >> applying this series, so I wanted to attempt a more complete fix, but I haven't
    >> had time to do any deeper investigation. I think this series is still beneficial
    >> even if it's not a complete solution, so I'll come back with another patch on
    >> top of this if/once I get it fully fixed.
    >>
    >> I'll prepare a v2 with a bounded loop. Presumably, 3 * (max CPU Hz) / (24MHz
    >> timer) ≈ 150 should be a conservative iteration limit?
    >
    > Should be OK.
    >
    > Maxime: How do you want to deal with the documentation aspect? We need
    > an erratum number, but AFAIU the concept hasn't made it into the silicom
    > vendor's brain yet. Any chance you could come up with something that
    > uniquely identifies this?
    >
    >> Also, does this make sense to CC to stable?
    >
    > Probably not, as the HW never worked, so it is not a regression.

    If the patches fix a bug which already exist, it makes sense to
    propagated the fix back to the stable versions.


    --
    <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

    Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
    <http://twitter.com/#!/linaroorg> Twitter |
    <http://www.linaro.org/linaro-blog/> Blog

    \
     
     \ /
      Last update: 2018-07-04 10:24    [W:2.914 / U:0.424 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site