linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: "Grant Likely" <grant.likely@secretlab.ca>
To: "Matt Sealey" <matt@genesi-usa.com>
Cc: Mitch Bradley <wmb@firmworks.com>,
	linuxppc-dev list <linuxppc-dev@ozlabs.org>,
	devicetree-discuss list <devicetree-discuss@ozlabs.org>
Subject: Re: GPIO - marking individual pins (not) available in device tree
Date: Mon, 27 Oct 2008 23:20:59 -0600	[thread overview]
Message-ID: <fa686aa40810272220w13dfbbadm7cda4ed2036ebc2b@mail.gmail.com> (raw)
In-Reply-To: <4906620B.7080308@genesi-usa.com>

On Mon, Oct 27, 2008 at 6:51 PM, Matt Sealey <matt@genesi-usa.com> wrote:
>
>
> David Gibson wrote:
>>
>> On Mon, Oct 27, 2008 at 10:40:12AM -0500, Matt Sealey wrote:
>>
>> So, you use
>>        gpios = <&controller pin1-specifier &controller pin8-specifier
>>                 &controller pin9-specifier &controller pin11-specifier
>>                 &controller pin15-specifier &controller pin30-specifier>;
>
> Okay that makes some more sense to me.
>
> So now my qualm is back to the beginning of the discussion. How do
> we encode the purpose of those pins reliably and within some
> standard framework, without getting *driver* specific?
>
> Take the example of an LCD controller with an 8-bit bus and two
> control pins, if you put all 10 into a gpios property, explicit
> knowledge of the purpose of those pins is lost. It must then be
> encoded directly into the driver..

I disagree.  With the approach we've been following the meaning of
those 10 gpio pins is not lost because we make a point of documenting
it (granted in the Linux kernel tree at the moment which is far from
ideal).  The knowledge of what those GPIOs are for is all bound up
with the documented binding attached to the compatible value.

> I liked Anton's suggestion of grouping them and creating new nodes,
> but you didn't like it when it was suggested before, so, I'm
> wondering if there's a middle ground..

I've got no problem with this myself, but I don't think it really adds
much in terms of additional information because users still need to
refer to binding documentation to figure out what it actually means.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

  parent reply	other threads:[~2008-10-28  5:20 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-23 21:32 GPIO - marking individual pins (not) available in device tree Matt Sealey
2008-10-23 22:22 ` Mitch Bradley
2008-10-23 23:05   ` Matt Sealey
2008-10-24  0:52     ` Mitch Bradley
2008-10-24  3:29       ` David Gibson
2008-10-24  4:17         ` Mitch Bradley
2008-10-24  4:45           ` David Gibson
2008-10-24 22:14             ` Matt Sealey
2008-10-26 23:47               ` David Gibson
2008-10-27 15:40                 ` Matt Sealey
2008-10-27 18:34                   ` Anton Vorontsov
2008-10-27 18:56                     ` Matt Sealey
2008-10-27 20:10                       ` Anton Vorontsov
2008-10-27 21:56                         ` Matt Sealey
2008-10-27 23:12                           ` Anton Vorontsov
2008-10-27 23:40                             ` Anton Vorontsov
2008-10-28  0:47                               ` Matt Sealey
2008-10-28  1:11                             ` Matt Sealey
2008-10-28  2:37                               ` Anton Vorontsov
2008-10-28 16:53                                 ` Matt Sealey
2008-10-28 17:39                                   ` Grant Likely
2008-10-28 19:46                                     ` Matt Sealey
2008-10-28  0:15                   ` David Gibson
2008-10-28  0:51                     ` Matt Sealey
2008-10-28  1:50                       ` David Gibson
2008-10-28  5:20                       ` Grant Likely [this message]
2008-10-24 22:03       ` Matt Sealey
2008-10-24 22:20         ` Stephen Neuendorffer
2008-10-26 21:39           ` Matt Sealey
2008-10-24 23:44         ` Mitch Bradley
2008-10-26 21:13           ` Matt Sealey
2008-10-26 23:53             ` David Gibson
2008-10-27 16:12               ` Matt Sealey
2008-10-27 16:35                 ` Scott Wood
2008-10-27 17:05                   ` Matt Sealey
2008-10-27 17:25                     ` Scott Wood
2008-10-27 17:49                       ` Matt Sealey
2008-10-27 17:54                         ` Scott Wood
2008-10-28  0:38                           ` David Gibson
2008-10-28  0:34                 ` David Gibson
2008-10-24  4:58     ` David Gibson
2008-10-24  3:27   ` David Gibson
2008-10-24 16:41 ` Anton Vorontsov
2008-10-24 17:01   ` Anton Vorontsov
2008-10-24 22:17     ` Matt Sealey
2008-10-24 22:37       ` Anton Vorontsov
  -- strict thread matches above, loose matches on Subject: below --
2008-10-28 13:31 Konstantinos Margaritis
2008-10-28 14:11 ` Anton Vorontsov
2008-10-28 14:15 ` Grant Likely
2008-10-28 17:06   ` Matt Sealey
2008-10-28 17:32     ` Grant Likely
2008-10-28 23:37 ` David Gibson

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=fa686aa40810272220w13dfbbadm7cda4ed2036ebc2b@mail.gmail.com \
    --to=grant.likely@secretlab.ca \
    --cc=devicetree-discuss@ozlabs.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=matt@genesi-usa.com \
    --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 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).