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 CE95AC77B7A for ; Wed, 7 Jun 2023 07:51:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239425AbjFGHv3 (ORCPT ); Wed, 7 Jun 2023 03:51:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41884 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239373AbjFGHvA (ORCPT ); Wed, 7 Jun 2023 03:51:00 -0400 Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2B27D2D57 for ; Wed, 7 Jun 2023 00:49:10 -0700 (PDT) Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-9745d99cfccso977510766b.1 for ; Wed, 07 Jun 2023 00:49:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1686124148; x=1688716148; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=sUmif8+PJuo1t9H5/fS1dgHw3TEAkR2eQjvlt4ezA7Y=; b=P//BIhq2msQubwmODXxKb6JMeyvTjBvQ7lbTXY2gQ08CaAF0kghL3k6b9lqkt8FzMC l5d1TtpqSOvfyUtwOs6t9fJGjGr6OAOOFCr8KdA/0CiuTDZGpOw9QcDvrVghXtVi5/Ua jfBXi0gYHDWW8D+3aXrjQg47fdqv19wnx5RGN79FZcRb1uKUjriNk1SbCDUdcw944Mm7 eHpxaVbt/HIWxvO6ffpXA8QYIF9JLhWdqZIp8x00pl4dGrrFpm3Z/1Qdb/epsMjWiZra hVk+egKKHJOATS9i7uAE2hJh02f8jyO5P3Y22+OSefH1M/AU6I9MT47/6vczZqSfdLbZ UBvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686124148; x=1688716148; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=sUmif8+PJuo1t9H5/fS1dgHw3TEAkR2eQjvlt4ezA7Y=; b=ZHkBSWmUKzWGnekqUznLR5gnc2XUvPM1vJgutddMN6OSoe13pRi+svow8+mIh+Hgw2 v+DbHFHoHDgcEZW9qRWP86/pj3QQbFP3k/yfyd/Tt06guD6+ATkUY+TG8D9eiSN546/S JBFPEWj4JLFcQXkTPXM+wItUvdL2YycAVrPodhPVVHGf6UPTcsJm1W0i89xvPLO6HhWM f+Iah9UeVV0GDioPQ1FO7EEzTtVosd0BbcjCOhSb38L6LDSJAcuMYpGGM4STWfD2BiNQ KamG75z4qnRa4p4gtZD7aXcIpHdwA9FqjTaUp24nSpW2HReRXZJ1d5KYLko4B0A7B4BR /vQg== X-Gm-Message-State: AC+VfDyOnfw3Yj6IRnNpJVzm738zMWrAl/mzQQG3rVjJ/IK9qIqdaSgE of9V+KrSlmvSXxoaClRlmjFWlA== X-Google-Smtp-Source: ACHHUZ4tHicUEQZZDx3qvkqytJ1UUjgre5Dp5VZ4TgLhAgMrJ77wvl2/vrm+tWipBTJaMBWuLCjwNw== X-Received: by 2002:a17:907:6e0d:b0:974:c32c:b485 with SMTP id sd13-20020a1709076e0d00b00974c32cb485mr4637812ejc.45.1686124148561; Wed, 07 Jun 2023 00:49:08 -0700 (PDT) Received: from [192.168.1.20] ([178.197.219.26]) by smtp.gmail.com with ESMTPSA id x22-20020a1709060a5600b0096f6a131b9fsm6533605ejf.23.2023.06.07.00.49.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Jun 2023 00:49:08 -0700 (PDT) Message-ID: Date: Wed, 7 Jun 2023 09:49:06 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.2 Subject: Re: [PATCH] arm64: dts: qcom: sdm845-db845c: Move LVS regulator nodes up Content-Language: en-US To: Doug Anderson , Amit Pundir Cc: Mark Brown , Bjorn Andersson , Andy Gross , Rob Herring , Konrad Dybcio , Krzysztof Kozlowski , Caleb Connolly , Conor Dooley , regressions , linux-arm-msm , dt , lkml References: <20230602161246.1855448-1-amit.pundir@linaro.org> From: Krzysztof Kozlowski In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On 07/06/2023 01:34, Doug Anderson wrote: > Hi, > > On Fri, Jun 2, 2023 at 9:12 AM 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/CAMi1Hd1avQDcDQf137m2auz2znov4XL8YGrLZsw5edb-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/boot/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 = <&vreg_s3a_1p35>; >> vin-lvs-1-2-supply = <&vreg_s4a_1p8>; >> >> + vreg_lvs1a_1p8: lvs1 { >> + regulator-min-microvolt = <1800000>; >> + regulator-max-microvolt = <1800000>; >> + regulator-always-on; >> + }; >> + >> + vreg_lvs2a_1p8: lvs2 { >> + regulator-min-microvolt = <1800000>; >> + regulator-max-microvolt = <1800000>; >> + regulator-always-on; >> + }; >> + >> vreg_s3a_1p35: smps3 { >> regulator-min-microvolt = <1352000>; >> regulator-max-microvolt = <1352000>; >> @@ -381,18 +393,6 @@ vreg_l26a_1p2: ldo26 { >> regulator-max-microvolt = <1200000>; >> regulator-initial-mode = ; >> }; >> - >> - vreg_lvs1a_1p8: lvs1 { >> - regulator-min-microvolt = <1800000>; >> - regulator-max-microvolt = <1800000>; >> - regulator-always-on; >> - }; >> - >> - vreg_lvs2a_1p8: lvs2 { >> - regulator-min-microvolt = <1800000>; >> - regulator-max-microvolt = <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=FV=UKyjRNZG-ED2meUAR9aXdco+AbUTHiKixTzjCkaJbjTg@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? Best regards, Krzysztof