- 10 Nov, 2016 1 commit
-
-
git://anongit.freedesktop.org/git/drm-intelDave Airlie authored
- gpu idling rework for s/r (Imre) - vlv mappable scanout fix - speed up probing in resume (Lyude) - dp audio workarounds for gen9 (Dhinakaran) - more conversion to using dev_priv internally (Ville) - more gen9+ wm fixes and cleanups (Maarten) - shrinker cleanup&fixes (Chris) - reorg plane init code (Ville) - implement support for multiple timelines (prep work for scheduler) from Chris and all - untangle dev->struct_mutex locking as prep for multiple timelines (Chris) - refactor bxt phy code and collect it all in intel_dpio_phy.c (Ander) - another gvt with bugfixes all over from Zhenyu - piles of lspcon fixes from Imre - 90/270 rotation fixes (Ville) - guc log buffer support (Akash+Sagar) - fbc fixes from Paulo - untangle rpm vs. tiling-fences/mmaps (Chris) - fix atomic commit to wait on the right fences (Daniel Stone) * tag 'drm-intel-next-2016-11-08' of git://anongit.freedesktop.org/git/drm-intel: (181 commits) drm/i915: Update DRIVER_DATE to 20161108 drm/i915: Mark CPU cache as dirty when used for rendering drm/i915: Add assert for no pending GPU requests during suspend/resume in LR mode drm/i915: Make sure engines are idle during GPU idling in LR mode drm/i915: Avoid early GPU idling due to race with new request drm/i915: Avoid early GPU idling due to already pending idle work drm/i915: Limit Valleyview and earlier to only using mappable scanout drm/i915: Round tile chunks up for constructing partial VMAs drm/i915: Remove the vma from the object list upon close drm/i915: Reinit polling before hpd when resuming drm/i915: Remove redundant reprobe in i915_drm_resume drm/i915/dp: Extend BDW DP audio workaround to GEN9 platforms drm/i915/dp: BDW cdclk fix for DP audio drm/i915: Fix pages pin counting around swizzle quirk drm/i915: Fix test on inputs for vma_compare() drm/i915/guc: Cache the client mapping drm/i915: Tidy slab cache allocations drm/i915: Introduce HAS_64BIT_RELOC drm/i915: Show the execlist queue in debugfs/i915_engine_info drm/i915: Unify global_list into global_link ...
-
- 08 Nov, 2016 1 commit
-
-
Daniel Vetter authored
Signed-off-by:Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 07 Nov, 2016 38 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:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> # v4.0+ Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161107165204.7008-1-chris@chris-wilson.co.uk
-
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:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
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>
-
git://github.com/skeggsb/linuxDave Airlie authored
- Initial atomic modesetting support. Used for "legacy" KMS interfaces, ioctl not exposed by default, but there is a commandline option to enable it. - Initial DP 1.2 MST support - Misc other code cleanups + fixes * 'linux-4.10' of git://github.com/skeggsb/linux: (64 commits) drm/nouveau/fifo/gf100-: protect channel preempt with subdev mutex drm/nouveau/gr: fallback to legacy paths during firmware lookup drm/nouveau/kms/nv50: initial support for DP 1.2 multi-stream drm/nouveau/kms/nv50: allow encoder update to be called from other modules drm/nouveau/kms/nv50: rename remaining nv50_crtc to nv50_head drm/nouveau/kms/nv50: remove code to create ctxdma for every framebuffer drm/nouveau/kms/nv50: remove code to support non-atomic page flips drm/nouveau/kms/nv50: remove code to support non-atomic connector properties drm/nouveau/kms/nv50: remove code to support non-atomic dpms drm/nouveau/kms/nv50: remove code to support non-atomic modesets drm/nouveau/kms/nv50: transition to atomic interfaces internally drm/nouveau/kms/nv50: turn mode_set_base_atomic() into a stub drm/nouveau/kms/nv50: convert encoder mode_fixup into an atomic_check() drm/nouveau/kms/nv50: clean-up encoder functions drm/nouveau/kms/nv50: ensure encoder normal power state is enabled at startup drm/nouveau/kms/nv50: prepare ctxdma interface to be usable with atomic drm/nouveau/kms/nv50: separate out cursor channel commit drm/nouveau/kms/nv50: separate out base channel commit drm/nouveau/kms/nv50: separate out vblank dmi commit drm/nouveau/kms/nv50: separate out procamp commit ...
-
Ben Skeggs authored
This avoids an issue that occurs when we're attempting to preempt multiple channels simultaneously. HW seems to ignore preempt requests while it's still processing a previous one, which, well, makes sense. Fixes random "fifo: SCHED_ERROR 0d []" + GPCCS page faults during parallel piglit runs on (at least) GM107. Signed-off-by:Ben Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org
-
Alexandre Courbot authored
Look for firmware files using the legacy ("nouveau/nvxx_fucxxxx") path if they cannot be found in the new, "official" path. User setups were broken by the switch, which is bad. There are only 4 firmware files we may want to look up that way, so hardcode them into the lookup function. All new firmware files should use the standard "nvidia/<chip>/gr/" path. Fixes: 8539b37a ("drm/nouveau/gr: use NVIDIA-provided external firmwares") Signed-off-by:Alexandre Courbot <acourbot@nvidia.com> Signed-off-by:
-
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
MST encoders will make use of this to share code with SOR> Signed-off-by: -
Ben Skeggs authored
No code changes, just renames + shuffles. Signed-off-by: -
Ben Skeggs authored
This is now handled by prepare_fb(). Legacy flips were the last user. Signed-off-by: -
Ben Skeggs authored
Made completely unreachable (and broken) by atomic commits. Signed-off-by: -
Ben Skeggs authored
Made completely unreachable by atomic commits. Signed-off-by: -
Ben Skeggs authored
Made completely unreachable (and broken) by atomic commits. Signed-off-by: -
Ben Skeggs authored
Make completely unreachable (and broken) by atomic commits. Signed-off-by: -
Ben Skeggs authored
This commit implements the atomic commit interfaces, and implements the legacy modeset and page flipping interfaces on top of them. There's two major changes in behavior from before: - We're now making use of interlocks between core and satellite EVO channels, which greatly improves our ability to keep their states synchronised. - DPMS is now implemented as a full modeset to either tear down the entire pipe (or bring it back up). This choice was made mostly to ease the initial implementation, but I'm also not sure what we gain by bring backing the old behaviour. We shall see. This does NOT currently expose the atomic ioctl by default, due to limited testing having been performed. Signed-off-by: -
Ben Skeggs authored
This cannot currently be supported with atomic modesettting. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Just a shuffle of blocks into an order consistent with the rest of the code, renaming hdmi/audio funtions for atomic, and removal of unused code. Signed-off-by: -
Ben Skeggs authored
To handle low-power DPMS states, we currently change an OR's (Output Resource) normal (active) power state to be off, leaving the rest of the display configured as usual. Under atomic modesetting, we will instead be doing a full modeset to tear down the pipe fully when entering a low-power state. As we'll no longer be touching the OR's PWR registers during runtime operation, we need to ensure the normal power state is set correctly during initialisation. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
This commit separates the calculation of EVO state from the commit, in order to make the same code useful for atomic modesetting. The legacy interfaces have been wrapped on top of them. Signed-off-by: -
Ben Skeggs authored
This commit separates the calculation of EVO state from the commit, in order to make the same code useful for atomic modesetting. The legacy interfaces have been wrapped on top of them. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
This commit separates the calculation of EVO state from the commit, in order to make the same code useful for atomic modesetting. The legacy interfaces have been wrapped on top of them. Signed-off-by: -
Ben Skeggs authored
This commit separates the calculation of EVO state from the commit, in order to make the same code useful for atomic modesetting. The legacy interfaces have been wrapped on top of them. Signed-off-by: -
Ben Skeggs authored
This commit separates the calculation of EVO state from the commit, in order to make the same code useful for atomic modesetting. The legacy interfaces have been wrapped on top of them. Signed-off-by: -
Ben Skeggs authored
This commit separates the calculation of EVO state from the commit, in order to make the same code useful for atomic modesetting. The legacy interfaces have been wrapped on top of them. We're no longer touching the overlay channel usage bounds as of this commit. The code to do so is in place for when overlay planes are added. Signed-off-by: -
Ben Skeggs authored
This commit separates the calculation of EVO state from the commit, in order to make the same code useful for atomic modesetting. The legacy interfaces have been wrapped on top of them. Signed-off-by: -
Ben Skeggs authored
This commit separates the calculation of EVO state from the commit, in order to make the same code useful for atomic modesetting. The legacy interfaces have been wrapped on top of them. Signed-off-by: -
Ben Skeggs authored
This commit separates the calculation of EVO state from the commit, in order to make the same code useful for atomic modesetting. The legacy interfaces have been wrapped on top of them. As of this commit, we're no longer bothering to point the core surface at a valid framebuffer. Prior to this, we'd initially point the core channel to the framebuffer passed in a mode_set()/mode_set_base(), and then use the base channel for any page-flip updates, leaving the core channel pointing at stale information. The important thing here is to configure the core surface parameters in such a way that EVO's error checking is satisfied. TL;DR: The situation isn't too much different to before. There may be brief periods of times during modesets where the (garbage) core surface will be showing. This issue will be resolved once support for atomic commits has been implemented and we're able to interlock the updates that involve multiple channels. Signed-off-by: -
Ben Skeggs authored
This commit separates the calculation of EVO state from the commit, in order to make the same code useful for atomic modesetting. The legacy interfaces have been wrapped on top of them. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Will be useful in debugging the transition to atomic. Signed-off-by:
-
