A simple GPIO, no muxing needed, no pulling supported. Therefore, reject
any mode changes that request pull up/down, ignore the others.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
This patch introuduce iot2050 platform support, it is the port from
meta-iot2050 layer.
Based on original patch by Le Jin.
Signed-off-by: Le Jin <le.jin@siemens.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Ivan Mikhaylov <ivan.mikhaylov@siemens.com>
This allows to full mux structures which still need the sysfs GPIO
numbers. In combination with mraa_find_gpio_line_by_name, this allows
for platform setup that is independent of the gpiochip probing order.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
This makes the retrieval robust against chips being reordered during
boot. The results can be used to fill out mraa_pin_t while initializing
a board.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Add mux_init_reg interface with different mux modes for GPIO, UART, SPI,
I2C, PWM, AIO.
Signed-off-by: Le Jin <le.jin@siemens.com>
Signed-off-by: Ivan Mikhaylov <ivan.mikhaylov@siemens.com>
The structure returned by readdir is may be statically allocated.
Keeping a pointer to it is broken.
The LED path is generally not a directory, it's a link to a directory.
And even if it were a directory, that would tell nothing about the
caller's access permissions.
And then there is a lot of duplication between mraa_led_init and
mraa_led_init_raw.
This addresses that all.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
UP Xtreme is based on the Intel(R) Core(TM) i3/i5/i7 Whiskey Lake SoCs.
The UP Xtreme presents one Raspberry Pi compatible HAT connector.
This implementaion supports i2c, spi, uart, adc and gpio through the
40pin HAT connector.
Gpio chardev capabilities have been disabled in this implementation. When
gpio chardev capabilities are enabled an input becomes unreadable after an
isr has been registered to the pin. See here for details:
https://github.com/intel-iot-devkit/mraa/issues/937
Tested on UP Xtreme, with UP Board Linux kernel 5.0.0
Features tested: gpio, gpio interrupts, i2c, spi, adc and uart.
Signed-off-by: Michael Campion <michael.campion@emutex.com>
This commit introduces mraa_gpio_init_by_name API for initializing
a GPIO by its line name provided by the kernel. This feature depends
on the GPIO chardev support and also the line names present in devicetree
or board files. Accessing GPIO using its line name, removes the dependency
from MRAA specific pin mapping and provides a cleaner way to access GPIOs.
This will solve the issue created by an external gpiochip probing before
the SoC's internal gpio controller and thereby making the MRAA pin mapping
wrong.
Currently, this API only supports initializing a single GPIO at a time.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
1. Add support for initializing onboard LEDs based on board definition.
Maximum LED count has been set to 12.
2. Introduce mraa_led_init_raw API for initializing LEDs based on
function name. This API can be used by platforms which doesn't have mapping
in board definition.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Updates to make the FT4222 platform extender more usable.
Previous implementation opened libft4222.so and loaded symbols as
needed. This implementation removes dynamic loading of libft4222 in
favor of creating a new shared libary which links against libft4222.so.
The dynamic loading is now done in mraa.c. One C method is exposed in
libmraa-platform-ft4222.so for finding/initializing an FT4222:
mraa_platform_t mraa_usb_platform_extender(mraa_board_t* board);
Mraa.c attempts to open this platform library and calls the
mraa_usb_platform_extender method. If an ftdi4222 is connected, the
user gets added IO from the extender. If no FT4222 device is connected,
continue as normal.
* Create a new platform library for the FT4222
* Expose only 1 C method from the library -
mraa_usb_platform_extender
* libmraa-platform-ft4222.so contains CXX code (as well as previous
C code). All *allocs have been removed in favor of global
C++ stl containers.
* Previously, the FT4222 would only initialize correctly if 2 ftdi
devices existed. Now, initialize FT4222 devices based on the
device id.
* Many fixes for various problems with the FT4222
* Added unit test for platform extender (minimal functionality w/o hw)
* Updated to FindFtd4222.cmake module to handle standard arguments
* Removed CMAKE_C_FLAGS addition of -DFTDID2XX and -DFTDI4222 since
these are NOT used anywhere in source.
* Building the FTDI4222 shim requires libft4222.h which requires
ftd2xx.h. Updated CMakeLists.txt to require both when building
the shim.
Signed-off-by: Noel Eck <noel.eck@intel.com>
Went a bit too far with the previous commit. Added pointer to pointer
back to mraa_find_uart_bus_pci.
Tested leaks against valgrind and verified dev_path gets set with gdb.
Signed-off-by: Noel Eck <noel.eck@intel.com>
Unfortunately the device_path char* is dynamically allocated
and #defined and const char *'ed depending on how each platform provided the
uart device paths which makes cleaning it up more complicated.
Added a check for the IEI_TANK.
Removed the char** (in favor of a char*) for mraa_find_uart_bus_pci.)
Signed-off-by: Noel Eck <noel.eck@intel.com>
Remove some _multiple functions and replace with generic function that
does both. Some general cleanup and will move more interrnal mraa
functions to use the _mraa prefix
Signed-off-by: Brendan Le Foll <brendan.le.foll@intel.com>
This patch adds support for using on board LED through sysfs.
Commonly available LED parameters are supported.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Brendan Le Foll <brendan.le.foll@intel.com>
This commit adds a MRAA platform for the UP Squared board, EVT3 revision.
It handles the relevant FPGA configuration updates when using MRAA to
change pin modes or toggle GPIO directions.
Signed-off-by: Javier Arteaga <javier@emutex.com>
Signed-off-by: Nicola Lunghi <nicola.lunghi@emutex.com>
Signed-off-by: Brendan Le Foll <brendan.le.foll@intel.com>
