Under what conditions would /sys/kernel/debug/gpio be empty?

Question

Summary

My aim is to control the GPIO pins in Peppermint 4 Linux (Kernel version 3.8.0) on an Intel motherboard (NM70 chipset with C1037U processor).

I'm debugging issues I'm having using the sysfs interface and am trying to understand the conditions where /sys/kernel/debug/gpio would be empty?

When attempting to export pins 0 to 255 by

echo XX > /sys/class/gpio/export

for XX from 0 to 255, I get the following error message

echo: write error: No such device

Under what conditions would /sys/kernel/debug/gpio be empty?

 Background

• Motherboard: Intel with NM70 chipset
• Processor: C1037U processor
• OS: Peppermint 4 Linux
• Kernel version: 3.8.0
• GPIO interface: sysfs

I'm attempting to use the sysfs interface, which allows GPIO pins to be accessed from userspace through the filesystem.

I’ve successfully followed the "Alternate Build Method: The Old-Fashioned Debian Way" section of https://help.ubuntu.com/community/Kernel/Compile to recompile the kernel in order to expose GPIO access in user space and to turn on debug mode for GPIO:

Once the new kernel was compiled, I was able to see the GPIO folder in /sys/class/gpio for the first time. Then, in theory, it should be a case of being able to turn GPIO ports ON/OFF by writing to the filesystem. This approach is outlined at http://falsinsoft.blogspot.co.uk/2012/11/access-gpio-from-linux-user-space.html.

When attempting to export pins 0 to 255 by

echo XX > /sys/class/gpio/export

for XX from 0 to 255, I get the following error message

echo: write error: No such device

When attempting to export pins outside the range 0 to 255 by

echo XX > /sys/class/gpio/export

I get the following error message

echo: write error: Invalid argument

The tutorial suggests this could be because the GPIO ports are reserved for another program and that, if so, the debug file (/sys/kernel/debug/gpio) would be able to show where they are reserved.

However, /sys/kernel/debug/gpio is empty.

I can see and control the GPIO pins in the BIOS (change pins to be input or output HIGH/LOW).

Related questions

writing to /sys/class/gpio/export failing

Enable pullup GPIO

Touslesmois

I am not too certain of x86 Linux. However, the fact /sys/kernel/debug/gpio is empty, probably means that Linux thinks that you have no GPIOs. Your kernel has to support GPIOs on your hardware. – Incondensable

How would you go about checking whether your kernel supports GPIO on your hardware? (Opened new question at #24147074) – Touslesmois

Answer 1

/sys/kernel/debug/gpio will be empty if there no GPIO device registered (warning: when I say GPIO device, I don't mean the piece of hardware, but rather the kernel representation of it).

So, these GPIO devices are registered at runtime by the kernel and associated to a specific GPIO device driver.

In turn, the GPIO device driver is selected and associated to a given device, because it is the one declaring compatibility with said GPIO device.

E.g., the kernel would match on PCI vendor and product ID, and probe a GPIO driver that claims support for that PCI vendor/product. When the GPIO driver is probed, it typically registers the GPIO device instance.

Finally, that registered GPIO device is what provides GPIOs shown in /sys/kernel/debug/gpio.

The above is part of the so-called "Device Driver model" in Linux. Although it's a bit outdated, you can read [1].

Now, let's see what GPIO driver you need to select for your NM70 chipset. Wikipedia says that the chipset codename is "Panther Point-M" [2]. With some luck, the lpc_ich driver could support it. You would have to build your kernel with CONFIG_LPC_ICH=y.

Alternatively, if your GPIOs are provided by a PCI device, you could use lspci to get the IDs, and then grep in the kernel sources for those IDs.

[1] http://www.oreilly.com/openbook/linuxdrive3/book/ch14.pdf

[2] https://en.wikipedia.org/wiki/List_of_Intel_chipsets

Venireman