As pinning (allocating and binding GTT memory) does not actually invoke
GPU commands, it is safe, and indeed is attempted, during resumption
from suspension:

  [drm:intel_init_clock_gating] *ERROR* failed to pin power context: -16
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reported-by: NHugh Dickins <hugh.dickins@tiscali.co.uk>
Cc: stable@kernel.org
Signed-off-by: NEric Anholt <eric@anholt.net>

Hugh found an error path where we were attempting to unref a bo without
holding the struct mutex:

  [drm:intel_init_clock_gating] *ERROR* failed to pin power context: -16
  ------------[ cut here ]------------
  WARNING: at drivers/gpu/drm/drm_gem.c:438 drm_gem_object_free+0x20/0x5e()
  Hardware name: ESPRIMO Mobile V5505
  Modules linked in: snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device
  Pid: 3793, comm: s2ram Not tainted 2.6.33-rc2 #4
  Call Trace:
   [<7815298e>] warn_slowpath_common+0x59/0x6b
   [<781529b3>] warn_slowpath_null+0x13/0x18
   [<78317c1a>] ? drm_gem_object_free+0x20/0x5e
   [<78317c1a>] drm_gem_object_free+0x20/0x5e
   [<78317bfa>] ? drm_gem_object_free+0x0/0x5e
   [<7829df11>] kref_put+0x38/0x45
   [<7833a5f0>] intel_init_clock_gating+0x232/0x271
   [<78317bfa>] ? drm_gem_object_free+0x0/0x5e
   [<7832c307>] i915_restore_state+0x21a/0x2b3
   [<7832379d>] i915_resume+0x3c/0xbb
   [<78174fe5>] ? trace_hardirqs_on_caller+0xfc/0x123
   [<7831c756>] ? drm_class_resume+0x0/0x3e
   [<7831c78d>] drm_class_resume+0x37/0x3e
   [<78351e0a>] legacy_resume+0x1e/0x51
   [<78351ece>] device_resume+0x91/0xab
   [<7831c756>] ? drm_class_resume+0x0/0x3e
   [<78352226>] dpm_resume+0x58/0x10f
   [<783522fb>] dpm_resume_end+0x1e/0x2c
   [<78180f80>] suspend_devices_and_enter+0x61/0x84
   [<78180ff8>] enter_state+0x55/0x83
   [<7818091c>] state_store+0x94/0xaa
   [<7829d09e>] kobj_attr_store+0x1e/0x23
   [<782098e0>] sysfs_write_file+0x66/0x99
   [<781cd2f0>] vfs_write+0x8a/0x108
   [<781cd408>] sys_write+0x3c/0x63
   [<78125c10>] sysenter_do_call+0x12/0x36
  ---[ end trace a343537f29950fda ]---

It is in fact slightly more insiduous that first appears since we are
attempting to not just free the object without the lock, but are trying
to do the whole bo manipulation without holding the lock.
Reported-by: NHugh Dickins <hugh.dickins@tiscali.co.uk>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Signed-off-by: NEric Anholt <eric@anholt.net>

drivers/gpu/drm/i915/i915_dma.c: In function 'i915_driver_load':
drivers/gpu/drm/i915/i915_dma.c:1114: warning: 'll_base' may be used uninitialized in this function

Partly this is because gcc isn't smart enough.  But `ll_base' does get used
uninitialised in the DRM_DEBUG() call.

Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Eric Anholt <eric@anholt.net>
Cc: Dave Airlie <airlied@linux.ie>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

The C99 specification states in section 6.11.5:

The placement of a storage-class specifier other than at the beginning
of the declaration specifiers in a declaration is an obsolescent
feature.
Signed-off-by: NTobias Klauser <tklauser@distanz.ch>
Signed-off-by: NEric Anholt <eric@anholt.net>

This code generally fails to adjust the render clock, and when it does,
it conflicts with some other register settings and can cause problems.

So remove this code altogether.  I'm reworking it now to do the right
thing, but the only bit it will share is the VBT check for whether
reclocking is supported, so I'm leaving that bit.

Reverts most of 652c393a ("add dynamic
clock frequency control"), though for many the regressions showed up
in the later 181a5336 ("Fix render
reclock availability detection").
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

We restored RC6 twice on resume, even with modesetting off.  Instead,
only restore it once and skip RC6 initialization entirely in non-KMS mode.
Signed-off-by: NAndy Lutomirski <luto@mit.edu>
Tested-by: NJeff Chua <jeff.chua.linux@gmail.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

This patch adds a new execbuf ioctl, execbuf2, for use by clients that
want to control fence register allocation more finely.  The buffer
passed in to the new ioctl includes a new relocation type to indicate
whether a given object needs a fence register assigned for the command
buffer in question.

Compatibility with the existing execbuf ioctl is implemented in terms
of the new code, preserving the assumption that fence registers are
required for pre-965 rendering commands.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[ickle: Remove pre-emptive clear_fence_reg()]
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NKristian Høgsberg <krh@bitplanet.net>
[anholt: Removed dmesg spam]
Signed-off-by: NEric Anholt <eric@anholt.net>

Make sure hangcheck timer won't beat us unexpectedly on Ironlake.
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

This patch changes around our hotplug enable code a bit to only enable
it for ports we actually detect and initialize.  This prevents problems
with stuck or spurious interrupts on outputs that aren't actually wired
up, and is generally more correct.

Fixes FDO bug #23183.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NKristian Høgsberg <krh@bitplanet.net>
Signed-off-by: NEric Anholt <eric@anholt.net>

Instead of using the IS_I9XX etc macros that expand to a ton of
comparisons, use new struct intel_device_info to capture the
capabilities of the different chipsets.  The drm_i915_private struct
will be initialized to point to the device info that correspond to
the actual device and this way, testing for a specific capability is
just a matter of checking a bit field.
Signed-off-by: NKristian Høgsberg <krh@bitplanet.net>
Signed-off-by: NEric Anholt <eric@anholt.net>

The old include/drm/drm_pciids.h used to be generated from the libdrm
git repo.  We don't use that anymore so just use a local list in the
driver like everybody else.
Signed-off-by: NKristian Høgsberg <krh@bitplanet.net>
Signed-off-by: NEric Anholt <eric@anholt.net>

Dirk reports that nothing is displayed on LVDS when using ubuntu 9.1 after
close/reopen the LID. And I also reproduce this issue on another laptop.
After some tests and debug, it seems that it is related with that the
LVDS status is not updated in time in course of suspend/resume.

Now the LID state is used to check whether the LVDS is connected or
disconnected. And when the LID is closed, it means that the LVDS is
disconnected. When it is reopened, it means that the LVDS is connected.
At the same time on some distributions the LID event is also used to put
the system into suspend state. When the LID is closed, the system will enter
the suspend state. When the LID is reopened, the system will be resumed.

In such case when the LID is closed, user-space script will receive the LID
notification event and  detect the LVDS as disconnected. Then the system will
enter the suspended state. When the LID is reopened, the system will be
resumed. As the LVDS status is not updated in course of resume, it will cause
that the LVDS connector is marked as unused and disabled. After the resume is
finished,user-space script will try to configure the display mode for LVDS.
But unfortunately as the LVDS status is not updated in time and it is still
marked as disconnected, the LVDS and its corresponding CRTC will be disabled
again in the function of drm_helper_disable_unused_functions after changing
mode for LVDS.

So we had better check and update the status of LVDS connector after receiving
the LID notication event. Then after the system is resumed from suspended
state, we can set the display mode for LVDS correctly.
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Reported-by: NDirk Hohndel <hohndel@infradead.org>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
CC: stable@kernel.org
Signed-off-by: NEric Anholt <eric@anholt.net>

The MALATA PC-81005 laptop always reports that the LID status is closed and we
can't use it reliabily for LVDS detection. So add this box into the quirk list.

https://bugs.freedesktop.org/show_bug.cgi?id=25523Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Review-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: NHector <hector1987@gmail.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

One problem in i915 hibernate with current legacy pci pm ops is
that after we do freeze, we'll be forced to do resume once again,
which re-init some resources and do modesetting again, that is
unnecessary for hibernate. This patch trys to bypass that.

We can't resolve this within legacy pm framework, but can do it
easily with new pm ops. Suspend (S3) process has also been kept
without change.
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Checking for the presence of a lid in order to validate whether or not
an LVDS display exists fails on some development platforms that implement
a lid device but allow the LVDS to be disabled. The VBT is correctly
updated, but Linux assumes that an LVDS is still present and lies to
userspace. Remove the lid check and trust the VBT.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

i915_gem_object_unbind had the ordering wrong. The other user,
i915_gem_object_put_fence_reg already has the correct ordering.

Results was usually corrupted pixmaps, especially garbled font glyphs
after a suspend/resume (because this evicts everything).

I'm still waiting for the feedback from the bug-reporters, but
because this obviously fixes a bug (at least for me) I'm already
submitting it.

Bugzilla: http://bugs.freedesktop.org/show_bug.cgi?id=25406Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NEric Anholt <eric@anholt.net>
CC: stable@kernel.org

Fixes a BUG_ON in kmap_atomic for the following atomic mapping with
USER0 type.
Signed-off-by: NEric Anholt <eric@anholt.net>

A residual bare printk survived the merger of the hang detector, remove
this debugging left-over.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>

Rather than restoring just a few clock gating registers on resume,
just reinitialize the whole thing.
Signed-off-by: NAndy Lutomirski <luto@mit.edu>
[anholt: Fixed up for RC6 support landed since the patch was written]
Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
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>

Both radeon and nouveau can re-use this code so move it up a level
so they can. However the hw interfaces for aux ch are different
enough that the code to translate from mode, address, bytes
to actual hw interfaces isn't generic, so move that code into the
Intel driver.
Signed-off-by: NDave Airlie <airlied@redhat.com>

IGD* isn't a useful name.  Replace with the codenames, as sourced from
pci.ids.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
[anholt: Fixed up for merge with pineview/ironlake changes]
Signed-off-by: NEric Anholt <eric@anholt.net>

These are handled by the error return being propagated to user-space and
do not any add any information to the original error, so are useless.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>

If we don't detect a supported memory configuration, we can't enable
CxSR.  Warn the user in this case so they can file a bug.

This patch brings the tree up to date with some fixes that were in a
more recent version of the page flipping patch you applied.  It fixes
pre-965 flip support, removes a leftover hack that forced alignment,
and initializes the pipe & plane CRTC mappings.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

That is "success", "unknown", "through", "performance", "[re|un]mapping"
, "access", "default", "reasonable", "[con]currently", "temperature"
, "channel", "[un]used", "application", "example","hierarchy", "therefore"
, "[over|under]flow", "contiguous", "threshold", "enough" and others.
Signed-off-by: NAndré Goddard Rosa <andre.goddard@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Add the missing clonemask for display port on Ironlake.
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Reviewed-by: NZhenyu Wang <zhenyuw@linux.intel.com>
cc: stable@kernel.org
Signed-off-by: NEric Anholt <eric@anholt.net>

We were always looking for the PORT_IDPB entry.
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Reviewed-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

This is a sync of a fix I made in the old UMS code.  If the BIOS uses
the GMBUS and doesn't clear that setup, then our bit-banging I2C can
fail, leading to monitors not being detected.
Signed-off-by: NEric Anholt <eric@anholt.net>

Without this, on some boots the TV wouldn't be detected.  Testing
showed 15ms to be insufficient.

https://bugs.freedesktop.org/show_bug.cgi?id=24290
https://bugs.freedesktop.org/show_bug.cgi?id=20785Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Tested-by: NYan Seiner <yan@seiner.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

In current vblank-wait implementation, if we turn off VGA output,
drm_wait_vblank will still wait on the disabled pipe until timeout,
because vblank on the pipe is assumed be enabled. This would cause
slow system response on some system such as moblin.

This patch resolve the issue by adding a drm helper function
drm_vblank_off which explicitly clear vblank_enabled[crtc], wake up
any waiting queue and save last vblank counter before turning off
crtc. It also slightly change drm_vblank_get to ensure that we will
will return immediately if trying to wait on a disabled pipe.
Signed-off-by: NLi Peng <peng.li@intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[anholt: hand-applied for conflicts with overlay changes]
Signed-off-by: NEric Anholt <eric@anholt.net>

Otherwise, I'd get stuck in a loop where (afaict) output scan would
trigger a TV interrupt, which would trigger a scan, etc.  TV load
detection not being the fastest thing in the world, X would process
requests very slowly.

https://bugs.freedesktop.org/show_bug.cgi?id=24404Signed-off-by: NAdam Jackson <ajax@redhat.com>
Acked-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Only update the render-clock on transition from busy to idle and vice
versa, or else we burn a significant percentage of the cpu just rewriting
the register -- not quite as power-friendly as intended ;-)
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

Assume that either the presence of an LVDS entry in the VBT or an ACPI
lid device indicates an LVDS device.  ACPI lid alone is not sufficient.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

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

Add a GETPARAM request for checking if page flipping is supported.
Useful for the 2D driver to enable the flipping path.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

Acked-by: NJakob Bornecrantz <jakob@vmware.com>
Acked-by: NThomas Hellström <thomas@shipmail.org>
Review-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NJesse "Orange Smoothie" Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NKristian Høgsberg <krh@bitplanet.net>
Signed-off-by: NEric Anholt <eric@anholt.net>