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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 45FE7C4332F for ; Tue, 18 Oct 2022 10:30:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229556AbiJRKar (ORCPT ); Tue, 18 Oct 2022 06:30:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55856 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229894AbiJRKaq (ORCPT ); Tue, 18 Oct 2022 06:30:46 -0400 Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 797658F954 for ; Tue, 18 Oct 2022 03:30:42 -0700 (PDT) Received: by mail-pg1-x52e.google.com with SMTP id r18so12905625pgr.12 for ; Tue, 18 Oct 2022 03:30:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=exg8qK7HbANK8LGW8V7Sf+Nbz3fOY3t3f61wcS0cpmU=; b=bwI1fqtxthcSt+uCO30znii+gfNeb5Q3uZ7GcmLwoC3d649+jbF8Ow3LyM7hk2IvuZ cLK+JkAdD54eOh2j6QV0/FJcL6wkMID6ihFlcV/rqJFPKeZ3Ak/fCTBhL4rCp7zhKgZN fM3mzoJAbfE3YkVKnfOJFKiItq1wQsghsle+UFshysohGg7t8WEEn+Jrk/D58LL7J6CZ aHg9jAruVGlQNvXe15cht5jDlXIW/pDhN6Q2DVXNtI3YOeqRQXT9j3l06mthM9P0cQU2 PF5zrbpJqU3dsdtfa4ONsclOwLxmLlXWfrqhIyCE9NELiLdPn00n5ay1VQ85N6YepgzZ WSTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=exg8qK7HbANK8LGW8V7Sf+Nbz3fOY3t3f61wcS0cpmU=; b=B6ViAnn6t5ziph1v96qyyIuJJOmorvAT2Ofz7rDC1HLOBghLJ4bbMJefzbqrnREcp3 tnNRESFQNI4t9GgMCUN70vDx1bHNpIkY50ECxH6Mpii87m49WZn24Bl/cF9zNmQoGKc3 R+uVcWDQieNOTQNJdZ4QyJ747I1BPYZ+l7/Mkuwk2kqX/dzWqW5ZlxWn0nRtfGjOOGug /nGzzDv80Po+WlDvRR+GVrdpkAmnviSL6OiQQUmkyFP08mUlYMUchTce+ok5/BsA/AFg iqZQ4gRSGXch0G7BmlNg8Ktpvmdb2ZTR7oFAQKQse2xiTBOLanT9UG0tfpDz+ZmdBAey W2ew== X-Gm-Message-State: ACrzQf03JAJDMkVh7ld1xmAIHPBy9Rg7jLZbyYvRcwu78NZdlk3p6diE M7wU8LXgrmraFsVJMrVU90NbzNrnNskvMisQxVxgeA== X-Google-Smtp-Source: AMsMyM5BLMlVQf/WZNomvvuRQgyN2ps9/NivHtmdRTqq88wmho9EPNZIly4CEni5YeJKoAVezylqg9ThesITq5rux/k= X-Received: by 2002:a63:464d:0:b0:441:5968:cd0e with SMTP id v13-20020a63464d000000b004415968cd0emr2101209pgk.595.1666089041982; Tue, 18 Oct 2022 03:30:41 -0700 (PDT) MIME-Version: 1.0 References: <20221017164005.2622934-1-amit.pundir@linaro.org> <20221017201654.u7x5vrjsad653kma@bogus> In-Reply-To: <20221017201654.u7x5vrjsad653kma@bogus> From: Ulf Hansson Date: Tue, 18 Oct 2022 12:30:04 +0200 Message-ID: Subject: Re: [PATCH] Revert "arm64: dts: qcom: sm8250: Add cpuidle states" To: Amit Pundir , Sudeep Holla Cc: Bjorn Andersson , Andy Gross , Maulik Shah , Dmitry Baryshkov , Rob Herring , Konrad Dybcio , Krzysztof Kozlowski , linux-arm-msm , dt , lkml Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Mon, 17 Oct 2022 at 22:17, Sudeep Holla wrote: > > On Mon, Oct 17, 2022 at 10:10:05PM +0530, Amit Pundir wrote: > > This reverts commit 32bc936d732171d48c9c8f96c4fa25ac3ed7e1c7. > > > > This patch was part of a patch series to add APSS RSC to > > Cluster power domain > > https://patchwork.kernel.org/project/linux-pm/cover/1641749107-31979-1-git-send-email-quic_mkshah@quicinc.com/ > > but the rest of the patches in this series got NACKed and didn't land. > > > > These cpuidle states made RB5 (sm8250) highly unstable and I run into > > following crash every now and then: > > > > [ T1] vreg_l11c_3p3: failed to enable: -ETIMEDOUT > > [ T1] qcom-rpmh-regulator 18200000.rsc:pm8150l-rpmh-regulators: ldo11: devm_regulator_register() failed, ret=-110 > > [ T1] qcom-rpmh-regulator: probe of 18200000.rsc:pm8150l-rpmh-regulators failed with error -110 > > > > I reported this breakage earlier this year as well: > > https://lore.kernel.org/all/CAMi1Hd2Sngya_2m2odkjq4fdV8OiiXsFMEX1bb807cWMC7H-sg@mail.gmail.com/ > > I can confirm that if I cherry-pick the rest of the patches from the > > series then I can't reproduce this crash, but I'm not sure when the rest > > of the patches are going to land though. I have been talking to Maulik (offlist) about re-posting the series, but apparently she has been too busy to move this forward. I assume a better option, than reverting, is to get the above series merged. If I recall, there were only a few minor comments from me on the genpd patch [1]. That said, let me help out and refresh the series, I will do it asap! > > > > Signed-off-by: Amit Pundir > > --- > > arch/arm64/boot/dts/qcom/sm8250.dtsi | 105 --------------------------- > > 1 file changed, 105 deletions(-) > > > > diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi b/arch/arm64/boot/dts/qcom/sm8250.dtsi > > index a5b62cadb129..a2c15da1a450 100644 > > --- a/arch/arm64/boot/dts/qcom/sm8250.dtsi > > +++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi > > @@ -101,8 +101,6 @@ CPU0: cpu@0 { > > capacity-dmips-mhz = <448>; > > dynamic-power-coefficient = <205>; > > next-level-cache = <&L2_0>; > > - power-domains = <&CPU_PD0>; > > - power-domain-names = "psci"; > > qcom,freq-domain = <&cpufreq_hw 0>; > > operating-points-v2 = <&cpu0_opp_table>; > > interconnects = <&gem_noc MASTER_AMPSS_M0 &mc_virt SLAVE_EBI_CH0>, > > @@ -125,8 +123,6 @@ CPU1: cpu@100 { > > capacity-dmips-mhz = <448>; > > dynamic-power-coefficient = <205>; > > next-level-cache = <&L2_100>; > > - power-domains = <&CPU_PD1>; > > - power-domain-names = "psci"; > > qcom,freq-domain = <&cpufreq_hw 0>; > > operating-points-v2 = <&cpu0_opp_table>; > > interconnects = <&gem_noc MASTER_AMPSS_M0 &mc_virt SLAVE_EBI_CH0>, > > @@ -146,8 +142,6 @@ CPU2: cpu@200 { > > capacity-dmips-mhz = <448>; > > dynamic-power-coefficient = <205>; > > next-level-cache = <&L2_200>; > > - power-domains = <&CPU_PD2>; > > - power-domain-names = "psci"; > > qcom,freq-domain = <&cpufreq_hw 0>; > > operating-points-v2 = <&cpu0_opp_table>; > > interconnects = <&gem_noc MASTER_AMPSS_M0 &mc_virt SLAVE_EBI_CH0>, > > @@ -167,8 +161,6 @@ CPU3: cpu@300 { > > capacity-dmips-mhz = <448>; > > dynamic-power-coefficient = <205>; > > next-level-cache = <&L2_300>; > > - power-domains = <&CPU_PD3>; > > - power-domain-names = "psci"; > > qcom,freq-domain = <&cpufreq_hw 0>; > > operating-points-v2 = <&cpu0_opp_table>; > > interconnects = <&gem_noc MASTER_AMPSS_M0 &mc_virt SLAVE_EBI_CH0>, > > @@ -188,8 +180,6 @@ CPU4: cpu@400 { > > capacity-dmips-mhz = <1024>; > > dynamic-power-coefficient = <379>; > > next-level-cache = <&L2_400>; > > - power-domains = <&CPU_PD4>; > > - power-domain-names = "psci"; > > qcom,freq-domain = <&cpufreq_hw 1>; > > operating-points-v2 = <&cpu4_opp_table>; > > interconnects = <&gem_noc MASTER_AMPSS_M0 &mc_virt SLAVE_EBI_CH0>, > > @@ -209,8 +199,6 @@ CPU5: cpu@500 { > > capacity-dmips-mhz = <1024>; > > dynamic-power-coefficient = <379>; > > next-level-cache = <&L2_500>; > > - power-domains = <&CPU_PD5>; > > - power-domain-names = "psci"; > > qcom,freq-domain = <&cpufreq_hw 1>; > > operating-points-v2 = <&cpu4_opp_table>; > > interconnects = <&gem_noc MASTER_AMPSS_M0 &mc_virt SLAVE_EBI_CH0>, > > @@ -231,8 +219,6 @@ CPU6: cpu@600 { > > capacity-dmips-mhz = <1024>; > > dynamic-power-coefficient = <379>; > > next-level-cache = <&L2_600>; > > - power-domains = <&CPU_PD6>; > > - power-domain-names = "psci"; > > qcom,freq-domain = <&cpufreq_hw 1>; > > operating-points-v2 = <&cpu4_opp_table>; > > interconnects = <&gem_noc MASTER_AMPSS_M0 &mc_virt SLAVE_EBI_CH0>, > > @@ -252,8 +238,6 @@ CPU7: cpu@700 { > > capacity-dmips-mhz = <1024>; > > dynamic-power-coefficient = <444>; > > next-level-cache = <&L2_700>; > > - power-domains = <&CPU_PD7>; > > - power-domain-names = "psci"; > > qcom,freq-domain = <&cpufreq_hw 2>; > > operating-points-v2 = <&cpu7_opp_table>; > > interconnects = <&gem_noc MASTER_AMPSS_M0 &mc_virt SLAVE_EBI_CH0>, > > @@ -300,42 +284,6 @@ core7 { > > }; > > }; > > }; > > - > > - idle-states { > > - entry-method = "psci"; > > - > > - LITTLE_CPU_SLEEP_0: cpu-sleep-0-0 { > > - compatible = "arm,idle-state"; > > - idle-state-name = "silver-rail-power-collapse"; > > - arm,psci-suspend-param = <0x40000004>; > > - entry-latency-us = <360>; > > - exit-latency-us = <531>; > > - min-residency-us = <3934>; > > - local-timer-stop; > > If this is temporary fix for some broke firmware or setup, I suggest to > just add status = "disabled" for these states. Also worth checking if keeping > the cpu states is okay and only cluster state is the issue or everything > needs to be disabled. That way it would avoid the churn when re-enabling it. That's a good option, unless we can get the other series (that fixes this issue) merged soon. As stated, I will help to re-spin it and then we can take it from there. > > -- > Regards, > Sudeep Kind regards Uffe