We have a number of cases that now look like:
#if DT_HAS_COMPAT(ti_lmp90077)
LMP90XXX_DEVICE(90077, 0, 16, 4);
#endif /* DT_INST_0_TI_LMP90077 */
The DT_INST_0_TI_LMP90077 comment is stale, and doesn't add much since
the #if associated with the #endif is just 2 lines up. Removing the old
comments seems the best cleanup.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Add checks to prevent SPI transactions from being run in ISR
context. This affects both the LMP90xxx ADC and GPIO drivers.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Move calibration setup SPI transaction to acquisition thread to allow
adc_read_async() to be called from ISR context.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Introduce a dedicated function for performing an entire LMP90xxx ADC
channel read and sample all channels in one go in the ADC acquisition
thread.
This removes the SPI transactions from adc_context_start_sampling()
which can be called in k_timer ISR context for consecutive ADC reads.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Since idc_read/idc_write are used outside of the driver we can't use the
DT_INST_... form (that utilize DT_DRV_COMPAT) of the macro's in
ipm_cavs_idc_priv.h. Use DT_INST(0, intel_cavs_idc) explicitly in the
header to fix the build issue.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Add counter driver for the NXP Kinetis Low Power Timer (LPTMR). The
driver can be configured either as 16 bit counter or 16 bit pulse
counter.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Convert older DT_INST_ macro use in atmel sam0 drivers to the new
include/devicetree.h DT_INST macro APIs.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
With the introduction of ZephyrConfig.cmake all parts of CMake code
should rely on the CMake ZEPHYR_BASE variable instead of the environment
setting.
This ensures that after the first CMake invocation, then all subsequent
invocation in same build folder will use same zephyr base.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Just to get something to test for PM, via frdm_k64f board. So only this
board will get PM enabled.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
By changing the various *NET_DEVICE* macros. It is up to the device
drivers to either set a proper PM function or, if not supported or PM
disabled, to use device_pm_control_nop relevantly.
All existing macro calls are updated. Since no PM support was added so
far, device_pm_control_nop is used as the default everywhere.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Convert older DT_INST_ macro use in openisa drivers to the new
include/devicetree.h DT_INST macro APIs.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Added device tree nodes and associated headers for
defined uarts on the stm32g0 and stm32g07x 8x parts.
Tested with uart on stm32g071rb disco board with usart3 going to stlink.
Using shell.
Signed-off-by: Kieran Levin <ktl@frame.work>
Convert older DT_INST_ macro use in microchip drivers to the new
include/devicetree.h DT_INST macro APIs.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Convert older DT_INST_ macro use in atmel sam drivers to the new
include/devicetree.h DT_INST macro APIs.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Convert older DT_INST_ macro use in sifive drivers to the new
include/devicetree.h DT_INST macro APIs.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Convert older DT_INST_ macro use in STM32 drivers to the new
include/devicetree.h DT_INST macro APIs.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
The primary problem was that the callback was being invoked twice,
which broke the tests.
A secondary issue is that when two level tests occur consecutively the
second will fail. Instrumentation confirms that the registers are
being configured correctly, and ip indicates that the condition was
detected, but the interrupt does not occur. Tests pass as long as no
level test precedes the failing test.
It's not clear whether this is an issue with the PLIC, or the GPIO
implementation (hardware or software). As "normal" GPIO applications
appear to work we'll run with it and keep an issue open.
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
