From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753762AbdJaSHd (ORCPT ); Tue, 31 Oct 2017 14:07:33 -0400 Received: from mail-qt0-f196.google.com ([209.85.216.196]:48214 "EHLO mail-qt0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751295AbdJaSHa (ORCPT ); Tue, 31 Oct 2017 14:07:30 -0400 X-Google-Smtp-Source: ABhQp+RmM9sSe76H44oxFtGcjunG1hCfTmZIcA+4KIZ0ej7mWTe40/xK0j/ul/ePowY4Ap6hY7Gku35pPO2IKiSAto8= MIME-Version: 1.0 In-Reply-To: References: <1509347446-26105-1-git-send-email-t-kristo@ti.com> <3227682.nATp9NGxKU@aspire.rjw.lan> From: Geert Uytterhoeven Date: Tue, 31 Oct 2017 19:07:29 +0100 X-Google-Sender-Auth: uqS_FTTc5A1rAAofn8v7GP_1Xt8 Message-ID: Subject: Re: [PATCH] PM / QoS: Fix default runtime_pm device resume latency To: "Rafael J. Wysocki" Cc: "Rafael J. Wysocki" , Tero Kristo , Linux PM , Linux Kernel Mailing List , Linux-Renesas , Laurent Pinchart , DRI Development Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Rafael, On Tue, Oct 31, 2017 at 6:22 PM, Rafael J. Wysocki wrote: > On Tue, Oct 31, 2017 at 2:55 PM, Geert Uytterhoeven > wrote: >> Hi Rafael, Tero, >> >> CC pinchartl, dri-devel >> >> On Tue, Oct 31, 2017 at 2:10 PM, Geert Uytterhoeven >> wrote: >>> CC linux-renesas-soc >>> >>> On Tue, Oct 31, 2017 at 2:09 PM, Geert Uytterhoeven >>> wrote: >>>> On Tue, Oct 31, 2017 at 12:27 AM, Rafael J. Wysocki wrote: >>>>> On Monday, October 30, 2017 11:19:08 AM CET Rafael J. Wysocki wrote: >>>>>> On Mon, Oct 30, 2017 at 8:10 AM, Tero Kristo wrote: >>>>>> > The recent change to the PM QoS framework to introduce a proper >>>>>> > no constraint value overlooked to handle the devices which don't >>>>>> > implement PM QoS OPS. Runtime PM is one of the more severely >>>>>> > impacted subsystems, failing every attempt to runtime suspend >>>>>> > a device. This leads into some nasty second level issues like >>>>>> > probe failures and increased power consumption among other things. >>>>>> >>>>>> Oh, that's bad. >>>>>> >>>>>> Sorry about breaking it and thanks for the fix! >>>>>> >>>>>> > Fix this by adding a proper return value for devices that don't >>>>>> > implement PM QoS implicitly. >>>>>> > >>>>>> > Fixes: 0cc2b4e5a020 ("PM / QoS: Fix device resume latency PM QoS") >>>>>> > Signed-off-by: Tero Kristo >>>>>> > Cc: Rafael J. Wysocki >>>>>> >>>>>> Applied. >>>>> >>>>> And pushed to Linus. >>>> >>>> I'm afraid it is not sufficient. >>>> >>>> Commit 0cc2b4e5a020fc7f ("PM / QoS: Fix device resume latency PM QoS") >>>> introduced two issues on Renesas platforms: >>>> 1. After boot up, many devices have changed their state from "suspended" >>>> to "active", according to /sys/kernel/debug/pm_genpd/pm_genpd_summary >>>> (comparing that file across boots is one of my standard tests). >>>> Interestingly, doing a system suspend/resume cycle restores their state >>>> to "suspended". >>>> >>>> 2. During system suspend, the following warning is printed on >>>> r8a7791/koelsch: >>>> >>>> i2c-rcar e6530000.i2c: runtime PM trying to suspend device but >>>> active child >> >> 3. I've just bisected a seemingly unrelated issue to the same commit. >> On Salvator-XS with R-Car H3, initialization of the rcar-du driver now >> takes more than 1 minute due to flip_done time outs, while it took 0.12s >> before: >> >> [ 3.015035] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). >> [ 3.021721] [drm] No driver support for vblank timestamp query. >> [ 13.280738] [drm:drm_atomic_helper_wait_for_flip_done] *ERROR* >> [CRTC:58:crtc-3] flip_done timed out >> [ 23.520707] [drm:drm_atomic_helper_commit_cleanup_done] *ERROR* >> [CRTC:58:crtc-3] flip_done timed out >> [ 33.760708] [drm:drm_atomic_helper_wait_for_flip_done] *ERROR* >> [CRTC:58:crtc-3] flip_done timed out >> [ 44.000755] [drm:drm_atomic_helper_commit_cleanup_done] *ERROR* >> [CRTC:58:crtc-3] flip_done timed out >> [ 44.003597] Console: switching to colour frame buffer device 128x48 >> [ 54.240707] [drm:drm_atomic_helper_wait_for_flip_done] *ERROR* >> [CRTC:58:crtc-3] flip_done timed out >> [ 64.480706] [drm:drm_atomic_helper_commit_cleanup_done] *ERROR* >> [CRTC:58:crtc-3] flip_done timed out >> [ 64.544876] rcar-du feb00000.display: fb0: frame buffer device >> [ 64.552013] [drm] Initialized rcar-du 1.0.0 20130110 for >> feb00000.display on minor 0 >> [ 64.559873] [drm] Device feb00000.display probed >> >>>> Commit 2a9a86d5c81389cd ("PM / QoS: Fix default runtime_pm device resume >>>> latency") fixes the second issue, but not the first. >> >> ... nor the third. >> >>>> Reverting commits 2a9a86d5c81389cd ("PM / QoS: Fix default runtime_pm >>>> device resume latency") and 0cc2b4e5a020fc7f ("PM / QoS: Fix device resume >>>> latency PM QoS") fixes both. >> >> ... all three. > > Sorry for the breakage. > > OK, I'll just push the reverts to Linus later today. > >>>> Do you have a clue? > > Well, kind of. > > There is a change in behavior in domain_governor.c that should not > have made any difference to my eyes, but maybe that's it. > > Can you please check if the attached patch makes any difference? Thanks, but it doesn't seem to fix the issues. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds