From patchwork Tue Oct 31 17:22:19 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Rafael J. Wysocki" X-Patchwork-Id: 10034985 X-Patchwork-Delegate: geert@linux-m68k.org Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 089B660327 for ; Tue, 31 Oct 2017 17:22:47 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E26FE28B1F for ; Tue, 31 Oct 2017 17:22:46 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id D760628BC5; Tue, 31 Oct 2017 17:22:46 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.3 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI, RCVD_IN_SORBS_SPAM, T_DKIM_INVALID autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 3055628BBF for ; Tue, 31 Oct 2017 17:22:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753908AbdJaRWd (ORCPT ); Tue, 31 Oct 2017 13:22:33 -0400 Received: from mail-oi0-f66.google.com ([209.85.218.66]:46719 "EHLO mail-oi0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753998AbdJaRWV (ORCPT ); Tue, 31 Oct 2017 13:22:21 -0400 Received: by mail-oi0-f66.google.com with SMTP id n82so27837202oig.3; Tue, 31 Oct 2017 10:22:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=EX2o9fjdO0IcLv3FhdmZIo6WDdqI/TBRNAmencCgPrE=; b=HqFCbQxbTZvJ8T9V7n7aoYQ+eI8CXwqcxsZH8vid37nIn3Ai3gnX7Ov/SNdJdD8AE5 8pjpm4M5s5/zxo5GY9LtPyHtcQtt+TZHvEySbtvFpnm5JBKFW1ObF4mPvQ4ERjIkVAlC 9lsIzWKP5nInvmPDbdptCIDFdnMxHJG7puzjngWpE6sJGk9ORVysirg+dEpK23umF23B qv4Nsz90uIpkSAhbJvD+9hByVlbiSne3RU4rytHk1T5yNDqKhYfLfNSgcPKhcmvhccOe LRE07NQShdNl9XM6KfkqSz+iQIorsCR2s74Jybko4714l9xmFkAUp7KB1JeJkAlL/Y3+ mHGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=EX2o9fjdO0IcLv3FhdmZIo6WDdqI/TBRNAmencCgPrE=; b=YD6EGNrnLCfz2CYEj8iEDjLh41nEvKd1gePCNNhp8TuzuzEvyE562a2MCaeHQ5Qxwn w+msEuUkS5t3l7BbbnGFiWI58gcDqbaMuvggaainunArH5/H1wx4RGUWceioaoRDOtsx dPUQ9JfihLtL21y1MDXyVDvmynErh7xlj97V0z8qzD3P2S3flJ0TqlUfwCwDIIaMCpzp jS4Rxe48u8YqXZ7ChBUURwqzyYudothc3n0yGVHPkZTkLK4zfijUnmzLWyYTNSyIWIAp OAFW/1ApcDwa5I0+QXh4U4Kwz0SduvTEtSOHqKCHw7tcOQewlHy6ufpKqaJccyVacT21 A2sg== X-Gm-Message-State: AMCzsaUTJI0SNEnAjFWI2FOhzBgdxplLy3eB+yc3aQVk9IfeO77sE/qh T/YcBByw3UZx9HRPtsxJv8RLQMX3wKPoVI1pfvo= X-Google-Smtp-Source: ABhQp+SwTJqk90vhg1kO5SKooKwmlxnIvJcQPS3go8QlPQiVuhTLlzNpnvIvk8xn82x4gRHuEUJvoetB1Uu3rRhdH5g= X-Received: by 10.157.5.33 with SMTP id 30mr1583177otw.431.1509470540084; Tue, 31 Oct 2017 10:22:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.73.24 with HTTP; Tue, 31 Oct 2017 10:22:19 -0700 (PDT) In-Reply-To: References: <1509347446-26105-1-git-send-email-t-kristo@ti.com> <3227682.nATp9NGxKU@aspire.rjw.lan> From: "Rafael J. Wysocki" Date: Tue, 31 Oct 2017 18:22:19 +0100 X-Google-Sender-Auth: _UTVLJE4c0IiPhLhIhCF2xgi6p0 Message-ID: Subject: Re: [PATCH] PM / QoS: Fix default runtime_pm device resume latency To: Geert Uytterhoeven Cc: "Rafael J. Wysocki" , Tero Kristo , Linux PM , Linux Kernel Mailing List , Linux-Renesas , Laurent Pinchart , DRI Development Sender: linux-renesas-soc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-renesas-soc@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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, Rafael --- drivers/base/power/domain_governor.c | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) Index: linux-pm/drivers/base/power/domain_governor.c =================================================================== --- linux-pm.orig/drivers/base/power/domain_governor.c +++ linux-pm/drivers/base/power/domain_governor.c @@ -83,12 +83,11 @@ static bool default_suspend_ok(struct de td->cached_suspend_ok = true; } else { constraint_ns -= td->suspend_latency_ns + td->resume_latency_ns; - if (constraint_ns > 0) { - td->effective_constraint_ns = constraint_ns; - td->cached_suspend_ok = true; - } else { - td->effective_constraint_ns = 0; - } + if (constraint_ns == 0) + return false; + + td->effective_constraint_ns = constraint_ns; + td->cached_suspend_ok = constraint_ns >= 0; } /*