2:43 p.m.
Hello.
Tell me if I understand correctly the situation about GPIO on Fedora.
(Please note: I'm not an engineer nor a developer). I'm asking this
because I'm unable to find suitable and exaustive (for me)
documentation.
GPIO sysfs interface is deprecated, and in the future will be removed
from the kernel. So in Fedora the kernel is compiled without such
flag. As a consequence we don't have the /sys/class/gpio path.
We have instead /dev/gpiochipN character device.
To use this device we can't use ordinary commands line tools (echo,
cat, etc), but you have to go through some library.
In addition to that, current kernel modules (like wire, wire_therm,
wire_gpio) cannot be used, and someone should write something new (i'm
thinking to 1wire sensors).
Furthermore, using the provided libgpiod tools, all that you can do at
the moment is putting a pin to high or to low level, and read the
level.
At last, at least on the Raspberry Pi, the gpioinfo command provides a
list of lines. The count of these lines is higher than the number of
pins, and ok, there is something a bit difficult to understand for me,
but I can imagine that the GPIO in the SOC is not only the pinout. The
fact is that these lines, these numbers are unmapped to the GPIO pins
(I'm unable to find documentation): if I try every line offset with
the tool gpioset, maybe with a LED, do you think I will be aple to
create a suitable mapping (like saying: line offset 7 is BCM pin 4,
and so on, for instance)?
Sorry if I wrote a bunch of garbage. Any clarification will be welcome.
Ciao,
A.
9:34 a.m.
GPIO sysfs interface is deprecated, and in the future will be
removed
from the kernel. So in Fedora the kernel is compiled without such
flag. As a consequence we don't have the /sys/class/gpio path.
We have instead /dev/gpiochipN character device.
That is correct. Upstream wants to kill it off due to security and
other issues, Fedora has never really supported the old interface so I
removed it as soon as it was deprecated so we didn't end up with a
massive legacy problem.
To use this device we can't use ordinary commands line tools
(echo,
cat, etc), but you have to go through some library.
Library or cli tools.
In addition to that, current kernel modules (like wire, wire_therm,
wire_gpio) cannot be used, and someone should write something new (i'm
thinking to 1wire sensors).
Please provide details as to why you think that is the case.
Furthermore, using the provided libgpiod tools, all that you can do
at
the moment is putting a pin to high or to low level, and read the
level.
You should also be able to set it to input or output at which point it
should be usable.
At last, at least on the Raspberry Pi, the gpioinfo command provides
a
list of lines. The count of these lines is higher than the number of
pins, and ok, there is something a bit difficult to understand for me,
but I can imagine that the GPIO in the SOC is not only the pinout. The
Yes, the gpio maps to all sorts of things like onboard LEDs, MMC card
detect, BT and WiFi enable pins and all sorts of other things. There
is the ability for the GPIO lines to be labled so you know what they
are, I thought the RPi ones had been but a lsgpio (from the
kernel-tools package) shows they're not yet for at least the RPi2 I
had handy but on another device they are labeled. A quick look at the
DT on the upstream kernel I see the 3B/3B+ have a few labels here and
there but it's not consistent. I've added it to my list to see if I
can't get it improved.
fact is that these lines, these numbers are unmapped to the GPIO
pins
(I'm unable to find documentation): if I try every line offset with
The docs for the RPI are here https://pinout.xyz/ and should be
consistent with Fedora.
the tool gpioset, maybe with a LED, do you think I will be aple to
create a suitable mapping (like saying: line offset 7 is BCM pin 4,
and so on, for instance)?
I believe others have achieved this, maybe have a look at the list
archives for details.
Sorry if I wrote a bunch of garbage. Any clarification will be
welcome.
Nope, completely relevant, the GPIO bits in general upstream need
improving, I've discussed this a few times, it's getting there but way
too slowly.
10:01 a.m.
On Tue, Aug 14, 2018 at 4:34 PM Peter Robinson <pbrobinson(a)gmail.com> wrote:
> In addition to that, current kernel modules (like wire,
wire_therm,
> wire_gpio) cannot be used, and someone should write something new (i'm
> thinking to 1wire sensors).
Please provide details as to why you think that is the case.
I didn't look at the module sources, due to the fact that I won't know
what I will read :-) but as far as I can see in the documentation, and
looking at the behaviours, it seems that wire and wire_therm modules
interact with the Sysfs interface (/sys/class/gpio). So we should need
modules that interact with the character device. Isn't it (more or
less)?
Nope, completely relevant, the GPIO bits in general upstream need
improving, I've discussed this a few times, it's getting there but way
too slowly.
Thank you very much for the clarifications and for your efforts.
Ciao,
A.
10:14 a.m.
On Tue, Aug 14, 2018 at 4:01 PM, Alessio Ciregia <alciregi(a)gmail.com> wrote:
On Tue, Aug 14, 2018 at 4:34 PM Peter Robinson
<pbrobinson(a)gmail.com> wrote:
> > In addition to that, current kernel modules (like wire, wire_therm,
> > wire_gpio) cannot be used, and someone should write something new (i'm
> > thinking to 1wire sensors).
>
> Please provide details as to why you think that is the case.
I didn't look at the module sources, due to the fact that I won't know
what I will read :-) but as far as I can see in the documentation, and
looking at the behaviours, it seems that wire and wire_therm modules
interact with the Sysfs interface (/sys/class/gpio). So we should need
modules that interact with the character device. Isn't it (more or
less)?
Don't expect you to dig through code but you mention "as far as I can
see in the documentation" so where is that documentation?
>> Nope, completely relevant, the GPIO bits in general upstream need
>> improving, I've discussed this a few times, it's getting there but way
>> too slowly.
>
> Thank you very much for the clarifications and for your efforts.
>
> Ciao,
> A.
10:35 a.m.
On Tue, Aug 14, 2018 at 5:14 PM Peter Robinson <pbrobinson(a)gmail.com> wrote:
Don't expect you to dig through code but you mention "as far as I can
see in the documentation" so where is that documentation?
Well, maybe these are my misunderstandings, but googling around, for
instance <http://linux-sunxi.org/1-Wire>;, or
<https://www.kernel.org/doc/Documentation/w1/w1.generic> or many
examples, mentions and implies only the use of sysfs interface
(/sys/bus/w1/devices) in order to communicate with the 1-wire devices.
You mean these modules are not actually limited to sysfs?
Ciao,
A.
2:40 a.m.
For your information, here you can find some notes about GPIO usage
(driving a LED and reading a pin status) on a RPi3 running F28.
<https://blog.oless.xyz/post/fedorarpigpio/>
In addition, in contrast to my assumptions, GPIO sysfs deprecation is
not related to 1wire or other modules.
Ciao
A.
2075
days inactive
2084
days old
5 comments
2 participants
participants (2)
-
Alessio Ciregia -
Peter Robinson