I am not using Silicon Labs platform for a while now and will not be for
the foreseeable future.
Signed-off-by: Christian Taedcke <christian.taedcke@lemonbeat.com>
Asbjorn will not be as involved with Zephyr
development anymore, so removing him as a codeowner.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
This introduces the I3C API for I3C controllers. Currently,
this supports one controller per bus under Zephyr.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Add R-Car Gen3 PWM driver.
Clock diviser is automatically adjusted according to requested period
and duty-cycle in order to obtain as much accuracy as possible.
Indeed, in order to improve PWM accurancy, the PWM clock has to fit
the requested period. So use the given period_cycle to define if the
clock as to be adapted. In such case, increase/decrease the clock
diviser to adapt the period_cycle and be sure that it fits into the
10 bits counter of the PWM controller.
Tested on H3ULCB on pwm0 and pwm4.
Signed-off-by: Pierre Marzin <pierre.marzin@iot.bzh>
WealianLiao is unable to support Zephyr for npcx chip for the
foreseeable future. Remove him from the CODEOWNERS file.
Signed-off-by: Jun Lin <CHLin56@nuvoton.com>
Fix warnings/errors:
* Path '/drivers/dma/*cavs*' not found in the tree
* Expected '/' after directory 'scripts/west_commands/fetchers'
Signed-off-by: Kumar Gala <galak@kernel.org>
This patch introduces the basic infrastructure to list and fetch binary
blobs. This includes:
- The new 'blobs' extension command
- An implementation of the `west blobs list` command
with custom formatting
- A very simple mechanism for loading fetchers
- A basic implementation of an HTTP fetcher
In order to ensure consistency among the west extension commands in the
main zephyr tree, we reuse a similar class factory pattern that is present
for ZephyrBinaryRunner instances in the ZephyrBlobFetcher case. This
could be achieved with a simpler mechanism, but opted for consistency
before simplicity.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
This is the initial commit with system build, sysbuild.
Using CMake as infrastructure together with the Zephyr sysbuild allows
us to support a convenient way of building a sample and allow for extra
images to be built as part of a larger system.
It uses Kconfig for configuration of image builds.
This allows for future extension with additional build images.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Add Marcin Szkudlinski to codeowners
Add Adrian Bonislawski to codeowners
Signed-off-by: Marcin Szkudlinski <marcin.szkudlinski@intel.com>
Signed-off-by: Adrian Bonislawski <adrian.bonislawski@intel.com>
Move scripts needed by the build system and not designed to be run
individually or standalone into the build subfolder.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Move scripts needed by the build system and not designed to be run
individually or standalone into the build subfolder.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Move scripts needed by the build system and not designed to be run
individually or standalone into the build subfolder.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Move scripts needed by the build system and not designed to be run
individually or standalone into the build subfolder.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Move scripts needed by the build system and not designed to be run
individually or standalone into the build subfolder.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Move scripts needed by the build system and not designed to be run
individually or standalone into the build subfolder.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Move scripts needed by the build system and not designed to be run
individually or standalone into the build subfolder.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Move scripts needed by the build system and not designed to be run
individually or standalone into the build subfolder.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Move scripts needed by the build system and not designed to be run
individually or standalone into the build subfolder.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
This adds basic support for the watchdog timer on the RP2040 MCU and
Raspberry Pi Pico development board
Signed-off-by: Jamie McCrae <spam@helper3000.net>
Add entries for w1 doc, api, drivers, and tests in the CODEOWNERS as well
as the MAINTAINERS file.
Signed-off-by: Thomas Stranger <thomas.stranger@outlook.com>
Updates the API and types to match updated I2C terminology. Replaces master
with controller and slave with target.
Updates all drivers to match the changed macros, types, and API signatures.
Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
A DMA friendly Stream API for zephyr. Based on ideas from io_uring
and iio, a queue based API for I/O operations.
Provides a pair of fixed length ringbuffer backed queues for submitting
I/O requests and recieving I/O completions. The requests may be chained
together to ensure the next operation does not start until the current
one is complete.
Requests target an abstract rtio_iodev which is expected to wrap all
the hardware particulars of how to perform the operation. For example
with a SPI bus device, a description of what a read, and write mean
can be decided by the iodev wrapping a particular device
hanging off of a SPI controller.
The queue pair are submitted to an executor which may be a simple
inplace looping executor done in the callers execution context
(thread/stack) but other executors are expected. A threadpool executor
might for example allow for concurrent request chains to execute in
parallel. A DMA executor, in conjunction with DMA aware iodevs
would allow for hardware offloading of operations going so far as to
schedule with priority using hardware arbitration.
Both the iodev and executor are definable by a particular
SoC, meaning they can work in conjuction to perform IO operations
using a particular DMA controller or methodology if desired.
The application decides entirely how large the queues are, where
the buffers to read/write come from (some executors
may have particular demands!), and which executor to submit
requests to.
Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
This commit rewrite renesas R-Car clock driver in order
to be able to support any new SoC easier.
This work is so creating a clock driver per soc alongside a
common driver for all reneasas r-car boars.
- drivers: create a driver per soc
- create a common driver
- create a common header used by soc & common driver
- create a soc specific driver calling for common driver
- dts: use new compatible
- use old yaml as common yaml
- create a new "child" yaml to define the new compatible field
- change compatible in device tree
As in Linux, the driver can support both r8a77951 and r8a77950
SoC's so we decided to name the new driver as in Linux with Zephyr
prefix : "clock_control_r8a7795_cpg_mssr.c".
Signed-off-by: Aymeric Aillet <aymeric.aillet@iot.bzh>
This is to update the CODEOWNERS file and to add owner
for these two directories
1) /soc/arm64/intel_socfpga
2) /dts/arm64/intel/*intel_socfpga*
Signed-off-by: Boon Khai Ng <boon.khai.ng@intel.com>
This code has gone unmaintained and bugs continue to be reported
against it. We do not have the resources as a project to maintain this
in "odd fixes" mode, and nobody has stepped up to maintain it [1], so
sadly this must be removed for now.
If anyone would like to see civetweb supported in upstream Zephyr
again, they are welcome to add it back, as long as they promise to
maintain it going forward.
Many thanks to everyone who has contributed to civetweb support in
Zephyr while it was here. So long and thanks for all the fish.
Fixes: #45807Fixes: #43910Fixes: #34226Fixes: #46743
[1] https://lists.zephyrproject.org/g/devel/message/8466
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This includes a basic driver for built-in flash on the Texas Intruments
SimpleLink CC13xx/CC26xx SoC series.
The driver makes use of driverlib HAL from TI's SDK and was tested on
two LaunchXL development boards with CC1352R and CC2652R SoCs:
- CC1352R1 LaunchXL
- CC26x2R1 LaunchXL
Tests were done using:
- flash shell sample (samples/drivers/flash_shell)
- littlefs filesystem sample (samples/subsys/fs/littlefs)*
- MCUboot (bootloader/mcuboot/boot/zephyr)*
* additional changes in DTS for the boards were required (partitions
table) and are not part of this changeset (will be introduced later)
Some additional information about the implementation:
1. TI's Technical Reference Manual for CC13x2 and CC26x2 points out that
"An individual 64-bit word can be programmed to change bits 1 to 0"
but it seems this 'alignment' requirement is handled internally by
the ROM function and thus 'write-block-size' is set to 1.
2. Interrupts, VIMS and line buffers are disabled during flash content
update (write or erase) and restored afterwards as recommended by TI.
3. Only RAM to flash write is supported (source of data to be written to
flash can't point to flash).
4. The driver doesn't take care of flash sector protection disable as
that functionality is handled by CCFG. Write or erase requests which
refer to a protected area will fail.
Signed-off-by: Piotr Dymacz <pepe2k@gmail.com>
Pinmux is depricated (see #39740) and shouldn't be used anymore
Signed-off-by: Evgeniy Paltsev <PaltsevEvgeniy@gmail.com>
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
