controlling pinctrl GPIOs from userspace on x86

controlling pinctrl GPIOs from userspace on x86

[Gerd v. Egidy]

Hi,

I have a x86 mainboard with a Intel Sunrise Point chipset. One function I want 
to control is tied to a specific GPIO on the chipset (GPP_E1 / SATAXPCIE_1). 
There seems to be a driver for this in the kernel: 
pinctrl/intel/pinctrl-sunrisepoint.c

The easiest solution for me would be if I could control this GPIO from 
userspace. 

I have seen examples where a pin from pinctrl is made available to the "gpio" 
driver with a devicetree setting on arm devices. But I have a x86 system with 
a classic BIOS, so no devicetree here to help me.

I have seen that there is pinconf which should give some info and control over 
pinctrl through debugfs, correct?. So I enabled CONFIG_PINCONF, but after 
loading the pinctrl-sunrisepoint module I could not see anything relating to 
this show up in /sys/kernel/debug.

Do I need to manually register the driver with the device somehow? I have 
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/INT345D:00 which seems to be 
what the driver is looking for.

Am I missing something?

Or is pinconf not going to help me? What to use instead?

Thanks.

Kind regards,

Gerd

Re: controlling pinctrl GPIOs from userspace on x86

[Linus Walleij]

On Tue, Dec 6, 2016 at 11:34 PM, Gerd v. Egidy <lists@egidy.de> wrote:

> I have a x86 mainboard with a Intel Sunrise Point chipset.

I think you should address Mika Westerberg, he know all stuff Intel GPIO.

> One function I want
> to control is tied to a specific GPIO on the chipset (GPP_E1 / SATAXPCIE_1).
> There seems to be a driver for this in the kernel:
> pinctrl/intel/pinctrl-sunrisepoint.c
>
> The easiest solution for me would be if I could control this GPIO from
> userspace.

- What kernel version are you running?

- Have you tried compiling tools/gpio/* and running "lsgpio"?
  https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/tools/gpio

> I have seen examples where a pin from pinctrl is made available to the "gpio"
> driver with a devicetree setting on arm devices. But I have a x86 system with
> a classic BIOS, so no devicetree here to help me.

Pin control per se is not available from userspace, only GPIO.
We only expose GPIO lines to userspace from the GPIO
subsystem.

That said, GPIO can use pin control as a back-end and pin control
drivers are often "dual devices" registering both pin control and GPIO.

> I have seen that there is pinconf which should give some info and control over
> pinctrl through debugfs, correct?.

Nope. debugfs is for debugging, development, not for proper use.
We always thought the name "debugfs" would strike a chord :D

Use the GPIO character device as exemplified with tools/gpio/*

> So I enabled CONFIG_PINCONF, but after
> loading the pinctrl-sunrisepoint module I could not see anything relating to
> this show up in /sys/kernel/debug.

That is probably because you need to:

- Enable CONFIG_DEBUGFS
- mount debugfs on /sys/kernel/debug

Yours,
Linus Walleij

Re: controlling pinctrl GPIOs from userspace on x86

[Gerd v. Egidy]

Hi Linus,

thank you for answering after such a long time.

> - What kernel version are you running?

I tried it with a 4.8.12 which was reasonably current when I tried it in 
december.

> - Have you tried compiling tools/gpio/* and running "lsgpio"?

nope.

> That said, GPIO can use pin control as a back-end and pin control
> drivers are often "dual devices" registering both pin control and GPIO.

The pinctrl-sunrisepoint driver does not seem to be such a dual device.

What other ways instead of a dual device driver are there to expose pin 
control pins through the GPIO subsystem?

Is there some kind of translation driver which takes a pinctrl pin with some 
extra information (like push-pull vs. open drain etc.) and creates a user 
accessible entry in the gpio subsystem from it?

If not, wouldn't it make sense to have such a thing?

> Nope. debugfs is for debugging, development, not for proper use.
> We always thought the name "debugfs" would strike a chord :D
> 
> Use the GPIO character device as exemplified with tools/gpio/*

But that just works with stuff exposed by the gpio subsystem, not pure pinctrl, 
correct?

> > So I enabled CONFIG_PINCONF, but after
> > loading the pinctrl-sunrisepoint module I could not see anything relating
> > to this show up in /sys/kernel/debug.
> 
> That is probably because you need to:
> 
> - Enable CONFIG_DEBUGFS
> - mount debugfs on /sys/kernel/debug

those were enabled & mounted. The rest of debugfs was available.

I dug a bit deeper in the source and to me it seemed like the pinctrl-
sunrisepoint module expects that there is a matching device entry in the ACPI 
table presented by the BIOS. I added a printk to spt_pinctrl_probe() and it 
was never called.

I have no control over the BIOS and the ACPI tables it presents. I know I 
could completely replace them, but this is a bit more involved.

According to the datasheet of the sunrisepoint chipset, you can't access the 
gpio resources of the chipset directly, but have to do that through the P2SB 
sideband interface. Other affected drivers, e.g. i2c-i801.c have code to handle 
that. I do not see anything like that in the pinctrl-sunrisepoint driver. I 
don't know how this is supposed to work. I guess that you need some help from 
the BIOS to make it work.

Mika, could you explain how this was designed to be used?

Kind regards,

Gerd

Re: controlling pinctrl GPIOs from userspace on x86

[Mika Westerberg]

On Wed, Jan 25, 2017 at 12:25:20AM +0100, Gerd v. Egidy wrote:
> Hi Linus,
> 
> thank you for answering after such a long time.
> 
> > - What kernel version are you running?
> 
> I tried it with a 4.8.12 which was reasonably current when I tried it in 
> december.
> 
> > - Have you tried compiling tools/gpio/* and running "lsgpio"?
> 
> nope.
> 
> > That said, GPIO can use pin control as a back-end and pin control
> > drivers are often "dual devices" registering both pin control and GPIO.
> 
> The pinctrl-sunrisepoint driver does not seem to be such a dual device.

It does actually.

> What other ways instead of a dual device driver are there to expose pin 
> control pins through the GPIO subsystem?
> 
> Is there some kind of translation driver which takes a pinctrl pin with some 
> extra information (like push-pull vs. open drain etc.) and creates a user 
> accessible entry in the gpio subsystem from it?
> 
> If not, wouldn't it make sense to have such a thing?

So you can use the older sysfs ABI also to access the pin:

# grep SATAXPCIE_1 /sys/kernel/debug/pinctrl/INT344B\:00/pins                 
pin 97 (SATAXPCIE_1) mode 1 0x44000700 0x00000019

# cat /sys/kernel/debug/pinctrl/INT344B\:00/gpio-ranges 
GPIO ranges handled:
0: INT344B:00 GPIOS [360 - 511] PINS [0 - 151]

# echo $((360+97)) > /sys/class/gpio/export 
[   86.778304] sunrisepoint-pinctrl INT344B:00: request pin 97 (SATAXPCIE_1) for INT344B:00:457

This will change the pin SATAXPCIE_1 to a GPIO and makes it accessible
from userspace via /sys/class/gpio/gpio457/*.

Note you should really know what you are doing if you are going to
toggle random GPIOS.