All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Sealey <matt@genesi-usa.com>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: 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: Tue, 28 Oct 2008 14:46:38 -0500	[thread overview]
Message-ID: <49076C1E.8090501@genesi-usa.com> (raw)
In-Reply-To: <fa686aa40810281039v4f22a464u3eb1d421e1226fc8@mail.gmail.com>



Grant Likely wrote:

> At this level, the 'compatible = "gpio-group";' is completely
> irrelevant.  The binding for "crystalfontz,something-gpio" must
> specify that there are two subnodes; one named data-bus and one named
> rw-ctrl.  The driver, which binds against compatible in the parent
> node, would know to go looking for those child nodes and to use the
> gpios property inside them.  Simple.

Point taken.

>>> Does this mean "hard-coding"?
>> No. If you have an array of GPIO pins (gpios property) then how do you
>> determine which is for data and which is some control pin? Do you
>> associate these numbers in the driver somehow? Maybe a matchlist or
>> an array? Given pins A B C D E F G H I J where does the data bus
>> start and the control pins live? A and B? A and J? I and J?
> 
> You know because you document it in the binding.

I think having a working device tree and a seperate binding document
sometimes slows things down. If it is not patently obvious what you
mean from a device tree, in order to write a new driver, the device
tree is not doing it's job..

Where the binding must take it's cue from established documentation,
and follows existing procedures and semantics, the binding is important
(for instance there are a few ways to check an interrupt fired on
MPC5200B, and Linux/dts encodes them per ONE table in the docs, this
must be referenced somewhere at least)

>> It would be definitely frivolous to define a whole device tree binding
>> for the *order in which you MUST specify the gpios for this particular
>> device*. There is obviously an implicit ordering of the GPIOs to make
>> up the data bus (you'd expect an order from MSB to LSB.. or perhaps
>> LSB to MSB... that might be better defined than undefined)
> 
> Why is it frivolous?  We do this all the time for reg and irqs.

See above. Does every driver require a ratified device tree binding
which is collaborated and agreed upon even though it may be in use on
one or two boards which actually may never see the light of day (I
bet none of you will ever see the CPLD core I'm sitting in front of
right now..)

I think it should be obvious both from the tree and inside the driver
what magical little sections of code do without cross-referencing, I
do far too much cross-referencing in Linux as it is, and it's one thing
I'm a little sore to see keep reoccurring, that I have to have 3 windows
open to understand the intent of a 10 line snippet in a driver..

-- 
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations

WARNING: multiple messages have this Message-ID (diff)
From: Matt Sealey <matt-sEEEE4iEDtaXzmuOJsdVMQ@public.gmane.org>
To: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
Cc: linuxppc-dev list
	<linuxppc-dev-mnsaURCQ41sdnm+yROfE0A@public.gmane.org>,
	avorontsov-hkdhdckH98+B+jHODAdFcQ@public.gmane.org,
	devicetree-discuss list
	<devicetree-discuss-mnsaURCQ41sdnm+yROfE0A@public.gmane.org>
Subject: Re: GPIO - marking individual pins (not) available in device tree
Date: Tue, 28 Oct 2008 14:46:38 -0500	[thread overview]
Message-ID: <49076C1E.8090501@genesi-usa.com> (raw)
In-Reply-To: <fa686aa40810281039v4f22a464u3eb1d421e1226fc8-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>



Grant Likely wrote:

> At this level, the 'compatible = "gpio-group";' is completely
> irrelevant.  The binding for "crystalfontz,something-gpio" must
> specify that there are two subnodes; one named data-bus and one named
> rw-ctrl.  The driver, which binds against compatible in the parent
> node, would know to go looking for those child nodes and to use the
> gpios property inside them.  Simple.

Point taken.

>>> Does this mean "hard-coding"?
>> No. If you have an array of GPIO pins (gpios property) then how do you
>> determine which is for data and which is some control pin? Do you
>> associate these numbers in the driver somehow? Maybe a matchlist or
>> an array? Given pins A B C D E F G H I J where does the data bus
>> start and the control pins live? A and B? A and J? I and J?
> 
> You know because you document it in the binding.

I think having a working device tree and a seperate binding document
sometimes slows things down. If it is not patently obvious what you
mean from a device tree, in order to write a new driver, the device
tree is not doing it's job..

Where the binding must take it's cue from established documentation,
and follows existing procedures and semantics, the binding is important
(for instance there are a few ways to check an interrupt fired on
MPC5200B, and Linux/dts encodes them per ONE table in the docs, this
must be referenced somewhere at least)

>> It would be definitely frivolous to define a whole device tree binding
>> for the *order in which you MUST specify the gpios for this particular
>> device*. There is obviously an implicit ordering of the GPIOs to make
>> up the data bus (you'd expect an order from MSB to LSB.. or perhaps
>> LSB to MSB... that might be better defined than undefined)
> 
> Why is it frivolous?  We do this all the time for reg and irqs.

See above. Does every driver require a ratified device tree binding
which is collaborated and agreed upon even though it may be in use on
one or two boards which actually may never see the light of day (I
bet none of you will ever see the CPLD core I'm sitting in front of
right now..)

I think it should be obvious both from the tree and inside the driver
what magical little sections of code do without cross-referencing, I
do far too much cross-referencing in Linux as it is, and it's one thing
I'm a little sore to see keep reoccurring, that I have to have 3 windows
open to understand the intent of a 10 line snippet in a driver..

-- 
Matt Sealey <matt-sEEEE4iEDtaXzmuOJsdVMQ@public.gmane.org>
Genesi, Manager, Developer Relations

  reply	other threads:[~2008-10-28 19:46 UTC|newest]

Thread overview: 76+ 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 21:32 ` 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  3:29         ` David Gibson
2008-10-24  4:17         ` Mitch Bradley
2008-10-24  4:17           ` Mitch Bradley
2008-10-24  4:45           ` David Gibson
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 20:10                         ` Anton Vorontsov
2008-10-27 21:56                         ` Matt Sealey
2008-10-27 21:56                           ` Matt Sealey
2008-10-27 23:12                           ` Anton Vorontsov
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  1:11                               ` Matt Sealey
2008-10-28  2:37                               ` Anton Vorontsov
2008-10-28 16:53                                 ` Matt Sealey
2008-10-28 16:53                                   ` Matt Sealey
2008-10-28 17:39                                   ` Grant Likely
2008-10-28 19:46                                     ` Matt Sealey [this message]
2008-10-28 19:46                                       ` Matt Sealey
2008-10-28  0:15                   ` David Gibson
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
2008-10-28  5:20                         ` Grant Likely
2008-10-24 22:03       ` Matt Sealey
2008-10-24 22:20         ` Stephen Neuendorffer
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 21:13             ` Matt Sealey
2008-10-26 23:53             ` David Gibson
2008-10-27 16:12               ` Matt Sealey
2008-10-27 16:12                 ` Matt Sealey
2008-10-27 16:35                 ` Scott Wood
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:38                             ` David Gibson
2008-10-28  0:34                 ` 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  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: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:11   ` Anton Vorontsov
2008-10-28 14:15 ` Grant Likely
2008-10-28 14:15   ` Grant Likely
2008-10-28 17:06   ` Matt Sealey
2008-10-28 17:06     ` Matt Sealey
2008-10-28 17:32     ` Grant Likely
2008-10-28 23:37 ` David Gibson
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=49076C1E.8090501@genesi-usa.com \
    --to=matt@genesi-usa.com \
    --cc=devicetree-discuss@ozlabs.org \
    --cc=grant.likely@secretlab.ca \
    --cc=linuxppc-dev@ozlabs.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 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.