- 12 Feb, 2014 18 commits
-
-
Daniel Vetter authored
Now that it's a normally kmalloce buffer we can use the usual cleanup paths. The upside here is that if we get the refcounting wrong will be able to catch it, since the drm core will complain about leftover framebuffers and kref about underflows. v2: Kill intel_framebuffer_fini - no longer needed now that we refcount all fbs properly and only confusing. v3: We actually still need to call unregister_private to remove the fb from the idr and drop the idr reference - the final unref doesn't do that. So much for remembering my own fb liftime rules. Reported by Imre Deak. Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v2) Signed-off-by:Daniel Vetter <daniel.vetter@ffwll.ch>
-
Damien Lespiau authored
If we can't actually determine at run-time we have a fused-off display, provide at least an option to disable it. v2: Move the i915.disable_display test in a separate check (Daniel Vetter) Signed-off-by:Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
-
Damien Lespiau authored
FUSE_STRAP has a bit to inform us that the display has been fused off. Use it to setup the definitive number of pipes at run-time. v2: actually tweak num_pipes, not num_planes v3: also tests SFUSE_STRAP bit 7 v4: rebase on top of drm-nightly use DRM_INFO() for the message telling display is fused off try to read the FUSE_LOCK bit to determine if PCH display is disabled v5: Don't read SFUSE_STRAP (register on the PCH) if num_pipes is already 0 from the initial device info struct (to prevent hangs) (Daniel Vetter) Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> (for v3) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (for v3) Signed-off-by: -
Chris Wilson authored
Arjan van de Ven reported that on his test machine that he was seeing stalls of greater than 1 frame greatly impacting the user experience. He tracked this down to being the locked flush during a pagefault as being the culprit hogging the struct_mutex and so blocking any other user from proceeding. Stalling on a pagefault is bad behaviour on userspace's part, for one it means that they are ignoring the coherency rules on pointer access through the GTT, but fortunately we can apply the same trick as the set-to-domain ioctl to do a lightweight, nonblocking flush of outstanding rendering first. "Prior to the patch it looks like this (this one testrun does not show the 20ms+ I've seen occasionally) 4.99 ms 2.36 ms 31360 __wait_seqno i915_wait_seqno i915_gem_object_wait_rendering i915_gem_object_set_to_gtt_domain i915_gem_fault __do_fault handle_ +pte_fault handle_mm_fault __do_page_fault do_page_fault page_fault 4.99 ms 2.75 ms 107751 __wait_seqno i915_gem_wait_ioctl drm_ioctl i915_compat_ioctl compat_sys_ioctl ia32_sysret 4.99 ms 1.63 ms 1666 i915_mutex_lock_interruptible i915_gem_fault __do_fault handle_pte_fault handle_mm_fault __do_page_fault do_page_fault page_fa +ult 4.93 ms 2.45 ms 980 i915_mutex_lock_interruptible intel_crtc_page_flip drm_mode_page_flip_ioctl drm_ioctl i915_compat_ioctl compat_sys_ioctl ia32_ +sysret 4.89 ms 2.20 ms 3283 i915_mutex_lock_interruptible i915_gem_wait_ioctl drm_ioctl i915_compat_ioctl compat_sys_ioctl ia32_sysret 4.34 ms 1.66 ms 1715 i915_mutex_lock_interruptible i915_gem_pwrite_ioctl drm_ioctl i915_compat_ioctl compat_sys_ioctl ia32_sysret 3.73 ms 3.73 ms 49 i915_mutex_lock_interruptible i915_gem_set_domain_ioctl drm_ioctl i915_compat_ioctl compat_sys_ioctl ia32_sysret 3.17 ms 0.33 ms 931 i915_mutex_lock_interruptible i915_gem_madvise_ioctl drm_ioctl i915_compat_ioctl compat_sys_ioctl ia32_sysret 2.97 ms 0.43 ms 1029 i915_mutex_lock_interruptible i915_gem_busy_ioctl drm_ioctl i915_compat_ioctl compat_sys_ioctl ia32_sysret 2.55 ms 0.51 ms 735 i915_gem_get_tiling drm_ioctl i915_compat_ioctl compat_sys_ioctl ia32_sysret After the patch it looks like this: 4.99 ms 2.14 ms 22212 __wait_seqno i915_gem_wait_ioctl drm_ioctl i915_compat_ioctl compat_sys_ioctl ia32_sysret 4.86 ms 0.99 ms 14170 __wait_seqno i915_gem_object_wait_rendering__nonblocking i915_gem_fault __do_fault handle_pte_fault handle_mm_fault __do_page_ +fault do_page_fault page_fault 3.59 ms 1.31 ms 325 i915_gem_get_tiling drm_ioctl i915_compat_ioctl compat_sys_ioctl ia32_sysret 3.37 ms 3.37 ms 65 i915_mutex_lock_interruptible i915_gem_wait_ioctl drm_ioctl i915_compat_ioctl compat_sys_ioctl ia32_sysret 2.58 ms 2.58 ms 65 i915_mutex_lock_interruptible i915_gem_do_execbuffer.isra.23 i915_gem_execbuffer2 drm_ioctl i915_compat_ioctl compat_sys_ioctl +ia32_sysret 2.19 ms 2.19 ms 65 i915_mutex_lock_interruptible intel_crtc_page_flip drm_mode_page_flip_ioctl drm_ioctl i915_compat_ioctl compat_sys_ioctl ia32_ +sysret 2.18 ms 2.18 ms 65 i915_mutex_lock_interruptible i915_gem_busy_ioctl drm_ioctl i915_compat_ioctl compat_sys_ioctl ia32_sysret 1.66 ms 1.66 ms 65 i915_gem_set_tiling drm_ioctl i915_compat_ioctl compat_sys_ioctl ia32_sysret It may not look like it, but this is quite a large difference, and I've been unable to reproduce > 5 msec delays at all, while before they do happen (just not in the trace above)." gem_gtt_hog on an old Pineview (GMA3150), before: 4969.119ms after: 4122.749ms Reported-by:
Arjan van de Ven <arjan.van.de.ven@intel.com> Testcase: igt/gem_gtt_hog Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by:
-
Imre Deak authored
Atm we call the handlers for pending pipestat interrupt events even if they aren't explicitly enabled by i915_enable_pipestat(). This isn't an issue for events other than the vblank start event, since those are always enabled anyways. Otoh, we enable the vblank start event on-demand, so we'll end up calling the vblank handler at times when they are disabled. I haven't checked if this causes any real problem, but for consistency and to remove some overhead we should still fix this by clearing / handling only the enabled interrupt events. Also this is a dependency for the upcoming VLV power domain patchset where we need to disable all the pipestat interrupts whenever the display power well is off. v2: - inline the status->enable mask mapping (Ville) - don't check for invalid PSR bit on platforms other than VLV (Ville) Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> [danvet: Frob conflict due to different merge order.] Signed-off-by:
-
Imre Deak authored
At least on VLV we can't get at the pipestat status bits by simply right shifting the corresponding enable bits. The mapping between enable and status bits for the sprite0,1 flip done and the PSR events don't follow this rule, so we need to map them separately. The PSR enable for pipe A is DPFLIPSTAT[22], but I haven't added support for this, since there is no user of it atm. Until support is added WARN if someone tries to enable PSR interrupts, or tries to enable the same (1 << 6) bit on pipe B, which MBZ. v2: - inline the status->enable mask mapping (Ville) - fix bogus use of status bits in enable mask (Ville) Signed-off-by:
-
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: -
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 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 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 4 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:
-
