We had two failure modes here:
1.
Deadlock in intelfb_alloc failure path where it calls
drm_framebuffer_remove, which grabs the struct mutex and intelfb_create
(caller of intelfb_alloc) was already holding it.
2.
Deadlock in intelfb_create failure path where it calls
drm_framebuffer_unreference, which grabs the struct mutex and
intelfb_create was already holding it.
[Daniel Vetter on why struct_mutex needs to be locked in the second half
of intelfb_create: "The vma [for the fbdev] is pinned, the problem is
that we re-lookup it a few times, which is racy. We should instead track
the vma directly, but oh well we don't."]
v2:
* Reformat commit msg to 72 chars. (Lukas Wunner)
* Add third failure mode. (Lukas Wunner)
v5:
* Rebase on drm-intel-nightly 2015y-09m-01d-09h-06m-08s UTC,
rephrase commit message. (Jani Nicula)
v6:
* In intelfb_alloc, if __intel_framebuffer_create failed,
fb will be an ERR_PTR, thus not null. So in the failure
path we need to check for IS_ERR_OR_NULL to avoid calling
drm_framebuffer_remove on the ERR_PTR. (Lukas Wunner)
* Since this is init code a drm_framebuffer_unreference should
be all we need. drm_framebuffer_remove is for framebuffers
that userspace has created - and is getting somewhat
defeatured. (Daniel Vetter)
v7:
* Clarify why struct_mutex needs to be locked in the second half
of intelfb_create. (Daniel Vetter)
Fixes: 60a5ca015f ("drm/i915: Add locking around
framebuffer_references--")
Reported-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
[Lukas: Create v3 + v4 + v5 + v6 + v7 based on Tvrtko's v2]
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/47d4e88c91b3bf0f7a280cabec54c8c8cf0cf6f2.1446892879.git.lukas@wunner.de
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Currently when allocating a framebuffer fails, the gem object gets
unrefed at the bottom of the call stack in __intel_framebuffer_create,
not where it gets refed, which is in intel_framebuffer_create_for_mode
(via i915_gem_alloc_object) and in intel_user_framebuffer_create
(via drm_gem_object_lookup).
This invites mistakes: __intel_framebuffer_create is also called from
intelfb_alloc, and as discovered by Tvrtko Ursulin, a double unref
was introduced there with a8bb681827 ("drm/i915: Fix error path leak
in fbdev fb allocation").
As suggested by Ville Syrjälä, fix the double unref and improve code
clarity by moving the unref away from __intel_framebuffer_create to
where the gem object gets refed.
Based on Tvrtko Ursulin's original v2.
v3: On fb alloc failure, unref gem object where it gets refed,
fix double unref in separate commit (Ville Syrjälä)
v4: Lock struct_mutex on unref (Chris Wilson)
v5: Rebase on drm-intel-nightly 2015y-09m-01d-09h-06m-08s UTC,
rephrase commit message (Jani Nicula)
Tested-by: Pierre Moreau <pierre.morrow@free.fr>
[MBP 5,3 2009 nvidia MCP79 + G96 pre-retina]
Tested-by: Paul Hordiienko <pvt.gord@gmail.com>
[MBP 6,2 2010 intel ILK + nvidia GT216 pre-retina]
Tested-by: William Brown <william@blackhats.net.au>
[MBP 8,2 2011 intel SNB + amd turks pre-retina]
Tested-by: Lukas Wunner <lukas@wunner.de>
[MBP 9,1 2012 intel IVB + nvidia GK107 pre-retina]
Tested-by: Bruno Bierbaumer <bruno@bierbaumer.net>
[MBP 11,3 2013 intel HSW + nvidia GK107 retina]
Fixes: a8bb681827 ("drm/i915: Fix error path leak in fbdev fb
allocation")
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/2161c5062ef5d6458f8ae14d924a26d4d1dba317.1446892879.git.lukas@wunner.de
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Merge second patch-bomb from Andrew Morton:
- most of the rest of MM
- procfs
- lib/ updates
- printk updates
- bitops infrastructure tweaks
- checkpatch updates
- nilfs2 update
- signals
- various other misc bits: coredump, seqfile, kexec, pidns, zlib, ipc,
dma-debug, dma-mapping, ...
* emailed patches from Andrew Morton <akpm@linux-foundation.org>: (102 commits)
ipc,msg: drop dst nil validation in copy_msg
include/linux/zutil.h: fix usage example of zlib_adler32()
panic: release stale console lock to always get the logbuf printed out
dma-debug: check nents in dma_sync_sg*
dma-mapping: tidy up dma_parms default handling
pidns: fix set/getpriority and ioprio_set/get in PRIO_USER mode
kexec: use file name as the output message prefix
fs, seqfile: always allow oom killer
seq_file: reuse string_escape_str()
fs/seq_file: use seq_* helpers in seq_hex_dump()
coredump: change zap_threads() and zap_process() to use for_each_thread()
coredump: ensure all coredumping tasks have SIGNAL_GROUP_COREDUMP
signal: remove jffs2_garbage_collect_thread()->allow_signal(SIGCONT)
signal: introduce kernel_signal_stop() to fix jffs2_garbage_collect_thread()
signal: turn dequeue_signal_lock() into kernel_dequeue_signal()
signals: kill block_all_signals() and unblock_all_signals()
nilfs2: fix gcc uninitialized-variable warnings in powerpc build
nilfs2: fix gcc unused-but-set-variable warnings
MAINTAINERS: nilfs2: add header file for tracing
nilfs2: add tracepoints for analyzing reading and writing metadata files
...
Here's a handful of i915 fixes for drm-next/v4.4. Imre's commit alone
should address the remaining warnings galore you experienced on
Skylake. Almost all of the rest are also fixes against user or QA
reported bugs, with references.
* tag 'drm-intel-next-fixes-2015-11-06' of git://anongit.freedesktop.org/drm-intel:
drm/i915/skl: disable display side power well support for now
drm/i915: Extend DSL readout fix to BDW and SKL.
drm/i915: Do graphics device reset under forcewake
drm/i915: Skip fence installation for objects with rotated views (v4)
drm/i915: add quirk to enable backlight on Dell Chromebook 11 (2015)
drm/i915/skl: Prevent unclaimed register writes on skylake.
drm/i915: disable CPU PWM also on LPT/SPT backlight disable
drm/i915: Fix maxfifo watermark calc on vlv cursor planes
drm/i915: add hotplug activation period to hotplug update mask
There are many places which use mapping_gfp_mask to restrict a more
generic gfp mask which would be used for allocations which are not
directly related to the page cache but they are performed in the same
context.
Let's introduce a helper function which makes the restriction explicit and
easier to track. This patch doesn't introduce any functional changes.
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Michal Hocko <mhocko@suse.com>
Suggested-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
__GFP_WAIT was used to signal that the caller was in atomic context and
could not sleep. Now it is possible to distinguish between true atomic
context and callers that are not willing to sleep. The latter should
clear __GFP_DIRECT_RECLAIM so kswapd will still wake. As clearing
__GFP_WAIT behaves differently, there is a risk that people will clear the
wrong flags. This patch renames __GFP_WAIT to __GFP_RECLAIM to clearly
indicate what it does -- setting it allows all reclaim activity, clearing
them prevents it.
[akpm@linux-foundation.org: fix build]
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Acked-by: Michal Hocko <mhocko@suse.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Christoph Lameter <cl@linux.com>
Acked-by: David Rientjes <rientjes@google.com>
Cc: Vitaly Wool <vitalywool@gmail.com>
Cc: Rik van Riel <riel@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
__GFP_WAIT has been used to identify atomic context in callers that hold
spinlocks or are in interrupts. They are expected to be high priority and
have access one of two watermarks lower than "min" which can be referred
to as the "atomic reserve". __GFP_HIGH users get access to the first
lower watermark and can be called the "high priority reserve".
Over time, callers had a requirement to not block when fallback options
were available. Some have abused __GFP_WAIT leading to a situation where
an optimisitic allocation with a fallback option can access atomic
reserves.
This patch uses __GFP_ATOMIC to identify callers that are truely atomic,
cannot sleep and have no alternative. High priority users continue to use
__GFP_HIGH. __GFP_DIRECT_RECLAIM identifies callers that can sleep and
are willing to enter direct reclaim. __GFP_KSWAPD_RECLAIM to identify
callers that want to wake kswapd for background reclaim. __GFP_WAIT is
redefined as a caller that is willing to enter direct reclaim and wake
kswapd for background reclaim.
This patch then converts a number of sites
o __GFP_ATOMIC is used by callers that are high priority and have memory
pools for those requests. GFP_ATOMIC uses this flag.
o Callers that have a limited mempool to guarantee forward progress clear
__GFP_DIRECT_RECLAIM but keep __GFP_KSWAPD_RECLAIM. bio allocations fall
into this category where kswapd will still be woken but atomic reserves
are not used as there is a one-entry mempool to guarantee progress.
o Callers that are checking if they are non-blocking should use the
helper gfpflags_allow_blocking() where possible. This is because
checking for __GFP_WAIT as was done historically now can trigger false
positives. Some exceptions like dm-crypt.c exist where the code intent
is clearer if __GFP_DIRECT_RECLAIM is used instead of the helper due to
flag manipulations.
o Callers that built their own GFP flags instead of starting with GFP_KERNEL
and friends now also need to specify __GFP_KSWAPD_RECLAIM.
The first key hazard to watch out for is callers that removed __GFP_WAIT
and was depending on access to atomic reserves for inconspicuous reasons.
In some cases it may be appropriate for them to use __GFP_HIGH.
The second key hazard is callers that assembled their own combination of
GFP flags instead of starting with something like GFP_KERNEL. They may
now wish to specify __GFP_KSWAPD_RECLAIM. It's almost certainly harmless
if it's missed in most cases as other activity will wake kswapd.
Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Michal Hocko <mhocko@suse.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Christoph Lameter <cl@linux.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Vitaly Wool <vitalywool@gmail.com>
Cc: Rik van Riel <riel@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
We have a timed release of a forcewake when using
I915_READ/WRITE macros. wait_for() macro will go to quite
long sleep if the first read doesn't satisfy the condition for
successful exit. With these two interacting, it is possible that
we lose the forcewake during the wait_for() and the subsequent read
will reaquire forcewake.
Further experiments with skl shows that when we lose forcewake,
we lose the reset request we submitted. So reset request register
is not power context saved.
Grab forcewakes for all engines before starting the reset/request
dance so that all requests stay valid for the duration of reset
requisition across all the engines.
v2: Add comment on power well sleeps. Wrap the reset handling
under forcewake instead of just reset requests (Chris)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92774
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Tomi Sarvela <tomix.p.sarvela@intel.com> (v1, v2)
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446721898-1450-1-git-send-email-mika.kuoppala@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
It just makes the code more confusing, so just reference intel_dp_>DP
directly.
Note that this also fix a bug where the value of intel_dp->DP could be
different than the last value written to the hw, due to an early return
that would skip the 'intel_dp->DP = DP' line.
v2: Don't preserve old DP value on failure. (Sivakumar)
- Don't call drm_dp_clock_recovery_ok() twice. (Sivakumar)
- Keep return type of clock recovery and channel equalization
functions as void. (Ander)
v3: Remove DP parameter from intel_dp_set_signal_levels(). (Sivakumar)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445594525-7174-2-git-send-email-ander.conselvan.de.oliveira@intel.com
BXT CRTC scaling uses the same gen9 codepaths as SKL; these codepaths
store panel fitter information in pipe_config->pch_pfit. However since
HAS_PCH_SPLIT() is false for BXT we never actually wind up filling in
this structure (we wind up filling in pipe_config->gmch_pfit instead,
which is ignored when we go to program the hardware). Make sure we
always take the PCH code path on gen9+ platforms.
v2: Use HAS_GMCH_DISPLAY() to more cleanly describe the platforms that
actually want to use GMCH-style panel fitting. (Ville)
Cc: Imre Deak <imre.deak@intel.com>
Cc: Chandra Konduru <chandra.konduru@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446656727-3516-1-git-send-email-matthew.d.roper@intel.com
Make pinning and waiting a separate step, and wait for object idle
without struct_mutex held.
Changes since v1:
- Do not wait when a reset is in progress.
- Remove call to i915_gem_object_wait_rendering for
intel_overlay_do_put_image (Chris Wilson)
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
struct_mutex is being locked for every plane in intel_prepare_plane_fb
and intel_cleanup_plane_fb.
Require the caller to hold the mutex, and only acquire the mutex for
each helper call. This way the lock only needs to be acquired
twice in ->atomic_commit(). Once for pinning new framebuffers at the
start, the second time for unpinning old framebuffer.
Changes since v1:
- Use mutex_lock_interruptible instead of i915 variant,
to prevent a deadlock when called from the reset code.
Changes since v2:
- Clarify struct_mutex is locked by the caller.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com> #v1
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Extends i915_display_info so that for each active crtc also print
all planes associated with the pipe. This patch shows information
about each plane wrt format, size, position, rotation, and scaling.
This is very useful when debugging user space compositors that try
to utilize several planes for a commit.
V2: Fixed comments from Maarten, Ville, and Chris. Fixed printing of
16.16 fixpoint, better rotation bitmask management and some minor fixes
V3: Corrected state->src_x & 0x00ff to state->src_x & 0xffff...
Signed-off-by: Robert Fekete <robert.fekete@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445961512-25317-1-git-send-email-robert.fekete@linux.intel.com
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Bunch of -fixes for 4.4. Well not just, I've left the mmio/register work
from Ville in here since it's low-risk but lots of churn all over.
* tag 'drm-intel-next-fixes-2015-10-22' of git://anongit.freedesktop.org/drm-intel: (23 commits)
drm/i915: Use round to closest when computing the CEA 1.001 pixel clocks
drm/i915: Kill the leftover RMW from ivb_sprite_disable()
drm/i915: restore ggtt double-bind avoidance
drm/i915/skl: Enable pipe gamma for sprite planes.
drm/i915/skl+: Enable pipe CSC on cursor planes. (v2)
MAINTAINERS: add link to the Intel Graphics for Linux web site
drm/i915: Move skl/bxt gt specific workarounds to ring init
drm/i915: Drop i915_gem_obj_is_pinned() from set-cache-level
drm/i915: revert a few more watermark commits
drm/i915: Remove dev_priv argument from NEEDS_FORCE_WAKE
drm/i915: Clean up LVDS register handling
drm/i915: Throw out some useless variables
drm/i915: Parametrize and fix SWF registers
drm/i915: s/PIPE_FRMCOUNT_GM45/PIPE_FRMCOUNT_G4X/ etc.
drm/i915: Turn GEN5_ASSERT_IIR_IS_ZERO() into a function
drm/i915: Fix a few bad hex numbers in register defines
drm/i915: Protect register macro arguments
drm/i915: Include gpio_mmio_base in GMBUS reg defines
drm/i915: Parametrize HSW video DIP data registers
drm/i915: Eliminate weird parameter inversion from BXT PPS registers
...
Kabylake is a Intel® Processor containing Intel® HD Graphics
following Skylake.
It is Gen9p5, so it inherits everything from Skylake.
Let's start by adding the platform separated from Skylake
but reusing most of all features, functions etc. Later we
rebase the PCI-ID patch without is_skylake=1
so we don't replace what original Author did there.
Few IS_SKYLAKEs if statements are not being covered by this patch
on purpose:
- Workarounds: Kabylake is derivated from Skylake H0 so no
W/As apply here.
- GuC: A following patch removes Kabylake support with an
explanation: No firmware available yet.
- DMC/CSR: Done in a separated patch since we need to be carefull
and load the version for revision 7 since
Kabylake is Skylake H0.
v2: relative cleaner commit message and added the missed
IS_KABYLAKE to intel_i2c.c as pointed out by Jani.
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Having flushed all requests from all queues, we know that all
ringbuffers must now be empty. However, since we do not reclaim
all space when retiring the request (to prevent HEADs colliding
with rapid ringbuffer wraparound) the amount of available space
on each ringbuffer upon reset is less than when we start. Do one
more pass over all the ringbuffers to reset the available space
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Arun Siluvery <arun.siluvery@linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Dave Gordon <david.s.gordon@intel.com>
