In npcx7 series, there're 8 Pulse Width Modulator (PWM) modules and each
one support generating a single 16-bit PWM output. A 16-bit clock
prescaler (PRSCn) and a 16-bit counter (CTRn) determine the cycle time,
the minimal possible pulse width, and the duty-cycle steps.
Beside introducing pwm driver for Nuvoton NPCX series, this CL also
includes:
1. Add PWM device tree declarations.
2. Zephyr PWM api implementation.
3. Add aliases in npcx7m6fb_evb board device tree file for supporting
samples/basic/blinky_pwm application and pwm test suites
Signed-off-by: Mulin Chao <MLChao@nuvoton.com>
In npcx7 series, all of them support the Intel Enhanced Serial
Peripheral Interface (eSPI) Revision 1.0. This specification provides a
path for migrating host sub-devices via LPC to a lower pin count, higher
bandwidth bus. In addition to Host communication via the peripheral
channel, it provides virtual wires support, out-of-band communication,
and device mastering option over the Chipset SPI flash.
Becisdes introducing eSPI device in npcx7, this CL also includes:
1. Add eSPI device tree declarations.
2. Add npcx7-espi-vws-map.dtsi to present the relationship between eSPI
Virtual-Wire signals, eSPI registers, and wake-up input sources.
3. Zephyr eSPI api implementation.
4, Add OOB (Out of Band tunneled SMBus) support.
5. Add configuration files for eSPI test suites.
Signed-off-by: Mulin Chao <MLChao@nuvoton.com>
Adding myself @jenmwms and @aasthagr as codeowners for
/arch/x86/, /soc/x86/, /boards/x86/, and
/drivers/serial/*ns16550* for x86 development.
Signed-off-by: Jennifer Williams <jennifer.m.williams@intel.com>
Move the devicetree bindings for Analog-to-Digital Converters (ADCs)
from dts/bindings/iio/adc to dts/bindings/adc as Zephyr does not have
an IIO layer.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
In early Zephyr days, STM32 code base greatly benefited from the care
of a handful of people.
These days are gone and so did these few people that haven't been
contributing for at least a year now.
CODEOWNERS file is updated to reflect current status of contribution,
for the areas where the is an active contributor.
Let them be thank for these initial contributions.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
Add timing functions and APIs. This is now used with some of the tests
we have for performance and metrics and will be used whereever timing
informations are needed, for example for tracing, profiling and other
operations where timing info is critical.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Add a generic host command handler framework that allows users to
declare new host command handlers with the HOST_COMMAND_HANDLER macro
at build time. The framework will handle incoming messages from the
host command peripheral device and forwards the incoming data to the
appropriate host command handler, which is looked up by id.
The framework will also send the response from the handler back to the
host command peripheral device. The device handles sending the data on
the physical bus.
This type of host command communication is typically done on an embedded
controller for a notebook or computer. The host would be the main
application processor (aka AP, CPU, SoC).
Signed-off-by: Jett Rink <jettrink@google.com>
The host command peripheral device API abstracts how an embedded
controller sends and receives data from a host on a bus. Each bus like
eSPI, SPI, or I2C would implement their own host command peripheral
device. Each hardware device would then handle the necessary hardware
access to send and receive data over that bus.
The chosen host command peripheral device will be used by the host
command handler framework to send and receive host data correctly.
Signed-off-by: Jett Rink <jettrink@google.com>
@ulfalizer hasn't been active for several months, remove him and add
@mbolivar-nordic. We can add @ulfalizer back if he comes back to the
project.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
At present this test uses an EEPROM emulator. Reuse the same test to
also use the real Atmel AT2x driver and an AT24 emulator, via the I2C
emulation controller.
EEPROM reads and writes for eeprom1 go through the AT2x driver, which
converts them to I2C transactions, which are passed through to the
AT24 emulator for processing. This approach makes more use of 'real'
code, in this case the Atmel AT2x driver.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Signed-off-by: Simon Glass <sjg@chromium.org>
Add an emulation controller which routes I2C traffic to attached
emulators depending on the I2C address selected. This allows drivers
for I2C peripherals to be tested on systems that don't have that
peripheral attached, with the emulator handling the I2C traffic.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Create a header file and implementation for emulators. Set up a linker
list so that emulators can be found and initialised at start-up.
Emulators are used to emulate hardware devices, to support testing of
various subsystems. For example, it is possible to write an emulator
for an I2C compass such that it appears on the I2C bus and can be used
just like a real hardware device.
Emulators often implement special features for testing. For example a
compass may support returning bogus data if the I2C bus speed is too
high, or may return invalid measurements if calibration has not yet
been completed. This allows for testing that high-level code can
handle these situations correctly. Test coverage can therefore
approach 100% if all failure conditions are emulated.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Signed-off-by: Simon Glass <sjg@chromium.org>
The FaZe board can be found in the Seagate FireCuda Gaming SSD devices.
A NVMe SSD and two chips are embedded: an ASMedia ASM2364 USB-to-PCIe
bridge controller and a NXP LPC11U67 MCU. The former is handling the USB
type-C to SSD I/Os while the latter is dedicated to the LED effects. The
two chips are connected together through I2C and GPIOs.
This Zephyr port is running on the LPC11U67 MCU.
Here is a list of the devices connected to the LPC11U67 on a FaZe board:
- ASMedia ASM2364 USB-to-PCIe bridge (I2C master on port O)
- 6 RGB LEDs connected connected to a TI LP5030 LED controller
(I2C device on port 1)
- 1 white LED (SSD activity blinking)
Signed-off-by: Maxime Bittan <maxime.bittan@seagate.com>
Signed-off-by: Simon Guinot <simon.guinot@seagate.com>
This adds a very primitive coredump mechanism under subsys/debug
where during fatal error, register and memory content can be
dumped to coredump backend. One such backend utilizing log
module for output is included. Once the coredump log is converted
to a binary file, it can be used with the ELF output file as
inputs to an overly simplified implementation of a GDB server.
This GDB server can be attached via the target remote command of
GDB and will be serving register and memory content. This allows
using GDB to examine stack and memory where the fatal error
occurred.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Sort entries alphabetically and cleanup top level menu for each
subsystem. Move stats subsystem Kconfig from debug into its own Kconfig.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
