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 2EBCCC7EE23 for ; Wed, 7 Jun 2023 07:51:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239368AbjFGHv3 (ORCPT ); Wed, 7 Jun 2023 03:51:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43528 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239369AbjFGHvA (ORCPT ); Wed, 7 Jun 2023 03:51:00 -0400 Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2A59A272D for ; Wed, 7 Jun 2023 00:49:10 -0700 (PDT) Received: by mail-ej1-x62d.google.com with SMTP id a640c23a62f3a-973f78329e3so1139553866b.3 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=cxEJWLLQmydGpVgwGPGILH9PI1kB57u5q+XP192dnLiImYIDnCnkhxM6QNu3I4i9ZW Jnp/ESymraOp4sm3cS48RWHFBpe9h4et/zQVJ/XQjV+hpkWthBUTIgA9n5sVNI9fGJMQ EacMQsSTUaen1ioEdF/R/+Flm1H2zuJmKAe6JK/DCLC5Euyny1oWQnuiZ1GDKYYHUGGm ephCn3NRH1IeoAhobpUFox6aeSwRMf2E+MJCRr1FLA70+f1RLD9HOY2lOQt+gk33ExFx gwHnJjfQbQjqdV66cyv60voeBLyLW6k4N8zlIJndCx7XP3EutP69Tb1wAnZdd8bCdzxg nf6Q== X-Gm-Message-State: AC+VfDw2C4mPc4cJeKHSYGWlpPn83x5qdMexAF/2eIl6ZvSV2V6KpsTZ KjATO+78fsNnrKO+GV7J2SwLpw== 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: devicetree@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