SAMA5D27 SOM1 Linux GPIO Pin Allocation Issue

This forum is for users of Microchip MPUs and who are interested in using Linux OS.

Moderator: nferre

rtmistler
Posts: 2
Joined: Fri Jun 15, 2018 6:15 pm

SAMA5D27 SOM1 Linux GPIO Pin Allocation Issue

Fri Jun 15, 2018 6:44 pm

Hi,

I've been using buildroot and the AT91 bootstrap.

Version of Linux I have is: Linux buildroot 4.9.87-linux4sam_5.8

We started with the SAMA5D27 SOM1 EK common files. We also mimicked the SOM1 EK design to make our carrier board. We put LEDs on PA10 and PB01 where on the SOM1 EK there also are LEDS. We however cannot access the /sys/class/gpio export for those file.

As an example, we have mapped GPIO pins for I/O using other various pins successfully where we can export: PA9, PB23, PB26, PC13-PC17, PC23-PC26, and PD8. And we can export, and then control or read the pins accordingly.

When we go to export pins 10 (PA10) or 33 (PB01) we receive a complaint that these pins are in use. When we mount the kernel debug fs and look at the usage of the GPIO pins, we do see that the pins are in use, but by "?", some unknown item.

We did nothing special with the device tree blob file for the AT91 bootstrap.

Next, searching the build/linux-linux4sam_5.8/ tree files for the string PA10 I found a dtsi example containing a leds section:

Code: Select all

	leds {
		compatible = "gpio-leds";
		pinctrl-names = "default";
		pinctrl-0 = <&pinctrl_led_gpio_default>;
		/* status = "okay"; Conflict with pwm0. */

		red {
			label = "red";
			gpios = <&pioA PIN_PA10 GPIO_ACTIVE_LOW>;
		};

		green {
			label = "green";
			gpios = <&pioA PIN_PB1 GPIO_ACTIVE_LOW>;
		};

	};
While this allows me to set the pins to be LOW or HIGH if I change the ACTIVE_xxx term from one to the other, I still cannot export the pins and control them using a program, which I need to do.

I commented out the status = okay line because it said something about PWM, and yes I will agree that PA10 can be multi purpose.

I do feel that each of these multi purpose pins is currently working on one of their multiple other purposes but do not know where to look to disable that functionality.

PA10 can also allocated for SDMMC0 or a timer. We are not using SDMMC0, but the devkit may do this and we need to know how to disable that capability.
PB01 can also be a PWM. We are not using a PWM and need to know how to allocate this pin for general GPIO.

Should I be addressing this using my AT91 device tree blob file, as shown above? What syntax is correct/incorrect?

Where should I be seeking to ensure that the multiple purposes of these pins are not considered active for the Linux build and that they will only be consider GPIO for userspace program control?
blue_z
Location: USA
Posts: 1690
Joined: Thu Apr 19, 2007 10:15 pm

Re: SAMA5D27 SOM1 Linux GPIO Pin Allocation Issue

Tue Jun 19, 2018 2:27 am

rtmistler wrote:We however cannot access the /sys/class/gpio export for those file.
FYI the sysfs interface of accessing GPIO has been officially deprecated beginning with kernel version 4.17.
Its replacement, the character device ABI, was introduced in version 4.8.
Regardless, control of GPIO from userspace is a bad idea.
That's not just my opinion, since the Linux kernel clearly documents this in Documentation/gpio/sysfs.txt:

Code: Select all

DO NOT ABUSE SYSFS TO CONTROL HARDWARE THAT HAS PROPER KERNEL DRIVERS.
PLEASE READ THE DOCUMENT NAMED "drivers-on-gpio.txt" IN THIS DOCUMENTATION
DIRECTORY TO AVOID REINVENTING KERNEL WHEELS IN USERSPACE. I MEAN IT.
REALLY.

Along those same lines, Linus Walleij of Linaro advises the following:

Code: Select all

The Rules of Linux Userspace GPIO

1. You do not access GPIOs from userspace
2. YOU DO NOT ACCESS GPIOS FROM USERSPACE
3. Read Documentation/gpio/drivers-on-gpio.txt
4. Use the character device

rtmistler wrote:As an example, we have mapped GPIO pins for I/O using other various pins successfully where we can export: PA9, PB23, PB26, PC13-PC17, PC23-PC26, and PD8.
How did you perform this "mapping"?

rtmistler wrote:Where should I be seeking to ensure that the multiple purposes of these pins are not considered active for the Linux build and that they will only be consider GPIO for userspace program control?
The SAMA5D2 SoC and SIP datasheets are quite clear (i.e. clearer than older Atmel/Microchip SoC datasheets) that "Each I/O line can be assigned to a peripheral or used as a general purpose I/O."
The 128 I/O pins of the SAMA5D2 SIP are versatile in that each pin can be:
A.) assigned to one of up to six possible peripheral functions (aka pin multiplexing),
OR
B.) be used as a GPIO.

Scenario A, i.e. pin multiplexing, is handled by the Linux kernel with the pinctrl (pin control) subsystem.
Pin assignment to a peripheral function is specified (for modern ARM kernels) using the Device Tree with pin-control group definitions.
Such pins are ("permanently") owned by the assigned peripheral (and its driver). (Dynamic pin-multiplexing is rare.)

Scenario B, i.e. pin as GPIO, is handled by the Linux kernel with the gpio and pinctrl subsystems.
All remaining I/O pins that have not been specified in a pin-control group become a managed resource of the gpio subsystem.
Explicit pin specification for GPIO usage by a kernel driver is specified using the Device Tree. The driver still has to acquire such a GPIO pin from the gpio subsystem.
Userspace can compete for and acquire (and then release) a GPIO just like other managed resources (such as free memory).

Regards
rtmistler
Posts: 2
Joined: Fri Jun 15, 2018 6:15 pm

Re: SAMA5D27 SOM1 Linux GPIO Pin Allocation Issue

Tue Jun 19, 2018 3:38 pm

Thanks for the pointers. Those references and the examples make things very clear.

I obviously have to do a lot of coding to re-orient how the resources are used.

Thanks!

Return to “LINUX”

Who is online

Users browsing this forum: Google [Bot] and 4 guests