[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJZ5v0gFpK3Kqyf=RM+160A3RAQYPs3c3EgxmNH7ZceEaujEUw@mail.gmail.com>
Date: Fri, 18 Jan 2019 12:05:18 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Vincent Guittot <vincent.guittot@...aro.org>
Cc: Guenter Roeck <linux@...ck-us.net>,
"open list:THERMAL" <linux-pm@...r.kernel.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Thara Gopinath <thara.gopinath@...aro.org>,
Jani Nikula <jani.nikula@...ux.intel.com>,
Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
rodrigo.vivi@...el.com, David Airlie <airlied@...ux.ie>,
"Intel graphics driver community testing & development"
<intel-gfx@...ts.freedesktop.org>,
dri-devel <dri-devel@...ts.freedesktop.org>,
Ulf Hansson <ulf.hansson@...aro.org>
Subject: Re: [PATCH v5 3/3] PM/runtime:Replace jiffies based accounting with
ktime based accounting
On Fri, Jan 18, 2019 at 11:53 AM Vincent Guittot
<vincent.guittot@...aro.org> wrote:
>
> On Fri, 18 Jan 2019 at 11:42, Vincent Guittot
> <vincent.guittot@...aro.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@...aro.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?
Powered by blists - more mailing lists