Add a custom driver that takes care of loading and launching RISC-V VPR
cores found on the new nRF54 SoCs.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
Turning on clock via clock controller and
resetting PIO device via reset controller on initializing.
Signed-off-by: TOKITA Hiroshi <tokita.hiroshi@gmail.com>
The Device Multiplexer (devmux) is a pseudo-device that can
be used to select between multiple included sub-devices.
It is experimental, but its current use is in system
remediation. Take for example, the scenario where the
system console and log subsystem both have the uart backend
enabled. The case may arise, where the chosen backing uart
could be an abstraction of another very high-bandwidth bus
- such as a PCIe BAR, a UDP socket, or even even just memory.
If the "service" (for lack of a better term) that backs this
abstract "uart" experiences an error, it is of critical
importance to be able to switch the system console, uart log
backend, or whatever to another uart (semi-transparently) in
order to bring up a shell, continue to view system logs, or
even just support user console I/O.
Signed-off-by: Christopher Friedt <cfriedt@meta.com>
This enables and declares interrupt handlers for eMIOS,
the handlers defined and implemented at HAL, the driver
takes the name for each id from interrupt-names devicetree
Signed-off-by: Dat Nguyen Duy <dat.nguyenduy@nxp.com>
A file just named `init.c` is not that descriptive inside of a project
that has a lot of files of already. Rename to `ethos_u.c`.
Signed-off-by: Ryan McClelland <ryanmcclelland@meta.com>
The Ethos-U driver was using IRQ_DIRECT_CONNECT. This is not what the
driver needs as this will not detect a context switch when coming out
of the isr, and this is needed as the isr will release a semaphore.
Signed-off-by: Ryan McClelland <ryanmcclelland@meta.com>
There's no need to use APPLICATION level. Also create a custom init
level that runs late in the process (depends e.g. on SPI which runs at
high priority level, 70).
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
This PR adds a misc driver for NXP S32 eMIOS peripheral.
eMIOS provides multiple unified channels (UCs), there are
several channels can be used as reference timebase
(master bus) for other channels. At this time, the
driver does initialize global configuration for eMIOS
Signed-off-by: Dat Nguyen Duy <dat.nguyenduy@nxp.com>
Added a generic driver for RaspberryPi Pico PIO.
This driver is an intermediate driver for abstracting the PIO
device driver from physical pin configuration.
Signed-off-by: TOKITA Hiroshi <tokita.hiroshi@fujitsu.com>
Signed-off-by: Yonatan Schachter <yonatan.schachter@gmail.com>
Signed-off-by: Ionut Catalin Pavel <iocapa@iocapa.com>
`spi_is_ready` function is being deprecated in favor of
`spi_is_ready_dt` so let's replace the old usage in the tree.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
Add a driver for the Arm Ethos-U NPU, including a Devicetree entry for
the mps3_an547 platform.
Signed-off-by: Kristofer Jonsson <kristofer.jonsson@arm.com>
Signed-off-by: Fredrik Knutsson <fredrik.knutsson@arm.com>
As of today <zephyr/zephyr.h> is 100% equivalent to <zephyr/kernel.h>.
This patch proposes to then include <zephyr/kernel.h> instead of
<zephyr/zephyr.h> since it is more clear that you are including the
Kernel APIs and (probably) nothing else. <zephyr/zephyr.h> sounds like a
catch-all header that may be confusing. Most applications need to
include a bunch of other things to compile, e.g. driver headers or
subsystem headers like BT, logging, etc.
The idea of a catch-all header in Zephyr is probably not feasible
anyway. Reason is that Zephyr is not a library, like it could be for
example `libpython`. Zephyr provides many utilities nowadays: a kernel,
drivers, subsystems, etc and things will likely grow. A catch-all header
would be massive, difficult to keep up-to-date. It is also likely that
an application will only build a small subset. Note that subsystem-level
headers may use a catch-all approach to make things easier, though.
NOTE: This patch is **NOT** removing the header, just removing its usage
in-tree. I'd advocate for its deprecation (add a #warning on it), but I
understand many people will have concerns.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
* Utilize DT_HAS_<COMPAT>_ENABLED for devicetree based drivers
* Move to using 'select SPI' instead of 'depends on'
(see commit df81fef944 for
more details)
Signed-off-by: Kumar Gala <galak@kernel.org>
In order to bring consistency in-tree, migrate all drivers to the new
prefix <zephyr/...>. Note that the conversion has been scripted, refer
to #45388 for more details.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
According to Kconfig guidelines, boolean prompts must not start with
"Enable...". The following command has been used to automate the changes
in this patch:
sed -i "s/bool \"[Ee]nables\? \(\w\)/bool \"\U\1/g" **/Kconfig*
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The driver was re-using the display log level, however, it is no longer
part of the display driver category.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
- Cleanup list of includes
- Remove unused structs/definitions
- Make init function static (is called by system init)
- Make config/data naming and access consistent
- Remove redundant zero initialization of data
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The driver is sleeping in milliseconds using a custom wrapper around
k_busy_wait, move to k_sleep.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Modernize the driver a little bit by using i2c_dt_spec. Note that the
RGB on its own is another I2C device connected to the same bus. Ideally,
both should be defined in Devicetree, but this has not been done for
now.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The driver was never migrated to Devicetree, this patch converts the
driver to a proper Devicetree based device.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The driver does not implement a display API, it has a custom API. Having
it under display is confusing, since display API consumers may expect
they can use it. These sort of custom drivers fit better under
drivers/misc.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Some drivers explicitely casted data/config from void * to the
corresponding type. However, this is unnecessary and, in many drivers it
has been misused to drop const qualifier (refer to previous commits).
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
This patch includes initial support for FT800 display driver.
It includes basic features. It can be easily extended with more
FT800 display list and co-processor features.
Signed-off-by: Hubert Miś <hubert.mis@gmail.com>
