mbox series

[v1,00/11] Continuing the work on coupled regulators

Message ID 20181005153638.1886-1-digetx@gmail.com
Headers show
Series Continuing the work on coupled regulators | expand

Message

Dmitry Osipenko Oct. 5, 2018, 3:36 p.m. UTC
Hello,

Maciej moved on to work on something else and kindly allowed me to
take over the coupled regulators patches [0] which I'll try to finalize.

I recently started to work on adding DVFS support to the CPUFreq driver
of NVIDIA Tegra20/30 which require the coupled regulators functionality.
Both Tegra20 and Tegra30 have the voltage "max-spread" constraint.
Tegra30 has an additional constraint, the "max-step" voltage.

What is done in this series:

1. Re-worked the original "Add voltage balancing mechanism" patch from
   Maciej by:
        1) Fixing infinite loop within regulator_balance_voltage().
        2) Handling suspend_state_t properly.
        3) Fixing broken compilation of the patch.

2. Added pair of patches to clean up regulator-couple resolving.

3. Changed device tree binding of the regulator-coupled-max-spread property
   to make it more flexible.

4. Added new device tree property, the regulator-max-step-microvolt.

5. Implemented wait/wound mutex which was suggested by Lucas Stach in the
   review comment to [0]. I've tested w/w locking extensively (including
   CONFIG_DEBUG_WW_MUTEX_SLOWPATH) and quite confident that everything is
   okay.

6. Patches were tested with KASAN on Tegra20 / Tegra30, I tried to cover
   various cases and verified that voltage constraints not violated under
   different circumstances.

Please review, thanks.

[0] https://lkml.org/lkml/2018/4/23/619

Dmitry Osipenko (9):
  regulator: core: Mutually resolve regulators coupling
  regulator: core: Don't allow to get regulator until all couples
    resolved
  dt-bindings: regulator: Change regulator-coupled-max-spread property
  regulator: core: Limit regulators coupling to a single couple
  dt-bindings: regulator: Document new regulator-max-step-microvolt
    property
  regulator: core: Add new max_uV_step constraint
  regulator: core: Decouple regulators on regulator_unregister()
  regulator: core: Use ww_mutex for regulators locking
  regulator: core: Properly handle case where supply is the couple

Maciej Purski (2):
  regulator: core: Add voltage balancing mechanism
  regulator: core: Change voltage setting path

 .../bindings/regulator/regulator.txt          |   7 +-
 drivers/regulator/core.c                      | 821 +++++++++++++++---
 drivers/regulator/of_regulator.c              |   4 +
 include/linux/regulator/driver.h              |   5 +-
 include/linux/regulator/machine.h             |   3 +
 5 files changed, 713 insertions(+), 127 deletions(-)

Comments

Tony Lindgren Oct. 8, 2018, 5:58 p.m. UTC | #1
* Dmitry Osipenko <digetx@gmail.com> [181005 15:43]:
> 1. Re-worked the original "Add voltage balancing mechanism" patch from
>    Maciej by:
>         1) Fixing infinite loop within regulator_balance_voltage().
>         2) Handling suspend_state_t properly.
>         3) Fixing broken compilation of the patch.

Thanks for fixing these, this series no longer hangs for me
on beagle-x15.

Regards,

Tony
Dmitry Osipenko Oct. 9, 2018, 8:52 a.m. UTC | #2
On 10/8/18 8:58 PM, Tony Lindgren wrote:
> * Dmitry Osipenko <digetx@gmail.com> [181005 15:43]:
>> 1. Re-worked the original "Add voltage balancing mechanism" patch from
>>    Maciej by:
>>         1) Fixing infinite loop within regulator_balance_voltage().
>>         2) Handling suspend_state_t properly.
>>         3) Fixing broken compilation of the patch.
> 
> Thanks for fixing these, this series no longer hangs for me
> on beagle-x15.

Thank you very much for testing once again!
Mark Brown Nov. 8, 2018, 1:07 p.m. UTC | #3
On Fri, Oct 05, 2018 at 06:36:37PM +0300, Dmitry Osipenko wrote:

> Wait/wound mutex shall be used in order to avoid lockups on locking of
> coupled regulators.

This breaks the build due to a few of the drivers (wm8350 and da9210 at
least) taking rdev locks in their interrupt handlers.  I'd suggest
adding a function for those drivers to use - exposing the ww context
seems like the wrong thing to do there.

Otherwise the series looks good, I've applied everything up to here.
Thanks for taking the time to pick this up, and especially for figuring
out the ww_mutex conversion.
Dmitry Osipenko Nov. 8, 2018, 4:53 p.m. UTC | #4
On 08.11.2018 16:07, Mark Brown wrote:
> On Fri, Oct 05, 2018 at 06:36:37PM +0300, Dmitry Osipenko wrote:
> 
>> Wait/wound mutex shall be used in order to avoid lockups on locking of
>> coupled regulators.
> 
> This breaks the build due to a few of the drivers (wm8350 and da9210 at
> least) taking rdev locks in their interrupt handlers.  I'd suggest
> adding a function for those drivers to use - exposing the ww context
> seems like the wrong thing to do there.

I totally missed those drivers, will fix them in v2.

> Otherwise the series looks good, I've applied everything up to here.
> Thanks for taking the time to pick this up, and especially for figuring
> out the ww_mutex conversion.
> 

Thank you.