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.3 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 6751AC43457 for ; Tue, 13 Oct 2020 13:55:27 +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 E49152478D for ; Tue, 13 Oct 2020 13:55:26 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="cb8WGRjA" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E49152478D 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-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=IuTWKTcigVCml67x8mr50qLw6CXB83E7iXN/QcMGjJI=; b=cb8WGRjACTp7J9WsxQl+6o43L zKXIEbgrn6IYFC05vMbiT2n68c9fXMAXBlFVSYgRDOHGZUsbQL0FO6v/94iiTxE+qzFn9cOEK1H0g 4FpiJDbwaVuOVwSs9Z+sGF1WJXIOISybo3V8qB8T3O+HpntwuWaUWt466KAq4pBuL9twdPAUATVeo /iaSUp3+tvxxIvFmlNOk/pFFs/Kr4E9wFZqimQUtp27E/doziYq1xzYKFWQDj+0Q1cxitvJaKzXky era2lHZ6dBn+lTEI2OF8RO857IAf+IzJnSDeDf3fizi9xqK0HyVK9em6UWYvVAK6P1s8/SUdQubBG nmlnf/Hpw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kSKkX-0001e0-HT; Tue, 13 Oct 2020 13:53:57 +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 1kSKkU-0001dR-M1 for linux-arm-kernel@lists.infradead.org; Tue, 13 Oct 2020 13:53:55 +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 37A6B31B; Tue, 13 Oct 2020 06:53:50 -0700 (PDT) Received: from [10.57.51.141] (unknown [10.57.51.141]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 50EF83F66B; Tue, 13 Oct 2020 06:53:47 -0700 (PDT) Subject: Re: [PATCH v2 2/2] [RFC] CPUFreq: Add support for cpu-perf-dependencies To: Viresh Kumar References: <20200924095347.32148-1-nicola.mazzucato@arm.com> <20200924095347.32148-3-nicola.mazzucato@arm.com> <20201006071909.3cgz7i5v35dgnuzn@vireshk-i7> <2417d7b5-bc58-fa30-192c-e5991ec22ce0@arm.com> <20201008110241.dcyxdtqqj7slwmnc@vireshk-i7> <20201008150317.GB20268@arm.com> <56846759-e3a6-9471-827d-27af0c3d410d@arm.com> <20201009053921.pkq4pcyrv4r7ylzu@vireshk-i7> From: Lukasz Luba Message-ID: <6a739b1b-e345-fa09-d815-6e9601aff5f6@arm.com> Date: Tue, 13 Oct 2020 14:53:45 +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: <20201009053921.pkq4pcyrv4r7ylzu@vireshk-i7> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201013_095354_777721_03FDC146 X-CRM114-Status: GOOD ( 20.14 ) 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: devicetree@vger.kernel.org, linux-pm@vger.kernel.org, vireshk@kernel.org, daniel.lezcano@linaro.org, rjw@rjwysocki.net, linux-kernel@vger.kernel.org, robh+dt@kernel.org, Nicola Mazzucato , sudeep.holla@arm.com, chris.redpath@arm.com, Ionela Voinescu , morten.rasmussen@arm.com, linux-arm-kernel@lists.infradead.org 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 Hi Viresh, On 10/9/20 6:39 AM, Viresh Kumar wrote: > > Oh yes, I get it now. Finally. Thanks for helping me out :) > > So if I can say all this stuff in simple terms, this is what it will > be like: > > - We don't want software aggregation of frequencies and so we need to > have per-cpu policies even when they share their clock lines. > > - But we still need a way for other frameworks to know which CPUs > share the clock lines (that's what the perf-dependency is all about, > right ?). > > - We can't get it from SCMI, but need a DT based solution. > > - Currently for the cpufreq-case we relied for this on the way OPP > tables for the CPUs were described. i.e. the opp-table is marked as > "shared" and multiple CPUs point to it. I've started wondering based on the OPP code if this is a good solution. We would end up with one (?) instance of opp_table and list of devices pinned to it, in: opp_table->dev_list It can be seen e.g. in function dev_pm_opp_get_sharing_cpus(), where we retrieve the cpumask simply looping through the devices: list_for_each_entry(opp_dev, &opp_table->dev_list, node) cpumask_set_cpu(opp_dev->dev->id, cpumask); This means we have a single OPP table for all pinned CPUs. I wonder if this is not too strong assumption for still being compliant with SCMI spec, when in theory performance levels might differ... (please correct me here it that would never happen) There is also 2nd function dev_pm_opp_of_get_sharing_cpus() which looks more promising. But I still don't know if the framework will allow us to have private OPP tables when we use 'shared' in DT. Could you clarify if we would get 'private' opp table for each CPU, which could be then populated independently, but still 2nd function will work? Regards, Lukasz _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel