As part of the work to support multiple IPC instances / backends using
IPC service, the static vrings mi code must be reworked to resemble a
classic device driver.
Fix also the sample using it.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
The IPC service code is currently assuming that only one IPC instance
does exist and the user can use the IPC service API to interface with
that singleton instance.
This is a huge limitation and this patch is trying to fix this
assumption introducing three major changes to the IPC service API:
- All the IPC instances are now supposed to be instantiated as a struct
device. A new test is introduced to be used as skeleton for all the
other backends.
- ipc_service_register_backend() is now removed (because multiple
backends are now supported at the same time).
- All the other ipc_service_*() functions are now taking a struct device
pointer as parameter to specify on which instance the user is going to
act and operate.
In this patch the documentation is also extended to better clarify the
terminology used.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
Rename the macro used to initialize the runtime fields to
Z_PM_DEVICE_RUNTIME_INIT (emphasize it is internal and follows parent
macro naming).
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Some macros were helpers for the state initializers (e.g. to assist
UTIL_LISTIFY). In order to make the API more clear, they have been
prefixed with Z_ to emphasize they are internal and they have also been
removed from documentation.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Z_PM_DEVICE_INIT is used as a static initializer, so all non-specified
fields will already be set to zero.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Add a dummy implementation for the wakeup API, so that it can still be
used when no PM_DEVICE is enabled.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The PM flags are only used internally, so there is no need to include
them in the documentation.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Document the deprecated functions and macros, tag them with @deprecated
command to inform about the replacement.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
- Add a new `subsys_pm` group, part of `subsys`
- Improve group naming
- Include conditional code using __DOXYGEN__, it allows to have better
control of inclusion.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Add an external group definition file. It can be used to create high
level group for things like subsystems, as there is no header such as
"subsys.h" where these type of logical groups can be defined.
This approach is followed by projects such as pipewire to organize
Doxygen modules.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
This commit enables the HSI48 clock for the stm32U5 soc family
to use the USB device peripheral.
Enable the VDD USB voltage supply.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
This commit enables the USB OTG full-speed instance (OTG)
on the target board b_u585i_iot02a from STMicroelectronics.
OTG is available on USB type-C connector (CN1).
Signed-off-by: Francois Ramu <francois.ramu@st.com>
Add the USB On-The-Go Supplement, Revision 2.0 in the DTS
of the stm32u575 and stm32u585 devices
(not for the stm32U5 serie).
Signed-off-by: Francois Ramu <francois.ramu@st.com>
Since cs gpios are initialized during driver initialization
remove spi_context_cs_configure that is not longer need.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
In case when we have multiple devices connected to the
one SPI interface the initial state of CS gpios after
MCU reset is floating and it might be low that prevents us from
communicating between particular devices. Fix that by
initializing all provided cs gpios and setting them as inactive.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
In case when we have multiple devices connected to the
one SPI interface the initial state of CS gpios after
MCU reset is floating and it might be low that prevents us from
communicating between particular devices. Fix that by
initializing all provided cs gpios and setting them as inactive.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
In case when we have multiple devices connected to the
one SPI interface the initial state of CS gpios after
MCU reset is floating and it might be low that prevents us from
communicating between particular devices. Fix that by
initializing all provided cs gpios and setting them as inactive.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
In case when we have multiple devices connected to the
one SPI interface the initial state of CS gpios after
MCU reset is floating and it might be low that prevents us from
communicating between particular devices. Fix that by
initializing all provided cs gpios and setting them as inactive.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
In case when we have multiple devices connected to the
one SPI interface the initial state of CS gpios after
MCU reset is floating and it might be low that prevents us from
communicating between particular devices. Fix that by
initializing all provided cs gpios and setting them as inactive.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
In case when we have multiple devices connected to the
one SPI interface the initial state of CS gpios after
MCU reset is floating and it might be low that prevents us from
communicating between particular devices. Fix that by
initializing all provided cs gpios and setting them as inactive.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
In case when we have multiple devices connected to the
one SPI interface the initial state of CS gpios after
MCU reset is floating and it might be low that prevents us from
communicating between particular devices. Fix that by
initializing all provided cs gpios and setting them as inactive.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
In case when we have multiple devices connected to the
one SPI interface the initial state of CS gpios after
MCU reset is floating and it might be low that prevents us from
communicating between particular devices. Fix that by
initializing all provided cs gpios and setting them as inactive.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
In case when we have multiple devices connected to the
one SPI interface the initial state of CS gpios after
MCU reset is floating and it might be low that prevents us from
communicating between particular devices. Fix that by
initializing all provided cs gpios and setting them as inactive.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
In case when we have multiple devices connected to the
one SPI interface the initial state of CS gpios after
MCU reset is floating and it might be low that prevents us from
communicating between particular devices. Fix that by
initializing all provided cs gpios and setting them as inactive.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
In case when we have multiple devices connected to the
one SPI interface the initial state of CS gpios after
MCU reset is floating and it might be low that prevents us from
communicating between particular devices. Fix that by
initializing all provided cs gpios and setting them as inactive.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
In case when we have multiple devices connected to the
one SPI interface the initial state of CS gpios after
MCU reset is floating and it might be low that prevents us from
communicating between particular devices. Fix that by
initializing all provided cs gpios and setting them as inactive.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
In case when we have multiple devices connected to the
one SPI interface the initial state of CS gpios after
MCU reset is floating and it might be low that prevents us from
communicating between particular devices. Fix that by
initializing all provided cs gpios and setting them as inactive.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
In case when we have multiple devices connected to the
one SPI interface the initial state of CS gpios after
MCU reset is floating and it might be low that prevents us from
communicating between particular devices. Fix that by
initializing all provided cs gpios and setting them as inactive.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
In case when we have multiple devices connected to the
one SPI interface the initial state of CS gpios after
MCU reset is floating and it might be low that prevents us from
communicating between particular devices. Fix that by
initializing all provided cs gpios and setting them as inactive.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
In case when we have multiple devices connected to the
one SPI interface the initial state of CS gpios after
MCU reset is floating and it might be low that prevents us from
communicating between particular devices. Fix that by
initializing all provided cs gpios and setting them as inactive.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
In case when we have multiple devices connected to the
one SPI interface the initial state of CS gpios after
MCU reset is floating and it might be low that prevents us from
communicating between particular devices. Fix that by
initializing all provided cs gpios and setting them as inactive.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
In case when we have multiple devices connected to the
one SPI interface the initial state of CS gpios after
MCU reset is floating and it might be low that prevents us from
communicating between particular devices. Fix that by
initializing all provided cs gpios and setting them as inactive.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
In case when we have multiple devices connected to the
one SPI interface the initial state of CS gpios after
MCU reset is floating and it might be low that prevents us from
communicating between particular devices. Fix that by
initializing all provided cs gpios and setting them as inactive.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
Add extra cs_gpios and num_cs_gpios members into
spi_context structure that will be used to
initialize all defined cs gpios during the driver
initialization using SPI_CONTEXT_CS_GPIOS_INITIALIZE macro.
While at it add a new spi_context_cs_configure_all
function that allows the user to configure
all available cs gpios in inactive mode.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
A couple of SPI drivers use CONFIG_KERNEL_INIT_PRIORITY_DEVICE
as init priority for driver initialization. Let's change
it to the dedicated CONFIG_SPI_INIT_PRIORITY to make it
compatible with other ones.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
Any exposed PTM root device will by default see their root capability
enabled so they will become PTM responder.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
This is a really simple one: one function is exposed to enable PTM
requester on a endpoint. PTM root capability will be enabled
automatically via a dedicated driver and its related DTS exposure.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Such module is missing and will prove to be useful for future features
and/or printing out debug messages on existing ones.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
