TI's TPS62864/TPS6286/TPS62868/TPS62869 are high-frequency synchronous
step-down converters controlled via I2C.  There are differences in the
electrical characteristics and packaging between the variants, but the
register interfaces are identical.
Signed-off-by: NVincent Whitchurch <vincent.whitchurch@axis.com>
Link: https://lore.kernel.org/r/20220204155241.576342-3-vincent.whitchurch@axis.comSigned-off-by: NMark Brown <broonie@kernel.org>

The I2C to the Atmel is very fussy, and locks up easily on
Pi0-3 particularly on reads.
If running at 100kHz on Pi3, reading the ID register generally
locks up the Atmel, but splitting the register select write and
read into two transactions is reliable.
Signed-off-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: NDetlev Casanova <detlev.casanova@collabora.com>
Link: https://lore.kernel.org/r/20220124220129.158891-10-detlev.casanova@collabora.comSigned-off-by: NMark Brown <broonie@kernel.org>

The I2C to the Atmel is very fussy, and locks up easily on
Pi0-3 particularly on reads.

The LCD power status is controlled solely by this driver, so
rather than reading it back from the Atmel, use the regmap cache
to avoid reading values.
Signed-off-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: NDetlev Casanova <detlev.casanova@collabora.com>
Link: https://lore.kernel.org/r/20220124220129.158891-9-detlev.casanova@collabora.comSigned-off-by: NMark Brown <broonie@kernel.org>

The driver was implementing a get_brightness function that
tried to read back the PWM setting of the display to report
as the current brightness.
The controller on the display does not support that, therefore
we end up reporting a brightness of 0, and that confuses
systemd's backlight service.

Remove the hook so that the framework returns the current
brightness automatically.
Signed-off-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: NDetlev Casanova <detlev.casanova@collabora.com>
Link: https://lore.kernel.org/r/20220124220129.158891-8-detlev.casanova@collabora.comSigned-off-by: NMark Brown <broonie@kernel.org>

We need independent control of the resets for the panel&bridge,
vs the touch controller.

Expose the reset lines that are on the Atmel's port C via the GPIO
API so that they can be controlled appropriately.
Signed-off-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: NDetlev Casanova <detlev.casanova@collabora.com>
Link: https://lore.kernel.org/r/20220124220129.158891-7-detlev.casanova@collabora.comSigned-off-by: NMark Brown <broonie@kernel.org>

The Atmel was doing a load of automatic sequencing of
control lines, however it was combining the touch controller's
reset with the bridge/panel control.

Change to control the control signals directly rather than
through the automatic POWERON control.
Signed-off-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: NDetlev Casanova <detlev.casanova@collabora.com>
Link: https://lore.kernel.org/r/20220124220129.158891-6-detlev.casanova@collabora.comSigned-off-by: NMark Brown <broonie@kernel.org>

The initial state of the Atmel is not defined, so ensure the
backlight PWM is set to 0 by default.
Signed-off-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: NDetlev Casanova <detlev.casanova@collabora.com>
Link: https://lore.kernel.org/r/20220124220129.158891-5-detlev.casanova@collabora.comSigned-off-by: NMark Brown <broonie@kernel.org>

The driver was using the regmap lock to serialise the
individual accesses, but we really need to protect the
timings of enabling the regulators, including any communication
with the Atmel.

Use a mutex within the driver to control overall accesses to
the Atmel, instead of the regmap lock.
Signed-off-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: NDetlev Casanova <detlev.casanova@collabora.com>
Link: https://lore.kernel.org/r/20220124220129.158891-4-detlev.casanova@collabora.comSigned-off-by: NMark Brown <broonie@kernel.org>

The Atmel is doing some things in the I2C ISR, during which
period it will not respond to further commands. This is
particularly true of the POWERON command.

Increase delays appropriately, and retry should I2C errors be
reported.
Signed-off-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: NDetlev Casanova <detlev.casanova@collabora.com>
Link: https://lore.kernel.org/r/20220124220129.158891-3-detlev.casanova@collabora.comSigned-off-by: NMark Brown <broonie@kernel.org>

There's no reason why 2 Raspberry Pi DSI displays can't be
attached to a Pi Compute Module, so the backlight names need to
be unique.

Use the parent dev_name. It's not as readable, but is unique.
Signed-off-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: NDetlev Casanova <detlev.casanova@collabora.com>
Link: https://lore.kernel.org/r/20220124220129.158891-2-detlev.casanova@collabora.comSigned-off-by: NMark Brown <broonie@kernel.org>

drivers/regulator/qcom_smd-regulator.c:1318:1-33: WARNING: Function "for_each_available_child_of_node" should have of_node_put() before return around line 1321.

Semantic patch information:
 False positives can be due to function calls within the for_each
 loop that may encapsulate an of_node_put.

Generated by: scripts/coccinelle/iterators/for_each_child.cocci

Fixes: 14e2976f ("regulator: qcom_smd: Align probe function with rpmh-regulator")
CC: Konrad Dybcio <konrad.dybcio@somainline.org>
Reported-by: Nkernel test robot <lkp@intel.com>
Signed-off-by: Nkernel test robot <lkp@intel.com>
Signed-off-by: NJulia Lawall <julia.lawall@inria.fr>
Link: https://lore.kernel.org/r/alpine.DEB.2.22.394.2201151210170.3051@hadrienSigned-off-by: NMark Brown <broonie@kernel.org>

max20086-regulator.c needs <linux/gpio/consumer.h> for an enum, some
macros, and a function prototype. (seen on ARCH=m68k)

Adding this header file fixes multiple build errors:

../drivers/regulator/max20086-regulator.c: In function 'max20086_i2c_probe':
../drivers/regulator/max20086-regulator.c:217:26: error: storage size of 'flags' isn't known
  217 |         enum gpiod_flags flags;
../drivers/regulator/max20086-regulator.c:261:27: error: 'GPIOD_OUT_HIGH' undeclared (first use in this function); did you mean 'GPIOF_INIT_HIGH'?
  261 |         flags = boot_on ? GPIOD_OUT_HIGH : GPIOD_OUT_LOW;
      |                           ^~~~~~~~~~~~~~
../drivers/regulator/max20086-regulator.c:261:44: error: 'GPIOD_OUT_LOW' undeclared (first use in this function); did you mean 'GPIOF_INIT_LOW'?
  261 |         flags = boot_on ? GPIOD_OUT_HIGH : GPIOD_OUT_LOW;
../drivers/regulator/max20086-regulator.c:262:27: error: implicit declaration of function 'devm_gpiod_get'; did you mean 'devm_gpio_free'? [-Werror=implicit-function-declaration]
  262 |         chip->ena_gpiod = devm_gpiod_get(chip->dev, "enable", flags);
../drivers/regulator/max20086-regulator.c:217:26: warning: unused variable 'flags' [-Wunused-variable]
  217 |         enum gpiod_flags flags;

Fixes: bfff546a ("regulator: Add MAX20086-MAX20089 driver")
Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
Reported-by: Nkernel test robot <lkp@intel.com>
Cc: Watson Chow <watson.chow@avnet.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://lore.kernel.org/r/20220115033603.24473-1-rdunlap@infradead.orgSigned-off-by: NMark Brown <broonie@kernel.org>

This code accidentally returns PTR_ERR(NULL) which is success.  It
should return a negative error code.

Fixes: bfff546a ("regulator: Add MAX20086-MAX20089 driver")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://lore.kernel.org/r/20220111072657.GK11243@kiliSigned-off-by: NMark Brown <broonie@kernel.org>

The MAX20086-MAX20089 are dual/quad power protectors for cameras. Add a
driver that supports controlling the outputs individually. Additional
features, such as overcurrent detection, may be added later if needed.
Signed-off-by: NWatson Chow <watson.chow@avnet.com>
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://lore.kernel.org/r/20220106224350.16957-3-laurent.pinchart+renesas@ideasonboard.comSigned-off-by: NMark Brown <broonie@kernel.org>

The RPMh regulator driver is much newer and gets more attention, which in
consequence makes it do a few things better. Update qcom_smd-regulator's
probe function to mimic what rpmh-regulator does to address a couple of
issues:

- Probe defer now works correctly, before it used to, well,
  kinda just die.. This fixes reliable probing on (at least) PM8994,
  because Linux apparently cannot deal with supply map dependencies yet..

- Regulator data is now matched more sanely: regulator data is matched
  against each individual regulator node name and throwing an -EINVAL if
  data is missing, instead of just assuming everything is fine and
  iterating over all subsequent array members.

- status = "disabled" will now work for disabling individual regulators in
  DT. Previously it didn't seem to do much if anything at all.
Signed-off-by: NKonrad Dybcio <konrad.dybcio@somainline.org>
Link: https://lore.kernel.org/r/20211230023442.1123424-1-konrad.dybcio@somainline.orgSigned-off-by: NMark Brown <broonie@kernel.org>

Return value from regmap_update_bits() directly instead
of taking this in another redundant variable.
Reported-by: NZeal Robot <zealci@zte.com.cn>
Signed-off-by: NMinghao Chi <chi.minghao@zte.com.cn>
Signed-off-by: NCGEL ZTE <cgel.zte@gmail.com>
Link: https://lore.kernel.org/r/20220104104139.601031-1-chi.minghao@zte.com.cnSigned-off-by: NMark Brown <broonie@kernel.org>

Receiving the Over-Current Protection interrupt while the regulator is
disabled does not count as unhandled/failure (IRQ_NONE, or 0 as it were)
but a "fake event", usually due to inrush as the is regulator about to
be enabled.

Fixes: 390af53e ("regulator: qcom-labibb: Implement short-circuit and over-current IRQs")
Signed-off-by: NMarijn Suijten <marijn.suijten@somainline.org>
Reviewed-by: NAngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
Link: https://lore.kernel.org/r/20211224113450.107958-1-marijn.suijten@somainline.orgSigned-off-by: NMark Brown <broonie@kernel.org>

The TPS68470 PMIC provides Clocks, GPIOs and Regulators. At present in
the kernel the Regulators and Clocks are controlled by an OpRegion
driver designed to work with power control methods defined in ACPI, but
some platforms lack those methods, meaning drivers need to be able to
consume the resources of these chips through the usual frameworks.

This commit adds a driver for the regulators provided by the tps68470,
and is designed to bind to the platform_device registered by the
intel_skl_int3472 module.

This is based on this out of tree driver written by Intel:
https://github.com/intel/linux-intel-lts/blob/4.14/base/drivers/regulator/tps68470-regulator.c
with various cleanups added.
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20211203102857.44539-6-hdegoede@redhat.comSigned-off-by: NMark Brown <broonie@kernel.org>

Return value from twlreg_write() directly instead
of taking this in another redundant variable.
Reported-by: NZeal Robot <zealci@zte.com.cn>
Signed-off-by: NMinghao Chi <chi.minghao@zte.com.cn>
Link: https://lore.kernel.org/r/20211213021655.435423-1-chi.minghao@zte.com.cnSigned-off-by: NMark Brown <broonie@kernel.org>

Add the rpmh regulators found in PM8450 PMIC
Signed-off-by: NVinod Koul <vkoul@kernel.org>
Tested-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20211201072515.3968843-3-vkoul@kernel.orgSigned-off-by: NMark Brown <broonie@kernel.org>

Add the DA9141 and DA9142 regulators device recognition data and
operational parameters.
Signed-off-by: NAdam Ward <Adam.Ward.opensource@diasemi.com>
Link: https://lore.kernel.org/r/5f5b9b02f07578cd36c6bc266349a56efc9b08d1.1638223185.git.Adam.Ward.opensource@diasemi.comSigned-off-by: NMark Brown <broonie@kernel.org>

Prevent changing current limit when enabled as a precaution against
possibile instability due to tight integration with switching cycle
Signed-off-by: NAdam Ward <Adam.Ward.opensource@diasemi.com>
Link: https://lore.kernel.org/r/52ee682476004a1736c1e0293358987319c1c415.1638223185.git.Adam.Ward.opensource@diasemi.comSigned-off-by: NMark Brown <broonie@kernel.org>

Add support for PMG1110 regulators.
Signed-off-by: NSatya Priya <quic_c_skakit@quicinc.com>
Link: https://lore.kernel.org/r/1637668167-31325-3-git-send-email-quic_c_skakit@quicinc.comSigned-off-by: NMark Brown <broonie@kernel.org>

The PM8226 PMIC is very often seen on
MSM8x26 boards.
Suggested-by: NIvaylo Ivanov <ivo.ivanov.ivanov1@gmail.com>
Signed-off-by: NDominik Kobinski <dominikkobinski314@gmail.com>
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20211123181119.2897-1-dominikkobinski314@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Provide a generic map_event helper for regulators which have a notification
IRQ with single, well defined purpose. Eg, IRQ always indicates exactly one
event for exactly one regulator device. For such IRQs the mapping is
trivial.
Signed-off-by: NMatti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Link: https://lore.kernel.org/r/603b7ed1938013a00371c1e7ccc63dfb16982b87.1637736436.git.matti.vaittinen@fi.rohmeurope.comSigned-off-by: NMark Brown <broonie@kernel.org>

Use common restricted voltage setting instead of implementing own.
Signed-off-by: NMatti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Link: https://lore.kernel.org/r/5a0ee14852802690241568a29ed19ff9550b0b08.1637233864.git.matti.vaittinen@fi.rohmeurope.comSigned-off-by: NMark Brown <broonie@kernel.org>

Few ROHM PMICs have regulators where voltage setting can be done only
when regulator is disabled. Add helper for those PMICs.
Signed-off-by: NMatti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Link: https://lore.kernel.org/r/6f51871e9fea611d133b5dd2560f4a7ee1ede9cd.1637233864.git.matti.vaittinen@fi.rohmeurope.comSigned-off-by: NMark Brown <broonie@kernel.org>

When an i2c remove callback fails, the i2c core emits a generic error
message and still removes the device. Apart from the message there the
return value isn't further used.

So don't return an error code after having already emitted a driver
specific warning about the problem to prevent two messages about the
same issue.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20211116110951.1213566-1-u.kleine-koenig@pengutronix.deSigned-off-by: NMark Brown <broonie@kernel.org>

Fixed regulator can't change voltage and regulator_sync_voltage()
returns -EINVAL in this case. Make regulator_sync_voltage() to succeed
for regulators that are incapable to change voltage.

On NVIDIA Tegra power management driver needs to sync voltage and we have
one device (Trimslice) that uses fixed regulator which is getting synced.
The syncing error isn't treated as fatal, but produces a noisy error
message. This patch silences that error.
Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
Link: https://lore.kernel.org/r/20211021183308.27786-1-digetx@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Driver was upstreamed in 2013 and never got a user, remove it.
Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
Link: https://lore.kernel.org/r/20211021192258.21968-3-digetx@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

The MFD for SY7636A still isn't merged so we need a dependency even if
it ends up not having a real driver due to the header file.
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NMark Brown <broonie@kernel.org>

Add basic support for UniPhier NX1 SoC. This includes a compatible string
and the same SoC-dependent data as PXs2 SoC.
Signed-off-by: NKunihiko Hayashi <hayashi.kunihiko@socionext.com>
Link: https://lore.kernel.org/r/1634520605-16583-3-git-send-email-hayashi.kunihiko@socionext.comSigned-off-by: NMark Brown <broonie@kernel.org>

Add the configuration for pm6350 regulators. The supplies are not known
so leave them out for now.

Additionally leave out configuration of smps3 - smps5 and ldo17 as these
are not configured in the downstream kernel and the type of them is not
known.
Signed-off-by: NLuca Weiss <luca@z3ntu.xyz>
Link: https://lore.kernel.org/r/20211007212444.328034-4-luca@z3ntu.xyzSigned-off-by: NMark Brown <broonie@kernel.org>

Signed-off-by: NAlistair Francis <alistair@alistair23.me>
Link: https://lore.kernel.org/r/20211015122551.38951-5-alistair@alistair23.meSigned-off-by: NMark Brown <broonie@kernel.org>

Removing all linux/gpio.h and linux/of_gpio.h dependencies and replacing
them with the gpiod interface.
Signed-off-by: NMaíra Canal <maira.canal@usp.br>
Link: https://lore.kernel.org/r/YWxmL2baF5AdzyHv@fedoraSigned-off-by: NMark Brown <broonie@kernel.org>

After this driver was converted to gpiod, clang started warning:

vers/regulator/lp872x.c:689:57: error: implicit conversion from
enumeration type 'enum lp872x_dvs_state' to different enumeration type
'enum gpiod_flags' [-Werror,-Wenum-conversion]
        dvs->gpio = devm_gpiod_get_optional(lp->dev, "ti,dvs", pinstate);
                    ~~~~~~~~~~~~~~~~~~~~~~~                    ^~~~~~~~
1 error generated.

lp872x_dvs_state was updated to have values from gpiod_flags but this is
not enough to avoid an implicit conversion warning from either GCC or
clang (although GCC enables this warning under -Wextra instead of -Wall
like clang so it is not seen under normal builds).

Eliminate lp872x_dvs_state in favor of using gpiod_flags everywhere so
that there is no more warning about an implicit conversion.

Fixes: 72bf80cf ("regulator: lp872x: replacing legacy gpio interface for gpiod")
Link: https://github.com/ClangBuiltLinux/linux/issues/1481Signed-off-by: NNathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/r/20211019004335.193492-1-nathan@kernel.orgSigned-off-by: NMark Brown <broonie@kernel.org>

Removing all linux/gpio.h and linux/of_gpio.h dependencies and replacing
them with the gpiod interface
Signed-off-by: NMaíra Canal <maira.canal@usp.br>
Message-Id: <YWma2yTyuwS5XwhY@fedora>
Signed-off-by: NMark Brown <broonie@kernel.org>

The driver and its bindings, before commit 04f9f068 ("regulator:
s5m8767: Modify parsing method of the voltage table of buck2/3/4") were
requiring to provide at least one safe/default voltage for DVS registers
if DVS GPIO is not being enabled.

IOW, if s5m8767,pmic-buck2-uses-gpio-dvs is missing, the
s5m8767,pmic-buck2-dvs-voltage should still be present and contain one
voltage.

This requirement was coming from driver behavior matching this condition
(none of DVS GPIO is enabled): it was always initializing the DVS
selector pins to 0 and keeping the DVS enable setting at reset value
(enabled).  Therefore if none of DVS GPIO is enabled in devicetree,
driver was configuring the first DVS voltage for buck[234].

Mentioned commit 04f9f068 ("regulator: s5m8767: Modify parsing
method of the voltage table of buck2/3/4") broke it because DVS voltage
won't be parsed from devicetree if DVS GPIO is not enabled.  After the
change, driver will configure bucks to use the register reset value as
voltage which might have unpleasant effects.

Fix this by relaxing the bindings constrain: if DVS GPIO is not enabled
in devicetree (therefore DVS voltage is also not parsed), explicitly
disable it.

Cc: <stable@vger.kernel.org>
Fixes: 04f9f068 ("regulator: s5m8767: Modify parsing method of the voltage table of buck2/3/4")
Signed-off-by: NKrzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Acked-by: NRob Herring <robh@kernel.org>
Message-Id: <20211008113723.134648-2-krzysztof.kozlowski@canonical.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

There are lots of fields in struct hi6421_spmi_pmic that aren't
used. As a matter of fact, only regmap is needed.

So, drop the struct as a whole, and set regmap as the drvdata.
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>
Acked-by: NMark Brown <broonie@kernel.org>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/1828cb783b1ebca0b98bf0b3077d8701adb228f7.1630586862.git.mchehab+huawei@kernel.org

Consistently use the defines for buck control mask values.
Signed-off-by: NMatti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Link: https://lore.kernel.org/r/YVqpujZLZmaiqwe8@fedoraSigned-off-by: NMark Brown <broonie@kernel.org>