- 14 Jul, 2016 9 commits
-
-
Matthew Auld authored
This should already be handled by drm_gem_object_release, which is called later on. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1467720019-31876-1-git-send-email-matthew.auld@intel.com
-
Ville Syrjälä authored
Dell XPS 13 9350 apparently doesn't like it when we use the panel type from OpRegion. The OpRegion panel type (0) tells us to use use low vswing for eDP, whereas the VBT panel type (2) tells us to use normal vswing. The problem is that low vswing results in some display flickers. Since no one seems to know how this stuff is supposed to be handled, let's just ignore the OpRegion panel type on SKL for now. v2: Print the panel type correctly in the debug output Reported-by:
James Bottomley <James.Bottomley@HansenPartnership.com> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Cc: drm-intel-fixes@lists.freedesktop.org References: https://lists.freedesktop.org/archives/intel-gfx/2016-June/098826.html Fixes: a0562819 ("drm/i915: Get panel_type from OpRegion panel details") Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1468324837-29237-1-git-send-email-ville.syrjala@linux.intel.comReviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Tested-by:
-
Tvrtko Ursulin authored
Created two common helpers for engine setup and engine init phases respectively to help with code sharing. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1468422221-12132-1-git-send-email-tvrtko.ursulin@linux.intel.com Reviewed-by: Chris Wilson <chris-wilson.co.uk>
-
Tvrtko Ursulin authored
Common code deserves to be put in a separate file from legacy and execlists implementation for clarity and ease of maintenance. Signed-off-by: -
Tvrtko Ursulin authored
Engine contains dev_priv so need to pass it in. Signed-off-by:
-
Tvrtko Ursulin authored
Use more of the shared engine setup data for legacy engine initialization. This time to simplify the irq initialization code. Signed-off-by: -
Tvrtko Ursulin authored
With the unified common engine setup done, and the execlist engine initialization loop clearly split into two phases, we can eliminate the separate legacy engine initialization code. v2: Fix cleanup path for legacy. v3: Rename constructors. (Chris Wilson) Signed-off-by:
-
Tvrtko Ursulin authored
Move the execlist engine setup to vfuncs so that the engine init loop is clearly split into the mode agnostic and specific steps. Signed-off-by:
-
Dave Gordon authored
intel_lrc.c has a table of "logical rings" (meaning engines), while intel_ringbuffer.c has separately open-coded initialisation for each engine. We can deduplicate this somewhat by using the same first-stage engine-setup function for both modes. So here we expose the function that transfers information from the static table of (all) known engines to the dev_priv->engine array of engines available on this device (adjusting the names along the way) and then embed calls to it in both the LRC and the legacy-mode setup. Signed-off-by:
Dave Gordon <david.s.gordon@intel.com> Reviewed-by: Chris Wilson <chris-wilson.co.uk> Signed-off-by:
-
- 13 Jul, 2016 1 commit
-
-
Ville Syrjälä authored
Prior to gen6 we didn't have per-ring IMR registers, which means that since commit 61ff75ac ("drm/i915: Simplify enabling user-interrupts with L3-remapping") we're now masking off all interrupts when init_render_ring() gets called. That's rather rude. Let's limit the ring IMR frobbing to machines that actually have the per-ring IMR registers. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: 61ff75ac ("drm/i915: Simplify enabling user-interrupts with L3-remapping") Signed-off-by:
-
- 12 Jul, 2016 3 commits
-
-
Chris Wilson authored
Make sure we keep kbuilder happy in all of its random configs by providing argument names for compile-time stubs. In file included from drivers/gpu/drm/i915/intel_dp_mst.c:27:0: drivers/gpu/drm/i915/i915_drv.h: In function 'i915_debugfs_register': >> drivers/gpu/drm/i915/i915_drv.h:3612:48: error: parameter name omitted static inline int i915_debugfs_register(struct drm_i915_private *) {return 0;} ^~~~~~~~~~~~~~~~ drivers/gpu/drm/i915/i915_drv.h: In function 'i915_debugfs_unregister': drivers/gpu/drm/i915/i915_drv.h:3613:51: error: parameter name omitted static inline void i915_debugfs_unregister(struct drm_i915_private *) {} Reported-by: 0day Signed-off-by: -
Chris Wilson authored
In commit 7608a43d ("locking/mutexes: Use MUTEX_SPIN_ON_OWNER when appropriate") the owner field in the mutex was updated from being dependent upon CONFIG_SMP to using optimistic spin. Update our peek function to suite. Fixes:7608a43d ("locking/mutexes: Use MUTEX_SPIN_ON_OWNER...") Reported-by:
Hong Liu <hong.liu@intel.com> Signed-off-by:
-
Chris Wilson authored
Now that the last couple of hacks have been removed from the runtime powermanagement users, we can fully enable the asserts by preventing the temptation to disable them when our code is buggy. Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com>
-
- 11 Jul, 2016 3 commits
-
-
Chris Wilson authored
Let's ensure that we cannot run indefinitely without the hangcheck worker being queued. We removed it from being kicked on every request because we were kicking it a few millions times in every hangcheck interval and only once is necessary! However, that leaves us with the issue of what if userspace never waits for a request, or runs out of resources, what if userspace just issues a request then spins on BUSY_IOCTL? Testcase: igt/gem_busy Signed-off-by:
-
Chris Wilson authored
Never go to sleep waiting on the GPU without first ensuring that we will get woken up. We have a choice of queuing the hangcheck before every schedule() or the first time we wakeup. In order to simply accommodate both the signaler and the ordinary waiter, move the queuing to the common point of enabling the irq. We lose the paranoid safety of ensuring that the hangcheck is active before the sleep, but avoid code duplication (and redundant hangcheck queuing). Testcase: igt/prime_busy Fixes: c81d4613 ("drm/i915: Convert trace-irq to the breadcrumb waiter") Signed-off-by:
-
Daniel Vetter authored
Signed-off-by:
-
- 10 Jul, 2016 2 commits
-
-
Chris Wilson authored
igt/prime_vgem (and others) depends upon VGEM so automatically select it when enabling i915 debugging. Signed-off-by:
-
Chris Wilson authored
igt/pm_rpm depends upon /dev/*/msr so automatically select it when enabling i915 debugging. Signed-off-by:
-
- 08 Jul, 2016 1 commit
-
-
Chris Wilson authored
One of the numerous VT-d workarounds we require is that the display hardware reads past the end of the buffer triggering VT-d faults. This is acknowledged in the code as being safe "since we fill the unused portions of the GGTT with the scratch page". Alas, that is no longer always true and so we trigger DMAR read faults. Skylake also requires another workaround to avoid mixing VT-d and unpopulated PTE, and so there we also need to ensure we fill unused entries with the scratch page. Reported-by:
Mike Lothian <mike@fireburn.co.uk> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96584 Fixes: f7770bfd ("drm/i915: Skip clearing the GGTT on full-ppgtt systems") Signed-off-by:
David Weinehall <david.weinehall@intel.com>
-
- 07 Jul, 2016 13 commits
-
-
Rodrigo Vivi authored
Some Kabylake SKUs are going to use Kabypoint PCH. It is mainly for Halo and DT ones. >From our specs it doesn't seem that KBP brings any change on the display south engine. So let's consider this as a continuation of SunrisePoint, i.e., SPT+. Since it is easy to get confused by a letter change: KBL = Kabylake - CPU/GPU codename. KBP = Kabypoint - PCH codename. Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Ander Conselvan de Oliveira <conselvan2@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96826 Link: http://patchwork.freedesktop.org/patch/msgid/1467418032-15167-1-git-send-email-rodrigo.vivi@intel.comSigned-off-by:
-
Tim Gore authored
This patch applies WaMediaPoolStateCmdInWABB which fixes a problem with the restoration of thread counts on resuming from RC6. References: HSD#2137167 Signed-off-by:
Tim Gore <tim.gore@intel.com> Reviewed-by:
Arun Siluvery <arun.siluvery@linux.intel.com> Signed-off-by:
-
Ville Syrjälä authored
Move the encoder cloning check to happen earlier in the modeset. The main benefit will be that the debug output from a failed modeset will be less confusing as output_types can not indicate an invalid configuration during the later computation stages. For instance, what happened to me was kms_setmode was attempting one of its invalid cloning checks during which it asked for DP+VGA cloning on HSW. In this case the DP .compute_config() was executed after the FDI .compute_config() leaving the DP link clock (1.62 in this case) in port_clock, and then later the FDI BW computation tried to use that as the FDI link clock (which should always be 2.7). 1.62 x 2 wasn't enough for the mode it was trying to use, and so it ended up rejecting the modeset, not because of an invalid cloning configuration, but because of supposedly running out of FDI bandwidth. Took me a while to figure out what had actually happened. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1466621833-5054-12-git-send-email-ville.syrjala@linux.intel.com
-
Ville Syrjälä authored
With the output_types bitmask there's no need to loop through the encoders anymore when checking for HDMI+non-HDMI cloning. v2: Use output_types bitmask v3: Fix the logic to really check that there are no non-HDMI encoders Signed-off-by:
-
Ville Syrjälä authored
has_dsi_encoder was introduced to indicate that the pipe is driving a DSI encoder. Now that we have the output_types bitmask that can tell us the same thing, let's just kill has_dsi_encoder. v2: Rebase, handle BXT DSI transcoder, rewrote commit message Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Ville Syrjälä authored
INTEL_OUTPUT_DISPLAYPORT hsa been bugging me for a long time. It always looks out of place besides INTEL_OUTPUT_EDP and INTEL_OUTPUT_DP_MST. Let's just rename it to INTEL_OUTPUT_DP. v2: Rebase Signed-off-by:
Mika Kahola <mika.kahola@intel.com> Reviewed-by:
-
Ville Syrjälä authored
A bunch of places still look for DP encoders manually. Just call intel_crtc_has_dp_encoder(). Note that many of these places don't look for EDP or DP_MST, but it's still fine to replace them because * for audio we don't enable audio on eDP anyway * the code that lack DP MST check is only for plaforms that don't support MST anyway v2: Rebase Signed-off-by:
-
Ville Syrjälä authored
Use the new output_types bitmask instead of has_dp_encoder. To make it less oainlful provide a small helper (intel_crtc_has_dp_encoder()) to do the bitsy stuff. v2: Rebase Signed-off-by:
-
Ville Syrjälä authored
Since we now have the output_types bitmaks in the crtc state, there's no need to iterate through all the encoders to see if an LVDS or SDVO/HDMI encoder might be present. Signed-off-by:
-
Ville Syrjälä authored
With the introduction of the output_types mask, intel_pipe_has_type() and intel_pipe_will_have_type() are basically the same thing. Replace them with a new intel_crtc_has_type() (identical to intel_pipe_will_have_type() actually). v2: Rebase v3: Make intel_crtc_has_type() static inline (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Ville Syrjälä authored
Rather than looping through encoders to see which encoder types are being driven by the pipe, add an output_types bitmask into the crtc state and populate it prior to compute_config and during state readout. v2: Determine output_types before .compute_config() hooks are called Signed-off-by:
-
Ville Syrjälä authored
Now that eDP encoders won't have can_mst==true, we can throw out the encoder type checks from the MST suspend/resume paths. Cc: Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Ville Syrjälä authored
If we've determined that the encoder is eDP, we shouldn't try to use MST on it. Or at least the code doesn't seem to expect that since there are some type==DP checks in the MST code. Cc: Dave Airlie <airlied@redhat.com> Signed-off-by:
Shashank Sharma <shashank.sharma@intel.com> Reviewed-by:
-
- 06 Jul, 2016 4 commits
-
-
Dave Gordon authored
Rather than using wait_for_atomic() when chacking for a response from the GuC, we can get the effect of a hybrid spin/sleep wait by breaking it into two stages. First, spin-wait for up to 10us to minimise latency for "quick" commands; then, if that times out, sleep-wait for up 10ms (the maximum allowed for a "slow" command). Being able to do this depends on the recent patch 18f4b843 drm/i915: Use atomic waits for short non-atomic ones and is similar to the hybrid approach in 1758b90e drm/i915: Use a hybrid scheme for fast register waits (although we can't use that as-is, because that interface doesn't quite match what we need here). Signed-off-by:
-
Chris Wilson authored
As we inspect both the tasklet (to check for an active bottom-half) and set the irq-posted flag at the same time (both in the interrupt handler and then in the bottom-halt), group those two together into the same cacheline. (Not having total control over placement of the struct means we can't guarantee the cacheline boundary, we need to align the kmalloc and then each struct, but the grouping should help.) v2: Try a couple of different names for the state touched by the user interrupt handler. Signed-off-by:
-
Chris Wilson authored
Following on from the scenario Tvrtko envisioned to explain a hard-to-hit race with multiple first waiters, we could also then race in the __i915_request_irq_complete() and the bottom-half may miss the vital irq-seqno barrier and so go to sleep not noticing their seqno is complete. v2: unlock, not double lock the rcu_read_lock. Fixes: 3d5564e9 ("drm/i915: Only apply one barrier after...") Signed-off-by:
-
Chris Wilson authored
After assigning ourselves as the new bottom-half, we must perform a cursory check to prevent a missed interrupt. Either we miss the interrupt whilst programming the hardware, or if there was a previous waiter (for a later seqno) they may be woken instead of us (due to the inherent race in the unlocked read of b->tasklet in the irq handler) and so we miss the wake up. Spotted-by:
-
- 05 Jul, 2016 4 commits
-
-
Chris Wilson authored
Since drm_i915_private is now a subclass of drm_device we do not need to chase the drm_i915_private->dev backpointer and can instead simply access drm_i915_private->drm directly. text data bss dec hex filename 1068757 4565 416 1073738 10624a drivers/gpu/drm/i915/i915.ko 1066949 4565 416 1071930 105b3a drivers/gpu/drm/i915/i915.ko Created by the coccinelle script: @@ struct drm_i915_private *d; identifier i; @@ ( - d->dev->i + d->drm.i | - d->dev + &d->drm ) and for good measure the dev_priv->dev backpointer was removed entirely. Signed-off-by:
-
Chris Wilson authored
If we have a drm_device, we have a drm_i915_private (since they are the same). Signed-off-by:
-
Chris Wilson authored
As we can just directly use drm_dev->drm.dev, we do not need the drm_dev->dev backpointer anymore and can also loose the warning about order of __i915_printk() and our initialisation (which is now always safe). Signed-off-by:
-
Chris Wilson authored
Let's reclaim a few hundred lines from i915_drv.c by splitting out the runtime configuration of the "constant" dev_priv->info. Signed-off-by:
-
