Add configuration, pinmux, dts and documentation for the STM32L496G
Discovery board based on the STM32L496AG SoC.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Add necessary board files, pinmux and device tree in order to have a
usable debug console.
Origin: Original
Change-Id: I280320700352fd36a544c03f4e57d2eeec2449e5
Signed-off-by: Florian Vaussard <florian.vaussard@heig-vd.ch>
This commit provides support for disco_l475_iot1 board
Pinmux driver is provided with initial support definitions
Change-Id: I17b637a8ba0b033014969eca8fffe76319c47c52
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
The k64 pinmux driver was deprecated when the more generic mcux pinmux
driver was added, but it can actually just be removed because it is not
a public interface. Applications should be using the public pinmux API,
not the private k64 pinmux API. There was one case in the net samples
that used the private API which was cleaned up in a previous patch.
Change-Id: I49a6397baa57973930cb63bd2a9883b14f7ddafd
Signed-off-by: Maureen Helm <maureen.helm@nxp.com>
Kinetis SoCs contain one or more PORT modules to handle pin muxing and
pin configuration. Unlike the existing k64 pinmux driver, this driver
handles each PORT module individually and can be used for other Kinetis
SoCs.
This driver uses KSDK CMSIS register accesses to the PORT module rather
than the KSDK PORT driver (fsl_port.h), because the Zephyr pinmux
interface contains both set() and get() functions to access the pin
configuration. The KSDK PORT driver only contains a set() function
(which is a very thin static inline function to modify the PCR
register), therefore building a shim on top of it would result in a
strange mix of using the KSDK PORT driver for the set() and a direct
CMSIS register access for the get().
Jira: ZEP-1393
Change-Id: I2f7c6b08b207350697d590dcd665223f81de9f9e
Signed-off-by: Maureen Helm <maureen.helm@nxp.com>
Add board support for the Nucleo64 L476RG development board.
Change-Id: Ibb5424bc936c67a5d96855617202136d7dea772c
Signed-off-by: Fabien Parent <fparent@baylibre.com>
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
This patch adds the support for the board pinmux initialization on
ARM V2M Beetle.
The GPIO controllers 2 and 3 are reserved and therefore neither exposed
nor configured by this driver.
Jira: ZEP-1245
Change-Id: Id5499c5dd887c319730408eeb30f02eeed1c3699
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@linaro.org>
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Add support for the STM32F401 chip on the board
Change-Id: I96c0799f3658ecea096fa5971bce9faf21919ee1
Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
Signed-off-by: Ricardo Salveti <ricardo.salveti@linaro.org>
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
The hexiwear board has a k64 SoC, so we can reuse the k64 pinmux driver
and just add a new pinmux table for the board.
Jira: ZEP-716
Change-Id: I936691b3578db298014f44fe18433d7943b431f3
Signed-off-by: Maureen Helm <maureen.helm@nxp.com>
The k64 pinmux driver can be used for any k64 board, not just frdm_k64f,
therefore renaming the driver accordingly.
Change-Id: I45e96d4a5ff6aa859d0f57fe098e44a8ae5283d1
Signed-off-by: Maureen Helm <maureen.helm@nxp.com>
Move pinmux defintions under board/<board> and have all board
configuration in one single place.
Change-Id: I055b024384fae2938881b1c57d8ce7426e732e92
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Add configuration for OLIMEXINO_STM32 board.
By default, the UART console is forwarded to USART1 available on
UEXT connector. All GPIO ports available on the connecot headers
are enabled.
Change-Id: I60b3ff20ea60b5294a3a6c31f4dba0802794f9d8
Origin: Based on nucleo_f103rb board
Signed-off-by: Yannis Damigos <giannis.damigos@gmail.com>
This moves the STM32 based boards (Nucleo F103RB and STM32 Mini A15) to
the "new" pinmux model.
Change-Id: I190df271a6b83fafeec0b281cd4ee7cf13d7e7db
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
This introduces the pinmux_dev driver for the Atmel SAM3X.
This driver implements what used to be the pinmux driver API, which
applications could use to modify the function of pins during runtime.
That functionality is now protected under the CONFIG_PINMUX_DEV option,
which should only be set during the early enabling of a new board, as
there is risk of damage to the board when misused.
Change-Id: I3aa00505d2771b53c41fe687c3e5230e804756be
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
This driver doesn't provide any API, it only initializes the pinmux
controller to appropriate values depending on the board.
The first board to use this new infrastructure is the Arduino 101 board,
because it is alphabetically the first.
To better organize code for the different SoCs and boards, a "family"
level is created in the 'drivers/pinmux' directory. The Arduino 101
board is part of the Quark MCU "family".
The PINMUX_DEV configuration (and functionality) is removed for now, it
will be added back when the pinmux_dev drivers are (re)introduced, with
clearer semantics.
Change-Id: Idf5cc3caf6be620aa50828ae8fdc535df6caf458
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Add a common driver for pin control subsystem in STM32 MCU series. The
driver allows for selection of pin's function without the ability of pin
remapping.
The driver implements a pinmux driver API, with custom `func` and `pin`
encoding in API calls. The caller is expected to use STM32PIN() helper
macro for encoding port/pin numbers or using one of the provided
STM32_PIN_* defines.
The common driver requires SoC specific support to be implemented. The
SoC code must implement these calls: stm32_get_pin_config(),
stm32_get_port_clock(), stm32_pin_configure(). Consult pinmux_stm32.h
header for detailn on semantics of these calls.
The driver also requires board level integration. The call
stm32_board_get_pinconf() is expected to privide pin function
assignments for the target board.
Whenever an IO pin is being enabled, the driver will automatically
enable the clock for corresponding port. The driver does not implement
disabling of port's clock as this has potentially disruptive, as such
such operation should be done explicitly in the code.
The pin control module needs to be initialized before any other modules,
but after clock_control. For this reason, the driver is initialized by
default at PRIMARY level, with priority set to 2. The priority can be
changed through configuration.
Change-Id: I8cb746d0f3cad72cd50b3355fe6d93a9f469be25
Origin: Original
Signed-off-by: Maciej Borzecki <maciek.borzecki@gmail.com>
K64 pinmux support is created as a normal driver.
As opposed to the Galileo board, the pin configuration options are
defined by the MCU and are not board-specific. Separate
platform/board-specific configuration code uses the pinmux driver for
the default pin settings. For FRDM-K64F, only the Arduino pins (22 of a
possible 160) are set up.
Some of the I/O pins routed to the Arduino header are also configured as
JTAG/SWD signals by default and are used by the OpenSDAv2 debug
interface. Therefore, a PRESERVE_JTAG_IO_PINS config option was created
for the FRDM-K64 platform to prevent the default pin settings from
re-configuring these pins.
The K64 MCU separates pin configuration and control, implemented in the
pinmux driver, from GPIO. This results in some cross referencing
between the K64 GPIO driver and the K64 pinmux driver due to the
dependencies of one on the other.
This pinmux driver also uses the expanded pinmux function/mode parameter
size to describe pin configuration options with bit fields for the K64,
including up to 8 pin functions, plus interrupt, pullup/down, drive
strength, open-drain and slew rate.
The following GCC warnings in the K64 pinmux driver are prevented when not
compiling with 'no-optimization' (-O0):
warning: 'gpio_dev' may be used uninitialized in this function
[-Wmaybe-uninitialized]
Change-Id: Ie5031d18750143bf895883058b3cd55fd9989fd3
Signed-off-by: Jeff Blais <jeff.blais@windriver.com>
Neil Armstrong