k_sleep() and k_usleep() resolve to an out of line implementation living in
another translation unit, a system call under CONFIG_USERSPACE and a plain
call otherwise. Either way the compiler sees neither whether the requested
duration is a constant nor whether the caller cares about the returned
value, so it always emits the tick to millisecond and microsecond
conversions. Those conversions are the only thing that drags the 64 bit
division helper into many small builds: CONFIG_SYS_CLOCK_TICKS_PER_SEC
defaults to 10000 on tickless platforms, which lands in the integer
division path and divides a 64 bit value by ten, something GCC will not
strength reduce on a 32 bit target.
Promote the former z_tick_sleep() helper to a k_sleep_ticks() system call
that reports the remaining time in ticks, and rebuild k_sleep() and
k_usleep() as inlines on top of it. The conversions now live at the call
site where the compiler can fold or discard them. Nearly every caller
discards them: of the 4036 sleep call sites in the tree, exactly six use
the returned value, and only three of those are outside of tests.
What this removes is best seen in the two out of line entry points that
disappear, which on a nucleo_f030r8 (Cortex-M0, 10000 ticks/s) were the
only two callers of the 64 bit division helper in the whole image:
08002594 <z_impl_k_sleep>:
bl 8001... <z_tick_sleep>
...
movs r0, #9 /* the ceil() bias, 10 - 1 */
adds r0, r0, r2
adcs r1, r3
movs r2, #10 /* ticks / 10 -> milliseconds */
bl 8000180 <__aeabi_uldivmod>
080025c0 <z_impl_k_usleep>:
movs r0, #99 /* the ceil() bias, 100 - 1 */
...
movs r2, #100 /* microseconds / 100 -> ticks */
bl 8000180 <__aeabi_uldivmod>
bl 8001... <z_tick_sleep>
Both are gone, and so are __aeabi_uldivmod and __udivmoddi4, which are no
longer referenced anywhere. A k_usleep(250) call site now passes the
literal 3 ticks the compiler worked out on its own, where it used to pass
250 microseconds to a helper that divided by 100 at runtime. For a loop
calling k_msleep(100), k_sleep(K_SECONDS(1)) and k_usleep(250) without
using the results, FLASH drops from 11028 to 10600 bytes.
Tracing stays in the out of line implementation. It cannot move into the
inlines because every tracing backend header includes kernel.h, so a
translation unit that reaches a backend header first would expand
SYS_PORT_TRACING_* before those macros exist. A consequence is that the
sleep_exit hook now reports ticks rather than milliseconds and the usleep
hook is no longer emitted; both are covered in a following commit.
The microsecond duration is clamped to zero the way Z_TIMEOUT_US() already
does. k_usleep() never did that, but it used to truncate the 64 bit
conversion into an int32_t before handing it over, which hid the worst of
it.
Passing the conversion through whole would turn a negative duration into a
sleep of roughly 1.8e17 ticks rather than a bogus absolute deadline.
This also removes a potential link error. k_usleep() had no
implementation at all with CONFIG_MULTITHREADING=n, since nothread.c only
ever provided z_impl_k_sleep(), so any caller failed to link. Nothing in
the tree happens to call it in that configuration, which is presumably why
it went unnoticed; a single z_impl_k_sleep_ticks() now serves both.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Drop the hand-rolled tick accounting for the generic core. The driver is
left with the cycle-domain primitives: read the counter, write the
comparator, acknowledge the interrupt.
The comparator matches only on equality, so this is the COMPARE_EXACT
backend. The write-then-verify loop that kept an already-past target
from being lost for a whole counter period moves to the core, which now
does it for every exact-match driver, so
hpet_timer_comparator_set_safe() goes away and timer_driver_set_compare()
is a plain register write. The QEMU SMP workaround for a counter that
reads backwards becomes TIMER_CORE_COUNTER_NONMONOTONIC.
sys_clock_no_timeout() parks the comparator out of reach in a single
register write. The counter keeps running, as that hook requires.
Stopping it belongs in sys_clock_idle_enter(), and only when this CPU is
the only one, because the HPET counter is shared.
qemu_x86 joins the sloppy-idle test variant.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
The NXP LPC546xx family has two M_CAN instances. Its HAL therefore names
the clock gates kCLOCK_Mcan0 / kCLOCK_Mcan1 and takes an instance index
in CLOCK_GetMCanClkFreq(), whereas the single-M_CAN parts the driver
currently assumes use kCLOCK_Mcan and CLOCK_GetMCanClkFreq(void).
On parts that report more than one M_CAN instance
(FSL_FEATURE_SOC_LPC_CAN_COUNT > 1), enable and resolve the rate of each
instance independently: MCUX_MCAN_CLK selects M_CAN0 and the new
MCUX_MCAN1_CLK selects M_CAN1. Single-M_CAN parts keep using kCLOCK_Mcan
and the argument-less CLOCK_GetMCanClkFreq() via MCUX_MCAN_CLK, so their
behavior is unchanged.
Signed-off-by: Marvin Gnad <marvin.gnad@gmail.com>
backlight_set() rejects a colour index >= ARRAY_SIZE(colour_define),
so the largest valid index is ARRAY_SIZE - 1, but capabilities
reported backlight.maximum = ARRAY_SIZE(colour_define). A client that
selected the advertised maximum got -EINVAL. Report ARRAY_SIZE - 1.
Assisted-by: Claude:fable-5
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
(cherry picked from commit 4ba7dab2aefaa16170c03318d2fef77856d67ec2)
The QTMR counter driver only programmed the COMP1 compare register and
relied on the hardware compare match. An alarm set too late therefore
did not fire until the 16-bit counter wrapped all the way around (up to
65536 ticks later), violating the counter API contract for short
relative alarms and for absolute alarms using
COUNTER_ALARM_CFG_EXPIRE_WHEN_LATE.
Add guard-period support (get/set_guard_period) and late detection:
after programming COMP1 the driver re-reads the counter and, if it has
already advanced past the target within the guard window, treats the
alarm as late. Late relative alarms and late absolute alarms with
EXPIRE_WHEN_LATE now expire immediately, and late absolute alarms
return -ETIME.
The QTMR ISR is driven purely by hardware status flags and the module
IRQ is shared across all four channels, so immediate expiry is
delivered by marking the channel software-pending, forcing the IRQ
with NVIC_SetPendingIRQ, and synthesizing the compare event in the
ISR. The IRQ number is taken from the parent qtmr node.
Verified on mimxrt1180_evk/mimxrt1189/cm33 with counter_basic_api:
test_short_relative_alarm, test_late_alarm and test_late_alarm_error
now pass on the QTMR instance.
Signed-off-by: Felix Wang <fei.wang_3@nxp.com>
The TSTMR is a read-only timestamp counter, but its clock source is
SoC-specific: on some SoCs (e.g. i.MX RT118x) it is a read-only view of
the System Counter (SYS_CTR) and depends on it being enabled, while on
others (e.g. MCXW or i.MX8ULP) it is a standalone counter that free-runs
from reset and has no SYS_CTR dependency at all.
On i.MX RT118x, where the TSTMR is backed by the SYS_CTR, the driver
reported a hard-coded 1 MHz rate and never enabled the SYS_CTR, so
counter_get_value() returned a frozen or wrongly-scaled count and
tests/drivers/counter/counter_basic_api (test_valid_function_without_
alarm) failed. On RT118x the SYS_CTR (and thus the TSTMR) runs at a
fixed 24 MHz.
Gate the SYS_CTR handling behind a new hidden Kconfig,
COUNTER_MCUX_TSTMR_SYSCTR_BACKEND, selected automatically when the TSTMR
driver is built on a SoC that also has an nxp,sysctr node enabled. On
those SoCs the TSTMR shares the SYS_CTR hardware, so the driver drives
the SYS_CTR_CONTROL registers directly:
- start() sets the count-enable bit (CNTCR.EN) when the counter is off;
- get_freq() returns 0 while the SYS_CTR is disabled so callers can tell
the counter is not yet running;
- the register accesses are compiled out entirely on standalone TSTMR
SoCs (e.g. MCXW or i.MX8ULP), which free-run from reset and do not
depend on SYS_CTR.
In the CCM rev2 clock driver, the IMX_CCM_SYSCTR_BASE_CLK case now also
covers the TSTMR backend and reports the fixed 24 MHz rate, while
IMX_CCM_SYSCTR_SLOW_CLK returns -ENOTSUP for the TSTMR backend: the
SYS_CTR slow-clock path is unreliable for timestamp reads on
RT1180/RT1189, so surfacing the error at init time is safer than
silently producing inaccurate timestamps.
The counter_basic_api test now treats a reported frequency of 0 as
"cannot set a millisecond period", so a not-yet-running counter is
skipped rather than mis-evaluated.
Signed-off-by: Felix Wang <fei.wang_3@nxp.com>
mcux_lpc_ctimer_cancel_alarm() only disabled the channel's match
interrupt; it left the match value programmed and the callback pointer
cleared without dropping the latched status flag. If the free-running
counter reached that stale match value while the interrupt was disabled,
the channel's status flag was still latched on this SoC. A subsequent
mcux_lpc_ctimer_set_alarm() re-registers the callback, so the latched
flag could be delivered to the new callback as a spurious expiry.
Clear the channel status flag in cancel_alarm() so a cancelled match can
no longer be latched into a later alarm. In set_alarm(), mask only this
channel's interrupt and clear its flag before registering the callback,
then let CTIMER_SetupMatch() re-enable the interrupt on the freshly armed
match. Masking a single channel this way is cheaper than taking irq_lock()
across the whole sequence, and a one-tick relative alarm is unaffected
because the callback is registered before the interrupt is re-enabled.
Found with tests/drivers/counter/counter_basic_api on frdm_mcxa366,
where test_cancelled_alarm_does_not_expire intermittently observed one
spurious callback on ctimer@40004000 ("Expected 0 callbacks, got 1").
With this change the test passes.
Signed-off-by: Felix Wang <fei.wang_3@nxp.com>
A dma_block_config whose block_size is zero is accepted and turned into
a descriptor that is handed to the hardware with a length of zero and
the owner bit set to DMA.
Because block_size is already zero when the loop reaches the test for
"did this block finish", the iteration behaves as though the block were
complete, so a chain containing a zero-length block silently gains a
zero-length link, and a single zero-length block produces a chain that
transfers nothing while dma_config() returns success.
dma_esp32_reload() has the same shape and sets the same owner bit, so a
reload of size zero reaches the hardware the same way.
Reject both rather than skipping them. Skipping would change the
observable structure of the block chain the caller described, and a
caller that passes zero has almost certainly made an arithmetic mistake
it would rather hear about.
Fixes#115720
Signed-off-by: Hsiu-Chi Tsai <hctsai@linux.com>
The thermometer sample uses sensor hardware that depends on a GPIO
device, but GPIO is not enabled in the board-specific sample
configuration for nucleo_h7a3zi_q.
Automatically enable CONFIG_GPIO when ti,tmp1075 is enabled with
alert-gpios property set,to ensure the required GPIO device is
instantiated and allow the sample to build successfully.
Signed-off-by: Fabrice DJIATSA <fabrice.djiatsa-ext@st.com>
Do not defer STOPRX when CBWT is active because CBWT does not process
ENDRX interrupts. Trigger STOPRX immediately to complete RX teardown
and prevent subsequent uart_rx_enable() calls from returning -EBUSY.
Fixes#115897 and #115899
Signed-off-by: Jakub Zymelka <jakub.zymelka@nordicsemi.no>
flash_mspi_nor unconditionally required erase offset and size to be
aligned to SPI_NOR_SECTOR_SIZE (4 KiB), even though some MSPI NOR and
EEPROM devices support finer-grained erase.
Add an optional erase-block-size DT property to the jedec,nor-mspi
binding, defaulting to SPI_NOR_SECTOR_SIZE to preserve existing
behavior for devices that do not set it, and use it in api_erase()
for the address and size alignment checks.
Signed-off-by: Mohammad Odeh <zephyr@exalt.ps>
Configure the instruction, address, and data line widths for the 1-1-2,
1-2-2, 1-1-4, and 1-4-4 MSPI transfer modes on the STM32 OSPI and
XSPI controllers.
Signed-off-by: Mohammad Odeh <zephyr@exalt.ps>
Run-time FW version check can be performed in the
stm32wb HCI driver, when initializing the Bluetooth IPM.
The wireless firmware information can be retrieved
(using the SHCI_GetWirelessFwInfo()) and verified
if it match or not.
Added FUS version.
Signed-off-by: Eric Mechin <eric.mechin@st.com>
Code guarded by BMM150_SET_ATTR_REP used the nonexistent
dev->driver->data and the undefined bmm150_magn_data type. Use
dev->data and struct bmm150_data.
Drop unused config variable as well.
Assisted-by: Claude:fable-5
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
In Multi-LED mode, nothing prevents adding zeros between numbers in
the slot sequence. This is not recommended by the datasheet and can
actually render the translation map unusable because a shift appears
when reading the sensor FIFO data register. To prevent this, additional
build asserts have been added to check the slot sequence at compile time.
The default led-slot from bindings has been corrected: each type of
sensor will make all accessible LEDs available to the user by default.
Signed-off-by: Alban Chauvel <a.chauvel@catie.fr>
MISRA C:2012 Rule 8.2 requires every parameter in a function type to be
named, including the parameters of function pointer parameters.
The Wi-Fi NAN shell dispatcher, the esp_hosted and Bouffalo Lab drivers
and the hostap and nrf_wifi glue declared callbacks with bare types.
Name them after the arguments the documentation or the
definitions already use. No functional change.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Fix the misspelled DT_INST_NODE_HAS_PROP() macro that prevents
the related assertion to be considered in regulator_stm32_vrefbuf.c
driver.
Signed-off-by: Etienne Carriere <etienne.carriere@st.com>
Add validation for unsupported oversampling, invalid ADC resolution,
and unconfigured channels.
This fixes the ADC error handling and allows the driver to pass the
adc_api and adc_error_case tests.
Signed-off-by: Tim Lin <tim2.lin@ite.corp-partner.google.com>
mipi_dbi_bitbang_data carries a k_mutex that the write path locks, but
nothing initialises it. The instance data is a zero-filled static
struct, so the uncontended fast path happens to work and the existing
single-threaded tests pass, while the wait queue and the kernel object
metadata are never set up.
Initialise it at the top of the init function, ahead of the GPIO
configuration that can jump to the failure path. mipi_dbi_spi.c does
the same for its own lock.
The data pointer moves out of the MIPI_DBI_8_BIT_MODE guard, because
the mutex exists in every configuration. Built for native_sim with an
eight line and a sixteen line data bus, so both sides of that guard
are covered.
Signed-off-by: Hsiu-Chi Tsai <hctsai@linux.com>
By default, the UART RX FIFO is configured to trigger an interrupt
when it is half full. This end up breaking implementations that
assumed a per-byte interrupt delivery. These changes make these
properties adjustable in the DTS for RX and TX FIFOs.
Signed-off-by: Steven Macías <esmu@bang-olufsen.dk>
Implements an emulated I2C device for register access of the LTC4286,
used to test driver conversion and register access logic.
Signed-off-by: Jan Carlo Roleda <jancarlo.roleda@analog.com>
Added Driver support for LTC4286 Hot-Swap Controller and Power Monitor.
Supports power telemetry and interrupt support to alert host device of
fault and warning events.
Signed-off-by: Jan Carlo Roleda <jancarlo.roleda@analog.com>
Select CONFIG_MBEDTLS_ENABLE_HEAP upon CRYPTO_MBEDTLS_SHIM=y
only when Mbed TLS library is embedded in Zephyr so that it uses
a dedicated heap, not the system heap.
This change also fixes a build issue occurring since commit c20d1c8646
("modules: tf-m: stop auto-enabling Mbed TLS/PSA Crypto") was merged
that lead to unexpected twister build failure with error message
like the line wrapped below when CRYPTO_MBEDTLS_SHIM is enabled while
Mbed TLS is not embedded in Zephyr (i.e. PSA_CRYPTO_PROVIDER_MBEDTLS
is disabled) as when TF-M provides the PSA Crypto services.
sample.mgmt.osdp.peripheral_device on nrf7120dk/nrf7120/cpuapp/ns
(zephyr/gnu) error (CMake build failure - warning: MBEDTLS_ENABLE_HEAP
(defined at modules/mbedtls/Kconfig.tf-psa-crypto:125,
modules/mbedtls/Kconfig.tf-psa-crypto:125) has direct
dependencies MBEDTLS || (MBEDTLS && 0) with value n, but is
currently being y-selected by the following symbols:)
Signed-off-by: Etienne Carriere <etienne.carriere@st.com>
A driver that recovers elapsed time from somewhere other than its
counter, a low-power companion that kept time while the counter was
stopped, can have a span to announce that outruns what the counter's
width expresses. Reaching that through timer_core_announce_from() means
routing it via the counter, which forces the counter itself to be wide
enough for the sleep rather than for the hardware.
Let such a driver hand the span over directly instead, in cycles, which
is the unit it already works in and the one every other driver-facing
primitive takes. The arithmetic is 64-bit whatever the counter's width,
since that span is exactly what the width cannot cover, and it is kept
separate from timer_core_announce_from() so only the recovery path pays
for it.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
The arming path computed its deadline in 64 bits whatever the counter's
width. On a 32-bit target that is synthesized from 32-bit halves: each
add needs its carry recovered with a compare, each shift is a pair plus
an or, and each constant costs twice the instructions. It showed
in the generated code, on openrisc worst of all.
The width was never needed. last_cycle is last_tick * CYC_PER_TICK
exactly, an invariant timer_core_init() establishes and the announce and
the rescale maintain, so
(last_tick + last_elapsed + ticks) * CYC
= last_cycle + (last_elapsed + ticks) * CYC
and the clamp, which subtracts last_cycle straight back off, is on that
relative span alone. The absolute deadline was carried through a
multiply and a subtract only to be cancelled. Forming the span directly
keeps the calculation inside the counter's width.
Three bounds make the narrow types safe, none of them a latency budget:
- The span is clamped in the tick domain before the multiply, so
span * CYC <= MAX_UNANNOUNCED <= COUNTER_MASK by construction. The
comparison that clamps it forms no wide sum either.
- The announce multiplies a tick count obtained by dividing an
already-masked delta, so dticks * CYC <= delta <= COUNTER_MASK. The
round trip cannot grow.
- Init divides a counter read, itself inside the width, and
multiplies it back.
last_cycle and last_tick stay 64 bits. They carry the count past the
counter's wrap, which is what sys_clock_cycle_get_64() reports.
The reload arm gains two simplifications from the same clamp. Capping
the span up front subsumes the clamp against the remaining budget, that
one being rel <= MAX - done, which is just want <= MAX. And the signed
cast goes: only the sign of want - done matters, and its magnitude when
positive, so saturating at zero stands in for every negative value and a
starved ISR still lands on the ALARM_MIN_CYCLES floor.
Counters as wide as the baseline keep the absolute form, having nothing
to narrow to and paying for the new shape without the saving.
One behavioural difference: clamping in the tick domain rounds the
ceiling down to a whole tick, so the longest arm the core programs may
be up to one tick shorter, and is tick-aligned where it was not.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
The core already holds a full-width baseline, so it can answer
sys_clock_cycle_get_32() and sys_clock_cycle_get_64() itself and the
driver no longer has to. Both are emitted unconditionally: the baseline
is 64 bits whatever the counter's width, so the 64-bit answer is always
available, and the linker drops it where nothing calls it. A driver that
has to scale the raw count itself suppresses either one with
TIMER_CORE_HAVE_CYCLE_GET_32 or _64.
Whether the platform also advertises the 64-bit counter through
CONFIG_TIMER_HAS_64BIT_CYCLE_COUNTER stays a per-driver decision. That
option says the read is cheap, or at least no dearer than a 32-bit one,
so nothing is gained by preferring the narrower getter: it holds where
the core locks for both, and not where it locks only for the 64-bit one.
The 32-bit getter stays lock-free on an atomic counter: it extends from
the baseline's low word, and pairing one baseline read with one counter
read gives the true position whatever an announce does in between. That
matters because it is on the thread-usage timestamp hot path. The lock
is taken only where the read cannot be trusted, either because the
driver synthesizes the count from state the ISR also touches
(TIMER_CORE_COUNTER_NONATOMIC) or because the full 64-bit baseline is
not a single load on a 32-bit CPU.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
TIMER_CORE_BACKEND_RELOAD covers hardware that fires after a relative
delay rather than at an absolute value: down-counters and
compare-match-reset periodics. It is assumed to auto-reload, so a
non-tickless kernel leaves it alone after init and the driver owns the
period.
Programming a reload restarts the counter, which the absolute backends
never have to think about, and that costs two guards the compare path
does not need. timer_core_arm() remembers the tick-aligned deadline it
armed and does nothing while that deadline has not moved, since the
kernel re-evaluates its earliest timeout on every add and abort and
back-to-back calls usually land on the same tick boundary. And a reload
floored at TIMER_CORE_ALARM_MIN_CYCLES is left to expire rather than
rewritten, or a set_timeout() stream arriving faster than the floor
would push the fire point out for as long as the stream lasts and
freeze announced time.
The relative delay is clamped against the budget left before the baseline
would fall TIMER_CORE_ALARM_MAX_CYCLES behind, not against that value
alone, which keeps the same invariant the compare path gets from clamping
its absolute deadline.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
TIMER_CORE_BACKEND_COMPARE_EXACT is the same hardware shape as
COMPARE_ORDERED, but the match is on equality only, so a deadline
written after the counter has passed it is lost for a whole counter
period. hpet and mips_cp0_timer work this way.
The core writes such a comparator through a verify loop that re-reads
the counter and pushes the target out, doubling the push, until it is
genuinely ahead. That is a generalisation of what hpet already does
privately, and it is what lets such a driver drop the minimum-delay
floor it would otherwise need: the floor exists to keep a deadline far
enough ahead to be caught, and the loop establishes that directly
rather than by guessing a constant.
Both flavours are reached through one core-side timer_core_set_compare(),
so neither the arming path nor the SMP bring-up branches on which is in
use.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Every tickless system-timer driver reimplements the same tick
accounting by hand: the cycle-to-tick division, the announce baseline
(last_cycle/last_tick/last_elapsed), the tick-aligned deadline
computation and the range clamp. The logic is identical across the
free-running-compare drivers (arm_arch_timer, riscv_machine_timer,
hpet, ...) down to the copied overflow-guard constant, and the small
divergences between the hand-rolled copies are a recurring source of
timer bugs.
Add system_timer_generic.h, an implementation header a driver includes
to get that accounting for free. It emits the tick-facing contract the
kernel calls (sys_clock_set_timeout(), sys_clock_elapsed()) and owns
the baseline state, so the driver is left with only cycle-domain
primitives: read the counter, arm the comparator, acknowledge the
interrupt. The emitted sys_clock_set_timeout() ignores the deprecated
idle argument; a converted driver gets the idle handoff through
sys_clock_idle_enter().
The header is included, not linked: the driver defines its constants
and static-inline primitives first, so the core inlines and
constant-folds against them (the per-tick divide becomes a
multiply-shift) on a plain -Os build with no LTO. Because the header
defines the global sys_clock_* symbols, a build that pulls in two
system timers fails at link time, which is the correct outcome. It
lives beside the drivers rather than under include/, as it is private
to them.
This commit covers one hardware shape,
TIMER_CORE_BACKEND_COMPARE_ORDERED: a free-running counter and an
absolute comparator whose match is an ordered comparison, so a deadline
already in the past fires immediately. arm_arch_timer and
riscv_machine_timer work this way. The commits that follow add the other
shapes and the cycle counter getters. The header documents the primitives
a driver provides and the knobs it may set.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Entering idle is signalled to the driver through the idle argument of
sys_clock_set_timeout(), which every driver has to carry whether or not
it has anything to hand off. Give the transition its own interface.
Add a weak sys_clock_idle_enter() hook, called by the power management
path when the CPU is about to be put to sleep. A driver that can
reconfigure for low power, hand over to a wakeup timer, or stop its
clock does so there; one that cannot needs no implementation at all.
The default forwards to sys_clock_set_timeout() with the deprecated idle
argument set to true, so a driver keying on that argument keeps working
until it migrates. Recovery is sys_clock_idle_exit(), as before.
The decision in pm_system_suspend() mirrors the one reprogram_next()
makes for a running system. Nothing to wake up for, with the uptime
allowed to drift, is handed over as SYS_CLOCK_IDLE_FOREVER so a driver
can stop its clock knowing sys_clock_idle_exit() will follow; anything
else is a wakeup deadline, adjusted for the exit latency as before.
The hook is issued on every suspend. The idle argument it replaces only
reached the driver when the exit latency was non-zero, so a platform
declaring none left a driver no way to learn the CPU was going to sleep,
which is when a handoff to a low-power wakeup timer has to happen. Where
the deadline needs no adjusting the driver is simply asked for the one it
already has.
That condition arrives in its own value rather than as K_TICKS_FOREVER,
which is unusable in an unsigned tick count: it is (int64_t)-1 with
CONFIG_TIMEOUT_64BIT and UINT32_MAX without it, so a driver comparing
against it would be testing two different things depending on the
configuration. SYS_CLOCK_IDLE_FOREVER sits above SYS_CLOCK_MAX_WAIT, the
longest wait the kernel ever asks for, so it cannot alias a deadline.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
An empty timeout list normally still gets the driver a wakeup request.
That is a synthetic timeout: nothing is waiting for it, it is there to
keep the announce baseline moving so uptime stays correct.
CONFIG_SYSTEM_CLOCK_SLOPPY_IDLE is the permission to skip it, which is
why an empty list only becomes visible to a driver when that option is
set, and today it becomes visible as a tick value the driver has to
recognise rather than as a condition of its own.
Add a weak sys_clock_no_timeout() hook, called in place of
sys_clock_set_timeout() when the list is empty and sloppy idle allows the
uptime to drift. Its default asks sys_clock_set_timeout() for UINT32_MAX
ticks, which is what K_TICKS_FOREVER is in the unsigned tick domain this
interface now uses, so an out-of-tree driver that has not migrated still
sees the "no deadline" value it always did. What gets deprecated is the
special meaning, not the call.
next_timeout() no longer decides sloppy idle, so its empty-list and
far-timeout arms collapse into one capped budget. The far-timeout arm no
longer stops a tick short of the cap either: it only did so to stay
distinguishable from the empty case, which now travels out of band.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
CONFIG_SYSTEM_CLOCK_SLOPPY_IDLE lets the kernel skip the wakeups that
keep uptime accurate while no timeout is pending. No in-tree board
selects it and no test enables it, so the drivers implementing it have
never run. Several stop their time base outright, which freezes
k_cycle_get_32() under a running thread and can hang k_busy_wait(), and
some of those cannot start it again at all.
Mark the option experimental until those drivers have been audited.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Set the MCAN TX/RX FIFO sizes based on CAN_FD_MODE.
This allows more efficient use of MRAM if CAN_FD_MODE is disabled.
Some Bosch M_CAN IPs (e.g. the ones used in certain STM32 families) use a
fixed Message RAM layout, where RX/TX buffer elements are always of a fixed
size. These drivers must now select CONFIG_CAN_MCAN_FIXED_MRAM_LAYOUT.
Signed-off-by: Ryan Erickson <ryan.erickson@ezurio.com>
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
The mux subsystem rework converted the PWM and qdec INPUTMUX consumers
to mux-states and deleted the #inputmux-cells specifier space, but this
driver was left behind on inputmux-connections, so enabling capture now
fails at devicetree parse time (counter_capture on frdm_mcxa153).
Convert it the same way as pwm_mcux_ctimer: mux-states in the binding
and test overlay (same cells, renamed), a mux_state_apply() loop in the
driver with its error propagated out of init, select MUX in Kconfig,
and the missing Counter entry in the 4.5 migration guide.
Fixes#115616
Signed-off-by: Benjamin Perseghetti <bperseghetti@rudislabs.com>
Change the RESET_STM32 prompt from "STM32 reset driver" to
"STM32 RCC reset driver" for clarity, per reviewer feedback.
Signed-off-by: Jake Jonggeun Park <ndamin221@gmail.com>
Co-authored-by: Mathieu CHOPLAIN <mathieu.choplain-ext@st.com>
Use the "<name> reset driver" form for reset driver prompts, per
doc/contribute/style/kconfig.rst. "reset" is the driver type, matching
the RESET_ symbol prefix, like "<name> ADC/PWM driver" in other subsystems.
Prompt-only; no symbol renames.
Part of #7272
Signed-off-by: Jake Jonggeun Park <ndamin221@gmail.com>
The I2S FIFO must be accessed with 32-bit DMA transfers even when
samples are 8 or 16 bits wide. Use the configured sample width on the
memory side and word width on the peripheral side for both stream
directions. This preserves FIFO sample packing and matches the MAX32
HAL implementation.
Fixes: 4409ba8655 ("drivers: i2s: add i2s driver for max32 mcu")
Signed-off-by: Shan Pen <bricle031@gmail.com>
Now that all series (with wake-up pins) have been migrated to the new
binding, drop the old driver.
Signed-off-by: Mathieu Choplain <mathieu.choplain-ext@st.com>
Add a new STM32 SoC-specific driver for management of wake-up pins at
Power Controller level. The more generic terminology "wake-up lines" is
used for consistency across all series, but the driver currently focuses
only on wake-up lines connected to GPIO pins. This driver is designed to
handle nodes with the new `st,stm32-pwr-wkupctrl` compatible as well as
derivatives (`st,stm32f1-pwr-wkupctrl` and `st,stm32f7-pwr-wkupctrl`).
The old driver is retained for backward compatibility; selection is done
automatically based on whether a node with the new compatible is present
and active in the Devicetree or not.
While at it, also update the STM32 GPIO driver to use the new driver
when appropriate by introducing a new (private) API. The old driver is
considered as deprecated and will be removed in a future commit.
Signed-off-by: Mathieu Choplain <mathieu.choplain-ext@st.com>
Adds the comparator driver for the Infineon HPPASS CSG comparator. Each
instance of the device represents one slice within the CSG device. Each
instance registers a dispatch callback with the CSG MFD parent to handle
it's portion of the shared comparator interrupt.
Assisted-by: Github Copilot:claude-opus-4.7
Signed-off-by: John Batch <john.batch@infineon.com>
Add helpers to arm the combined comparator interrupt and add a critical
section around it. Reduce callback register critical section from
irq_lock to irq_disable of the comparator interrupt.
Assisted-by: Github Copilot:claude-opus-4.8
Signed-off-by: John Batch <john.batch@infineon.com>
The return value of dmm_buffer_out_prepare() was immediately
overwritten by the queue put, so a failed preparation went
unnoticed and an invalid buffer could be handed to the TDM
peripheral. Propagate the error like the RX path does.
Assisted-by: Claude:fable-5
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
Report per-SI hardware statistics through the Ethernet .get_stats API.
netc_eth_get_stats reads the SI transmit discard counter (SITDFCR) into
tx_dropped and is shared by the PSI and VSI. The PSI additionally reads
the port-level receive-discard counter (rx_missed_errors) through
EP_GetPortDiscardStatistic, which only the PSI can access. All of this is
gated on CONFIG_NET_STATISTICS_ETHERNET.
Signed-off-by: Peter van der Perk <peter.vanderperk@nxp.com>
Add a NETC Virtual Station Interface (VSI) driver and its binding so Zephyr
can drive an ENETC virtual function while a separate OS owns the PSI/PF.
The driver brings the SI up off the boot path in a service thread, gating
first access on the NETC clock and the PF's SR-IOV VF-enable bit so it
can't fault on a not-yet-decoding SI. It programs its own unicast MAC and
multicast-promiscuous mode through VSI->PSI messages.
Note: the current Zephyr NETC PSI driver implements neither SR-IOV nor
PSI<->VSI messaging, so only the Zephyr-VSI-to-Linux-PSI path is tested.
Rework the shared Tx datapath for throughput: coalesced Tx-completion
interrupts (frame-threshold + timer), a per-slot buffer ring so frames
aren't serialised on one buffer, and backpressure that blocks on a full
ring instead of dropping. PTP egress timestamps are read with a bounded
busy-wait.
Signed-off-by: Peter van der Perk <peter.vanderperk@nxp.com>
Load the MAC address through the new net_eth_mac_load() /
NET_ETH_MAC_DT_INST_CONFIG_INIT() helpers instead of the driver-specific
NETC_GENERATE_MAC_ADDRESS macro.
Signed-off-by: Peter van der Perk <peter.vanderperk@nxp.com>
Implement the SCMI CLOCK_CONFIG_GET command (scmi_clock_config_get) and
wire it into the ARM SCMI clock_control driver as a .get_status callback.
This lets a consumer query a clock's enabled state over SCMI.
Signed-off-by: Peter van der Perk <peter.vanderperk@nxp.com>
With PR #112952 the FLASH_NODE logic was unified to use a common
handler.
Use the same logic in flash_infineon_qspi now that the memory map has
been updated to remove the fixed partition compatible.
Additionallly clean up the KConfing to only check for mapped partition
and remove the fixed partition check.
Signed-off-by: Laura Carlesso <laura.carlesso@infineon.com>
