For the device to enter D3 we should enable PCH clock gating.

v2:
- use HAS_PCH_LPT instead of IS_HASWELL (Ville, Paolo)
- rename lpt_allow_clock_gating to lpt_suspend_hw (Paolo)
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We did not mention the workaround name when implementing those. This
should help us track what we already implement.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This should replace intel_using_power_well. The idea is that we're
adding the requested power domain as an argument, so this might enable
the code to look less platform-specific and also allows us to easily
add new domains in case we need.

v2: Add more domains to enum intel_display_power_domain
v3: Even more domains requested
Requested-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Both the docs and the existing code were wrong.  So fix both and use a
switch statement like we do elsewhere to make things simple & clear.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Instead of repeatedly bombarding the user with a request to reboot and
increase the stolen size with every fb refresh, just inform them the
first time only.

v2: Rearrange code so the hint to increase the amount of memory stolen
by the BIOS is only emitted if we fail to find sufficient stolen memory
for FBC.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
[danvet: Fixup formatting code mismatch that gcc spotted.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Our rps code relies on the interrupts being off to prevent re-arming
of the work items at inopportune moments.

Also drop the redundant cancel_work for the main rps work,
disable_gt_powersave already takes care of that.

Finally add a WARN_ON to ensure we obey that piece of ordering
constraint. Long term I want to lock down the setup/teardown code in a
similar way to how we painstakingly check modeset sequence constraints
already.

v2: Disable polling after hpd handling is shut down - since Egbert's
hpd irq storm handling the hotplug work can re-arm the polling
handler. Spotted by Jani Nikula.

Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We don't want to write reserved regs here, and may want to do other bits
in the future, so split it out.
Reported-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Ville noticed this while doing another review; we may as well cancel
this work just to make sure we don't try anything fancy after disabling
the RPS interfaces.
Reported-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

On VLV, the Punit doesn't automatically drop the GPU to it's minimum
voltage level when entering RC6, so we arm a timer to do it for us from
the RPS interrupt handler.  It'll generally only fire when we go idle
(or if for some reason there's a long delay between RPS interrupts), but
won't be re-armed again until the next RPS event, so shouldn't affect
power consumption after we go idle and it triggers.

v2: use delayed work instead of timer + work queue combo (Ville)
v3: fix up delayed work cancel (must be outside lock) (Daniel)
    fix up delayed work handling func for delayed work (Jesse)
v4: cancel delayed work before RPS shutdown (Jani)
    pass delay not absolute time to mod_delayed_work (Jani)
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Uses slightly different interfaces than other platforms.

v2: track actual set freq, not requested (Rohit)
    fix debug prints in init code (Jesse)
v3: don't write sleep reg (Jesse)
    re-add RC6 wake limit write (Ben)
    fixup thresholds to match other platforms (Ben)
    clean up mem freq calculation (Ben)
    clean up debug prints (Ben)
v4: move defines from punit patch (Ville)
v5: remove writes to nonexistent regs (Jesse)
    put RP and RC regs together (Jesse)
    fix RC6 enable (Jesse)
v6: use correct fuse reads from NC (Jesse)
    split out min/max funcs for use in sysfs (Jesse)
    add debugfs & sysfs freq controls (Jesse)
v7: update with Ben's hw_max changes (Jesse)
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net> (v6)
[danvet: Follow checkpatch sugggestion to use min_t to avoid casting
fun.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

When requesting frequency changes or querying status from the Punit, we
need to use an opcode that corresponds to the frequency, taking into
account the memory frequency.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Alway use the alphabetical names in debug/error messages for planes,
pipes and ports, instead of using decimal numbers occasionally.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Bits 30 and 24:0 are PBC, so don't zero them. Some of the other bits
are being zeroed, but I couldn't find a reason for this, so leave them
as they are for now to avoid regressions.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
[danvet: Delete the redudant #define that Imre spotted in his review.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Check the VBT to see if the machine has inverted FDI RX polarity on
CPT. Based on this bit, set the appropriate bit on the TRANS_CHICKEN2
registers.

This should fix some machines that were showing black screens on all
outputs.

Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60029Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We have the exact same comment inside intel_init_display. This is
a leftover from when we moved a lot of code from intel_display.c to
intel_pm.c.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Haswell introduces a separate frequency domain for the ring (uncore). So
where we used to increase the CPU (IA) clock with GPU busyness, we now
need to scale the ring frequency directly instead. As the ring limits
our memory bandwidth, it is vital for performance that when the GPU is
busy, we increase the frequency of the ring to increase the available
memory bandwidth.

v2: Fix the algorithm to actually use the scaled gpu frequency for the ring.
v3: s/max_ring_freq/min_ring_freq/ as that is what it is
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Add space checkpatch complained about.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

It returns true if we've requested to turn the power well on and it's
really on. It also returns true for all the previous gens.

For now there's just one caller, but I'm going to add more.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Requested-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Most importantly this will allow users to set overclock frequencies in
sysfs. Previously the max was limited by the RP0 max as opposed to the
overclock max. This is useful if one wants to either limit the max
overclock frequency, or set the minimum frequency to be in the overclock
range. It also fixes an issue where if one sets the max frequency to be
below the overclock max, they wouldn't be able to set back the proper
overclock max.

In addition I've added a couple of other bits:
Show the overclock freq. as max in sysfs
Print the overclock max in debugfs.
Print a warning if the user sets the min frequency to be in the
overclock range.

In this patch I've decided to store the hw_max when we read it from the
pcode at init. The reason I do this is the pcode reads can fail, and are
slow.

v2: Report when user requested overclocked max (Daniel)
Remove when user sets min to overclock range (Daniel)

Reported-by: freezer from #intel-gfx on irc
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
[danvet: Fixup the s/100MHz/50MHz/ confusion in an unrelated comment
that Mika spotted.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Interrupts, clock gating, LVDS, and GMBUS are all within the, "this will
be bad for CPU" range when we have PCH_NOP.

There is a bit of a hack in init clock gating. We want to do most of the
clock gating, but the part we skip will hang the system. It could
probably be abstracted a bit better, but I don't feel it's too
unsightly.

v2: Use inverse HAS_PCH_NOP check (Jani)

v3: Actually do what I claimed in v2 (spotted by Daniel)
Merge Ivybridge IRQ handler PCH check to decrease whitespace (Daniel)
Move LVDS bail into this patch (Ben)

v4: logical rebase conflict resolution with SDEIIR (Ben)
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>

Brush up patch a bit and resolve conflicts:
- Adjust PCH_NOP checks due to Egbert's hpd handling rework.
- Addd a PCH_NOP check in the irq uninstall code.
- Resolve conflicts with Paulo's SDE irq handling race fix.

v5: Drop the added hunks in the ilk irq handler again, they're bogus.
OOps.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We don't need this until we start using the wait event commands.

v2: move to i915_irq.c (Jesse)
    drop unneeded sprite flip done enables (Ville)
v3: drop the DPFLIPSTAT enables altogether (Ville)
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Slightly different than other platforms.

v2 [Jani]: Fix IOSF_BYTE_ENABLES_SHIFT shift. Use common routine.
v3: drop turbo defines from this patch (Ville)
    use PCI_DEVFN(2,0) instead of open coding (Ville)
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
[danvet: Add checkpatch bikeshed about missing space.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

According to HSW PM programming guide, frequency bits starts at
24 instead of 25.

v2: Paulo Zanoni noticed that only frequency bits can be set at
GEN6_RPNSWREQ. All others are read only.

CC: Ben Widawsky <ben@bwidawsk.net>
CC: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

HSW doesn't overclock the same way as IVB or SNB. I do not know about
VLV, so I've kept that off as well. I'm still working on getting the doc
updates to explain how we overclock on Haswell.

Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Add missing () spotted by Wu Fengguang's kernel build robot.
Acked by Ben.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We're still not 100% ready to disable the power well, so don't disable
it for now. When we disable it we break the audio driver (because some
of the audio registers are on the power well) and machines with eDP on
port D (because it doesn't use TRANSCODER_EDP).

Also, instead of just reverting the code, add a Kernel option to let
us disable it if we want. This will allow us to keep developing and
testing the feature while it's not enabled.

This fixes problems caused by the following commit:
  commit d6dd9eb1
  Author: Daniel Vetter <daniel.vetter@ffwll.ch>
  Date:   Tue Jan 29 16:35:20 2013 -0200
       drm/i915: dynamic Haswell display power well support

References: http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg18788.html
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Mengdong Lin <mengdong.lin@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Bspec mentions this for HSW+. I can't quite tell what the effects are,
and I don't easily have a way to test this.
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Change the gen6+ max delay if the pcode read was successful (not the
inverse).

The previous code was all sorts of wrong and has existed since I broke
it:
commit 42c0526c
Author: Ben Widawsky <ben@bwidawsk.net>
Date:   Wed Sep 26 10:34:00 2012 -0700

    drm/i915: Extract PCU communication

I added some parentheses for clarity, and I also corrected the debug
message message to use the mask (wrong before I came along) and added a
print to show the value we're changing from.

Looking over the code, I'm not actually sure what we're trying to do. I
introduced the bug simply by extracting the function not implementing
anything new. We already set max_delay based on the capabilities
register (which is what we use elsewhere to determine min and max).
This would potentially increase it, I suppose? Jesse, I can't find the
document which explains the definitions of the pcode commands, maybe you
have it around.

Based on Jesse's response, this could potentially be for -fixes, or
stable, or maybe lead to us dropping it entirely. As the current code is
is, things won't completely break because of the aforementioned
capabilities register, and in my experimentation, enabling this has no
effect, it goes from 1100->1100.

I found this while reviewing Jesse's VLV patches.

Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Bikeshed-away the redudant parens spotted by Chris Wilson.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We'll re-enable select bits as needed after testing and power measurement.

v2: split out wake handling bits (Jani)
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Can prevent a hang when we get to tessellation.  We need to set bit 15
as well for this workaround.

v2: update changelog with accurate info
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We could split this out into a separate routine at some point as an
optimization.

v2: use FORCEWAKE_KERNEL (Ville)

Note: Ville mentioned in his review that he declines to be responsible
if this blows up due to the lack of "readback a register != FW_ACK,
but from the same cacheline" magic we have in other forcewake
implementations.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Bikeshed overtly long lines according to checkpatch.pl. Nope,
this time around I didn't screw up printk message since I've left
those alone.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We're starting to add many IS_HASWELL checks for the power well code,
so add a HAS_POWER_WELL macro to properly document that we're checking
for hardware that has the power down well.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Resolve conflicts since some converted code was added by
not-yet merged patches.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Even if "power power" is good for grepping.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This increases GEN6_RC6p_THRESHOLD from 100000 to 150000. For some
reason this avoids the gen6_gt_check_fifodbg.isra warnings and
associated GPU lockups, which makes my ivy bridge machine stable.
Signed-off-by: NStéphane Marchesin <marcheu@chromium.org>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Kill the HSW check from the single thread force wake code. HSW
uses MT force wake exclusively these days.

The commit that removed HSW single thread forcewake support:

 commit 36ec8f87
 Author: Daniel Vetter <daniel.vetter@ffwll.ch>
 Date:   Thu Oct 18 14:44:35 2012 +0200

    drm/i915: unconditionally use mt forcewake on hsw/ivb
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Use the number '1' instead of FORCEWAKE_KERNEL when requesting single
thread force wake since there is only one bit in the register. Using
the FORCEWAKE_KERNEL name might give someone the wrong impression.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The MT forcewake ACK register also has a corresponding bit to each of
the bits in the MT forcewake register. Use the define we have for the
bit we care about instead of a hardcoded number.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This has been lost in the locking rework for intel_alloc_context_page:

commit 2c34b850
Author: Ben Widawsky <ben@bwidawsk.net>
Date:   Sat Mar 19 18:14:26 2011 -0700

    drm/i915: fix ilk rc6 teardown locking

Cc: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Some early bios versions seem to ship with the wrong tuning values for
the MCH, possible resulting in pipe underruns under load. Especially
on DP outputs this can lead to black screen, since DP really doesn't
like an occasional whack from an underrun.

Unfortunately the registers seem to be locked after boot, so the only
thing we can do is politely point out issues and suggest a BIOS
upgrade.

Arthur Runyan pointed us at this issue while discussion DP bugs - thus
far no confirmation from a bug report yet that it helps. But at least
some of my machines here have wrong values, so this might be useful in
understanding bug reports.

v2: After a bit more discussion with Art and Ben we've decided to only
the check the watermark values, since the OREF ones could be be a
notch more aggressive on certain machines.

Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Runyan, Arthur J <arthur.j.runyan@intel.com>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Dumps annoying noise into the dmesg:

[drm:intel_set_power_well] *ERROR* Timeout enabling power well
Reported-by: NSedat Dilek <sedat.dilek@gmail.com>
Cc: Sedat Dilek <sedat.dilek@gmail.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: NSedat Dilek <sedat.dilek@gmail.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>