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>
The recommended config for upstream kernels (arm64
defconfig) on the Radxa "mainline" kernel Wiki
does not include GPIO sysfs support, so libmraa
applications and utilies don't work out of the
box. This change marks the board as supporting the
GPIO character device interface and fixes the
group and line number assignments such that it
actually works. Performance is also noticeably
better with the chardev path.
I tested this by using mraa-gpio to toggle various
pins on the 40-pin header with a multimeter
attached, and with a program I have that that
toggles 8 GPIO pins at the same time to upload
data to another system using a parallel protocol.
On upstream/mainline kernels, chardev support is
now used. On the older 4.4 kernels from Radxa,
chardev support is not available and libmraa
gracefully falls back to sysfs.
Note another significant difference compared to
the Radxa kernels in upstream kernels is the
default devicetree must be tweaked to disable the
'i2s1' device in order to use GPIO pins 12, 35,
36, 38, and 40 via libmraa. For example, I
appended the following section:
&i2s1 {
status = "disabled";
};
to arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b.dts
to accomplish this.
Signed-off-by: James Jones <linux@theinnocuous.com>
e.g.:
cv2 import at the beginning throws the error:
import cv2
import mraa
import time
...
Error:
ValueError: Error initialising PWM on pin
Signed-off-by: Brian Lee <brian@vamrs.com>
This fixes the problem of detecting if pins 74-77 are available for gpio/spi use. These pins were sown to be used by the emmc, but actually used by the sound pcm. If the sound PCM is disabled and the emmc is enabled the pinse can now be used. mraa-gpio list output Pins 74-77
73 GPIO115: GPIO
74 GPIO113: GPIO SPI
75 GPIO111: GPIO SPI
76 GPIO112: GPIO SPI
77 GPIO110: GPIO SPI
to build:
1. clone repo
2. sudo apt-get install build-essential python-dev cmake automake libpcre3 libpcre3-dev byacc flex swig3.0
3. cd mraa, mkdir build, cd build
4. cmake -D CMAKE_INSTALL_PREFIX=/usr ..
5. make
6. sudo make install
This has been verified to work on BBGW, and BBBW with 9.0-9.5 with emmc enabled and PCM aduio turned off. It is so nice to have control of these pins when running with out an SD card.
Closes#953
Signed-off-by: Chuck Duey <cduey@msn.com>
Signed-off-by: Thomas Ingleby <thomas.ingleby@intel.com>
Add onboard LED support for Dragonboard410c. There are 4 user LEDs and
two LEDs for BT and WLAN.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
On Dragonboard410c, configure SPI0_CS pin as GPIO for enabling the
user to control it without adding chip select property in Devicetree.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
This commit adds Ultra96, one of the Consumer Edition boards of the
96Boards family.
Ultra96 is an Arm-based, Xilinx Zynq UltraScale+ MPSoC development board.
This board runs petalinux distribution on the ARM core and integrates
Xilinx programmable logic (PL) UltraScale architecture in a single fabric.
This board supports standard peripherals defined by 96Boards CE
Specification. Since it ships with >4.8 kernel, only chardev mapping
is supported for accessing GPIO.
More information about this board can be found in 96Boards product
page: https://www.96boards.org/product/ultra96/
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
This commit cleans up the 96boards board support by sorting the boards
in alphabetical manner and also executing clang-format for 96boards.c
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Add support for Hikey960 board from HiSilicon based on their Kirin960 SoC.
Peripherals supported:
1. GPIO
2. UART
3. I2C
For GPIO only Chardev interface has been added since this board only supports
>=4.15 kernel and using legacy sysfs interface is highly discouraged.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: malikabhi05 <abhishek.malik@intel.com>
Move the chardev enablement inside the platform check.
Some boards might not have the chardev mapping yet.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: malikabhi05 <abhishek.malik@intel.com>
As of now both Dragonboard410c and Hikey boards run latest LTS kernel.
Hence, adding chardev support for those.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: malikabhi05 <abhishek.malik@intel.com>
The Pi doesn't have userspace level PWM support, but you can mmap the
raw registers and configure it that way, which is what this patch is
doing. Tested with Raspberry Pi 3 B. I am able to set the duty cycle,
change the frequency, and set the pulse width. Signals verified with
logic analyzer. Note that the only accessible pwm is on GPIO18, which is
also used by the audio subsystem.
Signed-off-by: Nick Crast <nicholas.crast@anaren.com>
Signed-off-by: Brendan Le Foll <brendan.le.foll@intel.com>
There were unused variables, incorrect pointer operations
and plan broken string comparison.
Now there's only one - for unused uart3_enabled in beaglebone.c,
but we want to keep it for declaration consistency.
Also fixes#757.
Signed-off-by: Alex Tereschenko <alext.mkrs@gmail.com>
Beaglebone AIO pins seem to be a little different than most boards, so
this is my attempt to work with that without impacting other boards. I
added a new flag in mraa_board_t to indicate whether or not the aio pins
are sequential. One the beaglebone, they are not. To go along with this,
I added a new device mraa_aio_dev_t, that will map each aio to a
physical pin.
In the main aio logic, if aio_non_seq is true for the board, the manual
mapping is used, otherwise the old mathematical mapping is used.
Signed-off-by: Nick Crast <nrcrast@gmail.com>
Signed-off-by: Brendan Le Foll <brendan.le.foll@intel.com>
