aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2019-04-18drm/tegra: gem: Fix CPU-cache maintenance for BO's allocated using get_pages()Dmitry Osipenko1-2/+2
The allocated pages need to be invalidated in CPU caches. On ARM32 the DMA_BIDIRECTIONAL flag only ensures that data is written-back to DRAM and the data stays in CPU cache lines. While the DMA_FROM_DEVICE flag ensures that the corresponding CPU cache lines are getting invalidated and nothing more, that's exactly what is needed for a newly allocated pages. This fixes randomly failing rendercheck tests on Tegra30 using the Opentegra driver for tests that use small-sized pixmaps (10x10 and less, i.e. 1-2 memory pages) because apparently CPU reads out stale data from caches and/or that data is getting evicted to DRAM at the time of HW job execution. Fixes: bd43c9f0fa1f ("drm/tegra: gem: Map pages via the DMA API") Cc: stable <[email protected]> Signed-off-by: Dmitry Osipenko <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2019-04-18drm/rockchip: shutdown drm subsystem on shutdownVicente Bergas1-0/+9
As explained by Robin Murphy: > the IOMMU shutdown disables paging, so if the VOP is still > scanning out then that will result in whatever IOVAs it was using now going > straight out onto the bus as physical addresses. We had a more radical approach before in commit 7f3ef5dedb14 ("drm/rockchip: Allow driver to be shutdown on reboot/kexec") but that resulted in new warnings and oopses on shutdown on rk3399 chromeos devices. So second try is resurrecting Vicentes shutdown change which should achieve the same result but in a less drastic way. Fixes: 63238173b2fa ("Revert "drm/rockchip: Allow driver to be shutdown on reboot/kexec"") Cc: Jeffy Chen <[email protected]> Cc: Robin Murphy <[email protected]> Cc: Marc Zyngier <[email protected]> Cc: Brian Norris <[email protected]> Cc: Doug Anderson <[email protected]> Cc: [email protected] Suggested-by: JeffyChen <[email protected]> Suggested-by: Robin Murphy <[email protected]> Signed-off-by: Vicente Bergas <[email protected]> [adapted commit message to explain the history] Signed-off-by: Heiko Stuebner <[email protected]> Tested-by: Brian Norris <[email protected]> Tested-by: Douglas Anderson <[email protected]> Acked-by: Marc Zyngier <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-04-17drm/panel: simple: add lg,acx467akm-7 panelJonathan Marek1-0/+31
Add ACX467AKM-7 4.95" 1080×1920 LCD panel that is found on the LG Nexus 5 (hammerhead) phone. Signed-off-by: Jonathan Marek <[email protected]> [[email protected]: checkpatch fixes; rename jdi,1080p-hammerhead binding to lg,acx467akm-7.] Signed-off-by: Brian Masney <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-04-18Merge branch 'drm-fixes-5.1' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie8-13/+43
into drm-fixes - GPUVM fixes for vega/RV and shadow buffers - TTM fixes for hugepages - TTM fix for refcount imbalance in error path - DC AUX fix for some active DP-DVI dongles - DC fix for multihead VT switch regression Signed-off-by: Dave Airlie <[email protected]> From: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-04-18Merge tag 'drm/tegra/for-5.1-rc6' of ↵Dave Airlie2-5/+15
git://anongit.freedesktop.org/tegra/linux into drm-fixes drm/tegra: Fixes for v5.1-rc6 This contains a follow-up fix for the stream ID programming and a fix for a regression on older Tegra devices (Tegra20 and Tegra30) that are running into a division by zero trying to enable audio over HDMI. Signed-off-by: Dave Airlie <[email protected]> From: Thierry Reding <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-04-18Revert "drm: allow render capable master with DRM_AUTH ioctls"Dave Airlie1-16/+4
This reverts commit 8059add0478e29cb641936011a8fcc9ce9fd80be. This commit while seemingly a good idea, breaks a radv check, for a node being master because something succeeds where it failed before now. Apply the Linus rule, revert early and try again, we don't break userspace. Signed-off-by: Dave Airlie <[email protected]>
2019-04-18drm/drv: Fix incorrect resolution of merge conflictJanusz Krzysztofik1-1/+0
Commit f06ddb53096b ("BackMerge v5.1-rc5 into drm-next") incorrectly resolved a merge conflict related to a patch having been merged twice: - commit 3f04e0a6cfeb ("drm: Fix drm_release() and device unplug") introduced as a standalone fix via drm-fixes branch, - commit 1ee57d4d75fb ("drm: Fix drm_release() and device unplug") applied as patch 1/2 of a series on drm-next branch. That incorrect resolution of the conflict effectively reverted a change introduced to drivers/gpu/drm/drm_drv.c by patch 2/2 of that series - commit ba3bf37e150a ("drm/drv: drm_dev_unplug(): Move out drm_dev_put() call"). Fix it. Fixes: f06ddb53096b ("BackMerge v5.1-rc5 into drm-next") Signed-off-by: Janusz Krzysztofik <[email protected]> Signed-off-by: Dave Airlie <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-04-17drm/meson: add size and alignment requirements for dumb buffersNeil Armstrong1-1/+13
The Amlogic SoCs Canvas buffers stride must be aligned on 64bytes and overall size should be aligned on PAGE width. Adds a custom dumb_create op to adds these requirements. Fixes: bbbe775ec5b5 ("drm: Add support for Amlogic Meson Graphic Controller") Suggested-by: Sky Zhou <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Reviewed-by: Sky Zhou <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-04-17drm/meson: Make some functions staticYueHaibing1-8/+8
Fix sparse warnings: drivers/gpu/drm/meson/meson_viu.c:93:6: warning: symbol 'meson_viu_set_g12a_osd1_matrix' was not declared. Should it be static? drivers/gpu/drm/meson/meson_viu.c:121:6: warning: symbol 'meson_viu_set_osd_matrix' was not declared. Should it be static? drivers/gpu/drm/meson/meson_viu.c:190:6: warning: symbol 'meson_viu_set_osd_lut' was not declared. Should it be static? Signed-off-by: YueHaibing <[email protected]> Acked-by: Neil Armstrong <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-04-17drm/sun4i: Make some symbols staticYueHaibing2-4/+4
Fix sparse warnings: drivers/gpu/drm/sun4i/sun8i_tcon_top.c:271:36: warning: symbol 'sun8i_r40_tcon_top_quirks' was not declared. Should it be static? drivers/gpu/drm/sun4i/sun8i_tcon_top.c:276:36: warning: symbol 'sun50i_h6_tcon_top_quirks' was not declared. Should it be static? drivers/gpu/drm/sun4i/sun4i_tcon.c:239:6: warning: symbol 'sun4i_tcon_set_mux' was not declared. Should it be static? Reported-by: Hulk Robot <[email protected]> Signed-off-by: YueHaibing <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-04-17drm/etnaviv: clean up etnaviv_gem_new_handleLucas Stach1-15/+9
Setting the GFP flags does not need a new code block if moved to the right location, which makes this function a bit easier to read. Signed-off-by: Lucas Stach <[email protected]> Reviewed-by: Philipp Zabel <[email protected]> Reviewed-by: Christian Gmeiner <[email protected]>
2019-04-17drm/lima: Make lima_sched_ops staticYueHaibing1-1/+1
Fix sparse warning: drivers/gpu/drm/lima/lima_sched.c:356:36: warning: symbol 'lima_sched_ops' was not declared. Should it be static? Fixes: a1d2a6339961 ("drm/lima: driver for ARM Mali4xx GPUs") Reported-by: Hulk Robot <[email protected]> Signed-off-by: YueHaibing <[email protected]> Signed-off-by: Qiang Yu <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-04-17drm: etnaviv: avoid DMA API warning when importing buffersRussell King2-0/+6
During boot, I get this kernel warning: WARNING: CPU: 0 PID: 19001 at kernel/dma/debug.c:1301 debug_dma_map_sg+0x284/0x3dc etnaviv etnaviv: DMA-API: mapping sg segment longer than device claims to support [len=3145728] [max=65536] Modules linked in: ip6t_REJECT nf_reject_ipv6 ip6t_rpfilter xt_tcpudp ipt_REJECT nf_reject_ipv4 xt_conntrack ip_set nfnetlink ebtable_broute ebtable_nat ip6table_raw ip6table_nat nf_nat_ipv6 ip6table_mangle iptable_raw iptable_nat nf_nat_ipv4 nf_nat nf_conntrack nf_defrag_ipv4 nf_defrag_ipv6 libcrc32c iptable_mangle ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter caam_jr error snd_soc_imx_spdif imx_thermal snd_soc_imx_audmux nvmem_imx_ocotp snd_soc_sgtl5000 caam imx_sdma virt_dma coda rc_cec v4l2_mem2mem snd_soc_fsl_ssi snd_soc_fsl_spdif imx_vdoa imx_pcm_dma videobuf2_dma_contig etnaviv dw_hdmi_cec gpu_sched dw_hdmi_ahb_audio imx6q_cpufreq nfsd sch_fq_codel ip_tables x_tables CPU: 0 PID: 19001 Comm: Xorg Not tainted 4.20.0+ #307 Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) [<c0019658>] (unwind_backtrace) from [<c001489c>] (show_stack+0x10/0x14) [<c001489c>] (show_stack) from [<c07fb420>] (dump_stack+0x9c/0xd4) [<c07fb420>] (dump_stack) from [<c00312dc>] (__warn+0xf8/0x124) [<c00312dc>] (__warn) from [<c00313d0>] (warn_slowpath_fmt+0x38/0x48) [<c00313d0>] (warn_slowpath_fmt) from [<c00b14e8>] (debug_dma_map_sg+0x284/0x3dc) [<c00b14e8>] (debug_dma_map_sg) from [<c046eb40>] (drm_gem_map_dma_buf+0xc4/0x13c) [<c046eb40>] (drm_gem_map_dma_buf) from [<c04c3314>] (dma_buf_map_attachment+0x38/0x5c) [<c04c3314>] (dma_buf_map_attachment) from [<c046e728>] (drm_gem_prime_import_dev+0x74/0x104) [<c046e728>] (drm_gem_prime_import_dev) from [<c046e5bc>] (drm_gem_prime_fd_to_handle+0x84/0x17c) [<c046e5bc>] (drm_gem_prime_fd_to_handle) from [<c046edd0>] (drm_prime_fd_to_handle_ioctl+0x38/0x4c) [<c046edd0>] (drm_prime_fd_to_handle_ioctl) from [<c0460efc>] (drm_ioctl_kernel+0x90/0xc8) [<c0460efc>] (drm_ioctl_kernel) from [<c0461114>] (drm_ioctl+0x1e0/0x3b0) [<c0461114>] (drm_ioctl) from [<c01cae20>] (do_vfs_ioctl+0x90/0xa48) [<c01cae20>] (do_vfs_ioctl) from [<c01cb80c>] (ksys_ioctl+0x34/0x60) [<c01cb80c>] (ksys_ioctl) from [<c0009000>] (ret_fast_syscall+0x0/0x28) Exception stack(0xd81a9fa8 to 0xd81a9ff0) 9fa0: b6c69c88 bec613f8 00000009 c00c642e bec613f8 b86c4600 9fc0: b6c69c88 bec613f8 c00c642e 00000036 012762e0 01276348 00000300 012d91f8 9fe0: b6989f18 bec613dc b697185c b667be5c irq event stamp: 47905 hardirqs last enabled at (47913): [<c0098824>] console_unlock+0x46c/0x680 hardirqs last disabled at (47922): [<c0098470>] console_unlock+0xb8/0x680 softirqs last enabled at (47754): [<c000a484>] __do_softirq+0x344/0x540 softirqs last disabled at (47701): [<c0038700>] irq_exit+0x124/0x144 ---[ end trace af477747acbcc642 ]--- The reason is the contiguous buffer exceeds the default maximum segment size of 64K as specified by dma_get_max_seg_size() in linux/dma-mapping.h. Fix this by providing our own segment size, which is set to 2GiB to cover the window found in MMUv1 GPUs. Signed-off-by: Russell King <[email protected]> Signed-off-by: Lucas Stach <[email protected]>
2019-04-17drm/i915: Update DRIVER_DATE to 20190417Joonas Lahtinen1-2/+2
Signed-off-by: Joonas Lahtinen <[email protected]>
2019-04-17drm/i915/ehl: inherit icl cdclk init/uninitJani Nikula1-2/+2
The cdclk init/uninit code was changed by commit 93a643f29bcb ("drm/i915/cdclk: have only one init/uninit function") between the versions of commit 39564ae86d51 ("drm/i915/ehl: Inherit Ice Lake conditional code"). What got merged fails to do cdclk init/uninit on ehl. Fixes: 39564ae86d51 ("drm/i915/ehl: Inherit Ice Lake conditional code") Cc: José Roberto de Souza <[email protected]> Cc: Lucas De Marchi <[email protected]> Cc: Bob Paauwe <[email protected]> Cc: Rodrigo Vivi <[email protected]> Reviewed-by: Bob Paauwe <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-04-17drm: add drm_format_helper.c to kerneldocGerd Hoffmann1-1/+0
Also drop the dstclip parameter sphinx has warned about (leftover from an earlier patch version). Signed-off-by: Gerd Hoffmann <[email protected]> Acked-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-04-17drm/tegra: hdmi: Setup audio only if configuredThierry Reding1-3/+9
The audio configuration is only valid if the HDMI codec has been properly set up. Do not attempt to set up audio before that happens because it causes a division by zero. Note that this is only problematic on Tegra20 and Tegra30. Later chips implement the division instructions which return zero when dividing by zero and don't throw an exception. Fixes: db5adf4d6dce ("drm/tegra: hdmi: Fix audio to work with any pixel clock rate") Reported-by: Marcel Ziswiler <[email protected]> Tested-by: Dmitry Osipenko <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2019-04-17drm/i915: Introduce struct class_instance for engines across the uAPIChris Wilson1-4/+4
SSEU reprogramming of the context introduced the notion of engine class and instance for a forwards compatible method of describing any engine beyond the old execbuf interface. We wish to adopt this class:instance description for more interfaces, so pull it out into a separate type for userspace convenience. Fixes: e46c2e99f600 ("drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only)") Signed-off-by: Chris Wilson <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Lionel Landwerlin <[email protected]> Cc: Dmitry Rogozhkin <[email protected]> Cc: Tony Ye <[email protected]> Cc: Andi Shyti <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Acked-by: Tony Ye <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-04-16drm/lima: Use the drm_gem_fence_array_add helpers for our deps.Eric Anholt3-93/+16
It's a pretty direct port of what I did for v3d. Signed-off-by: Eric Anholt <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-and-tested-by: Qiang Yu <[email protected]>
2019-04-16drm: Add helpers for setting up an array of dma_fence dependencies.Eric Anholt1-0/+93
I needed to add implicit dependency support for v3d, and Rob Herring has been working on it for panfrost, and I had recently looked at the lima implementation so I think this will be a good intersection of what we all want and simplify our scheduler implementations. v2: Rebase on xa_limit_32b API change, and tiny checkpatch cleanups on the way in (unsigned int vs unsigned, extra return before EXPORT_SYMBOL_GPL) Signed-off-by: Eric Anholt <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-and-tested-by: Qiang Yu <[email protected]> (v1)
2019-04-16drm: Expose "FB_DAMAGE_CLIPS" property to atomic aware user-space onlyDeepak Rawat1-2/+3
Plane property "FB_DAMAGE_CLIPS" can only be used by atomic aware user-space, so no point exposing it otherwise. Cc: <[email protected]> Signed-off-by: Deepak Rawat <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Fixes: d3b21767821e ("drm: Add a new plane property to send damage during plane update") Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-04-16drm/i915: fully convert the IRQ initialization macros to intel_uncorePaulo Zanoni1-56/+88
Make them take the uncore argument from the caller instead of passing the implicit &dev_priv->uncore directly. This will allow us to finally pass something that's not dev_priv->uncore in the future, and gets rid of the implicit variables in register macros. v2: Rebase on top of the newer patches. Reviewed-by: Ville Syrjälä <[email protected]> (v1) Signed-off-by: Paulo Zanoni <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-04-16drm/i915: convert the IRQ initialization functions to intel_uncorePaulo Zanoni1-49/+48
The IRQ initialization helpers are simple and self-contained. Continue the transition started in the recent uncore rework to get us rid of I915_READ/WRITE and the implicit dev_priv variables. While the implicit dev_priv is removed from the IRQ initialization helpers, we didn't get rid of them in the macro callers. Doing that should be very simple now. v2: Rebase on top of the new patches. Reviewed-by: Ville Syrjälä <[email protected]> (v1) Signed-off-by: Paulo Zanoni <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-04-16drm/i915: add GEN2_ prefix to the I{E, I, M, S}R registersPaulo Zanoni7-43/+44
This discussion started because we use token pasting in the GEN{2,3}_IRQ_INIT and GEN{2,3}_IRQ_RESET macros, so gen2-4 passes an empty argument to those macros, making the code a little weird. The original proposal was to just add a comment as the empty argument, but Ville suggested we just add a prefix to the registers, and that indeed sounds like a more elegant solution. Now doing this is kinda against our rules for register naming since we only add gens or platform names as register prefixes when the given gen/platform changes a register that already existed before. On the other hand, we have so many instances of IIR/IMR in comments that adding a prefix would make the users of these register more easily findable, in addition to make our token pasting macros actually readable. So IMHO opening an exception here is worth it. Cc: Ville Syrjälä <[email protected]> Signed-off-by: Paulo Zanoni <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-04-16drm/i915: don't specify the IRQ register in the gen2 macrosPaulo Zanoni1-32/+25
Like the gen3+ macros, the gen2 versions of the IRQ initialization macros take the register name in the 'type' argument. But gen2 only has one set of registers, so there's really no need to specify the type. This commit removes the type argument and uses the registers directly instead of passing them through variables. Signed-off-by: Paulo Zanoni <[email protected]> Reviewed-by: Daniele Ceraolo Spurio <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-04-16drm/i915: refactor the IRQ init/reset macrosPaulo Zanoni1-50/+86
The whole point of having macros here is for the token pasting necessary to automatically have IMR, IIR and IER selected. We don't really need or want all the inlining that happens as a consequence. The good thing about the current code is that it works regardless of the relative offsets between these registers (they change after gen4, with the usual VLV/CHV exceptions). One thing which we can do is to split the logic of what we do with imr/ier/iir to functions separate from the macros that pick them. That's what we do in this commit. This allows us to get rid of the gen8 duplicates and also all the inlining: add/remove: 2/0 grow/shrink: 0/21 up/down: 384/-5949 (-5565) Function old new delta gen3_irq_reset - 233 +233 gen3_irq_init - 151 +151 i8xx_irq_postinstall 459 442 -17 gen11_irq_postinstall 804 744 -60 ironlake_irq_postinstall 450 353 -97 vlv_display_irq_postinstall 348 245 -103 i965_irq_postinstall 378 272 -106 i915_irq_postinstall 333 227 -106 gen8_irq_power_well_post_enable 374 240 -134 ironlake_irq_reset 397 218 -179 vlv_display_irq_reset 616 433 -183 i965_irq_reset 374 180 -194 cherryview_irq_reset 379 185 -194 i915_irq_reset 407 209 -198 ibx_irq_reset 332 133 -199 gen5_gt_irq_postinstall 533 332 -201 gen8_irq_power_well_pre_disable 434 204 -230 gen8_gt_irq_postinstall 469 196 -273 gen8_de_irq_postinstall 1200 836 -364 gen5_gt_irq_reset 471 76 -395 gen8_gt_irq_reset 775 99 -676 gen8_irq_reset 1100 333 -767 gen11_irq_reset 1959 686 -1273 Total: Before=2259222, After=2253657, chg -0.25% v2: - Make checkpatch happy with a temporary which_ (Checkpatch). - Reorder the arguments for the INIT macros (Ville). - Correctly explain when the register offsets change in the commit message (Ville). - Use more line breaks in the macro calls to make the arguments look a little more organized/readable. - Update the bloat-o-meter output (minor change only). Reviewed-by: Ville Syrjälä <[email protected]> (v1) Signed-off-by: Paulo Zanoni <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-04-16drm: aspeed: Clean up Kconfig optionsJoel Stanley1-3/+3
The GFX IP is inside of the ASPEED BMC SoC so there is little use enabling it on a kernel that does not support ASPEED. When building with COMPILE_TEST the architecture many not have CMA support, so to avoid breaking the build we only select these options if the architecture supports the contiguous allocator. I suspect the DRM_PANEL came from a cut/paste error. Fixes: 4f2a8f5898ec ("drm: Add ASPEED GFX driver") Reported-by: Stephen Rothwell <[email protected]> Reported-by: kernel test robot <[email protected]> Signed-off-by: Joel Stanley <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-04-16Merge tag 'gvt-next-2019-04-16' of https://github.com/intel/gvt-linux into ↵Joonas Lahtinen9-82/+172
drm-intel-next-queued gvt-next-2019-04-16 - Refine range of MCHBAR snapshot (Yakui) - Refine out-of-sync page struct (Yakui) - Remove unused vGPU sreg (Yan) - Refind MMIO reg names (Xiaolin) - Proper handling of sync/async flip (Colin) - Proper handling of PIPE_CONTROL/MI_FLUSH_DW index mode (Xiaolin) - EXCC reg mask fix (Colin) Signed-off-by: Joonas Lahtinen <[email protected]> From: Zhenyu Wang <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-04-16drm/i915: Mark up ips for RCU protectionChris Wilson1-2/+2
drivers/gpu/drm/i915/intel_pm.c:8352:9: error: incompatible types in comparison expression (different address spaces) drivers/gpu/drm/i915/intel_pm.c:8359:9: error: incompatible types in comparison expression (different address spaces) Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-04-16drm/i915: Drop bool return from breadcrumbs signalerChris Wilson2-13/+5
Since removal of the "missed interrupt detection" nobody used the result of whether or not we signaled anybody during that invocation, so now remove the return value. References: 789659f4307a ("drm/i915: Drop fake breadcrumb irq") Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-04-16drm/i915/gvt: Fix incorrect mask of mmio 0x22028 in gen8/9 mmio listColin Xu1-2/+2
According to GFX PRM on 01.org, bit 31:16 of mmio 0x22028 should be masks. Fixes: 178657139307 ("drm/i915/gvt: vGPU context switch") Reviewed-by: Zhenyu Wang <[email protected]> Signed-off-by: Colin Xu <[email protected]> Signed-off-by: Zhenyu Wang <[email protected]>
2019-04-16drm/i915/gvt: addressed guest GPU hang with HWS index modeXiaolin Zhang1-0/+20
with the introduce of "switch to use HWS indices rather than address", guest GPU hang observed when running workloads which will update the seqno to the real HW HWSP, not vitural GPU HWSP and then cause GPU hang. this patch is to revoke index mode in PIPE_CTRL and MI_FLUSH_DW and patch guest GPU HWSP address value to these commands. Fixes: 54939ea0bd85 ("drm/i915: Switch to use HWS indices rather than addresses") Reviewed-by: Zhenyu Wang <[email protected]> Signed-off-by: Xiaolin Zhang <[email protected]> Signed-off-by: Zhenyu Wang <[email protected]>
2019-04-16Merge tag 'drm-intel-next-2019-04-04' into gvt-nextZhenyu Wang1514-59817/+81998
Merge back drm-intel-next for engine name definition refinement and 54939ea0bd85 ("drm/i915: Switch to use HWS indices rather than addresses") that would need gvt fixes to depend on. Signed-off-by: Zhenyu Wang <[email protected]>
2019-04-15drm/i915: Nuke drm_crtc_state and use intel_atomic_state insteadManasi Navare1-33/+28
This is one of the patches to start replacing drm pointers and use the intel_atomic_state and intel_crtc to derive the necessary intel state variables required for the intel modeset functions. v3: * Remove the unwanted newline (Ville) v2: * Flip the function arguments (Ville) * Remove some remaining instances of drm pointers (Ville) * Use old_crtc_state and new_crtc_state (Ville) Suggested-by: Ville Syrjala <[email protected]> Cc: Ville Syrjala <[email protected]> Signed-off-by: Manasi Navare <[email protected]> Reviewed-by: Ville Syrjala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-04-15drm/i915: Restore correct bxt_ddi_phy_calc_lane_lat_optim_mask() calculationVille Syrjälä1-2/+4
We are no longer calling bxt_ddi_phy_calc_lane_lat_optim_mask() when intel{hdmi,dp}_compute_config() succeeds, and instead only call it when those fail. This is fallout from the bool->int .compute_config() conversion which failed to invert the return value check before calling bxt_ddi_phy_calc_lane_lat_optim_mask(). Let's just replace it with an early bailout so that it's harder to miss. This restores the correct latency optim setting calculation (which could fix some real failures), and avoids the MISSING_CASE() from bxt_ddi_phy_calc_lane_lat_optim_mask() after intel{hdmi,dp}_compute_config() has failed. Cc: Lyude Paul <[email protected]> Fixes: 204474a6b859 ("drm/i915: Pass down rc in intel_encoder->compute_config()") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109373 Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Lyude Paul <[email protected]> (cherry picked from commit 7a412b8f60cd57ab7dcb72ab701fde2bf81752eb) Signed-off-by: Rodrigo Vivi <[email protected]>
2019-04-15drm/i915: Do not enable FEC without DSCVille Syrjälä1-3/+3
Currently we enable FEC even when DSC is no used. While that is theoretically valid supposedly there isn't much of a benefit from this. But more importantly we do not account for the FEC link bandwidth overhead (2.4%) in the non-DSC link bandwidth computations. So the code may think we have enough bandwidth when we in fact do not. Cc: [email protected] Cc: Anusha Srivatsa <[email protected]> Cc: Manasi Navare <[email protected]> Fixes: 240999cf339f ("i915/dp/fec: Add fec_enable to the crtc state.") Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Manasi Navare <[email protected]> (cherry picked from commit 6fd3134ae3551d4802a04669c0f39f2f5c56f77d) Signed-off-by: Rodrigo Vivi <[email protected]>
2019-04-15drm/i915/selftests: Skip live timeline/suspend tests if wedgedChris Wilson2-0/+6
If the driver is wedged, we can not issue the requests to exercise the timelines or the system across suspend, so skip the tests. live_hangcheck is there to fail if we cannot recover. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-04-15BackMerge v5.1-rc5 into drm-nextDave Airlie53-307/+440
Need rc5 for udl fix to add udl cleanups on top. Signed-off-by: Dave Airlie <[email protected]>
2019-04-15drm/amd/display: Add profiling tools for bandwidth validationJoshua Aberback2-0/+70
[Why] We used this change to investigate the performance of bandwidth validation, it will be useful to have if we need to investigate further. [How] We use performance counter tick numbers to profile performance, they live at dc->debug.bw_val_profile (set .enable in debugger to turn on measuring). Signed-off-by: Joshua Aberback <[email protected]> Reviewed-by: Tony Cheng <[email protected]> Acked-by: Bhawanpreet Lakha <Bhawanpreet [email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-04-15drm/amd/display: Add fast_validate parameterJoshua Aberback11-13/+29
Add a fast_validate parameter in dc_validate_global_state for future use Signed-off-by: Joshua Aberback <[email protected]> Reviewed-by: Tony Cheng <[email protected]> Acked-by: Bhawanpreet Lakha <Bhawanpreet [email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-04-15drm/amd/display: Relax requirements for CRTCs to be enabledNicholas Kazlauskas1-12/+44
[Why] As long as we have at least one non-cursor plane enabled on a CRTC then the CRTC itself can remain enabled. This will allow for commits where there's an overlay plane enabled but no primary plane enabled. [How] Remove existing primary plane fb != NULL checks and replace them with the new does_crtc_have_active_plane helper. This will be called from atomic check when validating the CRTC. Since the primary plane state can now potentially be NULL we'll need to guard for that when accessing it in some of the cursor logic. Signed-off-by: Nicholas Kazlauskas <[email protected]> Reviewed-by: David Francis <[email protected]> Acked-by: Bhawanpreet Lakha <Bhawanpreet [email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-04-15drm/amd/display: Check scaling info when determing update typeNicholas Kazlauskas1-3/+8
[Why] Surface scaling info updates can affect bandwidth and blocks. We need to be checking these with global validation to avoid underflow or corruption. [How] Drop the state->allow_modeset early exit in dm_determine_update_type_for_commit. Most of those should be considered fast now anyway. Fill in scaling info and it to the surface update in atomic check. Signed-off-by: Nicholas Kazlauskas <[email protected]> Reviewed-by: David Francis <[email protected]> Acked-by: Bhawanpreet Lakha <Bhawanpreet [email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-04-15drm/amd/display: Don't warn when DC update type > DM guessNicholas Kazlauskas1-3/+0
[Why] DM thinks that the update type should be full whenever a stream or plane is added or removed (including recreations). This won't match in the case where DC thinks what looks like a fast update to DM is actually a medium or full - like scaling changes that affect bandwidth and clocks. [How] Drop this warning. DC knows better than the DM does for determining cases like this. The other warning can be kept for now since it would warn on a pretty serious DC or DM bug. Signed-off-by: Nicholas Kazlauskas <[email protected]> Reviewed-by: David Francis <[email protected]> Acked-by: Bhawanpreet Lakha <Bhawanpreet [email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-04-15drm/amd/display: Use surface directly when checking update typeNicholas Kazlauskas1-16/+12
[Why] DC expects the surface memory address to identify the surface. This doesn't work with what we're doing with the temporary surfaces, it will always assume this is a full update because the surface isn't in the current context. [How] Use the surface directly. This doesn't give us much improvement yet, since we always create a new dc_plane_state when state->allow_modeset is true. The call into dc_check_update_surfaces_for_stream also needs to be locked, for two reasons: 1. It checks the current DC state 2. It modifies the surface update flags Both of which could be currently in the middle of commit work from commit tail. A TODO here is to pass the context explicitly into this function and find a way to get the surface update flags out of it without modifying the surface in place. Signed-off-by: Nicholas Kazlauskas <[email protected]> Reviewed-by: David Francis <[email protected]> Acked-by: Bhawanpreet Lakha <Bhawanpreet [email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-04-15drm/amd/display: Add basic downscale and upscale valdiationNicholas Kazlauskas1-0/+15
[Why] Planes have downscaling limits and upscaling limits per format and DM is expected to validate these using DC caps. We should fail atomic check validation if we aren't capable of doing the scaling. [How] We don't currently create store which DC plane maps to which DRM plane so we can't easily check the caps directly. For now add basic constraints that cover the absolute min and max downscale / upscale limits for most RGB and YUV formats across ASICs. Leave a TODO indicating that these should really be done with DC caps. We'll probably need to subclass DRM planes again in order to correctly identify which DC plane maps to it. Signed-off-by: Nicholas Kazlauskas <[email protected]> Reviewed-by: Harry Wentland <[email protected]> Reviewed-by: Tony Cheng <[email protected]> Acked-by: Bhawanpreet Lakha <Bhawanpreet [email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-04-15drm/amd/display: change name from dc_link_get_verified_link_cap to ↵Samson Tam3-4/+3
dc_link_get_link_cap [Why] DM doesn't need to know which link cap is being retrieved ( verified or preferred ). Let DC figure it out. [How] Change name. Signed-off-by: Samson Tam <[email protected]> Reviewed-by: Tony Cheng <[email protected]> Acked-by: Bhawanpreet Lakha <Bhawanpreet [email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-04-15drm/amd/display: Rework DC plane filling and surface updatesNicholas Kazlauskas1-202/+204
[Why] We currently don't do DC validation for medium or full updates where the plane state isn't created. There are some medium and full updates that can cause bandwidth or clock changes to occur resulting in underflow or corruption. We need to be able to fill surface and plane info updates during atomic commit for dm_determine_update_type for commit. Since we already do this during atomic commit tail it would be good if we had the same logic in both places for creating these structures. [How] Introduce fill_dc_scaling_info and fill_dc_plane_info_and_addr. These two functions cover the following three update structures: - struct dc_scaling_info - struct dc_plane_info - struct dc_plane_address Cleanup and adapter the existing fill_plane_* helpers to work with these functions. Update call sites that used most of these sub helpers directly to work with the new functions. The exception being prepare_fb - we just want the new buffer attributes specifically in the case where we're creating the plane. This is needed for dc_commit_state in the case where the FB hasn't been previously been used. This isn't quite a refactor, but functionally driver behavior should be mostly the smae as before. The one exception is that we now check the return code for fill_plane_buffer_attributes which means that commits will be rejected that try to enable DCC with erroneous parameters. Signed-off-by: Nicholas Kazlauskas <[email protected]> Reviewed-by: David Francis <[email protected]> Acked-by: Bhawanpreet Lakha <Bhawanpreet [email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-04-15drm/amd/display: Recalculate pitch when buffers changeNicholas Kazlauskas1-39/+34
[Why] Pitch was only calculated based on format whenever the plane state was recreated. This could result in surface corruption due to the incorrect pitch being programmed when the surface pitch changed during commits where state->allow_modeset = false. [How] Recalculate pitch at the same time we update the buffer address and other buffer attributes. This function was previously called fill_plane_tiling_attributes but I've also renamed it to fill_plane_buffer_attributes to clarify the actual intent of the function now that it's handling most buffer related attributes. Signed-off-by: Nicholas Kazlauskas <[email protected]> Reviewed-by: David Francis <[email protected]> Acked-by: Bhawanpreet Lakha <Bhawanpreet [email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-04-15drm/amd/display: Maintain z-ordering when creating planesNicholas Kazlauskas1-5/+69
[Why] The overlay will be incorrectly placed *below* the primary plane for commits with state->allow_modeset = true because the primary plane won't be removed and recreated in the same commit. [How] Add the should_reset_plane helper to determine if the plane should be reset or not. If we need to add or force reset any plane in the context then we'll need to do the same for every plane on the stream. Unfortunately we need to do the remove / recreate routine for removing planes as well since DC currently isn't well equipped to handle the plane with the top pipe being removed with other planes still active. Signed-off-by: Nicholas Kazlauskas <[email protected]> Reviewed-by: Sun peng Li <[email protected]> Acked-by: Bhawanpreet Lakha <Bhawanpreet [email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-04-15drm/amd/display: Update plane scaling parameters for fast updatesNicholas Kazlauskas1-24/+39
[Why] Plane scaling parameters are not correctly filled or updated when performing fast updates. They're filled when creating the dc plane state and during atomic check. While the atomic check code path happens for the plane even during fast updates, the issue is that they're done in place on the dc_plane_state directly. This dc_plane_state may be the current state plane state being used by the hardware, so these parameters won't be correctly programmed. The new scaling parameters should instead be passed as an update to the plane. [How] Update fill_rects_from_plane_state to not modify dc_plane_state directly. Update the call sites that use this to fill in the appropriate values. Signed-off-by: Nicholas Kazlauskas <[email protected]> Reviewed-by: Sun peng Li <[email protected]> Acked-by: Bhawanpreet Lakha <Bhawanpreet [email protected]> Signed-off-by: Alex Deucher <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.