On Thu, Aug 16, 2012 at 12:38:33PM -0600, Stephen Warren wrote: > On 08/16/2012 12:08 AM, Alexandre Courbot wrote: > > diff --git a/Documentation/power/power_seq.txt b/Documentation/power/power_seq.txt > > > +Usage by Drivers and Resources Management > > +----------------------------------------- > > +Power sequences make use of resources that must be properly allocated and > > +managed. The power_seq_build() function builds a power sequence from the > > +platform data. It also takes care of resolving and allocating the resources > > +referenced by the sequence if needed: > > + > > + struct power_seq *power_seq_build(struct device *dev, struct list_head *ress, > > + struct platform_power_seq *pseq); > > + > > +The 'dev' argument is the device in the name of which the resources are to be > > +allocated. > > + > > +The 'ress' argument is a list to which the resolved resources are appended. This > > +avoids allocating a resource referenced in several power sequences multiple > > +times. > > I see in other parts of the thread, there has been discussion re: > needing the separate ress parameter, and requiring the driver to pass > this in to multiple power_seq_build calls. > > The way the pinctrl subsystem solved this was to have a single function > that parsed all pinctrl setting (c.f. all power sequences) at once, and > return a single handle. Later, the driver passes this handle > pinctrl_lookup_state(), along with the requested state (c.f. sequence > name) to search for, and finally passes that handle to > pinctrl_select_state(). Doing something similar here would result in: > > struct power_seqs *power_seq_get(struct device *dev); > void power_seq_put(struct power_seqs *seqs); > struct power_seq *power_seq_lookup(struct power_seqs *seqs, > const char *name); > int power_seq_executestruct power_seq *seq); > > struct power_seqs *devm_power_seq_get(struct device *dev); > void devm_power_seq_put(struct power_seqs *seqs); Hehe, this looks very much like what I had in mind when I proposed this during the last version of this series. The nice thing about this is that the API is very much in line with how other subsystems work. Thierry
Attachment:
pgpTOuFDQw1jH.pgp
Description: PGP signature
