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=-7.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no 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 498DFC433E0 for ; Tue, 4 Aug 2020 10:45:36 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 24543206C0 for ; Tue, 4 Aug 2020 10:45:36 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="xSqxt2jn" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 24543206C0 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+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=merlin.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=eUrALvppKtMTkdGYlJfQm6AzTsZNvQAWxFJYmqqiM4Y=; b=xSqxt2jnKrOx5iFILBRM6Xtq1 FM3D3FJe7Ak7EHKnnZdsodREvp06UJ2n258QHIx6me0X49entjCkSmxmltlVy15/u/zs+mlxoqshR Xn0UotVzQ9PijVWw394JYxZRnnJM6FWgVQUt9zONnPzWrrEW/kFeeKoCsUMg0+JxKvFhyulrENiWr hXcsgwtAaTfgMvyqcZvU8RQiwmyS3yjz6xTizfoyM3Ql++Wxrw7H6zzGhKndU38Z7aWtby23ixXAZ v+M0y6Dmo+sk03tw0hJmbN4LUphjOUollYtZYEExc70+aB16kBpNSnXCCaQ5dzWsAlNaYyGkYcMn7 yV22V0T/Q==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k2uQc-0000sS-56; Tue, 04 Aug 2020 10:44:18 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k2uQY-0000rU-8u for linux-arm-kernel@lists.infradead.org; Tue, 04 Aug 2020 10:44:15 +0000 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 8BE5F31B; Tue, 4 Aug 2020 03:44:13 -0700 (PDT) Received: from [10.37.12.45] (unknown [10.37.12.45]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id DF34E3F718; Tue, 4 Aug 2020 03:44:11 -0700 (PDT) Subject: Re: [PATCH 0/4] CPUFreq statistics retrieved by drivers To: Viresh Kumar References: <20200729151208.27737-1-lukasz.luba@arm.com> <20200730085333.qubrsv7ufqninihd@vireshk-mac-ubuntu> <20200730091014.GA13158@bogus> <3b3a56e9-29ec-958f-fb3b-c689a9389d2f@arm.com> <20200804053502.35d3x3vnb3mggtqs@vireshk-mac-ubuntu> <20200804103857.mxgkmt6qmmzejuzb@vireshk-mac-ubuntu> From: Lukasz Luba Message-ID: <1f978078-b2df-a2e5-6af8-e73f65044ba7@arm.com> Date: Tue, 4 Aug 2020 11:44:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20200804103857.mxgkmt6qmmzejuzb@vireshk-mac-ubuntu> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200804_064414_598030_FCDAFF0A X-CRM114-Status: GOOD ( 25.81 ) 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: linux-pm@vger.kernel.org, rjw@rjwysocki.net, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Sudeep Holla , cristian.marussi@arm.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 8/4/20 11:38 AM, Viresh Kumar wrote: > On 04-08-20, 11:29, Lukasz Luba wrote: >> On 8/4/20 6:35 AM, Viresh Kumar wrote: >>> IIUC, the only concern right now is to capture stats with fast switch ? Maybe we >>> can do something else in that case and brainstorm a bit.. >> >> Correct, the fast switch is the only concern right now and not tracked. We >> could fill in that information with statistics data from firmware >> with a cpufreq driver help. >> >> I could make the if from patch 1/4 covering narrowed case, when >> fast switch is present, check for drivers stats. >> Something like: >> -----------8<------------------------------------------------------------ >> if (policy->fast_switch_enabled) >> if (policy->has_driver_stats) >> return cpufreq_stats_present_driver_data(policy, buf); >> else >> return 0; >> -------------->8---------------------------------------------------------- > > I don't think doing it with help of firmware is the right thing to do > here then. For another platform we may not have a firmware which can > help us, we need something in the opp core itself for that. Lemme see > if I can do something about it. OK, great, I will wait then with this patch series v2 which would change into debugfs scmi only. Could you please add me on CC, I am very interested in. > >>> Why is firmware the governor here ? Aren't you talking about the simple fast >>> switch case only ? >> >> I used a term 'governor' for the firmware because it makes the final >> set for the frequency. It (FW) should respect the frequency value >> set using the fast switch. I don't know how other firmware (e.g. Intel) >> treats this fast switch value or if they even expose FW stats, though. > > For Intel I think, Linux is one of the entities that vote for deciding > the frequency of the CPUs and the firmware (after taking all such > factors into account) chooses a frequency by its own, which must be >= > the frequency requested by Linux. > >> You can read about this statistics region in [1] at: >> 4.5.5 Performance domain statistics shared memory region >> >>> >>> Over that, I think this cpufreq stats information isn't parsed by any tool right >>> now and tweaking it a bit won't hurt anyone (like if we start capturing things a >>> bit differently). So we may not want to worry about breaking userspace ABI here, >>> if what we are looking to do is the right thing to do. >> >> So, there is some hope... IMHO it would be better to have this cpufreq >> stats in normal location, rather then in scmi debugfs. > > I agree. > >>> I am not sure what notifications are we talking about here. >> >> There is a notification mechanism described in the SCMI spec [1] at >> 4.5.4 Notifications. >> We were referring to that mechanism. > > Ahh, I see. All I was thinking was about the cpufreq specific > notifiers :) > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel