Atm after a failed link training we disable the DP port. This can happen
during a modeset-enable or a DP link re-establishment. The latter can be
a problem and we shouldn't disable the DP port, see the previous patch for
the reasoning. In the former case the right thing would be to disable
the DP port, but also the rest of the pipe.

As a stop-gap solution leave the DP port enabled in both cases. It is an
improvement on its own (avoiding HW lock ups) and the proper solution
for the first case requires a bigger change, so let's keep that on the
TODO list.

v2:
- fix explanation of change impact (Chris)
Suggested-by: NDaniel Vetter <daniel@ffwll.ch>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Currently if the DP link is lost (either because of a hot unplug, or
failed link status check) we disable the DP port, but leave the rest
of the pipe running. This is incompatible with the modeset disabling
sequence of some platforms/configurations. At least this is the case for
DP ports on the CPU as opposed to PCH.

Atm we'll also get a warning when we do a modeset disable after the
above link lost event, since we expect the DP port to be enabled at this
point (see the bugzilla ticket for the related dmesg).

Note that with this patch we'll still end up disabling the port, thanks
to the HPD uevent and subsequent modeset disable.

See also the next patch fixing the other half of this issue.

Solution suggested by Ville.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70570Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

My 855gm doesn't register the intel backlight but it still ends up
calling the backlight code to enable/disable the backlight via the
LVDS code. This leads to some WARNs due to backlight.max being 0.

Let's have intel_panel_enable_backlight() and intel_panel_disable_backlight()
check whether there's a backlight present or not.

Also move the backlight.present check from asle_set_backlight() into
intel_panel_set_backlight() for some extra symmetry.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Fix typo possibly leading to timed out DP aux transactions on ports C,D.

Introduced in:

Commmit 4aeebd74
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Oct 31 09:53:36 2013 +0100

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72210
Signed off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We need to defer the free request until the object/vma is capable of
being freed - or else we have a problem  when we try to destroy the
context.

The exact same issue is described and fixed here:
commit e2078043
Author: Ben Widawsky <ben@bwidawsk.net>
Date:   Fri Dec 6 14:11:22 2013 -0800

    drm/i915: Defer request freeing

I had this fix previously, but decided not to keep it for some reason I
can no longer remember.

gem_reset_stats is a really good test at hitting the problem.

For the inquisitive:
[  170.516392] ------------[ cut here ]------------
[  170.517227] WARNING: CPU: 1 PID: 105 at drivers/gpu/drm/drm_mm.c:578 drm_mm_takedown+0x2e/0x30 [drm]()
[  170.518064] Memory manager not clean during takedown.
[  170.518941] CPU: 1 PID: 105 Comm: kworker/1:1 Not tainted 3.13.0-rc4-BEN+ #28
[  170.519787] Hardware name: Hewlett-Packard HP EliteBook 8470p/179B, BIOS 68ICF Ver. F.02 04/27/2012
[  170.520662] Call Trace:
[  170.521517]  [<ffffffff814f0589>] dump_stack+0x4e/0x7a
[  170.522373]  [<ffffffff81049e6d>] warn_slowpath_common+0x7d/0xa0
[  170.523227]  [<ffffffff81049edc>] warn_slowpath_fmt+0x4c/0x50
[  170.524079]  [<ffffffffa06c414e>] drm_mm_takedown+0x2e/0x30 [drm]
[  170.524934]  [<ffffffffa07213f3>] gen6_ppgtt_cleanup+0x23/0x110
[i915]
[  170.525777]  [<ffffffffa07837ed>] ppgtt_release.part.5+0x24/0x29
[i915]
[  170.526603]  [<ffffffffa071aaa5>] i915_gem_context_free+0x195/0x1a0
[i915]
[  170.527423]  [<ffffffffa071189d>] i915_gem_free_request+0x9d/0xb0
[i915]
[  170.528247]  [<ffffffffa0718af9>] i915_gem_reset+0x1f9/0x3f0 [i915]
[  170.529065]  [<ffffffffa0700cce>] i915_reset+0x4e/0x180 [i915]
[  170.529870]  [<ffffffffa070829d>] i915_error_work_func+0xcd/0x120
[i915]
[  170.530666]  [<ffffffff8106c13a>] process_one_work+0x1fa/0x6d0
[  170.531453]  [<ffffffff8106c0d8>] ? process_one_work+0x198/0x6d0
[  170.532230]  [<ffffffff8106c72b>] worker_thread+0x11b/0x3a0
[  170.532996]  [<ffffffff8106c610>] ? process_one_work+0x6d0/0x6d0
[  170.533771]  [<ffffffff810743ef>] kthread+0xff/0x120
[  170.534548]  [<ffffffff810742f0>] ? insert_kthread_work+0x80/0x80
[  170.535322]  [<ffffffff814f97ac>] ret_from_fork+0x7c/0xb0
[  170.536089]  [<ffffffff810742f0>] ? insert_kthread_work+0x80/0x80
[  170.536847] ---[ end trace 3d4c12892e42d58f ]---

v2: Whitespace fix. (Chris)

Note: This is a bug that only hits the ppgtt topic branch but I've
figured that doing the request cleanup in this order is generally the
right thing to do.
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
[danvet: Add a code comment to clarify what's actually going on since
the lifetime rules aroung ppgtt cleanup are ... fuzzy a best atm. Also
add a note about why we need this.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The opregion notification for runtime suspend is currently D1, not D3.
Signed-off-by: NKristen Carlson Accardi <kristen@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

It ought to work ok in 3.14.  We have some fun stuff coming after that,
but all the basics are in place now and seem relatively stable.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Acked by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This is user-triggerable and hence we should not allow it to spam
dmesg. Also, it upsets the nice dmesg tracking piglit does.

Note that this is just extra debugging information, mostly
unwanted, in case of a hang and that there is a separate message to the
user giving instructions on how to report a bug for a GPU hang.

v2: Add note as suggests in Chris' reply.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72740
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

A couple patches in the upcoming rework of semaphores will break if
semaphores are toggled by the user at various times. Since the code
cleanups there seem to be an overall win, and toggling semaphores at
runtime is not a terribly useful thing to do, simply make the module
parameter read-only.

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

The ring will emit too many if semaphores are disabled since we do not
add the correct number to num_dwords anymore.

This was introduced:
commit 52ed2325
Author: Ben Widawsky <benjamin.widawsky@intel.com>
Date:   Mon Dec 16 20:50:38 2013 -0800

    drm/i915: Don't emit mbox updates without semaphores

FWIW, the bug was fixed later in the series.

/me hangs head in shame.

Daniel: Also note that we should have merged the read-only semaphore
modparam before this patch.
Reported-by: NKenneth Graunke <kenneth@whitecape.org>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

While trying to find a random -EINVAL from a failing test, I noticed we
had a few hard to follow return values.

The first two hunks in this patch replace completely useless
initialization of ret. The last several hunks help to distinguish
between altering 'return ret' and 'return <ERROR>'
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

On pre-PCH platforms ISR doesn't seem to be an actual ISR, at least as
far as display interrupts are concerned. Instead it sort of looks like
some ISR bits just directly reflect the corresponding bit from PIPESTAT.
The bit appears in the ISR only if the PIPESTAT interrupt is enabled. So
in that sense it sort of looks a bit like the south interrupt scheme on
PCH platforms. So it goes something a bit like this:
PIPESTAT.status & PIPESTAT.enable -> ISR -> IMR -> IIR -> IER -> actual
interrupt

In any case that means the intel_pipe_in_vblank_locked() doesn't actually
work for pre-PCH platforms. As a last resort, add a similar kludge as radeon
has that fixes things up if we got called from the vblank interrupt,
but the scanline counter value indicates that we're not quite there yet.
We know that the scanline counter increments at hsync but is otherwise
accurate, so we can limit the kludge to the line just prior to vblank
start, instead of the relative distance that radeon uses.

Reviewed-by: mario.kleiner.de@gmail.com
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

Preparation for moving the early vblank IRQ logic into
radeon_get_crtc_scanoutpos().

v2: Fix radeon_drv.c compile warning (Mario)

Reviewed-by: mario.kleiner.de@gmail.com
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

The scanline counter counts lines in the current field, not the entire
frame. But the crtc_ timings are the values for the entire frame. Divide
the vertical timings by 2 to make them match the scanline counter.

The rounding was carefully chosen to make it do the right thing wrt. the
observed scanline counter and ISR vblank bit behaviour.

Reviewed-by: mario.kleiner.de@gmail.com
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

Update the pixel/line/frame duration information when we switch to the
new pipe config. This will keep the timestamping constants in better
sync with the real hardware state.

Reviewed-by: mario.kleiner.de@gmail.com
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

drm core no longer uses crtc->hwmode, and neither does i915, so we can totally ignore it
in i915.

Reviewed-by: mario.kleiner.de@gmail.com
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

Rather than using crtc->hwmode, just pass the relevant mode to
drm_calc_vbltimestamp_from_scanoutpos(). This removes the last hwmode
usage from core drm.

Reviewed-by: mario.kleiner.de@gmail.com
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

We don't really use hwmode anymore in i915, so eliminating its use
from the core code seems prudent. Just pass the appropriate mode
to drm_calc_timestamping_constants().

Reviewed-by: mario.kleiner.de@gmail.com
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

We were apparently relying on the defaults on BDW, which resulted in no
hotplug or AUX interrupts.  So be sure to call the ibx_irq_preinstall to
enable all interrupts.

v2: use preinstall instead of redundant SDIER write

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

Daniel thought that this was an opportune moment to include which pins
and bits ended up being stuck in the WARN.
Suggested-by: NDaniel Vetter <daniel@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Disabling the hotplug IRQ is a two-step process. First, inside the IRQ
handler we mark the rogue hotplug pin for disabling. Then later in the
hotplug worker, we actually disable the hotplug pin. So we should not
WARN about the rogue hotplug IRQ being sent until after we have
completed disabling the pin.

References: https://bugzilla.redhat.com/show_bug.cgi?id=1051170Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

It seems that hardware that is broken enough to emit a hotplug IRQ even
though the pin is surposedly disable, will do so indefinitely.

Note: There's a good chance the underlying issue has been fixed with

commit 0ce99f74
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Fri Jul 26 11:27:49 2013 +0200

    drm/i915: fix gen4 digital port hotplug definitions

References: https://bugzilla.redhat.com/show_bug.cgi?id=1051170
Link: https://bugzilla.redhat.com/attachment.cgi?id=847786Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
[danvet: Add note about the potential fix.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We specifically exclude original gen4 (i.e. i965g/gm), so update the
naming for consistency. Spotted while reviewing related code due to a
report from Jesse about byt needing again different values.

v2: g4x, not gm45 since this also applies to the desktop version.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

It's an accident waiting to happen.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

INSTPM is a masked register so use the _MASKED_BIT_{ENABLE,DISABLE}
macros when enabling/disabling self-refresh on 915GM.
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>

There's no LVDS port on 830M so don't go reading the LVDS control
register.
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>

PFIT_CONTROL doesn't exist on 830M, so avoid reading it in
i9xx_get_pfit_config().

Also assume that only mobile gen2/3 chipsets have a panel fitter. This
matches the documentation, but I didn't have real hardware to verify.

Gen4 docmentation is a bit inconsistent, but experimenetation on my
LPT machine suggests that the panel fitter is available on non-mobile
gen4 platforms. At least on this machine panel fitter appears works
just fine even on VGA output.
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>

Many of the fields from Gen6 have gone away for vlv. Strip all those
fields that are not relevent and try to update fields that we care
about. This patch give information about current RP & RC status and
individual Wells.

v2: Move Render & Media Well status to separate lines (Ville)
Signed-off-by: NDeepak S <deepak.s@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

VGA detection requires the reference clock to be on, so make sure this
is the case.

This fixes VGA hotplug/manual detection where all pipes are off and so
we would normally disable all clocks.

v2:
- Instead of disabling PSR clock gating, force the reference clock on
  through the DPLL_A register. (Kin Chan S <kin.s.chan@intel.com>)

v3:
- Move enabling of the clock to intel_reset_dpio() and use the DPLL_B
  register instead, where we already have a similar tweak for the CRI
  clock. (Ville)
Reported-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

intel_init_dpio() isn't called during resume, so we won't set the CRI
clock enable bit during that time. Move the enabling to
intel_reset_dpio() instead.

Note that the HW reset value for this bit is 1, so probably this patch
won't make any difference. We should still make the setting explicit,
since BIOS could change things under us.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The WA is mentioned in HSW's GAMMA_MODE register documentation, but
not on on BDW's documentation, so let's assume it is not needed there.
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>

That we can use for debugging purposes.

v2: Use designated initializers for the 'names' array (Paulo Zanoni,
    Jani Nikula).
    Add a check in case the array has a hole (which can now remain
    unnoticed with designated initializers) (Jani Nikula)

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (for v1)
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In some cases we have more than 1 connector associated to an encoder
(e.g., SDVO, Haswell DP/HDMI) and we can only set a mode for one of
these connectors. If we only allowed modesets for connected connectors
we would never need this patch, but since we do allow modeset for
disconnected connectors we may see user space trying to set modes on
the two connectors attached to the same encoder, so we need to forbid
that.

This problem can be reproduced by running the following
intel-gpu-tools test case:
  ./kms_setmode --run-subtest clone-exclusive-crtc

Thanks to Daniel Vetter for providing a version of this patch on
pastebin.

Credits-to: Daniel 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>

So shuffle the checks around a bit. Also give all the structs and
functions proper prefixes: i830_ for the dual-pipe mobile platforms
and i845_ for the two single-pipe desktop platforms.

Note that the max fifo value isn't actually correct for the i830M, but
since we don't frob the fifo split we don't actually need it. This is
different for some gen3 devices where we need the full fifo for self
refresh mode.

Cc: Thomas Richter <richter@rus.uni-stuttgart.de>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

My OCD just couldn't let this slide. Spotted while reviewing Ville's
patch to only flip planes when we have FBC.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Looks like 830M doesn't quite like it when you try to move a plane from
one pipe to another. It seems that the plane's old pipe has to be active
even if the plane is already disabled, otherwise the relevant register
just won't accept new values.

The following commit:

 commit 1f1c2e24
 Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
 Date:   Thu Nov 28 17:30:01 2013 +0200

    drm/i915: Swap primary planes on gen2 for FBC

caused a regression on 830M. It will attempt to swap the planes when the
driver is loaded, but at that time only pipe A might be active, so plane
A gets disabled, but plane B won't get enabled since pipe B is not
active when we try to move the plane over to pipe A.

There's no reason to swap planes on 830M since it doesn't support
FBC. Change the logic a bit to limit the plane swapping to platforms
which actually support FBC. This should avoid getting a black screen on
830M.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

When the pipe A force quirk is applied the code will attempt to grab
a crtc mutex during intel_modeset_setup_hw_state(). If we're already
holding all crtc mutexes this will obviously deadlock every time.

So instead of using drm_modeset_lock_all() just grab the
mode_config.mutex. This is enough to avoid the unlocked mutex warnings
from certain lower level functions.

The regression was introduced in:

 commit 02747664
 Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
 Date:   Mon Dec 2 11:08:06 2013 +0200

    drm/i915: Take modeset locks around intel_modeset_setup_hw_state()
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
[danvet: Add cc: stable since the offending commit has that, too.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

LPT does have PCH refclk, but it's different form the IBX/CPT/PPT one
and doesn't use the same structs. It is wrong to have a message saying
that "LPT does not has PCH refclk" (sic). While at it, signal that we
only want this function on IBX/CPT/PPT by renaming it and adding a
WARN.

On HSW we also print "0 shared PLLs initialized", but we *do* have
shared PLLs on HSW (LCPLL, WRPLL, SPLL) and we *do* initialize them.
We just don't use "struct intel_shared_dpll". So remove the debug
message.

In the future we may want to rename all that "intel shared pll" code
to "ibx shared pll", but I'll leave this to another patch.
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>

Properly zero the refcounts and crtc->ddi_pll_set so the previous HW
state doesn't affect the result of reading the current HW state.

This fixes WARNs about WRPLL refcount if we have an HDMI monitor on
HSW and then suspend/resume.

Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64379Tested-by: NQingshuai Tian <qingshuai.tian@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

According to Art, we don't have a way to read back the state reliably at
runtime, through the control reg or the mailbox, at least not without risking
disabling it again.  So drop the readout and checking on BDW.

v2: drop TODO comment (Paulo)
    move POSTING_READ of control reg under HSW branch in disable (Paulo)
    always report IPS as enabled on BDW (Paulo)

References: https://bugs.freedesktop.org/show_bug.cgi?id=71906Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>