On Tue, 5 Feb 2019 at 14:24, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote: > > Hi Ulf, > > On Wed, Jan 30, 2019 at 1:15 PM Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: > > On Wed, 30 Jan 2019 at 12:16, Vincent Guittot > > <vincent.guittot@xxxxxxxxxx> wrote: > > > > > > A deadlock has been seen when swicthing clocksources which use PM runtime. > > > The call path is: > > > change_clocksource > > > ... > > > write_seqcount_begin > > > ... > > > timekeeping_update > > > ... > > > sh_cmt_clocksource_enable > > > ... > > > rpm_resume > > > > Hmm, isn't this already a problem in genpd then? > > > > In genpd's ->runtime_resume() callback (genpd_runtime_resume()) we > > call ktime_get() to measure the latency of running the callback. > > > > Or, perhaps irq_safe_dev_in_no_sleep_domain() returns true for the > > genpd + device in question, which means the ktime thingy is skipped. > > > > Geert? > > Correct. After adding > > dev_info(dev, "%s: pm_runtime_is_irq_safe = %d, > genpd_is_irq_safe(%s) = %d => %s\n", __func__, > pm_runtime_is_irq_safe(dev), genpd->name, genpd_is_irq_safe(genpd), > ret ? "true" : "false"); > > I see on R-Car M2-W: > > sh_cmt ffca0000.timer: irq_safe_dev_in_no_sleep_domain: > pm_runtime_is_irq_safe = 1, genpd_is_irq_safe(always-on) = 0 => true > > For all other devices, the result is false. Thanks for confirming! I guess we have been lucky so far. Anyway, if runtime PM core converts to use ktime_get_mono_fast_ns(), we should probably consider to convert genpd to this as well. Don't you think? Kind regards Uffe
