[PATCH v2 5/8] timer: Allow delays with a 32-bit microsecond timer

[Simon Glass]

Hi Bin,

On Tue, 7 Jul 2020 at 01:09, Bin Meng <bmeng.cn at gmail.com> wrote:
>
> Hi Simon,
>
> On Sat, Jul 4, 2020 at 12:38 AM Simon Glass <sjg at chromium.org> wrote:
> >
> > The current get_timer_us() uses 64-bit arithmetic. When implementing
> > microsecond-level timeouts, 32-bits is plenty. Add a new function to
> > support this.
> >
> > Signed-off-by: Simon Glass <sjg at chromium.org>
> > ---
> >
> > (no changes since v1)
> >
> >  include/time.h | 11 +++++++++++
> >  lib/time.c     |  5 +++++
> >  2 files changed, 16 insertions(+)
> >
> > diff --git a/include/time.h b/include/time.h
> > index e99f9c8012..434e63b075 100644
> > --- a/include/time.h
> > +++ b/include/time.h
> > @@ -17,6 +17,17 @@ unsigned long get_timer(unsigned long base);
> >  unsigned long timer_get_us(void);
> >  uint64_t get_timer_us(uint64_t base);
> >
> > +/**
> > + * get_timer_us_long() - Get the number of elapsed microseconds
> > + *
> > + * This uses 32-bit arithmetic on 32-bit machines, which is enough to handle
> > + * delays of over an hour.
> > + *
> > + *@base: Base time to consider
> > + *@return elapsed time since @base
> > + */
> > +unsigned long get_timer_us_long(unsigned long base);
>
> The function name does not clear indicates this is 32-bit value
> because unsigned long is still 64-bit when building for 64-bit U-Boot.

Yes that's right. My purpose is to use the natural long time.

Shall I update the commit message?

Regards,
Simon