[Intel-gfx] [PATCH v5 3/3] PM/runtime:Replace jiffies based accounting with ktime based accounting

Rafael J. Wysocki rafael at kernel.org
Fri Jan 18 11:05:18 UTC 2019


On Fri, Jan 18, 2019 at 11:53 AM Vincent Guittot
<vincent.guittot at linaro.org> wrote:
>
> On Fri, 18 Jan 2019 at 11:42, Vincent Guittot
> <vincent.guittot at linaro.org> wrote:
> >
> > Hi Guenter,
> >
> > Le Thursday 17 Jan 2019 à 14:16:28 (-0800), Guenter Roeck a écrit :
> > > On Fri, Dec 21, 2018 at 11:33:56AM +0100, Vincent Guittot wrote:
> > > > From: Thara Gopinath <thara.gopinath at linaro.org>
> > > >
> > > > This patch replaces jiffies based accounting for runtime_active_time
> > > > and runtime_suspended_time with ktime base accounting. This makes the
> > > > runtime debug counters inline with genpd and other pm subsytems which
> > > > uses ktime based accounting.
> > > >
> > > > timekeeping is initialized before pm_runtime_init() so ktime_get() will
> > > > be ready before first call. In fact, timekeeping_init() is called early
> > > > in start_kernel() which is way before driver_init() (and that's when
> > > > devices can start to be initialized) called from rest_init() via
> > > > kernel_init_freeable() and do_basic_setup().
> > > >
> > > This is not (always) correct. My qemu "collie" boot test fails with this
> > > patch applied. Reverting the patch fixes the problem. Bisect log attached.
> > >
> >
> > Can you try the patch below ?
> > ktime_get_mono_fast_ns() has the advantage of being init with dummy clock so
> > it can be used at early_init.
>
> Another possibility would be delay the init of the gpiochip

Well, right.

Initializing devices before timekeeping doesn't feel particularly
robust from the design perspective.

How exactly does that happen?


More information about the Intel-gfx mailing list