On Fri, Jan 18, 2019 at 11:53 AM Vincent Guittot <vincent.guittot@xxxxxxxxxx> wrote: > > On Fri, 18 Jan 2019 at 11:42, Vincent Guittot > <vincent.guittot@xxxxxxxxxx> 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@xxxxxxxxxx> > > > > > > > > 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? _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
