Drivers need to know the CEA version number in addition to other display
info (like whether the display is an HDMI sink) before enabling certain
features.  So track the CEA version number in the display info
structure.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NKeith Packard <keithp@keithp.com>

Jesse Barnes and I found a couple of issues where incorrect mode
setting would cause problems with RC6 enabled. We're hopeful that
fixing those will resolve the outstanding issues with a few machines
that had trouble before 3.0 with rc6.

Cc: Pekka Enberg <penberg@kernel.org>
Cc: Francesco Allertsen <fallertsen@gmail.com>
Cc: Ted Phelps <phelps@gnusto.com>
Cc: Gu Rui <chaos.proton@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38567
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=38332Signed-off-by: NKeith Packard <keithp@keithp.com>

This reverts commit 97cdd710.

Clearing the dpcd data means that if the fetch fails, any previous
data will be lost. On eDP, this is no fun as we only fetch dpcd at
init time, so the memset will destroy that the next time through.

Before initiating a new read or write on the DP AUX channel, wait for
any outstanding activity to complete.  This may happen during normal
retry behavior.  If the wait fails (i.e. after 1ms the AUX channel is
still busy) dump a backtrace to make the caller easier to spot.

v2: use msleep instead, and timeout after 3ms (only ever saw 1 retry
    with msleep in testing)
v3: fix backtrace check to trigger if the 3ms wait times out

Fixes https://bugs.freedesktop.org/show_bug.cgi?id=38136.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>

The EDID parser will zero out the bpc value, and the driver needs to handle
that case.  In our picker, we'll just ignore 0 values as far as bpp
picking goes.

Fixes https://bugs.freedesktop.org/show_bug.cgi?id=39323.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NKeith Packard <keithp@keithp.com>

At least on a Lenovo X220 the HPD bits of this are enabled at boot but
cleared after resume, which means plug interrupts stop working.

This also happens to fix DP displays re-lighting on resume.  I'm quite
certain that's an accident: the first DP link train inevitably fails on
that machine, and it's only serendipity that we're getting multiple plug
interrupts and the second train works.  But I shall take my victories
where I get them.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Tested-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>

These bits moved around on SNB and above.

v2: again with the git send-email fail
v3: add macros for getting per-pipe override & enable bits
v4: enable phase sync pointer on SNB and IVB configs as well
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NKeith Packard <keithp@keithp.com>

Using the new quirk added to support disabling SSC on Lenovo U160
(#36656, commit 435793df), also register
the Vaio as a special case and disable SSC for it.

This patch fixes #34437 on fdo bugzilla:
https://bugs.freedesktop.org/show_bug.cgi?id=34437Signed-off-by: NMichel Alexandre Salim <salimma@fedoraproject.org>
Signed-off-by: NKeith Packard <keithp@keithp.com>

If a mode set fails we may get a message from drm_crtc_helper if we're lucky,
but it won't tell us anything about *why* we failed to set a mode.  So
add a few DRM_ERRORs for the cases that shouldn't happen so we can debug
things more easily.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NKeith Packard <keithp@keithp.com>

Mainly for use in debugging and benchmarking, this file allows the user
to control the max frequency used by the GPU.  Frequency may still vary
based on workload (if the frequency is set to higher than the minimum)
but won't go over the newly set value.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NKeith Packard <keithp@keithp.com>

The Dell OptiPlex FX170 claims to have LVDS, but doesn't.
Signed-off-by: NPieterjan Camerlynck <pieterjan.camerlynck@gmail.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>

Failing to pin a scanout buffer will most likely lead to a black
screen, so if the GPU is wedged, then just let the pin happen and hope
that things work out OK.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

On Ironlake and above, we have per-transcoder DIP registers, so use them
for sending DIPs like AVI infoframes on ILK and above.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NKeith Packard <keithp@keithp.com>

CB tuning is needed to handle potential process variations that might
cause clock jitter for certain PLL settings.  However, we were setting
it incorrectly since we were using the wrong M value as a check (M1 when
we needed to use the whole M value).  Fix it up, making my HDMI
attached display a little prettier (used to have occasional dots crawl
across the display).
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NKeith Packard <keithp@keithp.com>

Writes to the plane control register are buffered in the chip until a
write to the DSPADDR (pre-965) or DSPSURF (post-965) register occurs.

This patch adds flushes in:

	intel_enable_plane
	gen6_init_clock_gating
	ivybridge_init_clock_gating
Signed-off-by: NKeith Packard <keithp@keithp.com>

After writing to the plane control reg we need to write to the surface
reg to trigger the double buffered register latch.  On previous
chipsets, writing to DSPADDR was enough, but on ILK+ DSPSURF is the reg
that triggers the double buffer latch.

v2: write DSPADDR too to cover pre-965 chipsets
v3: use flush_display_plane instead, that's what it's for
v4: send the right patch
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>

On CougarPoint and PantherPoint PCH chips, the timing generator may fail
to start after DP training completes.  This is due to a bug in the
FDI autotraining detect logic (which will stall the timing generator and
re-enable it once training completes), so disable it to avoid silent DP
mode setting failures.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NKeith Packard <keithp@keithp.com>

This corrects the DPMS mode tracking so that the DPMS code will
actually turn the CRTC off the next time the screen saves.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>

This reverts commit 885a5014.

We actually *do* need to track DPMS state so that on hotplug, we don't
retrain the link until DPMS is disabled.

However, that code had avery small bug -- it wouldn't set the
dpms_mode at mode set time, and so link retraining would not actually
occur on monitor hotplug until the monitor had gone through a DPMS
off/DPMS on cycle.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Tested-by: NAndrew Lutomirski <luto@mit.edu>

Display port pipe selection on CPT is not done with a bit in the
output register, rather it is controlled by a couple of bits in the
separate transcoder register which indicate which display port output
is connected to the transcoder.

This patch replaces the simplistic macro DP_PIPE_ENABLED with the
rather more complicated function dp_pipe_enabled which checks the
output register to see if that is enabled, and then goes on to either
check the output register pipe selection bit (on non-CPT) or the
transcoder DP selection bits (on CPT).

Before this patch, any time the mode of pipe A was changed, any
display port outputs on pipe B would get disabled as
intel_disable_pch_ports would ensure that the mode setting operation
could occur on pipe A without interference from other outputs
connected to that pch port
Signed-off-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NAdam Jackson <ajax@redhat.com>

Eliminates an open-coded read and also gains the retry behaviour of
intel_dp_get_dpcd, which seems like a good idea.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NAdam Jackson <ajax@redhat.com>

This describes the function better, allowing it to be used where the
DPCD value is relevant.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NAdam Jackson <ajax@redhat.com>

This uses the common dpcd reading routine, i915_dp_detect_common,
instead of open-coding a call to intel_dp_aux_native_read. Besides
reducing duplicated code, this also gains the read retries which
may be necessary when a cable is first plugged back in and the link
needs to be retrained.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NAdam Jackson <ajax@redhat.com>

drm_helper_hpd_irq_event queues another work proc to go and deliver
the user-space event, and that function also wants to hold the config
mutex, so we shouldn't hold the mutex across the
drm_helper_hpd_irq_event call.
Signed-off-by: NKeith Packard <keithp@keithp.com>

The docs say the port has to come on in training pattern 1; at this
point, though, ->DP is in normal mode.  The intent here is to wait
until the port is in fact sending data, but that doesn't happen since
we've broken the sequence the hardware expects, and the vblank wait will
time out and kvetch in the log.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NKeith Packard <keithp@keithp.com>

The DP spec says training patterns 1 and 2 are to be sent non-scrambled,
and the GPU docs claim that happens (or at least, there's no explicit
scrambling control).  But the sink may be confused if we don't
explicitly tell it what we're doing, so play it safe.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NKeith Packard <keithp@keithp.com>

Consider a 1600x900 panel, upscaling a 1360x768 mode, full-aspect.  The
old math would give you:

    scaled_width  = 1600 * 768;         /* 1228800 */
    scaled_height = 1360 * 900;         /* 1224000 */
    if (scaled_width > scaled_height) { /* pillarbox, and true */
        width  = 1224000 / 768;         /* int(1593.75) = 1593 */
        x      = (1600 - 1593 + 1) / 2; /* 4 */
        y      = 0;
        height = 768;
    } /* ... */

This is broken.  The total width of scanout would then be 1593 + 4 + 4,
or 1601, which is wider than the panel itself.  The hardware very
dutifully implements this, and you end up with a black 45° diagonal from
the top-left corner to the bottom edge of the screen.  It's a cool
effect and all, but not what you wanted.  Similar things happen for the
letterbox case.

The problem is that you have an integer number of pixels, which means
it's usually impossible to upscale equally on both axes.  1360/768 is
1.7708, 1600/900 is 1.7777.  Since we're constrained on the one axis,
the other one wants to come out as an even number of pixels (the panel
is almost certainly even on both axes, and the x/y offsets will be
applied on both sides).  In the math above, if 'width' comes out even,
rounding down is correct; if it's odd, you'd rather round up.  So just
increment width/height in those cases.

Tested on a Lenovo T500 (Ironlake).
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Tested-By: NDaniel Manrique <daniel.manrique@canonical.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38851Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Signed-off-by: NKeith Packard <keithp@keithp.com>

Hotplug detection is a mode setting operation and must hold the
struct_mutex or risk colliding with other mode setting operations.

In particular, the display port hotplug function attempts to re-train
the link if the monitor is supposed to be running when plugged back
in. If that happens while mode setting is underway, the link will get
scrambled, leaving it in an inconsistent state.

This is a special case -- usually the driver mode setting entry points
are covered by the upper level DRM code, but in this case the function
is invoked as a work function not under the control of DRM.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Cc: stable@kernel.org
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>

It's not clear what a sink would do if you wrote zero to this register -
which I guess would mean "I don't support any channel encodings, good
luck" - but let's not find out.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Reviewed-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>

Signed-off-by: NAdam Jackson <ajax@redhat.com>
Reviewed-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>

%hx alone prints 0 as "0", not "00".
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Reviewed-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>

For parity with radeon and nouveau, and also because I suspect we're
going to need it to get format-conversion dongles right.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Reviewed-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>

No reason not to see this on g4x, after all.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Reviewed-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>

Signed-off-by: NAdam Jackson <ajax@redhat.com>
Reviewed-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>