[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BANLkTinaOk4Qq+uwdZQtapncwjpdTg9wmQ@mail.gmail.com>
Date: Wed, 20 Apr 2011 17:13:41 +0200
From: Linus Walleij <linus.ml.walleij@...il.com>
To: Haojian Zhuang <haojian.zhuang@...il.com>
Cc: Kyungmin Park <kmpark@...radead.org>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
Ben Nizette <bn@...sdigital.com>, linux-kernel@...r.kernel.org,
Grant Likely <grant.likely@...retlab.ca>,
Lee Jones <lee.jones@...aro.org>,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 1/2] gpio: add pin biasing and drive mode to gpiolib
2011/4/20 Haojian Zhuang <haojian.zhuang@...il.com>:
> Before suspend, it may be configured as some function that isn't GPIO.
> Is it a goal
> that avoid declaring gpio_request() for suspend and updating the setting of pin?
I refer to that as a totally different use case "pinmux or padmux"
which I think we are better off treating as totally orthogonal to GPIO.
I have loose ideas to break pin/pad muxing into a separate driver
directory under drivers/pinpadmux or something.
Some people inevitably think that GPIO and pin/padmux are
intertwined, but as far as I have seen they are not. However there
may be a cross dependency so that a GPIO driver may need to
export an additional pin/padmux interface or so, e.g we have
a separate chip in I2C which can mux pins...
However this is a separate issue altogether, I think we can assume
pin/padmuxing is in the board code until we have a suitable
solution for a framework for that. (Don't know if I'll be able to write
one though.)
> Are these two patches are post in mailing list? I can't find your
> second patch in this
> patch series?
I can see it here ... ?
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