The i2c-core driver mixes runtime suspend and system wide suspend, in
that, during a system wide suspend, it skips calling ->suspend if the
device is runtime suspended.
I have an interrupt controller running over the i2c bus and that driver
is oblivious of the runtime pm framework, IOW, it doesn't do any runtime
pm calls. CONFIG_RUNTIME_PM is enabled however (for some other bus
drivers). The issue I am facing is that all such i2c devices are assumed
runtime suspended and the ->suspend for these devices is not invoked
during systemwide suspend.
Looking around in pci and platform busses, they don't skip calling the
->suspend callback, actually, they dont check if the device is runtime
suspended.
The question is, why do we have this special check in i2c bus driver?
Pasted below is the relevant commit.
commit 2f60ba706bd9af84c4eab704243b262e69556f2e
i2c: Fix bus-level power management callbacks
There are three issues with the i2c bus type's power management
callbacks at the moment. ....
....
....
.... Finally, the system sleep PM
(ie. suspend/resume) callbacks don't check if the device has been
already suspended at run time, in which case they should skip
suspending it. Also, it looks like the i2c bus type can use the
generic subsystem-level runtime PM callbacks.
For these reasons, rework the system sleep PM callbacks provided by
the i2c bus type to handle hibernation correctly and to invoke the
"legacy" callbacks for drivers that provide them. In addition to
that make the i2c bus type use the generic subsystem-level runtime
PM callbacks.
Thanks,
Abhijeet
--
Sent by an employee of Qualcomm Innovation Center, Inc. The Qualcomm
Innovation Center, Inc. is a member of Code Aurora Forum.
On Thu, Dec 30, 2010 at 10:09 AM, Abhijeet Dharmapurikar
<[email protected]> wrote:
> The i2c-core driver mixes runtime suspend and system wide suspend, in that,
> during a system wide suspend, it skips calling ->suspend if the device is
> runtime suspended.
>
> I have an interrupt controller running over the i2c bus and that driver is
> oblivious of the runtime pm framework, IOW, it doesn't do any runtime pm
> calls. CONFIG_RUNTIME_PM is enabled however (for some other bus drivers).
> The issue I am facing is that all such i2c devices are assumed runtime
> suspended and the ->suspend for these devices is not invoked during
> systemwide suspend.
This was discussed on linux-pm recently. Rafael had a fix, I'm don't know
whether it's applied yet:
https://lists.linux-foundation.org/pipermail/linux-pm/2010-December/029567.html
https://lists.linux-foundation.org/pipermail/linux-pm/2010-December/029596.html
Also relevant:
https://lists.linux-foundation.org/pipermail/linux-pm/2010-December/029600.html
https://lists.linux-foundation.org/pipermail/linux-pm/2010-December/029658.html
On Thursday, December 30, 2010, Rabin Vincent wrote:
> On Thu, Dec 30, 2010 at 10:09 AM, Abhijeet Dharmapurikar
> <[email protected]> wrote:
> > The i2c-core driver mixes runtime suspend and system wide suspend, in that,
> > during a system wide suspend, it skips calling ->suspend if the device is
> > runtime suspended.
> >
> > I have an interrupt controller running over the i2c bus and that driver is
> > oblivious of the runtime pm framework, IOW, it doesn't do any runtime pm
> > calls. CONFIG_RUNTIME_PM is enabled however (for some other bus drivers).
> > The issue I am facing is that all such i2c devices are assumed runtime
> > suspended and the ->suspend for these devices is not invoked during
> > systemwide suspend.
>
> This was discussed on linux-pm recently. Rafael had a fix, I'm don't know
> whether it's applied yet:
>
> https://lists.linux-foundation.org/pipermail/linux-pm/2010-December/029567.html
> https://lists.linux-foundation.org/pipermail/linux-pm/2010-December/029596.html
Yes, the fix is already in the Linus' tree:
f08f5a0 PM / Runtime: Fix pm_runtime_suspended()
> Also relevant:
>
> https://lists.linux-foundation.org/pipermail/linux-pm/2010-December/029600.html
> https://lists.linux-foundation.org/pipermail/linux-pm/2010-December/029658.html
I'm not sure what happened to the last patch. Is there a new version?
If so, is it going to be pushed through the i2c tree, or should I take it?
Rafael
On Thu, Dec 30, 2010 at 11:49:30AM +0100, Rafael J. Wysocki wrote:
> On Thursday, December 30, 2010, Rabin Vincent wrote:
> > https://lists.linux-foundation.org/pipermail/linux-pm/2010-December/029658.html
> I'm not sure what happened to the last patch. Is there a new version?
> If so, is it going to be pushed through the i2c tree, or should I take it?
Jean appears to be on holiday for the Christmas vacation. I do have a
new version which I'll post later today. Since it depends on the patch
protoyping the generic API calls which the SPI patch also depends on
it'd probably be best to merge via your tree.