Older specs claimed this was bit 11, but newer specs and the actual
simulator code say it was bit 12.  Regardless, we don't use MI_FLUSH,
or try to enable it any more.
Signed-off-by: NEric Anholt <eric@anholt.net>
Reviewed-by: NKenneth Graunke <kenneth@whitecape.org>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
[danvet: Anyone trying to use this bit, please read all the relevant
discussions, it's epic.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We have always been using the wrong bit -- it's bit 12.  However, the
bit also doesn't do anything -- hardware has always accepted the
MI_FLUSH command even when it was specced not to.

Given that there is only one MI_FLUSH emitted in all of the driver
stack on gen6+ (in i965_video.c of the 2d driver, and it should be
using other code to do its flush instead), just remove the MI_FLUSH
enable instead of trying to fix it.
Signed-off-by: NEric Anholt <eric@anholt.net>
Reviewed-by: NKenneth Graunke <kenneth@whitecape.org>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This was completely spamming dmesg on my i855gm. This issue was just
shortly introduced with:

commit 931872fc
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Jan 16 23:01:13 2012 +0000

    drm/i915: Check that plane/pipe is disabled before removing the fb
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Otherwise, we are left with pretty bogus message saying that the pixel
format is not supported while leaving the details to the telepatic powers.

v2: use DRM_DEBUG_KMS instead of DRM_ERROR
Signed-off-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Now that we're using the sprite WM fields, we need to take care not to
clobber them in the main update_wm functions.  While we're at it, make
sure we mask out the old sprite wm value before or'ing in the new one
when the sprite wm is updated.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

I've reviewed gen2 pageflip code to hunt down multiple prepare pageflip
issues. The only thing I've found is a slight but functionally
meaningless confusion about the length of the mi cmd.

Fix it up and add a comment about what this dword should be (according
to docs at least).
Reviewed-by: NEric Anholt <eric@anholt.net>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

LLC is not SNB/IVB-specific, so we should check for it in a more generic
way.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NEric Anholt <eric@anholt.net>
Reviewed-by: NKenneth Graunke <kenneth@whitecape.org>
Signed-off-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Some decent history digging indicates that this was to be used for the
GLX_MESA_allocate_memory extension but never actually implemented for
any released i915 userspace code.

So just rip it out.

v2: Fixup the Makefile.
Acked-by: NDave Airlie <airlied@gmail.com>
Cc: Keith Whitwell <keithw@vmware.com>
Reviewed-by: NEric Anholt <eric@anholt.net>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The advantage of kcalloc is, that will prevent integer overflows which could
result from the multiplication of number of elements and size and it is also
a bit nicer to read.

The semantic patch that makes this change is available
in https://lkml.org/lkml/2011/11/25/107Signed-off-by: NThomas Meyer <thomas@m3y3r.de>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This is paranoid, but I am entirely willing to believe the hardware
could come up with a condition where I get a status with both the 'done'
and 'receive error' bits set.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The default in the Sandybridge docs is 5, as on Ironlake, and I have no
reason to believe 3 would work any better.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Matches the advice in the Sandybridge documentation.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

There is an error in i915_read_blc_pwm_ctl, where the register values
are not being copied correctly.  BLC_PWM_CTL and BLC_PWM_CTL2 are
getting mixed up.  This patch fixes that so that saveBLC_PWM_CTL2 and
not saveBLC_PWM_CTL is copied to the BLC_PWM_CTL2 register.
Signed-off-by: NSimon Que <sque@chromium.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Staring at an error state such as:

PGTBL_ER: 0x00000400
    Display B: Invalid tiling
fence[0] = 05001001
    valid, x-tiled, pitch: 512, start: 0x05000000, size: 1048576
Pinned [2]:
  00000000   131072 0001 0001 00000000 P uncached
  00020000  4096000 0041 0000 00000000 P uncached (name: 1)
Plane [1]:
  CNTR: c0000000 # enabled | gamma
  STRIDE: 00001400
  SIZE: 03ff04ff
  POS: 00000000
  ADDR: 05000000

Suggests that we did not clear the DSPBCNTR prior to unpinning the
framebuffer and reusing the GTT space. Impossible! Unless our DPMS
bookkeeping ran afoul again...

In the meantime add an assertion that the plane is decoupled from the
framebuffer prior to release.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Fix function name in comments, a left-over from when i965_reset was
renamed to i915_reset.
Signed-off-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This cleans up the mode set path a little further, making it easier to
extend for future platforms.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[danvet: shut up stupid gcc warning about potential use of
un-initlized fp2]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Makes the mode set routine a little cleaner and easier to extend.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

After checking the specs and discussing with Jesse, turns out CxSR is not
available on Ironlake and gen5, and its advertisement on the device
description is misleading.
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This patch enforces that the downclock clock source is the same as the preferred
clock source for LVDS. This fixes a bug where the driver chooses a downclock
clock source with a different P than the preferred mode clock source. This
happened even if the preferred clock source implemented an acceptable rate for
the downclock. The result of this bug is that downclock is disabled.
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

<@ajax> mjg59: how concerned should i be about [drm:intel_dsm_pci_probe]
        *ERROR* failed to get supported _DSM functions ?
<@mjg59> ajax: Entirely unconcerned
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

So we have a few places where the drm drivers would like to sleep to
be nice to the system, mainly in the modesetting paths, but we also
have two cases were atomic modesetting must take place, panic writing
and kernel debugger. So provide a central inline to determine if a
sleep or delay should be used and use this in the intel and radeon drivers.

v2: drop intel_drv.h MSLEEP macro, nobody uses it.

Based on patch from Michel Dänzer <michel.daenzer@amd.com>

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43941Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

In cases where the scanout hw is sufficiently similar between "overlay"
and traditional crtc layers, it might be convenient to allow the driver
to create internal drm_plane helper objects used by the drm_crtc
implementation, rather than duplicate code between the plane and crtc.
A private plane is not exposed to userspace.
Signed-off-by: NRob Clark <rob@ti.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

If it failed, leave it in the "off" state.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NKeith Packard <keithp@keithp.com>

If a PCH pipe PLL is being used by transcoder C, don't disable it.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NKeith Packard <keithp@keithp.com>

In the pre-gem days with non-existing hangcheck and gpu reset code,
this timeout of 3 seconds was pretty important to avoid stuck
processes.

But now we have the hangcheck code in gem that goes to great length
to ensure that the gpu is really dead before declaring it wedged.

So there's no need for this timeout anymore. Actually it's even harmful
because we can bail out too early (e.g. with xscreensaver slip)
when running giant batchbuffers. And our code isn't robust enough
to properly unroll any state-changes, we pretty much rely on the gpu
reset code cleaning up the mess (like cache tracking, fencing state,
active list/request tracking, ...).

With this change intel_begin_ring can only fail when the gpu is
wedged, and it will return -EAGAIN (like wait_request in case the
gpu reset is still outstanding).

v2: Chris Wilson noted that on resume timers aren't running and hence
we won't ever get kicked out of this loop by the hangcheck code. Use
an insanely large timeout instead for the HAS_GEM case to prevent
resume bugs from totally hanging the machine.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Acked-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>

If our semaphore logic gets confused and we have a ring stuck waiting
for one, there's a decent chance it'll just execute garbage when being
kicked. Also, kicking the ring obscures the place where the error
first occured, making error_state decoding much harder.

So drop this an let gpu reset handle this mess in a clean fashion.

In contrast, kicking rings stuck on MI_WAIT is rather harmless, at
worst there'll be a bit of screen-flickering. There's also old
broken userspace out there which needs this as a  work-around.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NChris Wilson <chris@hchris-wilson.co.uk>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NKeith Packard <keithp@keithp.com>

These registers are automatically incremented by the hardware during
transform feedback to track where the next streamed vertex output
should go.  Unlike the previous generation, which had a packet for
setting the corresponding registers to a defined value, gen7 only has
MI_LOAD_REGISTER_IMM to do so.  That's a secure packet (since it loads
an arbitrary register), so we need to do it from the kernel, and it
needs to be settable atomically with the batchbuffer execution so that
two clients doing transform feedback don't stomp on each others'
state.

Instead of building a more complicated interface involcing setting the
registers to a specific value, just set them to 0 when asked and
userland can tweak its pointers accordingly.
Signed-off-by: NEric Anholt <eric@anholt.net>
Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: NKenneth Graunke <kenneth@whitecape.org>
Signed-off-by: NKeith Packard <keithp@keithp.com>

The waits we do here are generally so short that sleeping is a bad
idea unless we have an IRQ to wake us up.  Improves regression test
performance from 18 minutes to 3.5 minutes on gen7, which is now
consistent with the previous generation.
Signed-off-by: NEric Anholt <eric@anholt.net>
Tested-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Acked-by: NKenneth Graunke <kenneth@whitecape.org>
Signed-off-by: NKeith Packard <keithp@keithp.com>

Previous to this commit, testing easily reproduced a failure where the
seqno would apparently arrive after the IRQ associated with it, with test programs as simple as:

for (;;) {
    glCopyPixels(0, 0, 1, 1);
    glFinish();
}

Various workarounds we've seen for previous generations didn't work to
fix this issue, so until new information comes in, replace the IRQ
waits on the BLT ring with polling.
Signed-off-by: NEric Anholt <eric@anholt.net>
Tested-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Acked-by: NKenneth Graunke <kenneth@whitecape.org>
Signed-off-by: NKeith Packard <keithp@keithp.com>

As a workaround for IRQ synchronization issues in the gen7 BLT ring,
we want to turn the two wait functions into polling loops.
Signed-off-by: NEric Anholt <eric@anholt.net>
Tested-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Acked-by: NKenneth Graunke <kenneth@whitecape.org>
Signed-off-by: NKeith Packard <keithp@keithp.com>

They don't fix our problems alone, but we're told to set them.
Signed-off-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NKeith Packard <keithp@keithp.com>

Add new ioctls for getting and setting the current destination color
key.  This allows for simple overlay display control by matching a color
key value in the primary plane before blending the overlay on top.

v2: remove unnecessary mutex acquire/release around reg accesses
v3: add support for full color key management
v4: fix copy & paste bug in snb_get_colorkey
    don't bother checking min/max values against docs as the docs are likely
    wrong (how could we handle 10bpc surface formats?)
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

To save power when the sprite is full screen, we can disable the primary
plane on the same pipe.  Track the sprite status and enable/disable the
primary opportunistically.

v2: remove primary plane enable/disable hooks; they're identical
Reviewed-by: NDaniel Vetter <daniel@ffwll.ch>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NKeith Packard <keithp@keithp.com>

The video sprites support various video surface formats natively and can
handle scaling as well.  So add support for them using the new DRM core
sprite support functions.

v2: use drm specific fourcc header and defines
v3: address Daniel's comments:
  - don't take struct mutex around register access (only needed for
    regs in the GT power well)
  - don't hold struct mutex across vblank waits
  - fix up update_plane API (pass obj instead of GTT offset)
  - add interlaced defines for sprite regs
  - drop unnecessary 'reg' variables
  - comment double buffered reg flushing
  Also fix w/h confusion when writing the scaling reg.
v4: more fixes, address more comments from Daniel, and include Hai's fix
  - prevent divide by zero in scaling calculation (Hai Lan)
  - update to Ville's new DRM_FORMAT_* types
  - fix sprite watermark handling (calc based on CRTC size, separate
    from normal display wm)
  - remove private refcounts now that the fb cleanups handles things
v5: add linear surface support
v6: remove color key clearing & setting from update_plane

For this version, I tested DPMS since it came up in the last review;
DPMS off/on works ok when a video player is working under X, but for
power saving we'll probably want to do something smarter.  I'll leave
that for a separate patch on top.  Likewise with the refcounting/fb
layer handling, which are really separate cleanups.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NKeith Packard <keithp@keithp.com>

We learned that the ECOBUS register was inside the GT power well, and
so *did* need force wake to be read, so it gets removed from the list
of 'doesn't need force wake' registers.

That means the code reading ECOBUS after forcing the mt_force_wake
function to be called needs to use I915_READ_NOTRACE; it doesn't need
to do more force wake fun as it's already done it manually.

This also adds a comment explaining why the MT forcewake testing code
only needs to call mt_forcewake_get/put and not disable RC6 manually
-- the ECOBUS read will return 0 if the device is in RC6 and isn't
using MT forcewake, causing the test to work correctly.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>

Many of the old fields from Ironlake have gone away. Strip all those
fields, and try to update to fields people care about. RC information
isn't exactly ideal anymore. All we can guarantee when we read the
register is that we're not using forcewake, ie. the software isn't
forcing the hardware to stay awake. The downside is that in doing this
we may wait a while and that causes an unnaturally idle state on the
GPU.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42578Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NKeith Packard <keithp@keithp.com>

This matches the modern specs more accurately.

This will be used by the following patch to fix the way we display RC
status.
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>