-ENOSPC can happen if userspace is being simplistic and tries to map a
too big object. To aid further spurious WARN debugging, also print out
the error code.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56017Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This reverts commit 24773670.

If (for whatever reason) the DP sink device never asks for the maximal
voltage level, we never don't hit the check that should bail us out
after 5 retries of the same voltage. Which leads to an endless loop in
the DP link training code, which hangs the driver.

Now some more DP link training experiments on eDP panels seem to
indicate that our training algorithm isn't robust enough anyway and
needs more work. Hence for 3.7-fixes, let's just revert the regressing
commit instead of trying to apply more duct-tape.
Reported-by: NOleksij Rempel <bug-track@fisher-privat.net>
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

For TV and LVDS encoders intel_sdvo_set_input_timings_for_mode()
is called to pass a mode to the sdvo chip and retrieve a dtd
containing information needed to calculate the adjusted_mode which
is done by intel_sdvo_get_dtd_from_mode().
To set this adjusted_mode as input mode for the sdvo chip, a dtd is
recalculated using intel_sdvo_get_mode_from_dtd(). During this round
trip the sdvo_flags contained in the dtd obtained from the hardware
are lost.
Since these flags cannot be ignored in all cases this patch preserves
and restores them.

This regression has been introduced in

commit 6651819b
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun Apr 1 19:16:18 2012 +0200

    drm/i915: handle input/output sdvo timings separately in mode_set
Signed-off-by: NEgbert Eich <eich@suse.de>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

SDVO LVDS are not clonable as the input mode gets adjusted by
the LVDS encoder.
Signed-off-by: NEgbert Eich <eich@suse.de>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

NCR machines with LVDS panels using Intel chipsets need to have the
QUIRK_INVERT_BRIGHTNESS bit set.
Unfortunately NCR doesn't set a meaningful subvendor/subdevice ID,
therefore we add a DMI dependent quirk list.
Signed-off-by: NEgbert Eich <eich@suse.de>
[danvet: fixup whitespace fail.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The DPLL multipiler is set up in intel_display.c:i9xx_update_pll()
called from i9xx_crtc_mode_set().
There the DPLL multiplier is adjusted so that the SDVO gets a sufficient
bus clock.
When cloning a CRTC between an SDVO driven encoder and the standard
DAC the DAC setup code reseted the multiplier value to 1 thus undoing
the correct setup. There is no need to touch the multiplier in the DAC
setup code: the correct value (i.e. 1 in case no SDVO encoder is used)
is set by i9xx_update_pll() already.
A comment at the code suggested that this code is a left over from the
days when there was no setup for clone modes.
Signed-off-by: NEgbert Eich <eich@suse.de>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Backlight is initialized for eDP, but cleaned up only for eDP on DP-D
port. This leaves behind a dangling backlight interface on module unload on
machines that have eDP connected to something other than DP-D, and breaks
the backlight interface for subsequent module reloads. Fix the cleanup, and
thus module reload on affected machines.
Reported-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Tested-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This magic brings stability to HSW CRW machines.
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The boot-up state seems to be all-zeros, so it's safer to check for
the bits that need to be set when the dvo encoder is in the dpms on
state, than checking the bits we set when it's in the off state.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55047Tested-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We need to check whether the _other plane is on our pipe, not whether
our plane is on the other pipe. Otherwise if not both pipes/planes are
active, we won't properly clean up the mess and set up our desired
plane->pipe mapping.

v2: Fixup the logic, I've totally fumbled it. Noticed by Chris Wilson.

v3: I've checked Bspec, and the flexible plane->pipe mapping is a
gen2/3 feature, so test for that instead of PCH_SPLIT

v4: Check whether we indeed have 2 pipes before checking the other
pipe, to avoid upsetting i845g/i865g. Noticed by Chris Wilson.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51265
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49838Tested-by: NDave Airlie <airlied@gmail.com>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk> #855gm
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This seems to be the root-cause that breaks resume on my i855gm when I
apply the "drm/i915: fixup the plane->pipe fixup code" patch. And that
code doesn't even run on my machine, so it's pure timing changes
causing the regression.

Furthermore resume has been constantly switching between working and
broken on this machine ever since kms support has been merged,
seemingly with no related change as a root cause. And always with the
same symptoms of the backlight lighting up, but the lvds panel only
displaying black.

Also, of both i855gm variants only one is in the table. And in the
past we've only ever removed entries from this quirk table because it
breaks things.

So let's just remove it - in case there's indeed a bios out there
relying on a running pipe A, we can add back in a more precise quirk
entry, like all the others (save for i830/i845).

Tested-by: Chris Wilson <chris@chris-wilson.co.uk> #855gm
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Note that just because we have n == MAX elements left, does not imply
that there are only MAX elements left in the scatterlist and so we may
not be on the last chain, and the nth element may in fact be a chain ptr.

This is exercised by the improved hangman tests and the gem_exec_big
test in i-g-t.

This regression has been introduced in

commit 9da3da66
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Jun 1 15:20:22 2012 +0100

   drm/i915: Replace the array of pages with a scatterlist

v2: KISS, replace the direct lookup with a for_each_sg() [danvet]
v3: Try to be clever again.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The intention was to allow the caller to avoid a failure to queue a
request having already written commands to the ring. However, this is a
moot point as the i915_add_request() can fail for other reasons than a
mere allocation failure and those failure cases are more likely than
ENOMEM. So the overlay code already had to handle i915_add_request()
failures, and due to

commit 3bb73aba
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Jul 20 12:40:59 2012 +0100

    drm/i915: Allow late allocation of request for i915_add_request()

the error handling code in intel_overlay.c was subject to causing
double-frees, as found by coverity.

Rather than further complicate i915_add_request() and callers, realise
the battle is lost and adapt intel_overlay.c to take advantage of the
late allocation of requests.

v2: Handle callers passing in a NULL seqno.
v3: Ditto. This time for sure.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

A previous patch, namely:

commit bf97b276
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Apr 11 20:42:41 2012 +0200

    drm/i915: implement w/a for incorrect guarband clipping

accidentally set bit 5 in 3D_CHICKEN, which has nothing to do with
clipping.  This patch changes it to be set in 3D_CHICKEN3, where it
belongs.

The game "Dante" demonstrates random clipping issues when guardband
clipping is enabled and bit 5 of 3D_CHICKEN3 isn't set.  So the
workaround is actually necessary.

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Oliver McFadden <oliver.mcfadden@linux.intel.com>
Acked-by: NPaul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: NKenneth Graunke <kenneth@whitecape.org>
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

I've discovered this on my ivb machine while stress-testing the new
flip_tests. Only harmful effect observed is that the timestamp is a
bit bogus.

Note that this is empirical duct-tape: I've noticed that we seem to
only ever miss the very first vblank irq right after enabling the
pipe. And with this hack applied I couldn't reproduce the failure case
anywhere else any more.
Tested-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

starting an old X server causes a kernel BUG since commit 1b50247a:

------------[ cut here ]------------
kernel BUG at drivers/gpu/drm/i915/i915_gem.c:3661!
invalid opcode: 0000 [#1] SMP
Modules linked in: snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss uvcvideo
+videobuf2_core videodev videobuf2_vmalloc videobuf2_memops uhci_hcd ath9k mac80211 snd_hda_codec_realtek ath9k_common microcode
+ath9k_hw psmouse serio_raw sg ath cfg80211 atl1c lpc_ich mfd_core ehci_hcd snd_hda_intel snd_hda_codec snd_hwdep snd_pcm rtc_cmos
+snd_timer snd evdev eeepc_laptop snd_page_alloc sparse_keymap

Pid: 2866, comm: X Not tainted 3.5.6-rc1-eeepc #1 ASUSTeK Computer INC. 1005HA/1005HA
EIP: 0060:[<c12dc291>] EFLAGS: 00013297 CPU: 0
EIP is at i915_gem_entervt_ioctl+0xf1/0x110
EAX: f5941df4 EBX: f5940000 ECX: 00000000 EDX: 00020000
ESI: f5835400 EDI: 00000000 EBP: f51d7e38 ESP: f51d7e20
 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
CR0: 8005003b CR2: b760e0a0 CR3: 351b6000 CR4: 000007d0
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: ffff0ff0 DR7: 00000400
Process X (pid: 2866, ti=f51d6000 task=f61af8d0 task.ti=f51d6000)
Stack:
 00000001 00000000 f5835414 f51d7e84 f5835400 f54f85c0 f51d7f10 c12b530b
 00000001 c151b139 c14751b6 c152e030 00000b32 00006459 00000059 0000e200
 00000001 00000000 00006459 c159ddd0 c12dc1a0 ffffffea 00000000 00000000
Call Trace:
 [<c12b530b>] drm_ioctl+0x2eb/0x440
 [<c12dc1a0>] ? i915_gem_init+0xe0/0xe0
 [<c1052b2b>] ? enqueue_hrtimer+0x1b/0x50
 [<c1053321>] ? __hrtimer_start_range_ns+0x161/0x330
 [<c10530b3>] ? lock_hrtimer_base+0x23/0x50
 [<c1053163>] ? hrtimer_try_to_cancel+0x33/0x70
 [<c12b5020>] ? drm_version+0x90/0x90
 [<c10ca171>] vfs_ioctl+0x31/0x50
 [<c10ca2e4>] do_vfs_ioctl+0x64/0x510
 [<c10535de>] ? hrtimer_nanosleep+0x8e/0x100
 [<c1052c20>] ? update_rmtp+0x80/0x80
 [<c10ca7c9>] sys_ioctl+0x39/0x60
 [<c1433949>] syscall_call+0x7/0xb
Code: 83 c4 0c 5b 5e 5f 5d c3 c7 44 24 04 2c 05 53 c1 c7 04 24 6f ef 47 c1 e8 6e e0 fd ff c7 83 38 1e 00 00 00 00 00 00 e9 3f ff ff
+ff <0f> 0b eb fe 0f 0b eb fe 8d b4 26 00 00 00 00 0f 0b eb fe 8d b6
EIP: [<c12dc291>] i915_gem_entervt_ioctl+0xf1/0x110 SS:ESP 0068:f51d7e20
---[ end trace dd332ec083cbd513 ]---

The crash happens here in i915_gem_entervt_ioctl() :

    3659          BUG_ON(!list_empty(&dev_priv->mm.active_list));
    3660          BUG_ON(!list_empty(&dev_priv->mm.flushing_list));
 -> 3661          BUG_ON(!list_empty(&dev_priv->mm.inactive_list));
    3662          mutex_unlock(&dev->struct_mutex);

Quoting Chris :
  "That BUG_ON there is silly and can simply be removed. The check is to
   verify that no batches were submitted to the kernel whilst the UMS/GEM
   client was suspended - to which the BUG_ONs are a crude approximation.
   Furthermore, the checks are too late, since it means we attempted to
   program the hardware whilst it was in an invalid state, the BUG_ONs are
   the least of your concerns at that point."

Note that this regression has been introduced in

commit 1b50247a
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Apr 24 15:47:30 2012 +0100

    drm/i915: Remove the list of pinned inactive objects

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NWilly Tarreau <w@1wt.eu>
[danvet: Added note about the regressing commit and cc: stable.]
Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

I can't even find how I figured this might be needed anymore. But sure
enough, the value I'm reading back on platforms doesn't match what the
docs recommends.

It seemed to fix Chris' GT1 in limited testing as well.
Tested-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Now that we correctly generate it, this hack is no longer required (and
might actually paper over a serious bug).

pageflip timestamps are sanity check in the latest version of the flip-test
in intel-gpu-tools.

v2: Also remove the gettimeofday(&now) which is no longer used.
Noticed by Mario Kleiner.

Reviewed-by: mario.kleiner@tuebingen.mpg.de
Tested-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

... since finish_page_flip needs the vblank timestamp generated
in drm_handle_vblank. Somehow all the gmch platforms get it right,
but all the pch platform irq handlers get is wrong. Hooray for copy&
pasting!

Currently this gets papered over by a gross hack in finish_page_flip.
A second patch will remove that.

Note that without this, the new timestamp sanity checks in flip_test
occasionally get tripped up, hence the cc: stable tag.

Cc: stable@vger.kernel.org
Reviewed-by: mario.kleiner@tuebingen.mpg.de
Tested-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Falling into default case in vmi915_gem_fault is a bug. Be more
verbose about it.
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Subsequent threads returning EBUSY from vm_insert_pfn() was not handled
correctly. As a result concurrent access from new threads to
mmapped data caused SIGBUS.

Note that this fixes i-g-t/tests/gem_threaded_tiled_access.
Tested-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In commit cdb0e95b
Author: Keith Packard <keithp@keithp.com>
Date:   Tue Nov 1 20:00:06 2011 -0700

    drm/i915: Try harder during dp pattern 1 link training

extra passes were made to retry the same voltage and then retry a full
clock reset. However, as coverity pointed out, we never tried the full
clock reset as we broke out of the loop early.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We don't have bit 6 swizzling on VLV, so this function is easy.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NAdam Jackson <ajax@redhat.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

If there's no downstream device, DPCD success is good enough.  If
there's a hotplug-capable downstream device, count the number of
connected sinks in DP_SINK_STATUS and return success if it's non-zero.
Otherwise, probe DDC and report appropriately.

v2: Check DP_SINK_STATUS instead of something unrelated to sink status.
Tested-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

v2: Fix parenthesis mismatch, spotted by Jani Nikula
Tested-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
[danvet: Fixup merge conflict and MAX_DOWNSTREAM #define as spotted by
Jani.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Tested-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Acked-by: NDave Airlie <airlied@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This was meant to be the purpose of the
intel_crtc_wait_for_pending_flips() function which is called whilst
preparing the CRTC for a modeset or before disabling. However, as Ville
Syrjala pointed out, we set the pending flip notification on the old
framebuffer that is no longer attached to the CRTC by the time we come
to flush the pending operations. Instead, we can simply wait on the
pending unpin work to be finished on this CRTC, knowning that the
hardware has therefore finished modifying the registers, before proceeding
with our direct access.

Fixes i-g-t/flip_test on non-pch platforms. pch platforms simply
schedule the flip immediately when the pipe is disabled, leading
to other funny issues.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
[danvet: Added i-g-t note and cc: stable]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

A side-effect of commit 7d54a904
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Aug 10 10:18:10 2012 +0100

    drm/i915: Apply post-sync write for pipe control invalidates

was that only a request to emit invalidate flush would result in the
TLB being invalidated (since it requires synchronisation and so incurs a
performance penalty). However, the stated w/a for hardware contexts is
that the TLBs must be invalidated prior to a MI_SET_CONTEXT, yet the w/a
itself did not request the TLBs to be invalidated...

Note this w/a does not prevent the hard system hang I experience when
using hw contexts (with rc6 enabled) on SNB GT1.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

On the EINVAL case we don't release struct_mutex. It should be safe to
grab the lock after checking the parameters, which also resolves the
issues.
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The dithering introduced in

commit 3b5c78a3
Author: Adam Jackson <ajax@redhat.com>
Date:   Tue Dec 13 15:41:00 2011 -0800

    drm/i915/dp: Dither down to 6bpc if it makes the mode fit

stores the INTEL_MODE_DP_FORCE_6BPC flag in the private_flags of the
adjusted mode, while i9xx_crtc_mode_set() and ironlake_crtc_mode_set() use
the original mode, without the flag, so it would never have any
effect. However, the BPC was clamped by VBT settings, making things work by
coincidence, until that part was removed in

commit 4344b813
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Fri Aug 10 11:10:20 2012 +0200

Use adjusted_mode instead of mode when checking for
INTEL_MODE_DP_FORCE_6BPC to make the flag have effect.

v2: Don't forget to fix this in i9xx_crtc_mode_set() also, pointed out by
Daniel both before and after sending the first patch.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47621
CC: Adam Jackson <ajax@redhat.com>
CC: stable@vger.kernel.org
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Finishes commit 02d71956
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Aug 9 16:44:54 2012 +0200

    drm/i915: properly guard ilk ips state

The core functions were annotated with their locking requirements, but
we overlooked that they were exported, without any control over the
locking, to debugfs. So in order to enable debugfs to read the registers
without triggering sanity checks, we change the exported entry points to
properly take the required locks before calling the core routines.
Reported-by: Nyangguang <guang.a.yang@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55304Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

... even if the actual infoframe is smaller than the maximum possible
size.

If we don't write all the 32 DIP data bytes the InfoFrame ECC may not
be correctly calculated in some cases (e.g., when changing the port),
and this will lead to black screens on HDMI monitors. The ECC value is
generated by the hardware.

I don't see how this should break anything since we're writing 0 and
that should be the correct value, so this patch should be safe.

Notice that on IVB and older we actually have 64 bytes available for
VIDEO_DIP_DATA, but only bytes 0-31 actually store infoframe data: the
others are either read-only ECC values or marked as "reserved". On HSW
we only have 32 bytes, and the ECC value is stored on its own separate
read-only register. See BSpec.

This patch fixes bug #46761, which is marked as a regression
introduced by commit 4e89ee17:
    drm/i915: set the DIP port on ibx_write_infoframe

Before commit 4e89 we were just failing to send AVI infoframes when we
needed to change the port, which can lead to black screens in some
cases. After commit 4e89 we started sending infoframes, but with a
possibly wrong ECC value. After this patch I hope we start sending
correct infoframes.

Version 2:
  - Improve commit message
  - Try to make the code more clear

Cc: stable@vger.kernel.org
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=46761Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This should never happen, but the silent "return" makes me wonder
every time I try to debug InfoFrame bugs, so promote this to BUG() to
make sure people will complain if we ever break this.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This fixes the gpio reset problem so the Retina MBP works, but avoids
breaking the Dell systems. Ben will work on a better solution for 3.7.

Tested by me on retina MBP.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Cards typically have 5-7 scratch registers; one of these is reserved for
rdev->rptr_save_reg. Unfortunately the reservation is done in function
r100_cp_init, which is called by all drivers except r600 - and this
function is also invoked on resume from suspend. After several resumes,
no scratch registers are free and graphics acceleration is disabled.

Dmesg then reports either:
   *ERROR* radeon: cp failed to get scratch reg (-22).
   *ERROR* radeon: cp isn't working(-22).
   radeon 0000:01:00.0: failed initializing CP (-22).
or:
   *ERROR* radeon: failed to get scratch reg (-22).
   *ERROR* radeon: failed testing IB on GFX ring (-22).
   *ERROR* ib ring test failed (-22).

The chain of calls on boot for all except r600 is:
radeon_init -> ... -> (rXXX_init) -> rXXX_startup -> r100_cp_init

The chain of calls on resume for all except r600 is:
rXXX_resume -> rXXX_startup -> r100_cp_init.

R600 correctly allocates rptr_save_reg in r600_init (ie once only, not
in resume). However moving the code into the init functions for all
drivers means touching 4 drivers. So instead, this patch just adds a
test in r100_cp_init to avoid reallocating on resume. As the rdev
structure is allocated via kzalloc in radeon_driver_load_kms, and zero
is not a valid registerid, zero safely implies not-yet-allocated.

This issue appears to have been introduced in c7eff978 (3.6.0-rcN)
Signed-off-by: NSimon Kitching <skitching@vonos.net>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Somehow this hunk got dropped from my last patch. We do not have the
rc6_attrs when there is no CONFIG_PM so this causes a compilation error.
Reported-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

As we make the simplification of using a power-of-two size for the
execbuffer handle-to-object TLB, we should validate that this is actually
true and so clarify that premise.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Clear Audio Enable bit to trigger unsolicated event to notify Audio
Driver part the HDMI hot plug change. The patch fixed the bug when
remove HDMI cable the bit was not cleared correctly.

In intel_enable_hdmi(), if intel_hdmi->has_audio been true, the "Audio enable bit" will
be set to trigger unsolicated event to notify Alsa driver the change.

intel_hdmi->has_audio will be reset to false from intel_hdmi_detect() after
remove the hdmi cable, here's debug log:

[  187.494153] [drm:output_poll_execute], [CONNECTOR:17:HDMI-A-1] status updated from 1 to 2
[  187.525349] [drm:intel_hdmi_detect], HDMI: has_audio = 0

so when comes back to intel_disable_hdmi(), the "Audio enable bit" will not be cleared. And this
cause the eld infomation and pin presence doesnot update accordingly in alsa driver side.

This patch will also trigger unsolicated event to alsa driver to notify the hot plug event:

[  187.853159] ALSA sound/pci/hda/patch_hdmi.c:772 HDMI hot plug event: Codec=3 Pin=5 Presence_Detect=0 ELD_Valid=1
[  187.853268] ALSA sound/pci/hda/patch_hdmi.c:990 HDMI status: Codec=3 Pin=5 Presence_Detect=0 ELD_Valid=0
Signed-off-by: NWang Xingchao <xingchao.wang@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>