- 12 Feb, 2014 12 commits
-
-
Imre Deak authored
There isn't any PSR interrupt enable bit for pipe A, so we couldn't enable it through the current API. Passing the corresponding status bits solves this and also makes the mapping between enable and status bits simpler on VLV (addressed in an upcoming patch). Except of checking for invalid status bit arguments, no functional change. v2: split out the low level parts of i915_enable_pipestat accepting separate enabled and status masks, to make the non-standard mapping between those masks stand out more (added in the next patch) (Jesse,Daniel) Signed-off-by:Imre Deak <imre.deak@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Chris Wilson authored
Touching the VGA registers risks a hard machine hang, at least on this ivb machine after removing a conflicting efifb. This is more than likely related to the discovery that VGA IO decode on the more recent PCH platforms is terminally broken. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by:
-
Chris Wilson authored
This has very little effect other than log the errors in case of failure, and we then hope for the best. Signed-off-by:
-
Jesse Barnes authored
Allocate this struct instead, so we can re-use another allocated elsewhere if needed. Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: WARN_ON if there's no backing storage attached to an fb, that's a bug.] Signed-off-by:
-
Chris Wilson authored
When we detect that the user passed along an invalid handle or object, we emit a warning as an aide for debugging. Since these are indeed only for debugging user triggerable errors (and the errors are reported back to userspace by the errno), the messages should only be at the debug level and not claiming that there is a catastrophic error in the driver/hardware. References: https://bugs.freedesktop.org/show_bug.cgi?id=74704Signed-off-by:
-
Damien Lespiau authored
Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
-
Damien Lespiau authored
Reviewed-by:
Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by:
-
Damien Lespiau authored
We had 2 set of defines for the same register, so make it one. Reviewed-by:
-
Damien Lespiau authored
And rename it to num_sprites as this value doesn't count the primary plane. This limit lives with num_pipes really, and now that dev_priv->info is writable we can put it there instead. While at it, introduce a intel_device_info_runtime_init() where we'll be able to gather the device info fields at run-time. v2: rename num_plane to num_sprites (Ville Syrjälä) v3: rebase on top of latest drm-nightly Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> (for v2) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (for v2) Signed-off-by:
-
Damien Lespiau authored
Turns out it'd be nice to change some device information at run-time or simply have some code to fill in the info struct instead of having to declare the values in 30+ structures. What prompted this change is handling fused out display/pipe and tweaking num_pipes at run-time, but I'm quite sure we'll find other flags/limits to stick into dev_priv->info. Most of the changes were done with a sed: sed -i -e 's/dev_priv->info->/dev_priv->info./g' drivers/gpu/drm/i915/*[ch] with a few tweaks to make it all work: - Change the field definition in struct drm_i915_private - adjust i915_dump_device_info() - adjust i915_driver_load() - adjust the INTEL_INFO() macro v2: cast the info pointer returned by INTEL_INFO() to be const to catch uses that would modify the structure post-initialization. (Ville Syrjälä) v3: Redo the patch onto latest drm-nightly, Keep the info field const to catch post initialization writes instead of the v2 solution, Use a direct structure copy for the initial info initialization to use the compiler type safety (Ville Syrjälä) Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> (for v2) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (for v2) Signed-off-by: -
Damien Lespiau authored
If we make sure that all the dev_priv->info usages are wrapped by INTEL_INFO(), we can easily modify the ->info field to be structure and not a pointer while keeping the const protection in the INTEL_INFO() macro. v2: Rebased onto latest drm-nightly Suggested-by:
-
Ville Syrjälä authored
According to Bspec we need to disable SF pipelined attribute fetch whenever SF outputs exceed 16 and normal clip mode is used. A quick glance at Mesa suggests that these conditions could happen. So let's just always set the magic bit. Signed-off-by:
Kenneth Graunke <kenneth@whitecape.org> Signed-off-by:
-
- 07 Feb, 2014 2 commits
-
-
Jeff McGee authored
sysfs changes to rps min and max delay were only triggering an update of the rps interrupt limits if the active delay required an update. This change ensures that interrupt limits are always updated. v2: correct compile issue missed on rebase v3: add igt testcases to signed-off-by section Testcase: igt/pm_rps/min-max-config-idle Testcase: igt/pm_rps/min-max-config-loaded Signed-off-by:
Jeff McGee <jeff.mcgee@intel.com> Signed-off-by:
-
Jeff McGee authored
A check of rps/rc6 state after i915_reset determined that the ring MAX_IDLE registers were returned to their hardware defaults and that the GEN6_PMIMR register was set to mask all interrupts. This change restores those values to their pre-reset states by re-initializing rps/rc6 in i915_reset. A full re-initialization was opted for versus a targeted set of restore operations for simplicity and maintain- ability. Note that the re-initialization is not done for Ironlake, due to a past comment that it causes problems. Also updated the rps initialization sequence to preserve existing min/max values in the case of a re-init. We assume the values were validated upon being set and do not do further range checking. The debugfs interface for changing min/max was updated with range checking to ensure this condition (already present in sysfs interface). v2: fix rps logging to output hw_max and hw_min, not rps.max_delay and rps.min_delay which don't strictly represent hardware limits. Add igt testcase to signed-off-by section. Testcase: igt/pm_rps/reset Signed-off-by:
-
- 06 Feb, 2014 1 commit
-
-
Chris Wilson authored
As the VM do not track activity of objects and instead use a large hammer to forcibly idle and evict all of their associated objects when one is released, it is possible for that to cause a recursion when we need to wait for free space on a ring and call retire requests. (intel_ring_begin -> intel_ring_wait_request -> i915_gem_retire_requests_ring -> i915_gem_context_free -> i915_gem_evict_vm -> i915_gpu_idle -> intel_ring_begin etc) In order to remove the requirement for calling retire-requests from intel_ring_wait_request, we have to inline a couple of steps from retiring requests, notably we have to record the position of the request we wait for and use that to update the available ring space. Signed-off-by:
-
- 05 Feb, 2014 5 commits
-
-
Ben Widawsky authored
We get a large number of bugs which have a, "hey I have that too" because they see a GPU hang in dmesg. While two machines of the same model having a GPU hang is indeed a coincidence, it is far from enough evidence to suggest they are the same. In order to reduce this effect, and hopefully get people to file new bug reports, clearly the error message itself has been insufficient (see ref at the bottom for a new bug report with this characteristic). The algorithm is purposely pretty naive. I don't think we need much in order to avoid the problem I am trying to solve, and keeping it naive gives us some ability to make a decent test case. Cc: Jesse Barnes <jbarnes@virtuousgeek.org> References: https://bugs.freedesktop.org/show_bug.cgi?id=73276Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
-
Imre Deak authored
s/FLIPDONE/FLIP_DONE/ to make all FLIP_DONE macro names consistent. No functional change. Signed-off-by:
-
Imre Deak authored
Signed-off-by:
-
Imre Deak authored
This will be used by other platforms too, so factor it out. The only functional change is the reordeing of gmbus_irq_handler() wrt. the hotplug handling, but since it only schedules a work, it isn't an issue. Signed-off-by:
-
Imre Deak authored
Bspec and the code suggests that the interrupt signaled by IIR[7,5] (DISPLAY_PIPE_A/B_VBLANK) is a first level IRQ flag for the second level PIPEA/BSTAT[2] (Start of Vertical Blank) interrupt. Measuring the relative timings of when IIR[7] and PIPEASTAT[1,2] get set and checking the effect of unmasking different pipestat and IIR events shows that this isn't so: First, ISR/IIR[7] gets set independently of PIPEASTAT[18] (Start of Vertical Blank Enable) or any other pipestat enable bit, so it isn't a first level IRQ bit showing the state of PIPEASTAT[2], but is connected directly to the timing generator. Second, setting only PIPEASTAT[18] and leaving all other pipestat events disabled, IIR[6] (DISPLAY_PIPE_A_EVENT) gets set close to the moment when PIPEASTAT[2] gets set, so the former is a first level interrupt flag for the latter. The bspec is rather unclear about this, but I also assume that IIR[6] signals all pipestat A events, except PIPEASTAT[31] (FIFO Under-run Status). Third, IIR[7] is set close to the moment when PIPEASTAT[1] (Framestart Interrupt) gets set, in the mode I used about 12usec after PIPEASTAT[2] and IIR[6] gets set. This means the IIR[7] isn't marking the start of vblank, but rather signals the framestart event. Based on the above, we don't need to unmask IIR[7] when waiting for start of vblank events, but we can rely on IIR[6] being always unmasked, which will signal when PIPEASTAT[2] gets set. Doing this will also get rid of the overhead of getting an interrupt and servicing IIR[7], which is atm raised always some time after IIR[6]/PIPEASTAT[2] is raised. Signed-off-by:
-
- 04 Feb, 2014 10 commits
-
-
Antti Koskipaa authored
RFCv2: Reorganize array indexing so that full offsets can be used as is. It makes grepping for registers in i915_reg.h much easier. Also move offset arrays to intel_device_info. v1: Fixed offsets for VLV, proper eDP handling v2: Fixed BCLRPAT, PIPESRC, PIPECONF and DSP* macros. v3: Added EDP pipe comment, removed redundant offset arrays for MSA_MISC and DDI_FUNC_CTL. v4: Rename patch and report object size increase. v5: Change location of commas, add PIPE_EDP into enum pipe v6: Insert PIPE_EDP_OFFSET into pipe offset array v7: Set I915_MAX_PIPES back to 3, change more registers accessors to use the new macros, get rid of _PIPE_INC and add dev_priv as a parameter where required by the new macros. Upcoming hardware will not have the various display pipe register ranges evenly spaced in memory. Change register address calculations into array lookups. Tested on SNB, VLV, IVB, Gen2 and HSW w/eDP. I left the UMS cruft untouched. Size differences: text data bss dec hex filename 596431 4634 56 601121 92c21 i915.ko (new) 593199 4634 56 597889 91f81 i915.ko (old) Signed-off-by:Antti Koskipaa <antti.koskipaa@linux.intel.com> Reviewed-by:
-
Chris Wilson authored
Since a purged buffer is one without any associated pages, attempting to use it should generate EFAULT rather than EINVAL, as it is not strictly an invalid parameter. Signed-off-by:
-
Chris Wilson authored
EFAULT will be a possible return code where backing storage is transient, such after it is purged by madvise. As such it is to be expected and so should not trigger a WARN inside i915_gem_fault() but be converted silently to SIGBUS. Signed-off-by:
-
Mika Kuoppala authored
Found with smatch. Signed-off-by:
-
Mika Kuoppala authored
Found with smatch Signed-off-by:
-
Deepak S authored
When we enter RC6 and GFX Clocks are off, the voltage remains higher than Vmin. When we try to set the freq to RPn, it might fail since the Gfx clocks are down. So to fix this in Gfx idle, Bring the GFX clock up and set the freq to RPn then move GFx down. v2: remove vlv_update_rps_cur_delay function. Update commit message (Daniel) v3: Fix the timeout during wait for gfx clock (Jesse) v4: addressed comments on set freq and punit wait (Ville) v5: use wait_for while waiting for GFX clk to be up. (Daniel) update cur_delay before requesting min_delay. (Ville) v6: use wait_for while waiting for punit. (Ville) Signed-off-by:Deepak S <deepak.s@intel.com> Reviewed-by:
-
Mika Kuoppala authored
As we seek the guilty batch using request and hangcheck score, this code is not needed anymore. v2: Rebase. Passing dev_priv instead of getting it from last_ring Signed-off-by:
-
Mika Kuoppala authored
With full ppgtt using acthd is not enough to find guilty batch buffer. We get multiple false positives as acthd is per vm. Instead of scanning which vm was running on a ring, to find corressponding context, use a different, simpler, strategy of finding batches that caused gpu hang: If hangcheck has declared ring to be hung, find first non complete request on that ring and claim it was guilty. v2: Rebase Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73652Suggested-by:
-
Ville Syrjälä authored
Both Bspec and the W/A database state that WaDisablePSDDualDispatchEnable is only needed for IVB GT1. The only real confusion here is that the the W/A database also says to write to the GT2 only register as well, which is strange if the W/A is only for GT1. Signed-off-by:
-
Ville Syrjälä authored
IVB GT2 has two registers for these things, and both must be written. To add a bit more confusion both Bspec and the W/A database state that WaDisablePSDDualDispatchEnable is only needed for IVB GT1, but the W/A database also says to write even the second GT2 only register. So I don't really know what the right thing here is. Note that Bspec disagrees with the w/a database here, but Ville confirmed (by asking Chris) that on gt1 the 2nd reg doesn't exist. Signed-off-by:
-
- 30 Jan, 2014 10 commits
-
-
Chris Wilson authored
We want to use the GTT for reading back objects upon an error so that we have exactly the information that the GPU saw. However, it is verboten to access snoopable pages through the GTT and causes my PineView GPU to throw a page fault instead. This has not been a problem in the past as we only dumped ringbuffers and batchbuffers, both of which must be not snooped. However, the introduction of HWS page dumping leads to a read of a snooped object through the GTT. This was introduced by commit f3ce3821 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Jan 23 22:40:36 2014 +0000 drm/i915: Include HW status page in error capture Signed-off-by:
-
Chris Wilson authored
Repeating the same information multiple times is just annoying. Signed-off-by:
-
Mika Kuoppala authored
If we have stopped rings then we know that test is running so no need for spam. In addition, only spam when default context gets banned. v2: - make sure default context ban gets shown (Chris) - use helper for checking for default context, everywhere (Chris) v3: - dont be quiet when debug is set (Ben, Daniel) Reference: https://bugs.freedesktop.org/show_bug.cgi?id=73652Signed-off-by: -
Mika Kuoppala authored
With full ppgtt support drm_i915_file_private gained knowledge about the default context. Also reset stats are now inside i915_hw_context so we can use proper abstraction. v2: Move BUG_ON and WARN_ON to more proper locations (Ben) v3: Pass dev directly to i915_context_is_banned to avoid the need to dereference ctx->last_ring. Spotted by Mika when checking my s/BUG/WARN/ change, I've missed this ->last_ring dereference. Suggested-by:
-
Chia-I Wu authored
The optimization helps IVB too. No piglit regression. Signed-off-by:
Chia-I Wu <olv@lunarg.com> Reviewed-by:
-
Chia-I Wu authored
The optimization is available on Ivy Bridge and later, and is disabled by default. Enabling it helps certain workloads such as GLBenchmark TRex test. No piglit regression. v2 - no need to save the register before suspend as init_clock_gating can correctly program it after resume - split IVB change to another commit Signed-off-by:
-
Ben Widawsky authored
v2: Rebased upon cleaned up error state v3: Make sure hangcheck info remains last (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Ben Widawsky authored
Chris: Do we also want to capture? GAC_ECO_BITS /* gen6,7 */ GAM_ECOCHK /* gen6,7 */ GAB_CTL /* gen6 */ GFX_MODE /* gen6 */ Requested-by:
-
Ben Widawsky authored
v2: Moved num_requests up (Chris) Rebased on new hws page capture which required a rename since it made two members named, 'hws' in the per ring error state. (Ben) Signed-off-by:
-
Ben Widawsky authored
This helps make an upcoming patch a bit more reviewable Signed-off-by:
-
