summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm
AgeCommit message (Collapse)Author
2018-12-13drm/dp_mst: Fix memory leak in drm_dp_mst_topology_mgr_destroy()Lyude Paul
We need to call drm_dp_mst_topology_mgr_set_mst(mgr, false) when destroying the topology manager in order to ensure that the root mstb and all of it's descendents are actually destroyed, and additionally to try to make sure that we leave the hub in a clean state. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20181211235026.21758-1-lyude@redhat.com
2018-12-13drm: Rename crtc_idr as object_idr to KMS cleanupsShayenne da Luz Moura
This patch solves this TODO task: drm_mode_config.crtc_idr is misnamed, since it contains all KMS object. Should be renamed to drm_mode_config.object_idr. Signed-off-by: Shayenne da Luz Moura <shayenneluzmoura@gmail.com> [danvet: resolve conflict with addition of privobj_list.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20181213212957.vkitkyl5cj2qh7qr@smtp.gmail.com
2018-12-13dma-mapping: bypass indirect calls for dma-directChristoph Hellwig
Avoid expensive indirect calls in the fast path DMA mapping operations by directly calling the dma_direct_* ops if we are using the directly mapped DMA operations. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Jesper Dangaard Brouer <brouer@redhat.com> Tested-by: Jesper Dangaard Brouer <brouer@redhat.com> Tested-by: Tony Luck <tony.luck@intel.com>
2018-12-14Merge branch 'vmwgfx-fixes-4.20' of ↵Dave Airlie
git://people.freedesktop.org/~thomash/linux into drm-fixes One regression fix for avoiding kernel OOM, one cleanup return fix. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Hellstrom <thellstrom@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181213122815.10581-1-thellstrom@vmware.com
2018-12-14Merge tag 'vmwgfx-next-2018-12-13' of ↵Dave Airlie
git://people.freedesktop.org/~thomash/linux into drm-next Pull request of 2018-12-13 Two minor fixes for next pull. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Hellstrom <thellstrom@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181213130848.3080-1-thellstrom@vmware.com
2018-12-13drm/i915: Fix Cherryview oops on bootChris Wilson
Do not dereference the LUT blob before checking whether that blob exists. Or else, <1>[ 13.978684] BUG: unable to handle kernel NULL pointer dereference at 0000000000000048 <6>[ 13.978718] PGD 0 P4D 0 <4>[ 13.978733] Oops: 0000 [#1] PREEMPT SMP PTI <4>[ 13.978750] CPU: 0 PID: 282 Comm: modprobe Not tainted 4.20.0-rc5-CI-CI_DRM_5294+ #1 <4>[ 13.978773] Hardware name: /NUC5CPYB, BIOS PYBSWCEL.86A.0058.2016.1102.1842 11/02/2016 <4>[ 13.978932] RIP: 0010:cherryview_load_csc_matrix+0x1e6/0x210 [i915] <4>[ 13.978953] Code: 41 5c 41 5d e9 7b 83 aa e1 41 c1 e4 0d 48 83 bd 00 02 00 00 00 48 8b 85 10 02 00 00 45 89 e5 74 09 ba 01 00 00 00 31 c9 eb 9d <48> 8b 50 48 48 c1 ea 03 81 fa 00 01 00 00 75 07 31 d2 48 85 c0 75 <4>[ 13.979001] RSP: 0018:ffffc9000026f840 EFLAGS: 00010246 <4>[ 13.979018] RAX: 0000000000000000 RBX: ffff888165500000 RCX: 7885fe6200000000 <4>[ 13.979039] RDX: 0000000000000020 RSI: ffff88816553a008 RDI: ffff888165464a88 <4>[ 13.979060] RBP: ffff888165464a88 R08: 000000000ed0e429 R09: 0000000000000001 <4>[ 13.979080] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000004000 <4>[ 13.979101] R13: 0000000000004000 R14: ffff888165500000 R15: ffff888165464a88 <4>[ 13.979122] FS: 00007fb69c4f3540(0000) GS:ffff88817ba00000(0000) knlGS:0000000000000000 <4>[ 13.979146] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4>[ 13.979163] CR2: 0000000000000048 CR3: 000000016d7fa000 CR4: 00000000001006f0 <4>[ 13.979184] Call Trace: <4>[ 13.979302] intel_update_crtc+0x18f/0x2b0 [i915] <4>[ 13.979421] intel_update_crtcs+0x49/0x60 [i915] <4>[ 13.979538] intel_atomic_commit_tail+0x1ea/0xd70 [i915] <4>[ 13.979657] ? intel_atomic_commit_ready+0x3f/0x50 [i915] <4>[ 13.979762] ? __i915_sw_fence_complete+0x1a0/0x250 [i915] <4>[ 13.979884] intel_atomic_commit+0x244/0x330 [i915] <4>[ 13.980002] intel_initial_commit+0xb6/0x140 [i915] <4>[ 13.980127] intel_modeset_init+0x7a1/0x1880 [i915] <4>[ 13.980235] i915_driver_load+0xcbb/0x15c0 [i915] <4>[ 13.980257] ? __pm_runtime_resume+0x4f/0x80 <4>[ 13.980277] ? _raw_spin_unlock_irqrestore+0x4c/0x60 <4>[ 13.980296] ? lockdep_hardirqs_on+0xe0/0x1b0 <4>[ 13.980401] i915_pci_probe+0x29/0xa0 [i915] <4>[ 13.980421] pci_device_probe+0xa1/0x130 <4>[ 13.980440] really_probe+0xf3/0x3e0 <4>[ 13.980456] driver_probe_device+0x10a/0x120 <4>[ 13.980474] __driver_attach+0xdb/0x100 <4>[ 13.980489] ? driver_probe_device+0x120/0x120 <4>[ 13.980505] ? driver_probe_device+0x120/0x120 <4>[ 13.980522] bus_for_each_dev+0x74/0xc0 <4>[ 13.980539] bus_add_driver+0x15f/0x250 <4>[ 13.980554] ? 0xffffffffa0348000 <4>[ 13.980568] driver_register+0x56/0xe0 <4>[ 13.980583] ? 0xffffffffa0348000 <4>[ 13.980597] do_one_initcall+0x58/0x2e0 <4>[ 13.980615] ? do_init_module+0x1d/0x1ea <4>[ 13.980631] ? rcu_read_lock_sched_held+0x6f/0x80 <4>[ 13.980649] ? kmem_cache_alloc_trace+0x264/0x290 <4>[ 13.980668] do_init_module+0x56/0x1ea <4>[ 13.980685] load_module+0x227a/0x29c0 <4>[ 13.980715] ? __se_sys_finit_module+0xd3/0xf0 <4>[ 13.980731] __se_sys_finit_module+0xd3/0xf0 <4>[ 13.980756] do_syscall_64+0x55/0x190 <4>[ 13.980772] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4>[ 13.980789] RIP: 0033:0x7fb69c019839 <4>[ 13.980804] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 1f f6 2c 00 f7 d8 64 89 01 48 <4>[ 13.980851] RSP: 002b:00007ffdc112e3a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 <4>[ 13.980875] RAX: ffffffffffffffda RBX: 000055c689fe0b30 RCX: 00007fb69c019839 <4>[ 13.980895] RDX: 0000000000000000 RSI: 000055c689a05d2e RDI: 0000000000000000 <4>[ 13.980916] RBP: 000055c689a05d2e R08: 0000000000000000 R09: 0000000000000000 <4>[ 13.980936] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 <4>[ 13.980957] R13: 000055c689fe0c60 R14: 0000000000040000 R15: 000055c689fe0b30 <4>[ 13.980986] Modules linked in: i915(+) snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm pinctrl_cherryview prime_numbers <4>[ 13.981027] CR2: 0000000000000048 Fixes: 302da0cdf784 ("drm/i915: Use intel_ types more consistently for color management code (v2)") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109054 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181213161241.3461-1-chris@chris-wilson.co.uk
2018-12-13drm/vmwgfx: Protect from excessive execbuf kernel memory allocations v3Thomas Hellstrom
With the new validation code, a malicious user-space app could potentially submit command streams with enough buffer-object and resource references in them to have the resulting allocated validion nodes and relocations make the kernel run out of GFP_KERNEL memory. Protect from this by having the validation code reserve TTM graphics memory when allocating. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Deepak Rawat <drawat@vmware.com> --- v2: Removed leftover debug printouts
2018-12-13drm/i915/icl: Mind the SFC units when resetting VD or VEBox enginesOscar Mateo
SFC (Scaler & Format Converter) units are shared between VD and VEBoxes. They also happen to have separate reset bits. So, whenever we want to reset one or more of the media engines, we have to make sure the SFCs do not change owner in the process and, if this owner happens to be one of the engines being reset, we need to reset the SFC as well. This happens in 4 steps: 1) Tell the engine that a software reset is going to happen. The engine will then try to force lock the SFC (if currently locked, it will remain so; if currently unlocked, it will ignore this and all new lock requests). 2) Poll the ack bit to make sure the hardware has received the forced lock from the driver. Once this bit is set, it indicates SFC status (lock or unlock) will not change anymore (until we tell the engine it is safe to unlock again). 3) Check the usage bit to see if the SFC has ended up being locked to the engine we want to reset. If this is the case, we have to reset the SFC as well. 4) Unlock all the SFCs once the reset sequence is completed. Obviously, if we are resetting the whole GPU, we don't have to worry about all of this. BSpec: 10989 BSpec: 10990 BSpec: 10954 BSpec: 10955 BSpec: 10956 BSpec: 19212 Signed-off-by: Tomasz Lis <tomasz.lis@intel.com> Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by: Michel Thierry <michel.thierry@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181213091522.2926-4-chris@chris-wilson.co.uk
2018-12-13drm/i915/icl: Record the valid VDBoxes with SFC capabilityOscar Mateo
In Gen11, only even numbered "logical" VDBoxes are hooked up to an SFC (Scaler & Format Converter) unit. We will use this information to decide when the SFC units need to be reset. BSpec: 20189 Signed-off-by: Tomasz Lis <tomasz.lis@intel.com> Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by: Michel Thierry <michel.thierry@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181213091522.2926-3-chris@chris-wilson.co.uk
2018-12-13drm/i915/selftests: Verify we can perform resets from atomic contextChris Wilson
We currently require that our per-engine reset can be called from any context, even hardirq, and in the future wish to perform the device reset without holding struct_mutex (which requires some lockless shenanigans that demand the lowlevel intel_reset_gpu() be able to be used in atomic context). Test that we meet the current requirements by calling i915_reset_engine() from under various atomic contexts. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181213091522.2926-2-chris@chris-wilson.co.uk
2018-12-13drm/i915/selftests: Check we can recover a wedged deviceChris Wilson
After declaring a terminally wedged device, we allow ourselves to recover on the next GPU reset (manually triggered), or resume. Check that resetting a wedged device does work. v2: Add rpm (taken explicitly in the subtest in case we remove the outer wakeref) and early warning to i915_reset() for missed wakerefs Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181213091522.2926-1-chris@chris-wilson.co.uk
2018-12-12drm/i915: merge gen checks to use rangeLucas De Marchi
Instead of using IS_GEN() for consecutive gen checks, let's pass the range to IS_GEN_RANGE(). By code inspection these were the ranges deemed necessary for spatch: @@ expression e; @@ ( - IS_GEN(e, 3) || IS_GEN(e, 2) + IS_GEN_RANGE(e, 2, 3) | - IS_GEN(e, 3) || IS_GEN(e, 4) + IS_GEN_RANGE(e, 3, 4) | - IS_GEN(e, 5) || IS_GEN(e, 6) + IS_GEN_RANGE(e, 5, 6) | - IS_GEN(e, 6) || IS_GEN(e, 7) + IS_GEN_RANGE(e, 6, 7) | - IS_GEN(e, 7) || IS_GEN(e, 8) + IS_GEN_RANGE(e, 7, 8) | - IS_GEN(e, 8) || IS_GEN(e, 9) + IS_GEN_RANGE(e, 8, 9) | - IS_GEN(e, 10) || IS_GEN(e, 9) + IS_GEN_RANGE(e, 9, 10) | - IS_GEN(e, 9) || IS_GEN(e, 10) + IS_GEN_RANGE(e, 9, 10) ) After conversion, checking we don't have any missing IS_GEN_RANGE() || IS_GEN() was also done. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181212181044.15886-3-lucas.demarchi@intel.com
2018-12-12drm/i915: replace IS_GEN<N> with IS_GEN(..., N)Lucas De Marchi
Define IS_GEN() similarly to our IS_GEN_RANGE(). but use gen instead of gen_mask to do the comparison. Now callers can pass then gen as a parameter, so we don't require one macro for each gen. The following spatch was used to convert the users of these macros: @@ expression e; @@ ( - IS_GEN2(e) + IS_GEN(e, 2) | - IS_GEN3(e) + IS_GEN(e, 3) | - IS_GEN4(e) + IS_GEN(e, 4) | - IS_GEN5(e) + IS_GEN(e, 5) | - IS_GEN6(e) + IS_GEN(e, 6) | - IS_GEN7(e) + IS_GEN(e, 7) | - IS_GEN8(e) + IS_GEN(e, 8) | - IS_GEN9(e) + IS_GEN(e, 9) | - IS_GEN10(e) + IS_GEN(e, 10) | - IS_GEN11(e) + IS_GEN(e, 11) ) v2: use IS_GEN rather than GT_GEN and compare to info.gen rather than using the bitmask Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181212181044.15886-2-lucas.demarchi@intel.com
2018-12-12drm/i915: Rename IS_GEN to IS_GEN_RANGELucas De Marchi
RANGE makes it longer, but clearer. We are also going to add a macro to check an individual gen, so add the _RANGE prefix here. Diff generated with: sed 's/IS_GEN(/IS_GEN_RANGE(/g' drivers/gpu/drm/i915/{*/,}*.{c,h} -i v2: use IS_GEN rather than GT_GEN Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181212181044.15886-1-lucas.demarchi@intel.com
2018-12-13Merge tag 'drm-msm-next-2018-12-12' of ↵Dave Airlie
git://people.freedesktop.org/~robclark/linux into drm-next This time around, seeing some love for some older hw: - a2xx gpu support for apq8060 (hp touchpad) and imx5 (headless gpu-only mode) - a2xx gpummu support (a2xx was pre-iommu) - mdp4 display support for apq8060/touchpad For display/dpu: - a big pile of continuing dpu fixes and cleanups On the gpu side of things: - per-submit statistics and traceevents for better profiling - a6xx crashdump support - decouple get_iova() and page pinning.. so we can unpin from physical memory inactive bo's while using softpin to lower cpu overhead - new interface to set debug names on GEM BOs and debugfs output improvements - additional submit flag to indicate buffers that are used to dump (so $debugfs/rd cmdstream dumping is useful with softpin + state-objects) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rob Clark <robdclark@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/CAF6AEGvVvLPD9_Z4kyfGe98Y--byj6HbxHivEYSgF7Rq7=bFnw@mail.gmail.com
2018-12-13Merge branch 'linux-4.21' of git://github.com/skeggsb/linux into drm-nextDave Airlie
Mostly just initial support for Turing TU104/TU106 chipsets. Support for TU102 is missing as I don't yet have HW, but it should be trivial to add in later in the merge window (in theory). It's a bit of a rough first pass that'll get improved in future releases as a finish figuring out some of the other HW changes, but it's good enough as it stands for modesetting and suspend/resume etc. Acceleration bring-up is incomplete due to NVIDIA not yet having provided FW images for me to use, though command submission and copy engines are functional already. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Ben Skeggs <skeggsb@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/CACAvsv7KmfcQqZcx+wh_1UKjTovp4PH_5UVMfeyxUu-M9WLZfw@mail.gmail.com
2018-12-13Merge tag 'drm/tegra/for-4.21-rc1' of ↵Dave Airlie
git://anongit.freedesktop.org/tegra/linux into drm-next drm/tegra: Changes for v4.21-rc1 These changes contain a couple of minor fixes for host1x and the Falcon library in Tegra DRM. There are also a couple of missing pieces that finally enable support for host1x, VIC and display on Tegra194. I've also added a patch that enables audio over HDMI using the SOR which has been tested, and works, on both Tegra186 and Tegra194. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thierry Reding <thierry.reding@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181207134712.32683-1-thierry.reding@gmail.com
2018-12-13Merge branch 'drm-next-4.21' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie
into drm-next [airlied: make etnaviv build again] amdgpu: - DC trace support - More DC documentation - XGMI hive reset support - Rework IH interaction with KFD - Misc fixes and cleanups - Powerplay updates for newer polaris variants - Add cursor plane update fast path - Enable gpu reset by default on CI parts - Fix config with KFD/HSA not enabled amdkfd: - Limit vram overcommit - dmabuf support - Support for doorbell BOs ttm: - Support for simultaneous submissions to multiple engines scheduler: - Add helpers for hw with preemption support Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181207233119.16861-1-alexander.deucher@amd.com
2018-12-13Merge branch 'mediatek-drm-fixes-4.20' of ↵Dave Airlie
https://github.com/ckhu-mediatek/linux.git-tags into drm-fixes Single bridge attachment fix. Signed-off-by: Dave Airlie <airlied@redhat.com> From: CK Hu <ck.hu@mediatek.com> Link: https://patchwork.freedesktop.org/patch/msgid/1544407975.18825.3.camel@mtksdaap41
2018-12-13Merge branch 'linux-4.20' of git://github.com/skeggsb/linux into drm-fixesDave Airlie
Three fixes: tegra regression fix display flushing fix mst cleanup fix. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Ben Skeggs <skeggsb@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/CACAvsv7WCPzjQZonk+eS1FgEUKirz-4LOrVpMUVMM=D-GjbVpg@mail.gmail.com
2018-12-13Merge branch 'drm-fixes-4.20' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie
into drm-fixes Fixes for 4.20: - Stability fixes for new polaris variants (e.g., RX590) - New vega pci ids - Vega20 smu fix - Ctx locking fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181212203022.3054-1-alexander.deucher@amd.com
2018-12-13Merge tag 'drm-misc-fixes-2018-12-12' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes - rockchip: Revert change causing WARN on shutdown (Brian) Cc: Brian Norris <briannorris@chromium.org> Signed-off-by: Dave Airlie <airlied@redhat.com> From: Sean Paul <sean@poorly.run> Link: https://patchwork.freedesktop.org/patch/msgid/20181212204309.GA150523@art_vandelay
2018-12-13Merge tag 'drm-intel-fixes-2018-12-12-1' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes - Two fixes to avoid GPU hangs (on Braswell and Gen3) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181212134010.GA18900@jlahtine-desk.ger.corp.intel.com
2018-12-13Merge tag 'drm-intel-fixes-2018-12-07' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes - Fix for system crash after GPU hang (Bugzilla #107945) - GVT fix for guest graphics corruption (https://github.com/intel/gvt-linux/issues/61) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181207104352.GA18214@jlahtine-desk.ger.corp.intel.com
2018-12-12drm/amd/display: Add fast path for cursor plane updatesNicholas Kazlauskas
[Why] Legacy cursor plane updates from drm helpers go through the full atomic codepath. A high volume of cursor updates through this slow code path can cause subsequent page-flips to skip vblank intervals since each individual update is slow. This problem is particularly noticeable for the compton compositor. [How] A fast path for cursor plane updates is added by using DRM asynchronous commit support provided by async_check and async_update. These don't do a full state/flip_done dependency stall and they don't block other commit work. However, DC still expects itself to be single-threaded for anything that can issue register writes. Screen corruption or hangs can occur if write sequences overlap. Every call that potentially perform register writes needs to be guarded for asynchronous updates to work. The dc_lock mutex was added for this. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106175 Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Acked-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Reviewed-by Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-12-12drm/i915: Don't forget to reset blocks when testing lower wm levelsMatt Roper
During DDB allocation, we try to distribute enough blocks for each plane to hit the highest watermark level; if that fails, we retry each lower level (which should require fewer blocks) until we find one that's possible (or until the whole commit is rejected as impossible). We need to reset our running block count when trying each lower level, otherwise all lower levels will fail as well. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: d8e8749802 ("drm/i915: Switch to level-based DDB allocation algorithm (v5)") Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181212191720.3706-1-matthew.d.roper@intel.com
2018-12-12drm/amdgpu: drop fclk/gfxclk ratio settingEvan Quan
Since this is not needed any more on the latest SMC firmware. Signed-off-by: Evan Quan <evan.quan@amd.com> Acked-by: Feifei Xu <Feifei.Xu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-12-12drm/amdgpu: Enable GPU recovery by default for CIAndrey Grodzovsky
I retested Bonaire (gfx7 dGPU) and it works fine. Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-12-12drm/rockchip: Add implicit fencing support for planesHeiko Stuebner
Render like lima will attach a fence to the framebuffer dma_buf, so the display driver should wait for it to finish before showing the framebufferto prevent tearing. Generally tested on rk3188, rk3288, rk3328 and rk3399 and together with an actual lima-based kmscube on rk3188 and rk3328. Suggested-by: Qiang Yu <yuq825@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181130102449.6430-1-heiko@sntech.de
2018-12-12drm/vmwgfx: remove redundant return ret statementColin Ian King
The return statement is redundant as there is a return statement immediately before it so we have dead code that can be removed. Also remove the unused declaration of ret. Detected by CoverityScan, CID#1473793 ("Structurally dead code") Signed-off-by: Colin Ian King <colin.king@canonical.com> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
2018-12-12drm/xen: Don't set the dpms hookDaniel Vetter
Doesn't do anything for atomic. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Cc: xen-devel@lists.xen.org Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181210100359.22507-7-daniel.vetter@ffwll.ch
2018-12-12drm/qxl: Don't set the dpms hookDaniel Vetter
Doesn't do anything with atomic. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Dave Airlie <airlied@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: virtualization@lists.linux-foundation.org Cc: spice-devel@lists.freedesktop.org Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181210100359.22507-6-daniel.vetter@ffwll.ch
2018-12-12drm/i915: Flush GPU relocs harder for gen3Chris Wilson
Adding an extra MI_STORE_DWORD_IMM to the gpu relocation path for gen3 was good, but still not good enough. To survive 24+ hours under test we needed to perform not one, not two but three extra store-dw. Doing so for each GPU relocation was a little unsightly and since we need to worry about userspace hitting the same issues, we should apply the dummy store-dw into the EMIT_FLUSH. Fixes: 7dd4f6729f92 ("drm/i915: Async GPU relocation processing") References: 7fa28e146994 ("drm/i915: Write GPU relocs harder with gen3") Testcase: igt/gem_tiled_fence_blits # blb/pnv Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181207134037.11848-1-chris@chris-wilson.co.uk (cherry picked from commit a889580c087a9cf91fddb3832ece284174214183) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2018-12-12drm/i915: Allocate a common scratch pageChris Wilson
Currently we allocate a scratch page for each engine, but since we only ever write into it for post-sync operations, it is not exposed to userspace nor do we care for coherency. As we then do not care about its contents, we can use one page for all, reducing our allocations and avoid complications by not assuming per-engine isolation. For later use, it simplifies engine initialisation (by removing the allocation that required struct_mutex!) and means that we can always rely on there being a scratch page. v2: Check that we allocated a large enough scratch for I830 w/a Fixes: 06e562e7f515 ("drm/i915/ringbuffer: Delay after EMIT_INVALIDATE for gen4/gen5") # v4.18.20 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108850 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181204141522.13640-1-chris@chris-wilson.co.uk Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: <stable@vger.kernel.org> # v4.18.20+ (cherry picked from commit 5179749925933575a67f9d8f16d0cc204f98a29f) [Joonas: Use new function in gen9_init_indirectctx_bb too] Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2018-12-12drm/i915/execlists: Apply a full mb before execution for BraswellChris Wilson
Braswell is really picky about having our writes posted to memory before we execute or else the GPU may see stale values. A wmb() is insufficient as it only ensures the writes are visible to other cores, we need a full mb() to ensure the writes are in memory and visible to the GPU. The most frequent failure in flushing before execution is that we see stale PTE values and execute the wrong pages. References: 987abd5c62f9 ("drm/i915/execlists: Force write serialisation into context image vs execution") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: stable@vger.kernel.org Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181206084431.9805-3-chris@chris-wilson.co.uk (cherry picked from commit 490b8c65b9db45896769e1095e78725775f47b3e) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2018-12-12drm/nouveau/kms: Fix memory leak in nv50_mstm_del()Lyude Paul
Noticed this while working on redoing the reference counting scheme in the DP MST helpers. Nouveau doesn't attempt to call drm_dp_mst_topology_mgr_destroy() at all, which leaves it leaking all of the resources for drm_dp_mst_topology_mgr and it's children mstbs+ports. Fixes: f479c0ba4a17 ("drm/nouveau/kms/nv50: initial support for DP 1.2 multi-stream") Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: <stable@vger.kernel.org> # v4.10+ Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-12drm/nouveau/kms/nv50-: also flush fb writes when rewinding push bufferBen Skeggs
Should hopefully fix a regression some people have been seeing since EVO push buffers were moved to VRAM by default on Pascal GPUs. Fixes: d00ddd9da ("drm/nouveau/kms/nv50-: allocate push buffers in vidmem on pascal") Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: <stable@vger.kernel.org> # 4.19+
2018-12-11drm/i915: DFSM pipe disable is valid from gen9 onwards (v2)Bob Paauwe
It's not just GEN9 platforms that allow for pipes to be disabled via the DFSM register, but all later platforms as well. v2: drop pointless parentheses (Ville) Signed-off-by: Bob Paauwe <bob.j.paauwe@intel.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181211192545.140081-1-bob.j.paauwe@intel.com
2018-12-11drm/i915: Switch to level-based DDB allocation algorithm (v5)Matt Roper
The DDB allocation algorithm currently used by the driver grants each plane a very small minimum allocation of DDB blocks and then divies up all of the remaining blocks based on the percentage of the total data rate that the plane makes up. It turns out that this proportional allocation approach is overly-generous with the larger planes and can leave very small planes wthout a big enough allocation to even hit their level 0 watermark requirements (especially on APL, which has a smaller DDB in general than other gen9 platforms). Or there can be situations where the smallest planes hit a lower watermark level than they should have been able to hit with a more equitable division of DDB blocks, thus limiting the overall system sleep state that can be achieved. The bspec now describes an alternate algorithm that can be used to overcome these types of issues. With the new algorithm, we calculate all plane watermark values for all wm levels first, then go back and partition a pipe's DDB space second. The DDB allocation will calculate what the highest watermark level that can be achieved on *all* active planes, and then grant the blocks necessary to hit that level to each plane. Any remaining blocks are then divided up proportionally according to data rate, similar to the old algorithm. There was a previous attempt to implement this algorithm a couple years ago in bb9d85f6e9d ("drm/i915/skl: New ddb allocation algorithm"), but some regressions were reported, the patch was reverted, and nobody ever got around to figuring out exactly where the bug was in that version. Our watermark code has evolved significantly in the meantime, but we're still getting bug reports caused by the unfair proportional algorithm, so let's give this another shot. v2: - Make sure cursor allocation stays constant and fixed at the end of the pipe allocation. - Fix some watermark level iterators that weren't handling the max level. v3: - Ensure we don't leave any DDB blocks unused by using DIV_ROUND_UP+min to calculate the extra blocks for each plane. (Ville) - Replace a while() loop with a for() loop to be more consistent with surrounding code. (Ville) - Clean unattainable watermark levels with memset rather than directly clearing the member fields. Also do the same for the transition watermark values if they can't be achieved. (Ville) - Drop min_disp_buf_needed calculations in skl_compute_plane_wm() since the results are no longer needed or used. (Ville) - Drop skl_latency[0] != 0 sanity check; both watermark methods already account for an invalid 0 latency by returning FP_16_16_MAX. (Ville) v4: - Break DDB allocation loop when total_data_rate=0 rather than alloc_size=0. If total_data_rate has dropped to 0, all remaining planes are disabled, which isn't true for alloc_size (we might just have not had any remaining blocks to hand out). Plus total_data_rate=0 is the case we need to avoid to a prevent a div-by-0. (Ville) - s/DIV_ROUND_UP/DIV64_U64_ROUND_UP/ to prevent 32-bit breakage (Ville) v5: - Don't forget to move 'start' pointer forward for UV surface when setting plane DDB boundaries. (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105458 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181211173107.11068-2-matthew.d.roper@intel.com
2018-12-11drm/i915: Don't use DDB allocation when choosing gen9 watermark methodMatt Roper
The bspec gives an if/else chain for choosing whether to use "method 1" or "method 2" for calculating the watermark "Selected Result Blocks" value for a plane. One of the branches of the if chain is: "Else If ('plane buffer allocation' is known and (plane buffer allocation / plane blocks per line) >=1)" Since our driver currently calculates DDB allocations first and the actual watermark values second, the plane buffer allocation is known at this point in our code and we include this test in our driver's logic. However we plan to soon move to a "watermarks first, ddb allocation second" sequence where we won't know the DDB allocation at this point. Let's drop this arm of the if/else statement (effectively considering the DDB allocation unknown) as an independent patch so that any regressions can be more accurately bisected to either the different watermark value (in this patch) or the new DDB allocation (in the next patch). Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181211173107.11068-1-matthew.d.roper@intel.com
2018-12-11drm/amd/display: Fix duplicating scaling/underscan connector stateNicholas Kazlauskas
[Why] These properties aren't being carried over when the atomic state. This tricks atomic check and commit tail into performing underscan and scaling operations when they aren't needed. With the patch that forced scaling/RMX_ASPECT on by default this results in many unnecessary surface updates and hangs under certain conditions. [How] Duplicate the properties. Fixes: 91b66c47ba34 ("drm/amd/display: Set RMX_ASPECT as default") Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-12-11drm/amd/display: Fix unintialized max_bpc state valuesNicholas Kazlauskas
[Why] If the "max bpc" isn't explicitly set in the atomic state then it have a value of 0. This has the correct behavior of limiting a panel to 8bpc in the case where the panel supports 8bpc. In the case of eDP panels this isn't a true assumption - there are panels that can only do 6bpc. Banding occurs for these displays. [How] Initialize the max_bpc when the connector resets to 8bpc. Also carry over the value when the state is duplicated. Bugzilla: https://bugs.freedesktop.org/108825 Fixes: 307638884f72 ("drm/amd/display: Support amdgpu "max bpc" connector property") Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-12-11Revert "drm/amd/display: Set RMX_ASPECT as default"Nicholas Kazlauskas
This reverts commit 91b66c47ba3468f7882ea4a84d5e0e0c186b638f. Forcing RMX_ASPECT as default uses the preferred/native mode's timings for any mode the user selects and scales the image. This provides a a consistently nicer result in the case where the selected mode's refresh rate matches the native mode's refresh but this isn't always the case. For example, if the monitor is 1080p@144Hz and the preferred mode is 60Hz then even if the user selects 1080p@144Hz as their selected mode they'll get 1080p@60Hz. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-12-11drm/amdgpu: Fix stub function nameKuehling, Felix
This function was renamed in a previous commit. Update the stub function name for builds with CONFIG_HSA_AMD disabled. Fixes: 611736d8447c ("drm/amdgpu: Add KFD VRAM limit checking") Acked-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-12-11drm/msm/dpu: Fix clock issue after bind failureJayant Shekhar
In case of msm drm bind failure, pm runtime put sync is called from dsi driver which issues an asynchronous put on mdss device. Subsequently when dpu_mdss_destroy is triggered the change will make sure to put the mdss device in suspend and clearing pending work if not scheduled. Signed-off-by: Jayant Shekhar <jshekhar@codeaurora.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2018-12-11drm/msm/dpu: Clean up dpu_media_info.h static inline functionsJordan Crouse
Do some cleanup in the static inline functions defined in dpu_media_info.h by cleaning up gotos and unneeded local variables. v3: Added spaces between operators per Seal Paul and Sam Ravnborg Reviewed-by: Sean Paul <sean@poorly.run> Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2018-12-11drm/msm/dpu: Further cleanups for static inline functionsJordan Crouse
Remove more static inline functions that are lightly used and/or very simple and easy to build into the calling functions. v3: Fix a nit from Sean Paul v2: Removed another unused function from dpu_hw_lm.c and add back dpu_crtc_get_client_type() since there was a question regarding its usefulness. Reviewed-by: Sean Paul <sean@poorly.run> Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2018-12-11drm/msm/dpu: Cleanup the debugfs functionsJordan Crouse
Do some debugfs cleanups from across the DPU driver. The DRM destroy functions will do a recursive delete on the entire debugfs node so there is no need to store dentry pointers for the debugfs files that are persistent for the life of the driver. This also means that the destroy functions can go away too. Also, use standard API functions where applicable instead of using hand written code. v3: No changes v2: Add more code; most of the dpu debugfs files should be addressed now. Reviewed-by: Sean Paul <sean@poorly.run> Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2018-12-11drm/msm/dpu: Remove dpu_irq and unused functionsJordan Crouse
dpu_irq.c does some unneeded checks and passes control to dpu_core_irq.c The simple functions can be defined in the same file where we use them and the files and their associated hangers on can be deleted. Additionally the postinstall hook isn't used even in dpu_core_irq.c so zap that entire path. v3: No changes Reviewed-by: Sean Paul <sean@poorly.run> Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2018-12-11drm/msm: Make irq_postinstall optionalJordan Crouse
Allow the KMS operation 'irq_postinstall' to be optional so that the target display drivers don't need to define a dummy function if they don't need one. v3: No changes Reviewed-by: Sean Paul <sean@poorly.run> Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
generated by cgit (git 2.34.1) at 2025-09-23 19:11:00 +0000