linux-arm-msm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Devi Priya <quic_devipriy@quicinc.com>
To: Konrad Dybcio <konrad.dybcio@linaro.org>, <agross@kernel.org>,
	<andersson@kernel.org>, <lgirdwood@gmail.com>,
	<broonie@kernel.org>, <robh+dt@kernel.org>,
	<krzysztof.kozlowski+dt@linaro.org>,
	<linux-arm-msm@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<devicetree@vger.kernel.org>
Cc: <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_poovendh@quicinc.com>, <quic_ipkumar@quicinc.com>
Subject: Re: [PATCH 6/6] regulator: qcom_smd: Add support to define the bootup voltage
Date: Mon, 6 Feb 2023 19:18:29 +0530	[thread overview]
Message-ID: <9c3801a3-9180-d955-d5b4-9a6ec39866eb@quicinc.com> (raw)
In-Reply-To: <bab449de-73c9-f65e-24fa-84749fbc51bb@linaro.org>



On 2/2/2023 5:13 PM, Konrad Dybcio wrote:
> 
> 
> On 2.02.2023 12:09, Devi Priya wrote:
>>
>>
>> On 1/31/2023 6:14 PM, Konrad Dybcio wrote:
>>>
>>>
>>> On 31.01.2023 10:28, Devi Priya wrote:
>>>>
>>>>
>>>> On 1/27/2023 9:40 PM, Konrad Dybcio wrote:
>>>>>
>>>>>
>>>>> On 27.01.2023 17:07, Devi Priya wrote:
>>>>>>
>>>>>>
>>>>>> On 1/13/2023 9:07 PM, Konrad Dybcio wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 13.01.2023 16:03, devi priya wrote:
>>>>>>>> Kernel does not know the initial voltage set by the bootloaders.
>>>>>>>> During regulator registration, the voltage variable is just declared
>>>>>>>> and it is zero. Based on that, the regulator framework considers current
>>>>>>>> the voltage as zero and tries to bring up each regulator to minimum
>>>>>>>> the supported voltage.
>>>>>>>>
>>>>>>>> This introduces a dip in the voltage during kernel boot and gets
>>>>>>>> stabilized once the voltage scaling comes into picture.
>>>>>>>>
>>>>>>>> To avoid the voltage dip, adding support to define the
>>>>>>>> bootup voltage set by the boodloaders and based on it, regulator
>>>>>>>> framework understands that proper voltage is already set
>>>>>>>>
>>>>>>>> Co-developed-by: Praveenkumar I <quic_ipkumar@quicinc.com>
>>>>>>>> Signed-off-by: Praveenkumar I <quic_ipkumar@quicinc.com>
>>>>>>>> Signed-off-by: devi priya <quic_devipriy@quicinc.com>
>>>>>>>> ---
>>>>>>> Or maybe hook it up to the spmi_regulator_common_get_voltage()
>>>>>>> from the SPMI regulator driver and read the real voltage instead
>>>>>>> of relying on hardcoded values thay may differ between boards?
>>>>>>>
>>>>>>> Konrad
>>>>>> In IPQ9574, SPMI regulator is not used. We are using RPM-Glink communication and the regulators are controlled by RPM.
>>>>>> In this case, we don't have an option to readback the bootup voltage and so, we have hardcoded the values
>>>>> Unless something changed, RPM regulator framework is simply a
>>>>> fancy front-end for communicating with the PMIC over SPMI, AFAIK..
>>>>>
>>>>> Konrad
>>>> Currently in our driver, the voltage write request will be sent to RPM via GLINK which then writes it to the PMIC over I2C using the below APIs
>>>> qcom_rpm_smd_write -> rpmsg_send
>>>> In IPQ9574, we do not have SPMI support or the support to readback voltage.
>>> Okay, I didn't quite catch that there's *only* an i2c PMIC on this
>>> platform.. Looking at the MP5496 datasheet though, reading back
>>> the voltage should be possible via simply reading the fields that
>>> are used to set it.
>>>
>>> Konrad
>> The CPR regulator operates in closed loop mode and the RPM can independently update the PMIC voltage.
>> So, Performing an i2c read to the PMIC would introduce conflicts when RPM uses the i2c for any of the voltage write or read operations.
> So.. are we even going to set voltage from Linux at all, for example
> for DCVS? If not, maybe we can simply not register the regulator and
> let the non-APSS parts handle it themselves?
> 
In IPQ9574, PMIC basically controls three rails. In that, RPM has 
control over two rails (MX and CX) & APSS has control over the APC rail. 
RPM controls the MX and CX rails independently. For APC rail, APSS sends 
the voltage request to RPM via GLINK and RPM takes care of accessing the 
PMIC via I2C for APSS voltage requests & its own requests. This approach 
helps us to avoid arbitration. In this case, if we directly use the I2C 
to read the PMIC we would end up having issues, if RPM is accessing the 
PMIC.
> Konrad
>>>>
>>>>>>
>>>>>>>>      drivers/regulator/qcom_smd-regulator.c | 6 +++++-
>>>>>>>>      1 file changed, 5 insertions(+), 1 deletion(-)
>>>>>>>>
>>>>>>>> diff --git a/drivers/regulator/qcom_smd-regulator.c b/drivers/regulator/qcom_smd-regulator.c
>>>>>>>> index 1eb17d378897..49a36b07397c 100644
>>>>>>>> --- a/drivers/regulator/qcom_smd-regulator.c
>>>>>>>> +++ b/drivers/regulator/qcom_smd-regulator.c
>>>>>>>> @@ -800,6 +800,7 @@ struct rpm_regulator_data {
>>>>>>>>          u32 id;
>>>>>>>>          const struct regulator_desc *desc;
>>>>>>>>          const char *supply;
>>>>>>>> +    int boot_uV; /* To store the bootup voltage set by bootloaders */
>>>>>>>>      };
>>>>>>>>        static const struct rpm_regulator_data rpm_mp5496_regulators[] = {
>>>>>>>> @@ -809,7 +810,7 @@ static const struct rpm_regulator_data rpm_mp5496_regulators[] = {
>>>>>>>>      };
>>>>>>>>        static const struct rpm_regulator_data rpm_ipq9574_mp5496_regulators[] = {
>>>>>>>> -    { "s1", QCOM_SMD_RPM_SMPA, 1, &ipq9574_mp5496_smpa1, "s1" },
>>>>>>>> +    { "s1", QCOM_SMD_RPM_SMPA, 1, &ipq9574_mp5496_smpa1, "s1", 875000 },
>>>>>>>>          {}
>>>>>>>>      };
>>>>>>>>      @@ -1394,6 +1395,9 @@ static int rpm_regulator_init_vreg(struct qcom_rpm_reg *vreg, struct device *dev
>>>>>>>>          vreg->type    = rpm_data->type;
>>>>>>>>          vreg->id    = rpm_data->id;
>>>>>>>>      +    if (rpm_data->boot_uV)
>>>>>>>> +        vreg->uV = rpm_data->boot_uV;
>>>>>>>> +
>>>>>>>>          memcpy(&vreg->desc, rpm_data->desc, sizeof(vreg->desc));
>>>>>>>>          vreg->desc.name = rpm_data->name;
>>>>>>>>          vreg->desc.supply_name = rpm_data->supply;
>>>>>> Best Regards,
>>>>>> Devi Priya
>>>> Best Regards,
>>>> Devi Priya

  reply	other threads:[~2023-02-06 13:50 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-13 15:03 [PATCH 0/6] Add regulator support for IPQ9574 SoC devi priya
2023-01-13 15:03 ` [PATCH 1/6] soc: qcom: smd-rpm: Add IPQ9574 compatible devi priya
2023-01-13 16:42   ` Krzysztof Kozlowski
2023-01-16 11:12     ` Mark Brown
2023-01-27 15:57       ` Devi Priya
2023-01-27 15:54     ` Devi Priya
2023-01-13 15:03 ` [PATCH 2/6] dt-bindings: soc: qcom: smd-rpm: Add IPQ9574 compatible string devi priya
2023-01-13 16:43   ` Krzysztof Kozlowski
2023-01-27 15:59     ` Devi Priya
2023-01-13 15:03 ` [PATCH 3/6] regulator: qcom_smd: Add MP5496 regulators devi priya
2023-01-13 15:24   ` Konrad Dybcio
2023-01-27 16:01     ` Devi Priya
2023-01-27 16:03       ` Konrad Dybcio
2023-01-31 10:16         ` Devi Priya
2023-01-13 15:03 ` [PATCH 4/6] regulator: qcom_smd: Add PMIC compatible for IPQ9574 devi priya
2023-01-17 18:38   ` Rob Herring
2023-01-27 16:05     ` Devi Priya
2023-01-27 20:12       ` Rob Herring
2023-01-31 10:22         ` Devi Priya
2023-01-13 15:03 ` [PATCH 5/6] arm64: dts: qcom: ipq9574: Add cpufreq & RPM related nodes devi priya
2023-01-13 15:32   ` Konrad Dybcio
2023-02-02  9:54     ` Devi Priya
2023-01-13 15:03 ` [PATCH 6/6] regulator: qcom_smd: Add support to define the bootup voltage devi priya
2023-01-13 15:37   ` Konrad Dybcio
2023-01-27 16:07     ` Devi Priya
2023-01-27 16:10       ` Konrad Dybcio
2023-01-31  9:28         ` Devi Priya
2023-01-31 12:44           ` Konrad Dybcio
2023-02-02 11:09             ` Devi Priya
2023-02-02 11:43               ` Konrad Dybcio
2023-02-06 13:48                 ` Devi Priya [this message]
2023-01-31  9:37   ` Dmitry Baryshkov
2023-02-02 11:09     ` Devi Priya
2023-02-06 22:30 ` (subset) [PATCH 0/6] Add regulator support for IPQ9574 SoC Bjorn Andersson
2023-02-08  6:09   ` Devi Priya

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=9c3801a3-9180-d955-d5b4-9a6ec39866eb@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_poovendh@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;
as well as URLs for NNTP newsgroup(s).