Because on Haswell, the pipe is never running at this point, so we hit
the 50ms timeout waiting for nothing. We already have two other places
where we wait for vblanks on haswell_crtc_enable, so we're safe.

This gets us rid of one instance of "vblank wait timed out" for each
mode set, which means driver init and resume are also 50ms faster.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Depending on the HW gen and the connector type, the pipe won't start
running right after we call intel_enable_pipe, so that
intel_wait_for_vblank call we currently have will just sit there for
the full 50ms timeout. So this patch adds an argument that will allow
us to avoid the vblank wait in case we want. Currently all the callers
still request for the vblank wait, so the behavior should still be the
same.

We also added a POSTING_READ on the register: previously
intel_wait_for_vblank was acting as a POSTING_READ, but now if
wait_for_vblank is false we'll stkip it, so we need an explicit
POSTING_READ.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

For use by get_plane_config.

v2: cleanup tile_height bits (Chris)
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In Jesse's patch to switch the fbdev framebuffer from an embedded
struct to a pointer the kfree in case of an error was missed. Fix this
up by using our own internal fb allocation helper directly instead of
reinventing that wheel.

We need a to_intel_framebuffer cast unfortunately since all the other
callers of _create still look better whith using a drm_framebuffer as
return pointer.

v2: Add an unlocked __intel_framebuffer_create function since our
dev->struct_mutex locking is too much a mess. With ppgtt we even need
it to take a look at the global gtt offset of pinned objects, since
the vma list might chance from underneath us. At least with the
current global gtt lookup functions. Reported by Mika.

Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Now that it's a normally kmalloce buffer we can use the usual cleanup
paths. The upside here is that if we get the refcounting wrong will be
able to catch it, since the drm core will complain about leftover
framebuffers and kref about underflows.

v2: Kill intel_framebuffer_fini - no longer needed now that we
refcount all fbs properly and only confusing.

v3: We actually still need to call unregister_private to remove the fb
from the idr and drop the idr reference - the final unref doesn't do
that. So much for remembering my own fb liftime rules. Reported by
Imre Deak.

Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v2)
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Touching the VGA registers risks a hard machine hang, at least on this
ivb machine after removing a conflicting efifb. This is more than likely
related to the discovery that VGA IO decode on the more recent PCH
platforms is terminally broken.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This has very little effect other than log the errors in case of failure,
and we then hope for the best.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Allocate this struct instead, so we can re-use another allocated
elsewhere if needed.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[danvet: WARN_ON if there's no backing storage attached to an fb,
that's a bug.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We had 2 set of defines for the same register, so make it one.
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

And rename it to num_sprites as this value doesn't count the primary
plane.

This limit lives with num_pipes really, and now that dev_priv->info is
writable we can put it there instead.

While at it, introduce a intel_device_info_runtime_init() where we'll be
able to gather the device info fields at run-time.

v2: rename num_plane to num_sprites (Ville Syrjälä)
v3: rebase on top of latest drm-nightly

Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> (for v2)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (for v2)
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

If we make sure that all the dev_priv->info usages are wrapped by
INTEL_INFO(), we can easily modify the ->info field to be structure and
not a pointer while keeping the const protection in the INTEL_INFO()
macro.

v2: Rebased onto latest drm-nightly
Suggested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

With 20+ module parameters, I think referring to them via a struct
improves clarity over just having a bunch of globals. While at it, move
the parameter initialization and definitions into a new file
i915_params.c to reduce clutter in i915_drv.c.

Apart from the ill-named i915_enable_rc6, i915_enable_fbc and
i915_enable_ppgtt parameters, for which we lose the "i915_" prefix
internally, the module parameters now look the same both on the kernel
command line and in code. For example, "i915.modeset".

The downsides of the change are losing static on a couple of variables
and not having the initialization and module_param_named() right next to
each other. On the other hand, all module parameters are now defined in
one place at i915_params.c. Plus you can do this to find all module
parameter references:

$ git grep "i915\." -- drivers/gpu/drm/i915

v2:
- move the definitions into a new file
- s/i915_params/i915/
- make i915_try_reset i915.reset, for consistency
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Currently we print all pipe underruns on GMCH platforms. Hook up the
same logic we use on PCH platforms where we disable the underrun
reporting after the first underrun.

Underruns don't actually generate interrupts themselves on GMCH
platforms, we just can detect them whenever we service other
interrupts. So we don't have any enable bits to worry about. We just
need to remember to clear the underrun status when enabling underrun
reporting.

Note that the underrun handling needs to be moved to the non-locked
pipe_stats[] loop in the interrupt handlers to avoid having to rework
the locking in intel_set_cpu_fifo_underrun_reporting().
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Now that we have DDI support, we can check these all the time.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Since
commit ee1452d7
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Fri Sep 20 15:05:30 2013 +0300

    drm/i915: assume all GM45 Acer laptops use inverted backlight PWM

failed and was later reverted in
commit be505f64
Author: Alexander van Heukelum <heukelum@fastmail.fm>
Date:   Sat Dec 28 21:00:39 2013 +0100

    Revert "drm/i915: assume all GM45 Acer laptops use inverted backlight PWM"

fix the individual broken machine instead.

Note to backporters:

http://patchwork.freedesktop.org/patch/17837/

is the patch you want for 3.13 and older.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=54171
Reference: http://mid.gmane.org/DUB115-W7628C7C710EA51AA110CD4A5000@phx.gbl
CC: stable@vger.kernel.org
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Patch mangling for 3.14 plus adding the link to the original
for 3.13.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Currently we're doing the reset handling a bit late, and we're doing
it both in the driver load code and on resume. This makes it unusable
for e.g. resetting the panel power sequence state like Paulo wants to.

Instead of adding yet another single-use callback shuffle things
around:
- Output handling code is responsible to reset/init all state on its
  own at driver load time.
- We call the reset functions much earlier, before we start using any
  of the modeset code.

Compared to Paulo's new ->resume callback the only difference in
placement is that ->reset is still called without dev->struct_mutex
held. Which is imo a feature.

v2: Rebase on top of the now merge dinq.

Cc: Paulo Zanoni <przanoni@gmail.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

I forgot to set new_config and new_enabled appropriately in the load
detect code. Fix it up.

v2: Handle the other error path in intel_get_load_detect_pipe() too (Imre)
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

crtc->new_config is only relevant for pipes that are going to be active
post-modeset. Set the pointer to NULL for all pipes that are going to
be disabled. This is done to help catch bugs where some piece of code
would go looking at crtc->new_config even if the data there is stale.

v2: Clear new_config in disable_crtc_nofb() too (Imre)
Suggested-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

If the first modeset operation fails, we will attempt to restore the
previous configuration that we read out from the hardware. But as we
don't yet reconstruct the framebuffer information, we end up calling
the modeset code with an enabled crtc but with fb==NULL. This will
lead to an oops within the modeset code.

Check for NULL fb when restoring the configuration, and instead of
oopsing simply disable the pipe.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

On VLV we need to compute the new cdclk before we've updated the current
state. The code achieved that in a somewhat complex way. Now that we
have new_enabled and new_config, we can simplify the code quite a bit.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Add a new_config pointer to intel_crtc which will point to the new pipe
config for said crtc while intel_crtc.config will still contain the old
config during first parts of the modeset operation. This is a step
towards having the entire new state available during the compute phase,
so that we can make accurate decisions about global resource usage.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Add 'new_enabled' to intel_crtc and precompute it alongside new_encoder
and new_crtc. This will allow making decisions about shared resources
that are affected by the set of active pipes, before we've clobbered
anything for real.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This reverts commit 446f2545.

I've left the masking in the pageflip code since that seems to be some
useful piece of preemptive robustness.

Iirc I've merged this patch under the assumption that the BIOS leaves
some random gunk in the lower bits and gets unhappy if we trample on
them. We have quite a few case like this, so this made sense.

Now I've just learned that there's actual hardware features bits in
the low 12 bits, and the kernel needs to preserve them to allow a
userspace blob to do its job. Given Dave Airlie's clear stance on
userspace blob drivers I've quickly chatted with him and he doesn't
seem too happy. So let's revert this.

If there are indeed bits that we must preserve in this range then we
can ressurrect this patch, but with proper documentation for those
bits supplied. And we probably also need to think a bit about
interactions with our driver.

Cc: Armin Reese <armin.c.reese@intel.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Dave Airlie <airlied@linux.ie>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

On older generations (gen2, gen3) the GPU requires fences for many
operations, such as blits. The display hardware also requires fences for
scanouts and this leads to a situation where an arbitrary number of
fences may be pinned by old scanouts following a pageflip but before we
have executed the unpin workqueue. This is unpredictable by userspace
and leads to random EDEADLK when submitting an otherwise benign
execbuffer. However, we can detect when we have an outstanding flip and
so cause userspace to wait upon their completion before finally
declaring that the system is starved of fences. This is really no worse
than forcing the GPU to stall waiting for older execbuffer to retire and
release their fences before we can reallocate them for the next
execbuffer.

v2: move the test for a pending fb unpin to a common routine for
later reuse during eviction

Reported-and-tested-by: dimon@gmx.net
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73696Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NJon Bloomfield <jon.bloomfield@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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>

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>

The intel_encoder_crtc_ok() is a duplicate of the drm_encoder_crtc_ok()
function that used to be only available in the DRM CRTC helpers. It has
recently been moved to the core, so the duplicate can now be dropped.
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

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>

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>

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>