- 11 Jul, 2016 1 commit
-
-
Daniel Vetter authored
Signed-off-by:Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 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 <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1468059777-10205-1-git-send-email-chris@chris-wilson.co.ukReviewed-by:
Matthew Auld <matthew.auld@intel.com>
-
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:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1467709290-5941-1-git-send-email-tim.gore@intel.com
-
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:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-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:
Dave Gordon <david.s.gordon@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-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 8 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:
-
Chris Wilson authored
As we only ever keep the first error state around, we can avoid some work that can be quite intrusive if we don't record the error the second time around. This does move the race whereby the user could discard one error state as the second is being captured, but that race exists in the current code and we hope that recapturing error state is only done for debugging. Note that as we discard the error state for simulated errors, igt that exercise error capture continue to function. Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com>
-
Chris Wilson authored
Remove some redundant kernel messages as we deduce a hung GPU and capture the error state. v2: Fix "hang" vs "no progress" message whilst I was there v3: s/snprintf/scnprintf/ Signed-off-by:
-
Chris Wilson authored
These are identical, so let's just use the same vfunc. Signed-off-by:
-
Chris Wilson authored
After Joonas complained about using READ_ONCE() on the only use of the variable in the function, where the intent was to simply document that the read was intentionally racy and unlocked, I switched the READ_ONCE() over to lockless_dereference(). However, in linux-next that has a stronger type-check to only allow pointers and is no longer interchangeable with READ_ONCE(), see commit 331b6d8c ("locking/barriers: Validate lockless_dereference() is used on a pointer type") Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Fixes: 67d97da3 ("drm/i915: Only start retire worker when idle") Signed-off-by:
-
- 04 Jul, 2016 11 commits
-
-
Tvrtko Ursulin authored
Some IS_ and HAS_ macros can return any non-zero value for true. One potential problem with that is that someone could assign them to integers and be surprised with the result. Therefore it is probably safer to do the conversion to 0/1 in the macros themselves. Luckily this does not seem to have an effect on code size. Only one call site was getting bit by this and a patch for that has been sent as "drm/i915/guc: Protect against HAS_GUC_* returning true values other than one". v2: Added some extra braces as suggested by checkpatch. Signed-off-by:
-
Dave Gordon authored
Also remove some redundant dev and dev_priv locals Signed-off-by:
-
Chris Wilson authored
Since we now subclass struct drm_device, we can save pointer dances by noting the equivalence of struct drm_device and struct drm_i915_private, i.e. by using to_i915(). text data bss dec hex filename 1073824 4562 416 1078802 107612 drivers/gpu/drm/i915/i915.ko 1068976 4562 416 1073954 106322 drivers/gpu/drm/i915/i915.ko Created by the coccinelle script: @@ expression E; identifier p; @@ - struct drm_i915_private *p = E->dev_private; + struct drm_i915_private *p = to_i915(E); Signed-off-by:
-
Peter Antoine authored
This patch added the loading of the GuC for Kabylake. It loads a 9.14 firmware. v2: Fix commit message v3: Fix major/minor var names to match -nightly. (Rodrigo) Cc: Christophe Prigent <christophe.prigent@intel.com> Signed-off-by:
Peter Antoine <peter.antoine@intel.com> Signed-off-by:
Michel Thierry <michel.thierry@intel.com> Reviewed-by:
-
Peter Antoine authored
This reverts commit 2b81b844 Cc: Christophe Prigent <christophe.prigent@intel.com> Signed-off-by:
-
Chris Wilson authored
For simplicity in testing, only report known rings in the mask. This allows userspace to try and trigger a missed irq on every ring and do a comparison between i915_ring_test_irq and i915_ring_missed_irq to see if any rings failed. v2: Move the debug message to after the rings are selected (so that the message accurately reflects reality) Signed-off-by:
-
Chris Wilson authored
Acquiring the forcewake domain asserts that it is in an atomic section (as we always expect to be under the uncore.lock). This is true except for initialising the domains on Ivybridge, and so we generate a warning. Wrap the manual usage of fw_domains inside the spin_lock. Signed-off-by:
-
Chris Wilson authored
igt likes to inject GPU hangs into its command streams. However, as we expect these hangs, we don't actually want them recorded in the dmesg output or stored in the i915_error_state (usually). To accommodate this allow userspace to set a flag on the context that any hang emanating from that context will not be recorded. We still do the error capture (otherwise how do we find the guilty context and know its intent?) as part of the reason for random GPU hang injection is to exercise the race conditions between the error capture and normal execution. v2: Split out the request->ringbuf error capture changes. v3: Move the flag defines next to the intel_context->flags definition Signed-off-by:
-
Chris Wilson authored
The request tells us where to read the ringbuf from, so use that information to simplify the error capture. If no request was active at the time of the hang, the ring is idle and there is no information inside the ring pertaining to the hang. Note carefully that this will reduce the amount of information stored in the error state - any ring without an active request will not be recorded. Signed-off-by:
-
Chris Wilson authored
Now that we have (near) universal GPU recovery code, we can inject a real hang from userspace and not need any fakery. Not only does this mean that the testing is far more realistic, but we can simplify the kernel in the process. Signed-off-by:
-
Chris Wilson authored
Make sure that the RPS bottom-half is flushed before we set the idle frequency when we decide the GPU is idle. This should prevent any races with the bottom-half and setting the idle frequency, and ensures that the bottom-half is bounded by the GPU's rpm reference taken for when it is active (i.e. between gen6_rps_busy() and gen6_rps_idle()). v2: Avoid recursively using the i915->wq - RPS does not touch the struct_mutex so has no place being on the ordered i915->wq. v3: Enable/disable interrupts for RPS busy/idle in order to prevent further HW access from RPS outside of the wakeref. Signed-off-by:
Michał Winiarski <michal.winiarski@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1467616119-4093-6-git-send-email-chris@chris-wilson.co.uk
-
