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>

Per the specs and to address
https://bugs.freedesktop.org/show_bug.cgi?id=36888.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Cc: stable@kernel.org
Signed-off-by: NKeith Packard <keithp@keithp.com>

Physically-addressed hardware status pages are initialized early in
the driver load process by i915_init_phys_hws. For UMS environments,
the ring structure is not initialized until the X server starts. At
that point, the entire ring structure is re-initialized with all new
values. Any values set in the ring structure (including
ring->status_page.page_addr) will be lost when the ring is
re-initialized.

This patch moves the initialization of the status_page.page_addr value
to intel_render_ring_init_dri.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Cc: stable@kernel.org

Align unfenced buffers on older hardware to the power-of-two object
size.  The docs suggest that it should be possible to align only to a
power-of-two tile height, but using the already computed fence size is
easier and always correct. We also have to make sure that we unbind
misaligned buffers upon tiling changes.

In order to prevent a repetition of this bug, we change the interface
to the alignment computation routines to force the caller to provide
the requested alignment and size of the GTT binding rather than assume
the current values on the object.
Reported-and-tested-by: NSitosfe Wheeler <sitsofe@yahoo.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36326Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NKeith Packard <keithp@keithp.com>

We've tried several times to make this machine 'just work', but every
patch that does causes many other machines to fail. This adds a quirk
which special cases this hardware and forces ssc to be
disabled. There's no way to override this from the command line; that
would be a significantly more invasive change.

This patch fixes #36656 on fdo bugzilla:
https://bugs.freedesktop.org/show_bug.cgi?id=36656Signed-off-by: NKeith Packard <keithp@keithp.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=36656Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

Compute drivers may change this, so make sure to emit it to
avoid errors in bo blits.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=39119Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

...which is measured by the size and not the amount of space remaining.

Waiting upon size-8, did one of two things. In the common case with more
than 8 bytes available to write into the ring, it would return
immediately. Otherwise, it would timeout given the impossible condition
of waiting for more space than is available in the ring, leading to
warnings such as:

[drm:intel_cleanup_ring_buffer] *ERROR* failed to quiesce render ring
whilst cleaning up: -16
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NKeith Packard <keithp@keithp.com>

This reverts commit a51f7a66.

We still have a few Ironlake and Sandybridge machines which fail when
RC6 is enabled. Better luck next release?
Signed-off-by: NKeith Packard <keithp@keithp.com>

i915_driver_load adds a write-combining MTRR region for the GTT
aperture to improve memory speeds through the aperture. If
i915_driver_load fails after this, it would not have cleaned up the
MTRR. This shouldn't cause any problems, except for consuming an MTRR
register. Still, it's best to clean up completely in the failure path,
which is easily done by calling mtrr_del if the mtrr was successfully
allocated.

i915_driver_load calls i915_gem_load which register
i915_gem_inactive_shrink. If i915_driver_load fails after calling
i915_gem_load, the shrinker will be left registered. When called, it
will access freed memory and crash. The fix is to unregister the shrinker in the
failure path using code duplicated from i915_driver_unload.

i915_driver_load also has some incorrect gotos in the error cleanup
paths:

 * After failing to initialize the GTT (which cannot happen, btw,
   intel_gtt_get returns a fixed (non-NULL) value), it tries to
   free the uninitialized WC IO mapping. Fixed this by changing the
   target from out_iomapfree to out_rmmap
Signed-off-by: NKeith Packard <keithp@keithp.com>
Tested-by: NLin Ming <ming.m.lin@intel.com>

BUS_CNTL reg and bits moved between pre-PCIE and PCIE asics.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

BUS_CNTL is at 0x30 on rs600, not 0x4c.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Don't enable backends that don't exist.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Skip connectors that do not have an HPD pin.

Should fix:
https://bugs.freedesktop.org/show_bug.cgi?id=39027Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Tested-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

evergreen+ asics have 2-6 crtcs.  Don't access crtc registers
for crtc regs that don't exist as they have very high latency
and may cause problems on some asics.  The previous code missed
a few cases and was not fine grained enough (missed the 4 crtc
case for example).

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=38800

v2: fix typo noticed by Chris Bandy <cbandy@jbandy.com>
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Reviewed-by: NMichel Dänzer <michel@daenzer.net>
Tested-by: NSimon Farnsworth <simon.farnsworth@onelan.co.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

According to the hardware documentation, GDRST is exactly the same as on
Sandybridge.  So simply enable the existing code.
Signed-off-by: NKenneth Graunke <kenneth@whitecape.org>
Signed-off-by: NKeith Packard <keithp@keithp.com>

On sinks with a DPCD rev of 1.1 or greater, we can send sink power
management commands to address 0x600 per section 5.1.5 of the
DisplayPort 1.1a spec.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>

When checking link status during a hot plug event or detecting sink
presence, we need to retry 3 times per the spec (section 9.1 of the 1.1a
DisplayPort spec).  Consolidate the retry code into a
native_aux_read_retry function for use by get_link_status and _detect.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>