In
commit 81e49f8114
Author: Glauber Costa <glommer@openvz.org>
Date: Wed Aug 28 10:18:13 2013 +1000
i915: bail out earlier when shrinker cannot acquire mutex
SHRINK_STOP was added to tell the core shrinker code to bail out and
go to the next shrinker since the i915 shrinker couldn't acquire
required locks. But the SHRINK_STOP return code was added to the
->count_objects callback and not the ->scan_objects callback as it
should have been, resulting in tons of dmesg noise like
shrink_slab: i915_gem_inactive_scan+0x0/0x9c negative objects to delete nr=-xxxxxxxxx
Fix discusssed with Dave Chinner.
References: http://www.spinics.net/lists/intel-gfx/msg33597.html
Reported-by: Knut Petersen <Knut_Petersen@t-online.de>
Cc: Knut Petersen <Knut_Petersen@t-online.de>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Glauber Costa <glommer@openvz.org>
Cc: Glauber Costa <glommer@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Michal Hocko <mhocko@suse.cz>
Acked-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This regression has been introduced in
commit 9f11a9e4e5
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Jun 13 00:54:58 2013 +0200
drm/i915: set up PIPECONF explicitly for i9xx/vlv platforms
Ville brough up the idea that this is just the pipe A quirk gone
wrong.
Note that after resume the bios might or might not have enabled pipe A
already. We have a bit of magic to make sure that on resume we set up
a decent mode for pipe A, but I fear if I just smash pipe A to always
on we'd enable it in a bogus state and hang the hw. Hence the
readback.
v2: Clarify the logic a bit as suggested by Chris. Also amend the
commit message to clarify why we don't unconditionally enable the
pipe.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66462
References: https://lkml.org/lkml/2013/8/26/238
Cc: Meelis Roos <mroos@ut.ee>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Use |= instead of = as suggested by Chris.]
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The native TV encoder has it's own flags to adjust sync modes and
enabled interlaced modes which are totally irrelevant for the adjusted
mode. This worked out nicely since the input modes used by both the
load detect code and reported in the ->get_modes callbacks all have no
flags set, and we also don't fill out any of them in the ->get_config
callback.
This changed with the additional sanitation done with
commit 2960bc9cce
Author: Imre Deak <imre.deak@intel.com>
Date: Tue Jul 30 13:36:32 2013 +0300
drm/i915: make user mode sync polarity setting explicit
sinc now the "no flags at all" state wouldn't fit through core code
any more. So fix this up again by explicitly clearing the flags in the
->compute_config callback.
Aside: We have zero checking in place to make sure that the requested
mode is indeed the right input mode we want for the selected TV mode.
So we'll happily fall over if userspace tries to pull us. But that's
definitely work for a different patch series. So just add a FIXME
comment for now.
Reported-by: Knut Petersen <Knut_Petersen@t-online.de>
Cc: Knut Petersen <Knut_Petersen@t-online.de>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Knut Petersen <Knut_Petersen@t-online.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There is no clear cut rules or specs for the retry interval, as there
are many factors that affect overall response time. Increase the
interval, and even more so on branch devices which may have limited i2c
bit rates.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=60263
Tested-by: Nicolas Suzor <nic@suzor.com>
Reviewed-by: Todd Previte <tprevite@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In
commit edc3d8848d
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date: Thu May 23 13:55:35 2013 +0300
drm/i915: avoid big kmallocs on reading error state
we introduce a two-pass mechanism for splitting long strings being
formatted into the error-state. The first pass finds the length, and the
second pass emits the right portion of the string into the accumulation
buffer. Unfortunately we use the same va_list for both passes, resulting
in the second pass reading garbage off the end of the argument list. As
the two passes are only used for boundaries between read() calls, the
corruption is only rarely seen.
This fixes the root cause behind
commit baf27f9b17
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Sat Jun 29 23:26:50 2013 +0100
drm/i915: Break up the large vsnprintf() in print_error_buffers()
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Pull drm fixes from Dave Airlie:
- some small fixes for msm and exynos
- a regression revert affecting nouveau users with old userspace
- intel pageflip deadlock and gpu hang fixes, hsw modesetting hangs
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: (22 commits)
Revert "drm: mark context support as a legacy subsystem"
drm/i915: Don't enable the cursor on a disable pipe
drm/i915: do not update cursor in crtc mode set
drm/exynos: fix return value check in lowlevel_buffer_allocate()
drm/exynos: Fix address space warnings in exynos_drm_fbdev.c
drm/exynos: Fix address space warning in exynos_drm_buf.c
drm/exynos: Remove redundant OF dependency
drm/msm: drop unnecessary set_need_resched()
drm/i915: kill set_need_resched
drm/msm: fix potential NULL pointer dereference
drm/i915/dvo: set crtc timings again for panel fixed modes
drm/i915/sdvo: Robustify the dtd<->drm_mode conversions
drm/msm: workaround for missing irq
drm/msm: return -EBUSY if bo still active
drm/msm: fix return value check in ERR_PTR()
drm/msm: fix cmdstream size check
drm/msm: hangcheck harder
drm/msm: handle read vs write fences
drm/i915/sdvo: Fully translate sync flags in the dtd->mode conversion
drm/i915: Use proper print format for debug prints
...
On HSW enabling a plane on a disabled pipe may hang the entire system.
And there's no good reason for doing it ever, so just don't.
v2: Move the crtc active checks to intel_crtc_cursor_{set,move} to
avoid confusing people during modeset
Cc: stable@vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The cursor is disabled before crtc mode set in crtc disable (and we
assert this is the case), and enabled afterwards in crtc enable. Do not
update it in crtc mode set.
On HSW enabling a plane on a disabled pipe may hang the entire system.
And there's no good reason for doing it ever, so just don't.
v2: Add note about HSW hangs - vsyrjala
Cc: stable@vger.kernel.org
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Pull vfs pile 4 from Al Viro:
"list_lru pile, mostly"
This came out of Andrew's pile, Al ended up doing the merge work so that
Andrew didn't have to.
Additionally, a few fixes.
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (42 commits)
super: fix for destroy lrus
list_lru: dynamically adjust node arrays
shrinker: Kill old ->shrink API.
shrinker: convert remaining shrinkers to count/scan API
staging/lustre/libcfs: cleanup linux-mem.h
staging/lustre/ptlrpc: convert to new shrinker API
staging/lustre/obdclass: convert lu_object shrinker to count/scan API
staging/lustre/ldlm: convert to shrinkers to count/scan API
hugepage: convert huge zero page shrinker to new shrinker API
i915: bail out earlier when shrinker cannot acquire mutex
drivers: convert shrinkers to new count/scan API
fs: convert fs shrinkers to new scan/count API
xfs: fix dquot isolation hang
xfs-convert-dquot-cache-lru-to-list_lru-fix
xfs: convert dquot cache lru to list_lru
xfs: rework buffer dispose list tracking
xfs-convert-buftarg-lru-to-generic-code-fix
xfs: convert buftarg LRU to generic code
fs: convert inode and dentry shrinking to be node aware
vmscan: per-node deferred work
...
This is just a remnant from the old days when our reset handling was
horribly racy, suffered from terribly locking issues and often happily
live-locked. Those days are now gone so we can drop the hacks and just
rip the reschedule-point out.
Reported-by: Peter Zijlstra <peterz@infradead.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Yet another regression due to
commit 135c81b8c3
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Sun Jul 21 21:37:09 2013 +0200
drm/i915: clean up crtc timings computation
I'm starting to wonder whether this was worth it ...
v2: Actually make it compile.
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>
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 135c81b8c3
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>
The main shrinker driver will keep trying for a while to free objects if
the returned value from the shrink scan procedure is 0. That means "no
objects now", but a retry could very well succeed.
But what we should say here is a different thing: that it is impossible to
shrink, and we would better bail out soon. We find this behavior more
appropriate for the case where the lock cannot be taken. Specially given
the hammer behavior of the i915: if another thread is already shrinking,
we are likely not to be able to shrink anything anyway when we finally
acquire the mutex.
Signed-off-by: Glauber Costa <glommer@openvz.org>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Dave Chinner <dchinner@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Kent Overstreet <koverstreet@google.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Carlos Maiolino <cmaiolino@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Chuck Lever <chuck.lever@oracle.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: David Rientjes <rientjes@google.com>
Cc: Gleb Natapov <gleb@redhat.com>
Cc: Greg Thelen <gthelen@google.com>
Cc: J. Bruce Fields <bfields@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Kent Overstreet <koverstreet@google.com>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Steven Whitehouse <swhiteho@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Convert the driver shrinkers to the new API. Most changes are compile
tested only because I either don't have the hardware or it's staging
stuff.
FWIW, the md and android code is pretty good, but the rest of it makes me
want to claw my eyes out. The amount of broken code I just encountered is
mind boggling. I've added comments explaining what is broken, but I fear
that some of the code would be best dealt with by being dragged behind the
bike shed, burying in mud up to it's neck and then run over repeatedly
with a blunt lawn mower.
Special mention goes to the zcache/zcache2 drivers. They can't co-exist
in the build at the same time, they are under different menu options in
menuconfig, they only show up when you've got the right set of mm
subsystem options configured and so even compile testing is an exercise in
pulling teeth. And that doesn't even take into account the horrible,
broken code...
[glommer@openvz.org: fixes for i915, android lowmem, zcache, bcache]
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Glauber Costa <glommer@openvz.org>
Acked-by: Mel Gorman <mgorman@suse.de>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Kent Overstreet <koverstreet@google.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Carlos Maiolino <cmaiolino@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Chuck Lever <chuck.lever@oracle.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: David Rientjes <rientjes@google.com>
Cc: Gleb Natapov <gleb@redhat.com>
Cc: Greg Thelen <gthelen@google.com>
Cc: J. Bruce Fields <bfields@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Kent Overstreet <koverstreet@google.com>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Steven Whitehouse <swhiteho@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
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>
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>
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 96a02917a0
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>
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>
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 81b5c7bc8d
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>
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>
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 ffe74d7550
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>
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 eaba1b8f33
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>
Since we've started to clean up pending flips when the gpu hangs in
commit 96a02917a0
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>
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>
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 f1f644dc66
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>
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 6cc5f341b5
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>
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 69787f7da6
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 b4a98e57fc
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>
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 5032d871f7
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>
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>
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>
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
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>
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>
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>
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>
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>
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>
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>
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 135c81b8c3
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>
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 05407ff889
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>
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>
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>
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>
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>
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>
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>
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
Need to get my stuff out the door ;-) Highlights:
- pc8+ support from Paulo
- more vma patches from Ben.
- Kconfig option to enable preliminary support by default (Josh
Triplett)
- Optimized cpu cache flush handling and support for write-through caching
of display planes on Iris (Chris)
- rc6 tuning from Stéphane Marchesin for more stability
- VECS seqno wrap/semaphores fix (Ben)
- a pile of smaller cleanups and improvements all over
Note that I've ditched Ben's execbuf vma conversion for 3.12 since not yet
ready. But there's still other vma conversion stuff in here.
* tag 'drm-intel-next-2013-08-23' of git://people.freedesktop.org/~danvet/drm-intel: (62 commits)
drm/i915: Print seqnos as unsigned in debugfs
drm/i915: Fix context size calculation on SNB/IVB/VLV
drm/i915: Use POSTING_READ in lcpll code
drm/i915: enable Package C8+ by default
drm/i915: add i915.pc8_timeout function
drm/i915: add i915_pc8_status debugfs file
drm/i915: allow package C8+ states on Haswell (disabled)
drm/i915: fix SDEIMR assertion when disabling LCPLL
drm/i915: grab force_wake when restoring LCPLL
drm/i915: drop WaMbcDriverBootEnable workaround
drm/i915: Cleaning up the relocate entry function
drm/i915: merge HSW and SNB PM irq handlers
drm/i915: fix how we mask PMIMR when adding work to the queue
drm/i915: don't queue PM events we won't process
drm/i915: don't disable/reenable IVB error interrupts when not needed
drm/i915: add dev_priv->pm_irq_mask
drm/i915: don't update GEN6_PMIMR when it's not needed
drm/i915: wrap GEN6_PMIMR changes
drm/i915: wrap GTIMR changes
drm/i915: add the FCLK case to intel_ddi_get_cdclk_freq
...
This lets drivers see the flags requested by the application
[airlied: fixup for rcar/imx/msm]
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
With all the common infoframe bits now in place, we can finally write
the vendor specific infoframes in our driver.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
Daniel Vetter
Jani Nikula
Chris Wilson
Linus Torvalds
Ville Syrjälä
Glauber Costa
Dave Chinner
Takashi Iwai
Damien Lespiau
Alex Williamson
Paulo Zanoni
Jesse Barnes
Joe Perches
Imre Deak
Mika Kuoppala
Kristian Høgsberg
Dave Airlie
Keith Packard