drm/i915/sdvo: Robustify the dtd<->drm_mode conversions

We've failed to properly clear out the flags when converting a dtd to
a drm mode. For more paranoia just memset the entire structure (and
drop the now redundant clears).

Also since

commit 135c81b8c3c9a70d7b55758c9c2a247a4abb7b64
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun Jul 21 21:37:09 2013 +0200

    drm/i915: clean up crtc timings computation

we don't update the crtc timings any more properly, so do that again.

v2: Remove more redundant clearing, spotted by Ville.

v3: Actually make it compile. Oops.

v4: Use a temporary structure to fill in the mode and copy it over
with drm_mode_copy. This will ensure we don't clobber the mode list or
id. Suggested by Ville.

Cc: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Use the = {}; structure clearing instead of memset as
suggested by Ville.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/sdvo: Fully translate sync flags in the dtd->mode conversion

Instead of just a flag bit for each of the positive/negative sync
modes drm actually uses a separate flag for each ... This upsets the
modeset checker since the adjusted mode filled out at modeset time
doesn't match the one reconstructed at check time (since the
->get_config callback already gets this right).

Reported-by: Knut Petersen <Knut_Petersen@t-online.de>
Cc: Knut Petersen <Knut_Petersen@t-online.de>
References: http://www.gossamer-threads.com/lists/linux/kernel/1778688?do=post_view_threaded
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Use proper print format for debug prints

Replace "%8x" with "%08x".
The hex number should be shown with zero stuffed instead of spaces.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: fix wait_for_pending_flips vs gpu hang deadlock

My g33 here seems to be shockingly good at hitting them all. This time
around kms_flip/flip-vs-panning-vs-hang blows up:

intel_crtc_wait_for_pending_flips correctly checks for gpu hangs and
if a gpu hang is pending aborts the wait for outstanding flips so that
the setcrtc call will succeed and release the crtc mutex. And the gpu
hang handler needs that lock in intel_display_handle_reset to be able
to complete outstanding flips.

The problem is that we can race in two ways:
- Waiters on the dev_priv->pending_flip_queue aren't woken up after
  we've the reset as pending, but before we actually start the reset
  work. This means that the waiter doesn't notice the pending reset
  and hence will keep on hogging the locks.

  Like with dev->struct_mutex and the ring->irq_queue wait queues we
  there need to wake up everyone that potentially holds a lock which
  the reset handler needs.

- intel_display_handle_reset was called _after_ we've already
  signalled the completion of the reset work. Which means a waiter
  could sneak in, grab the lock and never release it (since the
  pageflips won't ever get released).

  Similar to resetting the gem state all the reset work must complete
  before we update the reset counter. Contrary to the gem reset we
  don't need to have a second explicit wake up call since that will
  have happened already when completing the pageflips. We also don't
  have any issues that the completion happens while the reset state is
  still pending - wait_for_pending_flips is only there to ensure we
  display the right frame. After a gpu hang&reset events such
  guarantees are out the window anyway. This is in contrast to the gem
  code where too-early wake-up would result in unnecessary restarting
  of ioctls.

Also, since we've gotten these various deadlocks and ordering
constraints wrong so often throw copious amounts of comments at the
code.

This deadlock regression has been introduced in the commit which added
the pageflip reset logic to the gpu hang work:

commit 96a02917a0131e52efefde49c2784c0421d6c439
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Mon Feb 18 19:08:49 2013 +0200

    drm/i915: Finish page flips and update primary planes after a GPU reset

v2:
- Add comments to explain how the wake_up serves as memory barriers
  for the atomic_t reset counter.
- Improve the comments a bit as suggested by Chris Wilson.
- Extract the wake_up calls before/after the reset into a little
  i915_error_wake_up and unconditionally wake up the
  pending_flip_queue waiters, again as suggested by Chris Wilson.

v3: Throw copious amounts of comments at i915_error_wake_up as
suggested by Chris Wilson.

Cc: stable@vger.kernel.org
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Track pfit enable state separately from size

Detangle the additional state of whether or not the hw has the pfit
enabled from whether it has zero size. This allows us to cleanly
distinguish in the code when we expect the pfit to be enabled (for
Haswell pc8), and when the BIOS is confused and needs sanitizing.

Reported-by: shui yanwei <yangweix.shui@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68251
Tested-by: shui yanwei <yangweix.shui@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Delay disabling of VGA memory until vgacon->fbcon handoff is done

When transitioning away from vgacon the system tries to save the
current contents of the VGA memory, so that it can be cleanly handed
off to fbcon (or whatever comes afterwards).

The recent change

 commit 81b5c7bc8de3e6f63419139c2fc91bf81dea8a7d
 Author: Alex Williamson <alex.williamson@redhat.com>
 Date:   Wed Aug 28 09:39:08 2013 -0600

    i915: Update VGA arbiter support for newer devices

caused i915 to disable VGA memory decode for the IGD when i915 is
initializing. Unfortunately that happens before the vgacon->fbcon
handoff so vgacon_save_screen() will read out all ones from the
VGA memory.

After the handoff fbcon will inherit the bogus state from vgacon,
and pre-fills the fb with matching contents. The end result is
a white rectangle in the top left corner of the screen, the size
of which matches the now inactive VGA console.

To remedy the situation delay the disabling of VGA memory until
the vgacon->fbcon handoff has happened.

Also rename i915_enable_vga to i915_enable_vga_mem to make
the relationship between these functions clearer.

Cc: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: try not to lose backlight CBLV precision

ACPI has _BCM and _BQC methods to set and query the backlight
brightness, respectively. The ACPI opregion has variables BCLP and CBLV
to hold the requested and current backlight brightness, respectively.

The BCLP variable has range 0..255 while the others have range
0..100. This means the _BCM method has to scale the brightness for BCLP,
and the gfx driver has to scale the requested value back for CBLV. If
the _BQC method uses the CBLV variable (apparently some implementations
do, some don't) for current backlight level reporting, there's room for
rounding errors.

Use DIV_ROUND_UP for scaling back to CBLV to get back to the same values
that were passed to _BCM, presuming the _BCM simply uses bclp = (in *
255) / 100 for scaling to BCLP.

Reference: https://gist.github.com/aaronlu/6314920
Reported-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Aaron Lu <aaron.lu@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Confine page flips to BCS on Valleyview

Once again we find that Valleyview is ever so subtlety different from
the rest of its gen7 brethen. In this case, Valleyview has no support
for pageflipping from the RCS ring.

Fixes a regression from

commit ffe74d75502e3a9b0791240b5562bcbecc6ab8dc
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Aug 26 20:58:12 2013 +0100

    drm/i915: Use RCS flips on Ivybridge+

Reported-by: "Lee, Chon Ming" <chon.ming.lee@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68968
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Skip stolen region initialisation if none is reserved

Paulo reported that if he set the amount of reserved memory to 0, then
we emitted a warning about a conflict before disabling our use of stolen
memory. This was introduced with

commit eaba1b8f3379b5d100bd146b9a41d28348bdfd09
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Jul 4 12:28:35 2013 +0100

    drm/i915: Verify that our stolen memory doesn't conflict

and is simply fixed by checking for a no reservation first.

Reported-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: fix gpu hang vs. flip stall deadlocks

Since we've started to clean up pending flips when the gpu hangs in

commit 96a02917a0131e52efefde49c2784c0421d6c439
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Mon Feb 18 19:08:49 2013 +0200

    drm/i915: Finish page flips and update primary planes after a GPU reset

the gpu reset work now also grabs modeset locks. But since work items
on our private work queue are not allowed to do that due to the
flush_workqueue from the pageflip code this results in a neat
deadlock:

INFO: task kms_flip:14676 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kms_flip        D ffff88019283a5c0     0 14676  13344 0x00000004
 ffff88018e62dbf8 0000000000000046 ffff88013bdb12e0 ffff88018e62dfd8
 ffff88018e62dfd8 00000000001d3b00 ffff88019283a5c0 ffff88018ec21000
 ffff88018f693f00 ffff88018eece000 ffff88018e62dd60 ffff88018eece898
Call Trace:
 [<ffffffff8138ee7b>] schedule+0x60/0x62
 [<ffffffffa046c0dd>] intel_crtc_wait_for_pending_flips+0xb2/0x114 [i915]
 [<ffffffff81050ff4>] ? finish_wait+0x60/0x60
 [<ffffffffa0478041>] intel_crtc_set_config+0x7f3/0x81e [i915]
 [<ffffffffa031780a>] drm_mode_set_config_internal+0x4f/0xc6 [drm]
 [<ffffffffa0319cf3>] drm_mode_setcrtc+0x44d/0x4f9 [drm]
 [<ffffffff810e44da>] ? might_fault+0x38/0x86
 [<ffffffffa030d51f>] drm_ioctl+0x2f9/0x447 [drm]
 [<ffffffff8107a722>] ? trace_hardirqs_off+0xd/0xf
 [<ffffffffa03198a6>] ? drm_mode_setplane+0x343/0x343 [drm]
 [<ffffffff8112222f>] ? mntput_no_expire+0x3e/0x13d
 [<ffffffff81117f33>] vfs_ioctl+0x18/0x34
 [<ffffffff81118776>] do_vfs_ioctl+0x396/0x454
 [<ffffffff81396b37>] ? sysret_check+0x1b/0x56
 [<ffffffff81118886>] SyS_ioctl+0x52/0x7d
 [<ffffffff81396b12>] system_call_fastpath+0x16/0x1b
2 locks held by kms_flip/14676:
 #0:  (&dev->mode_config.mutex){+.+.+.}, at: [<ffffffffa0316545>] drm_modeset_lock_all+0x22/0x59 [drm]
 #1:  (&crtc->mutex){+.+.+.}, at: [<ffffffffa031656b>] drm_modeset_lock_all+0x48/0x59 [drm]
INFO: task kworker/u8:4:175 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kworker/u8:4    D ffff88018de9a5c0     0   175      2 0x00000000
Workqueue: i915 i915_error_work_func [i915]
 ffff88018e37dc30 0000000000000046 ffff8801938ab8a0 ffff88018e37dfd8
 ffff88018e37dfd8 00000000001d3b00 ffff88018de9a5c0 ffff88018ec21018
 0000000000000246 ffff88018e37dca0 000000005a865a86 ffff88018de9a5c0
Call Trace:
 [<ffffffff8138ee7b>] schedule+0x60/0x62
 [<ffffffff8138f23d>] schedule_preempt_disabled+0x9/0xb
 [<ffffffff8138d0cd>] mutex_lock_nested+0x205/0x3b1
 [<ffffffffa0477094>] ? intel_display_handle_reset+0x7e/0xbd [i915]
 [<ffffffffa0477094>] ? intel_display_handle_reset+0x7e/0xbd [i915]
 [<ffffffffa0477094>] intel_display_handle_reset+0x7e/0xbd [i915]
 [<ffffffffa044e0a2>] i915_error_work_func+0x128/0x147 [i915]
 [<ffffffff8104a89a>] process_one_work+0x1d4/0x35a
 [<ffffffff8104a821>] ? process_one_work+0x15b/0x35a
 [<ffffffff8104b4a5>] worker_thread+0x144/0x1f0
 [<ffffffff8104b361>] ? rescuer_thread+0x275/0x275
 [<ffffffff8105076d>] kthread+0xac/0xb4
 [<ffffffff81059d30>] ? finish_task_switch+0x3b/0xc0
 [<ffffffff810506c1>] ? __kthread_parkme+0x60/0x60
 [<ffffffff81396a6c>] ret_from_fork+0x7c/0xb0
 [<ffffffff810506c1>] ? __kthread_parkme+0x60/0x60
3 locks held by kworker/u8:4/175:
 #0:  (i915){.+.+.+}, at: [<ffffffff8104a821>] process_one_work+0x15b/0x35a
 #1:  ((&dev_priv->gpu_error.work)){+.+.+.}, at: [<ffffffff8104a821>] process_one_work+0x15b/0x35a
 #2:  (&crtc->mutex){+.+.+.}, at: [<ffffffffa0477094>] intel_display_handle_reset+0x7e/0xbd [i915]

This blew up while running kms_flip/flip-vs-panning-vs-hang-interruptible
on one of my older machines.

Unfortunately (despite the proper lockdep annotations for
flush_workqueue) lockdep still doesn't detect this correctly, so we
need to rely on chance to discover these bugs.

Apply the usual bugfix and schedule the reset work on the system
workqueue to keep our own driver workqueue free of any modeset lock
grabbing.

Note that this is not a terribly serious regression since before the
offending commit we'd simply have stalled userspace forever due to
failing to abort all outstanding pageflips.

v2: Add a comment as requested by Chris.

Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Hold an object reference whilst we shrink it

Whilst running the shrinker, we need to hold a reference as we unbind
the objects, or else we may end up waiting for and retiring requests,
which in turn may result in this object being freed.

This is very similar to the eviction code which also has to be very
careful to keep a reference to its objects as it retires and unbinds
them.

Another similarity, that Ben pointed out, is that as we may call
retire-requests, the unbound_list is outside of our control. We must
only process a single element of that list at a time, that is we can not
rely on the "safe" next pointer being valid after a call to
i915_vma_unbind().

  BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
  IP: [<ffffffffa0082892>] i915_gem_gtt_finish_object+0x68/0xbd [i915]
  PGD 758d3067 PUD ac0d6067 PMD 0
  Oops: 0000 [#1] SMP
  Modules linked in: dm_mod snd_hda_codec_realtek iTCO_wdt iTCO_vendor_support pcspkr snd_hda_intel i2c_i801 snd_hda_codec snd_hwdep snd_pcm snd_page_alloc snd_timer snd lpc_ich mfd_core soundcore battery ac option usb_wwan usbserial uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev i915 video button drm_kms_helper drm acpi_cpufreq mperf freq_table
  CPU: 1 PID: 16835 Comm: fbo-maxsize Not tainted 3.11.0-rc7_nightlytop_8fdad4_20130902_+ #7977
  task: ffff8800712106d0 ti: ffff880028e4a000 task.ti: ffff880028e4a000
  RIP: 0010:[<ffffffffa0082892>]  [<ffffffffa0082892>] i915_gem_gtt_finish_object+0x68/0xbd [i915]
  RSP: 0018:ffff880028e4b9e8  EFLAGS: 00010246
  RAX: 0000000000000000 RBX: ffff880145734000 RCX: ffff880145735328
  RDX: ffff8801457353fc RSI: 0000000000000000 RDI: ffff88007597cc00
  RBP: ffff88007597cc00 R08: 0000000000000001 R09: ffff88014f257f00
  R10: ffffea0001d65f00 R11: 0000000000bba60b R12: ffff880149e5b000
  R13: ffff880145734001 R14: ffff88007597ccc8 R15: ffff88007597cc00
  FS:  00007ff5bc919740(0000) GS:ffff88014f240000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 0000000000000008 CR3: 0000000028f4c000 CR4: 00000000001407e0
  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
  Stack:
   0000000000000000 ffff88007597cc00 ffff8801440d6840 0000000000000000
   ffff880145734000 ffffffffa007c854 0000000000000010 ffff88007597c900
   0000000000018000 00000000004a1201 ffff88007597cc60 ffffffffa007d183
  Call Trace:
   [<ffffffffa007c854>] ? i915_vma_unbind+0xe2/0x1d1 [i915]
   [<ffffffffa007d183>] ? __i915_gem_shrink+0xf1/0x162 [i915]
   [<ffffffffa007d2ee>] ? i915_gem_object_get_pages_gtt+0xfa/0x303 [i915]
   [<ffffffffa00795f4>] ? i915_gem_object_get_pages+0x54/0x89 [i915]
   [<ffffffffa007cbda>] ? i915_gem_object_pin+0x238/0x5ce [i915]
   [<ffffffff812cba5f>] ? __sg_page_iter_next+0x2b/0x58
   [<ffffffffa0082056>] ? gen6_ppgtt_insert_entries+0xf2/0x114 [i915]
   [<ffffffffa007fe4b>] ? i915_gem_execbuffer_reserve_vma.isra.13+0x79/0x18d [i915]
   [<ffffffffa008017c>] ? i915_gem_execbuffer_reserve+0x21d/0x347 [i915]
   [<ffffffffa0080bfb>] ? i915_gem_do_execbuffer.isra.17+0x4f3/0xe61 [i915]
   [<ffffffffa00795f4>] ? i915_gem_object_get_pages+0x54/0x89 [i915]
   [<ffffffffa007e405>] ? i915_gem_pwrite_ioctl+0x743/0x7a5 [i915]
   [<ffffffffa0081a46>] ? i915_gem_execbuffer2+0x15e/0x1e4 [i915]
   [<ffffffffa000e20d>] ? drm_ioctl+0x2a5/0x3c4 [drm]
   [<ffffffffa00818e8>] ? i915_gem_execbuffer+0x37f/0x37f [i915]
   [<ffffffff816f64c0>] ? __do_page_fault+0x3ab/0x449
   [<ffffffff810be3da>] ? do_mmap_pgoff+0x2b2/0x341
   [<ffffffff810e49be>] ? vfs_ioctl+0x1e/0x31
   [<ffffffff810e5194>] ? do_vfs_ioctl+0x3ad/0x3ef
   [<ffffffff810e5224>] ? SyS_ioctl+0x4e/0x7e
   [<ffffffff816f88d2>] ? system_call_fastpath+0x16/0x1b
  Code: 52 0c a0 48 c7 c6 22 30 0d a0 31 c0 e8 ef 00 f9 ff bf c6 a7 00 00 e8 90 5d 24 e1 f6 85 13 01 00 00 10 75 44 48 8b 85 18 01 00 00 <8b> 50 08 48 8b 30 49 8b 84 24 88 02 00 00 48 89 c7 48 81 c7 98
  RIP  [<ffffffffa0082892>] i915_gem_gtt_finish_object+0x68/0xbd [i915]
  RSP <ffff880028e4b9e8>
  CR2: 0000000000000008

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68171
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
[danvet: Bikeshed the comments a bit as discussed with Chris.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: fix i9xx_crtc_clock_get for multiplied pixels

The dpll actually runs at the port clock so we don't need
to multiply it again with the pixel multiplier to get the
adjusted_mode.clock. This is in contrast to the ironlake
pixel clock readout code which uses the fdi dotclock: That
one does _not_ run with multiplied pixels.

This issue goes back to the original clock readout code added
in

commit f1f644dc66cbaf5a4c7dcde683361536b41885b9
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Thu Jun 27 00:39:25 2013 +0300

    drm/i915: get mode clock when reading the pipe config v9

Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: handle sdvo input pixel multiplier correctly again

The sdvo input timing needs to be the actual mode, the sdvo
encoder automatically adjusts for the need of pixel doubling or
quadrupling. This was lost in pipe config conversion of the
pixel multiplier in

commit 6cc5f341b5830541a1b6945435ca90c69b1b8b21
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Mar 27 00:44:53 2013 +0100

    drm/i915: add pipe_config->pixel_multiplier

While at it ditch the intel_ prefix from the crtc in
intel_sdvo_mode_set.

Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: fix hpd work vs. flush_work in the pageflip code deadlock

Historically we've run our own driver hotplug handling in our own
work-queue, which then launched the drm core hotplug handling in the
system workqueue. This is important since we flush our own driver
workqueue in the pageflip code while hodling modeset locks, and only
the drm hotplug code grabbed these locks. But with

commit 69787f7da6b2adc4054357a661aaa1701a9ca76f
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Tue Oct 23 18:23:34 2012 +0000

    drm: run the hpd irq event code directly

this was changed and now we could deadlock in our flip handler if
there's a hotplug work blocking the progress of the crucial unpin
works. So this broke the careful deadlock avoidance implemented in

commit b4a98e57fc27854b5938fc8b08b68e5e68b91e1f
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Nov 1 09:26:26 2012 +0000

    drm/i915: Flush outstanding unpin tasks before pageflipping

Since the rule thus far has been that work items on our own workqueue
may never grab modeset locks simply restore that rule again.

v2: Add a comment to the declaration of dev_priv->wq to warn readers
about the tricky implications of using it. Suggested by Chris Wilson.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Stuart Abercrombie <sabercrombie@chromium.org>
Reported-by: Stuart Abercrombie <sabercrombie@chromium.org>
References: http://permalink.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/26239
Cc: stable@vger.kernel.org
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Squash in a comment at the place where we schedule the work.
Requested after-the-fact by Chris on irc since the hpd work isn't the
only place we botch this.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: fix up the relocate_entry refactoring

Somehow we've lost the error handling in the patch split-up between
the internal and external patch. This regression has been introduced
in

commit 5032d871f7d300aee10c309ea004eb4f851553fe
Author: Rafael Barbalho <rafael.barbalho@intel.com>
Date:   Wed Aug 21 17:10:51 2013 +0100

    drm/i915: Cleaning up the relocate entry function

This bug is exercised by igt/gem_reloc_vs_gpu/interruptible.

Cc: Rafael Barbalho <rafael.barbalho@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Fix pipe config warnings when dealing with LVDS fixed mode

intel_fixed_panel_mode() overwrote the adjusted_mode with the fixed mode
only partially. Notably it forgot to copy over the sync flags. The LVDS code however programmed the hardware with the sync flags from fixed mode, and then later the pipe config comparison obviously failed as we
filled out the adjusted_mode in get_config from the real registers.

Just call drm_mode_copy() in intel_fixed_panel_mode() to copy over the
whole thing, and then just use adjusted_mode in the LVDS code to figure
out which sync settings the hardware needs.

Also constify the fixed_mode argument to intel_fixed_panel_mode().

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Don't call sg_free_table() if sg_alloc_table() fails

One needs to call __sg_free_table() if __sg_alloc_table() fails, but
sg_alloc_table() does that for us already.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewd-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

i915: Update VGA arbiter support for newer devices

This is intended to add VGA arbiter support for Intel HD graphics on
Core processors.  The old GMCH registers no longer exist, so even
though it appears that i915 participates in VGA arbitration, it doesn't
work.  On Intel HD graphics we already attempt to disable VGA regions
of the device.  This makes registering as a VGA client unnecessary since
we don't intend to operate differently depending on how many VGA devices
are present.  We can disable VGA memory regions by clearing the memory
enable bit in the VGA MSR.  That only leaves VGA IO, which we update
the VGA arbiter to know that we don't participate in VGA memory
arbitration.  We also add a hook on unload to re-enable memory and
reinstate VGA memory arbitration.

v3: Use explicit LEGACY_IO | LEGACY_MEM when restoring rather than
    LEGACY_MASK, per Ville's comments.

v2: I915_READ/WRITE accessors don't work in i915_disable_vga, use inb/outb
    directly.  Also, on the driver unbind VGA enable path, acquire legacy
    IO to re-enable VGA memory.  Correct comment.

Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Add patch changelog. Also squash in a fixup to have a dummy
static inline for vga_set_legacy_decoding for CONFIG_VGA_ARB=n as
reported by the 0-day kernel build bot.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
fixup 2

vgaarb: Fix VGA decodes changes

When VGA decodes change we need to do a bit more evaluation of exactly what
has changed.  We don't necessarily give up all the old owns resources and
we need to account for resources with locks.  The new algorithm is: If
something is added, update decodes.  If legacy resources were added and
none were there before, we have a new participant.  If something is
removed, update decodes.  If we previously owned it, we no longer own it.
If it was previously locked, invalidate all locks and release it.  If
legacy resources were removed and none are left, remove the participant
from VGA arbitration.

Previously we updated decodes, released ownership of everything that was
previously decoded, ignored all locks, and went off looking for another
device to transfer VGA to.  In a test case where Intel IGD removes only
legacy VGA memory decoding, this left the arbiter switching to discrete
graphics without actually disabling legacy VGA IO from the IGD.  As a
bonus, we bumped up the count of VGA arbitration participants for no
good reason.

Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Cc: Dave Airlie <airlied@redhat.com>
Acked-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Kill now unused variables, reported by the 0-day kernel
builtbot.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

vgaarb: Don't disable resources that are not owned

If a device does not own a resource then we don't need to disable it.
This resolves the case where an Intel IGD device can be configured to
disable decode of VGA memory but we still need the arbiter to handle
VGA I/O port routing.  When the IGD device is in conflict, only
PCI_COMMAND_IO should be disabled since VGA memory does not require
arbitration on this device.

Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Cc: Dave Airlie <airlied@redhat.com>
Acked-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Pin pages whilst mapping the dma-buf

As we attempt to kmalloc after calling get_pages, there is a possibility
that the shrinker may reap the pages we just acquired. To prevent this
we need to increment the pages_pin_count early, so rearrange the code
and error paths to make it so.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: enable trickle feed on Haswell

We shouldn't disable the trickle feed bits on Haswell. Our
documentation explicitly says the trickle feed bits of PRI_CTL and
CUR_CTL should not be programmed to 1, and the hardware engineer also
asked us to not program the SPR_CTL field to 1. Leaving the bits as 1
could cause underflows.

Reported-by: Arthur Runyan <arthur.j.runyan@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

x86: add early quirk for reserving Intel graphics stolen memory v5

Systems with Intel graphics controllers set aside memory exclusively for
gfx driver use.  This memory is not always marked in the E820 as
reserved or as RAM, and so is subject to overlap from E820 manipulation
later in the boot process.  On some systems, MMIO space is allocated on
top, despite the efforts of the "RAM buffer" approach, which simply
rounds memory boundaries up to 64M to try to catch space that may decode
as RAM and so is not suitable for MMIO.

v2: use read_pci_config for 32 bit reads instead of adding a new one
    (Chris)
    add gen6 stolen size function (Chris)
v3: use a function pointer (Chris)
    drop gen2 bits (Daniel)
v4: call e820_sanitize_map after adding the region
v5: fixup comments (Peter)
    simplify loop (Chris)

Acked-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: H. Peter Anvin <hpa@zytor.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66726
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66844
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: split PCI IDs out into i915_drm.h v4

For use by userspace (at some point in the future) and other kernel code.

v2: move PCI IDs to uabi (Chris)
    move PCI IDs to drm/ (Dave)
v3: fixup Quanta detection - needs to come first (Daniel)
v4: fix up PCI match structure init for easier use by userspace (Chris)

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

i915_gem: Convert kmem_cache_alloc(...GFP_ZERO) to kmem_cache_zalloc

The helper exists, might as well use it instead of __GFP_ZERO.

Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Use RCS flips on Ivybridge+

RCS flips do work on Iybridge+ so long as we can unmask the messages
through DERRMR. However, there are quite a few workarounds mentioned
regarding unmasking more than one event or triggering more than one
message through DERRMR. Those workarounds in principle prevent us from
performing pipelined flips (and asynchronous flips across multiple
planes) and equally apply to the "known good" BCS ring. Given that it
already appears to work, and also appears to work with unmasking all 3
planes at once (and queuing flips across multiple planes), be brave.

Bugzlla: https://bugs.freedesktop.org/show_bug.cgi?id=67600
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Lightly-tested-by: Stephane Marchesin <marchesin@icps.u-strasbg.fr>
Cc: Stephane Marchesin <marchesin@icps.u-strasbg.fr>
Cc: Ben Widawsky <ben@bwidawsk.net>
Tested-by: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Embed the ring->private within the struct intel_ring_buffer

We now have more devices using ring->private than not, and they all want
the same structure. Worse, I would like to use a scratch page from
outside of intel_ringbuffer.c and so for convenience would like to reuse
ring->private. Embed the object into the struct intel_ringbuffer so that
we can keep the code clean.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: fix lvds/dp panel fitter setting

If need to enable the panel fitter, the crtc timings have to be
programmed according to the panel's native (fixed) mode. This isn't the
case atm, since after the encoder changes adjusted_mode to fixed
mode the crtc_* timing fields of adjusted_mode will stay at their original
non-native values that the user passed in. This results in a corrupted
output.

One exception is when we have a second pass of computing encoder configs
due to bandwidth limitation, since then we'll set adjusted_mode.crtc_*
fields to the fixed mode values set in the first pass; so in this case
things will work out.

Fix this by updating the adjusted_mode.crtc_* fields when we set the
fixed panel mode.

This regression has been introduced in

commit 135c81b8c3c9a70d7b55758c9c2a247a4abb7b64
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun Jul 21 21:37:09 2013 +0200

    drm/i915: clean up crtc timings computation

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: tune down hangcheck noise

We already have a big splashing *ERROR* for all the relevant cases of
hangs, so this one here is redudant. And it results in an unclean
dmesg when running with simulated hangs. Regression has been
introduced in

commit 05407ff889ceebe383aa5907219f86582ef96b72
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date:   Thu May 30 09:04:29 2013 +0300

    drm/i915: detect hang using per ring hangcheck_score

Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68641
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Report requested frequency alongside current frequency in debugfs

It can be useful to compare at times the current vs requested frequency
of the GPU, so provide the contents of RPNSWREQ alonside CAGF.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Apply the force-detect VGA w/a to Valleyview

It appears that Valleyview shares its VGA encoder with more recent
siblings and requires the same forced detection cycle after a hardware
reset before we can rely on hotplugging.

Reported-and-tested-by: kobeqin <kobe.qin@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67733
Tested-by: kobeqin <kobe.qin@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Check for gen >= 5 insted, acked by Chris.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Adjust available RPS information through sysfs for vlv

Valleyview has its own render power state implementation with different
capability knobs - it has no RP0,RP1,RPn but rather RPe.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67734
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: kobe.qin@intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: sanitize forcewake registers on reset

In reset we try to restore the forcewake state to
pre reset state, using forcewake_count. The reset
doesn't seem to clear the forcewake bits so we
get warn on forcewake ack register not clearing.

Use same mechanism as intel_uncore_sanitize() does
when loading driver to reset the forcewake bits, right
after the chip has been reset.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Don't mask EI UP interrupt on IVB|SNB

Submitting a batchbuffer which simulates a gpu
hang by doing MI_BATCH_BUFFER_START into itself,
to test hangcheck, started to hard hang the whole box
(IVB). Bisecting lead to this commit:

commit 664b422c2966cd39b8f67e8d53a566ea8c877cd6
Author: Vinit Azad <vinit.azad@intel.com>
Date:   Wed Aug 14 13:34:33 2013 -0700

    drm/i915: Only unmask required PM interrupts

Experimenting with the mask register showed that
unmasking EI UP will prevent the hard hang in IVB and SNB.
HSW doesn't hang with EI UP masked.

Considering we are just disabling interrupts that aren't even
delivered to driver, this change is more likely to paper over some
weirdness in gpu's internal state machine. But until better
explanation can be found, let's trade little bit of power
for stability on these architectures.

v2: - Unmask EI_EXPIRED directly in I915_WRITE (Vinit)
v3: - Only unmask on SNB and IVB

Cc: Vinit Azad <vinit.azad@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Acked-by: Vinit Azad <vinit.azad@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/radeon: support render nodes

Enable support for drm render nodes for radeon by flagging the ioctls that
are safe and just needed for rendering.

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/nouveau: Support render nodes

Enable support for drm render nodes for nouveau by flagging the ioctls that
are safe and just needed for rendering.

Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Martin Peres <martin.peres@labri.fr>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/i915: Support render nodes

Enable support for drm render nodes for i915 by flagging the ioctls that
are safe and just needed for rendering.

v2: mark reg_read, set_caching and get_caching (ickle, danvet)

Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: fix DRM_IOCTL_MODE_GETFB handle-leak

DRM_IOCTL_MODE_GETFB is used to retrieve information about a given
framebuffer ID. It is a read-only helper and was thus declassified for
unprivileged access in:

  commit a14b1b42477c5ef089fcda88cbaae50d979eb8f9
  Author: Mandeep Singh Baines <mandeep.baines@gmail.com>
  Date:   Fri Jan 20 12:11:16 2012 -0800

      drm: remove master fd restriction on mode setting getters

However, alongside width, height and stride information,
DRM_IOCTL_MODE_GETFB also passes back a handle to the underlying buffer of
the framebuffer. This handle allows users to mmap() it and read or write
into it. Obviously, this should be restricted to DRM-Master.

With the current setup, *any* process with access to /dev/dri/card0 (which
means any process with access to hardware-accelerated rendering) can
access the current screen framebuffer and modify it ad libitum.

For backwards-compatibility reasons we want to keep the
DRM_IOCTL_MODE_GETFB call unprivileged. Besides, it provides quite useful
information regarding screen setup. So we simply test whether the caller
is the current DRM-Master and if not, we return 0 as handle, which is
always invalid. A following DRM_IOCTL_GEM_CLOSE on this handle will fail
with EINVAL, but we accept this. Users shouldn't test for errors during
GEM_CLOSE, anyway. And it is still better as a failing MODE_GETFB call.

v2: add capable(CAP_SYS_ADMIN) check for compatibility with i-g-t

Cc: <stable@vger.kernel.org>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/msm: convert to drm_bridge

Drop the msm_connector base class, and special calls to base class
methods from the encoder, and use instead drm_bridge.  This allows for a
cleaner division between the hdmi (and in future dsi) blocks, from the
mdp block.

Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: Add drm_bridge

This patch adds the notion of a drm_bridge. A bridge is a chained
device which hangs off an encoder. The drm driver using the bridge
should provide the association between encoder and bridge. Once a
bridge is associated with an encoder, it will participate in mode
set, and dpms (via the enable/disable hooks).

Signed-off-by: Sean Paul <seanpaul@chromium.org>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/nouveau: fix up 32-bit ioctls and device wake up.

Noticed by kbuild test robot.

Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/tegra: fix up page flip flags.

This was one level away from where I'd grepped.

Signed-off-by: Dave Airlie <airlied@redhat.com>

Merge branch 'drm-next-3.12' of git://people.freedesktop.org/~agd5f/linux into drm-next

Alex writes:
This is the radeon drm-next request.  Big changes include:
- support for dpm on CIK parts
- support for ASPM on CIK parts
- support for berlin GPUs
- major ring handling cleanup
- remove the old 3D blit code for bo moves in favor of CP DMA or sDMA
- lots of bug fixes

[airlied: fix up a bunch of conflicts from drm_order removal]

* 'drm-next-3.12' of git://people.freedesktop.org/~agd5f/linux: (898 commits)
  drm/radeon/dpm: make sure dc performance level limits are valid (CI)
  drm/radeon/dpm: make sure dc performance level limits are valid (BTC-SI) (v2)
  drm/radeon: gcc fixes for extended dpm tables
  drm/radeon: gcc fixes for kb/kv dpm
  drm/radeon: gcc fixes for ci dpm
  drm/radeon: gcc fixes for si dpm
  drm/radeon: gcc fixes for ni dpm
  drm/radeon: gcc fixes for trinity dpm
  drm/radeon: gcc fixes for sumo dpm
  drm/radeonn: gcc fixes for rv7xx/eg/btc dpm
  drm/radeon: gcc fixes for rv6xx dpm
  drm/radeon: gcc fixes for radeon_atombios.c
  drm/radeon: enable UVD interrupts on CIK
  drm/radeon: fix init ordering for r600+
  drm/radeon/dpm: only need to reprogram uvd if uvd pg is enabled
  drm/radeon: check the return value of uvd_v1_0_start in uvd_v1_0_init
  drm/radeon: split out radeon_uvd_resume from uvd_v4_2_resume
  radeon kms: fix uninitialised hotplug work usage in r100_irq_process()
  drm/radeon/audio: set up the sads on DCE3.2 asics
  drm/radeon: fix handling of variable sized arrays for router objects
  ...

Conflicts:
drivers/gpu/drm/i915/i915_dma.c
drivers/gpu/drm/i915/i915_gem_dmabuf.c
drivers/gpu/drm/i915/intel_pm.c
drivers/gpu/drm/radeon/cik.c
drivers/gpu/drm/radeon/ni.c
drivers/gpu/drm/radeon/r600.c

drm/radeon/dpm: make sure dc performance level limits are valid (CI)

Check to make sure the dc limits are valid before using them.
Some systems may not have a dc limits table.  In that case just
use the ac limits.  This fixes hangs on systems when the power
state is changed when on battery (dc) due to invalid performance
state parameters.

Should fix:
https://bugs.freedesktop.org/show_bug.cgi?id=68708

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon/dpm: make sure dc performance level limits are valid (BTC-SI) (v2)

Check to make sure the dc limits are valid before using them.
Some systems may not have a dc limits table.  In that case just
use the ac limits.  This fixes hangs on systems when the power
state is changed when on battery (dc) due to invalid performance
state parameters.

Should fix:
https://bugs.freedesktop.org/show_bug.cgi?id=68708

v2: fix up limits in dpm_init()

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

drm/radeon: gcc fixes for extended dpm tables

Newer versions of gcc seem to wander off into the
weeds when dealing with variable sizes arrays in
structs.  Rather than indexing the arrays, use
pointer arithmetic.

See bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=66932
https://bugs.freedesktop.org/show_bug.cgi?id=66972
https://bugs.freedesktop.org/show_bug.cgi?id=66945

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: gcc fixes for kb/kv dpm

Newer versions of gcc seem to wander off into the
weeds when dealing with variable sizes arrays in
structs.  Rather than indexing the arrays, use
pointer arithmetic.

See bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=66932
https://bugs.freedesktop.org/show_bug.cgi?id=66972
https://bugs.freedesktop.org/show_bug.cgi?id=66945

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: gcc fixes for ci dpm

Newer versions of gcc seem to wander off into the
weeds when dealing with variable sizes arrays in
structs.  Rather than indexing the arrays, use
pointer arithmetic.

See bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=66932
https://bugs.freedesktop.org/show_bug.cgi?id=66972
https://bugs.freedesktop.org/show_bug.cgi?id=66945

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: gcc fixes for si dpm

Newer versions of gcc seem to wander off into the
weeds when dealing with variable sizes arrays in
structs.  Rather than indexing the arrays, use
pointer arithmetic.

See bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=66932
https://bugs.freedesktop.org/show_bug.cgi?id=66972
https://bugs.freedesktop.org/show_bug.cgi?id=66945

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: gcc fixes for ni dpm

Newer versions of gcc seem to wander off into the
weeds when dealing with variable sizes arrays in
structs.  Rather than indexing the arrays, use
pointer arithmetic.

See bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=66932
https://bugs.freedesktop.org/show_bug.cgi?id=66972
https://bugs.freedesktop.org/show_bug.cgi?id=66945

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: gcc fixes for trinity dpm

Newer versions of gcc seem to wander off into the
weeds when dealing with variable sizes arrays in
structs.  Rather than indexing the arrays, use
pointer arithmetic.

See bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=66932
https://bugs.freedesktop.org/show_bug.cgi?id=66972
https://bugs.freedesktop.org/show_bug.cgi?id=66945

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: gcc fixes for sumo dpm

Newer versions of gcc seem to wander off into the
weeds when dealing with variable sizes arrays in
structs.  Rather than indexing the arrays, use
pointer arithmetic.

See bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=66932
https://bugs.freedesktop.org/show_bug.cgi?id=66972
https://bugs.freedesktop.org/show_bug.cgi?id=66945

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeonn: gcc fixes for rv7xx/eg/btc dpm

Newer versions of gcc seem to wander off into the
weeds when dealing with variable sizes arrays in
structs.  Rather than indexing the arrays, use
pointer arithmetic.

See bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=66932
https://bugs.freedesktop.org/show_bug.cgi?id=66972
https://bugs.freedesktop.org/show_bug.cgi?id=66945

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: gcc fixes for rv6xx dpm

Newer versions of gcc seem to wander off into the
weeds when dealing with variable sizes arrays in
structs.  Rather than indexing the arrays, use
pointer arithmetic.

See bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=66932
https://bugs.freedesktop.org/show_bug.cgi?id=66972
https://bugs.freedesktop.org/show_bug.cgi?id=66945

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: gcc fixes for radeon_atombios.c

Newer versions of gcc seem to wander off into the
weeds when dealing with variable sizes arrays in
structs.  Rather than indexing the arrays, use
pointer arithmetic.

See bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=66932
https://bugs.freedesktop.org/show_bug.cgi?id=66972
https://bugs.freedesktop.org/show_bug.cgi?id=66945

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: enable UVD interrupts on CIK

The same as on evergreen.

Signed-off-by: Christian König <christian.koenig@amd.com>
Reported-by: FrankR Huang <FrankR.Huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

drm/radeon: fix init ordering for r600+

The vram scratch buffer needs to be initialized
before the mc is programmed otherwise we program
0 as the GPU address of the default GPU fault
page.  In most cases we put vram at zero anyway and
reserve a page for the legacy vga buffer so in practice
this shouldn't cause any problems, but better to make
it correct.

Was changed in:
6fab3febf6d949b0a12b1e4e73db38e4a177a79e

Reported-by: FrankR Huang <FrankR.Huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

drm/radeon/dpm: only need to reprogram uvd if uvd pg is enabled

Avoid needless uvd reprogramming if uvd powergating is disabled.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>

drm/radeon: check the return value of uvd_v1_0_start in uvd_v1_0_init

No need to try the ring tests if starting the UVD block failed.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>

drm/radeon: split out radeon_uvd_resume from uvd_v4_2_resume

For powergating, we just need to re-init the registers, there
is no need to restore the uvd BOs.  This just adds needless
work when powergating uvd for playback while the system is
on.  We only need to restore the uvd BOs on an actual resume
from suspend or when the driver loads.

This fixes multi-stream UVD playback on KB systems.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>

radeon kms: fix uninitialised hotplug work usage in r100_irq_process()

Commit a01c34f72e7cd2624570818f579b5ab464f93de2 (radeon kms: do not
flush uninitialized hotplug work) moved work initialisation phase to
the last step of radeon_irq_kms_init(). Meelis Roos reported that this
causes problems on his machine because drm_irq_install() uses hotplug
work on r100.

hotplug work flushed in radeon_irq_kms_fini(), with two possible cases:
-- radeon_irq_kms_fini() call after successful radeon_irq_kms_init()
-- radeon_irq_kms_fini() call after unsuccessful (or not called at all)
   radeon_irq_kms_init()

The latter one causes flush work on uninitialised hotplug work. Move
work initialisation before drm_irq_install(), but keep existing agreement
to flush hotplug work in radeon_irq_kms_fini() only for `irq.installed'
(successful radeon_irq_kms_init()) case.

WARNING: CPU: 0 PID: 243 at kernel/workqueue.c:1378 __queue_work+0x132/0x16d()
Call Trace:
[<c12319b3>] ? dump_stack+0xa/0x13
[<c1022600>] ? warn_slowpath_common+0x75/0x8a
[<c1031010>] ? __queue_work+0x132/0x16d
[<c1031010>] ? __queue_work+0x132/0x16d
[<c102269e>] ? warn_slowpath_null+0x1b/0x1f
[<c1031010>] ? __queue_work+0x132/0x16d
[<c103107b>] ? queue_work_on+0x30/0x40
[<f8aed3f3>] ? r100_irq_process+0x16d/0x1e6 [radeon]
[<f8ae77cf>] ? radeon_driver_irq_preinstall_kms+0xc2/0xc5 [radeon]
[<f8974d77>] ? drm_irq_install+0xb2/0x1ac [drm]
[<f897604d>] ? drm_vblank_init+0x196/0x1d2 [drm]
[<f8ae78d3>] ? radeon_irq_kms_init+0x33/0xc6 [radeon]
[<f8aef35a>] ? r100_startup+0x1a3/0x1d6 [radeon]
[<f8ad77c8>] ? radeon_ttm_init+0x26e/0x287 [radeon]
[<f8aef752>] ? r100_init+0x2b3/0x309 [radeon]
[<c118082e>] ? vga_client_register+0x39/0x40
[<f8ac535f>] ? radeon_device_init+0x54b/0x61b [radeon]
[<f8ac40fd>] ? cail_mc_write+0x13/0x13 [radeon]
[<f8ac6864>] ? radeon_driver_load_kms+0x82/0xda [radeon]
[<f8978bbd>] ? drm_get_pci_dev+0x136/0x22d [drm]
[<f8ac409b>] ? radeon_pci_probe+0x6c/0x86 [radeon]
[<c112acf6>] ? pci_device_probe+0x4c/0x83
[<c11846c7>] ? driver_probe_device+0x80/0x184
[<c112a848>] ? pci_match_id+0x18/0x36
[<c1184837>] ? __driver_attach+0x44/0x5f
[<c11833f4>] ? bus_for_each_dev+0x50/0x5a
[<c118433e>] ? driver_attach+0x14/0x16
[<c11847f3>] ? __device_attach+0x28/0x28
[<c1184045>] ? bus_add_driver+0xd6/0x1bf
[<c1184c22>] ? driver_register+0x78/0xcf
[<f8ba8000>] ? 0xf8ba7fff
[<c10003bf>] ? do_one_initcall+0x8b/0x121
[<c101e668>] ? change_page_attr_clear+0x2e/0x33
[<f8ba8000>] ? 0xf8ba7fff
[<c101e689>] ? set_memory_ro+0x1c/0x20
[<c104de94>] ? set_page_attributes+0x11/0x12
[<c104f6e1>] ? load_module+0x12fa/0x17e8
[<c107483b>] ? map_vm_area+0x22/0x31
[<c104fc36>] ? SyS_init_module+0x67/0x7d
[<c1234245>] ? sysenter_do_call+0x12/0x26

Reported-by: Meelis Roos <mroos@linux.ee>
Tested-by: Meelis Roos <mroos@linux.ee>
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

drm/radeon/audio: set up the sads on DCE3.2 asics

This sets up the short audio descriptors properly on
DCE3.2 asics for hdmi audio.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: fix handling of variable sized arrays for router objects

The table has the following format:

typedef struct _ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT         //usSrcDstTableOffset pointing to this structure
{
  UCHAR               ucNumberOfSrc;
  USHORT              usSrcObjectID[1];
  UCHAR               ucNumberOfDst;
  USHORT              usDstObjectID[1];
}ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT;

usSrcObjectID[] and usDstObjectID[] are variably sized, so we
can't access them directly.  Use pointers and update the offset
appropriately when accessing the Dst members.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

drm/radeon: fix resume on some rs4xx boards (v2)

Setting MC_MISC_CNTL.GART_INDEX_REG_EN causes hangs on
some boards on resume.  The systems seem to work fine
without touching this bit so leave it as is.

v2: read-modify-write the GART_INDEX_REG_EN bit.
I suspect the problem is that we are losing the other
settings in the register.

fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=52952

Reported-by: Ondrej Zary <linux@rainbow-software.org>
Tested-by: Daniel Tobias <dan.g.tob@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

drm/radeon: add berlin pci ids

This adds the pci ids for the berlin GPU core.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

drm/radeon: fill in gpu_init for berlin GPU cores

This fills in the GPU specific details for berlin
GPU cores so that the driver will work with them.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

drm/radeon/dpm: ungate blocks in dpm disable for kb/kv

These blocks need to be ungated for the other parts of
the driver properly initialize them (e.g., after a gpu
reset, etc.).

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon/dpm: track uvd gated state for ci

Track the current uvd gated state on CI to avoid unnecessary
state changes when uvd is active.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: enable uvd dpm on CI

UVD dpm dynamically adjusts the uvd clocks on
demand.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: disable the GRPH block when we disable the crtc

Since we aren't using it when the crtc is disabled, turn it off
to save power.  The GRPH block is the part of the display
controller that controls the primary graphics plane (size,
address, etc.).

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: atombios hw i2c fixes

These fixes make writes work properly.  Previously
only reads worked.  Note that this feature is off
by default.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: fix LCD record parsing

If the LCD table contains an EDID record, properly account
for the edid size when walking through the records.

This should fix error messages about unknown LCD records.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

drm/radeon: check firmware overrides for mclk/sclk ss

Check the overrides in the firmware info table before
enabling spread spectrum on the engine or memory clocks.

Some boards may have valid spread spectrum tables, but
shouldn't necessarily have it enabled.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: update line buffer allocation for dce8

We need to allocate line buffer to each display when
setting up the watermarks.  Failure to do so can lead
to a blank screen.  This fixes blank screen problems
on dce8 asics.

Based on an initial fix from:
Jay Cornwall <jay.cornwall@amd.com>

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

drm/radeon: update line buffer allocation for dce6

We need to allocate line buffer to each display when
setting up the watermarks.  Failure to do so can lead
to a blank screen.  This fixes blank screen problems
on dce6 asics.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=64850

Based on an initial fix from:
Jay Cornwall <jay.cornwall@amd.com>

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

drm/radeon: update line buffer allocation for dce4.1/5

We need to allocate line buffer to each display when
setting up the watermarks.  Failure to do so can lead
to a blank screen.  This fixes blank screen problems
on dce4.1/5 asics.

Based on an initial fix from:
Jay Cornwall <jay.cornwall@amd.com>

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

drm/radeon/si: Add support for CP DMA to CS checker for compute v2

Also add a new RADEON_INFO query to check that CP DMA packets are
supported on the compute ring.

CP DMA has been supported since the 3.8 kernel, but due to an oversight
we forgot to teach the CS checker that the CP DMA packet was legal for
the compute ring on Southern Islands GPUs.

This patch fixes a bug where the radeon driver will incorrectly reject a legal
CP DMA packet from user space.  I would like to have the patch
backported to stable so that we don't have to require Mesa users to use a
bleeding edge kernel in order to take advantage of this feature which
is already present in the stable kernels (3.8 and newer).

v2:
  - Don't bump kms version, so this patch can be backported to stable
    kernels.

Cc: stable@vger.kernel.org
Signed-off-by: Tom Stellard <thomas.stellard@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: enable mgcg on CIK

Now that the CP is no longer reset and cg is properly
disabled in when appropriate in the dpm code we can
now enable mgcg (medium grained clockgating).

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: handle cg in KB/KV dpm code

Clockgating needs to be disabled around certain parts
of dpm setup otherwise the smc gets into a bad state
and dpm doesn't work properly.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: handle cg in CI dpm code

Clockgating needs to be disabled around certain parts
of dpm setup otherwise the smc gets into a bad state
and dpm doesn't work properly.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon/cik: properly set up the clearstate buffer for pg (v2)

The format of the clearstate buffer used for pg (powergating)
changed between NI and SI.  This formats it properly for what
the hardware expects on SI+.

v2: fix addresses

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: fixes for gfx clockgating on CIK

Clockgating requires signalling between the CP and the
RLC to work properly.  Resetting the CP block in the
CP resume code messed up the internal coordination
between the blocks.  Removing the reset allows gfx
clockgating to work properly.  However, when gfx clock
gating is enabled, there is a strange interaction with
dpm which causes the chip to stay in the high performance
level all the time, so leave gfx clockgating disabled
for now.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: restructure cg/pg on cik (v2)

- use new cg/pg flags for finer grained clock and
powergating control
- restructure the cg/pg code so it can be called from
other components such as dpm

v2: fix build breakage from rebase

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon/si: enable DMA pg by default

Enable DMA powergating by default.  The DMA engines
will be powergated when not in use.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon/si: properly set up the clearstate buffer for pg (v2)

The format of the clearstate buffer used for pg (powergating)
changed between NI and SI.  This formats it properly for what
the hardware expects on SI.

v2: fix addresses

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: enable mgcg on SI

Now that the CP is no longer reset and cg is properly
disabled in when appropriate in the dpm code we can
now enable mgcg (medium grained clockgating).

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: handle cg in SI dpm code

Clockgating needs to be disabled around certain parts
of dpm setup otherwise the smc gets into a bad state
and dpm doesn't work properly.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: fixes for gfx clockgating on SI

Clockgating requires signalling between the CP and the
RLC to work properly.  Resetting the CP block in the
CP resume code messed up the internal coordination
between the blocks.  Removing the reset allows gfx
clockgating to work properly.  However, when gfx clock
gating is enabled, there is a strange interaction with
dpm which causes the chip to stay in the high performance
level all the time, so leave gfx clockgating disabled
for now.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon/si: restructure cg code (v3)

Resturcture clockgating code so that it can be
enabled/disabled from other components such as
dpm.

v2: make function static
v3: add fine grained cg controls

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: use new cg/pg flags for SI

Allows us finer grained control over clock and
powergating on SI.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: add cg and pg flags

This commits adds flags for supported clockgating and
powergating features.  This allows us to more easily
track which features are supported on a particular
asic and to enable/disable features for debugging.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: set speaker allocation for DCE3.2

This updates the audio driver to the speaker allocation
block from the EDID.  A similar change was just implemented
for DCE4-8.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: set speaker allocation for DCE4/5 (v2)

This updates the audio driver to the speaker allocation
block from the EDID.  A similar change was just implemented
for DCE6/8.

v2: remove unused variables

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Rafał Miłecki <zajec5@gmail.com>

drm/radeon: set speakers allocation earlier

Do it before enabling audio channels (in AFMT_AUDIO_PACKET_CONTROL2
register).

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: add audio support for DCE6/8 GPUs (v12)

Similar to DCE4/5, but supports multiple audio pins
which can be assigned per afmt block.

v2: rework the driver to handle more than one audio
pin.
v3: try different dto reg
v4: properly program dto
v5 (ck): change dto programming order
v6: program speaker allocation block
v7: rebase
v8: rebase on Rafał's changes
v9: integrated Rafał's comments, update to latest
    drm_edid_to_speaker_allocation API
v10: add missing line break in error message
v11: add back audio enabled messages
v12: fix copy paste typo in r600_audio_enable

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Rafał Miłecki <zajec5@gmail.com>

drm/radeon: use loop for initializing AFMT blocks

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/edid: add a helper function to extract the speaker allocation data block (v3)

This adds a helper function to extract the speaker allocation
data block from the EDID.  This data block describes what speakers
are present on the display device.

v2: update per Ville Syrjälä's comments
v3: fix copy/paste typo in memory allocation

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Rafał Miłecki <zajec5@gmail.com>

drm/radeon: separate DMA code

Similar to separating the UVD code, just put the DMA
functions into separate files.

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: separate UVD code v3

Our different hardware blocks are actually completely
separated, so it doesn't make much sense any more to
structure the code by pure chipset generations.

Start restructuring the code by separating our the UVD block.

v2: updated commit message
v3: rebased and restructurized start/stop functions for kv dpm.

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: remove special handling for the DMA ring

Now that we have callbacks for [rw]ptr handling we can
remove the special handling for the DMA rings and use
the callbacks instead.

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>