The current implementation always sets the voltage before enabling,
even if the current voltage is in the allowed range.
This has some side effects, i.e. for PMIC regulators that are
pre-programmed for a specific value but allow voltage changes during
runtime. The side effect being that the regulator will always be reset
to the lower value of the voltage range at init.
Another usecase would be when a bootloader sets a specific voltage then
loads an application that uses the same driver.
The proposed fix is to evaluate the current voltage and try to bring
the actual voltage in range if the current voltage is not valid
according to the min/max constraints.
Tested on custom SAMD20 board with a custom RK816 PMIC driver.
Signed-off-by: Ionut Catalin Pavel <iocapa@iocapa.com>
Regulator voltage needs to be within allowed range before enabling. It
could happen that regulator default voltage is out of the allowed range,
so the regulator could be enabled at boot time producing a not-allowed
voltage.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The existing linear_range API did not allow values or windows outside of
the linear range (returned -EINVAL). With this change values are allowed
outside of the range, being adjusted to the edge values (min/max)
instead. In the case of windows, it is allowed to have partial
intersection. In both cases, the API assigns a valid index (nearest) and
returns -ERANGE. This change is useful because the main client of the
linear range API, regulators, needs such behavior. For example, If an
application specifies a voltage range from 1.0V to 1.5V and the
regulator supports from 1.2V to 2.7V, the regulator can configure a
voltage that satisfies the condition: 1.2V. With the current API, the
input would be refused because 1.0V lies outside of the 1.2V-2.7V range.
Also, for constant ranges, the minimum index is returned.
Tests have been updated/extended accordingly.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Since nPM1100 may be configured statically in some circuits, BUCK node
may note be defined, so neither API ops or init call are used in the
code. Add __unused attribute to account for such case.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@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>
BUCK1/2 are defined as "always on" regulators, however, there is a
special override register that allows to turn them on/off.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Some regulators are enabled by default, however, such condition cannot
be captured now by the regulator driver API. Refactor
regulator_common_init_enable to regulator_common_init (enable removed,
as it also sets mode) and add a new argument to specify such condition.
With this change, regulator_disable() and regulator_is_enabled() work as
expected without a first call to regulator_enable().
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
ISO/IEC 9899:1999 (C Standard), §7.4 Character handling <ctype.h>:
In all cases the argument is an int, the value of which shall be
representable as an unsigned char or shall equal the value of the macro
EOF. If the argument has any other value, the behavior is undefined.
So add a cast to unsigned char to make sure we do not trigger UB.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
- Refactor the regulator shell so that it exposes all regulator APIs
- vset/iset commands allow to specify a single value (equal min/max) or
a range
- Voltage/current input is now more user friendly, e.g. user can specify
units and decimals: 3.3v, 200mv, -4mv, etc.
- Reported values are also printed in a more user friendly way, e.g.
1800000 uV will be printed as 1.800 V.
- Added new command to list supported voltages
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Add a new API to query the configured regulator mode. Updated fake
driver and API tests.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Apply initial mode (regulator-initial-mode) as part of the
regulator_common_init_enable call. Update tests to cover this change.
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>
The edge voltages within a range need to be included as part of the
supported comparison.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Add a new API for drivers that can be called to initialize the regulator
at init time if `regulator-boot-on` or `regulator-always-on` are set.
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>
- Remove redundant comments
- Remove internal *_mode functions, as they were only used once.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Define regulator mode as an opaque type, same as we do in other
subsystems like GPIO (e.g. gpio_flags_t).
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Clarify the API for regulators that have the option to set mode
externally, such as PCA9420. Adjust the PCA9420 driver to comply with
the interface.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
- Function now returns error, value is obtained by reference. This
allows to propagate potential bus errors.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
- Mode specific APIs repeat the same functionality offered by non-mode
specific APIs
- The same functionality can be achieved by the non-mode APIs, since
they apply to the active mode which can be set using
regulator_set_mode() first.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The function can be implemented by using regulator_count_voltages() +
regulator_list_voltage(), so there's no need to defer the job to each
driver.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
- Rename to regulator_list_voltage (it is listing a single voltage)
- Function returns the value via a parameters, so that we can indicate
wether the given index is valid or not. If a driver doesn't implement
this call, function returns -EINVAL (as it should be).
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The regulator_count_modes was an API that was not useful. Unlike with
voltages where the interface guarantees they are zero-indexed, modes can
take an arbitrary identifier. So counting supported modes doesn't
provide any useful information such as if a mode is allowed.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
- Interface guarantees that voltage indices start from zero to
regulator_count_voltages()
- Function always return an unsigned number. If the device doesn't
implement the API returned value is zero, as expected.
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>
Add support for regulator mode related APIs to regulator shell, so that
the user can select new operation modes for the regulator and configure
target voltages
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
Cleanup regulator shell to use strtol() over atoi(), as strtol features
error detection. Remove device_is_ready() checks, and replace them with
NULL checks as device_get_binding() calls device_is_ready() interally
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
The I2C API already provides APIs to read/modify registers, so there is
no need to provide custom wrappers.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Drop the async enable function. This feature is rarely/never used,
complicates driver design, and doesn't really follow the sync/async API
design/naming used in other areas. In the future we can introduce
regulator_enable_async if needed, with support from the driver class (no
onoff). Note that drivers like PCA9420 did not implement any
asynchronous behavior. regulator-fixed implemented in the past
asynchronous behavior using work queues, an overkill for most GPIO
driven regulators. Let's keep things simple for now and extend the API
when needed, based on specific usecases.
In the current implementation, reference counting is managed by the
driver class. \isr-ok attribute is dropped, since calls are potentially
blocking. Note that drivers like PCA9420 already violated such rule.
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>
pca9420_i2c.h has neem remamed to pca9420.h (device only has I2C, so
it's kind of redundant to have i2c in the header name).
pmic_i2c.h was again not generic but designed specifically for PCA9420.
All its macros have been renamed, s/PMIC/PCA9420, and moved to the
pca9420.h header.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Store all common configuration settings in the parent device. This
change should save ROM, since it avoids duplication.
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>
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>
