- 08 Nov, 2016 7 commits
-
-
https://github.com/01org/gvt-linuxDaniel Vetter authored
gvt-next-2016-11-07 - Fix regression from e95433c7 - Some MMIO handler fixes - Add better handling for guest reset control - stratch page table tree for shadow ppgtt Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com>
-
Ville Syrjälä authored
The code to determine the primary plane offset for gen2/3 looks different than the code for gen4+, but in fact it's doing the same thing. Let's make it uniform. Allows us to eliminate the 'obj' from the list of local variables as well. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1478550057-24864-6-git-send-email-ville.syrjala@linux.intel.comReviewed-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Ville Syrjälä authored
intel_cursor_plane_create() and intel_sprite_plane_create() return an error pointer, so let's not mistakenly look for a NULL pointer. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reported-by:
-
Ville Syrjälä authored
Use the passed in plane_state instead of plane->state in vlv_update_plane(). Currently the two are one and the same, but if we start queuing up multiple plane updates they might not be. Looks like this was rebase fail on my part. Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Fixes: 8d0deca8 ("drm/i915: Pass 90/270 vs. 0/180 rotation info for intel_gen4_compute_page_offset()") Signed-off-by:
-
Chris Wilson authored
We always flush the chipset prior to executing with the GPU, so we can skip the flush during ordinary domain management. This should help mitigate some of the potential performance regressions, but likely trivial, from doing the flush unconditionally before execbuf introduced in commit dcd79934 ("drm/i915: Unconditionally flush any chipset buffers before execbuf") Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
Joonas Lahtinen authored
Get rid of sloppy inline functions now that we don't have more users: i915_gem_request_get_seqno i915_gem_request_get_engine v2: - request->engine is always non-NULL (Chris) Signed-off-by:
-
Daniel Vetter authored
Signed-off-by:Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 07 Nov, 2016 16 commits
-
-
Chris Wilson authored
On LLC, or even snooped, machines rendering via the GPU ends up in the CPU cache. This cacheline dirt also needs to be flushed to main memory when moving to an incoherent domain, such as the display's scanout engine. Mostly, this happens because either the object is marked as dirty from its first use or is avoided by setting the object into the display domain from the start. v2: Treat WT as not requiring a clflush prior to use on the display engine as well. Fixes: 0f71979a ("drm/i915: Performed deferred clflush inside set-cache-level") References: https://bugs.freedesktop.org/show_bug.cgi?id=95414Signed-off-by:
-
Imre Deak authored
During resume we will reset the SW/HW tracking for each ring head/tail pointers and so are not prepared to replay any pending requests (as opposed to GPU reset time). Add an assert for this both to the suspend and the resume code. v2: - Check for ELSP port idle already during suspend and check !gt.awake during resume. (Chris) v3: - Move the !gt.awake check to i915_gem_resume(). v4: - s/intel_lr_engines_idle/intel_execlists_idle/ (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Imre Deak authored
We assume that the GPU is idle once receiving the seqno via the last request's user interrupt. In execlist mode the corresponding context completed interrupt can be delayed though and until this latter interrupt arrives we consider the request to be pending on the ELSP submit port. This can cause a problem during system suspend where this last request will be seen by the resume code as still pending. Such pending requests are normally replayed after a GPU reset, but during resume we reset both SW and HW tracking of the ring head/tail pointers, so replaying the pending request with its stale tail pointer will leave the ring in an inconsistent state. A subsequent request submission can lead then to the GPU executing from uninitialized area in the ring behind the above stale tail pointer. Fix this by making sure any pending request on the ELSP port is completed before suspending. I used a polling wait since the completion time I measured was <1ms and since normally we only need to wait during system suspend. GPU idling during runtime suspend is scheduled with a delay (currently 50-100ms) after the retirement of the last request at which point the context completed interrupt must have arrived already. The chance of this bug was increased by commit 1c777c5d Author: Imre Deak <imre.deak@intel.com> Date: Wed Oct 12 17:46:37 2016 +0300 drm/i915/hsw: Fix GPU hang during resume from S3-devices state but it could happen even without the explicit GPU reset, since we disable interrupts afterwards during the suspend sequence. v2: - Do an unlocked poll-wait first. (Chris) v3-4: - s/intel_lr_engines_idle/intel_execlists_idle/ and move i915.enable_execlists check to the new helper. (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98470Signed-off-by:
-
Imre Deak authored
There is a small race where a new request can be submitted and retired after the idle worker started to run which leads to idling the GPU too early. Fix this by deferring the idling to the pending instance of the worker. This scenario was pointed out by Chris. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Imre Deak authored
Atm, in case an idle work handler is already pending but haven't yet started to run, retiring a new request will not extend the active period as required, rather simply leaves the pending idle work to be scheduled at the original expiration time. This may lead to idling the GPU too early. Fix this by using the delayed-work scheduler alternative which makes sure the handler's expiration time is extended in this case. Cc: Chris Wilson <chris@chris-wilson.co.uk> Requested-by:
-
Chris Wilson authored
Valleyview appears to be limited to only scanning out from the first 512MiB of the Global GTT. Lets presume that this behaviour was inherited from the display block copied from g4x (not Ironlake) and all earlier generations are similarly affected, though testing suggests different symptoms. For simplicity, impose that these platforms must scanout from the mappable region. (For extra simplicity, use HAS_GMCH_DISPLAY even though this catches Cherryview which does not appear to be limited to the low aperture for its scanout.) v2: Use HAS_GMCH_DISPLAY() to more clearly convey my intent about limiting this workaround to the old style of display engine. v3: Update changelog to reflect testing by Ville Syrjälä v4: Include the changes to the comments as well Reported-by:
Luis Botello <luis.botello.ortega@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98036 Fixes: 2efb813d ("drm/i915: Fallback to using unmappable memory for scanout") Signed-off-by:
-
Chris Wilson authored
When we split a large object up into chunks for GTT faulting (because we can't fit the whole object into the aperture) we have to align our cuts with the fence registers. Each partial VMA must cover a complete set of tile rows or the offset into each partial VMA is not aligned with the whole image. Currently we enforce a minimum size on each partial VMA, but this minimum size itself was not aligned to the tile row causing distortion. Reported-by:
Andreas Reis <andreas.reis@gmail.com> Reported-by:
Chris Clayton <chris2553@googlemail.com> Reported-by:
Norbert Preining <preining@logic.at> Tested-by:
-
Chris Wilson authored
Currently, the vma is being unlink from the object lookup on destroy. However, we are meant to be decoupling it upon close so that the user cannot access the closed vma whilst it remains active on the GPU. [ 34.074858] kernel BUG at drivers/gpu/drm/i915/i915_gem_gtt.c:3561! [ 34.074875] invalid opcode: 0000 [#1] PREEMPT SMP [ 34.074888] Modules linked in: snd_hda_intel i915 x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel lpc_ich mei_me mei snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_codec snd_hwdep snd_hda_core i2c_designware_platform i2c_designware_core snd_pcm e1000e ptp pps_core sdhci_acpi sdhci mmc_core i2c_hid [last unloaded: i915] [ 34.075010] CPU: 1 PID: 6224 Comm: gem_close_race Tainted: G U 4.9.0-rc3-CI-CI_DRM_1800+ #1 [ 34.075034] Hardware name: /NUC5i7RYB, BIOS RYBDWi35.86A.0355.2016.0224.1501 02/24/2016 [ 34.075057] task: ffff8802459a8040 task.stack: ffffc90000524000 [ 34.075074] RIP: 0010:[<ffffffffa0392cbc>] [<ffffffffa0392cbc>] i915_gem_obj_lookup_or_create_vma+0x8c/0xc0 [i915] [ 34.075118] RSP: 0018:ffffc90000527b68 EFLAGS: 00010202 [ 34.075135] RAX: ffff8802426c5e40 RBX: 0000000000000000 RCX: ffff8802447fc2a8 [ 34.075158] RDX: 0000000000000000 RSI: ffff8802447fc2a8 RDI: ffff880248a4a880 [ 34.075181] RBP: ffffc90000527b88 R08: 0000000000000008 R09: 0000000000000000 [ 34.075203] R10: 0000000000000001 R11: 0000000000000000 R12: ffff880248a4a880 [ 34.075225] R13: ffff8802447fc2a8 R14: ffff880243e9afa8 R15: ffff880248a4a9c8 [ 34.075248] FS: 00007f9b43e59740(0000) GS:ffff880256c80000(0000) knlGS:0000000000000000 [ 34.075273] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 34.075292] CR2: 00007f9b43419140 CR3: 000000024455d000 CR4: 00000000003406e0 [ 34.075314] Stack: [ 34.075323] 0000000000000000 ffffc90000527bd0 ffff880243cb8008 ffff880243e9afa8 [ 34.075353] ffffc90000527c08 ffffffffa03874c7 ffffc90000527bb8 ffff880243e9afa8 [ 34.075383] ffff880243e9afb0 ffffc90000527e10 ffff8802447fc2a8 ffff880243cb8040 [ 34.075414] Call Trace: [ 34.075435] [<ffffffffa03874c7>] eb_lookup_vmas.isra.7+0x247/0x330 [i915] [ 34.075468] [<ffffffffa0388c34>] i915_gem_do_execbuffer.isra.15+0x604/0x1a10 [i915] [ 34.075507] [<ffffffffa039c957>] ? i915_gem_object_get_sg+0x347/0x380 [i915] [ 34.075532] [<ffffffff811a69ce>] ? __might_fault+0x3e/0x90 [ 34.075562] [<ffffffffa038a430>] i915_gem_execbuffer2+0xc0/0x250 [i915] [ 34.075585] [<ffffffff81552926>] drm_ioctl+0x1f6/0x480 [ 34.075604] [<ffffffff8100107a>] ? trace_hardirqs_on_thunk+0x1a/0x1c [ 34.075635] [<ffffffffa038a370>] ? i915_gem_execbuffer+0x330/0x330 [i915] [ 34.075658] [<ffffffff81202d2e>] do_vfs_ioctl+0x8e/0x690 [ 34.075677] [<ffffffff8181582d>] ? _raw_spin_unlock_irqrestore+0x3d/0x60 [ 34.075700] [<ffffffff810fcd51>] ? SyS_timer_settime+0x141/0x1e0 [ 34.075721] [<ffffffff810d6de2>] ? trace_hardirqs_on_caller+0x122/0x1b0 [ 34.075742] [<ffffffff8120336c>] SyS_ioctl+0x3c/0x70 [ 34.075760] [<ffffffff8181602e>] entry_SYSCALL_64_fastpath+0x1c/0xb1 [ 34.075781] Code: 44 a0 48 c7 c2 9a 7e 43 a0 be e0 0d 00 00 48 c7 c7 a0 45 44 a0 e8 55 b8 ce e0 48 85 db 74 a3 49 83 bd f8 03 00 00 00 74 99 0f 0b <0f> 0b 48 89 da 4c 89 ee 4c 89 e7 e8 04 a9 ff ff 48 89 da 49 89 [ 34.075955] RIP [<ffffffffa0392cbc>] i915_gem_obj_lookup_or_create_vma+0x8c/0xc0 [i915] [ 34.075994] RSP <ffffc90000527b68> Testcase: igt/gem_close_race/basic-threads Fixes: db6c2b41 ("drm/i915: Store the vma in an rbtree...") Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com>
-
Ping Gao authored
All the unused entries in the page table tree(PML4E->PDPE->PDE->PTE) should point to scratch page table/scratch page to avoid page walk error due to the page prefetching. When removing an entry in shadow PPGTT, it need map to scratch page also, the older implementation use single scratch page to assign to all level entries, it doesn't align the page walk behavior when removed entry is in PML, PDP, PD. To avoid potential page walk error this patch implement a scratch page tree to replace the single scratch page. v2: more details in commit message address Kevin's comments. Signed-off-by:
Ping Gao <ping.a.gao@intel.com> Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com>
-
Du, Changbin authored
When SW wishes to reset the render engine, it will program engine's reset control register and wait response from HW. We need emulate the behavior of this register so guest i915 driver could walk through the engine reset flow. The registers are not emulated in gvt yet, this patch add the emulation logic. v2: add more desc info in commit message. Signed-off-by:
Zhi Wang <zhi.a.wang@intel.com> Signed-off-by:
Du, Changbin <changbin.du@intel.com> Signed-off-by:
-
Zhenyu Wang authored
From commit e95433c7, workload status setting was changed to only capture on error path, but we need to set it properly in normal path too, otherwise we'll fail to complete workload which could lead guest VM vGPU reset. v2: uses braces and add Fixes tag. Fixes: e95433c7 ("drm/i915: Rearrange i915_wait_request() accounting with callers") Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Ping Gao authored
Misc ctl related registers are for WA purpose, should detect the stepping info first before updating HW value. Signed-off-by:
-
Ping Gao authored
Need a explicit write_vreg in TLB MMIO write handler, beside that TLB vreg should update correspondingly following HW status to do correct emulation. Signed-off-by:
-
Ping Gao authored
Missing write_vreg in DMA_CTRL write handler would make obsolete value return when read vreg. v2: get data from vreg after updating it. Signed-off-by:
-
Ping Gao authored
Remove the variable 'execlist' as it's unused in function vgpu_has_pending_workload. Signed-off-by:
-
Zhenyu Wang authored
This is to fix smatch warning on drivers/gpu/drm/i915/gvt/cmd_parser.c:1421 cmd_handler_mi_op_2f() warn: shift has higher precedence than mask We need bits 20-19 mask for data size. Cc: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
- 04 Nov, 2016 5 commits
-
-
Lyude authored
Now that we don't run the connector reprobing from i915_drm_resume(), we need to make it so we don't have to wait for reprobing to finish so that we actually speed things up. In order to do this, we need to make sure that i915_drm_resume() doesn't get blocked by i915_hpd_poll_init_work() while trying to acquire the mode_config lock that drm_kms_helper_poll_enable() needs to acquire. The easiest way to do this is to just enable polling before hpd. This shouldn't break anything since at that point we have everything else we need for polling enabled. As well, this should result in a rather significant improvement in how quickly we can resume the system. Signed-off-by:
Lyude <lyude@redhat.com> Tested-by:
David Weinehall <david.weinehall@linux.intel.com> Reviewed-by:
-
Lyude authored
Weine's investigation on benchmarking the suspend/resume process pointed out a lot of the time in suspend/resume is being spent reprobing. While the reprobing process is a lengthy one for good reason, we don't need to hold up the entire suspend/resume process while we wait for it to finish. Luckily as it turns out, we already trigger a full connector reprobe in i915_hpd_poll_init_work(), so we can just ditch reprobing in i915_drm_resume() entirely. This won't lead to less time spent resuming just yet since now the bottleneck will be waiting for the mode_config lock in drm_kms_helper_poll_enable(), since that will be held as long as i915_hpd_poll_init_work() is reprobing all of the connectors. But we'll address that in the next patch. Signed-off-by:
-
Dhinakaran Pandiyan authored
According to BSpec, cdclk for BDW has to be not less than 432 MHz with DP audio enabled, port width x4, and link rate HBR2 (5.4 GHz). With cdclk less than 432 MHz, enabling audio leads to pipe FIFO underruns and displays cycling on/off. Let's apply this work around to GEN9 platforms too, as it fixes the same issue. v2: Move drm_device to drm_i915_private conversion Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97907 Cc: stable@vger.kernel.org Cc: Libin Yang <libin.yang@linux.intel.com> Signed-off-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Dhinakaran Pandiyan authored
According to BSpec, cdclk for BDW has to be not less than 432 MHz with DP audio enabled, port width x4, and link rate HBR2 (5.4 GHz). With cdclk less than 432 MHz, enabling audio leads to pipe FIFO underruns and displays cycling on/off. From BSpec: "Display» BDW-SKL» dpr» [Register] DP_TP_CTL [BDW+,EXCLUDE(CHV)] Workaround : Do not use DisplayPort with CDCLK less than 432 MHz, audio enabled, port width x4, and link rate HBR2 (5.4 GHz), or else there may be audio corruption or screen corruption." Since, some DP configurations (e.g., MST) use port width x4 and HBR2 link rate, let's increase the cdclk to >= 432 MHz to enable audio for those cases. v4: Changed commit message v3: Combine BDW pixel rate adjustments into a function (Jani) v2: Restrict fix to BDW Retain the set cdclk across modesets (Ville) Cc: stable@vger.kernel.org Signed-off-by: -
Chris Wilson authored
commit bc0629a7 ("drm/i915: Track pages pinned due to swizzling quirk") fixed one problem, but revealed a whole lot more. The root cause of the pin count mismatch for the swizzle quirk (for L-shaped memory on gen3/4) was that we were incrementing the pages_pin_count upon getting the backing pages but then overwriting the pages_pin_count to set it to 1 afterwards. With a little bit of adjustment to satisfy the GEM_BUG_ON sanitychecks, the fix is to replace the explicit atomic_set with an atomic_inc. v2: Consistently use atomics (not mix atomics and helpers) within the lowlevel get_pages routines. This makes the atomic operations much clearer. Fixes: 1233e2db ("drm/i915: Move object backing storage manipulation") Signed-off-by:
-
- 03 Nov, 2016 4 commits
-
-
Chris Wilson authored
When supplying a view to vma_compare() it is required that the supplied i915_address_space is the global GTT. I tested the VMA instead (which is the current position in the rbtree and maybe from any address space). Reported-by:
Matthew Auld <matthew.auld@intel.com> Tested-by:
-
Chris Wilson authored
Use i915_gem_object_pin_map() for the guc client's lifetime to replace the peristent kmap + frequent kmap_atomic with a permanent vmapping. This avoids taking the obj->mm.lock mutex whilst inside irq context later. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98571 Fixes: 96d77634 ("drm/i915: Use a radixtree for random access..."); Signed-off-by:
-
Tvrtko Ursulin authored
We can use the preferred KMEM_CACHE helper for brevity. Also simplifiy error unwind by only setting the ENOMEM error code once. v2: Add forgotten changes. (Joonas Lahtinen) Signed-off-by:
-
Joonas Lahtinen authored
Move has_64bit_reloc into dev_priv->info. This will make it visible in the feature listing debug output. v2: - Keep the struct member to keep GCC fragile but happy (Chris) v3: - More detailed commit message (Chris) - Include forgotten CHV and BXT (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
- 02 Nov, 2016 6 commits
-
-
Chris Wilson authored
When looking at freezes whilst working on execlists, knowing the order of the pending requests in the driver is useful. Signed-off-by:
-
Joonas Lahtinen authored
$ sed -i -r 's/\bglobal_list\b/global_link/g' *.c *.h Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Mika Kuoppala authored
Create new file for hangcheck specific code, intel_hangcheck.c, and move all related code in it. v2: s/intel_engine_hangcheck/intel_engine (Chris) No functional changes. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by:
-
Mika Kuoppala authored
Now when clearing ptes can modify upper level pdp's, we need to mark them dirty so that they will be flushed correctly. Reviewed-by:
-
Mika Kuoppala authored
Comparing pte index to a number of entries is wrong when clearing a range of pte entries. Use end marker of 'one past' to correctly point adequate number of ptes to the scratch page. v2: assert early instead of warning late (Chris) v3: removed consts (Joonas) Fixes: d209b9c3 ("drm/i915/gtt: Split gen8_ppgtt_clear_pte_range") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98282 Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Reported-by:
Mike Lothian <mike@fireburn.co.uk> Signed-off-by:
-
Ander Conselvan de Oliveira authored
Hardware engineers confirmed that writing to it has no effect, as implied by the FIXME comment. v2: Also remove comment from bxt_ddi_phy_verify_state(). (Imre) Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by:
-
- 01 Nov, 2016 2 commits
-
-
Tvrtko Ursulin authored
Commit 1bec9b0b ("drm/i915/shrinker: Only shmemfs objects are backed by swap") stopped considering the userptr objects in shrinker callbacks. Restore that so idle userptr objects can be discarded in order to free up memory. One change further to what was introduced in 1bec9b0b is to start considering userptr objects in oom but that should also be a correct thing to do. v2: Introduce I915_GEM_OBJECT_IS_SHRINKABLE. (Chris Wilson) Signed-off-by:
-
Ville Syrjälä authored
Unify our approach to things by passing around dev_priv instead of dev. Signed-off-by:
-
