When a transcoder is disabled, any ports pointing at it should also be
disabled.  If they're not, we may fail to disable the transcoder,
leading to blank displays.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

These bits have a different meaning on ILK+, where planes are hardwired
to pipes.  Fixing this avoid some spurious assertion failures.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

The specs say to do so.
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

For consistency and segregation from the noisy DRM_DEBUG().
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

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

With the recent SDVO fix, this is working on all the machines I have to
hand - except for an 845G.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Merge resume fixes from -fixes and an important fix for SDVO GMBUS.

Fortunately unreachable. For Crestline, the watermarks must always be
programmed to 8...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Judging by comments in the BIOS, if the SDVO LVDS option h40 is enabled,
then we are supposed to query the real panel type via Int15. We don't do
this and so for the Sony Vaio VGC-JS210J which has otherwise default
values, we choose the wrong mode.

This patch adds a driver option, i915.vbt_sdvo_panel_type, which can be
used to override the value in the VBT.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=33691Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

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

Hugh Dickins found that characters in xterm were going missing and oft
delayed. Being the curious type, he managed to associate this with the
new high-precision vblank patches; disabling these he found, restored
the orderliness of his characters.

The oddness begins when one realised that Hugh was not using vblanks at
all on his system (fvwm and some xterms). Instead, all he had to go on
were warning of a pipe underrun, curiously enough at around 60Hz. He
poked and found that in addition to the underrun warning, the hardware
was flagging the start of a new frame, a vblank, which in turn was
kicking off the pending vblank processing code.

There is little we can do for the underruns on Hugh's machine, a
Crestline [965GM], which must have its FIFO watermarks set to 8.
However, we do not need to process the vblank if we know that they are
disabled...
Reported-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

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

By setting the FB of a CRTC to NULL, we are turning off the CRTC (and so
disable the unused encoders and connectors). As such we can simplify the
later tests by making sure the set->mode is NULL. Setting the
num_connectors to zero means that we do not need to loop over the unused
connectors.

All current usage appears correct, this only builds additional defense
into the routine.

References: https://bugzilla.kernel.org/show_bug.cgi?id=27722Tested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

In drm_crtc_helper_set_config, we call drm_crtc_helper_set_mode which
may return early and do no operation if the crtc is to be disabled. In
this case we merrily swap to the new fb, discarding the old_fb believing
that it has been cleaned up. However, due to the early return, the
old_fb was not presented to the backend for correct reaping, and nor was
the new one - which is about to be reaped via the
drm_helper_disable_unused_functions(), leading to incorrect refcounting
of the pinned objects.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=27722
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=29857
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=29230Tested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

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

Instead of reporting EIO upfront in the entrance of an ioctl that may or
may not attempt to use the GPU, defer the actual detection of an invalid
ioctl to when we issue a GPU instruction. This allows us to continue to
use bo in video memory (via pread/pwrite and mmap) after the GPU has hung.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

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

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

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

Based on a patch by Takashi Iwai.
Reported-by: Matthias Hopf <mat@mshopf.de>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=27272Tested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Upon resume, like after a cold boot, we need to forcibly probe the
analog connector and cannot rely on the hotplug status.

Based on a patch by Takashi Iwai.
Reported-by: Stefan Dirsch <sndirsch@suse.de>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=26952Tested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Call drm_mode_config_reset() after an invalidation event to restore any
cached state to unknown.
Tested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Iterate over the attached CRTCs, encoders and connectors and call the
supplied reset vfunc in order to reset any cached state back to unknown.
Useful after an invalidation event such as a GPU reset or resuming.
Tested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

We were not pausing after detecting the response was pending and so did
not allow the hardware sufficient time to complete before aborting. This
lead to transient failures whilst probing SDVO devices.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30235Reported-by: Knut Petersen <Knut_Petersen@t-online.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Rather than power cycling the panel when there are no bits to display,
use the VDD AUX bit to power the panel up just enough for DP AUX
transactions to work.  This prevents a bit of unnecessary ugliness as
mode sets occur on the panel.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Now that we're doing the right thing elsewhere, these are no longer
necessary.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31114Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Move the plane->mode config to the point of use rather than repeatedly
querying the same information.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

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

Merge important suspend and resume regression fixes and resolve the
small conflict.

Conflicts:
	drivers/gpu/drm/i915/i915_dma.c

error_bo and pinned_bo could be used uninitialised if there were no
active buffers.

Caught by kmemcheck.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

The opregion is a shared memory region between ACPI and the graphics
driver. As the ACPI mapping has been changed to cachable in commit
6d5bbf00, mapping the intel opregion
non-cachable now fails. As no bus-master hardware is involved in the
opregion, cachable map should do no harm.

Tested on a Fujitsu Lifebook P8010.
Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
[ickle: convert to acpi_os_ioremap for consistency]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Merge with Linus to resolve conflicting fixes for the reusing the stale
HEAD value during intel_ring_wait().

Conflicts:
	drivers/gpu/drm/i915/intel_ringbuffer.c

If the driver calls into the kernel to wait for a breadcrumb to pass,
but hasn't enabled interrupts, fallback to polling the breadcrumb value.
Reported-by: Chris Clayton <chris2553@googlemail.com>
Tested-by: Chris Clayton <chris2553@googlemail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

We only have sufficient information for accurate (sub-frame) timestamping
when the modesetting is under our control.
Reported-by: Chris Clayton <chris2553@googlemail.com>
Tested-by: Chris Clayton <chris2553@googlemail.com>
Reviewed-by: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Reported-by: Chris Clayton <chris2553@googlemail.com>
Tested-by: Chris Clayton <chris2553@googlemail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

We can only utilize the stolen portion of the GTT if we are in sole
charge of the hardware. This is only true if using GEM and KMS,
otherwise VESA continues to access stolen memory.
Reported-by: Arnd Bergmann <arnd@arndb.de>
Reported-by: Frederic Weisbecker <fweisbec@gmail.com>
Tested-by: Jiri Olsa <jolsa@redhat.com>
Tested-by: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

* 'BUG_ON' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linus:
  Remove MAYBE_BUILD_BUG_ON
  BUILD_BUG_ON: make it handle more cases

* git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linus:
  module: fix missing semicolons in MODULE macro usage
  param: add null statement to compiled-in module params
  module: fix linker error for MODULE_VERSION when !MODULE and CONFIG_SYSFS=n
  module: show version information for built-in modules in sysfs

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6:
  selinux: return -ENOMEM when memory allocation fails
  tpm: fix panic caused by "tpm: Autodetect itpm devices"
  TPM: Long default timeout fix
  trusted keys: Fix a memory leak in trusted_update().
  keys: add trusted and encrypted maintainers
  encrypted-keys: rename encrypted_defined files to encrypted
  trusted-keys: rename trusted_defined files to trusted

Now BUILD_BUG_ON() can handle optimizable constants, we don't need
MAYBE_BUILD_BUG_ON any more.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>