* [PATCH] regulator: qcom_smd: change MP5496 supply names
@ 2025-12-16 18:38 Gabor Juhos
2025-12-17 10:30 ` Konrad Dybcio
0 siblings, 1 reply; 4+ messages in thread
From: Gabor Juhos @ 2025-12-16 18:38 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Varadarajan Narayanan, Devi Priya,
Praveenkumar I, Konrad Dybcio, Kathiravan T
Cc: linux-arm-msm, linux-kernel, Gabor Juhos
In case of the MP5496 regulators, the driver uses the same name both for
the regulator and for its supply. Due to this, in some cases the supply
gets resolved to the regulator itself, and the regulator core code throwns
an error message.
For example, booting the kernel with the 'ipq9574-rdp433' device tree,
results in the following message in the log:
[ 1.710392] qcom_rpm_smd_regulator remoteproc:glink-edge:rpm-requests:regulators: Supply for s1 (s1) resolved to itself
Additionally, the driver uses different supply names for the 's2' and for
the 'l2' regulators which is incorrect. Here is the supply map based on the
datasheet of the MP5496:
VIN1 -> Buck1
VIN2 -> Buck2, LDO2, LDO3
VIN3 -> Buck3
VIN4 -> Buck4
VIN5 -> LDO4, LDO5
This indicates that both 's2' (Buck2) and 'l2' (LDO2) are connected
to the same supply internally within the PMIC, so those should use
the same supply name.
Change the supply names according to the naming schema used by the other
regulators in the same driver to fix the above problems.
Although this breaks backward compatibility, but the risk of causing
issues is quite low because none of the in-kernel device tree sources
are defining supplies with the removed names.
Fixes: ad663ce67804 ("regulator: qcom_smd: Add LDO5 MP5496 regulator")
Fixes: 60bbee7db43b ("regulator: qcom_smd: Add MP5496 S1 regulator")
Fixes: 47894c859479 ("regulator: qcom_smd: Add MP5496 regulators")
Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
---
drivers/regulator/qcom_smd-regulator.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/regulator/qcom_smd-regulator.c b/drivers/regulator/qcom_smd-regulator.c
index 25ed9f713974ba25058c9dbf38d36e88f70a940b..91bfea06b98682fca3c41f49ac127884143d282f 100644
--- a/drivers/regulator/qcom_smd-regulator.c
+++ b/drivers/regulator/qcom_smd-regulator.c
@@ -792,10 +792,10 @@ struct rpm_regulator_data {
};
static const struct rpm_regulator_data rpm_mp5496_regulators[] = {
- { "s1", QCOM_SMD_RPM_SMPA, 1, &mp5496_smps, "s1" },
- { "s2", QCOM_SMD_RPM_SMPA, 2, &mp5496_smps, "s2" },
- { "l2", QCOM_SMD_RPM_LDOA, 2, &mp5496_ldoa2, "l2" },
- { "l5", QCOM_SMD_RPM_LDOA, 5, &mp5496_ldoa2, "l5" },
+ { "s1", QCOM_SMD_RPM_SMPA, 1, &mp5496_smps, "vdd_s1" },
+ { "s2", QCOM_SMD_RPM_SMPA, 2, &mp5496_smps, "vdd_s2_l2_l3" },
+ { "l2", QCOM_SMD_RPM_LDOA, 2, &mp5496_ldoa2, "vdd_s2_l2_l3" },
+ { "l5", QCOM_SMD_RPM_LDOA, 5, &mp5496_ldoa2, "vdd_l4_l5" },
{}
};
---
base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
change-id: 20251211-qcom_smd-mp5496-supply-fix-9086dad3cbc5
Best regards,
--
Gabor Juhos <j4g8y7@gmail.com>
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] regulator: qcom_smd: change MP5496 supply names
2025-12-16 18:38 [PATCH] regulator: qcom_smd: change MP5496 supply names Gabor Juhos
@ 2025-12-17 10:30 ` Konrad Dybcio
2025-12-17 20:32 ` Gabor Juhos
0 siblings, 1 reply; 4+ messages in thread
From: Konrad Dybcio @ 2025-12-17 10:30 UTC (permalink / raw)
To: Gabor Juhos, Liam Girdwood, Mark Brown, Varadarajan Narayanan,
Devi Priya, Praveenkumar I, Konrad Dybcio, Kathiravan T
Cc: linux-arm-msm, linux-kernel
On 12/16/25 7:38 PM, Gabor Juhos wrote:
> In case of the MP5496 regulators, the driver uses the same name both for
> the regulator and for its supply. Due to this, in some cases the supply
> gets resolved to the regulator itself, and the regulator core code throwns
> an error message.
>
> For example, booting the kernel with the 'ipq9574-rdp433' device tree,
> results in the following message in the log:
>
> [ 1.710392] qcom_rpm_smd_regulator remoteproc:glink-edge:rpm-requests:regulators: Supply for s1 (s1) resolved to itself
>
> Additionally, the driver uses different supply names for the 's2' and for
> the 'l2' regulators which is incorrect. Here is the supply map based on the
> datasheet of the MP5496:
>
> VIN1 -> Buck1
> VIN2 -> Buck2, LDO2, LDO3
> VIN3 -> Buck3
> VIN4 -> Buck4
> VIN5 -> LDO4, LDO5
One thing this reveals is that there's an LDO3 and an LDO4 which
we don't describe today.. are they managed as power-domains, or
are there other other reasons?
Konrad
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] regulator: qcom_smd: change MP5496 supply names
2025-12-17 10:30 ` Konrad Dybcio
@ 2025-12-17 20:32 ` Gabor Juhos
2025-12-18 13:27 ` Konrad Dybcio
0 siblings, 1 reply; 4+ messages in thread
From: Gabor Juhos @ 2025-12-17 20:32 UTC (permalink / raw)
To: Konrad Dybcio, Liam Girdwood, Mark Brown, Varadarajan Narayanan,
Devi Priya, Praveenkumar I, Konrad Dybcio, Kathiravan T
Cc: linux-arm-msm, linux-kernel
Hi Konrad,
2025. 12. 17. 11:30 keltezéssel, Konrad Dybcio írta:
> On 12/16/25 7:38 PM, Gabor Juhos wrote:
>> In case of the MP5496 regulators, the driver uses the same name both for
>> the regulator and for its supply. Due to this, in some cases the supply
>> gets resolved to the regulator itself, and the regulator core code throwns
>> an error message.
>>
>> For example, booting the kernel with the 'ipq9574-rdp433' device tree,
>> results in the following message in the log:
>>
>> [ 1.710392] qcom_rpm_smd_regulator remoteproc:glink-edge:rpm-requests:regulators: Supply for s1 (s1) resolved to itself
>>
>> Additionally, the driver uses different supply names for the 's2' and for
>> the 'l2' regulators which is incorrect. Here is the supply map based on the
>> datasheet of the MP5496:
>>
>> VIN1 -> Buck1
>> VIN2 -> Buck2, LDO2, LDO3
>> VIN3 -> Buck3
>> VIN4 -> Buck4
>> VIN5 -> LDO4, LDO5
>
> One thing this reveals is that there's an LDO3 and an LDO4 which
> we don't describe today..
The same is true for Buck3 and Buck4 too.
> are they managed as power-domains, or are there other other reasons?
Unfortunately, I don't know the exact reason.
I have no detailed hardware information about the reference boards, but it seems
that it depends on what is supported by the actual RPM firmware on the board.
For example, currently I have this RPM version on my IPQ9574 based board:
# cat /sys/kernel/debug/qcom_socinfo/rpm/name
03:RPM.BF.2.4.1-00116
# cat /sys/kernel/debug/qcom_socinfo/rpm/oem
CRM
# cat /sys/kernel/debug/qcom_socinfo/rpm/variant
CAAAANAAR
This version does not even support LDO5. At least, trying to use that results in
the following error:
[ 2.120281] l5: Bringing 0uV into 1800000-1800000uV
[ 2.127721] l5: failed to enable: -ENXIO
In this special case, the -ENXIO error code comes from qcom_smd_rpm_callback()
and it means that the resource does not exists.
So my guess is that the undescribed regulators are simply not used on the boards
supported currently.
Regards,
Gabor
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] regulator: qcom_smd: change MP5496 supply names
2025-12-17 20:32 ` Gabor Juhos
@ 2025-12-18 13:27 ` Konrad Dybcio
0 siblings, 0 replies; 4+ messages in thread
From: Konrad Dybcio @ 2025-12-18 13:27 UTC (permalink / raw)
To: Gabor Juhos, Liam Girdwood, Mark Brown, Varadarajan Narayanan,
Devi Priya, Praveenkumar I, Konrad Dybcio, Kathiravan T
Cc: linux-arm-msm, linux-kernel
On 12/17/25 9:32 PM, Gabor Juhos wrote:
> Hi Konrad,
>
> 2025. 12. 17. 11:30 keltezéssel, Konrad Dybcio írta:
>> On 12/16/25 7:38 PM, Gabor Juhos wrote:
>>> In case of the MP5496 regulators, the driver uses the same name both for
>>> the regulator and for its supply. Due to this, in some cases the supply
>>> gets resolved to the regulator itself, and the regulator core code throwns
>>> an error message.
>>>
>>> For example, booting the kernel with the 'ipq9574-rdp433' device tree,
>>> results in the following message in the log:
>>>
>>> [ 1.710392] qcom_rpm_smd_regulator remoteproc:glink-edge:rpm-requests:regulators: Supply for s1 (s1) resolved to itself
>>>
>>> Additionally, the driver uses different supply names for the 's2' and for
>>> the 'l2' regulators which is incorrect. Here is the supply map based on the
>>> datasheet of the MP5496:
>>>
>>> VIN1 -> Buck1
>>> VIN2 -> Buck2, LDO2, LDO3
>>> VIN3 -> Buck3
>>> VIN4 -> Buck4
>>> VIN5 -> LDO4, LDO5
>>
>> One thing this reveals is that there's an LDO3 and an LDO4 which
>> we don't describe today..
>
> The same is true for Buck3 and Buck4 too.
>
>> are they managed as power-domains, or are there other other reasons?
>
> Unfortunately, I don't know the exact reason.
OK, so the bucks are all managed by RPM as power domains indeed
L[2345] are all defined
*but*
I don't quite know how this is all mapped - it may be that LDO2 is mapped
as "l1", but I'm really not sure
Konrad
>
> I have no detailed hardware information about the reference boards, but it seems
> that it depends on what is supported by the actual RPM firmware on the board.
>
> For example, currently I have this RPM version on my IPQ9574 based board:
>
> # cat /sys/kernel/debug/qcom_socinfo/rpm/name
> 03:RPM.BF.2.4.1-00116
> # cat /sys/kernel/debug/qcom_socinfo/rpm/oem
> CRM
> # cat /sys/kernel/debug/qcom_socinfo/rpm/variant
> CAAAANAAR
>
> This version does not even support LDO5. At least, trying to use that results in
> the following error:
>
> [ 2.120281] l5: Bringing 0uV into 1800000-1800000uV
> [ 2.127721] l5: failed to enable: -ENXIO
>
> In this special case, the -ENXIO error code comes from qcom_smd_rpm_callback()
> and it means that the resource does not exists.
>
> So my guess is that the undescribed regulators are simply not used on the boards
> supported currently.
>
> Regards,
> Gabor
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2025-12-18 13:27 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-12-16 18:38 [PATCH] regulator: qcom_smd: change MP5496 supply names Gabor Juhos
2025-12-17 10:30 ` Konrad Dybcio
2025-12-17 20:32 ` Gabor Juhos
2025-12-18 13:27 ` Konrad Dybcio
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox