add driver for Monolithic Power Systems MPM54304 with basic
functionality to enable/disable the buck regulators
Signed-off-by: Elias Speinle <e.speinle@vogl-electronic.com>
nRF53X HV regulator differs from eg nRF52X as it offers a silent mode
option. For this reason, a new compatible is used, even if now such
capability is not exposed yet.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
Some Nordic SoCs, like nRF52 contain an internal regulator for the main
SoC supply. Depending on the SoC, the regulator can have multiple
configurations (e.g. single/double stage), which mainly depends on
supporting "high-voltage" mode or not (VDDH pin supply). This patch adds
bindings for nRF5X regulator and nRF52X HV regulator.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
Add specifier cells for nxp vref, when some other
peripherals use the vref to provide reference voltage,
this cells can be used to pass-in vref target voltage.
Signed-off-by: Zhaoxiang Jin <Zhaoxiang.Jin_1@nxp.com>
Remove nxp_ground_select property.
Delete the use of NXP vref peripheral CSR register REFL_GRL_SEL bit.
Signed-off-by: Zhaoxiang Jin <Zhaoxiang.Jin_1@nxp.com>
Adds support for the PGOOD pin. This pin is asserted by the
regulator when converter startup has completed and the output
is stable. If the PGOOD pin is not used, the PGOOD state is
check via the PGOOD_PIN_STS bit.
Signed-off-by: Ricardo Rivera-Matos <rriveram@opensource.cirrus.com>
Added is_enabled devicetree property to fake regulator.
Allows testing of init behaviour when regulator is enabled
in hardware.
Signed-off-by: Andy Sinclair <andy.sinclair@nordicsemi.no>
This add regulator driver for Smartbond DA1469X SOC.
Driver can control VDD, V14, V18, V18P, V30 rails,
full voltage range supported by SOC is covered.
For VDD, V14, V18, V18P DCDC can be configured.
Special VDD_CLAMP (always on) and VDD_SLEPP are added
to allow configuration of VDD in sleep modes.
Signed-off-by: Jerzy Kasenberg <jerzy.kasenberg@codecoup.pl>
A configurable delay during regulator switch on is currently
only supported by the GPIO and fixed regulator drivers.
This functionality has been moved to the common driver, so it can
be easily added to any regulator driver.
Signed-off-by: Andy Sinclair <andy.sinclair@nordicsemi.no>
Add binding, include header, and driver for NXP VREF IP block.
NXP VREF is an internal voltage reference generator on some SOCs
that fits well with the regulator API in zephyr.
Signed-off-by: Declan Snyder <declan.snyder@nxp.com>
AXP192 is a small power management IC, that also
features 5 GPIOS.
Besides GPIO driver this commit also includes needed modifications
in axp192 regulator and mfd driver as LDOIO0 functioanlity
is multiplexed with GPIO0 pin.
Signed-off-by: Martin Kiepfer <mrmarteng@teleschirm.org>
Add basic support of 'regulator-gpio'. For now, it is support
only controling voltage and driver presents only six functions:
* enable and disable the regulator;
* set and get voltage;
* count and list of voltage(s).
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Allow properties 'regulator-min-microvolt' and 'regulator-max-microvolt'
for fixed regulators: Note: they should be equal.
Add simple functions for getting list of allowed and count of voltages.
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Possible situation is that in some driver, devices can be controlled in
different ways: in some, we can only turn the power on or off, in others,
we can only control the voltage, and in some, we can control power supply
or voltage level. There may also be devices where there is no control
over power supply at all. A clear example of this can be eMMC devices
where the voltage is usually fixed and they are always powered on.
However, we would like to have a common code for controlling all the
mentioned types of devices, at least the driver shouldn't worry about the
implementation details of voltage regulators. Therefore, there may exist
empty regulators - regulators that only contain information about the
supported voltage, and we cannot change anything in them. The device tree
node description for such a regulator is only necessary for compatibility
with other regulators. Hence, we need to add the possibility of the
existence of such a dummy fixed-regulator.
In this commit, support for a fixed dummy regulator without the ability
for any control has been added. Note that such support also exists in the
Linux kernel. In other words, the logic of the fixed regulator has been
aligned with the logic of the fixed regulator inside the Linux kernel.
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
AXP192 is a small and simple power management IC featuring different
LDOs, DCDCs, AINs and also GPIOs. It also offers functionaltiy for
battery management.
This change includes the basic regulator driver functionaltiy for
LDO2-3 and DCDC1-3 as well as the mfd driver layer. Further drivers
for GPIO and ADC will follow.
Drivers have been developed and tested on M5StackCore2, an ESP32-based
board. Support for M5StackCore2 is still in progress.
Signed-off-by: Martin Kiepfer <mrmarteng@teleschirm.org>
Add a new regulator driver for Analog Devices ADP5360. While it is a MFD
device, only support for BUCK/BUCKBOOST regulators is added in this
patch.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The regulator driver has a configured min/max range that is used
to limit set values, and to initialise the regulator.
A new init value has been added, so that the startup voltage can
be higher than the lowest permitted value.
Signed-off-by: Andy Sinclair <andy.sinclair@nordicsemi.no>
While nPM1100 is to be operated in fixed configuration for some
applications, it has some degree of configuration via GPIOs. For
example, mode (auto/PWM) can be configured via MODE pin. VBUS current
can also be adjusted using ISET pin, even though there is no API yet to
limit the PMIC input current.
This patch adds a new regulator class driver for nPM1100 PMIC, so that
it can be used with the standard regulator API when needed.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Add FFF-based fake regulator driver. This driver can be used as a stub
or mock in testing.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
These inherited properties from Linux bindings are not supported yet.
The reason for the removal is because regulator-couple-with requires
definition of #cells spec, unless bindings explicitely ban the property
or use allowlist.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
PCA9420 PMIC offers of multiple operation states, or DVS (Dynamic
Voltage Scaling). Such states may be automatically changed by hardware
using MODESEL0/1 pins. Certain MCUs allow to automatically configure
certain output pins when entering low power modes so that PMIC state is
changed without software intervention. This means that application just
needs to configure the voltages for each state using
`nxp,modeN-microvolt`, set `nxp,enable-modesel-pins` in devicetree and
forget about configuring regulators.
This patch introduces a new _parent_ API to expose such functionality in
a vendor agnostic way. Consider this API as experimental for now, until
we have other usecases.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Most of devicetree properties for regulator, such as:
- regulator-min/max-microvolt
- regulator-min/max-microamp
- regulator-allowed-modes
- etc.
Are meant to specify limits on what consumers may set. They are **NOT**
meant to describe the hardware capabilities. For example, I could have a
BUCK converter that supports 0-5V output voltage, but my circuit may
only allow working on the 2.7-3.3V range.
This patch reworks the API so that the API class layer manages this
information. This is done by drivers collecting all such fields in a
common configuration structure that is later accessed by the class
layer. This simplifies drivers implementation. For example, if A
consumer calls regulator_set_voltage() with a voltage that is supported
but not allowed, driver code won't be called. Similarly, if a regulator
is configured to be `always-on`, enable/disable driver code will never
be called.
Drivers have been adjusted. PCA9420 mode settings have been removed from
devicetree in this commit as they are not actual modes but PMIC states.
This will be refactored in a follow-up commit.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
- Similar to what was done for other parts of the driver, remove any
register specification from Devicetree (modesel-reg/mask)
- Keep all the information in the driver, and define modes as "numbers",
e.g. PCA9420_MODE0: 0, PCA9420_MODE1: 1, etc.
- Bindings provide IC defaults now (all modes allowed 0/1/2/3 and
initial mode set to 0).
- When mode is controlled via the MODESEL0/1 pins (ie directly by an iMX
MCU using the dedicated PMIC_MODE0/1 pins), the driver will not allow
to select a mode (it is not possible). This mode is now enabled by
setting `nxp,enable-modesel-pins` in Devicetree. When enabled, all the
allowed modes are configured to be selectable via pins. When disabled,
mode can be set via I2C (using TOP_CNTL3 MODE0/1_I2C fields)
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Remove regulator-fixed-sync specialization, create a single driver that
is always synchronous. The asynchronous part is rarely/never used, so
let's keep things simple for now.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The driver had a conceptual issue regarding current limitation. PCA9420
is able to limit the current flowing through VIN, ie input current. This
is a global setting, not individual to each regulator. This patch
creates a new DT property: nxp,vin-ilim-microamp to specify such limit.
It is applied when the device is initialized.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Voltage ranges were hardcoded in Devicetree, however, things can be
significantly simplified by using the recently introduce linear ranges
API. All values are now computed using information stored in the driver,
so there is no need to store any lookup table in ROM. Code should now
both be faster in average and consume less ROM.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Maximum current was not specified. Even though not used, yet, it is a
valuable information. Values taken from PCA9420 datasheet, Figure 1
"Simplified block diagram".
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Regulator registers were set for each BUCK/LDO in DT, likely because of
the way the devices were instantiated. When using a generic iterator,
ie, DT_INST_FOREACH_CHILD, there's no way to differentiate the child
being _parsed_. Since instantiation happens now based on child node
names, we are able to know which registers each devices gets assigned at
the driver level. This greatly simplifies Devicetree, and it actually
removes information that is not strictly hardware description from it.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Right now the PCA9420 driver instantiates by iterating over all
children. This is somewhat problematic, for a few reasons:
- Since instantiation is generic code, we're forced to put internal
details on Devicetree, e.g. reg-masks. After this change, this will no
longer be necessary.
- We take all children, regardless of what is defined in DT.
While we have no means to validate Devicetree node names as in Linux
dtschema, this approach allows us to have per-child specific
initialization code. This is somewhat similar to the Linux approach.
Note: nodelabels have been removed, since they were not used.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
regulator-allowed-modes/regulator-initial-mode are standard properties
defined in regulator.yaml, so use them.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
