[lkml]   [2019]   [Dec]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 1/3] clocksource: davinci: work around a clocksource problem on dm365 SoC
    Hi Bart,

    On 13/12/19 9:54 PM, Bartosz Golaszewski wrote:
    > From: Bartosz Golaszewski <>
    > The DM365 platform has a strange quirk (only present when using ancient
    > u-boot - mainline u-boot v2013.01 and later works fine) where if we
    > enable the second half of the timer in periodic mode before we do its
    > initialization - the time won't start flowing and we can't boot.
    > When using more recent u-boot, we can enable the timer, then reinitialize
    > it and all works fine.
    > I've been unable to figure out why that is, but a workaround for this
    > is straightforward - just cache the enable bits for tim34.
    > Signed-off-by: Bartosz Golaszewski <>

    Timer Global Control Register (TGCR) has bits to reset both halves of
    timer. Does placing both halves in reset, waiting a bit (say 10ms) and
    then taking them out of reset help solve the this problem?

    Also, there are LPSCs controlling the timers. As an experiment, can you
    davinci_lpsc_clk_disable() and then doing a clk_disable() + clk_enable()
    on timer can get the timer out of this bad state.

    We need some way for Linux to start on a clean state after bootloader is
    done. And trying to reset the timer before use seems to be a better way
    to accomplish it.

    I assume the original code was just lucky in not hitting this case?


     \ /
      Last update: 2019-12-18 10:29    [W:10.016 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site