See http://bugzilla.kernel.org/show_bug.cgi?id=15021

Make sure that the appropriate AGP module is loaded and probed before
trying to set up the DRM.  The DRM already depends on the AGP core,
but in this case we know the specific AGP driver we need too, and can
help users avoid the trap of loading the AGP driver after the DRM
driver.
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

I think this is pretty much correct.  Not really tested.
Signed-off-by: NEric Anholt <eric@anholt.net>

Disables CXSR until it's done, and sets the mobile bit on mobile.
Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NEric Anholt <eric@anholt.net>

New memory control config reg at 0x50 should be used for stolen
memory size detection on Sandybridge.
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NEric Anholt <eric@anholt.net>

I can't explain this, except that it makes my display correct.
Signed-off-by: NEric Anholt <eric@anholt.net>

The register's moved to the same location as the one for the BCS, it seems.
Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NEric Anholt <eric@anholt.net>

In order to improve our diagnostic capabilities following a GPU hang
and subsequent reset, we need to record the batch buffer that triggered
the error. We assume that the current batch buffer, plus a few details
about what else is on the active list, will be sufficient -- at the very
least an improvement over nothing.

The extra information is stored in /debug/dri/.../i915_error_state
following an error, and may be decoded using
intel_gpu_tools/tools/intel_error_decode.

v2: Avoid excessive work under spinlocks.
v3: Include ringbuffer for later analysis.
v4: Use kunmap correctly and record more buffer state.
v5: Search ringbuffer for current batch buffer
v6: Use a work fn for the impossible IRQ error case.
v7: Avoid non-atomic paths whilst in IRQ context.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>

These old machines more often than not lie about their lid state.  So
don't use it to detect LVDS presence, but leave the event handler to
deal with lid open/close, when we might need to reset the mode.

Fixes kernel bug #15248
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Cc: stable@kernel.org
Signed-off-by: NEric Anholt <eric@anholt.net>

i915_gem_object_fenceable was mostly just a repeat of the
i915_gem_object_fence_offset_ok, but also checking the size (which was
checkecd when we allowed that BO to be tiled in the first place). So
instead, export the latter function and use it in place.
Signed-Off-By: NOwain G. Ainsworth <oga@openbsd.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

This aligns it with the other user of i915_gem_clear_fence_reg,
which blows away the mapping before changing the fence reg.

Only affects userspace if it races against itself when changing
tiling parameters, i.e. behaviour is undefined, anyway.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>

No functional change, because gtt flushing is a no-op. Still, try
to keep the bookkeeping accurate. The if is still slightly wrong
for with execbuf2 even i915-class hw doesn't always need a fence
reg for gpu access. But that's for somewhen lateron.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NEric Anholt <eric@anholt.net>

Cache-coherency is maintained by gem. Drop these leftover MI_FLUSH
commands from the userspace code.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>

I retested this and whatever this papered over, the problem doesn't seem
to exist anymore.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NEric Anholt <eric@anholt.net>
[anholt: fixed up compile warning]
Signed-off-by: NEric Anholt <eric@anholt.net>

Commit 84b79f8d (drm/i915: Fix crash
while aborting hibernation) attempted to fix a regression introduced
by commit cbda12d7 (drm/i915:
implement new pm ops for i915), but it went too far trying to split
the freeze/suspend and resume/thaw parts of the code.  As a result,
it introduced another regression, which only is visible on some systems.

Fix the problem by merging i915_drm_suspend() with
i915_drm_freeze() and moving some code from i915_resume()
into i915_drm_thaw(), so that intel_opregion_free() and
intel_opregion_init() are also executed in the freeze and thaw code
paths, respectively.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Reported-and-tested-by: NPedro Ribeiro <pedrib@gmail.com>
Tested-by: NTino Keitel <tino.keitel@tikei.de>
Acked-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

Tools like powertop want to check the current FBC status and report it
to the user.  So add a debugfs file indicating whether FBC is enabled,
and if not, why.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

At unload time, we need to disable DRPS, but we need to do it correctly
or the GPU will hang and we won't be able to load the module again.  So
set the SFCAVM bit so we can properly restore the DRPS config at unload.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

He Shuang reported an OGLC performance regression introduced in the patch
"enable memory self refresh on 9xx", In that patch, SR on 945 is disabled
everytime when calling intel_mark_busy(), while too much of such operation
will impact performance. Actually disable SR is necessary only when GPU and
Crtc changing from idle to busy. This patch make such optimization.

It fixes upstream bug
http://bugs.freedesktop.org/show_bug.cgi?id=26422Signed-off-by: NLi Peng <peng.li@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

The ironlake render p-state support includes some rather odd variable
names. Clean them up in order to improve the readability of the code.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Ironlake (and 965GM, which this patch doesn't support) supports a
hardware performance and power management feature that allows it to
adjust to changes in GPU load over time with software help.  The goal
if this is to maximize performance/power for a given workload.

This patch enables that feature, which is also a requirement for
supporting Intelligent Power Sharing, a feature which allows for
dynamic budgeting of power between the CPU and GPU in Arrandale
platforms.
Tested-by: Nykzhao <yakui.zhao@intel.com>
[anholt: Resolved against the irq handler loop removal]
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

Enabling memory self refresh (SR) on 9xx needs to set additional
register bits. On 945, we need bit 31 of FW_BLC_SELF to enable the
write to self refresh bit and bit 16 to enable the write of self
refresh watermark. On 915, bit 12 of INSTPM is used to enable SR.

SR will take effect when CPU enters C3+ state and its entry/exit
should be automatically controlled by H/W, driver only needs to set
SR enable bits in wm update. But this isn't safe in my test on 945
because GPU is hung. So this patch explicitly enables SR when GPU
is idle, and disables SR when it is busy. In my test on a netbook of
945GSE chipset, it saves about 0.8W idle power.
Signed-off-by: NLi Peng <peng.li@intel.com>
[anholt: rebased against 33c5fd12
by adding disable of INSTPM SR bit on 915GM for two pipe setup]
Signed-off-by: NEric Anholt <eric@anholt.net>

The fence start is for compatibility with UMS X Servers before fence
management.  KMS X Servers only started doing tiling after fence
management appeared.
Signed-off-by: NEric Anholt <eric@anholt.net>

As we need more and more controls within MCHBAR for memory config and
power management, this trys to keep MCHBAR enabled from driver load and
only tear down in driver unload.
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

With the introduction of the hang-check, we can safely expect that
i915_wait_request() will always return even when the GPU hangs, and so
do not need to open code the wait in order to manually check for the
hang. Also we do not need to always evict all buffers, so only flush
the GPU (and wait for it to idle) for KMS, but continue to evict for UMS.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>

Wrong Lid state reported.
Need to blacklist this machine for LVDS detection.
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Mostly obvious simplifications.

The i915 pread/pwrite ioctls, intel_overlay_put_image and
nouveau_gem_new were incorrectly using the locked versions
without locking: this is also fixed in this patch.
Signed-off-by: NLuca Barbieri <luca@luca-barbieri.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This will prevent things from falling over if the user frees the flip
buffer before we complete the flip, since we'll hold an internal
reference.
Reported-by: NKristian Høgsberg <krh@bitplanet.net>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

Commit cbda12d7 (drm/i915: implement
new pm ops for i915) introduced the problem that if s2disk hibernation
is aborted, the system will crash, because i915_pm_freeze() does
nothing, while it should at least reverse some operations carried out
by i915_suspend().

Fix this issue by splitting the i915 suspend into a freeze part a
suspend part, where the latter is not executed before creating a
hibernation image, and the i915 resume into a "low-level" resume part
and a thaw part, where the former is not executed after the image has
been created.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Tested-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NOwain G. Ainsworth <oga@openbsd.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

The MI_DISPLAY_FLIP command needs to be set the same pipe
source image like in pipe source register, e.g source image
size minus one. This fixes screen corrupt issue on Ironlake.
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

On Ironlake plane flip interrupt means flip done event already, the
behavior is not like old chips, and perform like other usual interrupt.
So only need to handle flip done event when receiving that interrupt.
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

When a new page flip is requested, we need to both queue an unpin for
the current framebuffer, and also increment the flip pending count on
the newly submitted buffer.

At flip finish time, we need to unpin the old fb and decrement the flip
pending count on the new buffer.

The old code was conflating the two, and led to hangs when new direct
rendered apps were started, replacing the existing frame buffer.  This
patch splits out the buffers and prevents the hangs.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NKristian Høgsberg <krh@bitplanet.net>
Signed-off-by: NEric Anholt <eric@anholt.net>

On 945, we need to avoid entering self-refresh if the compressor is
busy, or we may cause display FIFO underruns leading to ugly flicker.

Fixes fdo bug #24314, kernel bug #15043.
Tested-by: NAlexander Lam <lambchop468@gmail.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Julien Cristau <jcristau@debian.org> (fd.o #25371)
Cc: stable@kernel.org
Signed-off-by: NEric Anholt <eric@anholt.net>

An untiled framebuffer must be aligned to 64k. This is normally handled
by intel_pin_and_fence_fb_obj(), but the intelfb_create() likes to be
different and do the pinning itself. However, it aligns the buffer
object incorrectly for pre-i965 chipsets causing a PGTBL_ERR when it is
installed onto the output.

Fixes:
  KMS error message while initializing modesetting -
  render error detected: EIR: 0x10 [i915]
  http://bugs.freedesktop.org/show_bug.cgi?id=22936Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Signed-off-by: NEric Anholt <eric@anholt.net>

Before changing the status of a buffer with a pending write we will await
upon a new flush for that buffer. So we can take advantage of any flushes
posted whilst the buffer is active and pending processing by the GPU, by
clearing its write_domain and updating its last_rendering_seqno -- thus
saving a potential flush in deep queues and improves flushing behaviour
upon eviction for both GTT space and fences.

In order to reduce the time spent searching the active list for matching
write_domains, we move those to a separate list whose elements are
the buffers belong to the active/flushing list with pending writes.

Orignal patch by Chris Wilson <chris@chris-wilson.co.uk>, forward-ported
by me.

In addition to better performance, this also fixes a real bug. Before
this changes, i915_gem_evict_everything didn't work as advertised. When
the gpu was actually busy and processing request, the flush and subsequent
wait would not move active and dirty buffers to the inactive list, but
just to the flushing list. Which triggered the BUG_ON at the end of this
function. With the more tight dirty buffer tracking, all currently busy and
dirty buffers get moved to the inactive list by one i915_gem_flush operation.

I've left the BUG_ON I've used to prove this in there.

References:
  Bug 25911 - 2.10.0 causes kernel oops and system hangs
  http://bugs.freedesktop.org/show_bug.cgi?id=25911

  Bug 26101 - [i915] xf86-video-intel 2.10.0 (and git) triggers kernel oops
              within seconds after login
  http://bugs.freedesktop.org/show_bug.cgi?id=26101Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Tested-by: NAdam Lantos <hege@playma.org>
Cc: stable@kernel.org
Signed-off-by: NEric Anholt <eric@anholt.net>