lkml.org 
[lkml]   [2010]   [Dec]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjecti2c runtime suspend and system wide suspend
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.




\
 
 \ /
  Last update: 2010-12-30 05:41    [W:0.084 / U:0.216 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site