Massive power regression going 3.4->3.5

[James Bottomley]

On Mon, 2012-07-30 at 10:46 +0100, James Bottomley wrote:
> On Sun, 2012-07-29 at 21:25 +0200, Rafael J. Wysocki wrote:
> > On Sunday, July 29, 2012, Rafael J. Wysocki wrote:
> > > On Sunday, July 29, 2012, James Bottomley wrote:
> > > > On Sat, 2012-07-28 at 22:29 +0200, Rafael J. Wysocki wrote:
> > > > > On Saturday, July 28, 2012, Rafael J. Wysocki wrote:
> > > > > > On Saturday, July 28, 2012, James Bottomley wrote:
> > > > > > > One of the great things about the 3.4 kernel was the massive increase in
> > > > > > > power savings on my x220i laptop.  With full PCI suspend, it could get
> > > > > > > down to 6.5W in idle with a dim screen, provided I used powertop 2.0 to
> > > > > > > activate all the tunings).  I just upgraded to 3.5 (the openSUSE
> > > > > > > tumbleweed kernel) and all the power savings are gone.  Now it's back to
> > > > > > > its previous behaviour of idle somewhere between 16-18W.
> > > > > > 
> > > > > > Please check dbe9a2e (ACPI / PM: Make acpi_pm_device_sleep_state() follow the
> > > > > > specification) for starters.
> > > > > > 
> > > > > > If that is not the culprit, 38c92ff (ACPI / PM: Make __acpi_bus_get_power()
> > > > > > cover D3cold correctly) is worth ckecking too.
> > > > > > 
> > > > > > If none of the above, c2fb8a3 (USB: add NO_D3_DURING_SLEEP flag and revert
> > > > > > 151b61284776be2) is one more candidate.
> > > > > > 
> > > > > > I can't recall anything else that might be related to the symptom at the moment.
> > > > > 
> > > > > Actually, dbe9a2e and c2fb8a3 only affect system suspend, so for runtime PM
> > > > > 38c92ff seems to be the only relevant one from the above.
> > > > 
> > > > I verified the problem shows up on vanilla 3.5 (just in case it was an
> > > > openSUSE problem).  I also tried reverting 38c92ff with no success.  The
> > > > symptoms appear to be that something is preventing the PCI/device
> > > > subsystem from going into auto suspend.
> > > 
> > > The number of core power management commits during the 3.5 cycle was rather
> > > limited and none of them should affect PCI runtime PM.  I have no idea what
> > > the root cause of that may be, quite frankly.
> > 
> > I've just realized that you said "auto suspend", which makes me think that the
> > problem may be related to USB.
> > 
> > PCI doesn't really use any kind of auto suspend for what I know, but USB does
> > and it may cause PCI USB controllers to be suspended as a result.
> 
> I'm trying to bisect this, but I've got stuck around here:
> 
> git bisect bad 2f78d8e249973f1eeb88315e6444e616c60177ae
> git bisect good 28f3d717618156c0dcd2f497d791b578a7931d87
> 
> That's around the drm tree ... unfortunately that broke a lot of the
> basics of my i915 based system (compositing and resolution) as I step
> into it.

OK, I've run the bisect as far as I can.  It looks to be in the drm
tree.  Unfortunately, this tree has several merge points, some of which
go further back than v3.4.  Unfortunately, once the bisect steps back
before 3.4, we lose the changes that gave us the power savings, making
further debugging impossible

Here's the log

git bisect start
# bad: [28a33cbc24e4256c143dce96c7d93bf423229f92] Linux 3.5
git bisect bad 28a33cbc24e4256c143dce96c7d93bf423229f92
# bad: [28a33cbc24e4256c143dce96c7d93bf423229f92] Linux 3.5
git bisect bad 28a33cbc24e4256c143dce96c7d93bf423229f92
# good: [76e10d158efb6d4516018846f60c2ab5501900bc] Linux 3.4
git bisect good 76e10d158efb6d4516018846f60c2ab5501900bc
# good: [59cd358a7a5b2f6b61faa01dae6cfda3830ac62a] Merge tag 'perf-core-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent
git bisect good 59cd358a7a5b2f6b61faa01dae6cfda3830ac62a
# bad: [7e5b2db77b05746613516599c916a8cc2e321077] Merge branch 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus
git bisect bad 7e5b2db77b05746613516599c916a8cc2e321077
# good: [f9369910a6225b8d4892c3f20ae740a711cd5ace] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/signal
git bisect good f9369910a6225b8d4892c3f20ae740a711cd5ace
# bad: [2f78d8e249973f1eeb88315e6444e616c60177ae] Merge tag 'firewire-updates' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394
git bisect bad 2f78d8e249973f1eeb88315e6444e616c60177ae
# good: [28f3d717618156c0dcd2f497d791b578a7931d87] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
git bisect good 28f3d717618156c0dcd2f497d791b578a7931d87
# bad: [b3daeaef559d87b974c13a096582c5c70dc11061] drm/i915: move rps/emon function declarations
git bisect bad b3daeaef559d87b974c13a096582c5c70dc11061
# bad: [246bdbeb0f0fb14c4c085b6ed7edbab11afccd33] drm/i915: share forcewaking code between IVB and HSW
git bisect bad 246bdbeb0f0fb14c4c085b6ed7edbab11afccd33

If you do a gitk on the last bad and good 

gitk 28f3d717618156c0dcd2f497d791b578a7931d87..246bdbeb0f0fb14c4c085b6ed7edbab11afccd33

You see there are only drm commits in there.

James