From: Johan Hovold <johan@kernel.org>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Johan Hovold <johan@kernel.org>,
Martin Fuzzey <mfuzzey@parkeon.com>,
Alexandre Courbot <gnurou@gmail.com>,
Rob Herring <robh+dt@kernel.org>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [PATCH 0/2] gpio: Allow userspace export from DT
Date: Wed, 6 May 2015 15:06:15 +0200 [thread overview]
Message-ID: <20150506130615.GB5302@localhost> (raw)
In-Reply-To: <CACRpkdbFKs8mALw7q2d0EEDkhxKNLgeiFB5TyZ6ZPpfcW-c+oQ@mail.gmail.com>
On Wed, May 06, 2015 at 09:22:22AM +0200, Linus Walleij wrote:
> On Mon, May 4, 2015 at 10:49 AM, Johan Hovold <johan@kernel.org> wrote:
> > On Mon, Apr 13, 2015 at 01:05:15PM +0200, Martin Fuzzey wrote:
>
> >> The above means that, in order to export the GPIO to userspace via
> >> /sys/class/gpio/export the userspace code must know the exact hardware and
> >> kernel version information.
> >
> > Not quite. You can still determine the gpio number in the above cases by
> > walking the sysfs tree to find the chip and it's base. This is the only
> > way to do this for dynamic buses such as USB.
>
> Maybe we should start providing something like an
> "lsgpio" utility in tools/gpio to do this, just as a hint
> to userspace people on how things should be done.
I think we should focus on defining a new user-space interface rather
than make it easier to use the current one (it should really only be
used for development or one-off hacks IMO).
> >> This patch series solves both problems by performing the external
> >> signal => GPIO mapping in the device tree.
> >
> > As Rob already mentioned, what we want is some way to declare pin
> > functions. These could then be requested from userspace (or used in DT,
> > something which should allow for further refactoring there as well)
> > unless a driver has already claimed them.
>
> We have the ability to name the GPIO lines (I usually refer to
> lines rather than pins, as pins are physical and not all GPIOs
> are, actually) using the array "names" in struct gpio_chip,
> however this has no DT binding, so maybe people should
> work on that. These names appear as named line files
> in sysfs IIRC. Or maybe you're thinking of something else?
Yes, something like that. As you mention above, if it was possibly to
define those names in firmware, even the current sysfs interface would
expose the pins as
/sys/class/gpio/<function>
rather than say /sys/class/gpio/gpio279, thereby solving the gpio-number
look-up issue. Well, to actually make the pin available *from* userspace
you'd currently still need the number...
Johan
next prev parent reply other threads:[~2015-05-06 13:06 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-13 11:05 [PATCH 0/2] gpio: Allow userspace export from DT Martin Fuzzey
2015-04-13 11:05 ` [PATCH 1/2] Doc: DT: Add binding document for GPIO exporter Martin Fuzzey
2015-04-13 11:05 ` [PATCH 2/2] gpio: add driver to export DT configured GPIOs to userspace Martin Fuzzey
2015-04-15 13:19 ` [PATCH 0/2] gpio: Allow userspace export from DT Rob Herring
[not found] ` <CAL_JsqJorndYh4ROdKbJfpG1KY=Xosjc6BMFYRPrb+BsauFsnQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-04-28 12:56 ` Linus Walleij
2015-05-04 8:49 ` Johan Hovold
2015-05-06 7:22 ` Linus Walleij
2015-05-06 13:06 ` Johan Hovold [this message]
2015-05-06 17:56 ` Fuzzey, Martin
2015-05-08 9:31 ` Johan Hovold
2015-05-06 11:24 ` Russell King - ARM Linux
2015-05-06 12:43 ` Johan Hovold
2015-05-06 12:57 ` Russell King - ARM Linux
[not found] ` <20150506125707.GV2067-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2015-05-06 13:25 ` Johan Hovold
2015-05-07 5:38 ` Jiří Prchal
2015-05-07 12:28 ` Russell King - ARM Linux
[not found] ` <20150507122840.GB2067-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2015-05-08 10:04 ` Johan Hovold
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=20150506130615.GB5302@localhost \
--to=johan@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=gnurou@gmail.com \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-gpio@vger.kernel.org \
--cc=mfuzzey@parkeon.com \
--cc=robh+dt@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).