add ledc to board dtsi file,
change compatible and device define in pwm driver,
add yaml for board ledc support,
fix missing include for board in gpio include
Signed-off-by: Andrei-Edward Popa <andrei_edward.popa@upb.ro>
This PR updates GPIO driver to use DTS information
regarding gpio availability.
This also fixes interrupt handling and
also removes kconfig definition for GPIO port.
A few configuration checks were also added to
improve code usage.
Signed-off-by: Sylvio Alves <sylvio.alves@espressif.com>
Change the GPIO_MMIO32_INIT to take a devicetree node since we want
to use DEVICE_DT_DEFINE. This makes it so that code using
GPIO_DT_SPEC_GET works correctly with GPIO controllers that utilize
GPIO MMIO32.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Convert driver(s) to DEVICE_DEFINE instead of DEVICE_AND_API_INIT
so we can deprecate DEVICE_AND_API_INIT in the future.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Now that device_api attribute is unmodified at runtime, as well as all
the other attributes, it is possible to switch all device driver
instance to be constant.
A coccinelle rule is used for this:
@r_const_dev_1
disable optional_qualifier
@
@@
-struct device *
+const struct device *
@r_const_dev_2
disable optional_qualifier
@
@@
-struct device * const
+const struct device *
Fixes#27399
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Let's set the api at built time, or this will create a bug once device
instance pointers become constant.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Convert older DT_INST_ macro use in esp32 drivers to the new
include/devicetree.h DT_INST macro APIs.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Add the common config structure as a prefix of the driver-specific
config structure and use the mask parameter to initialize it.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
As the mmio32 is more of a library than a proper driver, just implement
the new port functions and have pin_interrupt_configure marked pretty
much as not supported.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
move gpio.h to drivers/gpio.h and
create a shim for backward-compatibility.
No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.
Related to #16539
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Any word started with underscore followed by and uppercase letter or a
second underscore is a reserved word according with C99.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
On 'drivers/i2c_esp32.c' there are functions useful for other
drivers. Functions and struct went moved to:
* arch/xtensa/soc/esp32/peripheral.h
* arch/xtensa/soc/esp32/soc.h
* include/drivers/gpio/gpio_esp32.h
Signed-off-by: Vitor Massaru Iha <vitor@massaru.org>
Convert code to use u{8,16,32,64}_t and s{8,16,32,64}_t instead of C99
integer types. This handles the remaining includes and kernel, plus
touching up various points that we skipped because of include
dependancies. We also convert the PRI printf formatters in the arch
code over to normal formatters.
Jira: ZEP-2051
Change-Id: Iecbb12601a3ee4ea936fd7ddea37788a645b08b0
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
This is a start to move away from the C99 {u}int{8,16,32,64}_t types to
Zephyr defined u{8,16,32,64}_t and s{8,16,32,64}_t. This allows Zephyr
to define the sized types in a consistent manor across all the
architectures we support and not conflict with what various compilers
and libc might do with regards to the C99 types.
We introduce <zephyr/types.h> as part of this and have it include
<stdint.h> for now until we transition all the code away from the C99
types.
We go with u{8,16,32,64}_t and s{8,16,32,64}_t as there are some
existing variables defined u8 & u16 as well as to be consistent with
Zephyr naming conventions.
Jira: ZEP-2051
Change-Id: I451fed0623b029d65866622e478225dfab2c0ca8
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
It is envisaged that this will be used by SoC or board code to make
available fixed purpose memory-mapped i/o registers to the rest of the
system which normally expects to use GPIO devices, e.g. for driving chip
select lines, LEDs or reading button states.
As such, the driver code doesn't provide a kconfig based configuration
mechanism, instead SoC/board code can hard-wire the devices it wants
with something simple like:
GPIO_MMIO32_INIT(misc_reg1, "MISC1", 0x12345678, 0xffffffffu)
Then, for example, if bit N of the register at 0x12345678 is wired up as
an SPI device chip select line, the SPI driver could be configured to
use pin N of the "MISC1" GPIO driver and not need any other board
specific code.
Change-Id: Ib02fcbab73fcf9637e25834db060fb3108626f47
Signed-off-by: Jon Medhurst <tixy@linaro.org>
