From patchwork Wed Nov 30 08:05:43 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 84967 Delivered-To: patch@linaro.org Received: by 10.140.20.101 with SMTP id 92csp127472qgi; Wed, 30 Nov 2016 00:05:49 -0800 (PST) X-Received: by 10.98.194.130 with SMTP id w2mr31585214pfk.143.1480493149693; Wed, 30 Nov 2016 00:05:49 -0800 (PST) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l186si63158446pgd.327.2016.11.30.00.05.49; Wed, 30 Nov 2016 00:05:49 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@linaro.org; spf=pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=stable-owner@vger.kernel.org; dmarc=fail (p=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754663AbcK3IFs (ORCPT + 3 others); Wed, 30 Nov 2016 03:05:48 -0500 Received: from mail-pg0-f47.google.com ([74.125.83.47]:32964 "EHLO mail-pg0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753043AbcK3IFr (ORCPT ); Wed, 30 Nov 2016 03:05:47 -0500 Received: by mail-pg0-f47.google.com with SMTP id 3so79569589pgd.0 for ; Wed, 30 Nov 2016 00:05:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=fYWUvmPU1mhVuZri3jC1510z4zYccZXo/on7a23j8pk=; b=IunFiso9S1Y/oUTmfAqqaoH+GGYYRWa6VUDZH5Z8g6GuGhYa0YjUsLRVJWrKyW1Nqp kfffjEXGt2F1bbUvGTPwadtt5h+EDCnESjOl2nw/+e6ByrCjiXmeT8TYIdezqRggSwus pg2V7Mgnqxdiuim9/lxQtBMoE8ZVdtlkdD4LY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=fYWUvmPU1mhVuZri3jC1510z4zYccZXo/on7a23j8pk=; b=bfA7Lohm68JymSb7qTDjGevjbzsuT41msESduMZob3TQxwo/qyYRt0xDHMFOi5CpkF CP49vBlzYle3n7ecPIZwRMvly7UgPZWm5qhCcV87S3sqUVKul9R2H65cht3kWa82od9r AURc7iR995JdchDc2ooOinniRI+RUSjt2KaS66FsR5Ag2eo5g2X/KhyK9IePf8NPhSoj 1Y3paGk7Hl29LTx0rX2LXqdJIjLqYiYAVp71RqfEn0UIgwYOLrBWbTpD3Tl5fyomJBpo YrsOX8UjJrkRqYhYIzkIBPO/fCGplJTxxMHA3bAzljYOraDIvCoR1zlIQGD9Pvl6/OTW 9FAA== X-Gm-Message-State: AKaTC03ThKUFoWiLpn5NCrX/hn2bm21J+1zKI+YA0E/sTIeMt1ffJB19+GfyS/qX3UVyS3r6 X-Received: by 10.84.171.228 with SMTP id l91mr70819519plb.4.1480493146351; Wed, 30 Nov 2016 00:05:46 -0800 (PST) Received: from localhost ([122.172.143.30]) by smtp.gmail.com with ESMTPSA id l7sm100370162pfg.35.2016.11.30.00.05.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Nov 2016 00:05:45 -0800 (PST) Date: Wed, 30 Nov 2016 13:35:43 +0530 From: Viresh Kumar To: Joonyoung Shim Cc: Rafael Wysocki , Viresh Kumar , Nishanth Menon , Stephen Boyd , linaro-kernel@lists.linaro.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, Vincent Guittot , "# v4 . 4+" Subject: Re: [PATCH V4] PM / OPP: Pass opp_table to dev_pm_opp_put_regulator() Message-ID: <20161130080543.GJ3288@vireshk-i7> References: <480ae6e161788d338fb1637aa2615a75588ac3c6.1480478081.git.viresh.kumar@linaro.org> <583E6F88.9010805@samsung.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <583E6F88.9010805@samsung.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On 30-11-16, 15:19, Joonyoung Shim wrote: > Hi Viresh, > > On 11/30/2016 12:59 PM, Viresh Kumar wrote: > > From: Stephen Boyd > > > > Joonyoung Shim reported an interesting problem on his ARM octa-core > > Odoroid-XU3 platform. During system suspend, dev_pm_opp_put_regulator() > > was failing for a struct device for which dev_pm_opp_set_regulator() is > > called earlier. > > > > This happened because an earlier call to > > dev_pm_opp_of_cpumask_remove_table() function (from cpufreq-dt.c file) > > removed all the entries from opp_table->dev_list apart from the last CPU > > device in the cpumask of CPUs sharing the OPP. > > > > But both dev_pm_opp_set_regulator() and dev_pm_opp_put_regulator() > > routines get CPU device for the first CPU in the cpumask. And so the OPP > > core failed to find the OPP table for the struct device. > > > > In order to fix that up properly, we need to revisit APIs like > > dev_pm_opp_set_regulator() and make them talk in terms of cookies > > provided by the OPP core. But such a solution will be hard to backport > > to stable kernels. > > > > This patch attempts to fix this problem by returning a pointer to the > > opp_table from dev_pm_opp_set_regulator() and using that as the > > parameter to dev_pm_opp_put_regulator(). This ensures that the > > dev_pm_opp_put_regulator() doesn't fail to find the opp table. > > > > Note that similar design problem also exists with other > > dev_pm_opp_put_*() APIs, but those aren't used currently by anyone and > > so we don't need to update them for now. > > > > [Viresh]: Written commit log, minor improvements in the patch and tested > > on exynos 5250. > > > > Cc: # v4.4+ > > Reported-by: Joonyoung Shim > > Signed-off-by: Stephen Boyd > > Signed-off-by: Viresh Kumar > > --- > > V3->V4: > > - Completely different approach, suggested earlier by Stephen. > > - Can be merged safely now as both /me and Stephen agree to this one. > > > > @Joonyoung: Can you please test this last patch please ? > > > > Just system suspend/resume is working Should I consider that as a Tested-by from you for the problem you reported at least ? > but i was missing below test case > that you inform when i test for prior patches on my Odroid-XU3 board. > > - offline CPU 4 > - suspend the system > > With this test case, now all patches posted have the problem that is > failed to get clk: -2. That probably happens because your DT isn't good enough. Following DT change may fix it for you: -- viresh -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/arch/arm/boot/dts/exynos5422-cpus.dtsi b/arch/arm/boot/dts/exynos5422-cpus.dtsi index bf3c6f1ec4ee..998a7dad95fc 100644 --- a/arch/arm/boot/dts/exynos5422-cpus.dtsi +++ b/arch/arm/boot/dts/exynos5422-cpus.dtsi @@ -41,6 +41,7 @@ device_type = "cpu"; compatible = "arm,cortex-a7"; reg = <0x101>; + clocks = <&clock CLK_KFC_CLK>; clock-frequency = <1000000000>; cci-control-port = <&cci_control0>; operating-points-v2 = <&cluster_a7_opp_table>; @@ -53,6 +54,7 @@ device_type = "cpu"; compatible = "arm,cortex-a7"; reg = <0x102>; + clocks = <&clock CLK_KFC_CLK>; clock-frequency = <1000000000>; cci-control-port = <&cci_control0>; operating-points-v2 = <&cluster_a7_opp_table>; @@ -65,6 +67,7 @@ device_type = "cpu"; compatible = "arm,cortex-a7"; reg = <0x103>; + clocks = <&clock CLK_KFC_CLK>; clock-frequency = <1000000000>; cci-control-port = <&cci_control0>; operating-points-v2 = <&cluster_a7_opp_table>; @@ -89,6 +92,7 @@ cpu5: cpu@1 { device_type = "cpu"; compatible = "arm,cortex-a15"; + clocks = <&clock CLK_ARM_CLK>; reg = <0x1>; clock-frequency = <1800000000>; cci-control-port = <&cci_control1>; @@ -101,6 +105,7 @@ cpu6: cpu@2 { device_type = "cpu"; compatible = "arm,cortex-a15"; + clocks = <&clock CLK_ARM_CLK>; reg = <0x2>; clock-frequency = <1800000000>; cci-control-port = <&cci_control1>; @@ -113,6 +118,7 @@ cpu7: cpu@3 { device_type = "cpu"; compatible = "arm,cortex-a15"; + clocks = <&clock CLK_ARM_CLK>; reg = <0x3>; clock-frequency = <1800000000>; cci-control-port = <&cci_control1>;