Bluetooth IPSP L2 sets the LL address only after establishing Bluetooth
connection. As this can take place after the interface was brough UP by
the application, the network interface API should not block such
attempt. Instead, verify the NET_IF_RUNNING flag.
For the same reason, move the assert verifying that LL address is set
from net_if_up() (which only puts the interface in the admin UP state)
into the function that transitions the interface into operational UP
state.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Instead of checking that output mode is enabled when single ended
configuration is requested, instead check that input mode is not
requested without output mode. This enables a pin to be configured as
`GPIO_DISCONNECTED | GPIO_SINGLE_ENDED` without triggering the
assertion.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
add DSP reg in context switch
add AGU reg in context switch to support XY mem
add thread option and API to dis/enable DSP switch
Signed-off-by: Siyuan Cheng <siyuanc@synopsys.com>
This is initial support. Necessary to test the UHC driver API,
for the USB support test implementations, and upcoming USBIP support.
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
To be able to call pm_device_runtime_put() from an IRQ context, move
from mutexes to semaphores and force the async path when the put
operation is called from an ISR.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
For the async operation move from condition variables to events to
reduce the dependency on the mutexes that cannot be used in IRQ
context.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
Add a new API to obtain the active error flags on a regulator, e.g.
overcurrent, overvoltage or over temperature.
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>
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 documentation, add -EINVAL return value when current limit
is out of the window.
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>
- Voltage is applied to the active or selected mode
- Implementation must return -EINVAL if given voltage window is not
valid.
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>
Adds an attribute that describes the maximum number of scatter gather
blocks that the DMA will accept. Useful in cases where DMA is used as
the abstraction for moving data around (e.g. SoF audio streams) and
variances of the hardware need to inform decisions about how to use
the DMA API.
Co-authored-by: Adrian Bonislawski <adrian.bonislawski@intel.com>
Co-authored-by: Jaska Uimonen <jaska.uimonen@intel.com>
Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
The stm32G0 device has a one APB peripheral clock bus
but splitted on two RCC registers: RCC_ABPENR1 and RCC_ABPENR2
Peripherals are on one or the other.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
According to section 5.1.2.2.2 of the I3C Specification v1.1.1. A
controller may skip the 0x7E broadcast header for private
transfers as an optimization if it is know that no I3C Target on
the bus has a spike filter.
Signed-off-by: Ryan McClelland <ryanmcclelland@meta.com>
When generating an array of devices with I3C_DEVICE_ARRAY_DT_INST
and I3C_I2C_DEVICE_ARRAY_DT_INST when the number of devices is
greater than 1, a comma was not inserted between each struct with
macro. This would give an error preventing compiling.
Signed-off-by: Ryan McClelland <ryanmcclelland@meta.com>
Some controllers will "automatically" NACK any read request to them
if there is no data in the TX FIFO. This would prevent use of the callback
function read_requested_cb which is expected to be called from an ISR.
i3c_target_tx_write was added to give applications a direct way to load
data in to the tx fifo.
Signed-off-by: Ryan McClelland <ryanmcclelland@meta.com>
Rename is_primary to is_secondary. The justification for this is
because it is less likely to have something configured to be
secondary, and the 0 value would be if it is primary.
Signed-off-by: Ryan McClelland <ryanmcclelland@meta.com>
Add a default value (0) used for the `input_positive` field of the
`adc_channel_cfg` structure when there is no `input-positive` property
specified in the DT node for a given channel.
This solves a problem that occurs when an ADC driver that requires
analog inputs to be specified (so it selects ADC_CONFIGURABLE_INPUTS)
is used together with an ADC driver that does not use the corresponding
fields of the `adc_channel_cfg` structure. With the previous form of
the macro, the DT nodes with channel configuration for the latter
driver would need to specify the `input-positive` property, though its
value would be ignored, otherwise a build error would occur.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
The XY Memory is a feature commonly found in DSP processors to increase
the DSP performance. The XY component allows a ARC processor to
implicitly load source operands and store results into a closely coupled
memory using a single instruction.
Add XY memory for ARC EM9D/EM11D processors including em_starterkit,
em_starterkit_em11d. emsdp_em9d, nsim_em, iotdk.
Signed-off-by: Siyuan Cheng <siyuanc@synopsys.com>
In Infineon XMC4XXX SoCs, gpio interrupts are triggered via an
Event Request Unit (ERU) module. A subset of the gpios are
connected to the ERU. The ERU monitors edge triggers and creates
a SR.
This driver configures the ERU for a target port/pin combination
for rising/falling edge events. Note that the ERU module does
not generate SR based on the gpio level. Internally the ERU
tracks the *status* of an event. The status is set on a positive
edge and unset on a negative edge (or vice-versa depending on
the configuration). The value of the status is used to implement
a level triggered interrupt; The ISR checks the status flag and
calls the callback function if the status is set.
The ERU configurations for supported port/pin combinations are
stored in a devicetree file dts/arm/infineon/xmc4xxx_x_x-intc.dtsi.
The configurations are stored in the opaque array
uint16 port_line_mapping[].
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
Cited commit requires the limits.h header to fetch the defintion of
INT_MAX, which is missing today. The build process fails without it.
Fixes: cb5c5519e4 ("arch/arm64: Support runtime frequency")
Signed-off-by: Rodrigo Cataldo <rodrigo.cataldo@huawei.com>
Co-authored-by: Henri Xavier <datacomos@huawei.com>
Reset controller node is necessary to enable support for resetting
peripherials using RCC.
This patch also includes RCC reset registers offsets used by STM32_RESET
macro.
Signed-off-by: Patryk Duda <pdk@semihalf.com>
Reset controller node is necessary to enable support for resetting
peripherials using RCC.
This patch also includes RCC reset registers offsets used by STM32_RESET
macro.
Signed-off-by: Patryk Duda <pdk@semihalf.com>
Reset controller node is necessary to enable support for resetting
peripherials using RCC.
This patch also includes RCC reset registers offsets used by STM32_RESET
macro.
Signed-off-by: Patryk Duda <pdk@semihalf.com>
Reset controller node is necessary to enable support for resetting
peripherials using RCC.
This patch also includes RCC reset registers offsets used by STM32_RESET
macro.
Signed-off-by: Patryk Duda <pdk@semihalf.com>
Reset controller node is necessary to enable support for resetting
peripherials using RCC.
This patch also includes RCC reset registers offsets used by STM32_RESET
macro.
Signed-off-by: Patryk Duda <pdk@semihalf.com>
Reset controller node is necessary to enable support for resetting
peripherials using RCC.
This patch also includes RCC reset registers offsets used by STM32_RESET
macro.
Signed-off-by: Patryk Duda <pdk@semihalf.com>
Reset controller node is necessary to enable support for resetting
peripherials using RCC.
This patch also includes RCC reset registers offsets used by STM32_RESET
macro.
Signed-off-by: Patryk Duda <pdk@semihalf.com>
Reset controller node is necessary to enable support for resetting
peripherials using RCC.
This patch also includes RCC reset registers offsets used by STM32_RESET
macro.
Signed-off-by: Patryk Duda <pdk@semihalf.com>
