Received: by 10.223.164.221 with SMTP id h29csp73920wrb; Tue, 31 Oct 2017 10:14:33 -0700 (PDT) X-Google-Smtp-Source: ABhQp+RWec+1Jbi0W35kenbQ202fmTCKaNQn4yig8rLYMMdsz5WJuMjV/Bwe96Yb9cJDn++I6Cdz X-Received: by 10.99.147.3 with SMTP id b3mr2502349pge.352.1509470073268; Tue, 31 Oct 2017 10:14:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1509470073; cv=none; d=google.com; s=arc-20160816; b=Uz9QPreJzaJlD2MNnTBn9iCHWBuJL5HAUKUGTPAac6muftGxjIQgxzaMDrWyRjSIrM IQaVVWxvqzT2B19McpluTO4xhb4OkK6bHSaJnWCgFPuS/+CLMWctzsMV4oPmigJDb8JK qw4m0oDz48udzo5hTR384p0eHttR1wK7Pm5B/4016kjV/90/sCe8dQdB9w47WRuXVWTH papu6CiwPA2izHZlK3ATxWczECuxMuGpPrFUuu7Bj6kVSZOsXKvg9npWtbeoRhT7Y5wm dupIhK01VgIUVgsmo+3Ydg/5Spyl5z6sOHkyEE1yGj8Wnr4S4wRsN9ixPBHMW/e7uIkV ga4Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature:arc-authentication-results; bh=agILR9xqkY2+ZXlNpZPu9iK7mm/5zo1M5jkKCiP46HM=; b=sHa0wE58PWO84WASRCLwm9KHvaVRaH7dYnal7epzyhJP9GO/VjHjUv6jD6ZNEzdJTN 9ez8Ui/TknBCI49f/hTknIiOVdJ99Og20cz5RdNs00ctrkVAPJBJ5Vtg9LnOBr0t7Onb 1FKx9G0spalPlkqk/yNkN6JFUfZMYzX7yGq/yt0SAtLFTwUqBm+llnK84LD9uvahgzaL OGl3CkxW15Dqh0+jd2XZvD+YHAUov9sFu8K+jGKjI/0McXbgog8sKrUWkmOa2l6YomB5 tn1UDfipBIg5ULKjXKoOi5H/GIxDmgPlOPT/W6y8cy//8qZucLHeb3V+bXTog5FuK5Xv Uaqg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass (test mode) header.i=@ideasonboard.com header.s=mail header.b=IAGVcFU8; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 73si2097646pfr.339.2017.10.31.10.14.19; Tue, 31 Oct 2017 10:14:33 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass (test mode) header.i=@ideasonboard.com header.s=mail header.b=IAGVcFU8; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753913AbdJaRML (ORCPT + 99 others); Tue, 31 Oct 2017 13:12:11 -0400 Received: from galahad.ideasonboard.com ([185.26.127.97]:35851 "EHLO galahad.ideasonboard.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753868AbdJaRMF (ORCPT ); Tue, 31 Oct 2017 13:12:05 -0400 Received: from avalon.localnet (dfj612ybrt5fhg77mgycy-3.rev.dnainternet.fi [IPv6:2001:14ba:21f5:5b00:2e86:4862:ef6a:2804]) by galahad.ideasonboard.com (Postfix) with ESMTPSA id 59E9620115; Tue, 31 Oct 2017 18:11:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1509469866; bh=X4icOeY0cLMXdD8E8Bw+V7LU/YSpANrrOyyRNuGGLbU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=IAGVcFU8/IkMJ3AAyotHn3mTr5QhEmrTe0legSfwmWDa48Eu2h3GqO7PiCLA8xj6P x+z2UTHgYxBOD/JCzLf03ptoqaD7ZsUka5hbhuH4XcrvensMS3VrgNviP40yZEYc5a auX5dD0mG28AewWEW9OQe2rVz36NHP8xk0YdR3Y8= From: Laurent Pinchart To: Geert Uytterhoeven Cc: "Rafael J. Wysocki" , Tero Kristo , Linux PM , Linux Kernel Mailing List , Linux-Renesas , DRI Development Subject: Re: [PATCH] PM / QoS: Fix default runtime_pm device resume latency Date: Tue, 31 Oct 2017 19:12:04 +0200 Message-ID: <1785554.vpm9XMd3xA@avalon> In-Reply-To: References: <1509347446-26105-1-git-send-email-t-kristo@ti.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Geert, On Tuesday, 31 October 2017 15:55:02 EET Geert Uytterhoeven wrote: > On Tue, Oct 31, 2017 at 2:10 PM, Geert Uytterhoeven wrote: > > 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. Thank you for tracking this and notifying me. I like it even better now that the problem seems to be fixed without requiring any action from my side :-) > >> Do you have a clue? > >> Thanks! -- Regards, Laurent Pinchart From 1582792005227315263@xxx Tue Oct 31 16:41:23 +0000 2017 X-GM-THRID: 1582665622280232801 X-Gmail-Labels: Inbox,Category Forums