Re: [PATCH v4 1/3] Runtime Interpreted Power Sequences
From: Thierry Reding <hidden>
Date: 2012-08-16 19:49:23
Also in:
linux-fbdev, linux-tegra, lkml
On Thu, Aug 16, 2012 at 12:38:33PM -0600, Stephen Warren wrote:
On 08/16/2012 12:08 AM, Alexandre Courbot wrote:quoted
diff --git a/Documentation/power/power_seq.txt b/Documentation/power/power_seq.txtquoted
+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
Attachments
- (unnamed) [application/pgp-signature] 836 bytes