[PATCH v2 3/8] timer: orion-timer: Add timer_get_boot_us() for BOOTSTAGE support

[Tony Dinh]

Hi Michael,

On Sun, Sep 4, 2022 at 1:54 AM Michael Walle <michael at walle.cc> wrote:
>
> Am 2022-09-04 02:02, schrieb Tony Dinh:
> > Hi Stefan,
> >
> > Sorry, that message was prematurely sent (fat finger). Please see the
> > continuation below.
> >
> > On Sat, Sep 3, 2022 at 4:43 PM Tony Dinh <mibodhi at gmail.com> wrote:
> >>
> >> Hi Stefan,
> >>
> >> On Sat, Sep 3, 2022 at 3:44 AM Stefan Roese <sr at denx.de> wrote:
> >> >
> >> > Hi Tony,
> >> >
> >> > On 03.09.22 11:44, Tony Dinh wrote:
> >> > > Hi Stefan,
> >> > >
> >> > > On Thu, Sep 1, 2022 at 11:25 PM Stefan Roese <sr at denx.de> wrote:
> >> > >>
> >> > >> Add timer_get_boot_us() to support boards, that have CONFIG_BOOTSTAGE
> >> > >> enabled, like pogo_v4.
> >> > >>
> >> > >> Signed-off-by: Stefan Roese <sr at denx.de>
> >> > >> ---
> >> > >> v2:
> >> > >> - Change timer_get_boot_us() to use the timer_early functions
> >> > >> - Remove #if CONFIG_IS_ENABLED(BOOTSTAGE)
> >> > >>
> >> > >> Simon, I'm currently looking into this timer_get_boot_us() to using
> >> > >> timer_early_get_count() etc consolidation.
> >> > >
> >> > > Indeed, as you've mentioned above, I think timer_early_get_count() and
> >> > > timer_early_get_rate() do need to take into consideration  what the
> >> > > input_clock_type is for Kirkwood boards with CONFIG_BOOTSTAGE such as
> >> > > the Pogo V4.
> >> > >
> >> > > I'm seeing on the Pogo V4 test, the timer command reports time about 6
> >> > > times slower than it should. It does seem to jive with the fact that
> >> > > the Pogo V4 CONFIG_SYS_TCLK is 166Mhz, versus MVEBU 25MHz clock rate.
> >> >
> >> > Ah, I've missing updating the early functions to also differentiate
> >> > between fixed clocks and TCLK timer.
> >> >
> >> > Please give the attached patch a try - should be applied on top of this
> >> > latest patchset.
> >>
> >
> > That looks promising, but I think we are still missing something.
> > After applying the attached patch, I ran the test again and it behaved
> > the same way (clock rate 6 times slower). So I did another test.
> >
> > --- Test 1
> > Pogo_V4> timer start; sleep 60; timer get; sleep 30; timer get
> > 60.000
> > 90.000
> >
> > So apparently the sleep cmd has reset the correct clock rate.
> >
> > --- Test 2
> >
> > Pogo_V4> timer start; sleep 30; timer get; sleep 30; timer get
> > 30.000
> > 60.000
> >
> > And then wait for 30 seconds, do another "timer get" (I expected to
> > see about 90 to 95 seconds).
> >
> > Pogo_V4> timer get
> > 66.237
>
> I've did the same test and can confirm it. But I think that is
> a drawback from the timer command. With a 32bit timer and a
> TCLK of 166MHz (on my board), the timer will wrap around about
> every 26s. So if you don't do a get_timer() call for that whole
> period, the overflow won't be counted in timer_conv_64().
>
> For the sleep command it works correctly, because it will
> poll get_timer() every 100us.
>
> In summary, you cannot expect a "timer get" on the console
> to work if you cannot make sure, the you call it at least
> every "2^32 / TCLK" seconds.
>
> -michael

Thanks for confirming that and the explanation. It makes perfect
sense! I think I got side tracked and never noticed that it is a
32-bit timer wrap- around :)

All the best,
Tony