drivers/regulator/qcom-rpmh-regulator.c | 186 +++++++++++++++++++++++++++++++- drivers/soc/qcom/rpmh-rsc.c | 13 ++- drivers/soc/qcom/rpmh.c | 47 +++++++- include/soc/qcom/rpmh.h | 5 + include/soc/qcom/tcs.h | 2 + 5 files changed, 245 insertions(+), 8 deletions(-)
This patch series adds a new `rpmh_read()` API to allow reading RPMH
addresses. Using this API enhances the RPMH regulator driver by adding
new `get_status()` callback to reflect the regulator status and also
readback the voltage/bypass/mode settings as they have been applied by
APPS during the bootloader stage, so regulator framework can get them
via `get_mode`, `get_bypass` & `get_voltage_selector` callbacks during
regulator registration.
This is needed because currently regulator framework does a unnecessary
write with `min-microvolt` DT setting for all the RPMH regulators during
regulator registration, because the first time after boot the value is
seen as -ENOTRECOVERABLE, as there is no option to read these regulator
settings.
With this change this unnecessary write can be avoided and regulator
framework gets a sense of the initial state set during the bootloader
stage for all regulator settings.
NOTE - During discussion on the v2 series - PATCH 3/4, reviewer had
inquired about possible need for the use of the sync_state() to handle the
"multiple" client case - for maintaining the regulator settings till all
the clients are probed.
This case was not covered in my previous series and had originally planned
to do that series seperately. But after the discussion decided to merge
the 2 series as it seemed this would be a better approach. But after
working on sync_state change. I realized a basic issue with using
sync_state() for regulators - that its per-driver and not per-regulator
resource. But we needed a sync_state callback for each regulator seperately.
I had been experimenting with few ideas but seems its going to need more
time for me to close on the eqvivalent solution that has per-regulator
sync_state or something to that effect. So I thought to close on this
series and attend to that seperately.
Signed-off-by: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com>
---
Changes in v3:
- Removed "bypass_supported" as that is not needed for regulators
that don't have set_bypass implemented, as pointed by Dmitry.
- Handled the corner case where the mode/bypass setting is read 0, but
its unclear if the register has been set to 0 or its un-accessed.
- Dropped `convert_mode_to_status()` and use the `regulator_mode_to_status()`
instead.
- Refactored some code to simplify the `status` update after every
enable/mode/bypass setting change.
- Corrected subject line of all patches to have `regulator: qcom-rpmh:`
for all the `qcom-rpmh-regulator.c` file changes, as pointed by Bjorn.
- Re-ordered the series to have the `rpmh.c` driver patches first and
than `qcom-rpmh-regulator.c` driver patches as asked by Bjorn.
- In the BOB5 bypass fix patch (PATCH 1/4 in previous series), added
the fixes commit#, as it was missed earlier.
- In the rpmh driver change(PATCH 2/4 in previous series), modified
commit wording and removed linked as suggested by reviewer.
- Fixed kernel test robot issues and other formatting issues in
PATCH 3/4 of last series.
- Corrected the checkpatch error fix PATCH 4/4 to keep to only
one error in comment section which existed prior to this
series.
- Link to v2: https://lore.kernel.org/all/20251022-add-rpmh-read-support-v2-0-5c7a8e4df601@oss.qualcomm.com/
Changes in v2:
- Fixed the BOB bypass mode handling (existing issue in current driver).
This was needed for `get_status()` implementation.
- Implemented `get_status()` callback.
- Callbacks for `is_enabled()` & `get_mode()` will now be used as-is
ie. v1 changes reverted.
- Bootstapped the read values for `mode` and `status` in probe, based on
comments recieved from reviewer.
- Callback for `get_voltage_sel()` has been modified to handle cases
where read voltage is out-of-range defined in the regulator DT settings,
this is needed to ensure backward compatibilty. Regulator probes may
fail otherwise for some older targets.
- This patch is rebased & tested on:
https://lore.kernel.org/all/176070318151.57631.15443673679580823321.b4-ty@kernel.org/
to avoid any merge issues.
- Fixed code style issues reported by checkpatch.pl script.
- Link to v1: https://lore.kernel.org/r/20250623-add-rpmh-read-support-v1-0-ae583d260195@oss.qualcomm.com
Signed-off-by: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com>
---
Kamal Wadhwa (3):
regulator: qcom-rpmh: Fix PMIC5 BOB bypass mode handling
regulator: qcom-rpmh: readback voltage/bypass/mode/status set during bootup
regulator: qcom-rpmh: Fix coding style issues
Maulik Shah (1):
soc: qcom: rpmh: Add support to read back resource settings
drivers/regulator/qcom-rpmh-regulator.c | 186 +++++++++++++++++++++++++++++++-
drivers/soc/qcom/rpmh-rsc.c | 13 ++-
drivers/soc/qcom/rpmh.c | 47 +++++++-
include/soc/qcom/rpmh.h | 5 +
include/soc/qcom/tcs.h | 2 +
5 files changed, 245 insertions(+), 8 deletions(-)
---
base-commit: bd0f139e5fc11182777b81cefc3893ea508544ec
change-id: 20260407-read-rpmh-v3-821188eae030
Best regards,
--
Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com>
On Tue, Apr 07, 2026 at 03:44:57AM +0530, Kamal Wadhwa wrote: > This patch series adds a new `rpmh_read()` API to allow reading RPMH > addresses. Using this API enhances the RPMH regulator driver by adding > new `get_status()` callback to reflect the regulator status and also > readback the voltage/bypass/mode settings as they have been applied by > APPS during the bootloader stage, so regulator framework can get them > via `get_mode`, `get_bypass` & `get_voltage_selector` callbacks during > regulator registration. > > This is needed because currently regulator framework does a unnecessary > write with `min-microvolt` DT setting for all the RPMH regulators during > regulator registration, because the first time after boot the value is > seen as -ENOTRECOVERABLE, as there is no option to read these regulator > settings. > > With this change this unnecessary write can be avoided and regulator > framework gets a sense of the initial state set during the bootloader > stage for all regulator settings. > > NOTE - During discussion on the v2 series - PATCH 3/4, reviewer had > inquired about possible need for the use of the sync_state() to handle the > "multiple" client case - for maintaining the regulator settings till all > the clients are probed. > > This case was not covered in my previous series and had originally planned > to do that series seperately. But after the discussion decided to merge > the 2 series as it seemed this would be a better approach. But after > working on sync_state change. I realized a basic issue with using > sync_state() for regulators - that its per-driver and not per-regulator > resource. But we needed a sync_state callback for each regulator seperately. > > I had been experimenting with few ideas but seems its going to need more > time for me to close on the eqvivalent solution that has per-regulator > sync_state or something to that effect. So I thought to close on this > series and attend to that seperately. > > Signed-off-by: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com> > --- > Changes in v3: If this is v3, why is not marked as such? > - Removed "bypass_supported" as that is not needed for regulators > that don't have set_bypass implemented, as pointed by Dmitry. > - Handled the corner case where the mode/bypass setting is read 0, but > its unclear if the register has been set to 0 or its un-accessed. > - Dropped `convert_mode_to_status()` and use the `regulator_mode_to_status()` > instead. > - Refactored some code to simplify the `status` update after every > enable/mode/bypass setting change. > - Corrected subject line of all patches to have `regulator: qcom-rpmh:` > for all the `qcom-rpmh-regulator.c` file changes, as pointed by Bjorn. > - Re-ordered the series to have the `rpmh.c` driver patches first and > than `qcom-rpmh-regulator.c` driver patches as asked by Bjorn. > - In the BOB5 bypass fix patch (PATCH 1/4 in previous series), added > the fixes commit#, as it was missed earlier. > - In the rpmh driver change(PATCH 2/4 in previous series), modified > commit wording and removed linked as suggested by reviewer. > - Fixed kernel test robot issues and other formatting issues in > PATCH 3/4 of last series. > - Corrected the checkpatch error fix PATCH 4/4 to keep to only > one error in comment section which existed prior to this > series. > - Link to v2: https://lore.kernel.org/all/20251022-add-rpmh-read-support-v2-0-5c7a8e4df601@oss.qualcomm.com/ > > Changes in v2: > - Fixed the BOB bypass mode handling (existing issue in current driver). > This was needed for `get_status()` implementation. > - Implemented `get_status()` callback. > - Callbacks for `is_enabled()` & `get_mode()` will now be used as-is > ie. v1 changes reverted. > - Bootstapped the read values for `mode` and `status` in probe, based on > comments recieved from reviewer. > - Callback for `get_voltage_sel()` has been modified to handle cases > where read voltage is out-of-range defined in the regulator DT settings, > this is needed to ensure backward compatibilty. Regulator probes may > fail otherwise for some older targets. > - This patch is rebased & tested on: > https://lore.kernel.org/all/176070318151.57631.15443673679580823321.b4-ty@kernel.org/ > to avoid any merge issues. > - Fixed code style issues reported by checkpatch.pl script. > - Link to v1: https://lore.kernel.org/r/20250623-add-rpmh-read-support-v1-0-ae583d260195@oss.qualcomm.com > > Signed-off-by: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com> > > --- > Kamal Wadhwa (3): > regulator: qcom-rpmh: Fix PMIC5 BOB bypass mode handling > regulator: qcom-rpmh: readback voltage/bypass/mode/status set during bootup > regulator: qcom-rpmh: Fix coding style issues > > Maulik Shah (1): > soc: qcom: rpmh: Add support to read back resource settings > > drivers/regulator/qcom-rpmh-regulator.c | 186 +++++++++++++++++++++++++++++++- > drivers/soc/qcom/rpmh-rsc.c | 13 ++- > drivers/soc/qcom/rpmh.c | 47 +++++++- > include/soc/qcom/rpmh.h | 5 + > include/soc/qcom/tcs.h | 2 + > 5 files changed, 245 insertions(+), 8 deletions(-) > --- > base-commit: bd0f139e5fc11182777b81cefc3893ea508544ec > change-id: 20260407-read-rpmh-v3-821188eae030 > > Best regards, > -- > Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com> > -- With best wishes Dmitry
On Tue, Apr 07, 2026 at 04:58:26AM +0300, Dmitry Baryshkov wrote: > On Tue, Apr 07, 2026 at 03:44:57AM +0530, Kamal Wadhwa wrote: > > This patch series adds a new `rpmh_read()` API to allow reading RPMH > > addresses. Using this API enhances the RPMH regulator driver by adding > > new `get_status()` callback to reflect the regulator status and also > > readback the voltage/bypass/mode settings as they have been applied by > > APPS during the bootloader stage, so regulator framework can get them > > via `get_mode`, `get_bypass` & `get_voltage_selector` callbacks during > > regulator registration. > > > > This is needed because currently regulator framework does a unnecessary > > write with `min-microvolt` DT setting for all the RPMH regulators during > > regulator registration, because the first time after boot the value is > > seen as -ENOTRECOVERABLE, as there is no option to read these regulator > > settings. > > > > With this change this unnecessary write can be avoided and regulator > > framework gets a sense of the initial state set during the bootloader > > stage for all regulator settings. > > > > NOTE - During discussion on the v2 series - PATCH 3/4, reviewer had > > inquired about possible need for the use of the sync_state() to handle the > > "multiple" client case - for maintaining the regulator settings till all > > the clients are probed. > > > > This case was not covered in my previous series and had originally planned > > to do that series seperately. But after the discussion decided to merge > > the 2 series as it seemed this would be a better approach. But after > > working on sync_state change. I realized a basic issue with using > > sync_state() for regulators - that its per-driver and not per-regulator > > resource. But we needed a sync_state callback for each regulator seperately. > > > > I had been experimenting with few ideas but seems its going to need more > > time for me to close on the eqvivalent solution that has per-regulator > > sync_state or something to that effect. So I thought to close on this > > series and attend to that seperately. > > > > Signed-off-by: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com> > > --- > > Changes in v3: > > If this is v3, why is not marked as such? I'm so sorry! i have fixed version and sent again (ignore this series) link - https://lore.kernel.org/all/20260407-read-rpmh-v3-v3-0-34079f92691c@oss.qualcomm.com/
© 2016 - 2026 Red Hat, Inc.