Rodrigo Vivi [Thu, 10 Dec 2015 19:12:27 +0000 (11:12 -0800)]
drm/i915: Fix random aux transactions failures.
Mainly aux communications on sink_crc
were failing a lot randomly on recent platforms.
The first solution was to try to use intel_dp_dpcd_read_wake, but then
it was suggested to move retries to drm level.
Since drm level was already taking care of retries and didn't want
to through random retries on that level the second solution was to
put the retries at aux_transfer layer what was nacked.
So I realized we had so many retries in different places and
started to organize that a bit. During this organization I noticed
that we weren't handing at all the case were the message size was
zeroed. And this was exactly the case that was affecting sink_crc.
Also we weren't respect BSPec who says this size message = 0 or > 20
are forbidden.
It is a fact that we still have no clue why we are getting this
forbidden value there. But anyway we need to handle that for now
so we return -EBUSY and drm level takes care of the retries that
are already in place.
v2: Print debug messsage when this case is reached as suggested
by Jani.
v3: This patch is crucial to make PSR test cases reliably working
on SKL. So split this patch from the aux re-org series and add
a FIXME as a promisse to continue that effort besides reminding
to remove the sleep when that is merged.
v4: Use a bigger usleep range so kernel doesn't need to be interrupted
on a exact time, as suggested by Paulo.
But anyway we should discuss the better time
ranges on the EBUSY handle re-org at drm level since this one here
is temporary.
v5: s/1000,1500/1000, 1500/ (by Paulo).
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Tested-by: Daniel Stone <daniels@collabora.com> # SKL Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1449774747-2772-1-git-send-email-rodrigo.vivi@intel.com
Dave Gordon [Tue, 8 Dec 2015 15:02:36 +0000 (15:02 +0000)]
drm/i915: intel_ring_initialized() must be simple and inline
Based on Chris Wilson's patch from 6 months ago, rebased and adapted.
The current implementation of intel_ring_initialized() is too heavyweight;
it's a non-inlined function that chases several levels of pointers. This
wouldn't matter too much if it were rarely called, but it's used inside
the iterator test of for_each_ring() and is therefore called quite
frequently. So let's make it simple and inline ...
The idea here is to use ring->dev as an indicator showing which engines
have been initialised and are therefore to be included in iterations that
use for_each_ring(). This allows us to avoid multiple memory references
and a (non-inlined) function call on each iteration of each such loop.
drm/i915: Do a better job at disabling primary plane in the noatomic case.
When disable_noatomic is called plane_mask is not correct yet, and
plane_state->visible = true is left as true after disabling the primary
plane.
Other planes are already disabled as part of crtc sanitization, only the
primary is left active. But the plane_mask is not updated here. It gets
updated during fb takeover in modeset_gem_init, or set to the new value
on resume.
This means that to disable the primary plane 1 << drm_plane_index(primary)
needs to be used.
Afterwards because the crtc is no longer active it's forbidden to keep
plane_state->visible set, or a WARN_ON in
intel_plane_atomic_calc_changes triggers. There are other code points
that rely on accurate plane_state->visible too, so make sure the bool is
cleared.
The other planes are already disabled in intel_sanitize_crtc, so they
don't have to be handled here.
Cc: stable@vger.kernel.org #v4.3, v4.2?
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92655 Tested-by: Tomas Mezzadra <tmezzadra@gmail.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/5652DB88.9070208@linux.intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Wayne Boyer [Tue, 8 Dec 2015 17:38:52 +0000 (09:38 -0800)]
drm/i915: Only set gem object L3 cache level for IVB devices
Do some further clean up based on the initial review of
drm/i915: Separate cherryview from valleyview.
In this case, in i915_gem_alloc_context_obj() only call
i915_gem_object_set_cache_level() for Ivy Bridge devices
since later platforms don't have L3 control bits in the PTE.
v2: Expand comment to mention snooping requirement. (Ville, Imre)
Wayne Boyer [Wed, 9 Dec 2015 20:29:35 +0000 (12:29 -0800)]
drm/i915: Separate cherryview from valleyview
The cherryview device shares many characteristics with the valleyview
device. When support was added to the driver for cherryview, the
corresponding device info structure included .is_valleyview = 1.
This is not correct and leads to some confusion.
This patch changes .is_valleyview to .is_cherryview in the cherryview
device info structure and simplifies the IS_CHERRYVIEW macro.
Then where appropriate, instances of IS_VALLEYVIEW are replaced with
IS_VALLEYVIEW || IS_CHERRYVIEW or equivalent.
v2: Use IS_VALLEYVIEW || IS_CHERRYVIEW instead of defining a new macro.
Also add followup patches to fix issues discovered during the first
review. (Ville)
v3: Fix some style issues and one gen check. Remove CRT related changes
as CRT is not supported on CHV. (Imre, Ville)
v4: Make a few more optimizations. (Ville)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Wayne Boyer <wayne.boyer@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1449692975-14803-1-git-send-email-wayne.boyer@intel.com Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com>
Joonas Lahtinen [Wed, 9 Dec 2015 13:56:13 +0000 (15:56 +0200)]
drm/i915: Cancel hangcheck before GPU is suspended
In order to avoid accessing GPU registers while GPU is suspended cancel
the hangcheck work before calling intel_suspend_complete which actually
puts the GPU to suspend. Otherwise hangcheck might do MMIO reads to a
suspended GPU.
Placement before intel_guc_suspend is imitated from i915_drm_suspend
which cancels the work at i915_gem_suspend, to keep the functions
similar.
On VLV systems, namely BYT, this was causing an error during runtime
suspend cycle:
[drm:vlv_check_no_gt_access [i915]] *ERROR* GT register access while GT waking disabled
Dave Gordon [Tue, 8 Dec 2015 13:30:51 +0000 (13:30 +0000)]
drm/i915: eliminate 'temp' in gen8_for_each_{pdd, pdpe, pml4e} macros
All of these iterator macros require a 'temp' argument, used merely to
hold internal partial results. We can instead declare the temporary
variable inside the macro, so the caller need not provide it.
Some of the old code contained nested iterators that actually reused the
same 'temp' variable for both inner and outer instances. It's quite
surprising that this didn't introduce bugs! But it does show that the
value of 'temp' isn't required to persist during the iterated body.
Chris Wilson [Tue, 8 Dec 2015 11:55:07 +0000 (11:55 +0000)]
drm/i915: Add soft-pinning API for execbuffer
Userspace can pass in an offset that it presumes the object is located
at. The kernel will then do its utmost to fit the object into that
location. The assumption is that userspace is handling its own object
locations (for example along with full-ppgtt) and that the kernel will
rarely have to make space for the user's requests.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
v2: Fixed incorrect eviction found by Michal Winiarski - fix suggested by Chris
Wilson. Fixed incorrect error paths causing crash found by Michal Winiarski.
(Not published externally)
v3: Rebased because of trivial conflict in object_bind_to_vm. Fixed eviction
to allow eviction of soft-pinned objects when another soft-pinned object used
by a subsequent execbuffer overlaps reported by Michal Winiarski.
(Not published externally)
v4: Moved soft-pinned objects to the front of ordered_vmas so that they are
pinned first after an address conflict happens to avoid repeated conflicts in
rare cases (Suggested by Chris Wilson). Expanded comment on
drm_i915_gem_exec_object2.offset to cover this new API.
v5: Added I915_PARAM_HAS_EXEC_SOFTPIN parameter for detecting this capability
(Kristian). Added check for multiple pinnings on eviction (Akash). Made sure
buffers are not considered misplaced without the user specifying
EXEC_OBJECT_SUPPORTS_48B_ADDRESS. User must assume responsibility for any
addressing workarounds. Updated object2.offset field comment again to clarify
NO_RELOC case (Chris). checkpatch cleanup.
v6: Trivial rebase on latest drm-intel-nightly
v7: Catch attempts to pin above the max virtual address size and return
EINVAL (Tvrtko). Decouple EXEC_OBJECT_SUPPORTS_48B_ADDRESS and
EXEC_OBJECT_PINNED flags, user must pass both flags in any attempt to pin
something at an offset above 4GB (Chris, Daniel Vetter).
Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Akash Goel <akash.goel@intel.com> Cc: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Cc: Michal Winiarski <michal.winiarski@intel.com> Cc: Zou Nanhai <nanhai.zou@intel.com> Cc: Kristian Høgsberg <hoegsberg@gmail.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Acked-by: PDT Signed-off-by: Thomas Daniel <thomas.daniel@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1449575707-20933-1-git-send-email-thomas.daniel@intel.com
Rodrigo Vivi [Wed, 9 Dec 2015 00:58:38 +0000 (16:58 -0800)]
drm/i915/kbl: drm/i915: Avoid GuC loading for now on Kabylake.
GuC has no version for KBL published yet and it is not recommended
to load the Skylake one, so let's avoid loading this for now while
we don't have the proper GuC firmware for Kabylake.
Imre Deak [Thu, 4 Dec 2014 16:39:35 +0000 (18:39 +0200)]
drm/i915: vlv: clamp minimum RPS frequency to what Punit allows
As described in the code comment, I couldn't set the minimum RPS
frequency on my BYT-M B0 to the minimum allowed as reported by Punit.
Fix this by clamping the minimum value to the first one that was
accepted on my machine.
Atm this issue doesn't cause any test failures, since in igt/pm_rps we
only check the cached version of the current frequency which is the same
what has been set. In the future we'll add checks for the actual
frequency too, and for that to pass this fix is necessary.
Ville Syrjälä [Fri, 4 Dec 2015 20:22:50 +0000 (22:22 +0200)]
drm/i915: Leave FDI running after failed link training on LPT-H
Currently we disable some parts of FDI setup after a failed link
training. But despite that we continue with the modeset as if everything
is fine. This results in tons of noise from the state checker, and
it means we're not following the proper modeset sequence for the rest of
crtc enabling, nor for crtc disabling.
Ideally we should abort the modeset and follow the proper disable
sequence to shut off everything we enabled so far, but that would
require a big rework of the modeset code. So instead just leave FDI
up and running in its untrained state, and log an error. This is
what we do on older platforms too.
Ville Syrjälä [Fri, 4 Dec 2015 20:22:14 +0000 (22:22 +0200)]
drm/i915: Disable LPT-H VGA dotclock during crtc disable
Currently we leave the LPT-H VGA dotclock running after turning
the pipe/fdi/port/etc. Properly disable the VGA dotclock as
specified in the modeset sequence.
Ville Syrjälä [Tue, 8 Dec 2015 14:05:48 +0000 (16:05 +0200)]
drm/i915: Disable FDI after the CRT port on LPT-H
Bspec modeset sequence tells us to disable the PCH transcoder and
FDI after the CRT port on LPT-H, so let's do that. And the CRT port
should be disabled after the pipe, as we do on other PCH platforms
too since
commit 1ea56e269e13 ("drm/i915: Disable CRT port after pipe on PCH platforms")
commit 00490c22b1b5 ("drm/i915: Consider SPLL as another shared pll, v2.")
moved the SPLL disable from the .post_disable() hook to some upper
level code, so we can just move the CRT port disabling into the
.post_disable() hook. If we still had the non-shared SPLL, it would have
needed to be moved into the .post_pll_disable() hook.
v2: Actually move the CRT port disable to the .post_disable() hook,
and amend the commit message with more details (Paulo)
v3: Fix typos in commit message (Paulo)
Ville Syrjälä [Fri, 4 Dec 2015 20:19:39 +0000 (22:19 +0200)]
drm/i915: Disable CLKOUT_DP bending on LPT/WPT as needed
When we want to use SPLL for FDI we want SSC, which means we have to
disable clock bending for the PCH SSC reference (bend and spread are
mutually exclusive). So let's turn off bending when we want spread.
In case the BIOS enabled clock bending for some reason we'll just turn
it off and enable the spread mode instead.
Not sure what happens if the BIOS is actually using the bend source for
HDMI at this time, but I suppose it should be no worse than what already
happens when we simply turn on the spread.
We don't currently use the bend source for anything, and only use the
PCH SSC reference for the SPLL to drive FDI (always with spread).
v2: Fix the %5 vs %10 fumble for SSCDITHPHASE (Paulo)
Add 'WARN_ON(steps % 5 != 0)' sanity check (Paulo)
Fix typos in commit message (Paulo)
Mika Kuoppala [Mon, 7 Dec 2015 16:29:44 +0000 (18:29 +0200)]
drm/i915/skl: Disable coarse power gating up until F0
There is conflicting info between E0 and F0 steppings
for this workarounds. Trust more authoritative source and
be conservative and extend also for F0.
This prevents numerous (>50) gpu hangs with SKL GT4e
during piglit run.
Rodrigo Vivi [Mon, 7 Dec 2015 22:45:20 +0000 (14:45 -0800)]
drm/i915: Fix idle_frames counter.
'commit 97173eaf5 ("drm/i915: PSR: Increase idle_frames")' was a mistake.
The special case it tried to cover was already being covered by
the DP_PSR_NO_TRAIN_ON_EXIT. So this ended up duplicated.
So, instead of reverting that let's take this opportunity and unify
the idle_frame definition in a single place so we standardize the access
and avoid room for that same mistake again.
Few changes with this patch:
1. Instead of just respecting the VBT we set a
global minumum with max(). So we are sure that we will avoid corner cases
in case VBT is doing something we don't understand.
2. Instead of minimum 5 we use 6. When introducing the idle_frames += 4 case
we considered that minimum was 2. All because the off-by-one issue.
drm/i915/skl: Update watermarks before the crtc is disabled.
On skylake some of the registers are only writable when the correct
power wells are enabled. Because of this watermarks have to be updated
before the crtc turns off, or you get unclaimed register read and write
warnings.
This patch needs to be modified slightly to apply to -fixes.
drm/i915: Calculate watermark related members in the crtc_state, v4.
This removes pre/post_wm_update from intel_crtc->atomic, and
creates atomic state for it in intel_crtc.
Changes since v1:
- Rebase on top of wm changes.
Changes since v2:
- Split disable_cxsr into a separate patch.
Changes since v3:
- Move some of the changes to intel_wm_need_update.
Mika Kuoppala traced down a use-after-free crash in module unload to
this commit, because ring->last_context is leaked beyond when the
context gets destroyed. Mika submitted a quick fix to patch that up in
the context destruction code, but that's too much of a hack.
The right fix is instead for the ring to hold a full reference onto
it's last context, like we do for legacy contexts.
Since this is causing a regression in BAT it gets reverted before we
can close this.
Cc: Nick Hoath <nicholas.hoath@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: David Gordon <david.s.gordon@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Alex Dai <yu.dai@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93248 Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
drm/i915: Clean up device info structure definitions
and I didn't spot this while reviewing. We really need that CI farm up
asap!
Reported-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Wayne Boyer <wayne.boyer@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
drm/i915: Convert RPS tracking to a intel_rps_client struct
we converted the __i915_wait_request() to take a new intel_rps_client
struct (rather than having to pass fake drm_i915_file_private structs).
However, due to use of passing a void pointer, I didn't spot one
callsite in wait-ioctl was passing the wrong pointer.
Fwiw, the impact of this bug is zero. Along the rps path, we always
first call list_empty(rps) which when we pass in the wrong pointer
always evaluates to false and we return early and never chase the
invalid pointers.
The user visible impact is then wait-ioctl doesn't get the same
waitboosting as the other interfaces (set-domain, throttle), which is a
performance concern for the *very* few users of the wait interface.
There is also a libdrm_intel patch to use the wait-ioctl for
drm_intel_bo_wait_rendering() if anyone feels inclined to review
libdrm_intel patches.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
[danvet: Add Chris' explanation for why the impact of this is pretty
close to 0.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Wayne Boyer [Wed, 2 Dec 2015 21:28:14 +0000 (13:28 -0800)]
drm/i915: Clean up device info structure definitions
Beginning with gen7, newer devices repetitively redefine values
for the device info structure members. This patch simplifies the
structure definitions by grouping member value definitions into the
existing GEN7_FEATURES #define and into the new GEN7_LP_FEATURES
and HSW_FEATURES #defines.
Specifically, GEN_DEFAULT_PIPEOFFSETS and IVB_CURSOR_OFFSETS are
added to GEN7_FEATURES and subsequent IVB definitions are simplified.
VLV_FEATURES is defined to differentiate and simplify the
gen7 low power (LP) devices.
HSW_FEATURES is defined and used to simplify all HSW+ devices
except for LP.
v2: Use VLV_FEATURES for the gen7 low power devices. (Jani)
As the comment indicates this can only fail gracefully when
called from compute_config. Fortunately this is now what's happening,
so the fixme can be removed and the DRM_ERROR downgraded.
Alex Goins [Thu, 26 Nov 2015 02:43:39 +0000 (18:43 -0800)]
i915: wait for fence in prepare_plane_fb
In intel_prepare_plane_fb, if fb is backed by dma-buf, wait for exclusive
fence
v2: First commit
v3: Remove object_name_lock acquire
Move wait from intel_atomic_commit() to intel_prepare_plane_fb()
v4: Wait only on exclusive fences, interruptible with no timeout
v5: Style tweaks to more closely match rest of file
v6: Properly handle interrupted waits
v7: No change
v8: No change
Alex Goins [Thu, 26 Nov 2015 02:43:38 +0000 (18:43 -0800)]
i915: wait for fence in mmio_flip_work_func
If a buffer is backed by dmabuf, wait on its reservation object's exclusive
fence before flipping.
v2: First commit
v3: Remove object_name_lock acquire
v4: Move wait ahead of mark_page_flip_active
Use crtc->primary->fb to get GEM object instead of pending_flip_obj
use_mmio_flip() return true when exclusive fence is attached
Wait only on exclusive fences, interruptible with no timeout
v5: Move wait from do_mmio_flip to mmio_flip_work_func
Style tweaks to more closely match rest of file
v6: Change back to unintteruptible wait to match __i915_wait_request due to
inability to properly handle interrupted wait.
Warn on error code from waiting.
v7: No change
v8: Test for !reservation_object_signaled_rcu(test_all=FALSE) instead of
obj->base.dma_buf->resv->fence_excl
Nick Hoath [Tue, 1 Dec 2015 14:48:57 +0000 (14:48 +0000)]
drm/i915: Extend LRC pinning to cover GPU context writeback
Use the first retired request on a new context to unpin
the old context. This ensures that the hw context remains
bound until it has been written back to by the GPU.
Now that the context is pinned until later in the request/context
lifecycle, it no longer needs to be pinned from context_queue to
retire_requests.
This fixes an issue with GuC submission where the GPU might not
have finished writing back the context before it is unpinned. This
results in a GPU hang.
v2: Moved the new pin to cover GuC submission (Alex Dai)
Moved the new unpin to request_retire to fix coverage leak
v3: Added switch to default context if freeing a still pinned
context just in case the hw was actually still using it
v4: Unwrapped context unpin to allow calling without a request
v5: Only create a switch to idle context if the ring doesn't
already have a request pending on it (Alex Dai)
Rename unsaved to dirty to avoid double negatives (Dave Gordon)
Changed _no_req postfix to __ prefix for consistency (Dave Gordon)
Split out per engine cleanup from context_free as it
was getting unwieldy
Corrected locking (Dave Gordon)
v6: Removed some bikeshedding (Mika Kuoppala)
Added explanation of the GuC hang that this fixes (Daniel Vetter)
v7: Removed extra per request pinning from ring reset code (Alex Dai)
Added forced ring unpin/clean in error case in context free (Alex Dai)
Signed-off-by: Nick Hoath <nicholas.hoath@intel.com>
Issue: VIZ-4277 Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: David Gordon <david.s.gordon@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Alex Dai <yu.dai@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Alex Dai <yu.dai@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Alex Dai [Thu, 3 Dec 2015 00:56:29 +0000 (16:56 -0800)]
drm/i915/guc: Clean up locks in GuC
For now, remove the spinlocks that protected the GuC's
statistics block and work queue; they are only accessed
by code that already holds the global struct_mutex, and
so are redundant (until the big struct_mutex rewrite!).
The specific problem that the spinlocks caused was that
if the work queue was full, the driver would try to
spinwait for one jiffy, but with interrupts disabled the
jiffy count would not advance, leading to a system hang.
The issue was found using test case igt/gem_close_race.
The new version will usleep() instead, still holding
the struct_mutex but without any spinlocks.
v4: Reorganize commit message (Dave Gordon)
v3: Remove unnecessary whitespace churn
v2: Clean up wq_lock too
v1: Clean up host2guc lock as well
Paulo Zanoni [Wed, 11 Nov 2015 16:46:22 +0000 (14:46 -0200)]
drm/i915: only recompress FBC after flushing a drawing operation
There's no need to stop and restart FBC, which is quite expensive as
we have to revalidate the CRTC state. After flushing a drawing
operation we know the CRTC state hasn't changed, so a nuke
(recompress) should be fine.
v2: Make it simpler (Chris).
v3: Rewrite the patch again due to patch order changes.
v4: Rewrite commit message (Chris).
Paulo Zanoni [Tue, 27 Oct 2015 16:54:22 +0000 (14:54 -0200)]
drm/i915: get rid of FBC {,de}activation messages
When running Cinnamon I see way too many pairs of these messages: many
per second. Get rid of them as they're just telling us FBC is working
as expected. We already have the messages for enable/disable, so we
don't really need messages for activation/deactivation.
Paulo Zanoni [Mon, 26 Oct 2015 20:44:25 +0000 (18:44 -0200)]
drm/i915: kill fbc.uncompressed_size
Directly call intel_fbc_calculate_cfb_size() in the only place that
actually needs it, and use the proper check before removing the stolen
node. IMHO, this change makes our code easier to understand.
Paulo Zanoni [Mon, 26 Oct 2015 18:27:49 +0000 (16:27 -0200)]
drm/i915: use a single intel_fbc_work struct
This was already on my TODO list, and was requested both by Chris and
Ville, for different reasons. The advantages are avoiding a frequent
malloc/free pair, and the locality of having the work structure
embedded in dev_priv. The maximum used memory is also smaller since
previously we could have multiple allocated intel_fbc_work structs at
the same time, and now we'll always have a single one - the one
embedded on dev_priv. Of course, we're now using a little more memory
on the cases where there's nothing scheduled.
The biggest challenge here is to keep everything synchronized the way
it was before.
Currently, when we try to activate FBC, we allocate a new
intel_fbc_work structure. Then later when we conclude we must delay
the FBC activation a little more, we allocate a new intel_fbc_work
struct, and then adjust dev_priv->fbc.fbc_work to point to the new
struct. So when the old work runs - at intel_fbc_work_fn() - it will
check that dev_priv->fbc.fbc_work points to something else, so it does
nothing. Everything is also protected by fbc.lock.
Just cancelling the old delayed work doesn't work because we might
just cancel it after the work function already started to run, but
while it is still waiting to grab fbc.lock. That's why we use the
"dev_priv->fbc.fbc_work == work" check described in the paragraph
above.
So now that we have a single work struct we have to introduce a new
way to synchronize everything. So we're making the work function a
normal work instead of a delayed work, and it will be responsible for
sleeping the appropriate amount of time itself. This way, after it
wakes up it can grab the lock, ask "were we delayed or cancelled?" and
then go back to sleep, enable FBC or give up.
v2:
- Spelling fixes.
- Rebase after changing the patch order.
- Fix ms/jiffies confusion.
Paulo Zanoni [Fri, 16 Oct 2015 20:55:40 +0000 (17:55 -0300)]
drm/i915: check for FBC planes in the same place as the pipes
This moves the pre-gen4 check from update() to enable(). The HAS_DDI
in the original code is not needed since only gen 2/3 have the plane
swapping code.
Paulo Zanoni [Thu, 15 Oct 2015 17:19:21 +0000 (14:19 -0300)]
drm/i915: alloc/free the FBC CFB during enable/disable
One of the problems with the current code is that it frees the CFB and
releases its drm_mm node as soon as we flip FBC's enable bit. This is
bad because after we disable FBC the hardware may still use the CFB
for the rest of the frame, so in theory we should only release the
drm_mm node one frame after we disable FBC. Otherwise, a stolen memory
allocation done right after an FBC disable may result in either
corrupted memory for the new owner of that memory region or corrupted
screen/underruns in case the new owner changes it while the hardware
is still reading it. This case is not exactly easy to reproduce since
we currently don't do a lot of stolen memory allocations, but I see
patches on the mailing list trying to expose stolen memory to user
space, so races will be possible.
I thought about three different approaches to solve this, and they all
have downsides.
The first approach would be to simply use multiple drm_mm nodes and
freeing the unused ones only after a frame has passed. The problem
with this approach is that since stolen memory is rather small,
there's a risk we just won't be able to allocate a new CFB from stolen
if the previous one was not freed yet. This could happen in case we
quickly disable FBC from pipe A and decide to enable it on pipe B, or
just if we change pipe A's fb stride while FBC is enabled.
The second approach would be similar to the first one, but maintaining
a single drm_mm node and keeping track of when it can be reused. This
would remove the disadvantage of not having enough space for two
nodes, but would create the new problem where we may not be able to
enable FBC at the point intel_fbc_update() is called, so we would have
to add more code to retry updating FBC after the time has passed. And
that can quickly get too complex since we can get invalidate, flush,
disable and other calls in the middle of the wait.
Both solutions above - and also the current code - have the problem
that we unnecessarily free+realloc FBC during invalidate+flush
operations even if the CFB size doesn't change.
The third option would be to move the allocation/deallocation to
enable/disable. This makes sure that the pipe is always disabled when
we allocate/deallocate the CFB, so there's no risk that the FBC
hardware may read or write to the memory right after it is freed from
drm_mm. The downside is that it is possible for user space to change
the buffer stride without triggering a disable/enable - only
deactivate/activate -, so we'll have to handle this case somehow - see
igt's kms_frontbuffer_tracking test, fbc-stridechange subtest. It
could be possible to implement a way to free+alloc the CFB during said
stride change, but it would involve a lot of book-keeping - exactly as
mentioned above - just for on case, so for now I'll keep it simple and
just deactivate FBC. Besides, we may not even need to disable FBC
since we do CFB over-allocation.
Note from Chris: "Starting a fullscreen client that covers a single
monitor in a multi-monitor setup will trigger a change in stride on
one of the CRTCs (the monitors will be flipped independently).". It
shouldn't be a huge problem if we lose FBC on multi-monitor setups
since these setups already have problems reaching deep PC states
anyway.
v2: Rebase after changing the patch order.
v3:
- Remove references to the stride change case being "uncommon" and
paste Chris' example.
- Rebase after a change in a previous patch.
Paulo Zanoni [Thu, 15 Oct 2015 13:44:46 +0000 (10:44 -0300)]
drm/i915: introduce intel_fbc_{enable,disable}
The goal is to call FBC enable/disable only once per modeset, while
activate/deactivate/update will be called multiple times.
The enable() function will be responsible for deciding if a CRTC will
have FBC on it and then it will "lock" FBC on this CRTC: it won't be
possible to change FBC's CRTC until disable(). With this, all checks
and resource acquisition that only need to be done once per modeset
can be moved from update() to enable(). And then the update(),
activate() and deactivate() code will also get simpler since they
won't need to worry about the CRTC being changed.
The disable() function will do the reverse operation of enable(). One
of its features is that it should only be called while the pipe is
already off. This guarantees that FBC is stopped and nothing is
using the CFB.
With this, the activate() and deactivate() functions just start and
temporarily stop FBC. They are the ones touching the hardware enable
bit, so HW state reflects dev_priv->crtc.active.
The last function remaining is update(). A lot of times I thought
about renaming update() to activate() or try_to_activate() since it's
called when we want to activate FBC. The thing is that update() may
not only decide to activate FBC, but also deactivate or keep it on the
same state, so I'll leave this name for now.
Moving code to enable() and disable() will also help in case we decide
to move FBC to pipe_config or something else later.
The current patch only puts the very basic code on enable() and
disable(). The next commits will take care of moving more stuff from
update() to the new functions.
v2:
- Rebase.
- Improve commit message (Chris).
v3: Rebase after changing the patch order.
v4: Rebase again after upstream changes.
Paulo Zanoni [Wed, 14 Oct 2015 20:45:36 +0000 (17:45 -0300)]
drm/i915: introduce is_active/activate/deactivate to the FBC terminology
The long term goal is to have enable/disable as the higher level
functions and activate/deactivate as the lower level functions, just
like we do for PSR and for the CRTC. This way, we'll run enable and
disable once per modeset, while update, activate and deactivate will
be run many times. With this, we can move the checks and code that
need to run only once per modeset to enable(), making the code simpler
and possibly a little faster.
This patch is just the first step on the conversion: it starts by
converting the current low level functions from enable/disable to
activate/deactivate. This patch by itself has no benefits other than
making review and rebase easier. Please see the next patches for more
details on the conversion.
v2:
- Rebase.
- Improve commit message (Chris).
v3: Rebase after changing the patch order.
Paulo Zanoni [Tue, 13 Oct 2015 22:13:25 +0000 (19:13 -0300)]
drm/i915: pass the crtc as an argument to intel_fbc_update()
There's no need to reevaluate the status of every single crtc when a
single crtc changes its state.
With this, we're cutting the case where due to a change in pipe B,
intel_fbc_update() is called, then intel_fbc_find_crtc() concludes FBC
should be enabled on pipe A, then it completely rechecks the state of
pipe A only to conclude FBC should remain enabled on pipe A. If any
change on pipe A triggers a need to recompute whether FBC is valid on
pipe A, then at some point someone is going to call
intel_fbc_update(PIPE_A).
The addition of intel_fbc_deactivate() is necessary so we keep track
of the previously selected CRTC when we do invalidate/flush. We're
also going to continue the enable/disable/activate/deactivate concept
in the next patches.
v2: Rebase.
v3: Rebase after changing the patch order.
Paulo Zanoni [Tue, 13 Oct 2015 21:04:45 +0000 (18:04 -0300)]
drm/i915: set dev_priv->fbc.crtc before scheduling the enable work
This thing where we need to get the crtc either from the work
structure or the fbc structure itself is confusing and unnecessary.
Set fbc.crtc right when scheduling the enable work so we can always
use it.
The problem is not what gets passed and how to retrieve it. The
problem is that when we're in the other parts of the code we always
have to keep in mind that if FBC is already enabled we have to get the
CRTC from place A, if FBC is scheduled we have to get the CRTC from
place B, and if it's disabled there's no CRTC. Having a single place
to retrieve the CRTC from allows us to treat the "is enabled" and "is
scheduled" cases as the same case, reducing the mistake surface. I
guess I should add this to the commit message.
Besides the immediate advantages, this is also going to make one of
the next commits much simpler. And even later, when we introduce
enable/disable + activate/deactivate, this will be even simpler as
we'll set the CRTC at enable time. So all the
activate/deactivate/update code can just look at the single CRTC
variable regardless of the current state.
v2: Improve commit message (Chris).
v3: Rebase after changing the patch order.
Paulo Zanoni [Fri, 16 Oct 2015 19:44:43 +0000 (16:44 -0300)]
drm/i915: fix the CFB size check
In function find_compression_threshold() we try to over-allocate CFB
space in order to reduce reallocations and fragmentation, and we're
not considering that at the CFB size check. Consider it.
There is also a longer-term plan to kill
dev_priv->fbc.uncompressed_size, but this will come later.
Ville Syrjälä [Tue, 1 Dec 2015 21:31:33 +0000 (23:31 +0200)]
drm/i915: Check VBT for CRT port presence on HSW/BDW
Unfortunatey there appear to quite a few HSW/BDW machines (eg.
NUCs, Brix Pro) in the wild with LPT/WPT-H that have no physical
CRT connector and non-working FDI. FDI training fails every
single time on these machines. Dunno, maybe they just didn't
bother wiring it up or something?
Unfortunately all the fuse bits and whatnot are telling us that
the CRT connector is present. And so what we get from this is tons
of false positives from the CI systems due to VGA connector forcing.
I've not found any way to detect this purely from hardware, so we
have to resort to looking at the VBT int_crt_support bit. We used
to check this bit on all platforms, but that broke all the old
machines, so the check was then restricted to VLV only in
commit 84b4e042c470 ("drm/i915: only apply crt_present check on VLV")
Considering HSW and VLV VBT probably got defined around the same time,
it should be reasonably safe to assume that the bits is sane for
HSW/BDW as well. At least I have one copy of some VBT spec here that
says it's meant for both VLV and HSW, and it knows about the bit
(lists it being valid from version 155 onwards). Also I have two
desktop machines with actual CRT ports and both have
int_crt_support==1 in their VBTs.
Also we already trust VBT >= 155 to tell us various details about
the DDI ports, so trusting it a bit more seems reasonable.
As far as VLV goes, the added VBT version check should be fine. Even
if someone has some weird VLV machine with a very old VBT version,
it just means they'll end up with a shadow CRT connector. IIRC the
reason for eliminating the shadow CRT connector on VLV was to speed
up display probing rather than fixing something more serious.
v2: Move the platform checks into the VBT parsing code
Also check that the VBT version is at least 155
v3: Improve commit message (Paulo)
Ville Syrjälä [Tue, 1 Dec 2015 21:29:56 +0000 (23:29 +0200)]
drm/i915: Don't register CRT connector when DDI E can't be used
On HSW/BDW DDI A and E share 2 lanes, so when DDI A requires the
shared lanes DDI E can't be used. The lanes are not supposed to
be dynamically switched between the two uses, so there's no point
in registering the CRT connector when DDI E has no lanes.
Ville Syrjälä [Tue, 1 Dec 2015 21:28:55 +0000 (23:28 +0200)]
drm/i915: Don't register the CRT connector when it's fused off on LPT-H
LPT-H has a strap bit for fused off CRT block. Check it to see if
we should register the CRT connector or not. Supposedly this also
forces the ADAP enable bit to 0, so the detection we added in
commit 6c03a6bd0dd8 ("drm/i915: Don't register CRT connector when it's fused off")
should already catch it, but checking the fuse bit should at least
do no harm.
Ville Syrjälä [Mon, 30 Nov 2015 14:23:46 +0000 (16:23 +0200)]
drm/i915: Round the AUX clock divider to closest on all platforms
Currently we round the AUX clock divider down on g4x, to closest
on HSW/BDW port A, and up everywhere else. We are supposed to get
as close to 2MHz as we can, so round to closest seems like the
best option.
Somehow we accumulated a duplicated .get_display_clock_speed()
assignment for PNV in
commit 34edce2fea69 ("drm/i915: Add cdclk extraction for g33, g965gm and g4x")
No real harm on having two, we just never reach the second one, so
simply kill it.
Imre Deak [Tue, 1 Dec 2015 08:23:52 +0000 (10:23 +0200)]
drm/i915/bxt: backlight clock gating workaround
Per bspec, "Backlight PWM may stop in the asserted state, causing
backlight to stay fully on. WA: Before disabling PWM, set CLKGATE_DIS_0
0x46530 bit 13 PWM1 Gating Dis (for PWM1) or bit 14 PWM2 Gating Dis (for
PWM2). The bits can remain set without harm." (There's no workaround
name for this.)
Jani Nikula [Tue, 1 Dec 2015 08:23:51 +0000 (10:23 +0200)]
drm/i915: use default 200 Hz backlight frequency
If the backlight modulation frequency can't be extracted from the
registers or from VBT, use 200 Hz as the default. This may enable
backlight on some machines that previously failed.
Jani Nikula [Tue, 1 Dec 2015 08:23:50 +0000 (10:23 +0200)]
drm/i915/bxt: add support for setting backlight freq from vbt
The only missing piece is the function to convert frequency to PWM
register value. The PWM is based on 19.2 MHz clock, except for BXT A
step, which is based on CDCLK, and which we ignore.
DPMS off operations may actually cause the entire system to powerdown or
reboot. Disable power well support for now until Broxton gets fixes
similar to what we have for SKL.
Ville Syrjälä [Thu, 26 Nov 2015 16:27:07 +0000 (18:27 +0200)]
drm/i915: Don't use crtc->config when reading out infoframe state
The .get_config() hooks should not reference anything in crtc->config,
everything should be based on the passed in pipe_config instead. So
don't dig out the cpu_transcoder from crtc->config on ddi platfforms,
and also avoid using the encoder->crtc link and instead look up the
pipe via pipe_config->base.crtc.
I don't think this will actually fix anything since during the initial
state readout we set up the encoder->crtc link prior to calling
.get_config(), and during the modeset state check the encoder->crtc
ought to be correct anyway since it's that state we just programmed.
But this seems the right thing to do anyway.
While at it, do some house cleaning on the local variables in the
.infoframe_enabled() hooks.
drm/i915: Enable PCH FIFO underruns later on ILK/SNB/IVB
we can only enable fifo underrun reporting when using the fdi/lpt
after everything is set up and after a bit of waiting. The waiting
is required, enabling it right after enabling encoders will first trigger
an underrun on the pch and then, 1 frame later, an underrun on the
cpu. Two vblank waits after encoder enabling seems enough to curb it.
And similar to
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Fri Nov 20 22:09:18 2015 +0200
drm/i915: Suppress spurious CPU FIFO underruns on ILK-IVB
we also need to make sure cpu fifo underrun reporting is disabled when
enabling the fdi rx/tx and pch transcoder&port. But somehow this is
only needed when enabling, not also when disabling.
Jani Nikula [Fri, 27 Nov 2015 10:21:46 +0000 (12:21 +0200)]
drm/i915: add has_dsi_encoder to crtc state
DSI has quite a few special cases, like DP, so add it to crtc
state. This way we can get rid of a number of intel_pipe_has_type()
checks for DSI. This isn't necessarily the prettiest way, but it's a
step towards being aligned with what's being done with other encoders.
Jani Nikula [Fri, 27 Nov 2015 10:21:45 +0000 (12:21 +0200)]
drm/i915: remove pre_pll_enable hook from DDI/gen9+ crtc enable
The hook was added to cater for DSI, but with the hooks rearranged on
the DSI encoder side, this is no longer needed. It was a bit silly
anyway to have two hooks called back-to-back.
Jani Nikula [Fri, 27 Nov 2015 10:21:44 +0000 (12:21 +0200)]
drm/i915/dsi: merge pre_pll_enable hook to pre_enable
For DSI, the pre_pll_enable and the pre_enable hooks are called
back-to-back on all platforms that support DSI. The distinction is
artificial for DSI, for which we enable the DSI PLL in the encoder
hooks. Do everything in pre_enable, and remove DSI pre_pll_enable hook.
shooting the messenger while the debugging for why Sonika's commit
triggered the errors was still in progress.
It looks like we need to read and acknowledge the PCH_PORT_HOTPLUG
register even though the hotplug trigger indicates there isn't a hotplug
irq to handle. The PCH doesn't seem to really ack the the interrupt to
the CPU unless we touch the hotplug register.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Sonika Jindal <sonika.jindal@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92084 Fixes: aaf5ec2e51ab ("drm/i915: Handle HPD when it has actually occurred")
[Jani: added a comment and amended the commit message while applying] Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1448462843-32739-1-git-send-email-jani.nikula@intel.com
Gerd Hoffmann [Thu, 26 Nov 2015 11:03:51 +0000 (12:03 +0100)]
drm/i915: more virtual south bridge detection
Commit "30c964a drm/i915: Detect virtual south bridge" detects and
handles the southbridge emulated by vmware esx. Add the ich9 south
bridge emulated by 'qemu -M q35'.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Power gating display wells during i915_pm_suspend
moved for_each_power_domain from intel_display.c to i915_drv.h but we
still have the definition around in intel_display.c, due to a merge
conflict resolution gone wrong in
Ville Syrjälä [Fri, 20 Nov 2015 20:35:41 +0000 (22:35 +0200)]
drm/i915: Don't register CRT connector when it's fused off
On some machines the CRT connector may be fused off. The weird thing
about this setup is that the ADPA register works otherwise normally,
except the enable bit is hardwired to 0. No one knows of any fuse
register that would tell us if this is the case, so the only thing we
can do (apart from a blacklist) is to try and set the enable bit and see
if it sticks. If not, we don't register the connector at all. Obviously
if the bit is already set when loading the driver we can just assume it
works.
I've smoke tested this approach on several machines (GMCH and PCH),
some with actual CRT connectors, some with shadow connectors, and
obviously the machine (IVB) with the fused off connector. So far
I've not seen any ill effects from this probe.
The main benefit is that we can actually run igt on machines with
fused off connectors, without totally upsetting the state checker.
Ville Syrjälä [Fri, 20 Nov 2015 20:09:20 +0000 (22:09 +0200)]
drm/i915: Check for underruns after crtc disable
To get a better idea if underruns occurred during crtc disabling,
let's check for them explicitly. This helps in cases where the
error interrupt isn't active, or there is no underrun interrupt
support at all.
Ville Syrjälä [Fri, 20 Nov 2015 20:09:19 +0000 (22:09 +0200)]
drm/i915: Disable CPU underruns around eDP port and vdd enable on ILK-IVB
We sometimes get a spurious CPU pipe underrun somewhere between
enabling port A and enabling vdd for the panel. Observed on both
ILK and IVB with port A eDP. Suppress FIFO underrun reporting
around the port and vdd enable to avoid the dmesg errors.
Not sure if port D eDP would suffer from the same issue, but assume
that it doesn't until proven differently.
Ville Syrjälä [Fri, 20 Nov 2015 20:09:18 +0000 (22:09 +0200)]
drm/i915: Suppress spurious CPU FIFO underruns on ILK-IVB
We still get spurious pipe underruns on ILK/SNB/IVB under two
circumstances when dealing with PCH ports:
* When the pipe has been disabled, but FDI RX/TX is still enabled
* During FDI link training
Both cases seem to happen at least when we do VGA+HDMI cloning
from the same pipe. I don't think I've seen them when not cloning,
but can't be 100% sure.
Disable underrun reporting around those places to eliminate the
dmesg errors.
Rodrigo Vivi [Mon, 23 Nov 2015 22:16:40 +0000 (14:16 -0800)]
drm/i915: Remove PSR Perf Counter for SKL+
Whenever DMC firmware put the HW into DC State a bunch
of registers including this perf counter is reset to 0.
Even with PSR active and working we could still read
"Performance_Counter: 0" what will misslead people to believe
PSR is broken. For instance on SKL we can only see PC10
residency with screen on if PSR is working properly.
However Performance_Counter was showing 0.
Even if it restored properly on DC6 exit we don't want to
give users the wrong impression that PSR is not working
while we know for sure it is.
So, it is better to remove this counter information while
we don't have a better way to track PSR residency.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Durgadoss R <durgadoss.r@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Rodrigo Vivi [Wed, 18 Nov 2015 19:21:55 +0000 (11:21 -0800)]
drm/i915: PSR: Mask LPSP hw tracking back again.
When we introduced PSR we let LPSP masked allowing us to get PSR
independently from the audio runtime PM. However in one of the
attempts to get PSR enabled by default one user reported one specific
case where he would miss screen updates if scrolling the firefox in a
Gnome environment when i915 runtime pm was enabled. So for
this specific case that (I could never create an i-g-t test case)
we decided to remove the LPSP mask and let HW tracking taking care of
this case. The mask got removed later by my
commit 09108b90f04 ("drm/i915: PSR: Remove Low Power HW tracking mask.")
So we started depending on audio driver again, what is bad.
With previous commit
"drm/i915: PSR: Let's rely more on frontbuffer tracking."
we transfered the PSR exit responsability totally to SW frontbuffer
tracking. So now can safelly shut off a bit the HW tracking, or
at least this case that makes us to depend on other drivers.
v2: Update commit message since this patch by itself doesn't solve
the bugzilla entries.
v3: Another attempt to improve commit message.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau damien.lespiau@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Rodrigo Vivi [Wed, 18 Nov 2015 19:21:12 +0000 (11:21 -0800)]
drm/i915: PSR: Let's rely more on frontbuffer tracking.
The ultimate goal here is to remove the dependency we
currently have on audio driver power to get PSR working.
Since with audio driver runtime PM disabled the Hardware tracking
believes graphics is fully active and prevent PSR Entry, or
in other words continuously exit PSR.
So, the idea is to transfer the PSR exit responsability
from the HW tracking to the SW tracking (frontbuffer tracking),
who is really mature right now.
However with LPSP masked out there might be cases where we could
miss exit from HW tracking since it can be relying on this,
like a specific case reported at our mailing list who
user reported he would miss screen updates if scrolling firefox
in a Gnome environment when i915 runtimepm was enabled.
So before masking out LPSP again to make us independent from
the audio driver we need to make sure that all our cases
are coverred from the frontbuffer tracking perspective,
where the flush means invalidate and flush.
Without this patch for HSW, BDW and SKL we just do the
invalidate part when the flush wasn't originated by a page flip
because we were trusting the HW tracking for the flip case.
So let's rely more on frontbuffer tracking and do the
invalidation regardless the origin as expected for all platforms.
v2: Improve commit message as suggested by Paulo.
v3: Another attempt to let commit message more clear.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau damien.lespiau@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Rodrigo Vivi [Thu, 12 Nov 2015 22:46:05 +0000 (14:46 -0800)]
drm/i915: Remove duplicated dpcd write on hsw_psr_enable_sink.
Commit (89251b17) intended to remove this line and let only one
DP_PSR_EN_CFG set, but it was wrong and this call is now duplicated
at the code.
Also "& ~DP_PSR_MAIN_LINK_ACTIVE" doesn't do anything at all. It
was like that since I introduced this call but probably the idea
was to be informative and make clear statement that we were not using
the link standby. So it is better to remove this one here and let
the code a bit cleaner.
v2: Improve commit message as requested by Paulo.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau damien.lespiau@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Clean up associated VMAs on context destruction
Added a warning based on an incorrect assumption that all VMAs
in a VM will be on the inactive list at the point last reference
to a context and VM is dropped.
This is not true because i915_gem_object_retire__read will not
put VMA on the inactive list until all activities on the object
in question (in all VMs) have been retired.
As a consequence, whether or not a context/VM will be destroyed
with its VMAs still on the active list, can depend on completely
unrelated activities using the same object from a different
context or engine.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92638
Testcase: igt/gem_request_retire/retire-vma-not-inactive Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michel Thierry <michel.thierry@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1448025816-25584-1-git-send-email-tvrtko.ursulin@linux.intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
projects / linux-beck.git / log