aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm
AgeCommit message (Collapse)AuthorFilesLines
2020-12-31drm/i915: Drop i915_request.lock requirement for intel_rps_boost()Chris Wilson5-18/+17
Since we use a flag within i915_request.flags to indicate when we have boosted the request (so that we only apply the boost) once, this can be used as the serialisation with i915_request_retire() to avoid having to explicitly take the i915_request.lock which is more heavily contended. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201231093149.19086-1-chris@chris-wilson.co.uk
2020-12-31drm/i915/gt: Pull context closure check from request submit to schedule-inChris Wilson2-4/+4
We only need to evaluate the current status of the context when it is scheduled in, we will force a reschedule when the context is closed propagating the change to inflight contexts. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201231093946.11649-1-chris@chris-wilson.co.uk
2020-12-31drm/i915/gt: Cancel submitted requests upon context resetChris Wilson2-6/+18
Since we process schedule-in of a context after submitting the request, if we decide to reset the context at that time, we also have to cancel the requets we have marked for submission. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201230220028.17089-1-chris@chris-wilson.co.uk
2020-12-30drm/i915/dp: Track pm_qos per connectorChris Wilson4-10/+9
Since multiple connectors may run intel_dp_aux_xfer conncurrently, a single global pm_qos does not suffice. (One connector may disable the dma-latency boost prematurely while the second is still depending on it.) Instead of a single global pm_qos, track the pm_qos request for each intel_dp. v2: Move the pm_qos setup/teardown to intel_dp_aux_init/fini Fixes: 9ee32fea5fe8 ("drm/i915: irq-drive the dp aux communication") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201230202309.23982-1-chris@chris-wilson.co.uk
2020-12-30drm/i915/gt: Taint the reset mutex with the shrinkerChris Wilson1-0/+11
Declare that, under extreme circumstances, the shrinker may need to wait upon a request, in which case reset must not itself deadlock in order to ensure forward progress of the driver. That is since the shrinker may depend upon a reset, any reset cannot touch the shrinker. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201229141626.4773-1-chris@chris-wilson.co.uk
2020-12-30drm/panel: s6e63m0: Support max-brightnessLinus Walleij1-4/+13
The "max-brightness" is a standard backlight property that we need to support for the Samsung GT-I8190 Golden because the display will go black if we crank up the brightness too high. As the platform needs this ability to give picture this is a regression fix along with the addition of the property to the GT-I8190 device tree. Cc: Stephan Gerhold <stephan@gerhold.net> Fixes: 9c3f0a0dd6a1 ("drm/panel: s6e63m0: Implement 28 backlight levels") Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20201214222210.238081-1-linus.walleij@linaro.org
2020-12-30drm/tve200: remove unused including <linux/version.h>Tian Tao2-2/+0
Remove including <linux/version.h> that don't need it. Signed-off-by: Tian Tao <tiantao6@hisilicon.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/1609291023-46889-1-git-send-email-tiantao6@hisilicon.com
2020-12-29drm/i915/gem: Peek at the inflight contextChris Wilson4-0/+16
If supported by the backend, we can quickly look at the context's inflight engine rather than search along the active list to confirm. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201229144114.31686-1-chris@chris-wilson.co.uk
2020-12-29drm/msm: Ensure get_pages is called when lockedIskren Chernev1-1/+4
get_pages is only called in a locked context. Add a WARN_ON to make sure it stays that way. Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com> Signed-off-by: Rob Clark <robdclark@chromium.org>
2020-12-29drm/msm: Fix null dereference in _msm_gem_newIskren Chernev1-1/+2
The crash was caused by locking an uninitialized lock during init of drm_gem_object. The lock changed in the breaking commit, but the init was not moved accordingly. 8<--- cut here --- Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = (ptrval) [00000000] *pgd=00000000 Internal error: Oops: 5 [#1] PREEMPT SMP ARM Modules linked in: msm(+) qcom_spmi_vadc qcom_vadc_common dm_mod usb_f_rndis rmi_i2c rmi_core qnoc_msm8974 icc_smd_rpm pm8941_pwrkey CPU: 2 PID: 1020 Comm: udevd Not tainted 5.10.0-postmarketos-qcom-msm8974 #8 Hardware name: Generic DT based system PC is at ww_mutex_lock+0x20/0xb0 LR is at _msm_gem_new+0x13c/0x298 [msm] pc : [<c0be31e8>] lr : [<bf0b3404>] psr: 20000013 sp : c36e7ad0 ip : c3b3d800 fp : 00000000 r10: 00000001 r9 : c3b22800 r8 : 00000000 r7 : c3b23000 r6 : c3b3d600 r5 : c3b3d600 r4 : 00000000 r3 : c34b4780 r2 : c3b3d6f4 r1 : 00000000 r0 : 00000000 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5787d Table: 03ae406a DAC: 00000051 Process udevd (pid: 1020, stack limit = 0x(ptrval)) Stack: (0xc36e7ad0 to 0xc36e8000) [...] [<c0be31e8>] (ww_mutex_lock) from [<bf0b3404>] (_msm_gem_new+0x13c/0x298 [msm]) [<bf0b3404>] (_msm_gem_new [msm]) from [<bf0b3aa8>] (_msm_gem_kernel_new+0x20/0x190 [msm]) [<bf0b3aa8>] (_msm_gem_kernel_new [msm]) from [<bf0b4a30>] (msm_gem_kernel_new+0x24/0x2c [msm]) [<bf0b4a30>] (msm_gem_kernel_new [msm]) from [<bf0b8e2c>] (msm_gpu_init+0x308/0x548 [msm]) [<bf0b8e2c>] (msm_gpu_init [msm]) from [<bf060a90>] (adreno_gpu_init+0x13c/0x240 [msm]) [<bf060a90>] (adreno_gpu_init [msm]) from [<bf062b1c>] (a3xx_gpu_init+0x78/0x1dc [msm]) [<bf062b1c>] (a3xx_gpu_init [msm]) from [<bf05f394>] (adreno_bind+0x1cc/0x274 [msm]) [<bf05f394>] (adreno_bind [msm]) from [<c087a254>] (component_bind_all+0x11c/0x278) [<c087a254>] (component_bind_all) from [<bf0b11d4>] (msm_drm_bind+0x18c/0x5b4 [msm]) [<bf0b11d4>] (msm_drm_bind [msm]) from [<c0879ea0>] (try_to_bring_up_master+0x200/0x2c8) [<c0879ea0>] (try_to_bring_up_master) from [<c087a648>] (component_master_add_with_match+0xc8/0xfc) [<c087a648>] (component_master_add_with_match) from [<bf0b0c3c>] (msm_pdev_probe+0x288/0x2c4 [msm]) [<bf0b0c3c>] (msm_pdev_probe [msm]) from [<c08844cc>] (platform_drv_probe+0x48/0x98) [<c08844cc>] (platform_drv_probe) from [<c0881cc4>] (really_probe+0x108/0x528) [<c0881cc4>] (really_probe) from [<c0882480>] (driver_probe_device+0x78/0x1d4) [<c0882480>] (driver_probe_device) from [<c08828dc>] (device_driver_attach+0xa8/0xb0) [<c08828dc>] (device_driver_attach) from [<c0882998>] (__driver_attach+0xb4/0x154) [<c0882998>] (__driver_attach) from [<c087fa1c>] (bus_for_each_dev+0x78/0xb8) [<c087fa1c>] (bus_for_each_dev) from [<c0880e98>] (bus_add_driver+0x10c/0x208) [<c0880e98>] (bus_add_driver) from [<c0883504>] (driver_register+0x88/0x118) [<c0883504>] (driver_register) from [<c0302098>] (do_one_initcall+0x50/0x2b0) [<c0302098>] (do_one_initcall) from [<c03bace4>] (do_init_module+0x60/0x288) [<c03bace4>] (do_init_module) from [<c03bdf1c>] (sys_finit_module+0xd4/0x120) [<c03bdf1c>] (sys_finit_module) from [<c0300060>] (ret_fast_syscall+0x0/0x54) Exception stack(0xc36e7fa8 to 0xc36e7ff0) 7fa0: 00020000 00000000 00000007 b6edd5b0 00000000 b6f2ff20 7fc0: 00020000 00000000 0000017b 0000017b b6eef980 bedc3a54 00473c99 00000000 7fe0: b6edd5b0 bedc3918 b6ed8a5f b6f6a8b0 Code: e3c3303f e593300c e1a04000 f590f000 (e1940f9f) ---[ end trace 277e2a3da40bbb76 ]--- Fixes: 6c0e3ea250476 ("drm/msm/gem: Switch over to obj->resv for locking") Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com> Signed-off-by: Rob Clark <robdclark@chromium.org>
2020-12-29drm/i915/gt: Define guc firmware blob for older CometlakesChris Wilson1-0/+1
When splitting the Coffeelake define to also identify Cometlakes, I missed the double fw_def for Coffeelake. That is only newer Cometlakes use the cml specific guc firmware, older Cometlakes should use kbl firmware. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2859 Fixes: 5f4ae2704d59 ("drm/i915: Identify Cometlake platform") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: <stable@vger.kernel.org> # v5.9+ Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201229120828.29931-1-chris@chris-wilson.co.uk
2020-12-29drm/mediatek: Move cmdq_reg info from struct mtk_ddp_comp to sub driver private dataCK Hu5-64/+84
Some ddp component exist in both display path and other path, so data belonged to sub driver should be moved into sub driver private data so it could be used for multiple path. cmdq_reg info is one of sub driver data, so move it. Signed-off-by: CK Hu <ck.hu@mediatek.com> Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2020-12-29drm/mediatek: Use struct cmdq_client_reg to gather cmdq variableCK Hu2-21/+9
struct cmdq_client_reg include subsys and offset, so use it to replace these two variable. Signed-off-by: CK Hu <ck.hu@mediatek.com> Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2020-12-29drm/mediatek: Remove irq in struct mtk_ddp_compCK Hu1-3/+0
irq in struct mtk_ddp_comp is useless, so remove it. Signed-off-by: CK Hu <ck.hu@mediatek.com> Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2020-12-29drm/mediatek: Move regs info from struct mtk_ddp_comp to sub driver private dataCK Hu5-93/+165
Some ddp component exist in both display path and other path, so data belonged to sub driver should be moved into sub driver private data so it could be used for multiple path. regs info is one of sub driver data, so move it. Signed-off-by: CK Hu <ck.hu@mediatek.com> Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2020-12-29drm/mediatek: Move clk info from struct mtk_ddp_comp to sub driver private dataCK Hu6-15/+141
Some ddp component exist in both display path and other path, so data belonged to sub driver should be moved into sub driver private data so it could be used for multiple path. clk info is one of sub driver data, so move it. Signed-off-by: CK Hu <ck.hu@mediatek.com> Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2020-12-29drm/mediatek: Separate getting larb device to a functionCK Hu1-25/+32
To make the code cleaner, separate getting larb device to a function. Signed-off-by: CK Hu <ck.hu@mediatek.com> Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2020-12-29drm/mediatek: Use correct device pointer to get CMDQ client registerChun-Kuang Hu8-13/+19
Some ddp component use mmsys device pointer to get CMDQ client register, this would get mmsys' CMDQ client register, so use each ddp component's device pointer to get. Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2020-12-29drm/mediatek: Get CMDQ client register for all ddp componentChun-Kuang Hu1-14/+15
Only OVL, RDMA,and WDMA get CMDQ client register information, but all ddp component should work with CMDQ, so get this information for all ddp component. Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2020-12-25drm/amd/display: avoid uninitialized variable warningLinus Torvalds1-1/+1
clang (quite rightly) complains fairly loudly about the newly added mpc1_get_mpc_out_mux() function returning an uninitialized value if the 'opp_id' checks don't pass. This may not happen in practice, but the code really shouldn't return garbage if the sanity checks don't pass. So just initialize 'val' to zero to avoid the issue. Fixes: 110b055b2827 ("drm/amd/display: add getter routine to retrieve mpcc mux") Cc: Josip Pavic <Josip.Pavic@amd.com> Cc: Bindu Ramamurthy <bindu.r@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-12-25drm/i915/gvt: unify lri cmd handler and mmio handlersYan Zhao1-75/+55
for common ctxs and commands in workload, call mmio handlers for value checking and command patching for registers with command fix write flag set. after calling mmio handlers, resotre old vreg values so as to keep vreg unchanged after command scanning. Note: for regs in below catigories, a. in ctx and save-restore list, and is inhibit ctx b. in mocs after cmd scanning, do not restore old vreg values, but update vreg as what has been implemented before this patch. Cc: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Yan Zhao <yan.y.zhao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20201223034632.17416-1-yan.y.zhao@intel.com Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2020-12-25drm/i915/gvt: update F_CMD_WRITE_PATCH flag when parsing init ctxYan Zhao1-0/+5
if a vreg has write handler, set its flag F_CMD_WRITE_PATCH on when parsing init ctx. Cc: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Yan Zhao <yan.y.zhao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20201223034623.17368-1-yan.y.zhao@intel.com Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2020-12-25drm/i915/gvt: statically set F_CMD_WRITE_PATCH flagYan Zhao1-3/+4
statically set F_CMD_WRITE_PATCH flag for RING MODE registers and force_nonpriv rgisters Cc: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Yan Zhao <yan.y.zhao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20201223034603.17320-1-yan.y.zhao@intel.com Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2020-12-25drm/i915/gvt: introduce a new flag F_CMD_WRITE_PATCHYan Zhao1-0/+31
F_CMD_WRITE_PATCH means command write to this register needs to be patched Cc: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Yan Zhao <yan.y.zhao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20201223034553.17272-1-yan.y.zhao@intel.com Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2020-12-25drm/i915/gvt: make width of mmio_attribute biggerYan Zhao2-2/+2
8 bits are all used up. extend it to 16 bits to hold more flags. Suggested-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Yan Zhao <yan.y.zhao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20201223034545.17224-1-yan.y.zhao@intel.com Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2020-12-25drm/i915/gvt: export find_mmio_infoYan Zhao2-3/+6
export find_mmio_info to be accessible by other gvt components Cc: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Yan Zhao <yan.y.zhao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20201223034536.17176-1-yan.y.zhao@intel.com Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2020-12-25drm/i915/gvt: filter cmd "pipe-ctrl" in cmd_handlerYan Zhao1-0/+5
"pipe-ctrl" is still a TODO. allow it here. Cc: Colin Xu <colin.xu@intel.com> Cc: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Yan Zhao <yan.y.zhao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20201223034526.17128-1-yan.y.zhao@intel.com Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2020-12-25drm/i915/gvt: filter cmds "lrr-src" and "lrr-dst" in cmd_handlerYan Zhao1-0/+6
do not allow "lrr-src" and "lrr-dst" Cc: Colin Xu <colin.xu@intel.com> Cc: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Yan Zhao <yan.y.zhao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20201223034517.17080-1-yan.y.zhao@intel.com Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2020-12-25drm/i915/gvt: filter cmds "srm" and "lrm" in cmd_handlerYan Zhao1-0/+11
do not allow "srm" and "lrm" except for GEN8_L3SQCREG4 and 0x21f0. Cc: Colin Xu <colin.xu@intel.com> Cc: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Yan Zhao <yan.y.zhao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20201223034508.17031-1-yan.y.zhao@intel.com Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2020-12-25drm/i915/gvt: scan VM ctx pagesYan Zhao4-4/+74
Logical Context is actually a big batch buffer consisting of multiple LRI commands + saved registers. It comprises Ring Context (the first 0x50 dwords) and Engine Context. The registers defined in Engine Context are command accessible, and safe to execute in VM Context. This patch 1. stops copy Ring Context and only copys Engine Context from VM Context 2. audits VM Engine Contexts to disallow undesired LRIs (if accessing registers out of Engine Context that hardware generates). Cc: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Wang Zhi <zhi.a.wang@intel.com> Signed-off-by: Yan Zhao <yan.y.zhao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20201223034500.16983-1-yan.y.zhao@intel.com Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2020-12-25drm/i915/gvt: parse init context to update cmd accessible reg whitelistYan Zhao4-4/+148
Logical Context is actually a big batch buffer consisting of multiple LRI commands + saved registers. It comprises Ring Context (the first 0x50 dwords) and Engine Context. The registers defined in Engine Context are command accessible, and safe to execute in VM Context. However, not all of them are currently tracked in existing register whitelist. Here we kick hardware to generate a dummy Engine Context and then scan the dummy Engine context to update whitelist dynamically. Based on updated list, later patches will audit future VM Engine Contexts to disallow undesired LRIs (if out of what hardware generates). Cc: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Wang Zhi <zhi.a.wang@intel.com> Signed-off-by: Yan Zhao <yan.y.zhao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20201223034430.16934-1-yan.y.zhao@intel.com Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2020-12-24Merge tag 'irq-core-2020-12-23' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds4-22/+43
Pull irq updates from Thomas Gleixner: "This is the second attempt after the first one failed miserably and got zapped to unblock the rest of the interrupt related patches. A treewide cleanup of interrupt descriptor (ab)use with all sorts of racy accesses, inefficient and disfunctional code. The goal is to remove the export of irq_to_desc() to prevent these things from creeping up again" * tag 'irq-core-2020-12-23' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (30 commits) genirq: Restrict export of irq_to_desc() xen/events: Implement irq distribution xen/events: Reduce irq_info:: Spurious_cnt storage size xen/events: Only force affinity mask for percpu interrupts xen/events: Use immediate affinity setting xen/events: Remove disfunct affinity spreading xen/events: Remove unused bind_evtchn_to_irq_lateeoi() net/mlx5: Use effective interrupt affinity net/mlx5: Replace irq_to_desc() abuse net/mlx4: Use effective interrupt affinity net/mlx4: Replace irq_to_desc() abuse PCI: mobiveil: Use irq_data_get_irq_chip_data() PCI: xilinx-nwl: Use irq_data_get_irq_chip_data() NTB/msi: Use irq_has_action() mfd: ab8500-debugfs: Remove the racy fiddling with irq_desc pinctrl: nomadik: Use irq_has_action() drm/i915/pmu: Replace open coded kstat_irqs() copy drm/i915/lpe_audio: Remove pointless irq_to_desc() usage s390/irq: Use irq_desc_kstat_cpu() in show_msi_interrupt() parisc/irq: Use irq_desc_kstat_cpu() in show_interrupts() ...
2020-12-24Merge tag 'drm-next-2020-12-24' of git://anongit.freedesktop.org/drm/drmLinus Torvalds37-132/+181
Pull drm fixes from Dave Airlie: "Xmas eve pull request present. Just some fixes that trickled in this past week: Mostly amdgpu fixes, with a dma-buf/mips build fix and some misc komeda fixes. dma-buf: - fix build on mips komeda: - fix commit tail operation order - NULL pointer fix - out of bounds access fix ttm: - remove an unused function amdgpu: - Vangogh SMU fixes - Arcturus gfx9 fixes - Misc display fixes - Sienna Cichlid SMU update - Fix S3 display memory leak - Fix regression caused by DP sub-connector support amdkfd: - Properly require pcie atomics for gfx10" * tag 'drm-next-2020-12-24' of git://anongit.freedesktop.org/drm/drm: (31 commits) drm/amd/display: Fix memory leaks in S3 resume drm/amdgpu: Fix a copy-pasta comment drm/amdgpu: only set DP subconnector type on DP and eDP connectors drm/amd/pm: bump Sienna Cichlid smu_driver_if version to match latest pmfw drm/amd/display: add getter routine to retrieve mpcc mux drm/amd/display: always program DPPDTO unless not safe to lower drm/amd/display: [FW Promotion] Release 0.0.47 drm/amd/display: updated wm table for Renoir drm/amd/display: Acquire DSC during split stream for ODM only if top_pipe drm/amd/display: Multi-display underflow observed drm/amd/display: Remove unnecessary NULL check drm/amd/display: Update RN/VGH active display count workaround drm/amd/display: change SMU repsonse timeout to 2s. drm/amd/display: gradually ramp ABM intensity drm/amd/display: To modify the condition in indicating branch device drm/amd/display: Modify the hdcp device count check condition drm/amd/display: Interfaces for hubp blank and soft reset drm/amd/display: handler not correctly checked at remove_irq_handler drm/amdgpu: check gfx pipe availability before toggling its interrupts drm/amdgpu: remove unnecessary asic type check ...
2020-12-24drm/i915/gt: Refactor heartbeat request construction and submissionChris Wilson1-18/+41
Pull the individual strands of creating a custom heartbeat requests into a pair of common functions. This will reduce the number of changes we will need to make in future. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201224160213.29521-1-chris@chris-wilson.co.uk
2020-12-24drm/i915: clear the gpu reloc batchMatthew Auld1-1/+3
The reloc batch is short lived but can exist in the user visible ppGTT, and since it's backed by an internal object, which lacks page clearing, we should take care to clear it upfront. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20201224151358.401345-2-matthew.auld@intel.com Cc: stable@vger.kernel.org
2020-12-24drm/i915: clear the shadow batchMatthew Auld1-18/+9
The shadow batch is an internal object, which doesn't have any page clearing, and since the batch_len can be smaller than the object, we should take care to clear it. Testcase: igt/gen9_exec_parse/shadow-peek Fixes: 4f7af1948abc ("drm/i915: Support ro ppgtt mapped cmdparser shadow buffers") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20201224151358.401345-1-matthew.auld@intel.com Cc: stable@vger.kernel.org
2020-12-24drm/i915/gt: ce->inflight updates are now serialisedChris Wilson1-27/+25
Since schedule-in and schedule-out are now both always under the tasklet bitlock, we can reduce the individual atomic operations to simple instructions and worry less. This notably eliminates the race observed with intel_context_inflight in __engine_unpark(). Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2583 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/20201224135544.1713-9-chris@chris-wilson.co.uk
2020-12-24drm/i915/gt: Simplify virtual engine handling for execlists_hold()Chris Wilson1-29/+0
Now that the tasklet completely controls scheduling of the requests, and we postpone scheduling out the old requests, we can keep a hanging virtual request bound to the engine on which it hung, and remove it from te queue. On release, it will be returned to the same engine and remain in its queue until it is scheduled; after which point it will become eligible for transfer to a sibling. Instead, we could opt to resubmit the request along the virtual engine on unhold, making it eligible for load balancing immediately -- but that seems like a pointless optimisation for a hanging context. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201224135544.1713-8-chris@chris-wilson.co.uk
2020-12-24drm/i915/gt: Resubmit the virtual engine on schedule-outChris Wilson2-49/+79
Having recognised that we do not change the sibling until we schedule out, we can then defer the decision to resubmit the virtual engine from the unwind of the active queue to scheduling out of the virtual context. This improves our resilence in virtual engine scheduling, and should eliminate the rare cases of gem_exec_balance failing. By keeping the unwind order intact on the local engine, we can preserve data dependency ordering while doing a preempt-to-busy pass until we have determined the new ELSP. This means that if we try to timeslice between a virtual engine and a data-dependent ordinary request, the pair will maintain their relative ordering and we will avoid the resubmission, cancelling the timeslicing until further change. The dilemma though is that we then may end up in a situation where the 'demotion' of the virtual request to an ordinary request in the engine queue results in filling the ELSP[] with virtual requests instead of spreading the load across the engines. To compensate for this, we mark each virtual request and refuse to resubmit a virtual request in the secondary ELSP slots, thus forcing subsequent virtual requests to be scheduled out after timeslicing. By delaying the decision until we schedule out, we will avoid unnecessary resubmission. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2079 Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2098 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201224135544.1713-7-chris@chris-wilson.co.uk
2020-12-24drm/i915/gt: Shrink the critical section for irq signalingChris Wilson3-1/+5
Let's only wait for the list iterator when decoupling the virtual breadcrumb, as the signaling of all the requests may take a long time, during which we do not want to keep the tasklet spinning. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201224135544.1713-6-chris@chris-wilson.co.uk
2020-12-24drm/i915/gt: Remove virtual breadcrumb before transferChris Wilson2-2/+18
The issue with stale virtual breadcrumbs remain. Now we have the problem that if the irq-signaler is still referencing the stale breadcrumb as we transfer it to a new sibling, the list becomes spaghetti. This is a very small window, but that doesn't stop it being hit infrequently. To prevent the lists being tangled (the iterator starting on one engine's b->signalers but walking onto another list), always decouple the virtual breadcrumb on schedule-out and make sure that the walker has stepped out of the lists. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201224135544.1713-5-chris@chris-wilson.co.uk
2020-12-24drm/i915/gt: Defer schedule_out until after the next dequeueChris Wilson2-67/+115
Inside schedule_out, we do extra work upon idling the context, such as updating the runtime, kicking off retires, kicking virtual engines. However, if we are in a series of processing single requests per contexts, we may find ourselves scheduling out the context, only to immediately schedule it back in during dequeue. This is just extra work that we can avoid if we keep the context marked as inflight across the dequeue. This becomes more significant later on for minimising virtual engine misses. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201224135544.1713-4-chris@chris-wilson.co.uk
2020-12-24drm/i915/gt: Decouple inflight virtual enginesChris Wilson1-16/+12
Once a virtual engine has been bound to a sibling, it will remain bound until we finally schedule out the last active request. We can not rebind the context to a new sibling while it is inflight as the context save will conflict, hence we wait. As we cannot then use any other sibliing while the context is inflight, only kick the bound sibling while it inflight and upon scheduling out the kick the rest (so that we can swap engines on timeslicing if the previously bound engine becomes oversubscribed). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201224135544.1713-3-chris@chris-wilson.co.uk
2020-12-24drm/i915/gt: Use virtual_engine during execlists_dequeueChris Wilson1-133/+104
Rather than going back and forth between the rb_node entry and the virtual_engine type, store the ve local and reuse it. As the container_of conversion from rb_node to virtual_engine requires a variable offset, performing that conversion just once shaves off a bit of code. v2: Keep a single virtual engine lookup, for typical use. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201224135544.1713-2-chris@chris-wilson.co.uk
2020-12-24drm/i915/gt: Replace direct submit with direct call to taskletChris Wilson16-150/+162
Rather than having special case code for opportunistically calling process_csb() and performing a direct submit while holding the engine spinlock for submitting the request, simply call the tasklet directly. This allows us to retain the direct submission path, including the CS draining to allow fast/immediate submissions, without requiring any duplicated code paths, and most importantly greatly simplifying the control flow by removing reentrancy. This will enable us to close a few races in the virtual engines in the next few patches. The trickiest part here is to ensure that paired operations (such as schedule_in/schedule_out) remain under consistent locking domains, e.g. when pulled outside of the engine->active.lock v2: Use bh kicking, see commit 3c53776e29f8 ("Mark HI and TASKLET softirq synchronous"). v3: Update engine-reset to be tasklet aware Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201224135544.1713-1-chris@chris-wilson.co.uk
2020-12-24Merge tag 'amd-drm-fixes-5.11-2020-12-23' of git://people.freedesktop.org/~agd5f/linux into drm-nextDave Airlie32-111/+161
amd-drm-fixes-5.11-2020-12-23: amdgpu: - Vangogh SMU fixes - Arcturus gfx9 fixes - Misc display fixes - Sienna Cichlid SMU update - Fix S3 display memory leak - Fix regression caused by DP sub-connector support amdkfd: - Properly require pcie atomics for gfx10 Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201223204752.4019-1-alexander.deucher@amd.com
2020-12-24Merge tag 'drm-misc-next-fixes-2020-12-22' of git://anongit.freedesktop.org/drm/drm-misc into drm-nextDave Airlie5-21/+20
Short summary of fixes pull: * dma-buf: Include <linux/vmalloc.h> for building on MIPS * komeda: Fix order of operation in commit tail; Fix NULL-pointer and out-of-bounds access; Cleanups * ttm: Fix an unused-function warning Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/X+JFYlW1SEZa6ShA@linux-uq9g
2020-12-23drm/i915/gem: Optimistically prune dma-resv from the shrinker.Chris Wilson5-5/+37
As we shrink an object, also see if we can prune the dma-resv of idle fences it is maintaining a reference to. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201223122051.4624-2-chris@chris-wilson.co.uk
2020-12-23drm/i915/gt: Prefer recycling an idle fenceChris Wilson1-2/+20
If we want to reuse a fence that is in active use by the GPU, we have to wait an uncertain amount of time, but if we reuse an inactive fence, we can change it right away. Loop through the list of available fences twice, ignoring any active fences on the first pass. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201223122051.4624-1-chris@chris-wilson.co.uk
2020-12-23drm/i915/gt: Consolidate the CS timestamp clocksChris Wilson17-254/+203
Pull the GT clock information [used to derive CS timestamps and PM interval] under the GT so that is it local to the users. In doing so, we consolidate the two references for the same information, of which the runtime-info took note of a potential clock source override and scaling factors. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201223122359.22562-2-chris@chris-wilson.co.uk