Removes conditional calling k_busy_wait() on single threaded
systems and uses k_sleep for both single and multi threaded
systems.
Commit e375d82 ("kernel: Implement k_sleep for Single Thread")
eliminated the need to call k_busy_wait() on single threaded
systems in place of k_sleep.
Signed-off-by: Ricardo Rivera-Matos <rriveram@opensource.cirrus.com>
Add an active discharge api for regulators. This uses the already
existing but previously unused regulator-active-discharge
property.
Signed-off-by: Ryan McClelland <ryanmcclelland@meta.com>
Reference counting was broken when adding the enable delay.
Now reverted to previous pattern.
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>
In some cases, it may be desirable to not have thread-safe reference
counting. For example, when CONFIG_MULTITHREADING=n.
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>
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>
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>
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>
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>
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>
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>
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>
