linux-stable.git/drivers/regulator/core.c, branch v5.8

regulator: core: Add regulator bypass trace points

2020-05-29T16:17:02+00:00

Add new trace points for the start and end of enabling bypass on a
regulator, to allow monitoring of when regulators are moved into bypass
and how long that takes.

Signed-off-by: Charles Keepax 
Link: https://lore.kernel.org/r/20200529152216.9671-1-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown

Merge series "Fix regulators coupling for Exynos5800" from Marek Szyprowski :

2020-05-29T13:36:03+00:00

Hi!

This patchset is another attempt to fix the regulator coupling on
Exynos5800/5422 SoCs. Here are links to the previous attempts:

https://lore.kernel.org/linux-samsung-soc/20191008101709.qVNy8eijBi0LynOteWFMnTg4GUwKG599n6OyYoX1Abs@z/
https://lore.kernel.org/lkml/20191017102758.8104-1-m.szyprowski@samsung.com/
https://lore.kernel.org/linux-pm/cover.1589528491.git.viresh.kumar@linaro.org/
https://lore.kernel.org/linux-pm/20200528131130.17984-1-m.szyprowski@samsung.com/

The problem is with "vdd_int" regulator coupled with "vdd_arm" on Odroid
XU3/XU4 boards family. "vdd_arm" is handled by CPUfreq. "vdd_int" is
handled by devfreq. CPUfreq initialized quite early during boot and it
starts changing OPPs and "vdd_arm" value. Sometimes CPU activity during
boot goes down and some low-frequency OPPs are selected, what in turn
causes lowering "vdd_arm". This happens before devfreq applies its
requirements on "vdd_int". Regulator balancing code reduces "vdd_arm"
voltage value, what in turn causes lowering "vdd_int" value to the lowest
possible value. This is much below the operation point of the wcore bus,
which still runs at the highest frequency.

The issue was hard to notice because in the most cases the board managed
to boot properly, even when the regulator was set to lowest value allowed
by the regulator constraints. However, it caused some random issues,
which can be observed as "Unhandled prefetch abort" or low USB stability.

Adding more and more special cases to the generic code has been rejected,
so the only way to ensure the desired behavior on Exynos5800-based SoCs
is to make a custom regulator coupler driver.

Best regards,
Marek Szyprowski

Patch summary:

Marek Szyprowski (2):
regulator: extract voltage balancing code to separate function
soc: samsung: Add simple voltage coupler for Exynos5800

arch/arm/mach-exynos/Kconfig | 1 +
drivers/regulator/core.c | 49 ++++++++-------
drivers/soc/samsung/Kconfig | 3 +
drivers/soc/samsung/Makefile | 1 +
.../soc/samsung/exynos-regulator-coupler.c | 59 +++++++++++++++++++
include/linux/regulator/coupler.h | 8 +++
6 files changed, 101 insertions(+), 20 deletions(-)
create mode 100644 drivers/soc/samsung/exynos-regulator-coupler.c

--
2.17.1

base-commit: 8f3d9f354286745c751374f5f1fcafee6b3f3136

regulator: extract voltage balancing code to the separate function

2020-05-29T13:36:00+00:00

Move the coupled regulators voltage balancing code to the separate
function and allow to call it from the custom regulator couplers.

Signed-off-by: Marek Szyprowski 
Link: https://lore.kernel.org/r/20200529124940.10675-2-m.szyprowski@samsung.com
Signed-off-by: Mark Brown

Merge series "MAINTAINER entries for few ROHM power devices" from Matti Vaittinen :

2020-05-20T15:09:02+00:00

Add maintainer entries to a few ROHM devices and Linear Ranges

Linear Ranges helpers were refactored out of regulator core to lib so
that other drivers could utilize them too. (I guess power/supply drivers
and possibly clk drivers can benefit from them). As regulators is
currently the main user it makes sense the changes to linear_ranges go
through Mark's tree.

During past two years few ROHM PMIC drivers have been added to
mainstream. They deserve a supporter from ROHM side too :)

Patch 1:
	Maintainer entries for few ROHM IC drivers
Patch 2:
	Maintainer entry for linear ranges helpers

---

Matti Vaittinen (2):
  MAINTAINERS: Add entry for ROHM power management ICs
  MAINTAINERS: Add maintainer entry for linear ranges helper

 MAINTAINERS | 37 +++++++++++++++++++++++++++++++++++++
 1 file changed, 37 insertions(+)

base-commit: b9bbe6ed63b2b9f2c9ee5cbd0f2c946a2723f4ce
--
2.21.0

--
Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND

~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~
Simon says - in Latin please.
~~~ "non cogito me" dixit Rene Descarte, deinde evanescavit ~~~
Thanks to Simon Glass for the translation =]

regulator: Revert "Use driver_deferred_probe_timeout for regulator_init_complete_work"

2020-04-29T17:57:45+00:00

This reverts commit dca0b44957e5 ("regulator: Use
driver_deferred_probe_timeout for regulator_init_complete_work"),
as we ended up reverting the default deferred_probe_timeout
value back to zero, to preserve behavior with 5.6 we need to
decouple the regulator timeout which was previously 30 seconds.

This avoids breaking some systems that depend on the regulator
timeout but don't require the deferred probe timeout.

Cc: linux-pm@vger.kernel.org
Cc: Linus Walleij 
Cc: Thierry Reding 
Cc: Liam Girdwood 
Cc: Bjorn Andersson 
Cc: Saravana Kannan 
Cc: Todd Kjos 
Cc: Len Brown 
Cc: Pavel Machek 
Cc: Ulf Hansson 
Cc: Kevin Hilman 
Cc: "Rafael J. Wysocki" 
Cc: Rob Herring 
Reported-by: Marek Szyprowski 
Suggested-by: Mark Brown 
Signed-off-by: John Stultz 
Reviewed-by: Mark Brown 
Link: https://lore.kernel.org/r/20200429172349.55979-1-john.stultz@linaro.org
Signed-off-by: Greg Kroah-Hartman

regulator: use consumer->supply_name in debugfs/regulator_summary

2020-04-14T15:57:42+00:00

Make it easier to identify regulator consumers when consumer device
uses more than one supply.

Before:

  regulator                      ena use open bypass voltage current min     max
 -----------------------------------------------------------------------------------
  regulator-dummy                  1   0    2      0     0mV     0mA 0mV     0mV
     1-0010                                                          0mV     0mV
     1-0010                                                          0mV     0mV

After:

  regulator                      ena use open bypass voltage current min     max
 -----------------------------------------------------------------------------------
  regulator-dummy                  1   0    2      0     0mV     0mA 0mV     0mV
     1-0010-vccio                                                    0mV     0mV
     1-0010-vcc33                                                    0mV     0mV

Signed-off-by: Michał Mirosław 
Link: https://lore.kernel.org/r/731a4b299c6ae0ee9d8995157600a3477f21a36c.1585959068.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Mark Brown

Merge tag 'regulator-spi-v5.7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/misc

2020-03-30T21:58:26+00:00

Pull spi and regulator updates from Mark Brown:
 "At one point in the release cycle I managed to fat finger things and
  apply some SPI fixes onto a regulator branch and merge that into the
  SPI tree, then pull in a change shared with the MTD tree moving the
  Mediatek quadspi driver over to become the Mediatek spi-nor driver in
  the SPI tree.

  This has made a mess which I only just noticed while preparing this
  and I can't see a sensible way to unpick things due to other
  subsequent merge commits especially the pull from MTD so it looks like
  the most sensible thing to do is give up and combine the two pull
  requests.

  Fortunately both subsystems were fairly quiet this cycle, the
  highlights are:

  regulator:

   - Support for Monoloithic Power Systems MP5416, MP8867 and MPS8869
     and Qualcomm PMI8994 and SMB208.

  SPI:

   - Lots of enhancements for spi-fsl-dspi, including XSPI mode support,
     from Vladimir Oltean.

   - Support for amlogic Meson G12A, IBM FSI, Mediatek spi-nor (moved
     from MTD), NXP i.MX8Mx, Rockchip PX30, RK3308 and RK3328, and
     Qualcomm Atheros AR934x/QCA95xx"

* tag 'regulator-spi-v5.7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/misc: (118 commits)
  spi: efm32: Convert to use GPIO descriptors
  regulator: qcom_smd: Add pmi8994 regulator support
  regulator: da9063: Fix get_mode() functions to read sleep field
  spi: spi-fsl-lpspi: Replace zero-length array with flexible-array member
  spi: spi-s3c24xx: Replace zero-length array with flexible-array member
  spi: stm32: Fix comments compilation warnings
  spi: atmel-quadspi: Add verbose debug facilities to monitor register accesses
  spi: spi-fsl-dspi: Add support for LS1028A
  spi: spi-fsl-dspi: Move invariant configs out of dspi_transfer_one_message
  spi: spi-fsl-dspi: Fix interrupt-less DMA mode taking an XSPI code path
  spi: spi-fsl-dspi: Avoid NULL pointer in dspi_slave_abort for non-DMA mode
  spi: spi-fsl-dspi: Replace interruptible wait queue with a simple completion
  spi: spi-fsl-dspi: Protect against races on dspi->words_in_flight
  spi: spi-fsl-dspi: Avoid reading more data than written in EOQ mode
  spi: spi-fsl-dspi: Fix bits-per-word acceleration in DMA mode
  spi: spi-fsl-dspi: Fix little endian access to PUSHR CMD and TXDATA
  spi: spi-fsl-dspi: Don't access reserved fields in SPI_MCR
  regulator: driver.h: fix regulator_map_* function names
  regulator: da9063: fix suspend
  spi: mxs: Drop GPIO includes
  ...

regulator: core: Avoid device name duplication in NORMAL_GET

2020-03-13T16:49:53+00:00

With current code:
	st-gyro-i2c i2c-PRP0001:00: i2c-PRP0001:00 supply vdd not found, using dummy regulator

which looks a bit oververbose.

Replace this with simplified format string for the above case, and drop
"deviceless" case since for all dev_*() macros used in _regulator_get()
the "(null)" will be printed anyway.

Signed-off-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20200312183245.1612-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown

regulator: Use driver_deferred_probe_timeout for regulator_init_complete_work

2020-03-04T17:11:45+00:00

The regulator_init_complete_work logic defers the cleanup for an
arbitrary 30 seconds of time to allow modules loaded by userland
to start.

This arbitrary timeout is similar to the
driver_deferred_probe_timeout value, and its been suggested we
align these so users have a method to extend the timeouts as
needed.

So this patch changes the logic to use the
driver_deferred_probe_timeout value for the delay value if it
is set (using a delay of 0 if it is not).

Cc: linux-pm@vger.kernel.org
Cc: Greg Kroah-Hartman 
Cc: Linus Walleij 
Cc: Thierry Reding 
Cc: Mark Brown 
Cc: Liam Girdwood 
Cc: Bjorn Andersson 
Cc: Saravana Kannan 
Cc: Todd Kjos 
Cc: Len Brown 
Cc: Pavel Machek 
Cc: Ulf Hansson 
Cc: Kevin Hilman 
Cc: "Rafael J. Wysocki" 
Cc: Rob Herring 
Acked-by: Mark Brown 
Signed-off-by: John Stultz 
Link: https://lore.kernel.org/r/20200225050828.56458-7-john.stultz@linaro.org
Signed-off-by: Greg Kroah-Hartman

Merge branch 'regulator-5.5' into regulator-linus

2020-01-23T12:37:04+00:00