Messages in this thread |  | | Subject | Re: [PATCH 1/3] clocksource: davinci: work around a clocksource problem on dm365 SoC | From | Sekhar Nori <> | Date | Wed, 18 Dec 2019 14:58:07 +0530 |
| |
Hi Bart,
On 13/12/19 9:54 PM, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski <bgolaszewski@baylibre.com> > > 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 <bgolaszewski@baylibre.com>
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 see if using LPSC_STATE_SWRSTDISABLE instead of LPSC_STATE_DISABLE in 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?
Thanks, Sekhar
|  |