When attaching a device, it should look up if the dynamic addr is
already attached only, and not by the static addr.
Signed-off-by: Ryan McClelland <ryanmcclelland@meta.com>
For ENTDAA, BCR and DCR is always transmitted back up to the controller.
When `i3c_bus_init` is done, it does the ENTDAA then it would get the
basic info would get the BCR and DCR again. This was rather reduntant.
This now splits it up so there is a function called
`i3c_device_adv_info_get` which gets the mrl, mwl, getcaps, and the
mxds. `i3c_device_basic_info_get` now only just gets the bcr and dcr.
There is also an inline function called `i3c_device_info_get` which
will get everything.
Signed-off-by: Ryan McClelland <ryanmcclelland@meta.com>
The winstream code itself is reasonably generic, but the console
integration was written to the intel_adsp memory window driver only,
as that was the only consumer.
Add an alternative that allows the winstream to be pointed to by a
linker symbol instead. The platform layer is responsible for putting
it where it needs to go.
Also includes a 20-byte "descriptor" recodr (with a very large magic
number) in the binary that points to the winstream, for the benefit of
external tooling that needs to find it at runtime.
Signed-off-by: Andy Ross <andyross@google.com>
The CMD_BLANK_CHECK can return errors when the flash is readable, and
should only be used after programming, not in is_area_readable(). From
the LPC55S69 datasheet: "As cells age and lose charge, a correctly
programmed address will fail this check, while still being able to be
read successfully for the remaining duration of the data retention time."
Signed-off-by: Derek Snell <derek.snell@nxp.com>
Add support for STM32H757 SoC, which shares its design
with STM32H747 with added cryptography peripherals.
Signed-off-by: Grzegorz Runc <g.runc@grinn-global.com>
Add a non-configurable option which drivers can select to indicate that
they do not support callbacks on watchdog expiry.
Signed-off-by: Jordan Yates <jordan@embeint.com>
The Atmel counter driver requires a valid pinctrl list to initialize.
This relax this condition since the timer can be used as general purpose
timer, which may not require a pin associated with the timer unit.
Fixes#83509
Signed-off-by: Gerson Fernando Budke <gerson.budke@ossystems.com.br>
Add the Sensor Fusion Low Power (SFLP) FIFO streaming capability,
using RTIO. The decode function is now aware of parsing following FIFO
tags:
- LSM6DSV16X_SFLP_GAME_ROTATION_VECTOR_TAG
- LSM6DSV16X_SFLP_GYROSCOPE_BIAS_TAG
- LSM6DSV16X_SFLP_GRAVITY_VECTOR_TAG
To activate SFLP the user should put in DT the proper configuration.
For example, to activate a 60Hz SFLP FIFO batching rate of game rotation
vector, gravity vector and gbias components, the user should add in DT
the following:
sflp-odr = <LSM6DSV16X_DT_SFLP_ODR_AT_60Hz>;
sflp-fifo-enable = <LSM6DSV16X_DT_SFLP_FIFO_GAME_ROTATION_GRAVITY_GBIAS>;
Signed-off-by: Armando Visconti <armando.visconti@st.com>
In case I3C IBI interrupt is not used do not skip reading the status
register, otherwise the interrupt event will not get cleared.
Signed-off-by: Armando Visconti <armando.visconti@st.com>
Align all sensor drivers that are using stmemsc (STdC) HAL i/f
to new APIs of stmemsc v2.8
Requires https://github.com/zephyrproject-rtos/hal_st/pull/24
Signed-off-by: Armando Visconti <armando.visconti@st.com>
Low power mode for non-asynchronous API case is only available when
RX is not used (RX pin is not defined). In that case TX starting
function was using uarte_enable_locked() which tracks if UARTE is
used by TX or RX and TXSTOPPED interrupt was disabling UARTE
unconditionally. Because of that following attempt to TX start
was assuming that UARTE is already enabled when it was disabled.
Fixing it by using uarte_disable_locked function in TXSTOPPED
handling.
Code reordering was required to make uarte_disable_locked()
available earlier.
Signed-off-by: Krzysztof Chruściński <krzysztof.chruscinski@nordicsemi.no>
The get_frame_count() API must return the number of frames in FIFO
for a given channel type, and not the total number of generic FIFO
frames. This API may be also re-used in the decoder routine when
the timestamp baseline is adjusted.
Signed-off-by: Armando Visconti <armando.visconti@st.com>
Address issue where the timing source is not stopped upon step completion
and not adjusting the actual position after performing a step.
Signed-off-by: Fabian Blatz <fabianblatz@gmail.com>
Adds a fallback for the dual-edge-step property in the step dir common
code. Without this drivers using the common code would have to declare the
dual-edge-step property so it can default to false when not set, even if
the IC does not support adjusting it.
Signed-off-by: Fabian Blatz <fabianblatz@gmail.com>
The status variable stores the return value of `net_recv_data`, which
is an `int` and may be negative.
Signed-off-by: Martin Jäger <martin@libre.solar>
Adds a timing source api which is used by the step-dir stepper common code.
This allows the reusable common code to configure different timing sources,
since the initial delayable work implementation was inacurate for higher
maximum velocities.
Signed-off-by: Fabian Blatz <fabianblatz@gmail.com>
Use the shell_device_filter utils method and leverage the new api classing
to only suggest stepper devices via tab-complete within the shell.
Signed-off-by: Fabian Blatz <fabianblatz@gmail.com>
The LIS2DUXS12 is a smart, digital, 3-axis linear accelerometer whose
MEMS and ASIC have been expressly designed to combine the lowest current
consumption possible with features such as always-on antialiasing
filtering, a finite state machine (FSM) and machine learning core (MLC)
with adaptive self-configuration (ASC), and an analog hub / Qvar sensing
channel.
(https://www.st.com/en/mems-and-sensors/lis2duxs12.html)
Signed-off-by: Armando Visconti <armando.visconti@st.com>
Prepare the driver to be able to handle other DUX software compatible
devices. Currently the driver handles the st_lis2dux12 compatible only.
Do following major changes:
1. Introduce the lis2dux12_chip_api structure filled with device specific
APIs. At the moment define following callback:
- api_lis2dux12_set_odr_raw()
- api_lis2dux12_set_range()
- api_lis2dux12_sample_fetch_accel()
- api_lis2dux12_sample_fetch_temp()
- api_lis2dux12_handle_interrupt()
- api_lis2dux12_init_interrupt()
2. Prepare specific APIs for st_lis2dux12 device.
3. Make DT instantiation on inst + name basis, and not only by inst. This
commit only use "name = DT_DRV_COMPAT = st_lis2dux12".
Signed-off-by: Armando Visconti <armando.visconti@st.com>
Regardless of the argument specified, it always references the
property of the 0th, so it was corrected to reference the instance
specified by the argument.
Signed-off-by: TOKITA Hiroshi <tokita.hiroshi@gmail.com>
For a 16-bit data bus, "DT_INST_PROP_LEN(n, data_gpios)" returns 16
which is equals "MIPI_DBI_MAX_DATA_BUS_WIDTH(16)".
As a result, the assertion will always be triggered.
Use a "<=" condition for the assertion instead.
Signed-off-by: Hua Zheng <writeforever@foxmail.com>
Command "waitms 50" on ChromeBook EC console, then it will crash EC.
Because arch_busy_wait() is re-entried by two different tasks,
the second calling will reset the timer and may cause the first
calling to fail to reach the waiting destination
(if the first calling's wait time is longer enough).
Verified by follow test pattern:
west build -p auto -b it8xxx2_evb tests/kernel/timer/timer_api
west build -p auto -b it8xxx2_evb tests/kernel/timer/timer_error_case
west build -p auto -b it8xxx2_evb tests/kernel/timer/timer_monotonic
west build -p auto -b it8xxx2_evb tests/kernel/timer/starve
west build -p auto -b it8xxx2_evb tests/kernel/context
Signed-off-by: Ruibin Chang <Ruibin.Chang@ite.com.tw>
Add empty function stubs to support building with the newly introduced
CONFIG_BUILD_ONLY_NO_BLOBS option.
Signed-off-by: Johan Hedberg <johan.hedberg@silabs.com>
The address passed in to the function was incorrect causing
failures when porting to RT1180.
Signed-off-by: Mahesh Mahadevan <mahesh.mahadevan@nxp.com>
For the lists of properties passed as a pointer to the get_props and
set_props functions, there is no reason to not make the pointer const as
the called functions will not and should not alter the pointed-to data.
In practice, not having the pointers const can cause compilation errors
if trying to pass in a const array of properties.
Signed-off-by: Mikkel Jakobsen <mikkel.aunsbjerg@escolifesciences.com>
Use uint64_t instead of uint32_t for the FLASH_STM32_EX_OP_SECTOR_WP
extended operation.
Some chips have two banks, more than 16 sectors each e.g. stm32h7a3xx
chips, so more than 32 bits are required.
Signed-off-by: Dawid Niedzwiecki <dawidn@google.com>
Fixed bug calculating offset of registers after unused space in the ADC
register space for the SZ package parts.
Signed-off-by: Jeff Daly <jeffd@silicom-usa.com>
Avoid referring to Pico 2 (the name of a board). In this context,
RPI_PICO is used to refer to the (Zephyr) `SOC_FAMILY` rather than the
Pico 1 board. This clarifies common numerical values between the RP2040
and RP2350 SoC series, and enables existing DTS files to be used with
RP2350-based boards with fewer changes.
Remove the use of Zehpyr's `CONFIG_` macros from the device tree files,
and replace them with `SOC_SERIES`-specific files. Update the driver
implementation to conditionally include the correct file. Update
documentation and samples to match.
Signed-off-by: Andrew Featherstone <andrew.featherstone@gmail.com>
The RP2350 SoC series contain two timer peripherals. Extend the driver
to support using the second timer (`TIMER1`).
N.b. this requires a fix from the Pico SDK to be patched into
hal_rpi_pico. See https://github.com/raspberrypi/pico-sdk/pull/1949 .
Signed-off-by: Andrew Featherstone <andrew.featherstone@gmail.com>
The watchdog register configuration of RP2350 differs from that
of RP2040, so we make fit that.
Signed-off-by: TOKITA Hiroshi <tokita.hiroshi@gmail.com>
Signed-off-by: Andrew Featherstone <andrew.featherstone@gmail.com>
Unlike the RP2040, the RP2350 has multiple tick generators that need to
be started. Start TIMER0 and TIMER1 tick generators during
clock_control_init.
Signed-off-by: Andrew Featherstone <andrew.featherstone@gmail.com>
Extend the existing driver to add some initial support for the new SoC,
whilst maintaining compatibility with the RP2040.
Signed-off-by: Andrew Featherstone <andrew.featherstone@gmail.com>
RP2350 is Raspberry Pi's newest SoC. From the datasheet:
"RP2350 is a new family of microcontrollers from Raspberry Pi that
offers significant enhancements over RP2040. Key features include:
• Dual Cortex-M33 or Hazard3 processors at 150 MHz
• 520 kB on-chip SRAM, in 10 independent banks
• 8 kB of one-time-programmable storage (OTP)
• Up to 16 MB of external QSPI flash/PSRAM via dedicated QSPI bus
...
"
This commit introduces some changes to support the existing RP2040 and
what is describe by Raspberry Pi as the "RP2350 family". Currently there
are 4 published products in the family: RP2350A, RP2350B, RP2354A, and
RP2354A. Within Zephyr's taxonomy, split the configuration as follows:
Family: Raspberry Pi Pico. This contains all RP2XXX SoCs,
SoC Series: RP2040 and RP2350.
SoC: RP2040 and, for now, just the RP2350A, which is present on the Pico
2, where the A suffix indicates QFN-60 package type. This structure is
reflected in `soc/raspberrypi/soc.yml`, and somewhat assumes that there
won't be a RP2050, for example, as a RP2040 with more RAM.
This is foundation work ahead of introducing support for Raspberry Pi's
Pico 2 board, which is fitted with a RP2350A and 4MB of flash.
Signed-off-by: Andrew Featherstone <andrew.featherstone@gmail.com>
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
Add support for SoC-specific clock ids and update the initialization
function to support the existing RP2040 and add support for the RP2350.
clock_control_rpi_pico.c uses numerical values for clock ids taken from
rpi_pico_clock.h which are the "clock generator". For the RP2350 these
values are different for some of the same logical clock sources, as well
as the RP2040 and RP2350 having different clock sources available.
Signed-off-by: Andrew Featherstone <andrew.featherstone@gmail.com>
XIP prefetching seems to still be running, even while interrupts are
disabled. Therefore it is important to wait for the FlexSPI to be idle
before performing a write/erase operation.
Signed-off-by: Martin Stumpf <martin.stumpf@vected.de>