[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121023104256.GB24820@arwen.pp.htv.fi>
Date: Tue, 23 Oct 2012 13:42:56 +0300
From: Felipe Balbi <balbi@...com>
To: Linus Walleij <linus.walleij@...aro.org>
CC: <balbi@...com>,
Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
"Rafael J. Wysocki" <rjw@...k.pl>,
Magnus Damm <damm@...nsource.se>,
Paul Mundt <lethal@...ux-sh.org>,
Benoit Cousson <b-cousson@...com>, <tony@...mide.com>,
<devicetree-discuss@...ts.ozlabs.org>,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
<linux-kernel@...r.kernel.org>, <linux-input@...r.kernel.org>,
Sourav Poddar <sourav.poddar@...com>,
<linux-omap@...r.kernel.org>,
<linux-arm-kernel@...ts.infradead.org>,
Amit Kucheria <amit.kucheria@...aro.org>,
Stephen Warren <swarren@...dotorg.org>
Subject: Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support
Hi,
On Tue, Oct 23, 2012 at 12:45:33PM +0200, Linus Walleij wrote:
> On Tue, Oct 23, 2012 at 12:29 PM, Felipe Balbi <balbi@...com> wrote:
> > On Tue, Oct 23, 2012 at 12:29:28PM +0200, Linus Walleij wrote:
>
> >> So the biggest implementation of the notifier approach to resource
> >> handling is the SH clock thing:
> >> drivers/base/power/clock_ops.c
> >
> > that's different right ? It's just creating the list of clocks, device
> > drivers still have to call pm_clk_add().
> >
> > That's ok, I guess, otherwise all struct device would allocate memory
> > which hardly ever used (so far).
>
> Hm so I have had this idea of runtime PM core helping out
> with pins, so I could add something like
>
> pm_pins_fetch()
> pm_pins_default()
> pm_pins_idle()
> pm_pins_sleep()
>
> So if one is using the pin states defined in <linux/pinctrl/pinctrl-state.h>
> then the PM core can help out in keeping track of the pins
> and states, and the driver will just tell the PM core what
> to do and when.
>
> Would this fit the bill for everyone's code consolidation needs?
> It would sure work for us...
>
> It however require that no custom states are used and that we
> keep to the state semantics I just happen to think is most
> common.
From a quick read, it looks ok. I guess problems will only how up when
we actually end up with a silicon errata or something similar which
mandates that we change pin's state at a particular location. Not sure
if we have those yet.
--
balbi
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists