Message ID | 20230113150310.29709-7-quic_devipriy@quicinc.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4e01:0:0:0:0:0 with SMTP id p1csp326630wrt; Fri, 13 Jan 2023 07:20:13 -0800 (PST) X-Google-Smtp-Source: AMrXdXv7S9qd9mURCRW/+NcKPhu/LqprQASwTkwKJpezZNAtKH0zsFrkfxo6SroeIwEz4XtlcIwx X-Received: by 2002:a17:906:3c1b:b0:84d:122d:4af3 with SMTP id h27-20020a1709063c1b00b0084d122d4af3mr3204685ejg.27.1673623213693; Fri, 13 Jan 2023 07:20:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673623213; cv=none; d=google.com; s=arc-20160816; b=hvgJrM76YcFKb63v4+W5/vwLV9OehN3tqs4rZYlt1YfvkZIUDiUAbwor3UP6moewDh S56Ynv0t8F652mV9a7gC8IbkelupImZg+PRzJiYHLAQ1YKeY8IIMlUpRK/POfWxWpx+B CLmEsCUYGmz4+kXE139Vg37wrXPWwGcFB7WY5rqu8N2NWn4DbjKnP1dxN0c2jhzb3wDq uWJgyWhZzCmI2ctMLwQxN5qxttH1UOeixRMJvoTgIwyWROjIX0CD5YBMZdjjPF7ahvq+ 1iVWjlojf9UUh4lrb0+FxhvDVYhScXn4QMQi+0jr188++wgCG8p3xltE7pWozlbhL/x7 +w7w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=1AihPbpUYyAXungFjjIU4AiL076pidUG87b7y21Ybz0=; b=hUDnE+Gw71RdTObjmCUi8Q0AMRlvvqFyWXRZb9YHrJ/xGdUuCNcDS7tmNseFxtLxm0 JP8ONHzit551ROQNQ/r8Yl6EU2ux8BQ1i7aX6Th/9peSCMhKMoy9D4eU4a6dBaQYQ6M9 n3jMHvucGsDCG4lpo6QwReCMpdZNPnYu20e2T8r23FZvn6IwRYQP6RiFyHIgEGDIdMCp qcrf5ZbpwZf9AZUrqz4LAqI4ymIi4mdywXmYPmETaeZK5w1PphjQDJEfDA13TB+cy5xQ IweRHOIwiFN4oML8ZW5pWOJohaxyrAV1wBratlRX0uOmPcJS2fpPk7y1HjN+vZwr/2kD PMhA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=ZFgDWMB7; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id qb20-20020a1709077e9400b0084d15a1bc6fsi23213365ejc.418.2023.01.13.07.19.49; Fri, 13 Jan 2023 07:20:13 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=ZFgDWMB7; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229488AbjAMPO2 (ORCPT <rfc822;callmefire3@gmail.com> + 99 others); Fri, 13 Jan 2023 10:14:28 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34220 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229877AbjAMPNZ (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 13 Jan 2023 10:13:25 -0500 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4C7AAEA6; Fri, 13 Jan 2023 07:04:06 -0800 (PST) Received: from pps.filterd (m0279865.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 30DBw6IC009428; Fri, 13 Jan 2023 15:04:02 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-type; s=qcppdkim1; bh=1AihPbpUYyAXungFjjIU4AiL076pidUG87b7y21Ybz0=; b=ZFgDWMB7dY5KgxCFEn7O1UN5qiuPwKmHS0A+7LV8S23cqgIIxIBArmuRaTh8K8J9DrzF MGZyX+CZGDvWefEvVWAoec0Zga7izUzM95g8tEiNrz/wkgyuYyuPm/kPossfK14yMVJi phrsulHjnTkmdqv5WCqeo/f9GVbRapkDuMst/dMiKxVYqdduXl2hNQPk9/Lfl1sMTypR RjQPKpR5419yumUKE0Uutzz5AdSDHHcZOus1Fxr0SefMVwIXg5bSVq5ubMXqYd52WqIU j5Ge4xI/zEv3uKn+zRRjeFrhk4nz1nuZQHpgOlT9hHUYj5t8t5205MJokKjkz6OX9eRV JA== Received: from nalasppmta01.qualcomm.com (Global_NAT1.qualcomm.com [129.46.96.20]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3n2wun1sc4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 13 Jan 2023 15:04:02 +0000 Received: from nalasex01a.na.qualcomm.com (nalasex01a.na.qualcomm.com [10.47.209.196]) by NALASPPMTA01.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 30DF41ES028067 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 13 Jan 2023 15:04:01 GMT Received: from devipriy-linux.qualcomm.com (10.80.80.8) by nalasex01a.na.qualcomm.com (10.47.209.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.36; Fri, 13 Jan 2023 07:03:56 -0800 From: devi priya <quic_devipriy@quicinc.com> To: <agross@kernel.org>, <andersson@kernel.org>, <konrad.dybcio@linaro.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> Subject: [PATCH 6/6] regulator: qcom_smd: Add support to define the bootup voltage Date: Fri, 13 Jan 2023 20:33:10 +0530 Message-ID: <20230113150310.29709-7-quic_devipriy@quicinc.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20230113150310.29709-1-quic_devipriy@quicinc.com> References: <20230113150310.29709-1-quic_devipriy@quicinc.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01a.na.qualcomm.com (10.52.223.231) To nalasex01a.na.qualcomm.com (10.47.209.196) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-ORIG-GUID: jhnIEHoRYdRqRK6TlIV5tlFtX1FWF53D X-Proofpoint-GUID: jhnIEHoRYdRqRK6TlIV5tlFtX1FWF53D X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.923,Hydra:6.0.562,FMLib:17.11.122.1 definitions=2023-01-13_07,2023-01-13_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 clxscore=1015 phishscore=0 malwarescore=0 spamscore=0 bulkscore=0 mlxscore=0 priorityscore=1501 adultscore=0 suspectscore=0 impostorscore=0 mlxlogscore=905 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2301130099 X-Spam-Status: No, score=0.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW, RCVD_IN_SBL_CSS,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1754921134968567477?= X-GMAIL-MSGID: =?utf-8?q?1754921134968567477?= |
Series |
Add regulator support for IPQ9574 SoC
|
|
Commit Message
Devi Priya
Jan. 13, 2023, 3:03 p.m. UTC
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> --- drivers/regulator/qcom_smd-regulator.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
Comments
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 > 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;
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 >> 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
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 > >>> 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
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. >> >>>> 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
On 13/01/2023 17: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> > --- > 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 }, I think this is a peculiarity of the particular board that than a property of the PMIC. Please describe this in the board or SoC DTS if the value can not be read using the software . > {} > }; > > @@ -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;
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 > >>> >>>>> 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
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. >> >>>> >>>>>> 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
On 1/31/2023 3:07 PM, Dmitry Baryshkov wrote: > On 13/01/2023 17: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> >> --- >> 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 }, > > I think this is a peculiarity of the particular board that than a > property of the PMIC. Please describe this in the board or SoC DTS if > the value can not be read using the software . > The bootup voltage is actually blown into the OTP register of the PMIC and so, it remains the same across boards for IPQ9574 SoC >> {} >> }; >> @@ -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
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? 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
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
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;