Linux ARM-MSM sub-architecture
 help / color / mirror / Atom feed
From: Devi Priya <quic_devipriy@quicinc.com>
To: Konrad Dybcio <konrad.dybcio@linaro.org>,
	Mark Brown <broonie@kernel.org>
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>
Subject: Re: [PATCH V2 4/6] regulator: qcom_smd: Add support to define the bootup voltage
Date: Tue, 7 Mar 2023 12:25:04 +0530	[thread overview]
Message-ID: <751e5129-3c11-0156-719e-3fe996a149be@quicinc.com> (raw)
In-Reply-To: <11b05b9f-b969-6648-2204-2da5f8465c96@quicinc.com>



On 3/6/2023 6:39 PM, Devi Priya wrote:
> 
> 
> On 3/3/2023 6:57 PM, Konrad Dybcio wrote:
>>
>>
>> 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..
For IPQ6018, the bootup voltage is the same as that of IPQ9574 which is
875mV
>>
>>   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
Okay, As we had discussions on reading back the voltage & the generic
DT property, do you suggest any other possible solutions here?
>>
>> Konrad
>>>
>>> Best Regards,
>>> Devi Priya

  parent reply	other threads:[~2023-03-07  6:55 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-17 14:20 [PATCH V2 0/6] Add regulator support for IPQ9574 SoC Devi Priya
2023-02-17 14:20 ` [PATCH V2 1/6] dt-bindings: soc: qcom: smd-rpm: Add IPQ9574 compatible Devi Priya
2023-02-18 10:20   ` Krzysztof Kozlowski
2023-02-17 14:20 ` [PATCH V2 2/6] regulator: qcom_smd: Add s1 sub-node to mp5496 regulator Devi Priya
2023-02-28 14:31   ` Rob Herring
2023-02-17 14:20 ` [PATCH V2 3/6] regulator: qcom_smd: Add MP5496 S1 regulator Devi Priya
2023-02-17 14:20 ` [PATCH V2 4/6] regulator: qcom_smd: Add support to define the bootup voltage Devi Priya
2023-02-22 22:11   ` Konrad Dybcio
2023-02-22 23:01     ` Mark Brown
2023-03-03 13:21       ` Devi Priya
2023-03-03 13:27         ` Konrad Dybcio
     [not found]           ` <11b05b9f-b969-6648-2204-2da5f8465c96@quicinc.com>
2023-03-07  6:55             ` Devi Priya [this message]
2023-03-08 10:27               ` Konrad Dybcio
2023-03-14 17:15                 ` Devi Priya
2023-03-18 14:08                   ` Konrad Dybcio
2023-03-27  8:40                     ` Devi Priya
2023-03-27  9:26                       ` Konrad Dybcio
2023-03-28  6:12                         ` Devi Priya
2023-03-28  8:28                           ` Konrad Dybcio
2023-04-03 14:07                             ` Devi Priya
2023-04-03 17:53                               ` Konrad Dybcio
2023-04-03 18:14                                 ` Mark Brown
2023-04-03 18:21                                   ` Konrad Dybcio
2023-04-03 18:28                                     ` Mark Brown
2023-02-17 14:20 ` [PATCH V2 5/6] arm64: dts: qcom: ipq9574: Add RPM related nodes Devi Priya
2023-02-17 14:50   ` Konrad Dybcio
2023-02-20 13:53     ` Devi Priya
2023-02-20 14:36       ` Konrad Dybcio
2023-02-20 15:22         ` Devi Priya
2023-02-17 14:20 ` [PATCH V2 6/6] arm64: dts: qcom: ipq9574: Add cpufreq support Devi Priya
2023-03-16  3:20 ` (subset) [PATCH V2 0/6] Add regulator support for IPQ9574 SoC Bjorn Andersson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=751e5129-3c11-0156-719e-3fe996a149be@quicinc.com \
    --to=quic_devipriy@quicinc.com \
    --cc=agross@kernel.org \
    --cc=andersson@kernel.org \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=konrad.dybcio@linaro.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=quic_anusha@quicinc.com \
    --cc=quic_arajkuma@quicinc.com \
    --cc=quic_gokulsri@quicinc.com \
    --cc=quic_ipkumar@quicinc.com \
    --cc=quic_kathirav@quicinc.com \
    --cc=quic_sjaganat@quicinc.com \
    --cc=quic_srichara@quicinc.com \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox