Hi,
I'm currently learning how Linux devicetree support works,
here is one question I couldn't find an answer for.
I understand that within the devicetree GPIOs are referenced by phandle,
thus the numbers are irrelevant. However, in sysfs the number is
what is used to access the GPIO, e.g. for debugging or
blinkenlight apps. How does this fit together?
In the old days platform data was used, e.g.
struct pl061_platform_data {
/* number of the first GPIO */
unsigned gpio_base;
...
};
Now, when DT is used gpio-pl061.c sets gc.base = -1 (dynamic numbering).
Should there be a DT property to assign the number base?
Or is there some better way, e.g. in gpio-mxs.c the code derives
the gc.base from of_alias_get_id(np, "gpio").
Should gpio-pl061.c do the same?
And how about assigning gpio names? When a name is assigned to
the GPIO, is shows up in sysfs instead of gpio%d, however the
number is still needed for /sys/class/gpio/export, right?
Thanks,
Johannes
On Wed, Aug 1, 2012 at 5:22 PM, Johannes Stezenbach <[email protected]> wrote:
> I'm currently learning how Linux devicetree support works,
> here is one question I couldn't find an answer for.
>
> I understand that within the devicetree GPIOs are referenced by phandle,
> thus the numbers are irrelevant. However, in sysfs the number is
> what is used to access the GPIO, e.g. for debugging or
> blinkenlight apps. How does this fit together?
I think it simply does not fit together.
Grant & me has been claiming the GPIO sysfs interface is a bit
crazy from time to time.
My long-term plan would be to replace it with /dev/gpio/gpioN
device nodes per-gpiochip and use ioctl etc to control these
beasts instead. However one does not do that overnight,
and my life is too busy, and other refactorings also need to
happen :-/
Yours,
Linus Walleij
On 08/05/2012 04:06 AM, Linus Walleij wrote:
> On Wed, Aug 1, 2012 at 5:22 PM, Johannes Stezenbach <[email protected]> wrote:
>
>> I'm currently learning how Linux devicetree support works,
>> here is one question I couldn't find an answer for.
>>
>> I understand that within the devicetree GPIOs are referenced by phandle,
>> thus the numbers are irrelevant. However, in sysfs the number is
>> what is used to access the GPIO, e.g. for debugging or
>> blinkenlight apps. How does this fit together?
>
> I think it simply does not fit together.
>
> Grant & me has been claiming the GPIO sysfs interface is a bit
> crazy from time to time.
>
> My long-term plan would be to replace it with /dev/gpio/gpioN
> device nodes per-gpiochip and use ioctl etc to control these
> beasts instead. However one does not do that overnight,
> and my life is too busy, and other refactorings also need to
> happen :-/
I can't comment on the sysfs-vs-dev interface location, but I don't
think it addresses Johannes' issue; finding out which GPIO IDs are
provided by which devices.
Perhaps in each device's sysfs node, there should be some information
re: which GPIO range it provides. Right now, perhaps a text file with
the GPIO base it it. With the new /dev interface you mention above,
perhaps a symlink to the /dev file, or a file containing the /dev file's
major/minor number. Or, is there such a thing already (other than
debugfs's gpio file).
On Mon, Aug 6, 2012 at 4:18 AM, Stephen Warren <[email protected]> wrote:
> I can't comment on the sysfs-vs-dev interface location, but I don't
> think it addresses Johannes' issue; finding out which GPIO IDs are
> provided by which devices.
>
> Perhaps in each device's sysfs node, there should be some information
> re: which GPIO range it provides. Right now, perhaps a text file with
> the GPIO base it it.
Yes that could work ...
> With the new /dev interface you mention above,
> perhaps a symlink to the /dev file, or a file containing the /dev file's
> major/minor number. Or, is there such a thing already (other than
> debugfs's gpio file).
Nothing I know of, but yes the day we come up with something,
it needs to be backward-compatible some way.
The problem is that there is really no reference userspace
like "lsgpio" or so. Maybe the first step could be to create that.
Yours,
Linus Walleij
On Mon, Aug 06, 2012 at 08:35:51AM +0200, Linus Walleij wrote:
> On Mon, Aug 6, 2012 at 4:18 AM, Stephen Warren <[email protected]> wrote:
>
> > I can't comment on the sysfs-vs-dev interface location, but I don't
> > think it addresses Johannes' issue; finding out which GPIO IDs are
> > provided by which devices.
> >
> > Perhaps in each device's sysfs node, there should be some information
> > re: which GPIO range it provides. Right now, perhaps a text file with
> > the GPIO base it it.
>
> Yes that could work ...
The method used by the gpio-mxs.c driver (of_alias_get_id)
would also work. The question is which method is preferable.
Ideally I would like to use DT attributes to identify my GPIOs
in the same way as they appear in the schematics. E.g.
one device may have GPIOs called PORT_A.0 to PORT_A.7,
another one may be EXT.0 to EXT.15. But a single integer ID
is good enough since GPIO usage is platform specific anyway.
However, the mapping must be static and not depend e.g. on
module load order like now if you use pl061 and some i2c GPIO.
Software must be able to rely on that e.g. GPIO ID 11
always refers to EXT.3.
> > With the new /dev interface you mention above,
> > perhaps a symlink to the /dev file, or a file containing the /dev file's
> > major/minor number. Or, is there such a thing already (other than
> > debugfs's gpio file).
>
> Nothing I know of, but yes the day we come up with something,
> it needs to be backward-compatible some way.
>
> The problem is that there is really no reference userspace
> like "lsgpio" or so. Maybe the first step could be to create that.
I don't know much about OpenWrt, but I've seen they have
something:
https://dev.openwrt.org/browser/trunk/target/linux/generic/files/drivers/char/gpio_dev.c
https://dev.openwrt.org/browser/trunk/target/linux/generic/files/include/linux/gpio_dev.h
https://dev.openwrt.org/browser/trunk/package/gpioctl/src/main.c
Johannes
On 8/6/2012 5:58 PM, Johannes Stezenbach wrote:
> On Mon, Aug 06, 2012 at 08:35:51AM +0200, Linus Walleij wrote:
>> On Mon, Aug 6, 2012 at 4:18 AM, Stephen Warren <[email protected]> wrote:
>>
>>> I can't comment on the sysfs-vs-dev interface location, but I don't
>>> think it addresses Johannes' issue; finding out which GPIO IDs are
>>> provided by which devices.
>>>
>>> Perhaps in each device's sysfs node, there should be some information
>>> re: which GPIO range it provides. Right now, perhaps a text file with
>>> the GPIO base it it.
>>
>> Yes that could work ...
>
> The method used by the gpio-mxs.c driver (of_alias_get_id)
> would also work. The question is which method is preferable.
>
> Ideally I would like to use DT attributes to identify my GPIOs
> in the same way as they appear in the schematics. E.g.
> one device may have GPIOs called PORT_A.0 to PORT_A.7,
> another one may be EXT.0 to EXT.15. But a single integer ID
> is good enough since GPIO usage is platform specific anyway.
> However, the mapping must be static and not depend e.g. on
> module load order like now if you use pl061 and some i2c GPIO.
> Software must be able to rely on that e.g. GPIO ID 11
> always refers to EXT.3.
There is precedence for a "slot-names" property that correlates specific
hardware entities with physical labels. It has been applied to PCI
plug-in slots and to other devices. See, for example,
http://www.openfirmware.org/1275/proposals/Closed/Accepted/381-it.txt
>
>
>>> With the new /dev interface you mention above,
>>> perhaps a symlink to the /dev file, or a file containing the /dev file's
>>> major/minor number. Or, is there such a thing already (other than
>>> debugfs's gpio file).
>>
>> Nothing I know of, but yes the day we come up with something,
>> it needs to be backward-compatible some way.
>>
>> The problem is that there is really no reference userspace
>> like "lsgpio" or so. Maybe the first step could be to create that.
>
> I don't know much about OpenWrt, but I've seen they have
> something:
> https://dev.openwrt.org/browser/trunk/target/linux/generic/files/drivers/char/gpio_dev.c
> https://dev.openwrt.org/browser/trunk/target/linux/generic/files/include/linux/gpio_dev.h
> https://dev.openwrt.org/browser/trunk/package/gpioctl/src/main.c
>
>
> Johannes
> _______________________________________________
> devicetree-discuss mailing list
> [email protected]
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>
On Mon, Aug 06, 2012 at 07:10:00PM +0800, Mitch Bradley wrote:
> On 8/6/2012 5:58 PM, Johannes Stezenbach wrote:
> > On Mon, Aug 06, 2012 at 08:35:51AM +0200, Linus Walleij wrote:
> >> On Mon, Aug 6, 2012 at 4:18 AM, Stephen Warren <[email protected]> wrote:
> >>
> >>> I can't comment on the sysfs-vs-dev interface location, but I don't
> >>> think it addresses Johannes' issue; finding out which GPIO IDs are
> >>> provided by which devices.
> >>>
> >>> Perhaps in each device's sysfs node, there should be some information
> >>> re: which GPIO range it provides. Right now, perhaps a text file with
> >>> the GPIO base it it.
> >>
> >> Yes that could work ...
> >
> > The method used by the gpio-mxs.c driver (of_alias_get_id)
> > would also work. The question is which method is preferable.
> >
> > Ideally I would like to use DT attributes to identify my GPIOs
> > in the same way as they appear in the schematics. E.g.
> > one device may have GPIOs called PORT_A.0 to PORT_A.7,
> > another one may be EXT.0 to EXT.15. But a single integer ID
> > is good enough since GPIO usage is platform specific anyway.
> > However, the mapping must be static and not depend e.g. on
> > module load order like now if you use pl061 and some i2c GPIO.
> > Software must be able to rely on that e.g. GPIO ID 11
> > always refers to EXT.3.
>
> There is precedence for a "slot-names" property that correlates specific
> hardware entities with physical labels. It has been applied to PCI
> plug-in slots and to other devices. See, for example,
> http://www.openfirmware.org/1275/proposals/Closed/Accepted/381-it.txt
Sorry about the slow response. After thinking it through I decided
that a) adding ad-hoc DT bindings isn't good, and b) doing
it properly is above my head atm (I have too many other tasks to
take care of). So I decided to use platform data to get stable
GPIO numbers and names for now.
Actually I think the kernel internal GPIO numbers shouldn't be in the
sysfs API, instead userspace should use the names. Probably it's
best to not use /sys/class/gpio/export but instead let the board
init code export the GPIOs available to userspace with proper names.
Not sure yet...
Thanks,
Johannes
On Fri, Aug 10, 2012 at 11:34 AM, Johannes Stezenbach <[email protected]> wrote:
> Actually I think the kernel internal GPIO numbers shouldn't be in the
> sysfs API, instead userspace should use the names.
This is true, but we cannot remove these numbers because they
are now in Documentation/ABI/testing/sysfs-gpio
And while the "testing" ABI is, well for testing, it would probably
break a lot of stuff it we removed it.
But we can sure add names. However these would still sit under
/sys/class/gpio/gpioN/name
Or do you suggest we simply duplicate all GPIOs which have
names under /sys/class/gpio/named/<name>
or something like that?
I know Grant may have opinions on this...
> Probably it's
> best to not use /sys/class/gpio/export but instead let the board
> init code export the GPIOs available to userspace with proper names.
This sounds true.
Yours,
Linus Walleij
On Tue, Aug 14, 2012 at 12:00:23PM +0200, Linus Walleij wrote:
> On Fri, Aug 10, 2012 at 11:34 AM, Johannes Stezenbach <[email protected]> wrote:
>
> > Actually I think the kernel internal GPIO numbers shouldn't be in the
> > sysfs API, instead userspace should use the names.
>
> This is true, but we cannot remove these numbers because they
> are now in Documentation/ABI/testing/sysfs-gpio
>
> And while the "testing" ABI is, well for testing, it would probably
> break a lot of stuff it we removed it.
>
> But we can sure add names. However these would still sit under
> /sys/class/gpio/gpioN/name
>
> Or do you suggest we simply duplicate all GPIOs which have
> names under /sys/class/gpio/named/<name>
> or something like that?
I'm still not sure. One idea was to add /proc/gpios which maps
names to numbers, then userspace can look up the number and use that.
But the more I think about it /sys/class/gpio/export is just
a debug hack and shouldn't be used. Board code should export
the available gpio according to pinctrl setup and schematics.
The only catch here is that board code then needs to know which gpio are
for userspace and which are used by in-kernel drivers.
E.g. a LED could be set by LED Triggers or by userspace
Blinkenlight app.
Johannes