Simplify driver implementation by using spi_dt_spec. Most internal
functions now take a device reference to simplify the operation, since
config did not exist before.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The device already has a DT compatible (and uses DT properties).
Instantiate the device using the DT-based macros and remove hardcoded
name.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Simplify driver implementation by using spi_dt_spec. Note that driver
has 2 SPI configurations, identical except the speed. For this reason,
the slow config is still kept in RAM and copied from the one obtained
via the SPI dt_spec macros. A better solution would be to have macros
that allow to override the SPI frequency, but this can be improved
later. Most internal helpers have been adjusted to accept a device
reference to make SPI (and future GPIO) transition easier.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Controller device can be obtained at compile time, so make
implementation more efficient thanks to that.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Controller device can be obtained at compile time, so make
implementation more efficient thanks to that.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The controller device instance can be obtained at compile time using
DEVICE_DT_GET, so do that.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Use DEVICE_DT_GET instead of device_get_binding, since the device
reference can be obtained at compile time.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The PCIe device can be obtained at compile time, so make code more
efficient thanks to that.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Simplify driver implementation by using gpio_dt_spec. To simplify
migration, all internal functions now take a device reference instead of
device data. As a result, the redundant config pointer in data has been
removed.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Simplify driver implementation by using gpio_dt_spec. As a result, the
driver data structure has become unused and so removed.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Simplify driver implementation by using gpio_dt_spec. Note that as a
result, the driver data structure has become obsolete/unused and so has
been entirely removed.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Simplify the driver implementation by using gpio_dt_spec. Note that most
internal functions have been changed to accept a device instance instead
of data/config references to make transition easier and to align with
most other drivers.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
An optional reference to the temperature sensor can be obtained at
compile time, update implementation.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The device configuration field access was dropping const qualifier for
no reason, don't do that.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Use struct i2c_dt_spec to simplify code. This change also allows to drop
device_get_binding usage.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The bus device can be obtained at compile time, so use DEVICE_DT_GET
instead. Device configuration is now used to store the bus device
reference.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Skip kernel_timer_interrupts when CONFIG_TICKLESS_KERNEL
is disabled, because timer won't generate interrupts
anymore after invoking irq_disable and irq_enable
to enable timer interrupt again in TICK mode.
Signed-off-by: Chen Peng1 <peng1.chen@intel.com>
The select uart instance used in uart driver initialization won't
work as expected because the index used was not correct. This
fixes the macro call to use proper index value.
Signed-off-by: Sylvio Alves <sylvio.alves@espressif.com>
As a complement of 7689abee34,
which fixed an issue where gpio number could errouneously be
set to a number greater than 32 in DTS, there is also another
situation where driver instance can be configured with a pin number
greater than 32.
This PR adds another check in GPIO driver to confirm
whether the PIN number is within valid bounds.
Signed-off-by: Sylvio Alves <sylvio.alves@espressif.com>
Some emulation definition might be defined out of tree. Do not try to
include them here, instead they will be included in the module tree
defining them.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Add tests checking that:
- invalid beacons are dropped and do not affect beacon interval;
- valid beacons with old Net Keys are either processed or dropped
depending on the Key Refresh phase;
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
Add a very simple test of the CONFIG_IRQ_OFFSET_NESTED feature that
exercises nested interrupts in a portable way. It calls irq_offset()
from within a k_timer callback and validates that the return lands
back in the original interrupt successfully.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The x86 and xtensa implementations of irq_offload() invoke synchronous
interrupts on the local CPU, and are therefore safe to use from within
an interrupt context. This is a cheap and portable way to exercise
nested interrupts, which are otherwise highly platform-dependent to
test. Add a kconfig to signal the capability.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The Xtensa implementation of arch_irq_offload() required that the user
select the correct interrupt manually, and would race with itself if
invoked from separate CPUs (it was saved here by the main
irq_offload() function which has a semaphore to serialize access).
Use the new gen_zsr.py script to automatically detect the highest
available software interrupt, and keep a per-CPU set of
callback/parameter pointers.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Use index zero, not one. The Xtensa tools emit the timers in priority
order, and as mentioned in the kconfig warnings using high priority
timers doesn't work. This also makes room for using software
interrupts that can preempt a timer interrupt for test purposes.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The nRF5340dk is shipping an external QSPI flash that can be used to do
XIP from. Extend the code_relocation nocopy sample to support this
platform so that part of the functions are executed from internal flash
and others from external flash.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
* Use case of interest:
Some platforms are shipping in parallel to the internal FLASH some other
storage / external FLASH (usually a QSPI FLASH) that can be used to
execute (XIP) code from.
The content of this external FLASH can usually be written at flash time
using proper tools (see for example the case of the external FLASH on
the nRF5340DK that can be written at flash time using nrfjprog).
The external FLASH is a nice addition that is extremely useful when a
large application code doesn't entirely fit on the internal FLASH so
that we could want to move part of it in the auxiliary FLASH to XIP the
code from there.
* The problem:
Right now Zephyr doesn't have a formal and generic way to move at build
time part of the code to a different memory region.
* The current status:
Zephyr is indeed shipping a code_relocation feature but that doesn't
entirely match our needs.
When XIP is enabled, the code_relocation feature is used in Zephyr to
move the selected code (that is to copy text section, to initialize data
and zero bss) from FLASH to SRAM at run time and execute code from SRAM.
The relocation is done by a generated snippet of code that is
memcpy()-ing the right content to the destination region also using some
build-time generated portions of linker script to retrieve start and
destination addresses and regions.
* This patch:
This patch is leveraging the code_relocation code and adding a NOCOPY
feature. This feature is using the code_relocation feature to
dynamically build the linker script snippets but entirely skipping the
run-time code relocation so that the code can be XIP-ed from the
destination region.
* Example:
Let's say that we have a big file called `huge_file.c` that we want to
XIP from the external FLASH that is mapped in an EXTFLASH region.
In this case we should enable `CONFIG_XIP` and
`CONFIG_CODE_DATA_RELOCATION` and instruct cmake as follows:
zephyr_code_relocate(src/huge_file.c EXTFLASH_TEXT NOCOPY)
zephyr_code_relocate(src/huge_file.c SRAM_DATA)
this means that:
- The .text section of the `huge_file.c` must reside in the EXTFLASH
memory region and we do not need to copy the section there because we
are going to XIP it (and we assume that the file is going to be placed
in the external FLASH at flash time).
- The .data section of the `huge_file.c` must still reside in the SRAM
memory region.
* TODOs:
It's desirable to have the possibility to relocate libraries and
pre-build files instead of source code files.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
Do not used generated macro from devicetree subsys directly
in driver.
Remove definition of it's own "FOREACH_STATUS_OKAY".
Redefine "DT_DRV_COMPAT" for each supported compatible string.
Signed-off-by: Aymeric Aillet <aymeric.aillet@iot.bzh>
