From: Kent Gibson <warthog618@gmail.com>
To: Ian Pilcher <arequipeno@gmail.com>
Cc: "linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
kernelnewbies@kernelnewbies.org
Subject: Re: gpiod_get() - How to get GPIO from chip & offset?
Date: Mon, 8 Aug 2022 09:54:56 +0800 [thread overview]
Message-ID: <20220808015456.GA12686@sol> (raw)
In-Reply-To: <d2c3cb8e-4042-13ad-4bb9-21b289ba773c@gmail.com>
On Sun, Aug 07, 2022 at 09:55:32AM -0500, Ian Pilcher wrote:
> I am trying to figure out how to use gpiod_get(), or one of its
> variants, to get the descriptor (struct gpio_desc *) for a specific
> GPIO. Getting a reference to the GPIO chip (struct gpio_chip *) is
> straightforward, and it provides a pointer to the device (.parent), but
> I absolutely cannot figure out what I am supposed to pass as the
> *con_id* argument.
>
> I know the offset of the GPIO on the chip, but I can't figure out how to
> use that.
>
> Ultimately, my goal is to set the direction of the GPIO from within a
> "board setup" module.
>
>
> BACKGROUND
>
> I maintain an out-of-tree "board" module[1] that sets up the GPIOs and
> LEDs on my Thecus NAS. I am in the process of upgrading the OS on the
> NAS, which will require me to change the user-space daemon from the old
> sysfs GPIO interface to the new (non-ancient?) gpiod interface.
>
So the daemon should use libgpiod to control the line where it used to
use sysfs.
> One significant difference between the sysfs and gpiod interfaces, is
> that the new interface does not seem to provide an easy way to set a
> GPIO's direction (input/output) from a shell script[2]. Thus, I would
> like the board module to do that, along with the other setup.
>
> [1] https://github.com/ipilcher/n5550/blob/master/modules/n5550_board.c
>
> [2] It may be possible to change a GPIO's direction from user space with
> the C API, but doing it in the kernel module, which does all of the
> other hardware configuration, seems like the most appropriate way.
>
Understand that configuration applied to a line, be it by the module or
from userspace, only remains valid while the line is held.
Once you free the line the state of the line may revert to its default
state. sysfs effectively holds the line indefinitely, which is one of
its problems.
So the line should be configured by whatever will be controlling it. If
that is the module then the module. If it is the userspace daemon then
the userspace daemon.
If the issue is changing the daemon from using sysfs to cdev then there
should be no changes required to the module.
The gpioset and gpioget tools provided by libgpiod change the direction
of the line from shell, but that is not relevant to your case as you
should be using the C API provided by libgpiod.
Cheers,
Kent.
next prev parent reply other threads:[~2022-08-08 2:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-07 14:55 gpiod_get() - How to get GPIO from chip & offset? Ian Pilcher
2022-08-08 1:54 ` Kent Gibson [this message]
2022-08-08 14:57 ` Andy Shevchenko
2022-08-08 15:00 ` Andy Shevchenko
2022-08-11 18:22 ` Ian Pilcher
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220808015456.GA12686@sol \
--to=warthog618@gmail.com \
--cc=arequipeno@gmail.com \
--cc=kernelnewbies@kernelnewbies.org \
--cc=linux-gpio@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).