Replace the wait for the ring to be clear with the more common wait for
the ring to be idle. The principle advantage is one less exported
intel_ring_wait function, and the removal of a hardcoded value.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Also document the WA name for the previous gens that implement it.
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We need to enable a special bit, otherwise none of the DP functions
requiring the PCH will work.

Version 2: store the PCH ID inside dev_priv, as suggested by Daniel
Vetter.
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>

DIV_ROUND_CLOSEST is faster if the compiler knows it will only be
dealing with unsigned dividends. This optimization rips 32 bytes of
binary code on x86_64.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: David Airlie <airlied@linux.ie>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The specs for gen2 say that the watermark values "should always be set
assuming a 32bpp display mode, even though the display mode may be 15 or
16 bpp."
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This allows the power related code to run independently of the rest of
the pipeline, extending the resume and init time improvements into
userspace, which would otherwise have been blocked on the struct mutex
if we were doing PCU communication.

v2: Also convert the locking for the rps sysfs interface.
Suggested-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v1)
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Communicating via the mailbox registers with the PCU can take quite
awhile.  And updating the ring frequency or enabling turbo is not
something that needs to happen synchronously, so take it out of our init
and resume paths to speed things up (~200ms on my T420).

v2: add comment about why we use a work queue (Daniel)
    make sure work queue is idle on suspend (Daniel)
    use a delayed work queue since there's no hurry (Daniel)
v3: make cleanup symmetric and just call cancel work directly (Daniel)
v4: schedule the work using round_jiffies_up to batch work better (Chris)
v5: fix the right schedule_delayed_work call (Chris)

References: https://bugs.freedesktop.org/show_bug.cgi?id=54089Signed-of-by: NJesse Barnes <jbarnes@virtuougseek.org>
[danvet: bikeshed the placement of the new delayed work, move it to
all the other gen6 power mgmt stuff.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Workaround for dual port PS dispatch on GT1.

v2: pull in register definition & offset handling
v3: use IVB GT1 macro to get the right regs (Ben)
v4: add for VLV too (Ben)
v5: don't read the reg, it's masked so we'll only enable the one extra bit (Chris)
v6: use a _GT2 suffix for the second reg (Chris)
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NAntti Koskipää <antti.koskipaa@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This allows us to get the right vblank interrupt frequency.

v2: pull in register definition
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NAntti Koskipää <antti.koskipaa@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

References: https://bugs.freedesktop.org/show_bug.cgi?id=50250Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NAntti Koskipää <antti.koskipaa@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

v2: use correct register
v3: remove extra hunks, pull in register definitions & offset check directly
v4: add GT1 vs GT2 distinction for IVB portion (Ben)

References: https://bugs.freedesktop.org/show_bug.cgi?id=50233Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NAntti Koskipää <antti.koskipaa@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Needs to be set on every context restore as well, so set it as part of
the initial state so we can save/restore it.  Note this removes the IVB
workaround value from VLV and uses the default value, just adding in the
L3 cache aging disable bit, since the IVB value is wrong for VLV.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NAntti Koskipää <antti.koskipaa@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Now that we no longer pretend to have flexibility in matching any
north display block with any pch, we can ditch this.

v2: Fix the embarassing rebase fail that Paulo Zanoni spotted.
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Found in Bspec vol4h South Display Engine Registers [CPT, PPT],
section "5.3.1  TRANS_CHICKEN_1—Transcoder Chicken Bits 1"

v2: Make it compile.
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We need to set the timing override chicken bit after fdi link training
has completed and before we enable the transcoder. We also have to
clear that bit again after disabling the pch transcoder.

See "Graphics BSpec: vol4g North Display Engine Registers [IVB],
Display Mode Set Sequence" and "Graphics BSpec: vol4h South Display
Engine Registers [CPT, PPT], South Display Engine Transcoder and FDI
Control, Transcoder Debug and DFT, TRANS_CHICKEN_2" bit 31:

"Workaround : Enable the override prior to enabling the transcoder.
Disable the override after disabling the transcoder."

While at it, use the _PIPE macro for the other TRANS_DP register.

v2: Keep the w/a as-is, but kill the original (but wrongly placed)
workaround introduced in

commit 3bcf603f
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Wed Jul 27 11:51:40 2011 -0700

    drm/i915: apply timing generator bug workaround on CPT and PPT

and

commit d4270e57
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Tue Oct 11 10:43:02 2011 -0700

    drm/i915: export a CPT mode set verification function

Note that this old code has unconditionally set the w/a, which might
explain why fdi link training sometimes silently fails, and especially
why the auto-train did not seem to work properly.

v3: Paulo Zanoni pointed out that this workaround is also required on
the LPT PCH. And Arthur Ranyan confirmed that this workaround is
requierd for all ports on the pch, not just DP: The important part
is that the bit is set whenever the pch transcoder is enabled, and
that it is _not_ set while the fdi link is trained. It is also
important that the pch transcoder is fully disabled, i.e. we have to
wait for bit 30 to clear before clearing the w/a bit.

Hence move to workaround into enable/disable_transcoder, where the pch
transcoder gets enabled/disabled.

v4: Whitespace changes dropped.

v5: Don't run the w/a on IBX, we only need it on CPT/PPT and LPT.

v6:
- resolve conflicts with Paulo's big hsw vga rework
- s/!IBX/CPT since hsw paths are now all separate, and Paulo's patch
  to implement the equivalent w/a for LPT is already merged.

Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Paulo Zanoni <przanoni@gmail.com>
Cc: Arthur Ranyan <arthur.j.runyan@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v5)
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v5)
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Fix power well control state by reading real register offset.
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Comment says for eaglelake/cantiga, but it's listed in the ilk table,
too. So apply it to both.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We were programming register 0x42020 twice on those platforms. Once
should be enough.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

With the consolidated registers, it appears that we're setting the same
bis several times. Let's just collect the bits we want to set and program
it once.

v2: More cleanup. Also program 0x42004 and 0x45000 for FBC on non
    mobile platforms (Paulo Zanoni)
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
[danvet: Undo the functional change as discussed on irc.]
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Register 0x42020 was defined twice under the names PCH_DSPCLK_GATE_D and
ILK_DSPCLK_GATE. This patch consolidate the 2 sets of defines in one.

The transforms done are:

PCH_DSPCLK_GATE_D    -> ILK_DSPCLK_GATE_D
ILK_DSPCLK_GATE      -> ILK_DSPCLK_GATE_D

DPARBUNIT_CLOCK_GATE_DISABLE -> ILK_DPARBUNIT_CLOCK_GATE_DISABLE
ILK_DPARB_CLK_GATE           -> ILK_DPARBUNIT_CLOCK_GATE_DISABLE

DPFDUNIT_CLOCK_GATE_DISABLE -> ILK_DPFDUNIT_CLOCK_GATE_DISABLE
ILK_DPFD_CLK_GATE           -> ILK_DPFDUNIT_CLOCK_GATE_DISABLE
ILK_CLK_FBC                 -> ILK_DPFDUNIT_CLOCK_GATE_DISABLE

DPFCRUNIT_CLOCK_GATE_DISABLE -> ILK_DPFCRUNIT_CLOCK_GATE_DISABLE
ILK_DPFC_DIS1                -> ILK_DPFCRUNIT_CLOCK_GATE_DISABLE

DPFCUNIT_CLOCK_GATE_DISABLE -> ILK_DPFCUNIT_CLOCK_GATE_DISABLE
ILK_DPFC_DIS2               -> ILK_DPFCUNIT_CLOCK_GATE_DISABLE

We have a VHRUNIT_CLOCK_GATE_DISABLE define for the pre-ILK DSPCLK_GATE_D.
Even if the same bit is used in ILK_DSPCLK_GATE_D, other bits in the
register change, so I went with re-defining it, well more precisely rename
IVB_VRHUNIT_CLK_GATE, which is not specific to IVB+. So:

IVB_VRHUNIT_CLK_GATE       -> ILK_VHRUNIT_CLOCK_GATE_DISABLE
VHRUNIT_CLOCK_GATE_DISABLE -> ILK_VHRUNIT_CLOCK_GATE_DISABLE (ILK+ code)

This commit is only a renaming commit, further commits will clean up the
logic.

v2: Rename bit 5 and 7 to _ENABLE as setting them to 1 enables clock
    gating on their respective units, contrary to all of the other bits
    (Paulo Zanoni)
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Single-threaded forcewake was only used on some early pre-production
ivybridge machines, all the latest ones should use mt forcewake. And
we already assume this in other places of the code (e.g. DERRMR
support in the ddx, or the latest intel_gt_reset patch to reset any
lingering forcewake references left behind by the bios), so don't
bother here, too.
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Some BIOSes may forcibly suspend RC6 during their operation which
trigger a warning as we find the hardware in a perplexing state upon
first use. So far that appears to be the worst symptom as fortuituously
we use the same values as the BIOS for programming the FORCEWAKE register.
Reported-by: NOleksij Rempel <bug-track@fisher-privat.net>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

No functional change, but reserves 0x2 for use by userspace.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

BIOS should be setting the minimum voltage for rc6 to be 450mV. Old or
buggy BIOSen may not be doing this, so we correct it for them. Ideally
customers should update the BIOS as only it would know the optimal
values for the platform, so we leave that fact as a DRM_ERROR for the
user to see.

Unfortunately this isn't fixing any of the issues it was targeted to
fix, but it is documented that we must do it.

CC: Jesse Barnes <jbarnes@virtuousgeek.org>
CC: Matt Turner <mattst88@gmail.com>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[danvet: bikeshedded loglevel of the "your bios is broken message" to
debug.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

There is a special mechanism for communicating with the PCU already
being used for the ring frequency stuff. As we'll be needing this for
other commands, extract it now to make future code less error prone and
the current code more reusable.

I'm not entirely sure if this code matches 1:1 with the previous code
behaviorally. Functionally however, it should be the same.

CC: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Fixup compile fail reported by Wu Fengguang.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

A previous patch, namely:

commit bf97b276
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Apr 11 20:42:41 2012 +0200

    drm/i915: implement w/a for incorrect guarband clipping

accidentally set bit 5 in 3D_CHICKEN, which has nothing to do with
clipping.  This patch changes it to be set in 3D_CHICKEN3, where it
belongs.

The game "Dante" demonstrates random clipping issues when guardband
clipping is enabled and bit 5 of 3D_CHICKEN3 isn't set.  So the
workaround is actually necessary.

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Oliver McFadden <oliver.mcfadden@linux.intel.com>
Acked-by: NPaul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: NKenneth Graunke <kenneth@whitecape.org>
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Introduced in commit 87f8020e:
  drm/i915: implement WaDisableEarlyCull for VLV and IVB

Notice that the original patch sent to the mailing list did not
include the Haswell chunk, it was added later.

The bit set by the commit does not exist on Haswell machines (at least
that's what the documentation says). Also, the commit gives me a GPU
hang every time we're loading the driver. So let's revert the Haswell
chunk, making the patch do only what its title actually says.
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>

This workaround is only valid for IVB and VLV and the write triggers an
error on HSW.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanonI@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

For the next person that checks these kind of things, without having to
dig up the register definition.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

There's is another register (a read only, so no harm done) at 0x42020 on
Haswell GPUs. Let's just remove the write from the copy&paste that
introduced haswell_init_clock_gating().

A note for the interested reader, it does seem we have a duplication of
the 0x42020 register definition, hence the removal of 2 writes. That
duplication could be the object of a later patch.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Workaround for a culling optimization.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
[danvet: Also apply to haswell, spotted by Damien.]
Reviewed-by: N"Lespiau, Damien" <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

References: https://bugs.freedesktop.org/show_bug.cgi?id=50250Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

I can't even find how I figured this might be needed anymore. But sure
enough, the value I'm reading back on platforms doesn't match what the
docs recommends.

It seemed to fix Chris' GT1 in limited testing as well.
Tested-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Finishes commit 02d71956
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Aug 9 16:44:54 2012 +0200

    drm/i915: properly guard ilk ips state

The core functions were annotated with their locking requirements, but
we overlooked that they were exported, without any control over the
locking, to debugfs. So in order to enable debugfs to read the registers
without triggering sanity checks, we change the exported entry points to
properly take the required locks before calling the core routines.
Reported-by: Nyangguang <guang.a.yang@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55304Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

With the new "standardized" sysfs interfaces we need to be a bit more
careful about setting the RPS values.

Because the sysfs code and the rps workqueue can run at the same time,
if the sysfs setter wins the race to the mutex, the workqueue can come
in and set a value which is out of range (ie. we're no longer protecting
by RPINTLIM).

I was not able to actually make this error occur in testing.
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In order to keep our cached values in sync with the hardware, we need a
posting read here.

CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Currently we've only frobbed this bit at irq_init time, but did
not restore it at resume time. Move it to the gen3 clock gating
function to fix this.

Notice while reading through code.

Cc: stable@vger.kernel.org (for 3.5 only)
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The same designer from the previous patch has told us to never read
FORCEWAKE. We only do this for the POSTING_READ(), so simply change that
to something within the same cacheline (for no reason in particular
other than it sounds nice). In the _mt case we can leverage
the gtfifodbg check for the POSTING_READ.

This partially reverts
commit 6af2d180
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Jul 26 16:24:50 2012 +0200

    drm/i915: fix forcewake related hangs on snb

v2: commit message, comments about posting read from (Daniel)

Note: vlv forcewake doesn't need any changes for this special
treatment since FORCEWAKE_VLV is in a totally different register
range, and the readback FORCEWAKE_ACK_VLV readback that follows is in
the same range.
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
[danvet: Added note.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

A designer familiar with the hardware has stated that the forcewake
timeout can theoretically be as high as a little over 1ms. Therefore we
modify our code to use 2ms (appropriate fudge and because we don't want
to round down).

Hopefully this can't prevent spurious timeouts.
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Acked-by: NChris Wilson <chris@chris-wilson.oc.uk>
[danvet: again fix conflict with vlv patch.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>