From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.4 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E6409C4CED1 for ; Thu, 3 Oct 2019 18:19:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BD1322086A for ; Thu, 3 Oct 2019 18:19:42 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="RYYfr/9/" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388473AbfJCSTm (ORCPT ); Thu, 3 Oct 2019 14:19:42 -0400 Received: from mail-pf1-f193.google.com ([209.85.210.193]:34445 "EHLO mail-pf1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388415AbfJCSTl (ORCPT ); Thu, 3 Oct 2019 14:19:41 -0400 Received: by mail-pf1-f193.google.com with SMTP id b128so2299671pfa.1 for ; Thu, 03 Oct 2019 11:19:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=V3zfpA6pohOCQvyvizEapVU0+r/7JkIaALQBuXL6dpc=; b=RYYfr/9/HTri5GnuFK4sU0LwnzxScseFLrCQRKdo8R8x6zLw+7WbCPHGjzFa3JdRYl icU7yPc1Jhv7lKLLzrclUV0/jLKR4YF4nfpJ8RwAjFenmzu2M5fXNAmjFIAjaZawuBUc z3CkbEhB2CJkLZXBXbQ0MjGvQ21yczR1w6aRk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=V3zfpA6pohOCQvyvizEapVU0+r/7JkIaALQBuXL6dpc=; b=OgIiyZGmixcD3vMlLxNL3MwiIy4B3tKV8T0cin/PBJNpQf8B9eLwf1YbeF/Odgc8RS ItxPrkLwSawXngye6AzUnruli1aJUg5Tnm1LWggtJ7ripVDr8RsbMWbIlv/bk2+mnc+H llreXvF5h8lUarficzFSaZgKlZjYUoq4IvE204EeOjXlOcPrgF7VkPcpD7Qwliw5aYF8 1bd5rKKUVydhXYMl5PoT41ETlvrV26atRvsEpJFvPm9p1e/hLN8qdX9naDQEKCMlABzi B62PQeN++BNBQZuLT6n2vqUHahVRfvEquO9GBfbFDQd7uJk44T9zJHAmN5cJIyXhTULM ggAw== X-Gm-Message-State: APjAAAXW7zmsZUPAuGf2Ab8rfI5SzTp4IhE5SAeL1Fs6zZoQJ3oOUHPQ 1IQzcCRR/yEHO6K+woXFS3m8kA== X-Google-Smtp-Source: APXvYqxAEXRIRhtV+Dp3adyBB3Odhiyb27dhM9grTiYboHDrD+loFme6hzU61w45+soIrPB+w9SPcw== X-Received: by 2002:a62:5e42:: with SMTP id s63mr12421616pfb.96.1570126781009; Thu, 03 Oct 2019 11:19:41 -0700 (PDT) Received: from localhost ([2620:15c:202:1:4fff:7a6b:a335:8fde]) by smtp.gmail.com with ESMTPSA id p189sm2794942pga.2.2019.10.03.11.19.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Oct 2019 11:19:40 -0700 (PDT) Date: Thu, 3 Oct 2019 11:19:38 -0700 From: Matthias Kaehlcke To: Leonard Crestez , Viresh Kumar Cc: Chanwoo Choi , MyungJoo Ham , Kyungmin Park , Artur =?utf-8?B?xZp3aWdvxYQ=?= , Saravana Kannan , Krzysztof Kozlowski , Alexandre Bailon , Georgi Djakov , Abel Vesa , Jacky Bai , Viresh Kumar , Lukasz Luba , NXP Linux Team , linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v9 6/8] PM / devfreq: Introduce get_freq_range helper Message-ID: <20191003181938.GJ87296@google.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org On Wed, Oct 02, 2019 at 10:25:09PM +0300, Leonard Crestez wrote: > Moving handling of min/max freq to a single function and call it from > update_devfreq and for printing min/max freq values in sysfs. > > This changes the behavior of out-of-range min_freq/max_freq: clamping > is now done at evaluation time. This means that if an out-of-range > constraint is imposed by sysfs and it later becomes valid then it will > be enforced. > > Signed-off-by: Leonard Crestez > Reviewed-by: Matthias Kaehlcke > --- > drivers/devfreq/devfreq.c | 110 +++++++++++++++++++++----------------- > 1 file changed, 62 insertions(+), 48 deletions(-) > > diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c > index 87eff789ce24..2d63692903ff 100644 > --- a/drivers/devfreq/devfreq.c > +++ b/drivers/devfreq/devfreq.c > > ... > > static ssize_t min_freq_show(struct device *dev, struct device_attribute *attr, > char *buf) > { > struct devfreq *df = to_devfreq(dev); > + unsigned long min_freq, max_freq; > > - return sprintf(buf, "%lu\n", max(df->scaling_min_freq, df->min_freq)); > + mutex_lock(&df->lock); > + get_freq_range(df, &min_freq, &max_freq); With this min/max_freq shown aren't necessarily those set through sysfs, but the aggregated PM QoS values (plus OPP constraints). I did some testing with a WIP patch that converts devfreq_cooling.c to PM QoS. When reading sysfs min/max values to double check the limits set earlier I found it utterly confusing to see the sysfs min/max values fluctuating due to thermal throttling, and not being able to see the configured values. Looks like cpufreq does the same, but I'm not convinced this is a good idea. I think we want to display the values set by userspace, as done before managing the limits through PM QoS. Viresh, was this change of userspace visible behavior done intentionally for cpufreq? From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id ED175C10F14 for ; Thu, 3 Oct 2019 18:19:44 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C26762086A for ; Thu, 3 Oct 2019 18:19:44 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="ZXYCv5I9"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="RYYfr/9/" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C26762086A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=imSAJgKU2WHLpD/AUPKD8AhngwwZ5WbPoMxp5tBMytE=; b=ZXYCv5I92Olzcw ldJW/fdkz9/lF2hjMvHDkJ7g2nh66tDDUEiiWUwkO8Mvn9Oi2ncOu4bHW5/gWUOlWeuLmPBGut+sS pz4L8oha3CCt9InC6wO/9ZUbUVeh8omnK5h1imniIkVbzcOdRdsH7ILM/fdE9ulHllYtSIddX8Lht Z4n+BsgTX/mWFtBT3GYg73irCUgFVTZQCzenPFN4sw94nTLQeX51VUd6R3su5yfLjyWtzkSC3EAIs 1mKs6RZUtf434kbDYqgDQi2czNlLHRTvNXNXGMEFtCgl7mhSOM+/dDPqXdoOJPerLx7OisLlupyNR 3i+h6K8KHARXnAKRNcBw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.2 #3 (Red Hat Linux)) id 1iG5hY-0005cr-61; Thu, 03 Oct 2019 18:19:44 +0000 Received: from mail-pg1-x541.google.com ([2607:f8b0:4864:20::541]) by bombadil.infradead.org with esmtps (Exim 4.92.2 #3 (Red Hat Linux)) id 1iG5hV-0005cM-Ni for linux-arm-kernel@lists.infradead.org; Thu, 03 Oct 2019 18:19:43 +0000 Received: by mail-pg1-x541.google.com with SMTP id p1so473401pgi.4 for ; Thu, 03 Oct 2019 11:19:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=V3zfpA6pohOCQvyvizEapVU0+r/7JkIaALQBuXL6dpc=; b=RYYfr/9/HTri5GnuFK4sU0LwnzxScseFLrCQRKdo8R8x6zLw+7WbCPHGjzFa3JdRYl icU7yPc1Jhv7lKLLzrclUV0/jLKR4YF4nfpJ8RwAjFenmzu2M5fXNAmjFIAjaZawuBUc z3CkbEhB2CJkLZXBXbQ0MjGvQ21yczR1w6aRk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=V3zfpA6pohOCQvyvizEapVU0+r/7JkIaALQBuXL6dpc=; b=qdeWQ8VkB7f5u3hVIQ++jPz2oKT6VMk2fzRKYetNnNiA2nKniIbQHezSwHPftcEiUI 8gqwmmRKaqHiBrYu7vB4KQexzUvw6JNME+5gORAVxQsxQD66lFc3XplnIY5yfoPdj2RM exjcx2fBBodScLEQiBCBMMyziEJ5HJGt+AeRZq8Kdg6qkTiwJ3ZIJ9upkAIPoLeykA5z udwiNET9dL2+GXJY7HUy2x8ZkbpyOzDSavEktbhiWNS2WUGva9b+4XVclKeLbTch1Iby S3/40hMFddHF7uAfnGWT2++x9LPtI9j53mK7iUmheIoozAm+6LIhB2s2sJuZYCOmGy7z 8wtg== X-Gm-Message-State: APjAAAVAZIuUongJVa6fJlVpWVUIhiybefA9biiwYz1tbLqJofAsSwiB q35B/WwXeKyl3jB+/pbZbpMc2A== X-Google-Smtp-Source: APXvYqxAEXRIRhtV+Dp3adyBB3Odhiyb27dhM9grTiYboHDrD+loFme6hzU61w45+soIrPB+w9SPcw== X-Received: by 2002:a62:5e42:: with SMTP id s63mr12421616pfb.96.1570126781009; Thu, 03 Oct 2019 11:19:41 -0700 (PDT) Received: from localhost ([2620:15c:202:1:4fff:7a6b:a335:8fde]) by smtp.gmail.com with ESMTPSA id p189sm2794942pga.2.2019.10.03.11.19.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Oct 2019 11:19:40 -0700 (PDT) Date: Thu, 3 Oct 2019 11:19:38 -0700 From: Matthias Kaehlcke To: Leonard Crestez , Viresh Kumar Subject: Re: [PATCH v9 6/8] PM / devfreq: Introduce get_freq_range helper Message-ID: <20191003181938.GJ87296@google.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20191003_111941_799088_D660210F X-CRM114-Status: GOOD ( 17.47 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Artur =?utf-8?B?xZp3aWdvxYQ=?= , Abel Vesa , Saravana Kannan , linux-pm@vger.kernel.org, Viresh Kumar , NXP Linux Team , Krzysztof Kozlowski , Lukasz Luba , Chanwoo Choi , Kyungmin Park , MyungJoo Ham , Alexandre Bailon , Georgi Djakov , linux-arm-kernel@lists.infradead.org, Jacky Bai Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Oct 02, 2019 at 10:25:09PM +0300, Leonard Crestez wrote: > Moving handling of min/max freq to a single function and call it from > update_devfreq and for printing min/max freq values in sysfs. > > This changes the behavior of out-of-range min_freq/max_freq: clamping > is now done at evaluation time. This means that if an out-of-range > constraint is imposed by sysfs and it later becomes valid then it will > be enforced. > > Signed-off-by: Leonard Crestez > Reviewed-by: Matthias Kaehlcke > --- > drivers/devfreq/devfreq.c | 110 +++++++++++++++++++++----------------- > 1 file changed, 62 insertions(+), 48 deletions(-) > > diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c > index 87eff789ce24..2d63692903ff 100644 > --- a/drivers/devfreq/devfreq.c > +++ b/drivers/devfreq/devfreq.c > > ... > > static ssize_t min_freq_show(struct device *dev, struct device_attribute *attr, > char *buf) > { > struct devfreq *df = to_devfreq(dev); > + unsigned long min_freq, max_freq; > > - return sprintf(buf, "%lu\n", max(df->scaling_min_freq, df->min_freq)); > + mutex_lock(&df->lock); > + get_freq_range(df, &min_freq, &max_freq); With this min/max_freq shown aren't necessarily those set through sysfs, but the aggregated PM QoS values (plus OPP constraints). I did some testing with a WIP patch that converts devfreq_cooling.c to PM QoS. When reading sysfs min/max values to double check the limits set earlier I found it utterly confusing to see the sysfs min/max values fluctuating due to thermal throttling, and not being able to see the configured values. Looks like cpufreq does the same, but I'm not convinced this is a good idea. I think we want to display the values set by userspace, as done before managing the limits through PM QoS. Viresh, was this change of userspace visible behavior done intentionally for cpufreq? _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel