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=-5.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, 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 D4524C433DF for ; Mon, 12 Oct 2020 22:02:55 +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 7526B2074F for ; Mon, 12 Oct 2020 22:02:55 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="v1/qJDx0" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7526B2074F Authentication-Results: mail.kernel.org; dmarc=fail (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-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=QydqVcq0ycxXV18ifPnB5Slqtntz+j1LFkUOVRXOBho=; b=v1/qJDx0c/Ah4e8acW6Gxu8yK UvJUpl/M8HqzDr1jGugmCz3iLHldAk++VRIZzNrd7rdn51OEfw5PKJh1Ne3VqqtUgU41d0Wfj2eXF zutsoUFPLnfKYe+XvVgZ9CClFLtVc1jwUR00HpQalRG47ypPLkTVElKkJCYhfCgpem2R1GNlRegDT q+z4Lcokg1qhMZKILuJD+odZOTMHG2VEIGJGfZHzIfDPJvX6C79zbRfIu6uW9XDy6zU8jk9v/vlq4 kFauBXyUs7EAKhp0SuNlnvYCSEPfezKu+n8OFtL868mQ+kRXfRdEvVe5lZjNpXb3K6bKd1KTUcU2c U7j432Fgw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kS5sy-0003e1-8L; Mon, 12 Oct 2020 22:01:40 +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 1kS5su-0003bu-5D for linux-arm-kernel@lists.infradead.org; Mon, 12 Oct 2020 22:01:37 +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 C7FCA31B; Mon, 12 Oct 2020 15:01:34 -0700 (PDT) Received: from localhost (unknown [10.1.199.49]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6999E3F719; Mon, 12 Oct 2020 15:01:34 -0700 (PDT) Date: Mon, 12 Oct 2020 23:01:33 +0100 From: Ionela Voinescu To: Lukasz Luba Subject: Re: [PATCH v2 2/2] [RFC] CPUFreq: Add support for cpu-perf-dependencies Message-ID: <20201012220132.GA1715@arm.com> References: <20201008150317.GB20268@arm.com> <56846759-e3a6-9471-827d-27af0c3d410d@arm.com> <20201009053921.pkq4pcyrv4r7ylzu@vireshk-i7> <42e3c8e9-cadc-d013-1e1f-fa06af4a45ff@arm.com> <20201009140141.GA4048593@bogus> <2b7b6486-2898-1279-ce9f-9e7bd3512152@arm.com> <20201012105945.GA9219@arm.com> <500510b9-58f3-90b3-8c95-0ac481d468b5@arm.com> <20201012163032.GA30838@arm.com> <9fe56600-ba7d-d3b6-eea3-885475d94d7a@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <9fe56600-ba7d-d3b6-eea3-885475d94d7a@arm.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201012_180136_293422_CAC32965 X-CRM114-Status: GOOD ( 19.87 ) 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: Rob Herring , daniel.lezcano@linaro.org, devicetree@vger.kernel.org, vireshk@kernel.org, linux-pm@vger.kernel.org, rjw@rjwysocki.net, linux-kernel@vger.kernel.org, sudeep.holla@arm.com, Nicola Mazzucato , Viresh Kumar , chris.redpath@arm.com, morten.rasmussen@arm.com, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hey Lukasz, I think after all this discussion (in our own way of describing things) we agree on how the current cpufreq based FIE implementation is affected in systems that use hardware coordination. What we don't agree on is the location where that implementation (that uses the new mask and aggregation) should be. On Monday 12 Oct 2020 at 19:19:29 (+0100), Lukasz Luba wrote: [..] > The previous FIE implementation where arch_set_freq_scale() > was called from the drivers, was better suited for this issue. > Driver could just use internal dependency cpumask or even > do the aggregation to figure out the max freq for cluster > if there is a need, before calling arch_set_freq_scale(). > > It is not perfect solution for software FIE, but one of possible > when there is no hw counters. > [..] > Difference between new FIE and old FIE (from v5.8) is that the new one > purely relies on schedutil max freq value (which will now be missing), > while the old FIE was called by the driver and thus it was an option to > fix only the affected cpufreq driver [1][2]. > My final argument is that now you have 2 drivers that would need this support, next you'll have 3 (the new mediatek driver), and in the future there will be more. So why limit and duplicate this functionality in the drivers? Why not make it generic for all drivers to use if the system is using hardware coordination? Additionally, I don't think drivers should not even need to know about these dependency/clock domains. They should act at the level of the policy, which in this case will be at the level of each CPU. Thanks, Ionela. > IMO we can avoid this new cpumask in policy. > > Regards, > Lukasz > > [1] https://elixir.bootlin.com/linux/v5.8/source/drivers/cpufreq/scmi-cpufreq.c#L58 > [2] https://elixir.bootlin.com/linux/v5.8/source/drivers/cpufreq/qcom-cpufreq-hw.c#L79 > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel