The setting of initial state in handled by the common driver,
which calls the enable function for any regulator that has
regulator-boot-on set, and is not already enabled.
Signed-off-by: Andy Sinclair <andy.sinclair@nordicsemi.no>
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>
Adds support for using the fixed and GPIO regulator drivers when
multithreading is disabled, such as in MCUboot.
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
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>
In some cases, the enable pin may be already enabled by a previous
stage, e.g. bootloader. Therefore, it is not desirable to disable
the pin, as it could cause malfunctioning of the device. Refactor init
procedure so that we pick the right GPIO flags during the first
configuration stage.
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>
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>
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>
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>
In order to bring consistency in-tree, migrate all drivers to the new
prefix <zephyr/...>. Note that the conversion has been scripted, refer
to #45388 for more details.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
k_work_schedule may return other non-negative value than 0.
When driver was adapted to the new k_work API that was not
taken into account.
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
Replace legacy API with new API. Note that this driver uses the
schedule, not reschedule, API, since triggers for delay never overlap.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Move users that are DEVICE_DT_DECLARE(DT_DRV_INST(n, ...)) to
DEVICE_DT_INST_DECLARE(n, ...) and similar for DEVICE_DT_DEFINE.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Use the devicetree node as the source of object name and other
information used when defining the device structure.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Nothing in the API description the delayed work structure sanctions
direct reference to internal fields. Do not assume that a delayed
work item can be submitted without delay by invoking k_work_submit()
with a reference to the contained work item. Instead submit with the
delayed API and no wait.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
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>
Andy Sinclair