Jani Nikula
2a307c2e91
drm/i915: add some more "i" in platform names for consistency
...
Consistency FTW.
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Signed-off-by: Jani Nikula <jani.nikula@intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/9ab811dc06570bd3fc05a917ade1bdc9bb805a75.1480520526.git.jani.nikula@intel.com
2016-12-07 15:19:31 +02:00
Jani Nikula
c0f86832e3
drm/i915: rename BROADWATER and CRESTLINE to I965G and I965GM, respectively
...
Add more consistency to our naming. Pineview remains the outlier. Keep
using code names for gen5+.
v2: rebased
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Signed-off-by: Jani Nikula <jani.nikula@intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/1481105584-23033-1-git-send-email-jani.nikula@intel.com
2016-12-07 15:18:33 +02:00
Chris Wilson
778e23a9e0
drm/i915: Implement local atomic_state_free callback
...
As we use debugobjects to track the lifetime of fences within our atomic
state, we ideally want to mark those objects as freed along with their
containers. This merits us hookin into config->funcs->atomic_state_free
for this purpose.
This allows us to enable debugobjects for sw-fences without triggering
known issues.
Fixes: fc1584059d ("drm/i915: Integrate i915_sw_fence with debugobjects")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20161205142941.21965-4-chris@chris-wilson.co.uk
2016-12-05 20:49:17 +00:00
Ville Syrjälä
11a85d6ab1
drm/i915: Skip vblank wait if cxsr was already off
...
Before we attempt to turn any planes on or off we must first exit
csxr. That's due to cxsr effectively making the plane enable bits
read-only. Currently we achieve that with a vblank wait right after
toggling the cxsr enable bit. We do the vblank wait even if cxsr was
already off, which seems wasteful, so let's try to only do it when
absolutely necessary.
We could start tracking the cxsr state fully somewhere, but for now
it seems easiest to just have intel_set_memory_cxsr() return the
previous cxsr state.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/1480354637-14209-11-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com >
2016-12-05 16:23:27 +02:00
Ville Syrjälä
3d90e649fa
drm/i915: Protect cxsr state with wm_mutex
...
Let's protect the cxsr state with the wm_mutex, since it might
get poked from multiple places if there's a parallel plane update
happening with a pipe getting enable/disabled.
It's still pretty racy for the old platforms, but for vlv/chv it
should work, I think. If not, we'll improve it later anyway.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/1480354637-14209-10-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com >
2016-12-05 16:23:27 +02:00
Ville Syrjälä
ddd2b792cc
drm/i915: Use the ilk_disable_lp_wm() return value
...
ilk_disable_lp_wm() will tell us whether the LP1+ watermarks were
disabled or not, and hence whether we need to for the vblank wait or
not. Let's use that information to eliminate some useless vblank
waits.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/1480354637-14209-3-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com >
2016-12-05 16:23:24 +02:00
Ville Syrjälä
3125d39fe6
drm/i915: Drop the nop intel_update_watermarks() call from haswell_crtc_enable()
...
HSW+ all use the .initial_watermarks() hook, so there's no point in
calling intel_update_watermarks() from HSW+ specific code. We'll still
hang on to the .initial_watermarks NULL check since theoretically if the
memory latencies are not populated we would not populate the function
pointer either.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/1480354637-14209-2-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com >
2016-12-05 16:23:24 +02:00
Chris Wilson
7a9e10253e
drm/i915: Move priority bumping for flips earlier
...
David found another issue with priority bumping from mmioflips, where we
are accessing the requests concurrently to them being retired and freed.
Whilst we are skipping the dependency if has been submitted, that is not
sufficient to stop the dependency from disappearing if another thread
retires that request. To prevent we can either employ the struct_mutex (or a
request mutex in the future) to serialise retiring before it is freed.
Alternatively, we need to keep the dependencies alive using RCU whilst
they are being accessed via the DFS.
[ 1746.698111] general protection fault: 0000 [#1 ] PREEMPT SMP
[ 1746.698305] Modules linked in: snd_hda_intel snd_hda_codec snd_hwdep x86_pkg_temp_thermal snd_hda_core coretemp crct10dif_pclmul crc32_pclmul snd_pcm ghash_clmulni_intel mei_me mei i915 e1000e ptp pps_core i2c_hid
[ 1746.698750] CPU: 1 PID: 6716 Comm: kworker/u8:2 Not tainted 4.9.0-rc6-CI-Nightly_816+ #1
[ 1746.698871] Hardware name: GIGABYTE GB-BKi7A-7500/MFLP7AP-00, BIOS F1 07/27/2016
[ 1746.699125] Workqueue: events_unbound intel_mmio_flip_work_func [i915]
[ 1746.699266] task: ffff880260a5e800 task.stack: ffffc90000f6c000
[ 1746.699361] RIP: 0010:[<ffffffffa006595d>] [<ffffffffa006595d>] execlists_schedule+0x8d/0x300 [i915]
[ 1746.699632] RSP: 0018:ffffc90000f6fcd8 EFLAGS: 00010206
[ 1746.699724] RAX: dead0000000000f8 RBX: ffff8801f64b2bf0 RCX: ffff8801f64b2c10
[ 1746.699842] RDX: dead000000000100 RSI: 0000000000000000 RDI: ffff8801f64b0458
[ 1746.699972] RBP: ffffc90000f6fd68 R08: ffff88026488dc00 R09: 0000000000000002
[ 1746.700090] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000400
[ 1746.700195] R13: ffffc90000f6fcf0 R14: ffff88020955aa40 R15: ffff88020955aa68
[ 1746.700307] FS: 0000000000000000(0000) GS:ffff88026dc80000(0000) knlGS:0000000000000000
[ 1746.700435] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1746.700532] CR2: 0000000002a69e90 CR3: 0000000002c07000 CR4: 00000000003406e0
[ 1746.700635] Stack:
[ 1746.700682] ffff880260a5e880 ffffc90000f6fd50 ffffffff810af69a ffffc90000f6fd28
[ 1746.700827] ffff88020955a628 ffff8801e1eaebf0 0000000000000020 0000000000000000
[ 1746.700947] 00000196af1edc96 ffff88025dfa4000 ffff8801f0b030a8 ffffc90000f6fcf0
[ 1746.701071] Call Trace:
[ 1746.701117] [<ffffffff810af69a>] ? dequeue_entity+0x25a/0xb50
[ 1746.701260] [<ffffffffa00516be>] fence_set_priority+0x7e/0x80 [i915]
[ 1746.701406] [<ffffffffa0051a15>] i915_gem_object_wait_priority+0x85/0x160 [i915]
[ 1746.701599] [<ffffffffa008ccd7>] intel_mmio_flip_work_func+0x47/0x2b0 [i915]
[ 1746.701717] [<ffffffff81094c4d>] process_one_work+0x14d/0x470
[ 1746.701809] [<ffffffff81094fb3>] worker_thread+0x43/0x4e0
[ 1746.701888] [<ffffffff81094f70>] ? process_one_work+0x470/0x470
[ 1746.701969] [<ffffffff81094f70>] ? process_one_work+0x470/0x470
[ 1746.702072] [<ffffffff8109a4d5>] kthread+0xc5/0xe0
[ 1746.702152] [<ffffffff81771c59>] ? _raw_spin_unlock_irq+0x9/0x10
[ 1746.702234] [<ffffffff8109a410>] ? kthread_park+0x60/0x60
[ 1746.702318] [<ffffffff81772272>] ret_from_fork+0x22/0x30
[ 1746.702387] Code: 89 42 08 48 8b 45 88 48 89 55 c0 4c 89 6d c8 4c 8d 70 d8 4d 8d 7e 28 4d 39 ef 74 72 49 8b 1e 48 8b 13 48 39 d3 48 8d 42 f8 74 3e <48> 8b 10 8b 52 38 41 39 d4 7e 26 48 8b 50 30 48 8b 78 28 48 8d
[ 1746.702921] RIP [<ffffffffa006595d>] execlists_schedule+0x8d/0x300 [i915]
Nov 25 21:42:54 kbl-gbbki7 kernel: [ 1746.703027] RSP <ffffc90000f6fcd8>
Fixes: 27745e829a ("drm/i915/execlists: Use a local lock for dfs_link access")
Fixes: 9a151987d7 ("drm/i915: Add execution priority boosting for mmioflips")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: David Weinehall <david.weinehall@linux.intel.com >
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20161128143649.4289-1-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
(cherry picked from commit 92117f0bce )
Signed-off-by: Jani Nikula <jani.nikula@intel.com >
2016-12-05 11:00:32 +02:00
Ville Syrjälä
1f3dc3e334
drm/i915: Initialize dev_priv->atomic_cdclk_freq at init time
...
Looks like we're only initializing dev_priv->atomic_cdclk_freq
at resume and commit times, not at init time. Let's do that as
well.
We're now hitting the 'WARN_ON(intel_state->cdclk == 0)' in
hsw_compute_linetime_wm() on account of populating
intel_state->cdclk from dev_priv->atomic_cdclk_freq.
Previously we were mispopulating intel_state->cdclk with
dev_priv->cdclk_freq which always had a proper value at init
time and hence the WARN_ON() didn't trigger.
Cc: <stable@vger.kernel.org > # 4.6+: 14676ec6b1 drm/i915: Fix cdclk vs. dev_cdclk mess when not recomputing things
Cc: <stable@vger.kernel.org > # 4.6+
Cc: Matthew Auld <matthew.auld@intel.com >
Reported-by: Matthew Auld <matthew.auld@intel.com >
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98902
Fixes: 14676ec6b1 ("drm/i915: Fix cdclk vs. dev_cdclk mess when not recomputing things")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/1480428837-4207-1-git-send-email-ville.syrjala@linux.intel.com
Tested-by: Matthew Auld <matthew.auld@intel.com >
Reviewed-by: Matthew Auld <matthew.auld@intel.com >
(cherry picked from commit 6a259b1f8a )
Signed-off-by: Jani Nikula <jani.nikula@intel.com >
2016-12-05 10:58:31 +02:00
Ville Syrjälä
14676ec6b1
drm/i915: Fix cdclk vs. dev_cdclk mess when not recomputing things
...
When we end up not recomputing the cdclk, we need to populate
intel_state->cdclk with the "atomic_cdclk_freq" instead of the
current cdclk_freq. When no pipes are active, the actual cdclk_freq
may be lower than what the configuration of the planes and
pipes would require from the point of view of the software state.
This fixes bogus WARNS from skl_max_scale() which is trying to check
the plane software state against the cdclk frequency. So any time
it got called during DPMS off for instance, we might have tripped
the warn if the current mode would have required a higher than
minimum cdclk.
v2: Drop the dev_cdclk stuff (Maarten)
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com >
Cc: Mika Kahola <mika.kahola@intel.com >
Cc: bruno.pagani@ens-lyon.org
Cc: Daniel J Blueman <daniel.blueman@gmail.com >
Cc: Paul Bolle <pebolle@tiscali.nl >
Cc: Joseph Yasi <joe.yasi@gmail.com >
Tested-by: Paul Bolle <pebolle@tiscali.nl >
Tested-by: Joseph Yasi <joe.yasi@gmail.com > (v1)
Cc: <stable@vger.kernel.org > # v4.6+
Fixes: 1a617b7765 ("drm/i915: Keep track of the cdclk as if all crtc's were active.")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98214
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/1479141311-11904-2-git-send-email-ville.syrjala@linux.intel.com
(cherry picked from commit e0ca7a6be3 )
Signed-off-by: Jani Nikula <jani.nikula@intel.com >
2016-12-05 10:55:07 +02:00
Daniel Vetter
93cd6fa680
Merge remote-tracking branch 'airlied/drm-next' into drm-intel-next-queued
...
Resync, and we need all the fancy new drm_mm stuff to implement more
efficient evict algorithms for softpin.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com >
2016-12-05 09:52:17 +01:00
Dave Airlie
f03ee46be9
Backmerge tag 'v4.9-rc8' into drm-next
...
Linux 4.9-rc8
Daniel requested this so we could apply some follow on fixes cleanly to -next.
2016-12-05 17:11:48 +10:00
Ander Conselvan de Oliveira
09d093869f
drm/i915/glk: Allow dotclock up to 2 * cdclk on geminilake
...
Geminilake has double wide pipes so it can output two pixels per CD
clock.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com >
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/1480667037-11215-8-git-send-email-ander.conselvan.de.oliveira@intel.com
2016-12-02 16:42:11 +02:00
Ander Conselvan de Oliveira
89b3c3c7ee
drm/i915/glk: Reuse broxton's cdclk code for GLK
...
Geminilake has the same register layout, reference clock and programming
sequence as broxton. The difference is that it doesn't support the 1.5
divider and has different ratios, but a lot of code can be shared
between the two platforms.
v2: Rebase (s/broxton/bxt).
v3: Fix vco calculation in glk_de_pll_vco().
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com >
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/1480667037-11215-7-git-send-email-ander.conselvan.de.oliveira@intel.com
2016-12-02 16:42:00 +02:00
Ander Conselvan de Oliveira
cc3f90f063
drm/i915/glk: Reuse broxton code for geminilake
...
Geminilake is mostly backwards compatible with broxton, so change most
of the IS_BROXTON() checks to IS_GEN9_LP(). Differences between the
platforms will be implemented in follow-up patches.
v2: Don't reuse broxton's path in intel_update_max_cdclk().
Don't set plane count as in broxton.
v3: Rebase
v4: Include the check intel_bios_is_port_hpd_inverted().
Commit message.
v5: Leave i915_dmc_info() out; glk's csr version != bxt's. (Rodrigo)
v6: Rebase.
v7: Convert a few mode IS_BROXTON() occurances in pps, ddi, dsi and pll
code. (Rodrigo)
v8: Squash a couple of DDI patches with more conversions. (Rodrigo)
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com >
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com >
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/1480667037-11215-2-git-send-email-ander.conselvan.de.oliveira@intel.com
2016-12-02 16:38:56 +02:00
Tvrtko Ursulin
401964465f
drm/i915: Make gmbus setup take dev_priv
...
Simplify the code by passing the right argument in.
v2: Commit message. (Joonas Lahtinen)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
2016-12-01 18:01:22 +00:00
Tvrtko Ursulin
12d79d7828
drm/i915: Make GEM object create and create from data take dev_priv
...
Makes all GEM object constructors consistent.
v2: Fix compilation in GVT code.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com > (v1)
2016-12-01 18:01:08 +00:00
Tvrtko Ursulin
187685cb90
drm/i915: Make GEM object alloc/free and stolen created take dev_priv
...
Where it is more appropriate and also to be consistent with
the direction of the driver.
v2: Leave out object alloc/free inlining. (Joonas Lahtinen)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
2016-12-01 18:00:15 +00:00
Matthew Auld
e411072d57
drm/i915: drop the struct_mutex when wedged or trying to reset
...
We grab the struct_mutex in intel_crtc_page_flip, but if we are wedged
or a reset is in progress we bail early but never seem to actually
release the lock.
Fixes: 7f1847ebf4 ("drm/i915: Simplify checking of GPU reset_counter in display pageflips")
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Signed-off-by: Matthew Auld <matthew.auld@intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20161128103648.9235-1-matthew.auld@intel.com
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: <stable@vger.kernel.org > # v4.7+
(cherry picked from commit ddbb271aea )
Signed-off-by: Jani Nikula <jani.nikula@intel.com >
2016-11-30 12:09:26 +02:00
Dave Airlie
a90f58311f
Merge tag 'drm-misc-next-2016-11-29' of git://anongit.freedesktop.org/git/drm-misc into drm-next
...
Big thing is that drm-misc is now officially a group maintainer/committer
model thing, with MAINTAINERS suitably updated. Otherwise just the usual
pile of misc things all over, nothing that stands out this time around.
* tag 'drm-misc-next-2016-11-29' of git://anongit.freedesktop.org/git/drm-misc: (33 commits)
drm: Introduce drm_framebuffer_assign()
drm/bridge: adv7511: Enable the audio data and clock pads on adv7533
drm/bridge: adv7511: Add Audio support
drm/edid: Consider alternate cea timings to be the same VIC
drm/atomic: Constify drm_atomic_crtc_needs_modeset()
drm: bridge: dw-hdmi: add ASoC dependency
drm: Fix shift operations for drm_fb_helper::drm_target_preferred()
drm: Avoid NULL dereference for DRM_LEGACY debug message
drm: Use u64_to_user_ptr() helper for blob ioctls
drm: Fix conflicting macro parameter in drm_mm_for_each_node_in_range()
drm: Fixup kernel doc for driver->gem_create_object
drm/hisilicon/hibmc: mark PM functions __maybe_unused
drm/hisilicon/hibmc: Checking for NULL instead of IS_ERR()
drm: bridge: add DesignWare HDMI I2S audio support
drm: Check against color expansion in drm_mm_reserve_node()
drm: Define drm_mm_for_each_node_in_range()
drm/doc: Fix links in drm_property.c
MAINTAINERS: Add link to drm-misc documentation
vgaarb: use valid dev pointer in vgaarb_info()
drm/atomic: Unconfuse the old_state mess in commmit_tail
...
2016-11-30 14:28:20 +10:00
Ville Syrjälä
6a259b1f8a
drm/i915: Initialize dev_priv->atomic_cdclk_freq at init time
...
Looks like we're only initializing dev_priv->atomic_cdclk_freq
at resume and commit times, not at init time. Let's do that as
well.
We're now hitting the 'WARN_ON(intel_state->cdclk == 0)' in
hsw_compute_linetime_wm() on account of populating
intel_state->cdclk from dev_priv->atomic_cdclk_freq.
Previously we were mispopulating intel_state->cdclk with
dev_priv->cdclk_freq which always had a proper value at init
time and hence the WARN_ON() didn't trigger.
Cc: stable@vger.kernel.org
Cc: Matthew Auld <matthew.auld@intel.com >
Reported-by: Matthew Auld <matthew.auld@intel.com >
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98902
Fixes: e0ca7a6be3 ("drm/i915: Fix cdclk vs. dev_cdclk mess when not recomputing things")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/1480428837-4207-1-git-send-email-ville.syrjala@linux.intel.com
Tested-by: Matthew Auld <matthew.auld@intel.com >
Reviewed-by: Matthew Auld <matthew.auld@intel.com >
2016-11-29 19:52:38 +02:00
Chris Wilson
49d73912cb
drm/i915: Convert vm->dev backpointer to vm->i915
...
99% of the time we access i915_address_space->dev we want the i915
device and not the drm device, so let's store the drm_i915_private
backpointer instead. The only real complication here are the inlines
in i915_vma.h where drm_i915_private is not yet defined and so we have
to choose an alternate path for our asserts.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20161129095008.32622-1-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
2016-11-29 11:38:00 +00:00
Matthew Auld
ddbb271aea
drm/i915: drop the struct_mutex when wedged or trying to reset
...
We grab the struct_mutex in intel_crtc_page_flip, but if we are wedged
or a reset is in progress we bail early but never seem to actually
release the lock.
Fixes: 7f1847ebf4 ("drm/i915: Simplify checking of GPU reset_counter in display pageflips")
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Signed-off-by: Matthew Auld <matthew.auld@intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20161128103648.9235-1-matthew.auld@intel.com
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: <stable@vger.kernel.org > # v4.7+
2016-11-29 09:25:04 +00:00
Chris Wilson
92117f0bce
drm/i915: Move priority bumping for flips earlier
...
David found another issue with priority bumping from mmioflips, where we
are accessing the requests concurrently to them being retired and freed.
Whilst we are skipping the dependency if has been submitted, that is not
sufficient to stop the dependency from disappearing if another thread
retires that request. To prevent we can either employ the struct_mutex (or a
request mutex in the future) to serialise retiring before it is freed.
Alternatively, we need to keep the dependencies alive using RCU whilst
they are being accessed via the DFS.
[ 1746.698111] general protection fault: 0000 [#1 ] PREEMPT SMP
[ 1746.698305] Modules linked in: snd_hda_intel snd_hda_codec snd_hwdep x86_pkg_temp_thermal snd_hda_core coretemp crct10dif_pclmul crc32_pclmul snd_pcm ghash_clmulni_intel mei_me mei i915 e1000e ptp pps_core i2c_hid
[ 1746.698750] CPU: 1 PID: 6716 Comm: kworker/u8:2 Not tainted 4.9.0-rc6-CI-Nightly_816+ #1
[ 1746.698871] Hardware name: GIGABYTE GB-BKi7A-7500/MFLP7AP-00, BIOS F1 07/27/2016
[ 1746.699125] Workqueue: events_unbound intel_mmio_flip_work_func [i915]
[ 1746.699266] task: ffff880260a5e800 task.stack: ffffc90000f6c000
[ 1746.699361] RIP: 0010:[<ffffffffa006595d>] [<ffffffffa006595d>] execlists_schedule+0x8d/0x300 [i915]
[ 1746.699632] RSP: 0018:ffffc90000f6fcd8 EFLAGS: 00010206
[ 1746.699724] RAX: dead0000000000f8 RBX: ffff8801f64b2bf0 RCX: ffff8801f64b2c10
[ 1746.699842] RDX: dead000000000100 RSI: 0000000000000000 RDI: ffff8801f64b0458
[ 1746.699972] RBP: ffffc90000f6fd68 R08: ffff88026488dc00 R09: 0000000000000002
[ 1746.700090] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000400
[ 1746.700195] R13: ffffc90000f6fcf0 R14: ffff88020955aa40 R15: ffff88020955aa68
[ 1746.700307] FS: 0000000000000000(0000) GS:ffff88026dc80000(0000) knlGS:0000000000000000
[ 1746.700435] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1746.700532] CR2: 0000000002a69e90 CR3: 0000000002c07000 CR4: 00000000003406e0
[ 1746.700635] Stack:
[ 1746.700682] ffff880260a5e880 ffffc90000f6fd50 ffffffff810af69a ffffc90000f6fd28
[ 1746.700827] ffff88020955a628 ffff8801e1eaebf0 0000000000000020 0000000000000000
[ 1746.700947] 00000196af1edc96 ffff88025dfa4000 ffff8801f0b030a8 ffffc90000f6fcf0
[ 1746.701071] Call Trace:
[ 1746.701117] [<ffffffff810af69a>] ? dequeue_entity+0x25a/0xb50
[ 1746.701260] [<ffffffffa00516be>] fence_set_priority+0x7e/0x80 [i915]
[ 1746.701406] [<ffffffffa0051a15>] i915_gem_object_wait_priority+0x85/0x160 [i915]
[ 1746.701599] [<ffffffffa008ccd7>] intel_mmio_flip_work_func+0x47/0x2b0 [i915]
[ 1746.701717] [<ffffffff81094c4d>] process_one_work+0x14d/0x470
[ 1746.701809] [<ffffffff81094fb3>] worker_thread+0x43/0x4e0
[ 1746.701888] [<ffffffff81094f70>] ? process_one_work+0x470/0x470
[ 1746.701969] [<ffffffff81094f70>] ? process_one_work+0x470/0x470
[ 1746.702072] [<ffffffff8109a4d5>] kthread+0xc5/0xe0
[ 1746.702152] [<ffffffff81771c59>] ? _raw_spin_unlock_irq+0x9/0x10
[ 1746.702234] [<ffffffff8109a410>] ? kthread_park+0x60/0x60
[ 1746.702318] [<ffffffff81772272>] ret_from_fork+0x22/0x30
[ 1746.702387] Code: 89 42 08 48 8b 45 88 48 89 55 c0 4c 89 6d c8 4c 8d 70 d8 4d 8d 7e 28 4d 39 ef 74 72 49 8b 1e 48 8b 13 48 39 d3 48 8d 42 f8 74 3e <48> 8b 10 8b 52 38 41 39 d4 7e 26 48 8b 50 30 48 8b 78 28 48 8d
[ 1746.702921] RIP [<ffffffffa006595d>] execlists_schedule+0x8d/0x300 [i915]
Nov 25 21:42:54 kbl-gbbki7 kernel: [ 1746.703027] RSP <ffffc90000f6fcd8>
Fixes: 27745e829a ("drm/i915/execlists: Use a local lock for dfs_link access")
Fixes: 9a151987d7 ("drm/i915: Add execution priority boosting for mmioflips")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: David Weinehall <david.weinehall@linux.intel.com >
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/20161128143649.4289-1-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
2016-11-29 09:16:36 +00:00
Ander Conselvan de Oliveira
c39055b072
drm/i915: Pass dev_priv to intel_setup_outputs()
...
Pass dev_priv to intel_setup_outputs() and functions called by it, since
those are all intel i915 specific functions. Also, in the majority of
the functions dev_priv is used more often than dev. In the rare cases
where there are a few calls back into drm core, a local dev variable was
added.
v2: Don't convert dev to &dev_priv->drm in intel_dsi_init. (Ville)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com >
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/1479910904-11005-1-git-send-email-ander.conselvan.de.oliveira@intel.com
2016-11-25 16:43:24 +02:00
Ville Syrjälä
9780aad59c
drm/i915: Simplify error handling in intel_modeset_all_pipes()
...
No need for the extra break statements and whatnot, just return the
error directly. And tighten the scope of the local variables while at
it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/1479141311-11904-4-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch >
2016-11-23 22:21:26 +02:00
Ville Syrjälä
8d96561a0a
drm/i915: Protect dev_priv->atomic_cdclk_freq with all the crtc locks
...
A modeset on one pipe can update dev_priv->atomic_cdclk_freq without
actually touching the hardware, in which case we won't force a modeset
on all the pipes, and thus won't lock any of the other pipes either.
That means a parallel plane update on another pipe could be looking at
a stale dev_priv->atomic_cdcdlk_freq and thus fail to notice when the
plane configuration is invalid, or potentially reject a valid update.
To overcome this we must protect writes to atomic_cdclk_freq with
all the crtc locks, and thus for reads any single crtc lock will
be sufficient protection.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com >
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/1479141311-11904-3-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch >
2016-11-23 22:20:40 +02:00
Ville Syrjälä
e0ca7a6be3
drm/i915: Fix cdclk vs. dev_cdclk mess when not recomputing things
...
When we end up not recomputing the cdclk, we need to populate
intel_state->cdclk with the "atomic_cdclk_freq" instead of the
current cdclk_freq. When no pipes are active, the actual cdclk_freq
may be lower than what the configuration of the planes and
pipes would require from the point of view of the software state.
This fixes bogus WARNS from skl_max_scale() which is trying to check
the plane software state against the cdclk frequency. So any time
it got called during DPMS off for instance, we might have tripped
the warn if the current mode would have required a higher than
minimum cdclk.
v2: Drop the dev_cdclk stuff (Maarten)
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com >
Cc: Mika Kahola <mika.kahola@intel.com >
Cc: bruno.pagani@ens-lyon.org
Cc: Daniel J Blueman <daniel.blueman@gmail.com >
Cc: Paul Bolle <pebolle@tiscali.nl >
Cc: Joseph Yasi <joe.yasi@gmail.com >
Tested-by: Paul Bolle <pebolle@tiscali.nl >
Tested-by: Joseph Yasi <joe.yasi@gmail.com > (v1)
Cc: stable@vger.kernel.org
Fixes: 1a617b7765 ("drm/i915: Keep track of the cdclk as if all crtc's were active.")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98214
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/1479141311-11904-2-git-send-email-ville.syrjala@linux.intel.com
2016-11-23 22:19:22 +02:00
Ville Syrjälä
83c04a62a1
drm/i915: Use enum plane_id in VLV/CHV sprite code
...
Use intel_plane->id to derive the VLV/CHV sprite register offsets
instead of abusing plane->plane which is really meant to for
primary planes only.
v2: Convert assert_sprites_disabled() over as well
v3: Rename the reg macro parameter to 'plane_id' as well (Paulo)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/1479830524-7882-6-git-send-email-ville.syrjala@linux.intel.com
2016-11-23 22:04:24 +02:00
Ville Syrjälä
8e816bb496
drm/i915: Use enum plane_id in SKL plane code
...
Replace the intel_plane->plane and hardcoded 0 usage in the SKL plane
code with intel_plane->id.
This should make the SKL "primary" and "sprite" code virtually
identical, so the next logical step would likely be dropping one
of the copies.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/1479830524-7882-5-git-send-email-ville.syrjala@linux.intel.com
2016-11-23 22:03:55 +02:00
Ville Syrjälä
d97d7b48b6
drm/i915: Add crtc->plane_ids_mask
...
Add a mask of which planes are available for each pipe. This doesn't
quite work for old platforms with dynamic plane<->pipe assignment, but
as we don't support that sort of stuff (yet) we can get away with it.
The main use I have for this is the for_each_plane_id_on_crtc() macro
for iterating over all possible planes on the crtc. I suppose we could
not add the mask, and instead iterate by comparing intel_plane->pipe
but then we'd need a local intel_plane variable which is just
unnecessary clutter in some cases. But I'm not hung up on this, so if
people prefer the other option I could be convinced to use it.
v2: Use BIT() in the iterator macro too (Paulo)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/1479830524-7882-3-git-send-email-ville.syrjala@linux.intel.com
2016-11-23 22:03:17 +02:00
Ville Syrjälä
b14e5848c0
drm/i915: Add per-pipe plane identifier
...
As I told people in [1] we really should not be confusing enum plane
as a per-pipe plane identifier. Looks like that happened nonetheless, so
let's fix it up by splitting the two into two enums.
We'll also want something we just directly pass to various register
offset macros and whatnot on SKL+. So let's make this new thing work for that.
Currently we pass intel_plane->plane for the "sprites" and just a
hardcoded zero for the "primary" planes. We want to get rid of that
hardocoding so that we can share the same code for all planes (apart
from the legacy cursor of course).
[1] https://lists.freedesktop.org/archives/intel-gfx/2015-September/076082.html
Cc: Matt Roper <matthew.d.roper@intel.com >
Cc: Daniel Vetter <daniel@ffwll.ch >
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/1479830524-7882-2-git-send-email-ville.syrjala@linux.intel.com
2016-11-23 22:02:36 +02:00
Chris Wilson
a6a7cc4b7d
drm/i915: Always flush the dirty CPU cache when pinning the scanout
...
Currently we only clflush the scanout if it is in the CPU domain. Also
flush if we have a pending CPU clflush. We also want to treat the
dirtyfb path similar, and flush any pending writes there as well.
v2: Only send the fb flush message if flushing the dirt on flip
v3: Make flush-for-flip and dirtyfb look more alike since they serve
similar roles as end-of-frame marker.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com > #v2
Link: http://patchwork.freedesktop.org/patch/msgid/20161118211747.25197-1-chris@chris-wilson.co.uk
2016-11-18 22:33:22 +00:00
Maarten Lankhorst
50637aa7ff
drm/i915: Enable support for nonblocking modeset
...
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/1478609742-13603-12-git-send-email-maarten.lankhorst@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch > #irc
2016-11-18 14:09:27 +01:00
Tvrtko Ursulin
d806e6828b
drm/i915: Only dump dp_m2_n2 configuration when drrs is used
...
Otherwise it is just an useless empty line.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Suggested-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com >
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com >
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/1479397449-27085-1-git-send-email-tvrtko.ursulin@linux.intel.com
2016-11-18 10:48:27 +00:00
Tvrtko Ursulin
08c4d7fcb3
drm/i915: Introduce enableddisabled helper
...
Similar to existing yesno and onoff and use it throughout the code.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/1479385814-2358-2-git-send-email-tvrtko.ursulin@linux.intel.com
2016-11-17 15:00:36 +00:00
Tvrtko Ursulin
a74f83754d
drm/i915: Only dump possible panel fitter config for the platform
...
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
2016-11-17 15:00:35 +00:00
Tvrtko Ursulin
dd2f616d37
drm/i915: Only dump scaler config where supported
...
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
2016-11-17 15:00:35 +00:00
Tvrtko Ursulin
2c89429e6b
drm/i915: Compact a few pipe config debug lines
...
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
2016-11-17 15:00:35 +00:00
Tvrtko Ursulin
66766e4f83
drm/i915: Don't log pipe config kernel pointer and duplicated pipe name
...
Kernel pointer does not sound like an useful thing to log and
pipe name is already contained in the crtc name.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
2016-11-17 15:00:35 +00:00
Tvrtko Ursulin
a430965756
drm/i915: Dump FDI config only where applicable
...
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
2016-11-17 15:00:35 +00:00
Tvrtko Ursulin
f698233258
drm/i915: Extract intel_link_m_n config printing into a helper
...
And also only dump DP config for crtcs with DP encoders.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
2016-11-17 15:00:35 +00:00
Tvrtko Ursulin
5e963a02b3
drm/i915: Make scaler updates less chatty
...
It looks to me skl_update_scaler will already log interesting
debug messages when the state transitions or there is an error.
In this case it feels we can remove the two unconditional
debug messages which happen immediately before calling
skl_update_scaler. This way we get rid of the sole debug
message when switching virtual terminals for example.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/1479376805-5087-1-git-send-email-tvrtko.ursulin@linux.intel.com
2016-11-17 14:02:56 +00:00
Tvrtko Ursulin
6315b5d33a
drm/i915: dev_priv cleanup in intel_display.c
...
v2: Rebase.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
2016-11-17 13:56:46 +00:00
Tvrtko Ursulin
dd11bc109d
drm/i915: dev_priv cleanup in intel_dp.c
...
And as usual a little bit of cascaded function prototype changes.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
2016-11-17 13:56:39 +00:00
Tvrtko Ursulin
29b74b7f17
drm/i915: dev_priv cleanup in i915_suspend.c
...
And a little bit of function prototype changes.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
2016-11-17 13:56:31 +00:00
Tvrtko Ursulin
5f56d5f97e
drm/i915: dev_priv cleanup in i915_gpu_error.c
...
And a little bit of cascaded function prototype changes.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
2016-11-17 13:56:25 +00:00
Daniel Vetter
3975797f3e
Merge remote-tracking branch 'airlied/drm-next' into drm-intel-next-queued
...
Tvrtko needs
commit b3c11ac267
Author: Eric Engestrom <eric@engestrom.ch >
Date: Sat Nov 12 01:12:56 2016 +0000
drm: move allocation out of drm_get_format_name()
to be able to apply his patches without conflicts.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com >
2016-11-17 14:32:57 +01:00
Ville Syrjälä
bae781b259
drm: Nuke modifier[1-3]
...
It has been suggested that having per-plane modifiers is making life
more difficult for userspace, so let's just retire modifier[1-3] and
use modifier[0] to apply to the entire framebuffer.
Obviosuly this means that if individual planes need different tiling
layouts and whatnot we will need a new modifier for each combination
of planes with different tiling layouts.
For a bit of extra backwards compatilbilty the kernel will allow
non-zero modifier[1+] but it require that they will match modifier[0].
This in case there's existing userspace out there that sets
modifier[1+] to something non-zero with planar formats.
Mostly a cocci job, with a bit of manual stuff mixed in.
@@
struct drm_framebuffer *fb;
expression E;
@@
- fb->modifier[E]
+ fb->modifier
@@
struct drm_framebuffer fb;
expression E;
@@
- fb.modifier[E]
+ fb.modifier
Cc: Kristian Høgsberg <hoegsberg@gmail.com >
Cc: Ben Widawsky <benjamin.widawsky@intel.com >
Cc: Rob Clark <robdclark@gmail.com >
Cc: Daniel Vetter <daniel.vetter@ffwll.ch >
Cc: Tomeu Vizoso <tomeu@tomeuvizoso.net >
Cc: dczaplejewicz@collabora.co.uk
Suggested-by: Kristian Høgsberg <hoegsberg@gmail.com >
Acked-by: Ben Widawsky <ben@bwidawsk.net >
Acked-by: Daniel Stone <daniels@collabora.com >
Acked-by: Rob Clark <robdclark@gmail.com >
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch >
Link: http://patchwork.freedesktop.org/patch/msgid/1479295996-26246-1-git-send-email-ville.syrjala@linux.intel.com
2016-11-17 11:58:09 +01:00
Maarten Lankhorst
5eff503b9d
drm/i915/gen9+: Kill off hw_ddb from intel_crtc.
...
dev_priv->hw_ddb is only used by skl_update_crtcs, but the ddb
allocation for each pipe is calculated in crtc_state.
We can rid of the global member by looking at crtc_state.
Do this by saving all active old ddb allocations from the old crtc_state
in an array, and then point them to the new allocation every time we update
a crtc.
This will allow us to keep track of the intermediate ddb allocations,
which is what hw_ddb was previously used for. With hw_ddb gone all
SKL-style watermark values are properly maintained only in crtc_state.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com >
Link: http://patchwork.freedesktop.org/patch/msgid/1478609742-13603-5-git-send-email-maarten.lankhorst@linux.intel.com
[mlankhorst: Reword commit message.]
Reviewed-by: Matt Roper <matthew.d.roper@intel.com >
2016-11-15 13:13:47 +01:00