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
signature.asc
Description: Digital signature
