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 <ba...@ti.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

Attachment: signature.asc
Description: Digital signature

Reply via email to