Make them match the others and add BPP definitions.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

If we disable the pipe and the GPU is currently waiting on a scanline
WAIT_FOR_EVENT, the GPU will hang. Fortunately, there is a magic bit
which we can write on i915+ to break this wait after disabling the
pipe.

References:

  Bug 29252 - [Arrandale] Hung WAIT_FOR_EVENT when running rss-glx-skyrocket
  https://bugs.freedesktop.org/show_bug.cgi?id=29252

  Bug 28964 - [i965gm] GPU infinite MI_WAIT_FOR_EVENT while watching video in Totem
  https://bugs.freedesktop.org/show_bug.cgi?id=28964

and many others.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>

Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

During DPMS we currently do not want the overlay code to be
interruptible, so pass that information down and only take the
uninterrruptible paths.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Store the pixel-multiplier on the adjusted mode and avoid modifying the
requested mode.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

With the extra intel_wait_for_vblank added in commit
9d0498a2 periodic stalls were being
triggered (which were detected by i915_hangcheck_elapsed). Partially
revert this change for now.
Signed-off-by: NSitsofe Wheeler <sitsofe@yahoo.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Jesse's feedback from using the wait_for() macro was that the msleep
argument was that it was superfluous and made the macro more difficult
to use and to read. As the actually amount of time to sleep is not
critical, the crucial part is to sleep and let the processor schedule
something else whilst we wait for the event, replace the argument with a
hardcoded value.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>

Kill any outstanding unpin_work when destroying the corresponding
crtc. Then flush the workqueue before the gem teardown, in case
any unpin work is still outstanding.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

idle_work wasn't cleaned up at all. It takes &dev->struct_mutex, but
accesss the mode_config crtc list (without any other locking!). Hence
this work needs to be canceled before calling drm_mode_config_cleanup.

As evidenced by the kernel's object debuggin code, the current code
also cleans up the timer to early (it gets rearmed). So move it right
before the final cleanup (it seems to work).

Also unconditionally set up the idle_timer in intel_increase_pllclock.
If we're unlucky the timer might fire right away, rendering the call
in the modesetting teardown pointless.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

hotplug_work is queued by the hotplug interrupt and only either emits
a hotplug uevent or queues a crt poll slow-work. No other locking.  So
it's safe to cancel this work _after_ irq's have been turned off.  But
before the modesetting objects are destroyed because the hotplug
function accesses them (without locking).

The current code (for kms) only switches irqs off after modesetting
teardown, hence move the irq teardown into the modeset cleanup right
before the crtc cleanup.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

This reverts commit b9421ae8.

This warning was so prelevant, even for apparently working machines,
that it was just causing fear, anxiety and panic.

The root cause still remains, so we will add some better debugging when
we focus on fixing it.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=17021Reported-by: NMaciej Rutecki <maciej.rutecki@gmail.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

This reverts commit ce171780.

This commit has been independently bisected a few times as being the cause
of a s2ram failure.
Reported-and-tested-by: NKyle McMartin <kyle@mcmartin.ca>
Reported-and-tested-by: NAndy Isaacson <adi@hexapodia.org>
Cc: Zou Nan hai <nanhai.zou@intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Arguably this is a bug in drm-core in that we should not be called twice
in succession with DPMS_ON, however this is still occuring and we see
FDI link training failures on the second call leading to the occassional
blank display. For the time being ignore the repeated call.

Original patch by Dave Airlie <airlied@redhat.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org

We were passing garbage values into the panel-fitter control register
when disabling it on Ironlake - those values (filter modes and reserved
MBZ bits) would have then be re-used the next time panel-fitting was
enabled.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

When we miss the flip prepare interrupt, we never get into the
software state needed to restart userspace, resulting in a freeze of a
full-screen OpenGL application (such as a compositor).

Work around this by checking DSPxSURF/DSPxBASE to see if the page flip
has actually happened. If it has, do the work we would have done when
the flip prepare interrupt comes in.

Also, add debugfs information to tell us what's going on (based on the
patch from Chris Wilson attached to bugs.fdo bug #29798).
Signed-off-by: NSimon Farnsworth <simon.farnsworth@onelan.co.uk>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

We reset intel_encoder for every matching encoder whilst iterating over
the encoders attached to this crtc when changing mode. As such in a
cloned configuration intel_encoder may not correspond to the correct
is_edp encoder.

By scoping intel_encoder to the loop, not only is the compiler able to
spot this mistake, we also improve readiability for ourselves.
[It might not be a mistake, within this function it is unclear as to
whether it is permissable for eDP to be cloned...]
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Adam Hill reported that his Arrandale system required a much longer, up
to 200x500us, wait for the panel to initialise or else modesetting would
fail.

References:

  https://bugs.freedesktop.org/show_bug.cgi?id=29141Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reported-and-tested-by: NAdam Hill <sidepipeuk@yahoo.co.uk>

Lets try to avoid repeating old bugs.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>

i965 uses the Display Registers to compute the offset from the display
base so the new base does not need adjusting when flipping. The older
chipsets use a fence to access the display and so do perceive the
surface as linear and have a single base register which is reprogrammed
using the flip.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Reported-by: NMarty Jack <martyj19@comcast.net>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>

The vblank status bit is a sticky bit that must be cleared with a write
of '1' prior to polling for the next vblank.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Tested-by: NSitsofe Wheeler <sitsofe@yahoo.com>

jbarnes: I'd still rather see a lock, but I think you're right that
we don't generally wait in code that needs not to miss an interrupt.
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>

When converting this to the new wait_for macro I inverted the wait
condition, which causes all sorts of problems.  So correct it to fix
several failures caused by the bad wait (flickering, bad output
detection, tearing, etc.).
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Tested-by: NSitsofe Wheeler <sitsofe@yahoo.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Waiting for a hard coded 20ms isn't always enough to make sure a vblank
period has actually occurred, so add code to make sure we really have
passed through a vblank period (or that the pipe is off when disabling).

This prevents problems with mode setting and link training, and seems to
fix a bug like https://bugs.freedesktop.org/show_bug.cgi?id=29278, but
on an HP 8440p instead.  Hopefully also fixes
https://bugs.freedesktop.org/show_bug.cgi?id=29141.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

We need to make sure the eDP PLL is enabled before the pipes or planes,
so do it as part of the DP prepare mode set function.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

We need to use I/O port instructions to access VGA registers on
Ironlake+, and it doesn't hurt on other platforms, so switch the VGA
plane disable function over to using them.  Move it to init time as well
while we're at it, no need to repeatedly disable the VGA plane with
every mode set and DPMS event.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Expand the crtc_gamma_set function to accept a starting offset. The
reason for this is to eventually use this function for setcolreg from
drm_fb_helper.c. The fbdev colormap function can start at any offset in
the color map.
Signed-by: NJames Simmons <jsimmons@infradead.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Change the interface to expect a PTR_ERR specifing the real error code
as opposed to assuming a NULL return => -EINVAL. Just once the user may
not be at fault!
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

RC6 allows the GPU to enter a lower power state when the GPU is idle.
Signed-off-by: NZou Nan hai <nanhai.zou@intel.com>
[anholt: Fixed the !renderctx error path to actually not enable RC6.]
Signed-off-by: NEric Anholt <eric@anholt.net>

RC6 power state requires a logical render context in place for saving
render context.
Signed-off-by: NZou Nan hai <nanhai.zou@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

i830 requires 32bpp cursors to be aligned to 16KB, so we have to expose
the alignment parameter to i915_gem_attach_phys_object().
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>

The i845 and i865 have a peculiarlity in that CURBASE is not the trigger
for the vsync update of the cursor registers but instead the
modification of that register is prohibited whilst the cursor is
enabled. Reorder the write sequence for CURPOS, CURCNTR and CURBASE on
i845 to i865 to match.

v2: Remove the checks for i845/i865 from within i9xx_cursor_update()
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>

The FBC is dependent upon a few details of the framebuffer so it is
required to be updated within set_base(), so remove the redundant call
from mode_set().
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>

Add a new macro, wait_for, to simplify the act of waiting on a register
to change state. wait_for() takes three arguments, the condition to
inspect on every loop, the maximum amount of time to wait and whether to
yield the cpu for a length of time after each check.

v2: Upgrade failure messages to DRM_ERROR on the suggestion of
Eric Anholt. We do not expect to hit these conditions as they reflect
programming errors, so if we do we want to be notified.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>

Previously, we only remembered to update the watermarks for i9xx, and
incorrectly assumed that the crtc->enabled flag was valid at that point
in the dpms cycle.

Note that on my x201s this makes a SR bug on pipe 1 much easier to hit.
(Since before this patch when disabling pipe 0, we either didn't update
the watermarks at all, or when we did we still thought we had two pipes
enabled and so disabled SR.)

References:

  Bug 28969 - [Arrandale] Screen flickers, suspect Self-Refresh
  https://bugs.freedesktop.org/show_bug.cgi?id=28969Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>

Writing to the DSPBASE register triggers the double-buffered update to
all the control registers, so always write it last in the update
sequence.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>

v2: Hook in DP paths to keep FULLSCREEN panel fitting on eDP.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

The comments have long desired that we should switch off the cursor
along with the display plane, make it so.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>

My i855GM suffers from a 80k/s interrupt storm without this.
So add 2nd gen to the list of things that don't like more than
one outstanding pageflip request.

Furthermore I've changed the busy loop into a ringbuffer wait.
Busy-loops that don't check whether the chip died are simply evil.
And performance should actually improve, because there's usually
a decent amount of rendering queued on the gpu, hopefully rendering
that MI_WAIT into a noop by the time it's executed.

The current code holds dev->struct_mutex while executing this loop,
hence stalling all other gem activity anyway.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@kernel.org
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[anholt: resolved against conflict]
Signed-off-by: NEric Anholt <eric@anholt.net>