[PATCH 1/1] Revert "drm/i915: drop i915_ prefix from enable_rc6, enable_fbc, enable_ppgtt parameters"

[Daniel Vetter]

On Thu, Jul 17, 2014 at 02:32:41PM +0530, Amit Shah wrote:
> On (Thu) 17 Jul 2014 [09:35:20], Daniel Vetter wrote:
> > On Wed, Jul 16, 2014 at 9:54 PM, Linus Torvalds
> > <torvalds at linux-foundation.org> wrote:
> > > Sorry for the top post, I'm on the road..
> > >
> > > In wondering if we couldn't just keep both the old an the new names and have
> > > them both point at the same variable? Remove the description for the old
> > > name, but keep it working?
> > 
> > I'm really surprised here ... We have rc6 enabled by default
> > everywhere, and all the additional rc6 levels that users try to enable
> > are known to hard-hang machines.
> 
> I haven't had this problem on my hardware (ThinkPad T420s, lspci
> below) for a few kernel versions.  I think I added the enable_rc6=
> setting back from the time the deeper states were enabled and then
> reverted for SandyBridge.
> 
> Nevertheless, with the current state, RC6p and RC6pp states are not
> used.

Yeah, on snb they cause crashes and instability and also don't provide
measurable power benefits (afaik). So I recommend you drop that one.

> > I actually have plans to taint the
> > kernel if you set any of them since I'm fed up with the random crash
> > reports. Same for fbc, even more so or the ppgtt knob. My stance is
> > that if you know about these knobs you _really_ should know the driver
> > to its depths and so also be able to follow module parameter
> > renamings.
> 
> I also remember there being bugzillas about power consumption, and
> using this setting was recommended (for Fedora, I think).  I know
> a few people are using this setting.

I know, google is littered with such entries. Unfortunately by the time
google thinks something is important (which usually takes a few months)
it's already badly outdated: i915 graphics developement is charging ahead
at a really brisk pace - we merge a few hundred patches per release for
i915 alone.
 
> > > On Jul 16, 2014 8:34 AM, "Amit Shah" <amit.shah at redhat.com> wrote:
> > >>
> > >> This reverts commit 3adee7a7976012a20f1d3b5a529a3c105e29fef1.
> > >>
> > >> After upgrading to v3.15, my laptop's battery started draining quite
> > >> fast.  Powertop pointed to the deep RC6 states not being used.  The
> > >> kernel param I had put to enable them had stopped working the way it
> > >> used to; so I disagree with the 'not maintaing ABI' part of the param
> > >> name change.
> > >>
> > >> However weird the names may be, they're in active use and changing them
> > >> only causes pain for users.  This also isn't advertised (marked
> > >> deprecated, big warning shown, etc.), so just reverting now.
> > >>
> > >> CC: Daniel Vetter <daniel.vetter at ffwll.ch>
> > >> CC: Jani Nikula <jani.nikula at linux.intel.com>
> > >> CC: David Airlie <airlied at linux.ie>
> > >> CC: <stable at vger.kernel.org> # v3.15+
> > >> Signed-off-by: Amit Shah <amit.shah at redhat.com>
> > 
> > Anyway we need to figure out what went wrong here. Please share your
> > exact kernelcmdline and lspci -nn. Also stats for before/after from
> > powertop when idle please.
> 
> Powertop stats for idle are a little difficult -- since this is my
> primary laptop.

Now I'm a bit confused: How have you measured that the lack of rc6p/pp is
the reason for your power consumption regression?
-Daniel

> 
> BOOT_IMAGE=/vmlinuz-3.15.4-200.fc20.x86_64 root=/dev/mapper/luks-3aff2acf-737d-4002-b644-15f599d09a18 ro rd.lvm.lv=fedora_grmbl/00 rd.lvm.lv=fedora_grmbl/01 vconsole.font=latarcyrheb-sun16 rd.luks.uuid=luks-0934d354-5b07-4e91-a699-9bfc57e76fdc rd.luks.uuid=luks-3aff2acf-737d-4002-b644-15f599d09a18 rhgb quiet slub_debug=- i915.i915_enable_rc6=7 LANG=en_IN.UTF-8
> 
> 00:00.0 Host bridge [0600]: Intel Corporation 2nd Generation Core Processor Family DRAM Controller [8086:0104] (rev 09)
> 00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0126] (rev 09)
> 00:16.0 Communication controller [0780]: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 [8086:1c3a] (rev 04)
> 00:19.0 Ethernet controller [0200]: Intel Corporation 82579LM Gigabit Network Connection [8086:1502] (rev 04)
> 00:1a.0 USB controller [0c03]: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 [8086:1c2d] (rev 04)
> 00:1b.0 Audio device [0403]: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller [8086:1c20] (rev 04)
> 00:1c.0 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 [8086:1c10] (rev b4)
> 00:1c.1 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 2 [8086:1c12] (rev b4)
> 00:1c.3 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 4 [8086:1c16] (rev b4)
> 00:1c.4 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 5 [8086:1c18] (rev b4)
> 00:1d.0 USB controller [0c03]: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 [8086:1c26] (rev 04)
> 00:1f.0 ISA bridge [0601]: Intel Corporation QM67 Express Chipset Family LPC Controller [8086:1c4f] (rev 04)
> 00:1f.2 SATA controller [0106]: Intel Corporation 6 Series/C200 Series Chipset Family 6 port SATA AHCI Controller [8086:1c03] (rev 04)
> 00:1f.3 SMBus [0c05]: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller [8086:1c22] (rev 04)
> 03:00.0 Network controller [0280]: Intel Corporation Centrino Advanced-N 6205 [Taylor Peak] [8086:0085] (rev 34)
> 05:00.0 SD Host controller [0805]: Ricoh Co Ltd MMC/SD Host Controller [1180:e822] (rev 07)
> 0d:00.0 USB controller [0c03]: NEC Corporation uPD720200 USB 3.0 Host Controller [1033:0194] (rev 04)
> 
> 
> Thanks,
> 		Amit

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch