From: Johannes Stezenbach <js@sig21.net>
To: Mitch Bradley <wmb@firmworks.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
devicetree-discuss@lists.ozlabs.org,
linux-kernel@vger.kernel.org
Subject: Re: DT GPIO numbering?
Date: Fri, 10 Aug 2012 11:34:58 +0200 [thread overview]
Message-ID: <20120810093458.GA13192@sig21.net> (raw)
In-Reply-To: <501FA608.1030805@firmworks.com>
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 <swarren@wwwdotorg.org> 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
next prev parent reply other threads:[~2012-08-10 9:34 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-01 15:22 DT GPIO numbering? Johannes Stezenbach
[not found] ` <20120801152240.GA16388-FF7aIK3TAVNeoWH0uzbU5w@public.gmane.org>
2012-08-05 10:06 ` Linus Walleij
2012-08-05 10:06 ` Linus Walleij
2012-08-06 2:18 ` Stephen Warren
2012-08-06 6:35 ` Linus Walleij
2012-08-06 9:58 ` Johannes Stezenbach
[not found] ` <20120806095805.GA16607-FF7aIK3TAVNeoWH0uzbU5w@public.gmane.org>
2012-08-06 11:10 ` Mitch Bradley
2012-08-06 11:10 ` Mitch Bradley
2012-08-10 9:34 ` Johannes Stezenbach [this message]
2012-08-14 10:00 ` Linus Walleij
2012-08-14 13:05 ` Johannes Stezenbach
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=20120810093458.GA13192@sig21.net \
--to=js@sig21.net \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=wmb@firmworks.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.