All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anton Vorontsov <avorontsov@ru.mvista.com>
To: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH RFC 0/7] "NAND on UPM" and related patches
Date: Wed, 12 Dec 2007 15:47:32 +0300	[thread overview]
Message-ID: <20071212124732.GA3904@localhost.localdomain> (raw)
In-Reply-To: <20071211003647.GB12363@localhost.localdomain>

On Tue, Dec 11, 2007 at 11:36:47AM +1100, David Gibson wrote:
[...]
> > > > OF device tree GPIOs bindings are similar to IRQs:
> > > > 
> > > > node {
> > > > 	gpios = <bank pin bank pin bank pin>;
> > > > 	gpio-parent = <&par_io_controller>;
> > > > };
> > > > 
> > > > "bank pin" scheme is controller specific, so controllers that want
> > > > to implement flat mappings or any other could do so.
> > > 
> > > It might be safest to do as is done for interrupts, and not define the
> > > internal format at all.
> > 
> > This is how it is done already. Take a look into second and third patches:
> > 
> > +static int par_io_xlate(struct device_node *np, int index)
> > +{
> > +       return __of_parse_gpio_bank_pin(np, index, 32, num_par_io_ports);
> > +}
> > +
> > +static struct of_gpio_chip of_gpio_chip = {
> > +       .xlate = par_io_xlate,
> > +};
> > 
> > __of_parse_gpio_bank_pin() is helper function, I just factored
> > it out, because both QE and CPM2 using same format.
> > 
> > But generally, controllers are encouraged to do their own xlates.
> > 
> > Or am I missing the point?
> 
> Right, but you are assuming a fixed size (2 cells?)

Nope, of_get_gpio() doesn't assume that, but per-controller's .xlate()
is free to assume (and check) that, right.

> for the bank/pin
> information, arent' you - I didn't see any #gpio-cells or similar
> looking property.

Well, per-controller .xlate() is checking for correct cell count
(just reminding -- __of_parse_gpio_bank_pin is helper function,
controllers are free to implement their own):

int __of_parse_gpio_bank_pin(struct device_node *np, int index,
                             int bank_width, int max_bank)
{
...
        gpios = of_get_property(np, "gpios", &len);
        len /= sizeof(u32);

        if (len < 2 || len % 2 || index > len / 2 - 1)
                return -EINVAL;
...
}

On the other hand, I might indeed introduce #gpio-cells, and move
that check into generic of_get_gpio(), which will use #gpio-cells.
I think this is good idea anyway, so I'll just do it. ;-)

> I'm wondering if some gpio controllers might want
> less (only one bank) or more (bank, pin, polarity/flags perhaps).

Yup, they might. With #gpio-cells or without. The matter of where
to place sanity checks.


Much thanks,

-- 
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2

  reply	other threads:[~2007-12-12 12:44 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-10 20:47 [PATCH RFC 0/7] "NAND on UPM" and related patches Anton Vorontsov
2007-12-10 20:48 ` [PATCH RFC 1/7] [POWERPC] Implement GPIO API embryo Anton Vorontsov
2007-12-12 16:48   ` Scott Wood
2007-12-12 17:10     ` Anton Vorontsov
2007-12-10 20:48 ` [PATCH RFC 2/7] [POWERPC] QE: implement GPIO API Anton Vorontsov
2007-12-10 20:48 ` [PATCH RFC 3/7] [POWERPC] CPM2: " Anton Vorontsov
2007-12-12 15:49   ` Jochen Friedrich
2007-12-12 16:03     ` Anton Vorontsov
2007-12-12 16:56   ` Scott Wood
2007-12-10 20:49 ` [PATCH RFC 4/7] [GPIO] Let drivers link if they support GPIO API as an addition Anton Vorontsov
2007-12-10 22:55   ` David Brownell
2007-12-10 23:04     ` Anton Vorontsov
2008-02-22 23:42       ` David Brownell
2008-02-22 23:35         ` Anton Vorontsov
2007-12-10 20:49 ` [PATCH RFC 5/7] [POWERPC] FSL UPM: routines to manage FSL UPMs Anton Vorontsov
2007-12-10 20:49 ` [PATCH RFC 6/7] [POWERPC][NAND] FSL UPM NAND driver Anton Vorontsov
2007-12-10 20:49 ` [PATCH RFC 7/7] [POWERPC] MPC8360E-RDK: add support for NAND on UPM Anton Vorontsov
2007-12-10 23:03   ` David Gibson
2007-12-10 23:16     ` Anton Vorontsov
2007-12-12 16:59   ` Scott Wood
2007-12-10 23:04 ` [PATCH RFC 0/7] "NAND on UPM" and related patches David Gibson
2007-12-10 23:10   ` Anton Vorontsov
2007-12-11  0:36     ` David Gibson
2007-12-12 12:47       ` Anton Vorontsov [this message]
2007-12-16  6:44         ` David Gibson
2007-12-12 16:39 ` Scott Wood
2007-12-12 16:40 ` Scott Wood
2007-12-12 16:55   ` Anton Vorontsov
2007-12-12 16:54     ` Scott Wood
2007-12-12 20:58       ` Anton Vorontsov
2007-12-12 21:06         ` Scott Wood
2007-12-12 21:13           ` Scott Wood
2007-12-13 14:09           ` Anton Vorontsov
2007-12-13  3:01 ` Chris Fester

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=20071212124732.GA3904@localhost.localdomain \
    --to=avorontsov@ru.mvista.com \
    --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.