Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<blockquote> <p>Why are there so many suspend and resume function pointers? </p> </blockquote> <ol> <li><code>i2c_driver</code> - legacy support.</li> <li><code>device_driver</code> - standard support. </li> <li><code>dev_pm_ops</code> - extended power management.</li> </ol> <p>Notice that they are all <em>function pointers</em>. There is sequencing for the <em>suspend</em> and <em>resume</em>. For instance, the <strong>i2c</strong> controller must be <em>suspended</em> after the devices but <em>resumed</em> before. </p> <blockquote> <p>Some kind of legacy thing?</p> </blockquote> <p>The <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/i2c/i2c-core.c?id=refs/tags/v3.12-rc5#n302" rel="nofollow"><code>struct i2c_driver</code></a> is a legacy mechism. It existed before the entire power infrastructure was created. As well, some configurations may exclude the full <code>struct dev_pm_ops</code> pointer, but have the <code>suspend</code> and <code>resume</code> driver hooks. The full <code>struct dev_pm_ops</code> supports <em>suspend to disk</em> and other features. <em>Suspend to memory</em> is more common and is given pointers space in <code>struct device_driver</code>. If <code>struct dev_pm_ops</code> is non-NULL, the two pointer will be the same. These two should call the same routine in your driver.</p> <blockquote> <p>Which one should I use for my driver?</p> </blockquote> <p>You probably shouldn't use any of them. It is probably more likely that your driver is part of some other sub-system. <sup>see <strong>Note</strong></sup> For instance, the <em>i2c</em> is used in <em>codecs</em> like the <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/sound/soc/codecs/wm8940.c?id=refs/tags/v3.12-rc5#n674" rel="nofollow">wm8940.c</a>. Generally, <em>i2c</em> is not the central controlling sub-system. It is a driver that is used by something else to control a chip-set. The <em>sound</em> sub-system will be suspended before <em>i2c</em> and it is better to put your hooks there. If your driver is pure <em>i2c</em>, then use the macros in <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/linux/pm.h" rel="nofollow">pm.h</a>, like <code>SET_SYSTEM_SLEEP_PM_OPS</code> to conditionalize the setting of <code>dev_pm_ops</code>; so set both of them. Most likely the <code>device_driver</code> will be copied to <code>dev_pm_ops</code> if it exists, but doing it explicitly is better.</p> <p>The <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/driver-model/" rel="nofollow">driver-model</a>, <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/i2c/writing-clients?id=refs/tags/v3.12-rc5#n277" rel="nofollow">i2c power management</a> and <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/power/devices.txt" rel="nofollow">power driver</a> documentation have more information on the structure and overviews.</p> <p><strong>Note:</strong> In this case, there are multiple <code>device_driver</code> structures. Usually the <code>i2c_driver</code> is managed by a controlling driver. The controlling driver should implement a <code>suspend</code>/<code>resume</code> for it's sub-system, which uses the <code>i2c_driver</code> interface.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload