linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: jamie@jamieiles.com (Jamie Iles)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/4 v4] drivers: create a pin control subsystem
Date: Sun, 21 Aug 2011 15:24:17 +0100	[thread overview]
Message-ID: <20110821142416.GA12272@gallagher> (raw)
In-Reply-To: <20110819142608.GB2800@pulham.picochip.com>

Hi Linus,

On Fri, Aug 19, 2011 at 03:26:08PM +0100, Jamie Iles wrote:
> On Fri, Aug 19, 2011 at 04:04:54PM +0200, Linus Walleij wrote:
> > On Fri, Aug 19, 2011 at 12:48 PM, Jamie Iles <jamie@jamieiles.com> wrote:
[...]
> > But yes, there is an assumption that each pin controller will only
> > deal with one block of GPIO pins. So if I make it possible to support
> > several GPIO ranges for one pin controller, does that solve your problem?
> > 
> > Like this:
> > 
> > struct pinctrl_gpio_range {
> >     char *name;
> >     unsigned int base;
> >     unsigned int npins;
> > }
> > 
> > static unsigned int gpio_ranges[] = {
> >     {
> >         .name="chip1",
> >         .base = 0,
> >         .npins = 16,
> >     },
> >     {
> >         .name =" chip2",
> >         .base = 32,
> >         .npins = 16,
> >     },
> >     {
> >         .name = "chip3",
> >         .base = 64,
> >         .npins = 16,
> >     },
> > };
> > 
> > static struct pinctrl_desc foo_desc = {
> >         ...
> >         .gpio_ranges = gpio_ranges,
> >         .num_gpio_ranges = ARRAY_SIZE(gpio_ranges),
> > };
> > 
> > For three different 32-bit GPIO controllers muxed on
> > pins 0..31 using GPIO space pins from 0..95.
> > 
> > Then I pass the number of the instance down to the
> > driver in the gpio_request_enable() callback like
> > this:
> > 
> > int (*gpio_request_enable) (struct pinctrl_dev *pctldev,
> > 	    unsigned instance,
> > 	    unsigned offset);
> > 
> > Would this work?
> > 
> > This has a restriction: the GPIO space must be mapped in
> > continous ranges, as must the pin controller. Else we need
> > one entry per pin in the list above...

One more thing that I thought of is that for device tree, when the gpio 
controllers are registered, the base is typically dynamically assigned.  I 
suspect that this can be solved in the device tree binding for the controller 
that references the bindings of the pinctrl, but this would require 
registering the gpio_ranges at runtime (or at least the bases).

So perhaps if we had:

struct pinctrl_gpio_range {
    unsigned int pinctrl_base;
    struct gpio_chip *chip;
}

and then gpio_request_enable was:

int (*gpio_request_enable)(struct pinctrl_dev *pctldev,
			   struct gpio_chip *gc,
			   unsigned offset)

Then have pinctrl_register_gpio_chip()?

For the static devices case then we can require gc->base must match the 
pinctrl gpio base.  For the device tree case we could do some matching of 
device_nodes from the gpio_chip to the pinctrl definitions?

Jamie

  reply	other threads:[~2011-08-21 14:24 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-19  9:53 [PATCH 1/4 v4] drivers: create a pin control subsystem Linus Walleij
2011-08-19 10:48 ` Jamie Iles
2011-08-19 14:04   ` Linus Walleij
2011-08-19 14:26     ` Jamie Iles
2011-08-21 14:24       ` Jamie Iles [this message]
2011-08-22 12:38         ` Linus Walleij
2011-08-22 12:54           ` Jamie Iles
2011-08-19 14:36     ` Arnd Bergmann
2011-08-19 16:52       ` Greg KH
2011-08-22 12:29         ` Linus Walleij
2011-08-21 14:53 ` Barry Song
2011-08-24  6:24 ` Barry Song
2011-08-24  7:41   ` Linus Walleij
2011-08-24 18:29 ` Stephen Warren
2011-08-25 10:12   ` Linus Walleij
2011-08-25 11:04     ` Sascha Hauer
2011-08-25 11:58       ` Linus Walleij
2011-08-25 12:07         ` Sascha Hauer
2011-08-25 15:12     ` David Brown
2011-08-25 18:14       ` Gregory Bean
2011-08-25 19:13     ` Stephen Warren
2011-08-26  8:35       ` Linus Walleij
2011-08-26 17:33         ` Stephen Warren
2011-08-29  8:40           ` Linus Walleij
2011-08-26  3:12 ` Barry Song
2011-08-26  8:36   ` Linus Walleij
2011-09-02  7:02 ` Stijn Devriendt
2011-09-02  7:57   ` Linus Walleij

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=20110821142416.GA12272@gallagher \
    --to=jamie@jamieiles.com \
    --cc=linux-arm-kernel@lists.infradead.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 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).