The workaround for the nRF52 anomaly 109 that is implemented in
the nrfx_pwm driver uses interrupts generated by a selected EGU
instance and by the enabled PWM instances (even if the interrupts
are not used in generation of the PWM output signals).
Add required IRQ_CONNECT calls so that those interrupts are
properly handled.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
- use CONFIG_HAS_HW_NRF_* symbols consistently in nRF multi-instance
drivers when creating particular driver instances
- remove unnecessary hidden Kconfig options that indicated the type of
peripheral to be used by a given instance (e.g. SPI, SPIM, or SPIS)
and enabled proper nrfx driver instance; instead, use one option per
peripheral type and include the corresponding shim driver flavor into
compilation basing on that option (not the one that enables the nrfx
driver as it was incorrectly done so far in some cases)
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Current implementation of `nrfx_pwm_stopped_check()` doesn't work
as expected when user doesn't provide event handler.
Workaround for that is to use low level function for checking whether
STOPPED event arrived.
The workaround should be removed when `nrfx_pwm_stopped_check()`
will contain needed functionality.
Signed-off-by: Adam Wojasinski <adam.wojasinski@nordicsemi.no>
New nrfx release aligns PWM fields in driver instance structure
to common nrfx naming convention.
Signed-off-by: Adam Wojasinski <adam.wojasinski@nordicsemi.no>
Since PINCTRL and pinctrl-0 is now required, there's no point in doing
extra validation at driver level. Modify the macro to just check that
sleep state is present when needed, since it was the only remaining
assertion that was not covered. Renamed the macro to make it more clear
what it does: NRF_DT_CHECK_NODE_HAS_PINCTRL_SLEEP
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
This is a follow-up to commit 63d6cfd654.
Use a bit mask to store information about channels that need to be
driven by the PWM peripheral instead of inspecting the `seq_values`
array each time.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
This is a follow-up to commit 63d6cfd654.
Revert unwanted PWM_NRFX_CH_POLARITY_MASK to PWM_NRFX_CH_COMPARE_MASK
replacement that was accidentally done in the above commit.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
This commits refactors implementation of the pwm_set_cycles function
to fix the following issues:
- when a channel was already set with a non-zero pulse width, setting
cycles for another one required specifying a matching period value,
even if that value was to be ignored anyway when the channel was to
be set to constant inactive or active level; due to this limitation,
it was not possible to e.g. use the LED driver API and turn off a LED
while another one (within the same PWM instance) was blinking
- the above limitation also applied when a channel was set with a pulse
width equal to period (duty 100%); even though such channel was not
in fact using the PWM peripheral, other channels within the same PWM
instance were forced to use the same period
- after a PWM generation was started for a channel, it was not possible
to change its pulse width before two PWM periods passed (while it
should be possible to change it after every period); this was caused
by a looping mechanism that was unnecessarily activated in the PWM
peripheral
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Fix the instance config structure name so that it's coherent with the
data one (missing underscore after the instance idx).
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
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>
The variable indicating the PWM channel is now names "channel" instead
of "pwm", adjust all drivers.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Add support for inverting of PWM channel outputs in the pwm_nrfx driver
by properly handling the `PWM_POLARITY_INVERTED` flag.
The dts properties that were used so far for inverting of the outputs
("nordic,invert" and "chX-inverted") are kept as they are needed for
setting of the initial polarity, i.e. for setting the inactive state
of the outputs before any PWM signal generation is requested for them.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Align with other PWM drivers and treat the `pwm` parameter (described
ambiguously as "PWM pin") of the `pwm_pin_set_cycles` function as a PWM
channel, not an SoC pin. This will also make the driver consistent with
the `pwm-cells` property definition in the "nordic,nrf-pwm" binding
and with related `DT_PWMS_*` macros.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
The API call checks for this condition before calling the pin_set driver
OP call, so drivers don't have to do this check now.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Extend the macro with checks for DT properties related to pin
assignments that are defined but would be ignored, depending on
whether PINCTRL is enabled or not, what presumably indicates
a resulting configuration different from what the user expects.
Add also a possibility to indicate that the pinctrl-1 property
should not be checked because the caller does not support the
sleep state.
Rename the macro so that its name better reflects its function.
Update accordingly all drivers that use it.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Add support for the new pinctrl API to the nRF PWM driver.
Update code of the driver and the related devicetree binding.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
In order to align with macros used to obtain a device reference (e.g.
DEVICE_DT_GET), align the PM macros to use "GET" instead of "REF". This
change should have low impact since no official release has gone out yet
with the "REF" macros.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The device PM subsystem _depends_ on device, not vice-versa. Devices
only hold a reference to struct pm_device now, and initialize this
reference with the value provided in Z_DEVICE_DEFINE. This requirement
can be solved with a forward struct declaration, meaning there is no
need to include device PM headers.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Device data is cleared on deinitialization. This operation removes
some important information. Let's restore the defaults each time
the device is initialized.
Signed-off-by: Pawel Dunaj <pawel.dunaj@nordicsemi.no>
Port some drivers to the recently introduced macros to showcase its
usage and be able to do some initial testing (nRF52840).
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The PM callback is no longer referenced as "pm_control" but
"pm_action_cb", so reflect this new naming on the callbacks.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
When the driver was called to set the period length for a channel
to 0, it set the COUNTERTOP register in the PWM peripheral to 0,
what resulted in an undefined behavior of the peripheral (and lack
of the STOPPED event sometimes).
The PWM API does not precise how should a zero length period be
handled; some drivers return the -EINVAL error in such case, some
do not. This patch fixes the pwm_nrfx driver so that it does not
change the previously used COUNTERTOP register value when the period
length is set to 0, and because the pulse cycles are always limited
by the driver to period cycles (so 0 in this case), in result the
relevant channel is simply deactivated. This allows users to switch
off a channel by requesting the pulse width to be set to 0 without
providing a non-zero period in such call.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Instead of passing target states, use actions for device PM control.
Actions represent better the meaning of the callback argument.
Furthermore, they are more future proof as they can be suitable for
other PM actions that have no direct mapping to a state. If we compare
with Linux, we could have a multi-stage suspend/resume. Such scenario
would not have a good mapping when using target states.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
According to the documentation the OFF state has to be used when the
devices is fully turned off, ie, power removed. Most drivers were using
a sort of fall-through for all non-active states, leading to behaviors
not following the specifications.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
- Return -ENOTSUP if the requested state is not supported
- Remove redundant "noop style" functions.
- Use switch everywhere to handle requested state (not necessary in all
drivers, but better take off with consistency in place after current
changes).
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The verb tense for the suspended state was not consistent with other
states. The likely reason: state was being used as a command/action.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The difference between low power and suspend states is a thin blur line
that is is not clear and most drivers have used indistinctly. This patch
converges to the usage of the suspend state for low power, since
contrary to the low power state, it is used by both system and runtime
device PM. The low power state is still kept, but its future is unclear
and needs some discussion.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Some devices are using PM_DEVICE_STATE_FORCE_SUSPEND as a sort of low
power state, something that is not correct. In fact, this state is not
an actual state and will be eventually moved, if found necessary, to an
action or command.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The device PM control function will only be called if the requested
state is different from the current one. A significant amount of drivers
were checking for state changes, now unnecessary. This patch removes all
this redundant logic.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Since the state is no longer modified by the device PM callback, just
use the state value.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The callback is now invoked to set the device PM state in all cases, so
the usage of ctrl_command is redundant.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The device PM subsystem already holds the device state, so there is no
need to keep duplicates inside the device. The pm_device_state_get has
been refactored to just return the device state. Note that this is still
not safe, but the same applied to the previous implementation. This
problem will be addressed later.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The callback is not used anymore, so just delete it from the pm_control
callback signature.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
the device PM callback is not used anymore by the device PM subsystem,
so remove it from all drivers/tests using it.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Move all PM_DEVICE_STATE_* definitions to an enum. The
PM_DEVICE_STATE_SET and PM_DEVICE_STATE_GET definitions have been kept
out of the enum since they do not represent any state. However, their
name has not been changed since they will be removed soon.
All drivers and tests have been adjusted accordingly.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
This commit clears current settings of the PWM perihperal
that are stored inside device structure.
This makes sure that PWM period and prescaler is configured
as expected after driver was suspended.
Signed-off-by: Radoslaw Koppel <radoslaw.koppel@nordicsemi.no>
The context parameter used across device power management is
actually the power state. Just use it and avoid a lot of
unnecessary casts.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
Andrzej Głąbek