Binding required does not need to be EC vendor-specific,
it simply requires 2 board GPIOs definition.
Signed-off-by: Jose Alberto Meza <jose.a.meza.arellano@intel.com>
Relocate common pinctrl setup to the SoC level so it can be
reused by multiple boards and kept consistent.
Signed-off-by: Muhammad Waleed Badar <walid.badar@gmail.com>
- Update low power state exit latency to match SDK
- Enable NBU wakeup source
- Configure 32MHz crystal osc
- Shutdown NBU when it's not used
Signed-off-by: Yassine El Aissaoui <yassine.elaissaoui@nxp.com>
Currently, scmi_send_message()'s logic is split across two functions,
each of which handling either polling or interrupt-based reply waiting.
Since the two functions are pretty much similar, merge them together in
a single scmi_send_message() function, which is able to handle both wait
startegies.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
So far, the SCMI core has been in charge of enabling/disabling the "poll
for message reply" logic by directly using functions from MBOX/SHMEM.
This behavior should be abstracted away by a simple transport layer
send_message() function, with the SCMI core not having to know (or care)
about which kind of transport is being used.
To fix this problem, move the polling logic to the transport layer. Now,
based on the value of the "use_polling" parameter propagated from the SCMI
core, SHMEM will set/clear the interrupt-related bit from the flags
portion of the SHMEM area.
Note that now we only alter the state of the SHMEM flags with the MBOX
interrupts being enabled at all times. This should be enough to signal
the SCMI platform that the agent is not interested in receiving interrupts
whenever polling is enabled.
This commit is part of #102904.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Add a new parameter to SHMEM's write_message() functon, which is meant to
allow it to perform the required configuration whenever the SCMI stack
(via the SCMI transport layer) wishes to poll for the reply.
For now, don't implement any logic related to this. Thus, no functional
change.
This commit is part of #102904.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Add a new parameter to the transport layer's send_message() function,
which is meant to allow it to perform the required configuration whenever
the SCMI stack user (via the SCMI core layer) wishes to poll for the
reply.
For now, don't implement any logic related to this. Thus, no functional
change.
This commit is part of #102904.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Add support sci b spi test for Renesas fpb_ra8e1:
- tests/drivers/spi/spi_loopback
- tests/drivers/spi/spi_controller_peripheral
Signed-off-by: Thinh Le Cong <thinh.le.xr@bp.renesas.com>
Add FPB-RA8E1 test support for tests/drivers/i2c/i2c_api
Signed-off-by: Thinh Le Cong <thinh.le.xr@bp.renesas.com>
Signed-off-by: Khai Cao <khai.cao.xk@renesas.com>
Add support for test app on Renesas fpb_ra8e1:
- tests/drivers/dma/chan_blen_transfer
- tests/drivers/dma/loop_transfer
Signed-off-by: Thinh Le Cong <thinh.le.xr@bp.renesas.com>
Add support for test app on Renesas fpb_ra8e1:
- tests/drivers/adc/adc_accuracy_test
- tests/drivers/adc/adc_api
Signed-off-by: Thinh Le Cong <thinh.le.xr@bp.renesas.com>
Add support for test app on Renesas fpb_ra8e1:
- tests/drivers/pwm/pwm_api
- tests/drivers/pwm/pwm_loopback
Signed-off-by: Thinh Le Cong <thinh.le.xr@bp.renesas.com>
Signed-off-by: Khai Cao <khai.cao.xk@renesas.com>
Add support for test app Renesas fpb_ra8e1:
- tests/drivers/spi/spi_loopback
- tests/drivers/spi/spi_controller_peripheral
Signed-off-by: Thinh Le Cong <thinh.le.xr@bp.renesas.com>
Add ELC sample support for Renesas fpb_ra8e1
Signed-off-by: Thinh Le Cong <thinh.le.xr@bp.renesas.com>
Signed-off-by: Khai Cao <khai.cao.xk@renesas.com>
Add board layer support for Renesas fpb_ra8e1 board
Signed-off-by: Thinh Le Cong <thinh.le.xr@bp.renesas.com>
Signed-off-by: Khai Cao <khai.cao.xk@renesas.com>
Add dts support for Renesas RA8E1 SoC series
Signed-off-by: Thinh Le Cong <thinh.le.xr@bp.renesas.com>
Signed-off-by: Khai Cao <khai.cao.xk@renesas.com>
stepper-ctrl is used as suffix for motion control drivers
stepper-driver is used as suffix for stepper drivers in mfd devices
Signed-off-by: Jilay Pandya <jilay.pandya@outlook.com>
Verify the return value of gpio_pin_configure_dt() when configuring
the codec reset GPIO.
Previously, failures during GPIO configuration were ignored, which
could leave the codec in an undefined state while the initialization
sequence continued.
Propagate the error to the caller to ensure proper failure handling.
Signed-off-by: Gaetan Perrot <gaetan.perrot@spacecubics.com>
Add initial support for Analog Devices ADE7978 isolated energy
metering IC for polyphase shunt meters.
The driver implements the Zephyr sensor API and provides:
- SPI communication (read/write 8/16/32-bit registers)
- Phase A RMS current measurement (SENSOR_CHAN_CURRENT)
- Phase A RMS voltage measurement (SENSOR_CHAN_VOLTAGE)
- Device Tree bindings
This is an initial minimal working implementation. Future enhancements
will include:
- Multi-phase support (Phase B, C, Neutral)
- Active and reactive power measurement
- Interrupt support
- Calibration API
Signed-off-by: Filip Stojanovic <filipembedded@gmail.com>
Much like the kernel or llext, rtio.h had become quite large though the
concepts and data types are not.
Restructure the headers into logically grouped components.
Signed-off-by: Tom Burdick <thomas.burdick@infineon.com>
For the F9P, we can use the UBX_KEY_UART1_PROTO_OUT_NMEA rather than
individually disabling all the messages.
For the m8, the NMEA output is already disabled when the CFG-PRT is done
from the u_blox_iface_init.
But this is not necessarily done in case the expected baudrate is already
set.
Let's keep the individual NMEA disabling for M8.
Signed-off-by: Philémon Jaermann <p.jaermann@gmail.com>
Be consistent and use that.
Only select the U_BLOX_PROTOCOL, the MODEM_UBX comes from the indirection.
Signed-off-by: Philémon Jaermann <p.jaermann@gmail.com>
The common interface can now be used by both drivers, use it.
select GNSS_U_BLOX to have access to the GNSS_U_BLOX_SATELLITES_COUNT
and the GNSS_U_BLOX_RESET_ON_INIT.
Signed-off-by: Philémon Jaermann <p.jaermann@gmail.com>
GNSS_U_BLOX should be selected by u-blox receiver to have access to the
common configuration, which for now is only the number of satellites to
store and the reset on init functionality.
Signed-off-by: Philémon Jaermann <p.jaermann@gmail.com>
No point in doing the baudrate configuration dance if the receiver is
already in the desired baudrate.
Only do the baudrate_configuration if trying to get the version failed.
Introduce a private msg_get() API which can take the timeout/retry_count
because the previously existing u_blox_iface_msg_get() hardcodes the
timeout to 3s with some retries which would be very wasteful to use if
the receiver is not in the expected baudrate as we would timeout.
Signed-off-by: Philémon Jaermann <p.jaermann@gmail.com>
Used to configure the baudrate with the more modern UBX-CFG-VALSET
if supported, and falling back on UBX-CFG-PRT otherwise.
Adding the UART1 related configuration keys.
Just using the baudrate one, relying on the other default parameters.
Signed-off-by: Philémon Jaermann <p.jaermann@gmail.com>
This gnss_u_blox_iface will be used by the gnss_u_blox_f9p.c and
gnss_u_blox_m8.c drivers.
Those two drivers currently define their own APIs which are
extremely similar.
The struct u_blox_iface_config is taken from the m8 flavor, as it allows
for baudrate configuration (while the f9 flavor requires the UART and the
receiver configuration to be the same).
The struct u_blox_iface_data is taken from the f9 flavor, which uses one
lock for logically separated resources (req_buf_lock and lock).
The init is done according to the m8 logic, which reconfigures the
baudrate of the receiver.
This is done with the UBX-CFG-PRT message, but the F9 could do that with
the more modern valset configuration mechanism.
This will be added in the following commit.
Signed-off-by: Philémon Jaermann <p.jaermann@gmail.com>
Compiler-generated FLIX instructions are currently disabled for LLEXT due
to a historic issue with LLEXT feature that appears to be already
resolved. However, another issue with FLIX is now being investigated.
The latter issue is not related to LLEXT but userspace feature.
To mitigate impact of global complier settings, this change adds a kconfig
choice for controlling FLIX generation independently for LLEXT modules.
Signed-off-by: Wojciech Jablonski <wojciech.jablonski@intel.com>
