[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdba4XM7Wr61pjXnBpgJY=U1F-772_ArfPDhjpRVd1NFUA@mail.gmail.com>
Date: Fri, 26 Aug 2011 09:57:49 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: Barry Song <21cnbao@...il.com>
Cc: Linus Walleij <linus.walleij@...ricsson.com>,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
Grant Likely <grant.likely@...retlab.ca>,
Stephen Warren <swarren@...dia.com>,
Russell King <linux@....linux.org.uk>,
Joe Perches <joe@...ches.com>,
Linaro Dev <linaro-dev@...ts.linaro.org>,
Lee Jones <lee.jones@...aro.org>
Subject: Re: [PATCH 0/4 v4] pin controller subsystem v4
On Fri, Aug 26, 2011 at 3:58 AM, Barry Song <21cnbao@...il.com> wrote:
> Do you want the pinmux_request_gpio called by the gpiolib driver or by
> every device driver who uses this gpio?
I always thought about the gpiolib driver.
I think Grant told me he wanted drivers with combined GPIO and
pinmuxing to reside in drivers/pinctrl and expose an additional
gpiolib interface.
> Do you think the following make sense in gpiolib driver?
> static int xxx_gpio_request(struct gpio_chip *chip, unsigned offset)
> {
> int ret = 0;
>
> ret = pinmux_request_gpio(chip->base + offset);
> if (ret)
> goto out;
> .....
> out:
> return ret;
> }
Looks sane to me. It's a bit unfortunate to have to subtract
the base and then add it again before passing to pinmux but
the idea is to drop the global GPIO pinspace down the road
and then it makes more sense.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists