Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp483637rwd; Wed, 7 Jun 2023 02:46:19 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4ybdaJTRF6NfvQ8+yRfPqzira12c2G9N/TylY0tMWA3eAkEDz3jOYpnCjmelSmaL2j5Vfu X-Received: by 2002:a05:6a21:329c:b0:101:1e75:78e with SMTP id yt28-20020a056a21329c00b001011e75078emr2454364pzb.14.1686131179247; Wed, 07 Jun 2023 02:46:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1686131179; cv=none; d=google.com; s=arc-20160816; b=OhBBwLzr15gFrxCyoW5IIrhh5f5ysECQ6jVL7HBVDenNFX8SKvsmpzzl/BkvVZfckQ R59AVH6iBERciRnopPmnUY0eiyx+jqHZsRURstYr/nBFPEoqmHRFOC6xwBqnk0ZMsXVM m7WVYg8jBxNTwDy3GIfBJj8YleUmQCd5pdEnSKcO7OKyMvtuus/2IWDVXENrA+mydiIN f4e5YbhrQWDo7Yowm+i8dvARLZXdUV9oHrQPwhGNLAc88H8Xez1fIopCzzVMBOvmE6yQ Hc6SBIJQm+fdHWUWvbb1HFj0D1taE3ES8h+Sd2R3+DT3NBA+RREDPUAKyizbJ5L4A8mN dExA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=tL/PpO32/XApPqfzUVTE3O6ft3MNge9AqUMgAVH97Go=; b=i1mCHB1pgHrnd1yW4zMTe+MswJYTz30xG6nbgEckWbBE2UOSj37vO14UCyw5xE/a7K uf9+kVYGim3+g194fxfi+FZ0EgzHySpnEnO/vplkn4W983wtYpNzXnDfl9bVurRswsBO rjYAKhuLt5afWQfcA+U/Izh2J4alI1P981GKvdazvyKlzuTBfEIkoWJSsrB28xos2rhC yShoOEJdl4X5js7Bt/ShtmfGC2Z9aArHK+LNuQeDqvKQv10Rpi6U7VM6TozurHhB+MJX PhVi3PPEw/QyWjoDrfW+nS2R5O320J6DFsJcKrnulHEDooxaR8m9S8To8s6bHOlCBpvG l3Og== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=LA1NcZSM; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id w19-20020a637b13000000b00520dfb861fbsi3746523pgc.416.2023.06.07.02.46.06; Wed, 07 Jun 2023 02:46:19 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=LA1NcZSM; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239164AbjFGJRr (ORCPT + 99 others); Wed, 7 Jun 2023 05:17:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40428 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238520AbjFGJRp (ORCPT ); Wed, 7 Jun 2023 05:17:45 -0400 Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com [IPv6:2607:f8b0:4864:20::f2d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8706EEA for ; Wed, 7 Jun 2023 02:17:44 -0700 (PDT) Received: by mail-qv1-xf2d.google.com with SMTP id 6a1803df08f44-6260e771419so1658066d6.1 for ; Wed, 07 Jun 2023 02:17:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1686129463; x=1688721463; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=tL/PpO32/XApPqfzUVTE3O6ft3MNge9AqUMgAVH97Go=; b=LA1NcZSM698iSn60uFcQpBnfpJtIf8HrfDX45R7PrTAbr/4cqrBSDZveCLn5zpjE+J vA0rFAeJDMZkfXW1kY/f86Q5xjAxnBSmf0exIC0lTVn3mpC+ZLjkP6iF9OF0TC4I7/gz Aw1IMePf/uSCDYvq/j/EeIYt1ZGKVBtHdqblBHAi8/FONeLu7GoiGW4WPPaIfjqIUAB4 ccP4uVkGyd8Ak13o4sCeO1rbpzhdixbb0yohSbvAia8nb72kJG8lIlj//Y3zWq4TmT8c ebz/k+vohkq8mfIYeA9dOxeKrTORy2Qo68o9BSzfcMCf2xSrEkT3R2c3YoRczy3PpsbX vS4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686129463; x=1688721463; h=content-transfer-encoding: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=tL/PpO32/XApPqfzUVTE3O6ft3MNge9AqUMgAVH97Go=; b=Ls7fhpLUUN1BDgAGxhETk39nNo0a2iFr4P7lEI363SDGeQaPx8CI65hLjWKxvx4D/u NdDqJbt6S/CEWCatuj5vmYbYBgDxuzzKlW2Ue2255DPHXo0mScNFq/ctBD7kZ7kQ2vP7 pXcvQPEAJzayNSoMPplXQkAfj8ubiR7X+6y7c3dVMWfZU2aOJiy4kC1BE72sqYGbm4iH hTx1z4HtveyaLMe9uqbNEFT5hPr1y2gJPAJJNloUzXgUzqcRe9IRh06UTTYAzKXdKfa5 2GxZYKJXlSd1LMWxxe0RgfQYHpKqt+r4Xpl4etlvgr5EBR+Jef5CjRkm6HH54r5U0T9d nwUg== X-Gm-Message-State: AC+VfDyySKnl9O4it2c1X1laGxTlGBS48M3PLOdgQGlg7ip1lCe6CGKm WwDdKLK8UWORRe+oIJ/Htlg2hAHlVp/7SluAq5pu2A== X-Received: by 2002:a05:6214:2a84:b0:625:86ed:8aab with SMTP id jr4-20020a0562142a8400b0062586ed8aabmr2135830qvb.14.1686129463604; Wed, 07 Jun 2023 02:17:43 -0700 (PDT) MIME-Version: 1.0 References: <20230602161246.1855448-1-amit.pundir@linaro.org> In-Reply-To: From: Amit Pundir Date: Wed, 7 Jun 2023 14:47:07 +0530 Message-ID: Subject: Re: [PATCH] arm64: dts: qcom: sdm845-db845c: Move LVS regulator nodes up To: Krzysztof Kozlowski Cc: Doug Anderson , Mark Brown , Bjorn Andersson , Andy Gross , Rob Herring , Konrad Dybcio , Krzysztof Kozlowski , Caleb Connolly , Conor Dooley , regressions , linux-arm-msm , dt , lkml Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 7 Jun 2023 at 13:19, Krzysztof Kozlowski wrote: > > On 07/06/2023 01:34, Doug Anderson wrote: > > Hi, > > > > On Fri, Jun 2, 2023 at 9:12=E2=80=AFAM Amit Pundir wrote: > >> > >> Move lvs1 and lvs2 regulator nodes up in the rpmh-regulators > >> list to workaround a boot regression uncovered by the upstream > >> commit ad44ac082fdf ("regulator: qcom-rpmh: Revert "regulator: > >> qcom-rpmh: Use PROBE_FORCE_SYNCHRONOUS""). > >> > >> Without this fix DB845c fail to boot at times because one of the > >> lvs1 or lvs2 regulators fail to turn ON in time. > >> > >> Link: https://lore.kernel.org/all/CAMi1Hd1avQDcDQf137m2auz2znov4XL8YGr= LZsw5edb-NtRJRw@mail.gmail.com/ > >> Signed-off-by: Amit Pundir > >> --- > >> arch/arm64/boot/dts/qcom/sdm845-db845c.dts | 24 +++++++++++----------= - > >> 1 file changed, 12 insertions(+), 12 deletions(-) > >> > >> diff --git a/arch/arm64/boot/dts/qcom/sdm845-db845c.dts b/arch/arm64/b= oot/dts/qcom/sdm845-db845c.dts > >> index e14fe9bbb386..df2fde9063dc 100644 > >> --- a/arch/arm64/boot/dts/qcom/sdm845-db845c.dts > >> +++ b/arch/arm64/boot/dts/qcom/sdm845-db845c.dts > >> @@ -301,6 +301,18 @@ regulators-0 { > >> vdd-l26-supply =3D <&vreg_s3a_1p35>; > >> vin-lvs-1-2-supply =3D <&vreg_s4a_1p8>; > >> > >> + vreg_lvs1a_1p8: lvs1 { > >> + regulator-min-microvolt =3D <1800000>; > >> + regulator-max-microvolt =3D <1800000>; > >> + regulator-always-on; > >> + }; > >> + > >> + vreg_lvs2a_1p8: lvs2 { > >> + regulator-min-microvolt =3D <1800000>; > >> + regulator-max-microvolt =3D <1800000>; > >> + regulator-always-on; > >> + }; > >> + > >> vreg_s3a_1p35: smps3 { > >> regulator-min-microvolt =3D <1352000>; > >> regulator-max-microvolt =3D <1352000>; > >> @@ -381,18 +393,6 @@ vreg_l26a_1p2: ldo26 { > >> regulator-max-microvolt =3D <1200000>; > >> regulator-initial-mode =3D ; > >> }; > >> - > >> - vreg_lvs1a_1p8: lvs1 { > >> - regulator-min-microvolt =3D <1800000>; > >> - regulator-max-microvolt =3D <1800000>; > >> - regulator-always-on; > >> - }; > >> - > >> - vreg_lvs2a_1p8: lvs2 { > >> - regulator-min-microvolt =3D <1800000>; > >> - regulator-max-microvolt =3D <1800000>; > >> - regulator-always-on; > >> - }; > > > > This is a hack, but it at least feels less bad than reverting the > > async probe patch. I'll leave it to Bjorn to decide if he's OK with > > it. Personally, it feels like this would deserve a comment in the dts > > to document that these regulators need to be listed first. > > > > Ideally, we could still work towards a root cause. I added a few more > > ideas to help with root causing in reply to the original thread about > > this. > > > > https://lore.kernel.org/r/CAD=3DFV=3DUKyjRNZG-ED2meUAR9aXdco+AbUTHiKixT= zjCkaJbjTg@mail.gmail.com/ > > We do not shape DTS based on given OS behavior. AOSP needs this, BSD > needs that and Linux needs something else. Next time someone will move > these regulators down because on his system probing is from end of list, > not beginning and he has the same problem. > > No, really, are we going to reshuffle nodes because AOSP needs it? Hi, other than the fact that I reproduced it on AOSP, there is nothing AOSP specific in this patch. I'm sure there may be another platforms/OS (which load kernel modules from a ramdisk) that may trip on this bug. But I can try reproducing it on an OS of your choice if it helps. Regards, Amit Pundir > > Best regards, > Krzysztof >