The message queue holds the result of a transfer: the PIO completion
handler puts a zero in it, and mipi_dbi_pico_pio_start_wait_reset_sm()
returns whatever it reads back. The DMA handler puts the channel number
there instead when status is negative.
An error on channel 0 is therefore delivered as 0 and the write reports
success. Channels come from dma_claim_unused_channel(), which hands out
the lowest free one, so channel 0 is the likely one for the first split.
Any other channel returns a positive number where the API expects a
negative errno.
The loop above already identifies which split owns the channel, so the
number itself is not needed in the message.
Signed-off-by: Hsiu-Chi Tsai <hctsai@linux.com>
mipi_dbi_pico_pio_write_helper() locks data->lock, but nothing calls
k_mutex_init() on it and the instance data is a zero-filled static
struct, so the wait queue is never set up.
An uncontended lock and unlock survive that: a zeroed wait queue does
not read as empty, peek returns NULL, and the unpend guards on it. The
first thread that blocks reaches sys_dlist_append(), which writes
through a NULL tail. Single-threaded use is why this has held so far.
It goes at the top, before the GPIO configuration that can return
early. mipi_dbi_spi.c and mipi_dbi_bitbang.c both initialise their own
lock the same way, the latter since 115854.
Signed-off-by: Hsiu-Chi Tsai <hctsai@linux.com>
When an asynchronous transfer times out, its completion callback can
give the semaphore before the abort path disables interrupts. This
leaves a stale completion token that a subsequent transfer can consume,
allowing it to return while the controller is still using the caller's
buffer. If the buffer is stack-allocated, this can cause a
use-after-return.
Reset the completion semaphore and error state after aborting the
failed transfer, while still holding the transfer mutex. This discards
any completion notification that raced with the timeout and ensures
the next transfer waits for its own completion.
Signed-off-by: Xiaolu Sun <xiaolu.sun@intel.com>
Alif SoCs feed some peripherals from two clocks in the always-on power
domain (PD-0) that the driver cannot describe today: S32K_CLK and
128K_CLK. Add parent identifiers for both and describe them in
devicetree.
S32K_CLK is the output of the ANA MISC_CTRL[SEL_32K] multiplexer, which
runs it from either the LFRC or the LFXO oscillator. Describe the two
oscillators as fixed clocks and the multiplexer output as a node
switched to one of them, so that the rate follows the selection instead
of being restated as a literal. SEL_32K is configured outside Zephyr
today. The bit resets to the LFRC, which is what the multiplexer node
records. A board or application which needs to select the LFXO instead
has to repoint the node at it.
128K_CLK is derived from the LFRC rather than being an independent
oscillator and runs at four times its rate, so it is described as a
fixed factor of that node.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Silesh C V <silesh@alifsemi.com>
alif_clock_control_on() returned early whenever the encoded clock ID
carries no enable bit, which happens before the block that programs the
clock source mux. A clock that is always on but still has a selectable
source was therefore left on whatever source the reset value or the boot
firmware selected.
The enable control and the source control are independent in the clock
ID encoding and either may be absent. Program the source whenever the
encoding describes a mux, enable the clock only when the encoding
describes an enable bit, and take the early exit only when the clock has
neither.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Silesh C V <silesh@alifsemi.com>
eth_mchp_get_stats() accesses the vendor member of struct net_stats_eth
as an embedded structure, but it is a pointer to an array of key-value
pairs. The driver fails to build with
CONFIG_NET_STATISTICS_ETHERNET_VENDOR=y.
The driver provides no vendor statistics and the pointer is already
NULL because the device data is zero-initialized, so remove the block.
Assisted-by: Claude:claude-fable-5.1
Signed-off-by: Tim Pambor <tim.pambor@codewrights.de>
adin2111_port_send() declares the port data pointer when
CONFIG_NET_STATISTICS_ETHERNET is enabled, but nothing uses it since
commit 18c00a714f ("drivers: ethernet: remove redundant tx stats").
Building the driver with Ethernet statistics enabled fails with
-Werror=unused-variable.
Remove the variable.
Assisted-by: Claude:claude-fable-5.1
Signed-off-by: Tim Pambor <tim.pambor@codewrights.de>
Store the public identity address that the Host hands to the driver's
setup() op also in the common HCI driver data, through the new
bt_hci_set_public_addr() API, before the HCI transport is opened. The
driver reads it with bt_hci_get_public_addr() and can apply it during
open(), i.e. from vendor-specific initialization that does not depend
on the Host's command APIs being available.
bt_hci_get_public_addr() returns BT_ADDR_ANY while no public address
has been set, which is what setup() receives in that case, so a driver
moving from one to the other keeps the check it has, and driver data
that has never been written needs no flag to say so. BT_ADDR_NONE is
the name that suggests itself for this, so the choice is spelled out
where a driver author looks: on both functions, with the check a driver
is expected to make, on the field, on the setup() parameter, which did
not document its value until now, and in the Kconfig help. The test
pins the value.
The channel is set on every bt_enable() and cleared when there is no
public identity, so that an address an earlier enable left behind is
not applied to the controller by a later one.
The setup() path keeps receiving the address as before; both channels
coexist until the drivers implementing setup() have migrated. So that
enabling the new channel no longer pulls in the mechanism it replaces,
BT_HCI_SET_PUBLIC_ADDR stops selecting BT_HCI_SETUP; the drivers that
apply the address in setup() (BlueNRG ACI, STM32WBA, CYW208XX) now
select BT_HCI_SETUP themselves, matching the conditions their setup()
implementations are compiled under.
Both functions are declared unconditionally, as coding guideline rule
A.1 requires of a header, so that their callers can select on the
option with IS_ENABLED() rather than the preprocessor, and defined in
a source file that is compiled only when the option is enabled, so
that a call that is not guarded fails to link rather than quietly
doing nothing. Only the field they work on is conditional, so a driver
that does not announce the capability pays nothing for it.
The driver API group version goes to 0.3.0 for the two functions added
to it.
The host identity test gains a scenario that creates a public identity
before bt_enable() and checks what the driver is handed while the
transport is opened, including that an enable without a public identity
hands it nothing rather than what the previous one left. The scenario
enables the capability through a prompt the test adds to it, since the
option is otherwise selected by drivers only. Its fake driver gains a
close() op, which the test needs in order to cycle the transport.
Assisted-by: Claude:claude-fable-5-1
Signed-off-by: Johan Hedberg <johan.hedberg@silabs.com>
Cache maintenance was being done on the DMA address after
uhc_dwc2_quirk_dma_addr_xlate() translated it, which is not
CPU-visible on some platforms and causes a data abort. Move
cache maintenance before the translation in ch_process_control(),
ch_start_control(), and ch_start_bulk().
Signed-off-by: Muhammad Waleed Badar <walid.badar@gmail.com>
dma_addr is an integer type, not a pointer, so comparing it
against NULL and passing it directly to sys_cache_data_invd_range()
/sys_cache_data_flush_range() was incorrect.
Signed-off-by: Muhammad Waleed Badar <walid.badar@gmail.com>
Send the vendor-specific set-public-address command from within open(),
through the HCI lockstep helper and the driver's own send path, instead
of implementing the setup() driver API op on top of the Host's
bt_hci_cmd_send_sync(). The response is consumed in the driver's event
handler by feeding received packets to the lockstep helper before
delivering them to the host.
The driver no longer calls any Host command API, so the address is now
also configured in controller-only builds, where bt_enable_raw() only
opens the driver and never called setup(), and it no longer selects
BT_HCI_SETUP. A failing or unanswered command fails open() with an
error instead of failing the Host's HCI initialization later, and is
logged by the helper.
open() aborts the receive thread it started when the command fails, so
that a second bt_enable() does not create a thread that is still
running.
The raw send path is factored out of send() and takes the device, so
that it serves both the send() op and the helper. It now reports a
failed Cy_BLE_SoftHciSendAppPkt() to its caller instead of logging and
returning success, which the helper needs in order to tell a command
that was not submitted from one that went unanswered.
Build-tested on cy8cproto_063_ble with the peripheral_hr sample. Not run
on hardware.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Johan Hedberg <johan.hedberg@silabs.com>
Add SAM0_GPIO_DRIVE_STRONG, a SAM0 specific GPIO devicetree flag that
sets PORT PINCFG.DRVSTR on pins configured as outputs.
gpio_sam0_config() rebuilds PINCFG from zero on every call, so a drive
strength selected through pinctrl is cleared as soon as the pin is
configured through the GPIO API. Carrying it on the gpios specifier
selects the stronger driver where the pin is declared, alongside the
existing SAM0_GPIO_DEBOUNCE.
On SAM D5x/E5x this raises the rated output current from 2 mA to 8 mA
at VDD >= 3.0 V (DS60001507, Table 54-13).
Assisted-by: Claude:claude-opus-5
Signed-off-by: Thomas Chiantia <thomas.chiantia@proton.me>
The NXP S32K3 series integrates the same DWC Ethernet QoS controller as
the MCXE31x, with the same interrupt lines and clock domains and without
a reset line, but is described by the nxp,s32-gmac compatible and uses
the RTD HAL headers. Extend the driver to also support the S32K3 series.
The NXP S32 GMAC driver does not support PTP, so use the dwc_mac driver
by default on S32K3 if PTP support is required.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Tim Pambor <tim.pambor@codewrights.de>
The receive, transmit and timestamp clocks of the S32K3 EMAC each come
from an MC_CGM mux that has to be switched to the right source before
the MAC leaves reset. The driver can only gate clocks and the boot clock
configuration leaves these muxes on FIRC, so the EMAC cannot be clocked
through clock control.
When the EMAC node is enabled, turning on one of the EMAC0 RX, TX or TS
gates now first switches the mux of that domain and sets its divider:
- RX and TX take the clocks the PHY drives into the pads: the 50 MHz
reference divided by 2 for RMII, or the separate 25 MHz clocks for
MII, following the phy-connection-type of the EMAC node.
- TS takes PLL_PHI0 undivided. It is locked to the crystal, keeps
running regardless of the PHY and the link speed, and satisfies the
self-test of the EMAC timestamp memory, which needs at least 1.5 times
AIPS_SLOW_CLK, more than the PHY clocks provide. MCX N and MCX A feed
their timestamp clock from a crystal-locked PLL as well.
The HAL has no call to switch a single mux, so this goes through
Clock_Ip_Init() with a configuration holding only that mux and divider.
Turning the gates off and reading clock rates are unchanged, and the
NXP S32 GMAC driver, which does not use these gates, is not affected.
The RX and TX handling mirrors the same EMAC on the MCXE31x in the
MC_CGM driver.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Tim Pambor <tim.pambor@codewrights.de>
The NXP S32 GMAC MDIO driver was tied to the SoC family, so it was
enabled on any S32 SoC with a snps,dwmac-mdio node regardless of the
Ethernet driver in use. Depend on ETH_NXP_S32_GMAC instead, so the MDIO
driver is only built together with the S32 GMAC Ethernet driver and is
left out when the generic dwc_mac driver is selected, which brings its
own driver for the same node.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Tim Pambor <tim.pambor@codewrights.de>
The RA8x1 cpu@0 node carries cpu-power-states but has no label, so
DT_NODELABEL(cpu0) does not resolve and the CPU power states are
invisible on ek_ra8m1, ek_ra8d1, fpb_ra8e1 and mck_ra8t1. Labelling it
alone would make the CGC driver select cpuclk0, which only the dual-core
RA8x2 parts define, so test the single-core cpuclk node before the
cpu0/cpu1 discrimination and add the label in the same commit.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
Assisted-by: Claude:opus-5
update hal nxp to SDK 26.09.00-rc1
SDK 26.09 renames the core#1 divider field of MCXW70's
scg_sys_clk_config_t from divPlat to divCore1, pairing it with the
existing divCore for core#0. The bit position and meaning are unchanged,
so follow the rename in clock_control_nxp_mcxw7x.c to keep the SoC
building. The devicetree property stays sys-clk-div-plat.
Signed-off-by: Zhaoxiang Jin <Zhaoxiang.Jin_1@nxp.com>
Each channel gets an event bit at UHC_DWC2_EVENT_PORT_PEND_CHANNEL plus
its index, so the enumerator has to be last. It sat in the middle, and on
a controller with several channels those bits collided with the suspend,
resume and dequeue events. Found on an STM32N6570-DK, which has 16.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
wifi_shell.c carried a private wifi_freq_to_channel() and the
hwsim driver open coded the same conversion twice, as a plain
(freq - 2407) / 5. Neither matches wifi_utils_chan_to_freq() at
channel 14: 2484 MHz maps back to channel 15, which has no
frequency, so a radio set up from a frequency alone ends up off
the medium.
Add wifi_utils_freq_to_chan() as the inverse of the forward
helper. A candidate channel is only returned once it converts
back to the frequency asked for, so the two directions cannot
drift and a frequency between two channel centers is rejected.
No band argument is needed because a center frequency is unique
across the bands. Drop the shell copy and use the helper in both
places.
The shell copy resolved neither the 5 GHz channels 32, 68 and 96
nor any 6 GHz channel, and printed the raw frequency in the
channel column for those. They now resolve, and a frequency that
belongs to no channel prints as 0 rather than as itself.
Assisted-by: Claude:opus-5
Signed-off-by: Sylvio Alves <sylvio.alves@espressif.com>
Replace the local 2.4 GHz channel to frequency macros with
wifi_utils_chan_to_freq(). The remaining conversions in this
driver go through the vendor HAL and are left alone.
Assisted-by: Claude:opus-5
Signed-off-by: Sylvio Alves <sylvio.alves@espressif.com>
Drop the two local mhz_from_2g_channel() and
mhz_from_5g_channel() helpers in favour of
wifi_utils_chan_to_freq(), so the band tables are built from the
same conversion as the rest of the tree.
Assisted-by: Claude:opus-5
Signed-off-by: Sylvio Alves <sylvio.alves@espressif.com>
Replace the open coded channel to frequency conversion with
wifi_utils_chan_to_freq().
The old code clamped every frequency above 2472 MHz to 2484 MHz,
so a channel beyond 14 was reported as channel 14. The helper
returns 0 for a channel that is not valid in the band, and such a
channel is now left out of the reported list instead of being
emitted with a zero center frequency.
Assisted-by: Claude:opus-5
Signed-off-by: Sylvio Alves <sylvio.alves@espressif.com>
Replace the open coded 2.4 GHz channel to frequency arithmetic,
which was spread over a macro in one file and five separate
expressions in the others, with wifi_utils_chan_to_freq().
None of the copies handled channel 14, so they reported it as
2477 MHz instead of 2484 MHz. The base frequency define stays for
the two frequency to channel conversions in wifi_hwsim_supp.c,
which a later commit converts as well.
Assisted-by: Claude:opus-5
Signed-off-by: Sylvio Alves <sylvio.alves@espressif.com>
When gnss start/stop api first implemented, wrong reset type was set
in driver implementation for warm and cold start operations, causing
unwanted loss of RAM/BBR CFG layers.
Signed-off-by: Konstantinos Papadopoulos <kostas.papadopulos@gmail.com>
This set of subops is used to access and modify some parameters of
FLASK security server and access vector cache.
Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
Add SHA3-224/256/384/512 support to the public hash API and to the
STM32MP13 HASH driver, on top of the existing SHA-2 polling/interrupt
paths added previously.
- include/zephyr/crypto/hash.h: add CRYPTO_HASH_ALGO_SHA3_{224,256,
384,512} to enum hash_algo.
- drivers/crypto/crypto_stm32_hash.c: dispatch the four SHA-3 variants
through both the polling (HAL_HASHEx_SHA3_xxx_Start()) and interrupt
(HAL_HASHEx_SHA3_xxx_Start_IT()) HAL entry points, gated by a new
STM32_HASH_USE_SHA3 macro defined whenever the devicetree node
advertises st,has-sha3-algorithm. DT_DRV_COMPAT and the new macro
are now defined ahead of the "crypto_stm32_hash_priv.h" include so
the private header can see STM32_HASH_USE_SHA3.
- drivers/crypto/crypto_stm32_hash_priv.h: size
STM32_HASH_MAX_DIGEST_SIZE from STM32_HASH_USE_SHA3, keeping it at
32 bytes (SHA-256) on nodes without SHA-3 support and growing it to
64 bytes (SHA3-512) only where needed.
- drivers/crypto/crypto_mbedtls_shim.c: map the new enum values to the
corresponding PSA_ALG_SHA3_xxx algorithms in the mbedTLS software
shim. Also fix mbedtls_hash_session_setup() to return -ENOTSUP
(instead of -EINVAL) for an unrecognized/disabled algorithm,
matching the convention already used by every other hash driver
(stm32_hash, esp32_sha, ...) so that ztest's "skip on -ENOTSUP"
pattern works uniformly regardless of which PSA_WANT_ALG_* bits
happen to be enabled.
- drivers/crypto/Kconfig: imply PSA_WANT_ALG_SHA3_{224,256,384,512}
from CONFIG_CRYPTO_MBEDTLS_SHIM, so all four SHA-3 variants are
exercised through the software shim the same way the SHA-2 family
already is.
Verified with `west build -b stm32mp135f_dk tests/crypto/crypto_hash`
(hardware and mbedTLS-shim variants) and a stm32h573i_dk build (no
SHA-3 HW, compiles fine and exercises the -ENOTSUP skip path).
Assisted-by: Claude:sonnet-5
Signed-off-by: bernard Puel <bernard.puel@st.com>
Add interrupt-driven HASH processing for SHA-224/SHA-256, on top of
the existing polling-only HAL_HASHEx_SHAxxx_Start() driver. The
calling thread now blocks on a semaphore given from the HASH ISR
instead of busy-polling status registers, freeing the CPU while the
peripheral computes the digest. This is purely devicetree-gated (no
Kconfig toggle): it activates automatically whenever the node has an
interrupt line, and falls back to polling for algorithms without a
HAL _Start_IT() variant (SHA-384/SHA-512).
Unlike other STM32 families already wiring up this same HASH IP
(F4/F7/H5/C5, e.g. `interrupts = <80 0>;` on H7), the STM32MP13
devicetree node had no `interrupts` property at all. Add it the same
way, using GIC SPI 81, derived from the CMSIS HASH1_IRQn (=113)
constant converted to GIC SPI numbering (SPI = IRQn - 32,
cross-checked against this SoC's I2C5 entry). No binding change is
needed: DT_INST_IRQN()/DT_INST_IRQ_HAS_IDX() work directly off the raw
devicetree data regardless of whether `interrupts` is declared in the
compatible's own binding, exactly as already relied upon for the other
families.
Also wire up the interrupt-driven path for HAL2-based series (C5, and
future ones): HAL2 exposes a single, algorithm-agnostic
HAL_HASH_Compute_IT() instead of one _Start_IT() per algorithm, so
every algorithm exposed on the node goes through it, unlike the
SHA-224/SHA-256-only restriction of the legacy HAL. Completion is
signalled through HAL2's renamed HAL_HASH_DigestCpltCallback() (the
error callback keeps its legacy name, HAL_HASH_ErrorCallback()), and
readiness is queried through HAL_HASH_GetState() rather than a direct
->State field read, since HAL2 does not expose that field under the
same name. HAL2 already resets its internal phase/state on a
completed digest, so the Phase-reset workaround below does not apply
to it. Compile-tested on nucleo_c562re (STM32C5, HAL2); not exercised
on real HAL2 hardware in this series since STM32MP13 uses the legacy
HAL.
Fix a pre-existing correctness bug found while testing: the vendor HAL
leaves hhash->Phase at HAL_HASH_PHASE_PROCESS after a completed
one-shot digest instead of resetting it to READY. A second
hash_compute() call on the same session therefore silently continued
the previous message's internal digest state instead of starting
fresh, producing a wrong digest with no reported error. Force Phase
back to READY after every completed computation, on both the polling
and interrupt paths.
Enable the HASH node at board level in stm32mp135f_dk.dts and add the
board to tests/crypto/crypto_hash's platform_allow. It is left out of
integration_platforms since stm32mp135f_dk requires an external
flasher not yet wired into CI, so it does not build/run automatically
in Twister's default sweep; the interrupt-mode path is instead
exercised through the samples/drivers/crypto/hash_bench benchmark.
Verified with `west build -b stm32mp135f_dk tests/crypto/crypto_hash`,
`west build -b nucleo_c562re tests/crypto/crypto_hash` and a generic
STM32H573 crypto hash test build.
Assisted-by: Claude:sonnet-5
Signed-off-by: bernard Puel <bernard.puel@st.com>
adc_get_decoder() is declared __syscall but adc_handlers.c never
provided a verifier, so the syscall was not dispatched.
Add the verifier, guarded by CONFIG_ADC_STREAM to match z_impl. The
device is checked with K_SYSCALL_OBJ() rather than
K_SYSCALL_DRIVER_ADC() because get_decoder is optional and z_impl
tolerates a NULL callback. The out-parameter is checked with
K_SYSCALL_MEMORY_WRITE().
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
Assisted-by: Claude:opus-5
z_vrfy_pwm_capture_cycles() left its period/pulse locals uninitialized
and copied them out without consulting the return value.
z_impl_pwm_capture_cycles() leaves both untouched on all of its error
paths, so the values written back were not ones it had set.
Zero-initialize both locals and copy out only on success.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
Assisted-by: Claude:opus-5
The transmit DMA runs with a single beat burst length and completes
each frame, including its transmit status writeback, before touching
the next descriptor. Every frame then pays descriptor and data fetch
latency as dead time on the wire. Raise the burst length to 16 beats
and enable operate on second frame so the DMA prepares the next frame
while the current one transmits. Measured on MCXN947 at 100 Mbit full
duplex this moves a saturating UDP upload from 84.8 to 95.5 Mbps of
goodput, the theoretical maximum for the wire at that frame size.
Signed-off-by: Benjamin Perseghetti <bperseghetti@rudislabs.com>
The transmit path holds one frame in flight and rebuilds the
descriptor list on every send, so the wire idles between frames and
loaded senders see -EBUSY drops. Drive the descriptors as the
persistent ring the hardware supports: program the ring length once,
stage each frame at the head, advance the tail pointer, and reclaim
completed frames in order from the interrupt. The transmit watchdog
guards the oldest outstanding frame, the carrier-loss abort reclaims
every outstanding frame after the queue flush, and each frame reads
its PTP timestamp from its own last descriptor.
Signed-off-by: Benjamin Perseghetti <bperseghetti@rudislabs.com>
Add support for communicating with the CO5300 display controller over
SPI. Implement SPI command and framebuffer write functions and select
the appropriate transport configuration based on the Devicetree bus.
Also add the SPI Devicetree binding and select SPI automatically when a
CO5300 instance is connected to an SPI bus.
Signed-off-by: Muhammad Waleed Badar <walid.badar@gmail.com>
Drop the co5300 driver's internal shadow framebuffer and the associated
even-coordinate/address alignment logic for the MIPI DSI write path.
co5300_mipi_dsi_adjust_coordinates() and its supporting framebuffer
allocation, placement, and alignment machinery (CO5300_FRAMEBUFFER_DECL,
addr_align, frame_ptr/frame_pitch, BUILD_ASSERTs) are removed, and
co5300_mipi_dsi_display_write() now writes directly from the caller-
supplied buffer using the caller's descriptor instead of a locally
adjusted one.
Move window-set and tearing-effect synchronization out of the per-bus
write callbacks (co5300_mipi_dsi_display_write/co5300_mspi_display_write)
and into the shared co5300_write() entry point, so both backends get
consistent handling without duplicating the logic.
Remove the now-unused pitch-align, addr-align, and ext-ram devicetree
properties from the chipone,co5300-mipi-dsi binding, and drop the
corresponding ext-ram/addr-align/pitch-align overlay properties from
the zc143ac72mipi shield.
Required alignment is now handled at the LVGL level instead: enable
LV_Z_AREA_X_ALIGNMENT_WIDTH and LV_Z_AREA_Y_ALIGNMENT_WIDTH (set to 2)
in the zc143ac72mipi shield's Kconfig.defconfig so LVGL rounds
invalidated areas to even boundaries before they reach the driver,
removing the need for the driver to compensate internally.
Signed-off-by: Muhammad Waleed Badar <walid.badar@gmail.com>
Some CO5300 panel variants require the red and blue color channels to be
swapped. Configure the address mode together with the pixel format, as the
required RGB/BGR setting depends on the selected pixel format.
Use the red-blue-swap Devicetree property to select the appropriate color
channel order for each supported pixel format.
Signed-off-by: Muhammad Waleed Badar <walid.badar@gmail.com>
Add support for driving the CO5300 display controller over the MSPI
bus in addition to the existing MIPI DSI backend. Bus-specific write
paths are now selected at build time via DT_ANY_INST_ON_BUS_STATUS_OKAY(),
with a common co5300_write() entry point dispatching to the appropriate
transfer function through the config->cmd_write/display_write callbacks.
Kconfig.co5300 now selects MIPI_DSI or MSPI depending on which bus
the enabled devicetree node is actually on.
Co-authored-by: Pavel Maloletkov <pavllick@gmail.com>
Signed-off-by: Muhammad Waleed Badar <walid.badar@gmail.com>
parent_config in adc_stm32_suspend_setup() is only used when an ADC
has an internal regulator or deep power-down mode, so series without
either (e.g. F4) fail to build with CONFIG_PM_DEVICE=y. Mark it
__maybe_unused.
Fixes a regression from commit 6d8da6d0a3 ("drivers: adc: stm32:
adapt driver to the new parent/child DT hierarchy").
Assisted-by: Claude:opus-5.5
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
close() takes the controller down and aborts the receive thread with no
regard for an SPI transfer in progress. The receive thread holds
sem_spi_available for the duration of a transfer, and
k_thread_abort() does not give the semaphore back, so a close() that
lands in a transfer leaves it taken and the next send blocks forever.
Before that, the controller is put in reset and its clocks are turned
off with the transfer still in flight.
Hold the semaphore across both, so that close() waits for the transfer
in progress to finish before it touches the controller or the thread.
bt_apollo_controller_deinit() does no SPI transfer of its own, so it
cannot wait for the semaphore close() holds.
Holding the semaphore does not stop a send that is already under way,
though: the send path gives it back between its attempts, which it
repeats for up to five seconds, so that the receive path can drain the
controller in the meantime. The driver therefore keeps track of whether
the transport is open and of how often that has changed. open() and
close() update both while holding the semaphore, and the send path
gives up with -ENETDOWN if on getting the semaphore the transport is
closed or the count has moved on since the send began. The count is
what stops a send that slept through a close() and the open() after it
from delivering the old session's packet to the new one; the flag is
what stops a send that starts while close() is finishing. The count is
atomic because a send notes it before it has the semaphore: what
counts is the session the call began in, not the one in which it first
gets the semaphore. open() makes its update before the controller
initialization, which already sends through the same path.
A close() from the receive callback aborts the calling thread, which
never returns to give the semaphore back, so that case gives it back
before the abort.
Build-tested on apollo4p_blue_kxr_evb and apollo3_evb with the
peripheral_hr sample. Not run on hardware.
Assisted-by: Claude:claude-fable-5-1
Signed-off-by: Johan Hedberg <johan.hedberg@silabs.com>
Send the vendor-specific NVDS configuration command from within open(),
through the HCI lockstep helper and the driver's own SPI send path,
instead of implementing the setup() driver API op on top of the Host's
bt_hci_cmd_send_sync(). The responses are consumed in the driver's
receive thread by feeding received packets to the lockstep helper
before they reach the host.
The command no longer depends on the Host, so the two code paths that
existed for it, one building the packet by hand for controller-only
builds and one going through the Host, collapse into one, and the
driver no longer selects BT_HCI_SETUP. The hand-built path was in fact
unreachable: bt_enable_raw() opens the driver without calling setup(),
so a controller-only build sent neither the NVDS command nor the reset
that follows it. Both now run there. A failing or unanswered command
fails open() with an error instead of failing the Host's HCI
initialization later, and is logged by the helper.
The reset that makes the NVDS parameters take effect is now sent in
every build. Only the controller-only path sent it before; builds with
a Host relied on the Host's own reset, which follows a few HCI
transactions later.
open() aborts the receive thread it started when the controller
initialization or the vendor command fails, so that a second
bt_enable() does not create a thread that is still running.
The raw send path is factored out of send() and takes the device, so
that it serves both the send() op and the helper.
Build-tested on apollo4p_blue_kxr_evb and apollo3_evb with the
peripheral_hr sample. Not run on hardware.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Johan Hedberg <johan.hedberg@silabs.com>
Add support for the counter capture API to the MCUX TPM driver. The
driver stores capture callbacks per channel, maps Zephyr edge flags to
TPM input capture edges, enables the channel interrupt, and reports the
captured counter value from the TPM CnV register. Single-shot captures
disarm the channel from the ISR, continuous captures stay armed.
The ISR samples CnV before clearing CHF. Every selected edge latches
the counter into CnV, and the reference manual only guarantees that a
CHF interrupt is not lost across the clearing sequence, not that CnV
still holds the value the current interrupt was raised for.
Capture is mutually exclusive with alarms on the same channel because
both features share the counter channel namespace.
A TPM channel samples the signal present on its own TPMx_CHn pad, so
add optional pinctrl support and a counter-capture-cells specifier to
the binding. That lets a board mux the pad from devicetree and pick the
sampled channel without changing the public counter API.
A channel can alternatively capture from a trigger input rather than
from its pad, by setting TRIG[n] and routing TRGMUX to the TPM input
capture target. That would give a fully on-chip capture source, as
CTIMER has through INPUTMUX, but it needs a trgmux node that the MCXW7x
SoC devicetree does not have yet, so it is left for a follow-up. This
patch wires only the pad path and takes no mux subsystem dependency.
Signed-off-by: Holt Sun <holt.sun@nxp.com>
Implement the counter_api reset callback for the NXP TPM counter
driver. Writing any value to the CNT register resets the counter to
its initial value while leaving the timer running.
Without this callback counter_reset() returns -ENOSYS, which the
shared counter test suites call unconditionally during setup.
Signed-off-by: Holt Sun <holt.sun@nxp.com>
The controller only streams pixels and has no backlight of its
own, so a brightness request has nowhere to land and callers get
-ENOSYS even when the attached panel can set one.
Add the set_brightness callback and hand the value to the panel,
the same way blanking and orientation are already forwarded.
Assisted-by: Claude:opus-5
Signed-off-by: Sylvio Alves <sylvio.alves@espressif.com>
A caller that renders into its own full size frames has them scanned
out directly, so the driver framebuffers are never read. Every other
display driver accepts zero here; this one required at least one and
wasted a frame worth of external memory.
Assisted-by: Claude:opus-5
Signed-off-by: Sylvio Alves <sylvio.alves@espressif.com>
A caller that hands in its own full size frames rotates through
them, so the driver has to make it wait for the frame it is about
to reuse. The wait was gated on the driver owning more than one
framebuffer, which is not what decides it: the frames belong to
the caller. With one driver framebuffer the wait was skipped and
the next frame was drawn into one still being scanned out,
tearing the picture.
Drop the gate and give each adopted frame a link list item of its
own, so a flip never repoints the item the panel is reading. A
partial update waits the same way before it draws into the buffer
the previous frame left behind.
Assisted-by: Claude:opus-5
Signed-off-by: Sylvio Alves <sylvio.alves@espressif.com>
Rename driver-specific dt macros for consistency. Prefix the macros with
ADC_STM32_ or ADC_SUB_STM32_, then depending if they use an inst or a
node_id: DT_INST_ or DT_.
Alos use inst as argument in DT_INST* macros instead of index and node_id
instead of node to be consistent with devicetree.h convention.
No functional change.
Signed-off-by: Guillaume Gautier <guillaume.gautier-ext@st.com>
