public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Anton Vorontsov <cbouatmailru@gmail.com>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: Jamie Iles <jamie@jamieiles.com>,
	linux-kernel@vger.kernel.org, linux@arm.linux.org.uk,
	tglx@linutronix.de, arnd@arndb.de, nico@fluxnic.net,
	Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: [PATCHv3 0/7] gpio: extend basic_mmio_gpio for different controllers
Date: Wed, 4 May 2011 14:36:57 +0400	[thread overview]
Message-ID: <20110504103657.GA23772@oksana.dev.rtsoft.ru> (raw)
In-Reply-To: <20110504000055.GA4008@ponder.secretlab.ca>

On Tue, May 03, 2011 at 06:00:55PM -0600, Grant Likely wrote:
[...]
> From the device tree use-case, I personally still prefer a binding
> that provides a single 'reg' entry for the register block and explicit
> offsets in the binding to specify where/how the gpio registers are
> layed out.  It just fits better with existing binding practices.

Hm. AFAIK, it's quite the reverse. Existing device-tree bindings
practices prefer per-bank device bindings. Ie. MPC8xxx, CPM, QE,
Simple GPIOs, etc.

> Also, if you're talking about a gpio device with, say, 128 gpios on an
> soc, then the natural binding probably will be to have a single device
> tree node covering all 4 banks because that is the way the
> documentation lays out the device.  Perhaps something like this
> (completely off the top of my head):
> 
> gpio@fedc0000 {
> 	compatible = "acme,super-soc-gpio", "mmio-gpio";
> 	reg = <0xfedc0000 0x100>;
> 	gpio-controller;
> 	#gpio-cells = <1>;
> 
> 	mmgpio-regoffset-data = <0x00 0x04 0x08 0x0c>;
> 	mmgpio-regoffset-dir  = <0x20 0x24 0x28 0x2c>;
> 	mmgpio-regoffset-set  = <0x10 0x14 0x18 0x1c>;
> 	mmgpio-regoffset-clr  = <0x30 0x34 0x38 0x3c>;
> };
> 
> ... where an array of regoffset values allows for multiple banks.
> Although this might be completely insane and it would be better to
> make the kernel key directly off the 'acme,super-soc-gpio' value.

Oh, I really don't understand why you advocate this approach. It
gives us nothing, except maybe saving a few lines in the device
tree, but in return you abuse hierarchy (you flatten it). From the
hardware point of view, it's even worse -- the bindings would not
let us describe bank's power properties, sleep/wake behaviour etc.
Or this will lead to something like the ugly
mmgpio-sleep = <0 1 1 1>; maps.

I understand that with bgpio library both approaches may easily
coexist, so I'm mostly talking about device tree bindings here.

IMO, the thing we should approach with device tree is these bindings
(example from arch/powerpc/boot/dts/mpc832x_rdb.dts):

                par_io@1400 {
                        #address-cells = <1>;
                        #size-cells = <1>;
                        reg = <0x1400 0x100>;
                        ranges = <3 0x1448 0x18>;
                        compatible = "fsl,mpc8323-qe-pario";

                        qe_pio_d: gpio-controller@1448 {
                                #gpio-cells = <2>;
                                compatible = "fsl,mpc8323-qe-pario-bank";
                                reg = <3 0x18>;
                                gpio-controller;
                        };

			... more banks here ...
                }

Note that in this case bank's reg specifies the whole registers range,
which should be split into several reg entries (inside the reg = <>,
not reg-stuff1, reg-stuff2 thing).

Thanks,

-- 
Anton Vorontsov
Email: cbouatmailru@gmail.com

  reply	other threads:[~2011-05-04 10:37 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-11 11:21 [PATCHv3 0/7] gpio: extend basic_mmio_gpio for different controllers Jamie Iles
2011-04-11 11:21 ` [PATCHv3 1/7] basic_mmio_gpio: remove runtime width/endianness evaluation Jamie Iles
2011-05-03 19:41   ` Grant Likely
2011-04-11 11:21 ` [PATCHv3 2/7] basic_mmio_gpio: convert to platform_{get,set}_drvdata() Jamie Iles
2011-05-03 19:41   ` Grant Likely
2011-04-11 11:21 ` [PATCHv3 3/7] basic_mmio_gpio: allow overriding number of gpio Jamie Iles
2011-05-03 19:41   ` Grant Likely
2011-04-11 11:21 ` [PATCHv3 4/7] basic_mmio_gpio: request register regions Jamie Iles
2011-05-03 19:41   ` Grant Likely
2011-04-11 11:21 ` [PATCHv3 5/7] basic_mmio_gpio: detect output method at probe time Jamie Iles
2011-04-11 12:05   ` Anton Vorontsov
2011-05-03 19:42   ` Grant Likely
2011-04-11 11:21 ` [PATCHv3 6/7] basic_mmio_gpio: support different input/output registers Jamie Iles
2011-04-11 12:06   ` Anton Vorontsov
2011-05-03 19:42   ` Grant Likely
2011-04-11 11:21 ` [PATCHv3 7/7] basic_mmio_gpio: support direction registers Jamie Iles
2011-05-03 19:42   ` Grant Likely
2011-05-03 21:09 ` [PATCHv3 0/7] gpio: extend basic_mmio_gpio for different controllers Grant Likely
2011-05-03 21:13   ` Grant Likely
2011-05-03 21:36     ` Grant Likely
2011-05-03 21:52     ` Anton Vorontsov
2011-05-03 22:04       ` Jamie Iles
2011-05-03 22:34         ` Anton Vorontsov
2011-05-04  0:00           ` Grant Likely
2011-05-04 10:36             ` Anton Vorontsov [this message]
2011-05-04 11:09           ` Jamie Iles
2011-05-04 11:31             ` Anton Vorontsov
2011-05-04 14:37               ` Jamie Iles
2011-05-04 14:43                 ` Grant Likely
2011-05-04 14:44                 ` Alan Cox
2011-05-04 14:57                   ` Jamie Iles
2011-05-04 15:02                 ` Anton Vorontsov
2011-05-04 15:04                   ` Jamie Iles
2011-05-13 19:37                   ` Anton Vorontsov

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=20110504103657.GA23772@oksana.dev.rtsoft.ru \
    --to=cbouatmailru@gmail.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=arnd@arndb.de \
    --cc=grant.likely@secretlab.ca \
    --cc=jamie@jamieiles.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=nico@fluxnic.net \
    --cc=tglx@linutronix.de \
    /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