Updated API version enables multi-instance GPIOTE driver.
Additionally obsolete symbol that was used to specify
API version in the past was removed.
Affected drivers have been adjusted and appropriate changes
in affected files have been made.
Signed-off-by: Jakub Zymelka <jakub.zymelka@nordicsemi.no>
Change introduces a new configuration option that can be used to disable
GPIO interrupt support to reduce memory footprint.
Signed-off-by: Marek Pieta <Marek.Pieta@nordicsemi.no>
Update gpio drivers to use DT_HAS_<compat>_ENABLED Kconfig symbol
to expose the driver and enable it by default based on devicetree.
We remove 'depend on' Kconfig for symbols that would be implied by
the devicetree node existing.
Signed-off-by: Kumar Gala <galak@kernel.org>
So far driver was using SENSE mechanism for all or none edge
interrupts. This was not convenient since in some modules may
require IN event to be used and other did not. Converting it to
use a mask specified in the device tree. Pins indicated in the
mask will use sensing.
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
Refactors all of the on-chip GPIO drivers to use a shared driver class
initialization priority configuration, CONFIG_GPIO_INIT_PRIORITY, to
allow configuring GPIO drivers separately from other devices. This is
similar to other driver classes like I2C and SPI.
Most drivers previously used CONFIG_KERNEL_INIT_PRIORITY_DEFAULT or
CONFIG_KERNEL_INIT_PRIORITY_DEVICE, therefore the default for this new
option is the lower of the two, which means earlier initialization.
Driver-specific options for off-chip I2C- or SPI-based GPIO drivers are
left intact because they often need to be initialized at a different
priority than on-chip GPIO drivers.
Signed-off-by: Maureen Helm <maureen.helm@intel.com>
Remove Kconfig options for enabling device instances in favor of
taking that information only from device tree. Prior to that
change there was a mix of devicetree and Kconfig.
Bring back use of CONFIG_GPIO_NRF_INIT_PRIORITY.
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
Currently level interrupts are implemented using GPIO SENSE, but edge
interrupts using GPIOTE events. Using GPIOTE events results in increased
power consumption according to product specifications and erratas of
some nRF MCUs. In case of nRF52832 it is <20uA in System ON Idle and
~400-450uA when used in conjunction with SPI or TWI.
Add a user configurable option to select between GPIOTE events and GPIO
SENSE mechanism, for implementing edge interrupts. Selecting GPIO SENSE
option will allow to reduce power consumption in scenarios mentioned by
nRF MCUs erratas.
Additionally GPIO SENSE mechanism (as opposed to GPIOTE event) allows to
detect state changes of pins configured as output.
Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
The GPIO driver uses a proprietary GPIOTE channel allocator.
This commit makes it use the allocation mechanism provided by nrfx.
Signed-off-by: Jedrzej Ciupis <jedrzej.ciupis@nordicsemi.no>
All GPIO controller drivers support DTS so we can select HAS_DTS_GPIO
at the GPIO driver subsystem level rather than for each specific driver.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Use this short header style in all Kconfig files:
# <description>
# <copyright>
# <license>
...
Also change all <description>s from
# Kconfig[.extension] - Foo-related options
to just
# Foo-related options
It's clear enough that it's about Kconfig.
The <description> cleanup was done with this command, along with some
manual cleanup (big letter at the start, etc.)
git ls-files '*Kconfig*' | \
xargs sed -i -E '1 s/#\s*Kconfig[\w.-]*\s*-\s*/# /'
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Make the following nRF peripheral drivers:
- ADC
- GPIO
- I2C
- SPI
- UART
- USB_DEVICE
enabled by default so that users do not need to explicitly enable them
in their applications after choosing an nRF SoC as the build target.
Kconfig options enabling these drivers depend on both a given hardware
feature (e.g. I2C) and an nRF family SoC selected, so effectively they
will be automatically enabled only when it is adequate (and in most
cases these drivers are the only option for a given hardware feature
on nRF SoCs).
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Jakub Zymelka