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 50C4CC64EC4 for ; Fri, 3 Mar 2023 13:27:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230042AbjCCN1H (ORCPT ); Fri, 3 Mar 2023 08:27:07 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33532 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229942AbjCCN1G (ORCPT ); Fri, 3 Mar 2023 08:27:06 -0500 Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 63D4330295 for ; Fri, 3 Mar 2023 05:27:04 -0800 (PST) Received: by mail-lj1-x231.google.com with SMTP id b10so2374927ljr.0 for ; Fri, 03 Mar 2023 05:27:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1677850022; 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=/nJxtHbroqM/Ddx9d2oTpdj+DoHaP62srzKbXybL1GM=; b=tOA+O0cflEFx2RiZ8FbGpJxq3lOPnlQZp3jQKLtpqZ89uCM2+XBlHDTE73gAO5/5O+ 4Bo8rbgQRGp2KIisrWeyx+y6Xhujt9oOYr/R2SgLt3CjSKLrSF/b8PBJFXN4dCUOUM1u KkNBJ22AlA/YclVMrHDKMjuxooxXPeFE0j14ukk6Z6tGhKNTxqQW7S2G3M6haNpiPUZn 8FHpJpLKpmh9y8OWX3ydBAuVjOFO1IdzINE9JM/KVDMiguNT/QUhCBgYca9WcFqdW2g8 KsGB/rbUQIx1rCUIM/zsX3SRZQnldIz6MeaGtqPK/KI/k1Rb+LQDq13/3J8z/wjG5gOG Xwwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677850022; 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=/nJxtHbroqM/Ddx9d2oTpdj+DoHaP62srzKbXybL1GM=; b=nFfkVEBt/nUpVJciOHMKbUuxOi/gpxDmHns72HKyzK5ZllkRMUbNEnAkcPWMU+cJk/ mg0VK/UjXKP2ytiAwua4vHM2wryWXAWFjnPQENThKyR5g8hhZINVDd4IYte8R5T5nDFA nigVIAELkjEHlAzY4AfwyVorLcBvLHaVILXHdYuAc49MhRqM9zC4Nxrpga6OvO7zZOG5 tcZHIHr4vUAOe3iuNYy/zi4ol8rrBY2fiASUOkrJOP9QoO9HzzqeCfBUVcwIJ1RLNHLd Qp38hDYxG0EbVi2p5jzNeApuSxYkQ2ZmmXcTOKXduy3HzmO27dUZEPUvkwUpJ4HcXTD+ V9zA== X-Gm-Message-State: AO0yUKXySkIm9xly2MJCPL7WcacjiBxMWdopU8hwqchzBG2GZdi3AW38 vP0CKOW38x+7rsfeQL66AhS9kQ== X-Google-Smtp-Source: AK7set9iwZOEO26r8kgcdgCsken1oZY71ltNn1/FRGVYWoSjGmN8yVUO/iHWh8bm9KIrEwSPqoOP8w== X-Received: by 2002:a2e:881a:0:b0:27f:c02b:a04b with SMTP id x26-20020a2e881a000000b0027fc02ba04bmr576543ljh.42.1677850022557; Fri, 03 Mar 2023 05:27:02 -0800 (PST) Received: from [192.168.1.101] (abym99.neoplus.adsl.tpnet.pl. [83.9.32.99]) by smtp.gmail.com with ESMTPSA id z14-20020a05651c022e00b00295a8e7a328sm308728ljn.54.2023.03.03.05.27.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 03 Mar 2023 05:27:02 -0800 (PST) Message-ID: <8ce07abd-2d02-69d2-8dc6-fe11525aecda@linaro.org> Date: Fri, 3 Mar 2023 14:27:00 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH V2 4/6] regulator: qcom_smd: Add support to define the bootup voltage Content-Language: en-US To: Devi Priya , Mark Brown Cc: agross@kernel.org, andersson@kernel.org, lgirdwood@gmail.com, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, quic_srichara@quicinc.com, quic_gokulsri@quicinc.com, quic_sjaganat@quicinc.com, quic_kathirav@quicinc.com, quic_arajkuma@quicinc.com, quic_anusha@quicinc.com, quic_ipkumar@quicinc.com References: <20230217142030.16012-1-quic_devipriy@quicinc.com> <20230217142030.16012-5-quic_devipriy@quicinc.com> <907628d1-b88d-5ac6-ed9d-7f63e2875738@linaro.org> <39f73580-f263-de0e-6819-89c3f4c75c3a@quicinc.com> From: Konrad Dybcio In-Reply-To: <39f73580-f263-de0e-6819-89c3f4c75c3a@quicinc.com> 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 3.03.2023 14:21, Devi Priya wrote: > > > On 2/23/2023 4:31 AM, Mark Brown wrote: >> On Wed, Feb 22, 2023 at 11:11:42PM +0100, Konrad Dybcio wrote: >> >>> Thinking about it again, this seems like something that could be >>> generalized and introduced into regulator core.. Hardcoding this >>> will not end well.. Not to mention it'll affect all mp5496-using >>> boards that are already upstream. >> >>> WDYT about regulator-init-microvolts Mark? >> >> The overwhelming majority of devices that have variable voltages >> support readback, these Qualcomm firmware devices are pretty much >> unique in this regard.  We don't want a general property to set a >> specific voltage since normally we should be using the >> constraints and don't normally need to adjust things immediately >> since we can tell what the current voltage is. >> >> This is pretty much just going to be a device specific bodge, >> ideally something that does know what the voltage is would be >> able to tell us at runtime but if that's not possible then >> there's no good options.  If the initial voltage might vary based >> on board then a device specific DT property might be less >> terrible, if it's determined by the regulator the current code >> seems fine.  Or just leave the current behavour, if the >> constraints are accurate then hopefully a temporary dip in >> voltage is just inelegant rather than an issue.  Indeed the >> current behaviour might well save power if you've got a voltage >> range configured and nothing actually ever gets round to setting >> the voltage (which is depressingly common, people seem keen on >> setting voltage ranges even when the voltage is never varied in >> practice). > > Hi Mark, The initial bootup voltage is actually blown into the OTP register of the PMIC and it remains the same across boards for IPQ9574 SoC. But what about IPQ6018 which also uses MP5496? That's also gonna set the voltage on there, it may be too high/low.. Initially the SoC runs at 800MHz with a voltage of 875mV set by the bootloaders. As kernel does not know the initial voltage, during regulator registration the framework considers the current voltage to be zero and tries to bring up the regulator to minimum supported voltage of 600mV. This causes the dip which might be of concern in SS parts where the voltage might be insufficient leading to silent reboots. That's an SoC-specific thing, the same regulator can be used with many different ones. We can't just assume it'll always be like this. I see the problem, but I believe this is not the correct solution. Konrad > > Best Regards, > Devi Priya