One limitation of the current IPM API is that it is assuming that the
hardware is only exporting one single channel through which the data can
be sent or signalling can happen.
If the hardware supports multiple channels, the IPM device must be
instantiated (possibly in the DT) several times, one for each channel to
be able to send data through multiple channels using the same hw
peripheral. Also in the current IPM API only one callback can be
registered, that means that only one driver is controlling all the
signalling happening on all the channels.
This patch is introducing a new MBOX API that is supporting
multi-channel signalling and data exachange leveraging and extending the
previous (and outdated) IPM API.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
Add missing eSPI driver interface under peripheral list.
Signed-off-by: Jose Alberto Meza <jose.a.meza.arellano@intel.com>
Co-authored-by: Gerard Marull-Paretas <gerard@teslabs.com>
This reverts commit cabbd916cf.
This is considered to be useful enough that it should be restored
as a stable Zephyr API.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
This device isn't an actual hardware driver: it's a virtual EEPROM
that stores data in an instance-specific RAM buffer, with the data
exposed on an I2C bus as a I2C follower (slave) device that can be
controlled by another device acting as a leader (master) on that same
bus.
As such it's a reasonable example of how to write an I2C follower
driver, but it's not clear that it has a real use in applications. A
Zephyr application that needs to emulate an EEPROM in a real-world
system would be unlikely to provide its data from a RAM buffer.
The sole in-tree reference is in the i2c_slave_api test, so move the
driver implementation into that test.
The Kconfig and hierarchy are being left in place until it is more
clear how this functionality should be selectable within Zephyr. The
I2C_SLAVE symbol has been converted from menuconfig to config to
eliminate a Kconfig style diagnostic.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Now there's an audio reference section move the i2s docs there
as the audio section is a better fit.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
The DS3231 is an I2C real-time clock with internal temperature
compensated oscillator, maintaining civil time to 1 s precision with
nominal 2 ppm accuracy from 0-40 Cel.
The basic functionality is exposed as a counter that is always running
at 1 Hz. Much more functionality is exposed as driver-specific API,
including the ability to translate between the time scale of the DS3231
and the time scale of the Zephyr uptime clock. This allows correlation
of events in the system clock to UTC, TAI, or whatever time scale is
used to maintain the DS3231.
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
DAC (digital to analog converter) peripheral driver with a generic API
suitable for most MCUs (only basic DAC features considered).
Signed-off-by: Martin Jäger <martin@libre.solar>
This generic video API can be used to capture/output video frames.
Once a video buffer is enqueued to a video device endpoint, device owns
the buffer and can process to capture (camera), output (disk, display),
convert (hw encoder)... User can then call dequeue to retrieve
the processed buffer (video driver ensure cache coherency).
Once dequeued, video buffer is owned by user (e.g. for frame
processing, display buffer update, write to media, etc...).
For each video-buffer, user needs allocate the associated frame buffer
via video_buffer_alloc. Buffer format is defined by video device
endpoint configuration. Video device can be controlled (e.g. contrast,
brightness, flip...) via controls.
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
This commit adds a lot more documentation to the Controller Area
Netwok API. The documentation is move to the networking section.
Signed-off-by: Alexander Wachter <alexander.wachter@student.tugraz.at>
Move guides and APIs into separate directories and cleanup naming
introducing index files rather than named section files.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
