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
WARNING: multiple messages have this Message-ID (diff)
From: Jamie Iles <jamie@jamieiles.com>
To: Jamie Iles <jamie@jamieiles.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
Linus Walleij <linus.walleij@stericsson.com>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Grant Likely <grant.likely@secretlab.ca>,
Stephen Warren <swarren@nvidia.com>,
Russell King <linux@arm.linux.org.uk>,
Joe Perches <joe@perches.com>,
Linaro Dev <linaro-dev@lists.linaro.org>,
Lee Jones <lee.jones@linaro.org>, Arnd Bergmann <arnd@arndb.de>
Subject: Re: [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
next prev parent reply other threads:[~2011-08-21 14:24 UTC|newest]
Thread overview: 56+ 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 9:53 ` Linus Walleij
2011-08-19 10:48 ` Jamie Iles
2011-08-19 10:48 ` Jamie Iles
2011-08-19 14:04 ` Linus Walleij
2011-08-19 14:04 ` Linus Walleij
2011-08-19 14:26 ` Jamie Iles
2011-08-19 14:26 ` Jamie Iles
2011-08-21 14:24 ` Jamie Iles [this message]
2011-08-21 14:24 ` Jamie Iles
2011-08-22 12:38 ` Linus Walleij
2011-08-22 12:38 ` Linus Walleij
2011-08-22 12:54 ` Jamie Iles
2011-08-22 12:54 ` Jamie Iles
2011-08-19 14:36 ` Arnd Bergmann
2011-08-19 14:36 ` Arnd Bergmann
2011-08-19 16:52 ` Greg KH
2011-08-19 16:52 ` Greg KH
2011-08-22 12:29 ` Linus Walleij
2011-08-22 12:29 ` Linus Walleij
2011-08-21 14:53 ` Barry Song
2011-08-21 14:53 ` Barry Song
2011-08-24 6:24 ` Barry Song
2011-08-24 6:24 ` Barry Song
2011-08-24 7:41 ` Linus Walleij
2011-08-24 7:41 ` Linus Walleij
2011-08-24 18:29 ` Stephen Warren
2011-08-24 18:29 ` Stephen Warren
2011-08-25 10:12 ` Linus Walleij
2011-08-25 10:12 ` Linus Walleij
2011-08-25 11:04 ` Sascha Hauer
2011-08-25 11:04 ` Sascha Hauer
2011-08-25 11:58 ` Linus Walleij
2011-08-25 11:58 ` Linus Walleij
2011-08-25 12:07 ` Sascha Hauer
2011-08-25 12:07 ` Sascha Hauer
2011-08-25 15:12 ` David Brown
2011-08-25 15:12 ` David Brown
2011-08-25 18:14 ` Gregory Bean
2011-08-25 18:14 ` Gregory Bean
2011-08-25 19:13 ` Stephen Warren
2011-08-25 19:13 ` Stephen Warren
2011-08-26 8:35 ` Linus Walleij
2011-08-26 8:35 ` Linus Walleij
2011-08-26 17:33 ` Stephen Warren
2011-08-26 17:33 ` Stephen Warren
2011-08-29 8:40 ` Linus Walleij
2011-08-29 8:40 ` Linus Walleij
2011-08-26 3:12 ` Barry Song
2011-08-26 3:12 ` Barry Song
2011-08-26 8:36 ` Linus Walleij
2011-08-26 8:36 ` Linus Walleij
2011-09-02 7:02 ` Stijn Devriendt
2011-09-02 7:02 ` Stijn Devriendt
2011-09-02 7:57 ` Linus Walleij
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 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.