Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp397155ybg; Wed, 3 Jun 2020 03:44:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwruy6mtyQi17sT+HCGhZQlzkwoDH0sHMLsi+J5tXwwblCBF4JoMKhBQUISK5JVuqyIu0eV X-Received: by 2002:a17:906:c155:: with SMTP id dp21mr26215141ejc.92.1591181082258; Wed, 03 Jun 2020 03:44:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591181082; cv=none; d=google.com; s=arc-20160816; b=mSFFMqHSLTFiv2mf13wtF02JOcTwle2E9d8dSaKdoHTYmM8dEz/EUAOkGmTaC+/4F/ 7jdsDP7Qw/oRhxQEsp6oh2CfMKhSSkMn9LL4L3/hUvjTPkuERzAdu6lMr+oQvtRmzGox Q/4jtIqEQCSdMd57nuk7A1y4o9ZDM5ekEFIO6j6p3GKnqn2PjQ9D1lFeCgCewM8wjoB0 /7QzSNDSBPNNGyTI9ZVqwIEQ86C6yZ71pXmMGDIv49Bgk+pppLWDlx4J8QsBOIS3sQlj h7vhYxQel/34VtvJ+vMzj1tfg+o6so+hiONL+uBss1oUmPyRjJTqCl647f5tbP2UQtjt S29g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=Ri5pbkUaX+VTUEt1IX2mupCMBRgMMH3oSS3u1ibsSp4=; b=xzAeU0+RFOKktGQ0f+q/fMW3ZywprhRLjhFe+VI7sxT+DAWCfzT50C0VXeCT83OeXB E6jzOXWXKkvcebOETdqfhuD1afFku1mJcovnyqvpGvRC7Mz4KzcGrgfOR7oAcCKVpsml u+9wJEPLjby6ZPtgDy4GKOm2dv9Dz3IL9fFjXR5p00a8pq2jyShqUJaCb+T45dCrVf4y S9LXotU48yuc3Wc5uuhVy/G/DS7PgZ7GD02JiyoGG5xY07h0MgtoQZGYc3644coyLuQU 4FtupWKKY7xFlDFBt97y7JYBV3WJvigtMmm2/t17YasmX38ouCGrM5f3PK4fo7fOj2dO KwMA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k30si836637edc.50.2020.06.03.03.44.18; Wed, 03 Jun 2020 03:44:42 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725890AbgFCKkY (ORCPT + 99 others); Wed, 3 Jun 2020 06:40:24 -0400 Received: from foss.arm.com ([217.140.110.172]:59786 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725828AbgFCKkX (ORCPT ); Wed, 3 Jun 2020 06:40:23 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 0A86331B; Wed, 3 Jun 2020 03:40:23 -0700 (PDT) Received: from bogus (unknown [10.37.12.118]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 152D53F305; Wed, 3 Jun 2020 03:40:20 -0700 (PDT) Date: Wed, 3 Jun 2020 11:40:17 +0100 From: Sudeep Holla To: Viresh Kumar Cc: Xiongfeng Wang , rjw@rjwysocki.net, guohanjun@huawei.com, ionela.voinescu@arm.com, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [Question]: about 'cpuinfo_cur_freq' shown in sysfs when the CPU is in idle state Message-ID: <20200603104017.GD7259@bogus> References: <20200603075200.hbyofgcyiwocl565@vireshk-i7> <20200603100727.GB7259@bogus> <20200603101010.alijrfmte2c6xv5c@vireshk-i7> <20200603101753.GC7259@bogus> <20200603102159.hzctwiqiukwhrpo7@vireshk-i7> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200603102159.hzctwiqiukwhrpo7@vireshk-i7> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 03, 2020 at 03:51:59PM +0530, Viresh Kumar wrote: > On 03-06-20, 11:17, Sudeep Holla wrote: > > On Wed, Jun 03, 2020 at 03:40:10PM +0530, Viresh Kumar wrote: > > > On 03-06-20, 11:07, Sudeep Holla wrote: > > > > But I have another question. If we can detect that CPPC on some platforms > > > > rely on CPU registers(I assume FFH registers here and not system/io/... > > > > type of GAS registers), can we set dvfs_on_any_cpu(can't recall exact > > > > flag name) to false if not already done to prevent such issues. Or I am > > > > talking non-sense as it may be applicable only for _set operation and > > > > > > Yes, non-sense :) > > > > > > > Thanks for confirming ????. > > Hehe. > > So, do you agree that we better do the read from the CPUs themselves ? > Yes if that is fine. I thought waking up the core was not a good solution in terms of power, but I have no objection for that as well as return 0 as IMO it aligns with the AMU counters when CPU is idle. -- Regards, Sudeep