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>
Import all Linux properties, so that we can maximize compatiblity with
upstream bindings.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Following Linux regulator.yaml, regulator-name is a common property for
all regulators.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
DTS property attributes are (by default) not required.
Explicitly specifying `required: false` is redundant.
Perhaps a warning to that effect would be useful.
Signed-off-by: Chris Friedt <cfriedt@meta.com>
The "pmic" driver was in reality a driver for NXP PCA9420 PMIC. There's
no "universal PMIC". While the driver may work for other NXP PMICs, it
is clearly not generic for other vendors PMIC.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Add support for regulator-boot-on to PMIC driver. Many PMIC devices will
be enabled at boot, so this property allows the regulator framework
to correctly track their state.
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
Add mode selection properties for regulator-pmic compatible. These
mode selection properties will be used with regulators that support
multiple modes, with each mode enabling specific voltage and current
limits.
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
Refactor binding to use root PMIC IC, so that properties can be shared
between regulator devices. Each individual regulator output is still
created as an individual device, since the regulator API aligns with
these devices better than the PMIC IC itself.
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
All in tree device drivers use some form of DEVICE_DT_GET
so we no longer need to require label properties.
Signed-off-by: Kumar Gala <galak@kernel.org>
All in tree device drivers use some form of DEVICE_DT_GET
so we no longer need to require label properties.
Signed-off-by: Kumar Gala <galak@kernel.org>
This commit adds a generic i2c regulator driver, and enables the NXP
PCA9420 PMIC IC using this driver. The regulator driver also exposes an
additional API in include/drivers/regulator/consumer.h, which allows
drivers to implement support for adjusting voltage levels and current
limits, if their device supports it.
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
This provides structure for the regulator device hierarchy and a
driver for GPIO-controlled regulators along with its binding.
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
This PR follows Linux in defining devicetree content for generic
voltage and current regulators, and an initial driver API for
controlling them.
A regulator itself may depend on a power source, so it needs to
support the properties that enable that power source.
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
