Messages in this thread | | | Date | Thu, 25 Aug 2022 10:15:11 -0500 | From | Andrew Halaney <> | Subject | Re: [RFT PATCH v2 1/2] regulator: core: Require regulator drivers to check uV for get_optimum_mode() |
| |
On Wed, Aug 24, 2022 at 02:22:56PM -0700, Douglas Anderson wrote: > The get_optimum_mode() for regulator drivers is passed the input > voltage and output voltage as well as the current. This is because, in > theory, the optimum mode can depend on all three things. > > It turns out that for all regulator drivers in mainline only the > current is looked at when implementing get_optimum_mode(). None of the > drivers take the input or output voltage into account. Despite the > fact that none of the drivers take the input or output voltage into > account, though, the regulator framework will error out before calling > into get_optimum_mode() if it doesn't know the input or output > voltage. > > The above behavior turned out to be a probelm for some boards when we > landed commit efb0cb50c427 ("regulator: qcom-rpmh: Implement > get_optimum_mode(), not set_load()"). Before that change we'd have no > problems running drms_uA_update() for RPMH regulators even if a > regulator's input or output voltage was unknown. After that change > drms_uA_update() started to fail. This is because typically boards > using RPMH regulators don't model the input supplies of RPMH > regulators. Input supplies for RPMH regulators nearly always come from > the output of other RPMH regulators (or always-on regulators) and RPMH > firmware is initialized with this knowledge and handles enabling (and > adjusting the voltage of) input supplies. While we could model the > parent/child relationship of the regulators in Linux, many boards > don't bother since it adds extra overhead. > > Let's change the regulator core to make things work again. Now if we > fail to get the input or output voltage we'll still call into > get_optimum_mode() and we'll just pass error codes in for input_uV > and/or output_uV parameters. > > Since no existing regulator drivers even look at input_uV and > output_uV we don't need to add this error handling anywhere right > now. We'll add some comments in the core so that it's obvious that (if > regulator drivers care) it's up to them to add the checks. > > Reported-by: Andrew Halaney <ahalaney@redhat.com> > Fixes: efb0cb50c427 ("regulator: qcom-rpmh: Implement get_optimum_mode(), not set_load()") > Signed-off-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Andrew Halaney <ahalaney@redhat.com>
Thanks again for the quick patches! - Andrew
| |