From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753682AbdJaQkf (ORCPT ); Tue, 31 Oct 2017 12:40:35 -0400 Received: from mail-wm0-f68.google.com ([74.125.82.68]:48065 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753593AbdJaQk3 (ORCPT ); Tue, 31 Oct 2017 12:40:29 -0400 X-Google-Smtp-Source: ABhQp+Ru6jT7nu8+OV86za2P108YRa3K9MZCpUay9xrLrsi/G/4FdUTFp51lxa/zX4j0c3cGCeFlIg== Date: Tue, 31 Oct 2017 17:40:24 +0100 From: Daniel Vetter To: Jani Nikula Cc: Geert Uytterhoeven , "Rafael J. Wysocki" , Tero Kristo , Linux PM , Linux Kernel Mailing List , DRI Development , "Peres, Martin" , Linux-Renesas , Laurent Pinchart Subject: Re: [PATCH] PM / QoS: Fix default runtime_pm device resume latency Message-ID: <20171031164024.ekqjmyuxsqc2sef3@phenom.ffwll.local> Mail-Followup-To: Jani Nikula , Geert Uytterhoeven , "Rafael J. Wysocki" , Tero Kristo , Linux PM , Linux Kernel Mailing List , DRI Development , "Peres, Martin" , Linux-Renesas , Laurent Pinchart References: <1509347446-26105-1-git-send-email-t-kristo@ti.com> <3227682.nATp9NGxKU@aspire.rjw.lan> <87r2tje3ap.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87r2tje3ap.fsf@intel.com> X-Operating-System: Linux phenom 4.12.0-1-amd64 User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 31, 2017 at 05:37:50PM +0200, Jani Nikula wrote: > On Tue, 31 Oct 2017, Geert Uytterhoeven wrote: > > Hi Rafael, Tero, > > > > CC pinchartl, dri-devel > > Cc: Marta, Martin > > Our CI is hitting this too. Should be ok again, we've locally reverted this patch. But a big chunk of the pw runs overnight did hit it unfortunately :-( -Daniel > > BR, > Jani. > > > > > 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. > > > >>> Do you have a clue? > >>> Thanks! > > > -- > Jani Nikula, Intel Open Source Technology Center > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch