From patchwork Wed Nov 1 10:28:46 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tero Kristo X-Patchwork-Id: 10036101 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 A9EB4602B5 for ; Wed, 1 Nov 2017 10:29:20 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id A1BA128AC9 for ; Wed, 1 Nov 2017 10:29:20 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 9670C28AEE; Wed, 1 Nov 2017 10:29:20 +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=-7.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_HI 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 8AF8B28AC9 for ; Wed, 1 Nov 2017 10:29:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751495AbdKAK3F (ORCPT ); Wed, 1 Nov 2017 06:29:05 -0400 Received: from fllnx210.ext.ti.com ([198.47.19.17]:50293 "EHLO fllnx210.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751344AbdKAK3D (ORCPT ); Wed, 1 Nov 2017 06:29:03 -0400 Received: from dflxv15.itg.ti.com ([128.247.5.124]) by fllnx210.ext.ti.com (8.15.1/8.15.1) with ESMTP id vA1ASqTb025380; Wed, 1 Nov 2017 05:28:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ti.com; s=ti-com-17Q1; t=1509532132; bh=0BF48tmK1OMVw0RxTkI6YZLi1cqFFG6FSJh1oP+gab0=; h=Subject:To:CC:References:From:Date:In-Reply-To; b=wwrHGXR5c2dr3Ek2EUKi8wZzttAOoXyUYZjqBvEam6nu9BVztB13qVojvEcxuoTJi Rbac9epD6Ga4WjxG0TD7JxNsAvt+u6lfit7a/sAYt/qPGmtO86biDZ5ZzBLQzbV4+s yW661giJkzPCEdijxxfcvPN78Aebu83PM7B/RpXw= Received: from DLEE104.ent.ti.com (dlee104.ent.ti.com [157.170.170.34]) by dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id vA1ASptW020910; Wed, 1 Nov 2017 05:28:51 -0500 Received: from DLEE112.ent.ti.com (157.170.170.23) by DLEE104.ent.ti.com (157.170.170.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.845.34; Wed, 1 Nov 2017 05:28:51 -0500 Received: from dflp33.itg.ti.com (10.64.6.16) by DLEE112.ent.ti.com (157.170.170.23) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.845.34 via Frontend Transport; Wed, 1 Nov 2017 05:28:51 -0500 Received: from [127.0.0.1] (ileax41-snat.itg.ti.com [10.172.224.153]) by dflp33.itg.ti.com (8.14.3/8.13.8) with ESMTP id vA1ASl5a029416; Wed, 1 Nov 2017 05:28:47 -0500 Subject: Re: [PATCH] PM / QoS: Fix default runtime_pm device resume latency To: "Rafael J. Wysocki" , Geert Uytterhoeven CC: "Rafael J. Wysocki" , Linux PM , Linux Kernel Mailing List , Linux-Renesas , Laurent Pinchart , DRI Development References: <1509347446-26105-1-git-send-email-t-kristo@ti.com> <3227682.nATp9NGxKU@aspire.rjw.lan> From: Tero Kristo Message-ID: <42ddd99a-e279-0d64-d000-e70f356998d0@ti.com> Date: Wed, 1 Nov 2017 12:28:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 01/11/17 00:32, Rafael J. Wysocki wrote: > On Tue, Oct 31, 2017 at 7:07 PM, Geert Uytterhoeven > wrote: >> 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. > > Thanks for testing! > > I've just pushed the reverts, but the PM QoS still needs to be fixed, > so we have to get to the bottom of this. > > The current theory goes that the changes in domain_governor.c are to > blame. Is genpd involved in all of the issues with the PM QoS fix you > have seen? > > Thanks, > Rafael > It seems the default values for pm_qos have changed with the patch, and that breaks genpd at least. I only fixed PM runtime initially, but you could try this diff to fix the genpd part also: --- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki diff --git a/include/linux/pm_qos.h b/include/linux/pm_qos.h index d68b056..7c8f643 100644 --- a/include/linux/pm_qos.h +++ b/include/linux/pm_qos.h @@ -34,9 +34,9 @@ enum pm_qos_flags_status { #define PM_QOS_NETWORK_LAT_DEFAULT_VALUE (2000 * USEC_PER_SEC) #define PM_QOS_NETWORK_THROUGHPUT_DEFAULT_VALUE 0 #define PM_QOS_MEMORY_BANDWIDTH_DEFAULT_VALUE 0 -#define PM_QOS_RESUME_LATENCY_DEFAULT_VALUE 0 +#define PM_QOS_RESUME_LATENCY_DEFAULT_VALUE PM_QOS_LATENCY_ANY #define PM_QOS_RESUME_LATENCY_NO_CONSTRAINT PM_QOS_LATENCY_ANY -#define PM_QOS_LATENCY_TOLERANCE_DEFAULT_VALUE 0 +#define PM_QOS_LATENCY_TOLERANCE_DEFAULT_VALUE (-1) #define PM_QOS_LATENCY_TOLERANCE_NO_CONSTRAINT (-1) #define PM_QOS_FLAG_NO_POWER_OFF (1 << 0)