Paulo Zanoni [Tue, 13 Dec 2016 20:57:44 +0000 (18:57 -0200)]
drm/i915: disable PSR by default on HSW/BDW
We've been ignoring the poor bugzilla reporters that say PSR causes
system lockups and all other sorts of problems. The earliest bug
report is from April, so I think we can use the "revert the offending
commit if no fixes are presented within 8 months" rule here.
Fixes: 9b58e352b463 ("drm/i915: Enable PSR by default on Haswell and Broadwell.")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97602
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97515
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96736
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96704
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96569
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95176
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94985 Cc: <stable@vger.kernel.org> # v4.6+ Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Jim Bride <jim.bride@linux.intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1481662664-18986-1-git-send-email-paulo.r.zanoni@intel.com
(cherry picked from commit 2ee7dc497e348eecbb82adbb1ea9e9a7e29fe921) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Mika Kuoppala [Wed, 14 Dec 2016 12:26:20 +0000 (14:26 +0200)]
drm/i915: Fix setting of boost freq tunable
For limiting the max frequency of gpu, the max freq tunable
is not enough to hard limit the max gap. We now have also per
client boost max freq. When this tunable was introduced,
it was mistakenly made read only. Allow user to gain control by
setting it writable.
Fixes: 29ecd78d3b79 ("drm/i915: Define a separate variable and control for RPS waitboost frequency") Cc: <stable@vger.kernel.org> # v4.9+ Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1481718380-9170-1-git-send-email-mika.kuoppala@intel.com
(cherry picked from commit 73a798711314b54cbd4fe224e24db92c306a8d8c) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Daniel Vetter [Tue, 13 Dec 2016 19:54:14 +0000 (20:54 +0100)]
drm/i915: tune down the fast link training vs boot fail
It's been unfixed since a while and no one is immediately working on
this. And we have the FIXME already. And now also a task in the DP
team's backlog.
Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: stable@vger.kernel.org Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
References: https://lists.freedesktop.org/archives/intel-gfx/2016-July/101951.html Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Adjust comment per Ville's feedback.] Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161213195414.28923-1-daniel.vetter@ffwll.ch
(cherry picked from commit 2dd85aeb5bc99e3763dd192cdb95ff405a102c8a) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Chris Wilson [Wed, 7 Dec 2016 13:34:11 +0000 (13:34 +0000)]
drm/i915: Reorder phys backing storage release
In commit a4f5ea64f0a8 ("drm/i915: Refactor object page API"), I
reordered the object->pages teardown to be more friendly wrt to a
separate obj->mm.lock. However, I overlooked the phys object and left it
with a dangling use-after-free of its phys_handle. Move the allocation
of the phys handle to get_pages and it release to put_pages to prevent
the invalid access and to improve symmetry.
v2: Add commentary about always aligning to page size.
Testcase: igt/drv_selftest/objects Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: a4f5ea64f0a8 ("drm/i915: Refactor object page API") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161207133411.8028-1-chris@chris-wilson.co.uk
(cherry picked from commit dbb4351bab0a8440f6b02895c142bce6c30b7097) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Imre Deak [Mon, 5 Dec 2016 16:27:38 +0000 (18:27 +0200)]
drm/i915/gen9: Fix PCODE polling during SAGV disabling
According to the previous patch, it's possible atm that we call
intel_do_sagv_disable() only once during the 1ms period and time out if
that call fails. As opposed to this the spec says that we need to keep
retrying this request for a 1ms duration, so let's do this similarly to
the CDCLK change notification request.
v4-5:
- Rebased on the reply_mask, reply change.
v6:
- Remove w/s change. (Lyude)
- Rebased on the timeout_base argument change.
drm/i915: Wait up to 3ms for the pcu to ack the cdclk change request on SKL
increased the timeout to match the spec, but we still see a timeout on
at least one SKL. A CDCLK change request following the failed one will
succeed nevertheless.
I could reproduce this problem easily by running kms_pipe_crc_basic in a
loop. In all failure cases _wait_for() was pre-empted for >3ms and so in
the worst case - when the pre-emption happened right after calculating
timeout__ in _wait_for() - we called skl_cdclk_wait_for_pcu_ready() only
once which failed and so _wait_for() timed out. As opposed to this the
spec says to keep retrying the request for at most a 3ms period.
To fix this send the first request explicitly to guarantee that there is
3ms between the first and last request. Though this matches the spec, I
noticed that in rare cases this can still time out if we sent only a few
requests (in the worst case 2) _and_ PCODE is busy for some reason even
after a previous request and a 3ms delay. To work around this retry the
polling with pre-emption disabled to maximize the number of requests.
Also increase the timeout to 10ms to account for interrupts that could
reduce the number of requests. With this change I couldn't trigger
the problem.
v2:
- Use 1ms poll period instead of 10us. (Chris)
v3:
- Poll with pre-emption disabled to increase the number of request
attempts. (Ville, Chris)
- Factor out a helper to poll, it's also needed by the next patch.
v4:
- Pass reply_mask, reply to skl_pcode_request(), instead of assuming the
reply is generic. (Ville)
v5:
- List the request specific timeout values as code comment. (Ville)
v6:
- Try the poll first with preemption enabled.
- Add code comment about first request being queued by PCODE. (Art)
- Add timeout_base_ms argument. (Ville)
v7:
- Clarify code comment about first queued request. (Chris)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Art Runyan <arthur.j.runyan@intel.com> Cc: <stable@vger.kernel.org> # v4.2- : 3b2c171 : drm/i915: Wait up to 3ms Cc: <stable@vger.kernel.org> # v4.2- Fixes: 5d96d8afcfbb ("drm/i915/skl: Deinit/init the display at suspend/resume")
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=97929
Testcase: igt/kms_pipe_crc_basic/suspend-read-crc-pipe-B Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1480955258-26311-1-git-send-email-imre.deak@intel.com
(cherry picked from commit a0b8a1fe34430c3a82258e8cb45f5968bdf31afd) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Hans de Goede [Thu, 1 Dec 2016 20:29:09 +0000 (21:29 +0100)]
drm/i915/dsi: Fix chv_exec_gpio disabling the GPIOs it is setting
Set the CHV_GPIO_GPIOEN bit when updating GPIOs from chv_exec_gpio.
Fixes: a0a6d4ffd2ad ("drm/i915/dsi: add support for gpio elements on CHV") Cc: stable@vger.kernel.org Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161201202925.12220-3-hdegoede@redhat.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
(cherry picked from commit b2b45fcd921e864a5e9bbc7aa55dee96d5e11c06) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Hans de Goede [Fri, 2 Dec 2016 15:01:28 +0000 (16:01 +0100)]
drm/i915/dsi: Fix swapping of MIPI_SEQ_DEASSERT_RESET / MIPI_SEQ_ASSERT_RESET
Looking at the ADF code from the Android kernel sources for a
cherrytrail tablet I noticed that it is calling the
MIPI_SEQ_ASSERT_RESET sequence from the panel prepare hook.
Until commit b1cb1bd29189 ("drm/i915/dsi: update reset and power sequences
in panel prepare/unprepare hooks") the mainline i915 code was doing the
same. That commits effectively swaps the calling of MIPI_SEQ_ASSERT_RESET /
MIPI_SEQ_DEASSERT_RESET.
Looking at the naming of the sequences that is the right thing to do,
but the problem is, that the old mainline code and the ADF code was
actually calling the right sequence (tested on a cube iwork8 air tablet),
and the swapping of the calling breaks things.
This breakage was likely not noticed in testing because on cherrytrail,
currently chv_exec_gpio ends up disabling the gpio pins rather then
setting them (this is fixed in the next patch in this patch-set).
This commit fixes the swapping by fixing MIPI_SEQ_ASSERT/DEASSERT_RESET's
places in the enum defining them, so that their (new) names match their
actual use.
Changes in v2:
-Add a comment to the enum explaining that the assert/reassert names
are swapped in the spec
Fixes: b1cb1bd29189 ("drm/i915/dsi: update reset and power sequences...") Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161202150128.29871-1-hdegoede@redhat.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
(cherry picked from commit 2b8208ac93be2783edc627fc02d9ca50cc479923) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Hans de Goede [Fri, 2 Dec 2016 14:29:04 +0000 (15:29 +0100)]
drm/i915/dsi: Do not clear DPOUNIT_CLOCK_GATE_DISABLE from vlv_init_display_clock_gating
On my Cherrytrail CUBE iwork8 Air tablet PIPE-A would get stuck on loading
i915 at boot 1 out of every 3 boots, resulting in a non functional LCD.
Once the i915 driver has successfully loaded, the panel can be disabled /
enabled without hitting this issue.
The getting stuck is caused by vlv_init_display_clock_gating() clearing
the DPOUNIT_CLOCK_GATE_DISABLE bit in DSPCLK_GATE_D when called from
chv_pipe_power_well_ops.enable() on driver load, while a pipe is enabled
driving the DSI LCD by the BIOS.
Clearing this bit while DSI is in use is a known issue and
intel_dsi_pre_enable() / intel_dsi_post_disable() already set / clear it
as appropriate.
This commit modifies vlv_init_display_clock_gating() to leave the
DPOUNIT_CLOCK_GATE_DISABLE bit alone fixing the pipe getting stuck.
Changes in v2:
-Replace PIPE-A with "a pipe" or "the pipe" in the commit msg and
comment
Matthew Auld [Mon, 28 Nov 2016 10:36:48 +0000 (10:36 +0000)]
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: 7f1847ebf48b ("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 ddbb271aea87fc6004d3c8bcdb0710e980c7ec85) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
(cherry picked from commit e411072d5740a49cdc9d0713798c30440757e451) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Chris Wilson [Mon, 28 Nov 2016 14:36:48 +0000 (14:36 +0000)]
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.
Fixes: 27745e829a5c ("drm/i915/execlists: Use a local lock for dfs_link access") Fixes: 9a151987d709 ("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 92117f0bce64268b841261774e45462cc7ff80af) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Chris Wilson [Fri, 25 Nov 2016 13:17:17 +0000 (13:17 +0000)]
drm/i915: Hold a reference on the request for its fence chain
Currently, we have an active reference for the request until it is
retired. Though it cannot be retired before it has been executed by
hardware, the request may be completed before we have finished
processing the execute fence, i.e. we may continue to process that fence
as we free the request.
Libin Yang [Fri, 11 Nov 2016 08:46:28 +0000 (16:46 +0800)]
drm/i915/audio: fix hdmi audio noise issue
Some monitors will have noise or even no sound after
applying the patch 6014ac12.
In patch 6014ac12, it will reset the cts value to 0 for HDMI.
However, we need to disable Enable CTS or M Prog bit. This is
the initial setting after HW reset.
Chris Wilson [Thu, 24 Nov 2016 09:47:52 +0000 (09:47 +0000)]
drm/i915/debugfs: Increment return value of gt.next_seqno
The i915_next_seqno read value is to be the next seqno used by the
kernel. However, in the conversion to atomics ops for gt.next_seqno, in
commit 28176ef4cfa5 ("drm/i915: Reserve space in the global seqno during
request allocation"), this was changed from a post-increment to a
pre-increment. This increment was missed from the value reported by
debugfs, so in effect it was reporting the current seqno (last
assigned), not the next seqno.
Fixes: 28176ef4cfa5 ("drm/i915: Reserve space in the global seqno during request allocation")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81209 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161124094752.19129-1-chris@chris-wilson.co.uk Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
(cherry picked from commit 9607ae79710afb453173b90d5bf564788a6e09b1) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Chris Wilson [Thu, 24 Nov 2016 09:34:01 +0000 (09:34 +0000)]
drm/i915/debugfs: Drop i915_hws_info
i915_hws_info() has not been kept upto date (missing new engines) and so
I consider it to be unused. HWS is included in the error state, which
would be an avenue to retrieving it if required in future (possibly via
i915_engine_info). As it is currently oopsing with an rpm testcase, just
remove it.
Fixes: 3b3f1650b1ca ("drm/i915: Allocate intel_engine_cs structure only for the enabled engines")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98838 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/20161124093401.18852-1-chris@chris-wilson.co.uk Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
(cherry picked from commit 30576a2c462d9658508c3de67601aa565f973064) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Ville Syrjälä [Tue, 29 Nov 2016 14:13:57 +0000 (16:13 +0200)]
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+: 14676ec6b1a6 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: 14676ec6b1a6 ("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 6a259b1f8a9e99b1ed114f8bf8b0cfccee130e54) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Ville Syrjälä [Mon, 14 Nov 2016 16:35:09 +0000 (18:35 +0200)]
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: 1a617b77658e ("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 e0ca7a6be38ce603d26df5707c22e53870a623e0) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Ville Syrjälä [Tue, 22 Nov 2016 20:21:53 +0000 (22:21 +0200)]
drm/i915: Make skl_write_{plane,cursor}_wm() static
Someone forgot to make skl_write_{plane,cursor}_wm() static when
removing the prototypes from the header. Sparse isn't pleased.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Lyude <cpaul@redhat.com> Cc: Matt Roper <matthew.d.roper@intel.com> Fixes: e62929b3f628 ("drm/i915/gen9+: Program watermarks as a separate step during evasion, v3.") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1479846113-24745-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Lyude <lyude@redhat.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
(cherry picked from commit d9348dec902ff36e0f1b25ccf1f4be25fc1ac409) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Chris Wilson [Tue, 22 Nov 2016 14:41:20 +0000 (14:41 +0000)]
drm/i915: Complete requests in nop_submit_request
Since the submit/execute split in commit d55ac5bf97c6 ("drm/i915: Defer
transfer onto execution timeline to actual hw submission") the
global seqno advance was deferred until the submit_request callback.
After wedging the GPU, we were installing a nop_submit_request handler
(to avoid waking up the dead hw) but I had missed converting this over
to the new scheme. Under the new scheme, we have to explicitly call
i915_gem_submit_request() from the submit_request handler to mark the
request as on the hardware. If we don't the request is always pending,
and any waiter will continue to wait indefinitely and hangcheck will not
be able to resolve the lockup.
References: https://bugs.freedesktop.org/show_bug.cgi?id=98748
Testcase: igt/gem_eio/in-flight Fixes: d55ac5bf97c6 ("drm/i915: Defer transfer onto execution timeline to actual hw submission") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161122144121.7379-3-chris@chris-wilson.co.uk
(cherry picked from commit 3dcf93f7f23a61e867a5ccadaf651cb2d29229fd) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Zhenyu Wang [Thu, 24 Nov 2016 07:55:49 +0000 (15:55 +0800)]
drm/i915/gvt: fix lock not released bug for dispatch_workload() err path
Need to be careful to release struct_mutext when request alloc
failed and take consistent handling for return status as with
normal go out path. Ensure to check correct workload request in
complete path too.
v2: Add Fixes note
Fixes: 90d27a1b180e ("drm/i915/gvt: fix deadlock in workload_thread") Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Cc: Dan Carpenter <dan.carpenter@oracle.com> Cc: Pei Zhang <pei.zhang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Chris Wilson [Fri, 18 Nov 2016 21:17:47 +0000 (21:17 +0000)]
drm/i915: Skip final clflush if LLC is coherent
If the LLC is coherent with the object, we do not need to worry about
whether main memory and cache mismatch when we hand the object back to
the system.
Chris Wilson [Fri, 18 Nov 2016 21:17:46 +0000 (21:17 +0000)]
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.
Let's add a couple more BUG_ONs before this to ascertain that the request
did make it to hardware. The impossible part of this stacktrace is that
request must have been considered completed by the i915_request_wait()
before we tried to retire it.
Matthew Auld [Fri, 18 Nov 2016 17:02:16 +0000 (17:02 +0000)]
drm/i915: i915_pages_create_for_stolen should return err ptr
When gathering the pages from our backing storage we expect get_pages()
to either give us our sg_table or an err ptr. However when gathering our
fake pages for stolen memory we may return NULL in the event of a
failure. To prevent any funny business we should therefore return the
proper err ptr value.
Chris Wilson [Tue, 15 Nov 2016 16:46:20 +0000 (16:46 +0000)]
drm/i915: Be more careful to drop the GT wakeref
Since we can retire requests from multiple paths, we cannot assume that
i915_gem_retire_requests() is the sole path on which we can transition
to gt.active_requests == 0. A consequence of this is that we would skip
the function if we had already retired all the requests and not
scheduled the idle worker.
This is fallout from changing the routine from considering active_engines
(for which it was the only consumer) to active_requests.
v2: Move kicking the idle working to i915_gem_request_retire() otherwise
we could postpone the idle callback everytime we called retire_requests
even though we did no work.
v3: We only need to move the idle work kicking!
v4: Drop the BUG_ON(!awake) as we may be called from the shrinker in the
middle of constructing a request before we have marked the device awake.
v5: Add a BUG_ON() for active_requests underflow upon retirement (Joonas)
Chris Wilson [Wed, 16 Nov 2016 19:07:04 +0000 (19:07 +0000)]
drm/i915: Move frontbuffer CS write tracking from ggtt vma to object
I tried to avoid having to track the write for every VMA by only
tracking writes to the ggtt. However, for the purposes of frontbuffer
tracking this is insufficient as we need to invalidate around writes not
just to the the ggtt but all aliased ppgtt views of the framebuffer. By
moving the critical section to the object and only doing so for
framebuffer writes we can reduce the tracking even further by only
watching framebuffers and not vma.
Matthew Auld [Thu, 17 Nov 2016 21:04:10 +0000 (21:04 +0000)]
drm/i915: add i915_address_space_fini
We already have an i915_address_space_init, so for symmetry we should
also have a _fini, plus we already open code it twice. This then also
fixes a bug where we leak the timeline for the ggtt vm.
v2: don't forget about the struct_mutex for the ggtt path.
Chris Wilson [Thu, 17 Nov 2016 15:58:46 +0000 (15:58 +0000)]
drm/i915: Add a few more sanity checks for stolen handling
We should never be called via obj->ops->release() on anything other than
a fully formed stolen object, so raise that to an assert. In the process
tidy up a comment and variable no longer used outside of a conditional
BUG.
Chris Wilson [Wed, 16 Nov 2016 12:26:18 +0000 (12:26 +0000)]
drm/i915: Remove stolen object spam
We don't spam the debug when we create a normal object, nor when we
allocate their pages. Yet we do for stolen objects, and since these are
quite frequently used (at least once per context), the resulting spam
floods the dmesg in CI.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Chris Wilson [Wed, 9 Nov 2016 10:45:07 +0000 (10:45 +0000)]
drm/i915: Demote i915_gem_open() debugging from DRIVER to USER
We use DRM_DEBUG() when reporting on user actions, to try and keep
intentional errors out of the CI dmesg. Demote the debug from
i915_gem_open() similarly so that it is only apparent with drm.debug & 1
like its brethren.
Tvrtko Ursulin [Thu, 17 Nov 2016 10:00:05 +0000 (10:00 +0000)]
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.
Daniel Vetter [Thu, 17 Nov 2016 13:46:39 +0000 (14:46 +0100)]
Merge tag 'gvt-next-2016-11-17' of https://github.com/01org/gvt-linux into drm-intel-next-queued
From Zhenyu Wang:
gvt-next-2016-11-17
- Fix lock order issue found in guest stress test
- Fix several MMIO handlers to correct behavior
- Fix crash for vgpu execlist reset and memleak
- Fix a possible conflict for unresolved vfio mdev dependency
- other misc fixes
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Tvrtko Ursulin [Thu, 17 Nov 2016 09:02:43 +0000 (09:02 +0000)]
drm/i915: Fix gen9 forcewake range table
Commit 0dd356bb6ff5 ("drm/i915: Eliminate Gen9 special case")
accidentaly dropped a MMIO range between 0xc000 to 0xcfff out
of the blitter forcewake domain. Fix it.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: 0dd356bb6ff5 ("drm/i915: Eliminate Gen9 special case") Reported-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1479373363-16528-1-git-send-email-tvrtko.ursulin@linux.intel.com
drm/i915: set DIDL using the ACPI video output device _ADR method return.
which went out of its way to cater to a specific BIOS, setting up DIDL
based on _ADR method. Perhaps that approach worked on that specific
machine, but on the machines I checked the _ADR method invents the
device identifiers out of thin air if DIDL has not been set. The source
for _ADR is also supposed to be the DIDL set by the driver, not the
other way around.
With this, we'll also limit the number of outputs to what the driver
actually has.
A side effect of this change is that the DIDL, and by proxy CADL, will
be initialized in the order of the connector list. That, in turn, has
internal panels in front, ensuring they're included in the DIDL and CADL
lists. Hopefully this ensures the BIOS does not block backlight hotkey
events, thinking the internal panel is off.
v2: do not set ACPI_DEVICE_ID_SCHEME in the device id (Peter Wu)
v3: Rebase
Cc: Peter Wu <peter@lekensteyn.nl> Cc: Rainer Koenig <Rainer.Koenig@ts.fujitsu.com> Cc: Jan-Marek Glogowski <glogow@fbihome.de> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Marcos Paulo de Souza <marcos.souza.org@gmail.com> Cc: Paolo Stivanin <paolostivanin@fastmail.fm> Tested-by: Rainer Koenig <Rainer.Koenig@ts.fujitsu.com> Tested-by: Paolo Stivanin <paolostivanin@fastmail.fm> Tested-by: Marcos Paulo de Souza <marcos.souza.org@gmail.com> Reviewed-and-tested-by: Peter Wu <peter@lekensteyn.nl> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/9660d29cf310c17bbf4d58c0e09d5b047446e2d5.1479295490.git.jani.nikula@intel.com
Min He [Wed, 16 Nov 2016 14:05:04 +0000 (22:05 +0800)]
drm/i915: fix the dequeue logic for single_port_submission context
For a single_port_submission context, GVT expects that it can only be
submitted to port 0, and there shouldn't be any other context in port 1
at the same time. This is required by GVT-g context to have an opportunity
to save/restore some non-hw context render registers.
This patch is to workaround GVT-g.
v2: optimized code by following Chris's advice, and added more comments to
explain the patch.
v3: followed the coding style.
Instead of partially depending on vfio pin/unpin pages interface if
mdev is available, which would result in failure if vfio is not
on. But replace with a wrapper which need to be fixed till mdev
support got fully merged.
Cc: Jike Song <jike.song@intel.com> Cc: Xiaoguang Chen <xiaoguang.chen@intel.com> Reviewed-by: Xiaoguang Chen <Xiaoguang.chen@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Dave Airlie [Wed, 16 Nov 2016 22:02:46 +0000 (08:02 +1000)]
Merge tag 'drm-misc-next-2016-11-16' of git://anongit.freedesktop.org/git/drm-misc into drm-next
Another pile of misc:
- Explicit fencing for atomic! Big thanks to Gustavo, Sean, Rob 3x, Brian
and anyone else I've forgotten to make this happen.
- roll out fbdev helper ops to drivers (Stefan Christ)
- last bits of drm_crtc split-up&kerneldoc
- some drm_irq.c crtc functions cleanup
- prepare_fb helper for cma, works correctly with explicit fencing (Marek
Vasut)
- misc small patches all over
* tag 'drm-misc-next-2016-11-16' of git://anongit.freedesktop.org/git/drm-misc: (51 commits)
drm/fence: add out-fences support
drm/fence: add fence timeline to drm_crtc
drm/fence: add in-fences support
drm/bridge: analogix_dp: return error if transfer none byte
drm: drm_irq.h header cleanup
drm/irq: Unexport drm_vblank_on/off
drm/irq: Unexport drm_vblank_count
drm/irq: Make drm_vblank_pre/post_modeset internal
drm/nouveau: Use drm_crtc_vblank_off/on
drm/amdgpu: Use drm_crtc_vblank_on/off for dce6
drm/color: document NULL values and default settings better
drm: Drop externs from drm_crtc.h
drm: Move tile group code into drm_connector.c
drm: Extract drm_mode_config.[hc]
Revert "drm: Add aspect ratio parsing in DRM layer"
Revert "drm: Add and handle new aspect ratios in DRM layer"
drm/print: Move kerneldoc next to definition
drm: Consolidate dumb buffer docs
drm: Clean up kerneldoc for struct drm_driver
drm: Extract drm_drv.h
...
Jonas Pfeil [Mon, 7 Nov 2016 23:18:39 +0000 (00:18 +0100)]
drm/vc4: Add fragment shader threading support
FS threading brings performance improvements of 0-20% in glmark2.
The validation code checks for thread switch signals and ensures that
the registers of the other thread are not touched, and that our clamps
are not live across thread switches. It also checks that the
threading and branching instructions do not interfere.
(Original patch by Jonas, changes by anholt for style cleanup,
removing validation the kernel doesn't need to do, and adding the flag
for userspace).
v2: Minor style fixes from checkpatch.
Signed-off-by: Jonas Pfeil <pfeiljonas@gmx.de> Signed-off-by: Eric Anholt <eric@anholt.net>
Chris Wilson [Wed, 16 Nov 2016 15:27:21 +0000 (15:27 +0000)]
drm/i915/execlists: Use a local lock for dfs_link access
Avoid requiring struct_mutex for exclusive access to the temporary
dfs_link inside the i915_dependency as not all callers may want to touch
struct_mutex. So rather than force them to take a highly contended
lock, introduce a local lock for the execlists schedule operation.
Reported-by: David Weinehall <david.weinehall@linux.intel.com> Fixes: 9a151987d709 ("drm/i915: Add execution priority boosting for mmioflips") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: David Weinehall <david.weinehall@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161116152721.11053-1-chris@chris-wilson.co.uk Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Gustavo Padovan [Wed, 16 Nov 2016 13:00:21 +0000 (22:00 +0900)]
drm/fence: add out-fences support
Support DRM out-fences by creating a sync_file with a fence for each CRTC
that sets the OUT_FENCE_PTR property.
We use the out_fence pointer received in the OUT_FENCE_PTR prop to send
the sync_file fd back to userspace.
The sync_file and fd are allocated/created before commit, but the
fd_install operation only happens after we know that commit succeed.
v2: Comment by Rob Clark:
- Squash commit that adds DRM_MODE_ATOMIC_OUT_FENCE flag here.
Comment by Daniel Vetter:
- Add clean up code for out_fences
v3: Comments by Daniel Vetter:
- create DRM_MODE_ATOMIC_EVENT_MASK
- userspace should fill out_fences_ptr with the crtc_ids for which
it wants fences back.
v4: Create OUT_FENCE_PTR properties and remove old approach.
v5: Comments by Brian Starkey:
- Remove extra fence_get() in atomic_ioctl()
- Check ret before iterating on the crtc_state
- check ret before fd_install
- set fence_state to NULL at the beginning
- check fence_state->out_fence_ptr before put_user()
- change order of fput() and put_unused_fd() on failure
- Add access_ok() check to the out_fence_ptr received
- Rebase after fence -> dma_fence rename
- Store out_fence_ptr in the drm_atomic_state
- Split crtc_setup_out_fence()
- return -1 as out_fence with TEST_ONLY flag
v6: Comments by Daniel Vetter
- Add prepare/unprepare_crtc_signaling()
- move struct drm_out_fence_state to drm_atomic.c
- mark get_crtc_fence() as static
Comments by Brian Starkey
- proper set fence_ptr fence_state array
- isolate fence_idx increment
- improve error handling
v7: Comments by Daniel Vetter
- remove prefix from internal functions
- make out_fence_ptr an s64 pointer
- degrade DRM_INFO to DRM_DEBUG_ATOMIC when put_user fail
- fix doc issues
- filter out OUT_FENCE_PTR == NULL and do not fail in this case
- add complete_crtc_signalling()
- krealloc fence_state on demand
Comment by Brian Starkey
- remove unused crtc_state arg from get_out_fence()
v8: Comment by Brian Starkey
- cancel events before check for !fence_state
- convert a few lefovers u64 types for out_fence_ptr
- fix memleak by assign fence_state earlier after realloc
- proper accout num_fences in case of error
v9: Comment by Brian Starkey
- memset last position of fence_state after krealloc
Comments by Sean Paul
- pass install_fds in complete_crtc_signaling() instead of ret
- put_user(-1, fence_ptr) when decoding props
v10: Comment by Brian Starkey
- remove unneeded num_fences increment on error path
- kfree fence_state after installing fences fd
v11: rebase against latest drm-misc
v12: rebase again against latest drm-misc
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Reviewed-by: Brian Starkey <brian.starkey@arm.com> (v10) Reviewed-by: Sean Paul <seanpaul@chromium.org> Tested-by: Robert Foss <robert.foss@collabora.com> (v10)
[danvet: Appease checkpatch.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1479301221-13056-1-git-send-email-gustavo@padovan.org
Gustavo Padovan [Tue, 15 Nov 2016 14:37:08 +0000 (23:37 +0900)]
drm/fence: add fence timeline to drm_crtc
Create one timeline context for each CRTC to be able to handle out-fences
and signal them. It adds a few members to struct drm_crtc: fence_context,
where we store the context we get from fence_context_alloc(), the
fence seqno and the fence lock, that we pass in fence_init() to be
used by the fence.
v2: Comment by Daniel Stone:
- add BUG_ON() to fence_to_crtc() macro
v3: Comment by Ville Syrjälä
- Use more meaningful name as crtc timeline name
v4: Comments by Brian Starkey
- Use even more meaninful name for the crtc timeline
- add doc for timeline_name
Comment by Daniel Vetter
- use in-line style for comments
- rebase after fence -> dma_fence rename
v5: Comment by Daniel Vetter
- Add doc for drm_crtc_fence_ops
v6: Comment by Chris Wilson
- Move fence_to_crtc to drm_crtc.c
- Move export of drm_crtc_fence_ops to drm_crtc_internal.h
Praveen Paneri [Tue, 15 Nov 2016 17:19:20 +0000 (22:49 +0530)]
drm/i915/bxt: Broxton decoupled MMIO
Decoupled MMIO is an alternative way to access forcewake domain
registers, which requires less cycles for a single read/write and
avoids frequent software forcewake.
This certainly gives advantage over the forcewake as this new
mechanism “decouples” CPU cycles and allow them to complete even
when GT is in a CPD (frequency change) or C6 state.
This can co-exist with forcewake and we will continue to use forcewake
as appropriate. E.g. 64-bit register writes to avoid writing 2 dwords
separately and land into funny situations.
v2:
- Moved platform check out of the function and got rid of duplicate
functions to find out decoupled power domain (Chris)
- Added a check for forcewake already held and skipped decoupled
access (Chris)
- Skipped writing 64 bit registers through decoupled MMIO (Chris)
v3:
- Improved commit message with more info on decoupled mmio (Tvrtko)
- Changed decoupled operation to enum and used u32 instead of
uint_32 data type for register offset (Tvrtko)
- Moved HAS_DECOUPLED_MMIO to device info (Tvrtko)
- Added lookup table for converting fw_engine to pd_engine (Tvrtko)
- Improved __gen9_decoupled_read and __gen9_decoupled_write
routines (Tvrtko)
v4:
- Fixed alignment and variable names (Chris)
- Write GEN9_DECOUPLED_REG0_DW1 register in just one go (Zhe Wang)
v5:
- Changed HAS_DECOUPLED_MMIO() argument name to dev_priv (Tvrtko)
- Sanitize info->had_decoupled_mmio at init (Chris)
Gustavo Padovan [Tue, 15 Nov 2016 13:06:39 +0000 (22:06 +0900)]
drm/fence: add in-fences support
There is now a new property called IN_FENCE_FD attached to every plane
state that receives sync_file fds from userspace via the atomic commit
IOCTL.
The fd is then translated to a fence (that may be a fence_array
subclass or just a normal fence) and then used by DRM to fence_wait() for
all fences in the sync_file to signal. So it only commits when all
framebuffers are ready to scanout.
v2: Comments by Daniel Vetter:
- remove set state->fence = NULL in destroy phase
- accept fence -1 as valid and just return 0
- do not call fence_get() - sync_file_fences_get() already calls it
- fence_put() if state->fence is already set, in case userspace
set the property more than once.
v3: WARN_ON if fence is set but state has no FB
v4: Comment from Maarten Lankhorst
- allow set fence with no related fb
v5: rename FENCE_FD to IN_FENCE_FD
v6: Comments by Daniel Vetter:
- rename plane_state->in_fence back to "fence"
- re-introduce WARN_ON if fence set but no fb
- rebase after fence -> dma_fence rename
v7: Comments by Brian Starkey
- set state->fence to NULL when duplicating the state
- fail if IN_FENCE_FD was already set
v8: rebase against latest drm-misc
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Reviewed-by: Brian Starkey <brian.starkey@arm.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Tested-by: Robert Foss <robert.foss@collabora.com>
[danvet: Rebase onto extracted drm_mode_config.[hc].] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Jianqun Xu [Wed, 16 Nov 2016 00:13:39 +0000 (08:13 +0800)]
drm/bridge: analogix_dp: return error if transfer none byte
Reference from drm_dp_aux description (about transfer):
Upon success, the implementation should return the number of payload bytes
that were transferred, or a negative error-code on failure. Helpers
propagate errors from the .transfer() function, with the exception of
the -EBUSY error, which causes a transaction to be retried. On a short,
helpers will return -EPROTO to make it simpler to check for failure.
The analogix_dp_transfer will return num_transferred, but if there is none
byte been transferred, the return value will be 0, which means success, we
should return error-code if transfer none byte.
for (retry = 0; retry < 32; retry++) {
err = aux->transfer(aux, &msg);
if (err < 0) {
if (err == -EBUSY)
continue;
Pei Zhang [Wed, 16 Nov 2016 11:05:50 +0000 (19:05 +0800)]
drm/i915/gvt: check workload empty before real scan
This patch will fix warning log print during command scan caused by
empty workload (ring head equals tail). This patch avoid going into
real scan process if workload is empty. It's guest's responsibility
to make sure if an empty workload is proper to submit to HW.
[v2] modify the patch description. It's a fix, not a w/a.
Signed-off-by: Pei Zhang <pei.zhang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Dave Airlie [Tue, 15 Nov 2016 23:39:55 +0000 (09:39 +1000)]
Merge tag 'sunxi-drm-for-4.10' of https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux into drm-next
sun4i-drm changes for 4.10
Support for the Allwinner A31 SoC display engine using the sun4i-drm
driver.
* tag 'sunxi-drm-for-4.10' of https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux:
drm/sun4i: Add a few formats
drm/sun4i: Add compatible strings for A31/A31s display pipelines
drm/sun4i: Add compatible string for A31/A31s TCON (timing controller)
drm/sun4i: tcon: Move SoC specific quirks to a DT matched data structure
drm/sun4i: sun6i-drc: Support DRC on A31 and A31s
Daniel Vetter [Mon, 14 Nov 2016 09:02:53 +0000 (10:02 +0100)]
drm/irq: Unexport drm_vblank_count
No one outside of drm_irq.c should ever need this. The correct way to
implement get_vblank_count for hw lacking a vblank counter is
drm_vblank_no_hw_counter. Fix this up in mtk, which is the only
offender left over.
Daniel Vetter [Mon, 14 Nov 2016 09:02:52 +0000 (10:02 +0100)]
drm/irq: Make drm_vblank_pre/post_modeset internal
Now that all drivers are switched over to drm_crtc_vblank_on/off we
can relegate pre/post_modeset to the purely drm_irq.c internal role of
supporting old ums userspace.
As usual switch to the drm_legacy_ prefix to make it clear this is
for old drivers only.
v2: Rebase on top of Thierry's s/int crtc/unsigned int pipe/ changes.
Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Daniel Vetter [Tue, 15 Nov 2016 21:58:19 +0000 (22:58 +0100)]
drm/nouveau: Use drm_crtc_vblank_off/on
With atomic nv50+ is already converted over to them, but the old
display code is still using it. Found in a 2 year old patch I have
lying around to un-export these old helpers!
v2: Drop the hand-rolled versions from resume/suspend code. Now that
crtc callbacks do this, we don't need a special case for s/r anymore.
v3: Remove unused variables.
v4: Don't remove drm_crtc_vblank_off from suspend paths, non-atomic
nouveau still needs that. But still switch to drm_crtc_vblank_off
since drm_vblank_off will disappear.
Daniel Vetter [Mon, 14 Nov 2016 09:02:50 +0000 (10:02 +0100)]
drm/amdgpu: Use drm_crtc_vblank_on/off for dce6
This old code pattern was reintroduced in
Author: Ken Wang <Qingqing.Wang@amd.com>
Date: Tue Jan 19 14:03:24 2016 +0800
drm/amdgpu: add display controller implementation for si v10
Realign it with later display code. Tsk, tsk for massive copypasting
;-)
Cc: Christian König <christian.koenig@amd.com> Cc: Ken Wang <Qingqing.Wang@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Acked-by: Christian König <christian.koenig@amd.com> for the whole series. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161114090255.31595-1-daniel.vetter@ffwll.ch
Adding new mode flags willy nilly breaks existing userspace. We need to
coordinate this better, potentially with a new client cap that only
exposes the aspect ratio flags when userspace is prepared for them
(similar to what we do with stereo 3D modes).
This also broke things so that we would always send out VIC==0 in
the AVI infoframe unless the user specified an aspect ratio via
the mode flags. And the automagic RGB full vs. limited range
handling was similartly broken as the user mode would never match
any CEA mode.
Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Lin, Jia <lin.a.jia@intel.com> Cc: Akashdeep Sharma <akashdeep.sharma@intel.com> Cc: Jim Bride <jim.bride@linux.intel.com> Cc: Jose Abreu <Jose.Abreu@synopsys.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Emil Velikov <emil.l.velikov@gmail.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> 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/1478176304-6743-2-git-send-email-ville.syrjala@linux.intel.com
Adding new mode flags willy nilly breaks existing userspace. We need to
coordinate this better, potentially with a new client cap that only
exposes the aspect ratio flags when userspace is prepared for them
(similar to what we do with stereo 3D modes).
Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Lin, Jia <lin.a.jia@intel.com> Cc: Akashdeep Sharma <akashdeep.sharma@intel.com> Cc: Jim Bride <jim.bride@linux.intel.com> Cc: Jose Abreu <Jose.Abreu@synopsys.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Emil Velikov <emil.l.velikov@gmail.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> 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/1478176304-6743-1-git-send-email-ville.syrjala@linux.intel.com
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.
Daniel Vetter [Mon, 14 Nov 2016 11:58:19 +0000 (12:58 +0100)]
drm: Extract drm_drv.h
I want to move dumb buffer documentation into the right vfuncs, and
for that I first need to be able to pull that into kerneldoc without
having to clean up all of drmP.h. Also, header-splitting is nice.
While at it shuffle all the function declarations for drm_drv.c into
the right spots, and drop the kerneldoc for drm_minor_acquire/release
since it's only used internally.
v2: Keep all existing copyright notices (Chris).
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
projects / linux-beck.git / log