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, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,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 97899C433FE for ; Tue, 8 Dec 2020 10:57:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 439AA23AC6 for ; Tue, 8 Dec 2020 10:57:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728907AbgLHK53 (ORCPT ); Tue, 8 Dec 2020 05:57:29 -0500 Received: from foss.arm.com ([217.140.110.172]:47276 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726226AbgLHK53 (ORCPT ); Tue, 8 Dec 2020 05:57:29 -0500 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 6BF891FB; Tue, 8 Dec 2020 02:56:43 -0800 (PST) Received: from [10.57.34.152] (unknown [10.57.34.152]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4C6CA3F68F; Tue, 8 Dec 2020 02:56:41 -0800 (PST) Subject: Re: [PATCH v4 3/4] scmi-cpufreq: get opp_shared_cpus from opp-v2 for EM To: Viresh Kumar Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org, devicetree@vger.kernel.org, sudeep.holla@arm.com, rjw@rjwysocki.net, vireshk@kernel.org, robh+dt@kernel.org, sboyd@kernel.org, nm@ti.com, daniel.lezcano@linaro.org, morten.rasmussen@arm.com, chris.redpath@arm.com References: <20201202172356.10508-1-nicola.mazzucato@arm.com> <20201202172356.10508-4-nicola.mazzucato@arm.com> <20201208055053.kggxw26kxtnpneua@vireshk-i7> <0e4d3134-f9b2-31fa-b454-fb30265a80b5@arm.com> <20201208072611.ptsqupv4y2wybs6p@vireshk-i7> From: Nicola Mazzucato Message-ID: <83b8400f-8dc4-000e-d790-0bf584a75f48@arm.com> Date: Tue, 8 Dec 2020 10:58:44 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20201208072611.ptsqupv4y2wybs6p@vireshk-i7> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/8/20 7:26 AM, Viresh Kumar wrote: > On 08-12-20, 07:22, Nicola Mazzucato wrote: >> On 12/8/20 5:50 AM, Viresh Kumar wrote: >>> On 02-12-20, 17:23, Nicola Mazzucato wrote: >>>> nr_opp = dev_pm_opp_get_opp_count(cpu_dev); >>>> if (nr_opp <= 0) { >>>> - dev_dbg(cpu_dev, "OPP table is not ready, deferring probe\n"); >>>> - ret = -EPROBE_DEFER; >>>> - goto out_free_opp; >>>> + ret = handle->perf_ops->device_opps_add(handle, cpu_dev); >>>> + if (ret) { >>>> + dev_warn(cpu_dev, "failed to add opps to the device\n"); >>>> + goto out_free_cpumask; >>>> + } >>>> + >>>> + ret = dev_pm_opp_set_sharing_cpus(cpu_dev, opp_shared_cpus); >>>> + if (ret) { >>>> + dev_err(cpu_dev, "%s: failed to mark OPPs as shared: %d\n", >>>> + __func__, ret); >>>> + goto out_free_cpumask; >>>> + } >>>> + >>> >>> Why do we need to call above two after calling >>> dev_pm_opp_get_opp_count() ? >> >> Sorry, I am not sure to understand your question here. If there are no opps for >> a device we want to add them to it > > Earlier we used to call handle->perf_ops->device_opps_add() and > dev_pm_opp_set_sharing_cpus() before calling dev_pm_opp_get_opp_count(), why is > the order changed now ? True. The order has changed to take into account the fact that when we have per-cpu + opp-shared, we don't need to add opps for devices which already have them. > >> otherwise no need as they would be duplicated. > > I am not sure why they would be duplicated in your case. I though > device_opps_add() is responsible for dynamically adding the OPPs here. In case of per-cpu + opp-shared, with the "previous order" we would try to add opps to a device which already has them, in fact attempting to add duplicates. Nothing wrong with it, but a lot of warnings are thrown. > >>> And we don't check the return value of >>> the below call anymore, moreover we have to call it twice now. >> >> This second get_opp_count is required such that we register em with the correct >> opp number after having added them. Without this the opp_count would not be correct. > > What if the count is still 0 ? What about deferred probe we were doing earlier ? My assumption is to rely on the two above to fail if there was something wrong. For the deferred probe, I am not sure it is still a useful case to have, but I will let Sudeep have his view also on this. > Thanks Viresh, hope it's a bit more clear now. Nicola 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 8B46FC4361B for ; Tue, 8 Dec 2020 10:58:01 +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 4F29923AA9 for ; Tue, 8 Dec 2020 10:58:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4F29923AA9 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: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=a0aAp/+9LmzP55Htt6hU91nslZbKC8mOb9H0sITAY24=; b=i5cbFE/kU/dKG2CLZwENtv7BA Lc0z6k1PEANo0ic0m6mvQo0ir/WspJTIdxPYwsiQFP1t96oAvgQXYTG83uJqRT6k6JqO9UfLlaQzS ljimvAo6vx0nR1vA3ngtDzjHEy4pVhC1ltRJDhsYwFNgwk4NzZx4j6v3uxWaYuNOh0w2h+89dN3zV iODAiaNM1Hs0PY7eOas6MEXyDHGGKo+1yIX5JmfM53ac4dVUA+ihZhQ0BdUfioOIMCuipKfwM0l+E OAYvxNvZr7dit/snhtDbUMR5ZQqWl7eVj/TSoUonW+THjNmEsIjSNNv4//3pES2TRUvqULio2KwCu jgHkBe6rQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kmafr-0004WK-Np; Tue, 08 Dec 2020 10:56:51 +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 1kmafo-0004W1-Rk for linux-arm-kernel@lists.infradead.org; Tue, 08 Dec 2020 10:56:49 +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 6BF891FB; Tue, 8 Dec 2020 02:56:43 -0800 (PST) Received: from [10.57.34.152] (unknown [10.57.34.152]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4C6CA3F68F; Tue, 8 Dec 2020 02:56:41 -0800 (PST) Subject: Re: [PATCH v4 3/4] scmi-cpufreq: get opp_shared_cpus from opp-v2 for EM To: Viresh Kumar References: <20201202172356.10508-1-nicola.mazzucato@arm.com> <20201202172356.10508-4-nicola.mazzucato@arm.com> <20201208055053.kggxw26kxtnpneua@vireshk-i7> <0e4d3134-f9b2-31fa-b454-fb30265a80b5@arm.com> <20201208072611.ptsqupv4y2wybs6p@vireshk-i7> From: Nicola Mazzucato Message-ID: <83b8400f-8dc4-000e-d790-0bf584a75f48@arm.com> Date: Tue, 8 Dec 2020 10:58:44 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20201208072611.ptsqupv4y2wybs6p@vireshk-i7> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201208_055648_989895_58CBBA43 X-CRM114-Status: GOOD ( 24.04 ) 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: nm@ti.com, devicetree@vger.kernel.org, linux-pm@vger.kernel.org, sboyd@kernel.org, vireshk@kernel.org, daniel.lezcano@linaro.org, rjw@rjwysocki.net, linux-kernel@vger.kernel.org, robh+dt@kernel.org, sudeep.holla@arm.com, 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 On 12/8/20 7:26 AM, Viresh Kumar wrote: > On 08-12-20, 07:22, Nicola Mazzucato wrote: >> On 12/8/20 5:50 AM, Viresh Kumar wrote: >>> On 02-12-20, 17:23, Nicola Mazzucato wrote: >>>> nr_opp = dev_pm_opp_get_opp_count(cpu_dev); >>>> if (nr_opp <= 0) { >>>> - dev_dbg(cpu_dev, "OPP table is not ready, deferring probe\n"); >>>> - ret = -EPROBE_DEFER; >>>> - goto out_free_opp; >>>> + ret = handle->perf_ops->device_opps_add(handle, cpu_dev); >>>> + if (ret) { >>>> + dev_warn(cpu_dev, "failed to add opps to the device\n"); >>>> + goto out_free_cpumask; >>>> + } >>>> + >>>> + ret = dev_pm_opp_set_sharing_cpus(cpu_dev, opp_shared_cpus); >>>> + if (ret) { >>>> + dev_err(cpu_dev, "%s: failed to mark OPPs as shared: %d\n", >>>> + __func__, ret); >>>> + goto out_free_cpumask; >>>> + } >>>> + >>> >>> Why do we need to call above two after calling >>> dev_pm_opp_get_opp_count() ? >> >> Sorry, I am not sure to understand your question here. If there are no opps for >> a device we want to add them to it > > Earlier we used to call handle->perf_ops->device_opps_add() and > dev_pm_opp_set_sharing_cpus() before calling dev_pm_opp_get_opp_count(), why is > the order changed now ? True. The order has changed to take into account the fact that when we have per-cpu + opp-shared, we don't need to add opps for devices which already have them. > >> otherwise no need as they would be duplicated. > > I am not sure why they would be duplicated in your case. I though > device_opps_add() is responsible for dynamically adding the OPPs here. In case of per-cpu + opp-shared, with the "previous order" we would try to add opps to a device which already has them, in fact attempting to add duplicates. Nothing wrong with it, but a lot of warnings are thrown. > >>> And we don't check the return value of >>> the below call anymore, moreover we have to call it twice now. >> >> This second get_opp_count is required such that we register em with the correct >> opp number after having added them. Without this the opp_count would not be correct. > > What if the count is still 0 ? What about deferred probe we were doing earlier ? My assumption is to rely on the two above to fail if there was something wrong. For the deferred probe, I am not sure it is still a useful case to have, but I will let Sudeep have his view also on this. > Thanks Viresh, hope it's a bit more clear now. Nicola _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel