summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2019-04-18drm/msm: dpu: Untangle frame_done timeout unitsSean Paul
There exists a bunch of confusion as to what the actual units of frame_done is: - The definition states it's in # of frames - CRTC treats it like it's ms - frame_done_timeout comment thinks it's Hz, but it stores ms - frame_done timer is setup such that it _should_ be in frames, but the timeout is super long So this patch tries to interpret what the driver really wants. I've de-centralized the #define since the consumers are expecting different units. For crtc, we just use 60ms since that's what it was doing before. Perhaps we could get fancy and scale with vrefresh, but that's for another time. For encoder, fix the comments and rename frame_done_timeout so it's obvious what the units are. In practice, frame_done_timeout is really just checked against 0 || !0, which I guess is why the units being wrong didn't matter. I've also dropped the timeout from the previous 60 frames to 5. That seems like more than enough time to give up on a frame, and my guess is that no one intended for the timeout to _actually_ be 60 frames. Reviewed-by: Fritz Koenig <frkoenig@google.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190128204306.95076-3-sean@poorly.run Signed-off-by: Rob Clark <robdclark@chromium.org>
2019-04-18drm/msm: dpu: Simplify frame_done watchdog timeout calculationSean Paul
Instead of setting the timeout and then immediately reading it back (along with the hand-rolled msecs_to_jiffies calculation), just calculate it once and set it in both places at the same time. Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190128204306.95076-2-sean@poorly.run Signed-off-by: Rob Clark <robdclark@chromium.org>
2019-04-18drm/msm: Use drm_mode_vrefresh instead of mode->vrefreshSean Paul
Use the drm_mode_vrefresh helper where we need refresh rate in case vrefresh is empty. Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190128204306.95076-1-sean@poorly.run Signed-off-by: Rob Clark <robdclark@chromium.org>
2019-04-18drm/msm: Fix NULL pointer dereferenceLuca Weiss
[ 3.707412] Unable to handle kernel NULL pointer dereference at virtual address 0000009c [ 3.714511] pgd = (ptrval) [ 3.722742] [0000009c] *pgd=00000000 [ 3.725238] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [ 3.728968] Modules linked in: [ 3.734265] CPU: 3 PID: 112 Comm: kworker/3:2 Tainted: G W 5.0.0-rc7-00183-g06a1c31df9eb #4 [ 3.737142] Hardware name: Generic DT based system [ 3.746778] Workqueue: events deferred_probe_work_func [ 3.751542] PC is at msm_gem_map_vma+0x3c/0xac [ 3.756669] LR is at msm_gem_get_and_pin_iova+0xd8/0x134 [ 3.761086] pc : [<c07d3b7c>] lr : [<c07d14f8>] psr: 60000013 [ 3.766560] sp : ee297be8 ip : ed9ab1c0 fp : ed93b800 [ 3.772546] r10: ee35e180 r9 : 00000000 r8 : ee297c80 [ 3.777752] r7 : 00000000 r6 : 7c100000 r5 : 00000000 r4 : ee35e180 [ 3.782968] r3 : 00000001 r2 : 00000003 r1 : ee35e180 r0 : 00000000 [ 3.789562] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [ 3.796079] Control: 10c5787d Table: 2e3a806a DAC: 00000051 [ 3.803282] Process kworker/3:2 (pid: 112, stack limit = 0x(ptrval)) [ 3.809006] Stack: (0xee297be8 to 0xee298000) [ 3.815445] 7be0: 00000000 c1108c48 eda8c000 00000003 eda8c0fc c1108c48 [ 3.819715] 7c00: eda8c000 00000003 eda8c0fc c07d14f8 00000001 c07d1100 7c100000 00000000 [ 3.827873] 7c20: eda8c000 bb7ffb78 00000000 eda8c000 00000000 00000000 c0c8b1d4 ee3bfa00 [ 3.836037] 7c40: ee3b9800 c07d1684 00000000 c1108c48 ee0d7810 ee3b9800 c0c8b1d4 c07d222c [ 3.844193] 7c60: ee3bfd84 ee297c80 00000000 c0b1d5b0 ee3bfc40 c07dcfd8 ee3bfd84 ee297c80 [ 3.852357] 7c80: 0000006d ee3bfc40 ee0d7810 bb7ffb78 c0c8b1d4 00000000 ee3bfc40 c07ddb48 [ 3.860516] 7ca0: 00002004 c0eba384 ee3bfc40 c079eba0 ee3bd040 ee3b9800 00000001 ed93b800 [ 3.868673] 7cc0: ed9aa100 c07db7e8 ee3bf240 ed9a6500 00000001 ee3b9800 ee3bf2d4 c07a0a30 [ 3.876834] 7ce0: ed93b800 7d100000 c1108c48 ee0d7610 ee3b9800 ed93b800 c1108c48 00000000 [ 3.884991] 7d00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 3.893151] 7d20: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 bb7ffb78 [ 3.901310] 7d40: c12113c4 ed93b800 ee3b9800 c1108c48 ee9eec10 00000000 ed93b800 7d100000 [ 3.909472] 7d60: eff7b000 c07cf748 7d100000 00000000 c0e9a350 c0b1d5b0 c12113c4 c0961e40 [ 3.917633] 7d80: c12113c4 40000113 eeff4bec c0ebe004 00000019 c0b1d230 ee9eeda8 60000113 [ 3.925791] 7da0: ee35d300 ee9eeda8 c07ce260 bb7ffb78 c07ce260 ee35d2c0 00000028 00000002 [ 3.933950] 7dc0: eeb76280 c118f884 ee0be640 c11c6128 c07ce260 c07ea4ac 00000000 c0962b48 [ 3.942108] 7de0: c118f868 00000001 c0ebbc98 ee35d2c0 00000000 eeb76280 00000000 c118f87c [ 3.950270] 7e00: ee35d2c0 00000000 c11c63e0 c118f694 00000019 c07ea5d0 ee0d7810 00000000 [ 3.958430] 7e20: c118f694 00000000 00000000 c07f2b0c c120f55c ee0d7810 c120f560 00000000 [ 3.966590] 7e40: 00000000 c07f08c4 c07f0e8c ee0d7810 c11ba3d0 ee0d7810 c118f694 c07f0e8c [ 3.974748] 7e60: c1108c48 00000001 c0ebc3cc c11c63f8 c11ba3d0 c07f0c08 00000001 c07f2f8c [ 3.982908] 7e80: c118f694 00000000 ee297ed4 c07f0e8c c1108c48 00000001 c0ebc3cc c11c63f8 [ 3.991068] 7ea0: c11ba3d0 c07ee8a0 c11ba3d0 ee82686c ee0baf38 bb7ffb78 ee0d7810 ee0d7810 [ 3.999227] 7ec0: c1108c48 ee0d7844 c118faac c07f05b0 ee0d7810 ee0d7810 00000001 bb7ffb78 [ 4.007389] 7ee0: ee0d7810 ee0d7810 c118fd18 c118faac c11c63e0 c07ef7d0 ee0d7810 c118fa90 [ 4.015548] 7f00: c118fa90 c07efd68 c118fac8 ee27fe00 eefd9c80 eefdcd00 00000000 c118facc [ 4.023708] 7f20: 00000000 c033c038 eefd9c80 eefd9c80 00000008 ee27fe00 ee27fe14 eefd9c80 [ 4.031866] 7f40: 00000008 c1103d00 eefd9c98 ee296000 eefd9c80 c033ce54 ee907eac c0b1d230 [ 4.040026] 7f60: ee907eac eea24440 ee285000 00000000 ee296000 ee27fe00 c033ce24 eea2445c [ 4.048188] 7f80: ee907eac c0341db0 00000000 ee285000 c0341c8c 00000000 00000000 00000000 [ 4.056346] 7fa0: 00000000 00000000 00000000 c03010e8 00000000 00000000 00000000 00000000 [ 4.064505] 7fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 4.072665] 7fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 [ 4.080828] [<c07d3b7c>] (msm_gem_map_vma) from [<c07d14f8>] (msm_gem_get_and_pin_iova+0xd8/0x134) [ 4.088983] [<c07d14f8>] (msm_gem_get_and_pin_iova) from [<c07d1684>] (_msm_gem_kernel_new+0x38/0xac) [ 4.097839] [<c07d1684>] (_msm_gem_kernel_new) from [<c07d222c>] (msm_gem_kernel_new+0x24/0x2c) [ 4.107130] [<c07d222c>] (msm_gem_kernel_new) from [<c07dcfd8>] (dsi_tx_buf_alloc_6g+0x44/0x90) [ 4.115631] [<c07dcfd8>] (dsi_tx_buf_alloc_6g) from [<c07ddb48>] (msm_dsi_host_modeset_init+0x80/0x104) [ 4.124313] [<c07ddb48>] (msm_dsi_host_modeset_init) from [<c07db7e8>] (msm_dsi_modeset_init+0x34/0x1c0) [ 4.133691] [<c07db7e8>] (msm_dsi_modeset_init) from [<c07a0a30>] (mdp5_kms_init+0x764/0x7e0) [ 4.143409] [<c07a0a30>] (mdp5_kms_init) from [<c07cf748>] (msm_drm_bind+0x56c/0x740) [ 4.151824] [<c07cf748>] (msm_drm_bind) from [<c07ea4ac>] (try_to_bring_up_master+0x238/0x2b4) [ 4.159636] [<c07ea4ac>] (try_to_bring_up_master) from [<c07ea5d0>] (component_add+0xa8/0x170) [ 4.168146] [<c07ea5d0>] (component_add) from [<c07f2b0c>] (platform_drv_probe+0x48/0x9c) [ 4.176737] [<c07f2b0c>] (platform_drv_probe) from [<c07f08c4>] (really_probe+0x278/0x404) [ 4.184981] [<c07f08c4>] (really_probe) from [<c07f0c08>] (driver_probe_device+0x78/0x1c0) [ 4.193147] [<c07f0c08>] (driver_probe_device) from [<c07ee8a0>] (bus_for_each_drv+0x74/0xb8) [ 4.201389] [<c07ee8a0>] (bus_for_each_drv) from [<c07f05b0>] (__device_attach+0xd0/0x164) [ 4.209984] [<c07f05b0>] (__device_attach) from [<c07ef7d0>] (bus_probe_device+0x84/0x8c) [ 4.218143] [<c07ef7d0>] (bus_probe_device) from [<c07efd68>] (deferred_probe_work_func+0x48/0xc4) [ 4.226398] [<c07efd68>] (deferred_probe_work_func) from [<c033c038>] (process_one_work+0x204/0x574) [ 4.235254] [<c033c038>] (process_one_work) from [<c033ce54>] (worker_thread+0x30/0x560) [ 4.244534] [<c033ce54>] (worker_thread) from [<c0341db0>] (kthread+0x124/0x154) [ 4.252606] [<c0341db0>] (kthread) from [<c03010e8>] (ret_from_fork+0x14/0x2c) [ 4.259966] Exception stack(0xee297fb0 to 0xee297ff8) [ 4.266998] 7fa0: 00000000 00000000 00000000 00000000 [ 4.272143] 7fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 4.280297] 7fe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 4.288451] Code: e5813080 1a000013 e3a03001 e5c4307c (e590009c) [ 4.294933] ---[ end trace 18729cc2bca2b4b3 ]--- Signed-off-by: Luca Weiss <luca@z3ntu.xyz> Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Rob Clark <robdclark@chromium.org>
2019-04-18drm/msm: Remove pm_runtime calls from msm_iommu.cJordan Crouse
Currently the IOMMU code calls pm_runtime_get/put on the GPU or display device before doing a IOMMU operation. This was because usually the IOMMU driver didn't do power control of its own and since the hardware used the same clocks and power as the respective multimedia device it was a easy way to make sure that the power was available. Now two things have changed. First, the SMMU devices can do their own power control and more important bringing up the a6xx GPU isn't as easy as turning on some clocks. To bring the GPU up we need the GMU which itself needs the IOMMU so we have a chicken and egg problem. Luckily this is easily fixed by removing the pm_runtime calls from the functions and letting the device link to the IOMMU device handle the magic. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Tested-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Rob Clark <robdclark@chromium.org>
2019-04-18drm/msm: don't allocate pages from the MOVABLE zoneLucas Stach
The pages backing the GEM objects are kept pinned in place as long as they are alive, so they must not be allocated from the MOVABLE zone. Blocking page migration for too long will cause the VM subsystem headaches and will outright break CMA, as a few pinned pages in CMA will lead to failure to find the required large contiguous regions. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Rob Clark <robdclark@chromium.org>
2019-04-18drm/tegra: gem: Fix CPU-cache maintenance for BO's allocated using get_pages()Dmitry Osipenko
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 <stable@vger.kernel.org> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-04-17drm/panel: simple: add lg,acx467akm-7 panelJonathan Marek
Add ACX467AKM-7 4.95" 1080×1920 LCD panel that is found on the LG Nexus 5 (hammerhead) phone. Signed-off-by: Jonathan Marek <jonathan@marek.ca> [masneyb@onstation.org: checkpatch fixes; rename jdi,1080p-hammerhead binding to lg,acx467akm-7.] Signed-off-by: Brian Masney <masneyb@onstation.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20181124200628.24393-2-masneyb@onstation.org
2019-04-17dt-bindings: drm/panel: simple: add lg,acx467akm-7 panelBrian Masney
Add binding for the LG ACX467AKM-7 4.95" 1080×1920 LCD panel that is found on the LG Nexus 5 (hammerhead) phone. This appears to be a JDI panel based on some Internet searches, however a specific model number could not be found. I disassembled an old Nexus 5 with a broken screen and the LG part number is the only model number present on the back of the panel, so I think that is probably the best ID to use. Signed-off-by: Brian Masney <masneyb@onstation.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20181124200628.24393-1-masneyb@onstation.org
2019-04-17drm/mcde: Add device tree bindingsLinus Walleij
This adds the device tree bindings for the ST-Ericsson Multi Channel Display Engine MCDE as found in the U8500 SoCs. Cc: devicetree@vger.kernel.org Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190416142844.12038-1-linus.walleij@linaro.org
2019-04-18Revert "drm: allow render capable master with DRM_AUTH ioctls"Dave Airlie
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 <airlied@redhat.com>
2019-04-18drm/drv: Fix incorrect resolution of merge conflictJanusz Krzysztofik
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 <janusz.krzysztofik@linux.intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190417133232.16232-1-janusz.krzysztofik@linux.intel.com
2019-04-17drm/meson: add size and alignment requirements for dumb buffersNeil Armstrong
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 <sky.zhou@amlogic.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Sky Zhou <sky.zhou@amlogic.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190408090137.2402-1-narmstrong@baylibre.com
2019-04-17drm/meson: Make some functions staticYueHaibing
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 <yuehaibing@huawei.com> Acked-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190413141455.34020-1-yuehaibing@huawei.com
2019-04-17drm/sun4i: Make some symbols staticYueHaibing
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 <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190416145855.20852-1-yuehaibing@huawei.com
2019-04-17drm/lima: Make lima_sched_ops staticYueHaibing
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 <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Qiang Yu <yuq825@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190416144353.34024-1-yuehaibing@huawei.com
2019-04-17drm/i915: Update DRIVER_DATE to 20190417Joonas Lahtinen
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-04-17drm/i915/ehl: inherit icl cdclk init/uninitJani Nikula
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 <jose.souza@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Bob Paauwe <bob.j.paauwe@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Bob Paauwe <bob.j.paauwe@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190416082852.18141-1-jani.nikula@intel.com
2019-04-17drm: add drm_format_helper.c to kerneldocGerd Hoffmann
Also drop the dstclip parameter sphinx has warned about (leftover from an earlier patch version). Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20190416090533.28374-1-kraxel@redhat.com
2019-04-17drm/i915: Introduce struct class_instance for engines across the uAPIChris Wilson
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 <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com> Cc: Tony Ye <tony.ye@intel.com> Cc: Andi Shyti <andi@etezian.org> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Acked-by: Tony Ye <tony.ye@intel.com> Reviewed-by: Andi Shyti <andi@etezian.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190412071416.30097-1-chris@chris-wilson.co.uk
2019-04-16drm/lima: Use the drm_gem_fence_array_add helpers for our deps.Eric Anholt
It's a pretty direct port of what I did for v3d. Signed-off-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20190401222635.25013-8-eric@anholt.net Reviewed-and-tested-by: Qiang Yu <yuq825@gmail.com>
2019-04-16drm: Add helpers for setting up an array of dma_fence dependencies.Eric Anholt
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 <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20190401222635.25013-6-eric@anholt.net Reviewed-and-tested-by: Qiang Yu <yuq825@gmail.com> (v1)
2019-04-16drm: Expose "FB_DAMAGE_CLIPS" property to atomic aware user-space onlyDeepak Rawat
Plane property "FB_DAMAGE_CLIPS" can only be used by atomic aware user-space, so no point exposing it otherwise. Cc: <stable@vger.kernel.org> Signed-off-by: Deepak Rawat <drawat@vmware.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Fixes: d3b21767821e ("drm: Add a new plane property to send damage during plane update") Link: https://patchwork.freedesktop.org/patch/msgid/20190415172814.9840-1-drawat@vmware.com
2019-04-16drm/i915: fully convert the IRQ initialization macros to intel_uncorePaulo Zanoni
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ä <ville.syrjala@linux.intel.com> (v1) Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190410235344.31199-6-paulo.r.zanoni@intel.com
2019-04-16drm/i915: convert the IRQ initialization functions to intel_uncorePaulo Zanoni
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ä <ville.syrjala@linux.intel.com> (v1) Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190410235344.31199-5-paulo.r.zanoni@intel.com
2019-04-16drm/i915: add GEN2_ prefix to the I{E, I, M, S}R registersPaulo Zanoni
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ä <ville.syrjala@linux.intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190410235344.31199-4-paulo.r.zanoni@intel.com
2019-04-16drm/i915: don't specify the IRQ register in the gen2 macrosPaulo Zanoni
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 <paulo.r.zanoni@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190410235344.31199-3-paulo.r.zanoni@intel.com
2019-04-16drm/i915: refactor the IRQ init/reset macrosPaulo Zanoni
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ä <ville.syrjala@linux.intel.com> (v1) Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190410235344.31199-2-paulo.r.zanoni@intel.com
2019-04-16drm: aspeed: Clean up Kconfig optionsJoel Stanley
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 <sfr@canb.auug.org.au> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190405081117.27339-1-joel@jms.id.au
2019-04-16Merge tag 'gvt-next-2019-04-16' of https://github.com/intel/gvt-linux into ↵Joonas Lahtinen
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 <joonas.lahtinen@linux.intel.com> From: Zhenyu Wang <zhenyuw@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190416084814.GH17995@zhen-hp.sh.intel.com
2019-04-16dma-buf: explicitely note that dma-fence-chains use 64bit seqnoChristian König
Instead of checking the upper values of the sequence number use an explicit field in the dma_fence_ops structure to note if a sequence should be 32bit or 64bit. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/299655/
2019-04-16drm/i915: Mark up ips for RCU protectionChris Wilson
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 <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190412085410.10392-3-chris@chris-wilson.co.uk
2019-04-16drm/i915: Drop bool return from breadcrumbs signalerChris Wilson
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 <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190416085218.431-1-chris@chris-wilson.co.uk
2019-04-16drm/i915/gvt: Fix incorrect mask of mmio 0x22028 in gen8/9 mmio listColin Xu
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 <zhenyuw@linux.intel.com> Signed-off-by: Colin Xu <colin.xu@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-04-16drm/i915/gvt: addressed guest GPU hang with HWS index modeXiaolin Zhang
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 <zhenyuw@linux.intel.com> Signed-off-by: Xiaolin Zhang <xiaolin.zhang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-04-16Merge tag 'drm-intel-next-2019-04-04' into gvt-nextZhenyu Wang
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 <zhenyuw@linux.intel.com>
2019-04-15drm/i915: Nuke drm_crtc_state and use intel_atomic_state insteadManasi Navare
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 <ville.syrjala@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190415182210.13347-1-manasi.d.navare@intel.com
2019-04-15drm/i915/selftests: Skip live timeline/suspend tests if wedgedChris Wilson
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 <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190413125820.14112-4-chris@chris-wilson.co.uk
2019-04-15BackMerge v5.1-rc5 into drm-nextDave Airlie
Need rc5 for udl fix to add udl cleanups on top. Signed-off-by: Dave Airlie <airlied@redhat.com>
2019-04-15drm/amd/display: Add profiling tools for bandwidth validationJoshua Aberback
[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 <joshua.aberback@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-04-15drm/amd/display: Add fast_validate parameterJoshua Aberback
Add a fast_validate parameter in dc_validate_global_state for future use Signed-off-by: Joshua Aberback <joshua.aberback@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-04-15drm/amd/display: Relax requirements for CRTCs to be enabledNicholas Kazlauskas
[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 <nicholas.kazlauskas@amd.com> Reviewed-by: David Francis <David.Francis@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-04-15drm/amd/display: Check scaling info when determing update typeNicholas Kazlauskas
[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 <nicholas.kazlauskas@amd.com> Reviewed-by: David Francis <David.Francis@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-04-15drm/amd/display: Don't warn when DC update type > DM guessNicholas Kazlauskas
[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 <nicholas.kazlauskas@amd.com> Reviewed-by: David Francis <David.Francis@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-04-15drm/amd/display: Use surface directly when checking update typeNicholas Kazlauskas
[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 <nicholas.kazlauskas@amd.com> Reviewed-by: David Francis <David.Francis@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-04-15drm/amd/display: Add basic downscale and upscale valdiationNicholas Kazlauskas
[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 <nicholas.kazlauskas@amd.com> Reviewed-by: Harry Wentland <Harry.Wentland@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-04-15drm/amd/display: change name from dc_link_get_verified_link_cap to ↵Samson Tam
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 <Samson.Tam@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-04-15drm/amd/display: Rework DC plane filling and surface updatesNicholas Kazlauskas
[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 <nicholas.kazlauskas@amd.com> Reviewed-by: David Francis <David.Francis@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-04-15drm/amd/display: Recalculate pitch when buffers changeNicholas Kazlauskas
[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 <nicholas.kazlauskas@amd.com> Reviewed-by: David Francis <David.Francis@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-04-15drm/amd/display: Maintain z-ordering when creating planesNicholas Kazlauskas
[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 <nicholas.kazlauskas@amd.com> Reviewed-by: Sun peng Li <Sunpeng.Li@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
generated by cgit (git 2.34.1) at 2025-07-15 16:36:29 +0000