GPIO offsets used by userspace

GPIO offsets used by userspace

[Andrew Jeffery]

[-- Attachment #1: Type: text/plain, Size: 575 bytes --]

Hi all,

Just a heads up that when the linked patch is pulled into the OpenBMC
kernel it will break our userspace. We will need to synchronise the
kernel bump with the fixes for the machine configs to update the magic
GPIO offset number.

https://lkml.org/lkml/2017/1/26/786

The magic offset is essentially 512-(ngpios) (I don't know why, but
that's the behaviour), and this now varies between AST2400 and AST2500
systems due to the AST2500 having an extra bank, and also because the
AST2400 has a "hole" at the end of its GPIO number space.

Cheers,

Andrew

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: GPIO offsets used by userspace

[Joel Stanley]

On Mon, Jan 30, 2017 at 12:04 PM, Andrew Jeffery <andrew@aj.id.au> wrote:
> Hi all,
>
> Just a heads up that when the linked patch is pulled into the OpenBMC
> kernel it will break our userspace. We will need to synchronise the
> kernel bump with the fixes for the machine configs to update the magic
> GPIO offset number.
>
> https://lkml.org/lkml/2017/1/26/786
>
> The magic offset is essentially 512-(ngpios) (I don't know why, but
> that's the behaviour), and this now varies between AST2400 and AST2500
> systems due to the AST2500 having an extra bank, and also because the
> AST2400 has a "hole" at the end of its GPIO number space.

Can you suggest a way to detect this from userspace?

Would using the chardev api make this easier?

Cheers,

Joel

RE: GPIO offsets used by userspace

[Hergert, Nolan]

Correct me if I'm wrong, but I think the maintainers are moving away from literal gpio numbers to named descriptors ("disk_led") in the device tree, as we're moving to more dynamic hardware https://lwn.net/Articles/533632/. Linus Walleij's talk was helpful  for me too: http://elinux.org/images/9/9b/GPIO_for_Engineers_and_Makers.pdf 

Nolan

-----Original Message-----
From: openbmc [mailto:openbmc-bounces+nolan.hergert=intel.com@lists.ozlabs.org] On Behalf Of Joel Stanley
Sent: Monday, January 30, 2017 4:26 PM
To: Andrew Jeffery <andrew@aj.id.au>
Cc: OpenBMC <openbmc@lists.ozlabs.org>
Subject: Re: GPIO offsets used by userspace

On Mon, Jan 30, 2017 at 12:04 PM, Andrew Jeffery <andrew@aj.id.au> wrote:
> Hi all,
>
> Just a heads up that when the linked patch is pulled into the OpenBMC 
> kernel it will break our userspace. We will need to synchronise the 
> kernel bump with the fixes for the machine configs to update the magic 
> GPIO offset number.
>
> https://lkml.org/lkml/2017/1/26/786
>
> The magic offset is essentially 512-(ngpios) (I don't know why, but 
> that's the behaviour), and this now varies between AST2400 and AST2500 
> systems due to the AST2500 having an extra bank, and also because the
> AST2400 has a "hole" at the end of its GPIO number space.

Can you suggest a way to detect this from userspace?

Would using the chardev api make this easier?

Cheers,

Joel
_______________________________________________
openbmc mailing list
openbmc@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/openbmc

Re: GPIO offsets used by userspace

[Andrew Jeffery]

[-- Attachment #1: Type: text/plain, Size: 2284 bytes --]

Hi Nolan!

On Tue, 2017-01-31 at 00:50 +0000, Hergert, Nolan wrote:
> Correct me if I'm wrong, but I think the maintainers are moving away
> from literal gpio numbers to named descriptors ("disk_led") in the
> device tree, as we're moving to more dynamic hardware
> https://lwn.net/Articles/533632/. Linus Walleij's talk was
> helpful  for me too:
> http://elinux.org/images/9/9b/GPIO_for_Engineers_and_Makers.pdf 

You're right, and that's what we should be aiming for if someone has
the time to do the work. In the short term, we *can* just change the
hacky offset numbers that already exist in the userspace to work around
the problem. It's distasteful, but not worse than what we already have.

Patrick: Did you have any plans for reworking the userspace bits?

Cheers,

Andrew

PS: please try to reply in-line rather than top-posting, that way the
context of the conversation is a bit easier to track.

> 
> Nolan
> 
> -----Original Message-----
> From: openbmc [mailto:openbmc-bounces+nolan.hergert=intel.com@lists.o
> zlabs.org] On Behalf Of Joel Stanley
> Sent: Monday, January 30, 2017 4:26 PM
> To: Andrew Jeffery <andrew@aj.id.au>
> Cc: OpenBMC <openbmc@lists.ozlabs.org>
> Subject: Re: GPIO offsets used by userspace
> 
> On Mon, Jan 30, 2017 at 12:04 PM, Andrew Jeffery <andrew@aj.id.au>
> wrote:
> > Hi all,
> > 
> > Just a heads up that when the linked patch is pulled into the
> > OpenBMC 
> > kernel it will break our userspace. We will need to synchronise
> > the 
> > kernel bump with the fixes for the machine configs to update the
> > magic 
> > GPIO offset number.
> > 
> > https://lkml.org/lkml/2017/1/26/786
> > 
> > The magic offset is essentially 512-(ngpios) (I don't know why,
> > but 
> > that's the behaviour), and this now varies between AST2400 and
> > AST2500 
> > systems due to the AST2500 having an extra bank, and also because
> > the
> > AST2400 has a "hole" at the end of its GPIO number space.
> 
> Can you suggest a way to detect this from userspace?
> 
> Would using the chardev api make this easier?
> 
> Cheers,
> 
> Joel
> _______________________________________________
> openbmc mailing list
> openbmc@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/openbmc

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

RE: GPIO offsets used by userspace

[Hergert, Nolan]

-----Original Message-----
From: Andrew Jeffery [mailto:andrew@aj.id.au] 
Sent: Monday, January 30, 2017 5:13 PM
To: Hergert, Nolan <nolan.hergert@intel.com>; Joel Stanley <joel@jms.id.au>; Patrick Williams <patrick@stwcx.xyz>
Cc: OpenBMC <openbmc@lists.ozlabs.org>
Subject: Re: GPIO offsets used by userspace

Hi Nolan!

On Tue, 2017-01-31 at 00:50 +0000, Hergert, Nolan wrote:
> Correct me if I'm wrong, but I think the maintainers are moving away 
> from literal gpio numbers to named descriptors ("disk_led") in the 
> device tree, as we're moving to more dynamic hardware 
> https://lwn.net/Articles/533632/. Linus Walleij's talk was helpful  
> for me too:
> http://elinux.org/images/9/9b/GPIO_for_Engineers_and_Makers.pdf

You're right, and that's what we should be aiming for if someone has the time to do the work. In the short term, we *can* just change the hacky offset numbers that already exist in the userspace to work around the problem. It's distasteful, but not worse than what we already have.

Patrick: Did you have any plans for reworking the userspace bits?

Cheers,

Andrew

PS: please try to reply in-line rather than top-posting, that way the context of the conversation is a bit easier to track.

Glad to, thanks for the heads up. 

> 
> Nolan
> 
> -----Original Message-----
> From: openbmc [mailto:openbmc-bounces+nolan.hergert=intel.com@lists.o
> zlabs.org] On Behalf Of Joel Stanley
> Sent: Monday, January 30, 2017 4:26 PM
> To: Andrew Jeffery <andrew@aj.id.au>
> Cc: OpenBMC <openbmc@lists.ozlabs.org>
> Subject: Re: GPIO offsets used by userspace
> 
> On Mon, Jan 30, 2017 at 12:04 PM, Andrew Jeffery <andrew@aj.id.au>
> wrote:
> > Hi all,
> > 
> > Just a heads up that when the linked patch is pulled into the 
> > OpenBMC kernel it will break our userspace. We will need to 
> > synchronise the kernel bump with the fixes for the machine configs 
> > to update the magic GPIO offset number.
> > 
> > https://lkml.org/lkml/2017/1/26/786
> > 
> > The magic offset is essentially 512-(ngpios) (I don't know why, but 
> > that's the behaviour), and this now varies between AST2400 and
> > AST2500
> > systems due to the AST2500 having an extra bank, and also because 
> > the
> > AST2400 has a "hole" at the end of its GPIO number space.
> 
> Can you suggest a way to detect this from userspace?
> 
> Would using the chardev api make this easier?
> 
> Cheers,
> 
> Joel
> _______________________________________________
> openbmc mailing list
> openbmc@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/openbmc

Re: GPIO offsets used by userspace

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 344 bytes --]

On Tue, Jan 31, 2017 at 11:42:35AM +1030, Andrew Jeffery wrote:
> Patrick: Did you have any plans for reworking the userspace bits?

Yes.  Joel has previously talked about writing a proposal based on the
kernel team's desires.  I think we're getting close to queuing up the
work to refactor anything using GPIOs.

-- 
Patrick Williams

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: GPIO offsets used by userspace

[Andrew Jeffery]

[-- Attachment #1: Type: text/plain, Size: 1144 bytes --]

On Tue, 2017-01-31 at 10:55 +1030, Joel Stanley wrote:
> > On Mon, Jan 30, 2017 at 12:04 PM, Andrew Jeffery <andrew@aj.id.au> wrote:
> > Hi all,
> > 
> > Just a heads up that when the linked patch is pulled into the OpenBMC
> > kernel it will break our userspace. We will need to synchronise the
> > kernel bump with the fixes for the machine configs to update the magic
> > GPIO offset number.
> > 
> > https://lkml.org/lkml/2017/1/26/786
> > 
> > The magic offset is essentially 512-(ngpios) (I don't know why, but
> > that's the behaviour), and this now varies between AST2400 and AST2500
> > systems due to the AST2500 having an extra bank, and also because the
> > AST2400 has a "hole" at the end of its GPIO number space.
> 
> Can you suggest a way to detect this from userspace?

Not off the top of my head.

> 
> Would using the chardev api make this easier?

To a degree. I'm not sure if named gpios are exposed by the sysfs
interface, but with the chardev API you can open the devices and
request a GPIO by name. If that fails and you have multiple devices, I
guess you can try the other gpiochips.

Andrew

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: GPIO offsets used by userspace

[Xo Wang]

On Mon, Jan 30, 2017 at 5:15 PM, Andrew Jeffery <andrew@aj.id.au> wrote:
> On Tue, 2017-01-31 at 10:55 +1030, Joel Stanley wrote:
>> > On Mon, Jan 30, 2017 at 12:04 PM, Andrew Jeffery <andrew@aj.id.au> wrote:
>> > Hi all,
>> >
>> > Just a heads up that when the linked patch is pulled into the OpenBMC
>> > kernel it will break our userspace. We will need to synchronise the
>> > kernel bump with the fixes for the machine configs to update the magic
>> > GPIO offset number.
>> >
>> > https://lkml.org/lkml/2017/1/26/786
>> >
>> > The magic offset is essentially 512-(ngpios) (I don't know why, but
>> > that's the behaviour), and this now varies between AST2400 and AST2500
>> > systems due to the AST2500 having an extra bank, and also because the
>> > AST2400 has a "hole" at the end of its GPIO number space.
>>
>> Can you suggest a way to detect this from userspace?
>
> Not off the top of my head.
>

I mentioned this on GitHub, but in theory we should have at least one
/sys/class/gpio/gpiochipN directory, where N is the offset for GPIOs
provided by that GPIO device.

On a BMC not attached to GPIO expanders this directory name could be
parsed by the Python currently in use. Not foolproof, but it could be
a working stopgap.

However I don't actually see a /sys/class/gpio/gpiochipN directory on
the BMCs I touched. Any ideas?

cheers
xo

Re: GPIO offsets used by userspace

[Joel Stanley]

On Wed, Feb 1, 2017 at 8:45 AM, Xo Wang <xow@google.com> wrote:
> However I don't actually see a /sys/class/gpio/gpiochipN directory on
> the BMCs I touched. Any ideas?

That's strange. On the machines I looked at we do have that. I double
checked on a Zaius running the v1.99.1 tag:

root@zaius5:~# ls /sys/class/gpio/gpiochip320/
base       device     label      ngpio      subsystem  uevent

> I mentioned this on GitHub, but in theory we should have at least one
> /sys/class/gpio/gpiochipN directory, where N is the offset for GPIOs
> provided by that GPIO device.
>
> On a BMC not attached to GPIO expanders this directory name could be
> parsed by the Python currently in use. Not foolproof, but it could be
> a working stopgap.

You're right, we could find this one. This would break on Witherspoon
though which will soon gain a driver for a GPIO expander.

We could write some python to iterate through the gpiochipN
directories, and match against the label:

root@zaius5:~# cat /sys/class/gpio/gpiochip320/label
1e780000.gpio

This would be a stopgap until we could get something saner, like sysfs
files named after the net or function.

Cheers,

Joel

Re: GPIO offsets used by userspace

[Xo Wang]

On Tue, Jan 31, 2017 at 3:25 PM, Joel Stanley <joel@jms.id.au> wrote:
> On Wed, Feb 1, 2017 at 8:45 AM, Xo Wang <xow@google.com> wrote:
>> However I don't actually see a /sys/class/gpio/gpiochipN directory on
>> the BMCs I touched. Any ideas?
>
> That's strange. On the machines I looked at we do have that. I double
> checked on a Zaius running the v1.99.1 tag:
>
> root@zaius5:~# ls /sys/class/gpio/gpiochip320/
> base       device     label      ngpio      subsystem  uevent
>

So it is! I checked again. Must be a gross malfunction on my part.

>> I mentioned this on GitHub, but in theory we should have at least one
>> /sys/class/gpio/gpiochipN directory, where N is the offset for GPIOs
>> provided by that GPIO device.
>>
>> On a BMC not attached to GPIO expanders this directory name could be
>> parsed by the Python currently in use. Not foolproof, but it could be
>> a working stopgap.
>
> You're right, we could find this one. This would break on Witherspoon
> though which will soon gain a driver for a GPIO expander.
>
> We could write some python to iterate through the gpiochipN
> directories, and match against the label:
>
> root@zaius5:~# cat /sys/class/gpio/gpiochip320/label
> 1e780000.gpio
>
> This would be a stopgap until we could get something saner, like sysfs
> files named after the net or function.
>

Makes sense.

xo

Re: GPIO offsets used by userspace

[Andrew Jeffery]

[-- Attachment #1: Type: text/plain, Size: 1024 bytes --]

On Wed, 2017-02-01 at 09:55 +1030, Joel Stanley wrote:
> > I mentioned this on GitHub, but in theory we should have at least one
> > /sys/class/gpio/gpiochipN directory, where N is the offset for GPIOs
> > provided by that GPIO device.
> >
> > On a BMC not attached to GPIO expanders this directory name could be
> > parsed by the Python currently in use. Not foolproof, but it could be
> > a working stopgap.
> 
> You're right, we could find this one. This would break on Witherspoon
> though which will soon gain a driver for a GPIO expander.
> 
> We could write some python to iterate through the gpiochipN
> directories, and match against the label:
> 
> root@zaius5:~# cat /sys/class/gpio/gpiochip320/label
> 1e780000.gpio
> 
> This would be a stopgap until we could get something saner, like sysfs
> files named after the net or function.

If we're going to change things so significantly we should move away
from using sysfs given it's deprecated, even if the alternative isn't
great.

Andrew

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: GPIO offsets used by userspace

[Andrew Jeffery]

[-- Attachment #1: Type: text/plain, Size: 1116 bytes --]

On Mon, 2017-01-30 at 12:04 +1030, Andrew Jeffery wrote:
> Hi all,
> 
> Just a heads up that when the linked patch is pulled into the OpenBMC
> kernel it will break our userspace. We will need to synchronise the
> kernel bump with the fixes for the machine configs to update the magic
> GPIO offset number.
> 
> https://lkml.org/lkml/2017/1/26/786
> 
> The magic offset is essentially 512-(ngpios) (I don't know why, but
> that's the behaviour), and this now varies between AST2400 and AST2500
> systems due to the AST2500 having an extra bank, and also because the
> AST2400 has a "hole" at the end of its GPIO number space.
> 

For those interested I've pushed a patch to skeleton that generalises
assignment of the GPIO_BASE value (i.e. it now dynamically detects the
chip base and so is also backwards compatible):

https://gerrit.openbmc-project.xyz/#/c/2261/

If you have any better ideas for an interim solution please speak up.

The rough plan is to apply that and then pull in the new kernel. Joel
has a testing commit here:

https://gerrit.openbmc-project.xyz/#/c/2257/

Andrew

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]