dri-devel February 2020

dri-devel@lists.freedesktop.org

302 participants
679 discussions

[PATCH 1/5 v5] drm/virtio: use consistent names for drm_files
by Gurchetan Singh 19 Feb '20

19 Feb '20

Minor cleanup, change: - file_priv--> file, - drm_file --> file. Signed-off-by: Gurchetan Singh <gurchetansingh(a)chromium.org> --- drivers/gpu/drm/virtio/virtgpu_ioctl.c | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c b/drivers/gpu/drm/virtio/virtgpu_ioctl.c index bbc31aef51f1..baad7e1c9505 100644 --- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c +++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c @@ -34,12 +34,12 @@ #include "virtgpu_drv.h" static int virtio_gpu_map_ioctl(struct drm_device *dev, void *data, - struct drm_file *file_priv) + struct drm_file *file) { struct virtio_gpu_device *vgdev = dev->dev_private; struct drm_virtgpu_map *virtio_gpu_map = data; - return virtio_gpu_mode_dumb_mmap(file_priv, vgdev->ddev, + return virtio_gpu_mode_dumb_mmap(file, vgdev->ddev, virtio_gpu_map->handle, &virtio_gpu_map->offset); } @@ -51,11 +51,11 @@ static int virtio_gpu_map_ioctl(struct drm_device *dev, void *data, * VIRTIO_GPUReleaseInfo struct (first XXX bytes) */ static int virtio_gpu_execbuffer_ioctl(struct drm_device *dev, void *data, - struct drm_file *drm_file) + struct drm_file *file) { struct drm_virtgpu_execbuffer *exbuf = data; struct virtio_gpu_device *vgdev = dev->dev_private; - struct virtio_gpu_fpriv *vfpriv = drm_file->driver_priv; + struct virtio_gpu_fpriv *vfpriv = file->driver_priv; struct virtio_gpu_fence *out_fence; int ret; uint32_t *bo_handles = NULL; @@ -116,7 +116,7 @@ static int virtio_gpu_execbuffer_ioctl(struct drm_device *dev, void *data, goto out_unused_fd; } - buflist = virtio_gpu_array_from_handles(drm_file, bo_handles, + buflist = virtio_gpu_array_from_handles(file, bo_handles, exbuf->num_bo_handles); if (!buflist) { ret = -ENOENT; @@ -178,7 +178,7 @@ static int virtio_gpu_execbuffer_ioctl(struct drm_device *dev, void *data, } static int virtio_gpu_getparam_ioctl(struct drm_device *dev, void *data, - struct drm_file *file_priv) + struct drm_file *file) { struct virtio_gpu_device *vgdev = dev->dev_private; struct drm_virtgpu_getparam *param = data; @@ -201,7 +201,7 @@ static int virtio_gpu_getparam_ioctl(struct drm_device *dev, void *data, } static int virtio_gpu_resource_create_ioctl(struct drm_device *dev, void *data, - struct drm_file *file_priv) + struct drm_file *file) { struct virtio_gpu_device *vgdev = dev->dev_private; struct drm_virtgpu_resource_create *rc = data; @@ -252,7 +252,7 @@ static int virtio_gpu_resource_create_ioctl(struct drm_device *dev, void *data, return ret; obj = &qobj->base.base; - ret = drm_gem_handle_create(file_priv, obj, &handle); + ret = drm_gem_handle_create(file, obj, &handle); if (ret) { drm_gem_object_release(obj); return ret; @@ -265,13 +265,13 @@ static int virtio_gpu_resource_create_ioctl(struct drm_device *dev, void *data, } static int virtio_gpu_resource_info_ioctl(struct drm_device *dev, void *data, - struct drm_file *file_priv) + struct drm_file *file) { struct drm_virtgpu_resource_info *ri = data; struct drm_gem_object *gobj = NULL; struct virtio_gpu_object *qobj = NULL; - gobj = drm_gem_object_lookup(file_priv, ri->bo_handle); + gobj = drm_gem_object_lookup(file, ri->bo_handle); if (gobj == NULL) return -ENOENT; -- 2.25.0.265.gbab2e86ba0-goog

3 10

[PATCH v3 0/2] Security mitigation for Intel Gen7/7.5 HWs
by Akeem G Abodunrin 19 Feb '20

19 Feb '20

Intel ID: PSIRT-TA-201910-001 CVEID: CVE-2019-14615 Summary of Vulnerability ------------------------ Insufficient control flow in certain data structures for some Intel(R) Processors with Intel Processor Graphics may allow an unauthenticated user to potentially enable information disclosure via local access Products affected: ------------------ Intel CPU’s with Gen7, Gen7.5 and Gen9 Graphics. Mitigation Summary ------------------ This patch provides mitigation for Gen7 and Gen7.5 hardware only. Patch for Gen9 devices have been provided and merged to Linux mainline, and backported to stable kernels. Note that Gen8 is not impacted due to a previously implemented workaround. The mitigation involves submitting a custom EU kernel prior to every context restore, in order to forcibly clear down residual EU and URB resources. The custom EU kernel are generated/assembled automatically, using Mesa (an open source tool) and IGT GPU tool - assembly sources are provided with IGT source code. This security mitigation change does not trigger any known performance regression. Performance is on par with current mainline/drm-tip. Note on Address Space Isolation (Full PPGTT) -------------------------------------------- Isolation of EU kernel assets should be considered complementary to the existing support for address space isolation (aka Full PPGTT), since without address space isolation there is minimal value in preventing leakage between EU contexts. Full PPGTT has long been supported on Gen Gfx devices since Gen8, and protection against EU residual leakage is a welcome addition for these newer platforms. By contrast, Gen7 and Gen7.5 device introduced Full PPGTT support only as a hardware development feature for anticipated Gen8 productization. Support was never intended for, or provided to the Linux kernels for these platforms. Recent work (still ongoing) to the mainline kernel is retroactively providing this support, but due to the level of complexity it is not practical to attempt to backport this to earlier stable kernels. Since without Full PPGTT, EU residuals protection has questionable benefit, *there are no plans to provide stable kernel backports for this patch series.* Mika Kuoppala (1): drm/i915: Add mechanism to submit a context WA on ring submission Prathap Kumar Valsan (1): drm/i915/gen7: Clear all EU/L3 residual contexts drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/gt/gen7_5_clearbuffer.h | 69 +++ drivers/gpu/drm/i915/gt/gen7_clearbuffer.h | 69 +++ drivers/gpu/drm/i915/gt/gen7_renderclear.c | 399 ++++++++++++++++++ drivers/gpu/drm/i915/gt/gen7_renderclear.h | 15 + drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 17 +- .../gpu/drm/i915/gt/intel_ring_submission.c | 135 +++++- 7 files changed, 698 insertions(+), 7 deletions(-) create mode 100644 drivers/gpu/drm/i915/gt/gen7_5_clearbuffer.h create mode 100644 drivers/gpu/drm/i915/gt/gen7_clearbuffer.h create mode 100644 drivers/gpu/drm/i915/gt/gen7_renderclear.c create mode 100644 drivers/gpu/drm/i915/gt/gen7_renderclear.h -- 2.20.1

1 2

[pull] amdgpu 5.6 fixes
by Alex Deucher 19 Feb '20

19 Feb '20

Hi Dave, Daniel, Fixes for 5.6. The following changes since commit 6f4134b30b6ee33e2fd4d602099e6c5e60d0351a: Merge tag 'drm-intel-next-fixes-2020-02-13' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2020-02-14 13:04:46 +1000) are available in the Git repository at: git://people.freedesktop.org/~agd5f/linux tags/amd-drm-fixes-5.6-2020-02-19 for you to fetch changes up to 6c62ce8073daf27ae3fd03b6929d6cea3887eeb2: drm/amdgpu/display: clean up hdcp workqueue handling (2020-02-19 11:03:24 -0500) ---------------------------------------------------------------- amd-drm-fixes-5.6-2020-02-19: amdgpu: - HDCP fixes - xclk fix for raven - GFXOFF fixes ---------------------------------------------------------------- Alex Deucher (4): drm/amdgpu/soc15: fix xclk for raven drm/amdgpu/gfx9: disable gfxoff when reading rlc clock drm/amdgpu/gfx10: disable gfxoff when reading rlc clock drm/amdgpu/display: clean up hdcp workqueue handling Bhawanpreet Lakha (2): drm/amd/display: fix backwards byte order in rx_caps. drm/amd/display: fix dtm unloading Evan Quan (1): drm/amd/powerplay: always refetch the enabled features status on dpm enablement changzhu (1): drm/amdgpu: add is_raven_kicker judgement for raven1 drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 26 +++++++++++++++++++++- drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 2 ++ drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 13 +++++++++-- drivers/gpu/drm/amd/amdgpu/soc15.c | 7 +++++- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 10 +++++---- .../drm/amd/display/modules/hdcp/hdcp2_execution.c | 4 ++-- drivers/gpu/drm/amd/powerplay/smu_v11_0.c | 6 ++--- 7 files changed, 55 insertions(+), 13 deletions(-)

1 0

[PATCH v5] dt-bindings: display: renesas: du: Document optional reset properties
by Geert Uytterhoeven 19 Feb '20

19 Feb '20

Document the optional properties for describing module resets, to support resetting display channels on R-Car Gen2 and Gen3. Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be> Acked-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Acked-by: Rob Herring <robh(a)kernel.org> --- Who's taking this kind of patches? V1 was submmitted in March 2017. v5: - Rebase on top of renesas,cmms and renesas,vsps patches, v4: - Use "All but R8A7779" instead of "R8A779[0123456]", to reduce future churn, v3: - Add Acked-by, - Drop LVDS resets, as LVDS is now covered by a separate binding, - Update the example. v2: - s/phandles/phandle/. --- .../devicetree/bindings/display/renesas,du.txt | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt b/Documentation/devicetree/bindings/display/renesas,du.txt index eb4ae41fe41f83c7..51cd4d1627703a15 100644 --- a/Documentation/devicetree/bindings/display/renesas,du.txt +++ b/Documentation/devicetree/bindings/display/renesas,du.txt @@ -50,6 +50,14 @@ Required Properties: VSP instance that serves the DU channel, and the channel index identifies the LIF instance in that VSP. +Optional properties: + - resets: A list of phandle + reset-specifier pairs, one for each entry in + the reset-names property. + - reset-names: Names of the resets. This property is model-dependent. + - All but R8A7779 use one reset for a group of one or more successive + channels. The resets must be named "du.x" with "x" being the numerical + index of the lowest channel in the group. + Required nodes: The connections to the DU output video ports are modeled using the OF graph @@ -96,6 +104,8 @@ Example: R8A7795 (R-Car H3) ES2.0 DU <&cpg CPG_MOD 722>, <&cpg CPG_MOD 721>; clock-names = "du.0", "du.1", "du.2", "du.3"; + resets = <&cpg 724>, <&cpg 722>; + reset-names = "du.0", "du.2"; renesas,cmms = <&cmm0>, <&cmm1>, <&cmm2>, <&cmm3>; renesas,vsps = <&vspd0 0>, <&vspd1 0>, <&vspd2 0>, <&vspd0 1>; -- 2.17.1

4 4

Re: LED backlight on Droid 4 and others
by Pavel Machek 19 Feb '20

19 Feb '20

Hi! > > > It would be good to get LED backlight to work in clean way for 5.6 > > > kernel. > ... > > > [If you have an idea what else is needed, it would be welcome; it > > > works for me in development tree but not in tree I'd like to > > > upstream.] > > > > > > Lee, would you be willing to take "backlight: add led-backlight > > > driver"? Would it help if I got "leds: Add managed API to get a LED > > > from a device driver" and "leds: Add of_led_get() and led_put()" into > > > for_next tree of the LED subsystem? > > > > It looks like you have an open question from Tony on v10. > > > > Is that patch orthogonal, or are there depend{ants,encies}? > > Uhh looks like we messed up a bit with integration. Now droid4 > LCD backlight can no longer be enabled at all manually in v5.6-rc1 > without the "add led-backlight driver" patch.. Should we just > merge it to fix it rather than start scrambling with other > temporary hacks? We should just merge the "add led-backlight driver". Everything should be ready for it. I'm sorry if I broke something working, I was not aware it worked at all. Unfortunately, this is backlight code, not LED, so I can't just merge it. > I don't care if we use "default-brightness", or if we use > "default-brightness-level". The binding merged says now > "default-brightness", so let's go with that one. That's what > other LED drivers are using too. No opinion on that. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

3 5

[PATCH] drm/sun4i: dsi: Avoid hotplug race with DRM driver bind
by Samuel Holland 19 Feb '20

19 Feb '20

We need to make sure that the DRM driver is fully registered before allowing the panel to be attached. Otherwise, we may trigger a hotplug event before sun4i_framebuffer_init() sets up drm->mode_config.funcs, causing a NULL pointer dereference. Fixes: 1a2703bd7356 ("drm/sun4i: dsi: Allow binding the host without a panel") Signed-off-by: Samuel Holland <samuel(a)sholland.org> --- This fixes a bug in my previous patch series, that I didn't catch until it was already merged. --- drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c index 9aa78c73873c..9cc1bb69fcda 100644 --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c @@ -970,7 +970,7 @@ static int sun6i_dsi_attach(struct mipi_dsi_host *host, if (IS_ERR(panel)) return PTR_ERR(panel); - if (!dsi->drm) + if (!dsi->drm || !dsi->drm->registered) return -EPROBE_DEFER; dsi->panel = panel; -- 2.24.1

2 1

[PATCH] drm/hisilicon: Fixed pcie resource conflict between drm and firmware
by Tian Tao 19 Feb '20

19 Feb '20

remove the framebuffer initialized by fireware/bootloader,which will use hibmc's pcie resource, and may cause conflict. Signed-off-by: Tian Tao <tiantao6(a)hisilicon.com> Signed-off-by: Gong junjie <gongjunjie2(a)huawei.com> --- drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c index 5f612f6..7ebe831 100644 --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c @@ -47,6 +47,22 @@ static irqreturn_t hibmc_drm_interrupt(int irq, void *arg) return IRQ_HANDLED; } +static void hibmc_remove_framebuffers(struct pci_dev *pdev) +{ + struct apertures_struct *ap; + + ap = alloc_apertures(1); + if (!ap) + return; + + ap->ranges[0].base = pci_resource_start(pdev, 0); + ap->ranges[0].size = pci_resource_len(pdev, 0); + + drm_fb_helper_remove_conflicting_framebuffers(ap, "hibmcdrmfb", false); + + kfree(ap); +} + static struct drm_driver hibmc_driver = { .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC, .fops = &hibmc_fops, @@ -327,6 +343,8 @@ static int hibmc_pci_probe(struct pci_dev *pdev, struct drm_device *dev; int ret; + hibmc_remove_framebuffers(pdev); + dev = drm_dev_alloc(&hibmc_driver, &pdev->dev); if (IS_ERR(dev)) { DRM_ERROR("failed to allocate drm_device\n"); -- 2.7.4

2 1

[PATCH] drm: kirin: Revert "Fix for hikey620 display offset problem"
by John Stultz 19 Feb '20

19 Feb '20

This reverts commit ff57c6513820efe945b61863cf4a51b79f18b592. With the commit ff57c6513820 ("drm: kirin: Fix for hikey620 display offset problem") we added support for handling LDI overflows by resetting the hardware. However, its been observed that when we do hit the LDI overflow condition, the irq seems to be screaming, and we do nothing but stream: [drm:ade_irq_handler [kirin_drm]] *ERROR* LDI underflow! over and over to the screen I've tried a few appraoches to avoid this, but none has yet been successful and the cure here is worse then the original disease, so revert this for now. Cc: Xinliang Liu <z.liuxinliang(a)hisilicon.com> Cc: Rongrong Zou <zourongrong(a)gmail.com> Cc: Xinwei Kong <kong.kongxinwei(a)hisilicon.com> Cc: Chen Feng <puck.chen(a)hisilicon.com> Cc: Sam Ravnborg <sam(a)ravnborg.org> Cc: David Airlie <airlied(a)linux.ie> Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: dri-devel <dri-devel(a)lists.freedesktop.org> Fixes: ff57c6513820 ("drm: kirin: Fix for hikey620 display offset problem") Signed-off-by: John Stultz <john.stultz(a)linaro.org> --- .../gpu/drm/hisilicon/kirin/kirin_ade_reg.h | 1 - .../gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 20 ------------------- 2 files changed, 21 deletions(-) diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h b/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h index 0da860200410..e2ac09894a6d 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h @@ -83,7 +83,6 @@ #define VSIZE_OFST 20 #define LDI_INT_EN 0x741C #define FRAME_END_INT_EN_OFST 1 -#define UNDERFLOW_INT_EN_OFST 2 #define LDI_CTRL 0x7420 #define BPP_OFST 3 #define DATA_GATE_EN BIT(2) diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c index 73cd28a6ea07..86000127d4ee 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c @@ -46,7 +46,6 @@ struct ade_hw_ctx { struct clk *media_noc_clk; struct clk *ade_pix_clk; struct reset_control *reset; - struct work_struct display_reset_wq; bool power_on; int irq; @@ -136,7 +135,6 @@ static void ade_init(struct ade_hw_ctx *ctx) */ ade_update_bits(base + ADE_CTRL, FRM_END_START_OFST, FRM_END_START_MASK, REG_EFFECTIVE_IN_ADEEN_FRMEND); - ade_update_bits(base + LDI_INT_EN, UNDERFLOW_INT_EN_OFST, MASK(1), 1); } static bool ade_crtc_mode_fixup(struct drm_crtc *crtc, @@ -304,17 +302,6 @@ static void ade_crtc_disable_vblank(struct drm_crtc *crtc) MASK(1), 0); } -static void drm_underflow_wq(struct work_struct *work) -{ - struct ade_hw_ctx *ctx = container_of(work, struct ade_hw_ctx, - display_reset_wq); - struct drm_device *drm_dev = ctx->crtc->dev; - struct drm_atomic_state *state; - - state = drm_atomic_helper_suspend(drm_dev); - drm_atomic_helper_resume(drm_dev, state); -} - static irqreturn_t ade_irq_handler(int irq, void *data) { struct ade_hw_ctx *ctx = data; @@ -331,12 +318,6 @@ static irqreturn_t ade_irq_handler(int irq, void *data) MASK(1), 1); drm_crtc_handle_vblank(crtc); } - if (status & BIT(UNDERFLOW_INT_EN_OFST)) { - ade_update_bits(base + LDI_INT_CLR, UNDERFLOW_INT_EN_OFST, - MASK(1), 1); - DRM_ERROR("LDI underflow!"); - schedule_work(&ctx->display_reset_wq); - } return IRQ_HANDLED; } @@ -919,7 +900,6 @@ static void *ade_hw_ctx_alloc(struct platform_device *pdev, if (ret) return ERR_PTR(-EIO); - INIT_WORK(&ctx->display_reset_wq, drm_underflow_wq); ctx->crtc = crtc; return ctx; -- 2.17.1

1 0

[PATCH 1/5 v3] drm/virtio: use consistent names for drm_files
by Gurchetan Singh 19 Feb '20

19 Feb '20

1 5

[PATCH v2] drm/msm: devcoredump should dump MSM_SUBMIT_BO_DUMP buffers
by Rob Clark 18 Feb '20

18 Feb '20

From: Rob Clark <robdclark(a)chromium.org> Also log buffers with the DUMP flag set, to ensure we capture all useful cmdstream in crashdump state with modern mesa. Otherwise we miss out on the contents of "state object" cmdstream buffers. v2: add missing 'inline' Signed-off-by: Rob Clark <robdclark(a)chromium.org> --- drivers/gpu/drm/msm/msm_gem.h | 10 ++++++++++ drivers/gpu/drm/msm/msm_gpu.c | 28 +++++++++++++++++++++++----- drivers/gpu/drm/msm/msm_rd.c | 8 +------- 3 files changed, 34 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h index 9e0953c2b7ce..dcee0e223ed8 100644 --- a/drivers/gpu/drm/msm/msm_gem.h +++ b/drivers/gpu/drm/msm/msm_gem.h @@ -160,4 +160,14 @@ struct msm_gem_submit { } bos[0]; }; +/* helper to determine of a buffer in submit should be dumped, used for both + * devcoredump and debugfs cmdstream dumping: + */ +static inline bool +should_dump(struct msm_gem_submit *submit, int idx) +{ + extern bool rd_full; + return rd_full || (submit->bos[idx].flags & MSM_SUBMIT_BO_DUMP); +} + #endif /* __MSM_GEM_H__ */ diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c index 18f3a5c53ffb..615c5cda5389 100644 --- a/drivers/gpu/drm/msm/msm_gpu.c +++ b/drivers/gpu/drm/msm/msm_gpu.c @@ -355,16 +355,34 @@ static void msm_gpu_crashstate_capture(struct msm_gpu *gpu, state->cmd = kstrdup(cmd, GFP_KERNEL); if (submit) { - int i; - - state->bos = kcalloc(submit->nr_cmds, + int i, nr = 0; + + /* count # of buffers to dump: */ + for (i = 0; i < submit->nr_bos; i++) + if (should_dump(submit, i)) + nr++; + /* always dump cmd bo's, but don't double count them: */ + for (i = 0; i < submit->nr_cmds; i++) + if (!should_dump(submit, submit->cmd[i].idx)) + nr++; + + state->bos = kcalloc(nr, sizeof(struct msm_gpu_state_bo), GFP_KERNEL); + for (i = 0; i < submit->nr_bos; i++) { + if (should_dump(submit, i)) { + msm_gpu_crashstate_get_bo(state, submit->bos[i].obj, + submit->bos[i].iova, submit->bos[i].flags); + } + } + for (i = 0; state->bos && i < submit->nr_cmds; i++) { int idx = submit->cmd[i].idx; - msm_gpu_crashstate_get_bo(state, submit->bos[idx].obj, - submit->bos[idx].iova, submit->bos[idx].flags); + if (!should_dump(submit, submit->cmd[i].idx)) { + msm_gpu_crashstate_get_bo(state, submit->bos[idx].obj, + submit->bos[idx].iova, submit->bos[idx].flags); + } } } diff --git a/drivers/gpu/drm/msm/msm_rd.c b/drivers/gpu/drm/msm/msm_rd.c index af7ceb246c7c..732f65df5c4f 100644 --- a/drivers/gpu/drm/msm/msm_rd.c +++ b/drivers/gpu/drm/msm/msm_rd.c @@ -43,7 +43,7 @@ #include "msm_gpu.h" #include "msm_gem.h" -static bool rd_full = false; +bool rd_full = false; MODULE_PARM_DESC(rd_full, "If true, $debugfs/.../rd will snapshot all buffer contents"); module_param_named(rd_full, rd_full, bool, 0600); @@ -336,12 +336,6 @@ static void snapshot_buf(struct msm_rd_state *rd, msm_gem_put_vaddr(&obj->base); } -static bool -should_dump(struct msm_gem_submit *submit, int idx) -{ - return rd_full || (submit->bos[idx].flags & MSM_SUBMIT_BO_DUMP); -} - /* called under struct_mutex */ void msm_rd_dump_submit(struct msm_rd_state *rd, struct msm_gem_submit *submit, const char *fmt, ...) -- 2.24.1

2 1

← Newer
1
...
38
39
40
41
42
43
44
...
68
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel February 2020