dri-devel February 2020

dri-devel@lists.freedesktop.org

302 participants
679 discussions

[PATCH] 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. 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..22b4ccd7bb28 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 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

[Bug 205915] New: AMDGPU: Screen flicker after resume from suspend
by bugzilla-daemon＠bugzilla.kernel.org 18 Feb '20

18 Feb '20

https://bugzilla.kernel.org/show_bug.cgi?id=205915 Bug ID: 205915 Summary: AMDGPU: Screen flicker after resume from suspend Product: Drivers Version: 2.5 Kernel Version: 5.5.0-rc2 Hardware: x86-64 OS: Linux Tree: Fedora Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: onil(a)pm.me Regression: No After resume from suspend screen flickers, flickering intensifies during mouse movement. reverting to 5.4 fixes the issue. workaround: changing dpm_force_performance_level to "high" (and optionally afterwards to "low") resolves the issue while "auto" introduces it again. OS: Fedora 31 on gnome wayland GPU: 5700XT Pulse Monitor: LG 27UK650W on DP 1.4 Mesa: 19.3 no info/error message on syslog. -- You are receiving this mail because: You are watching the assignee of the bug.

1 16

[PATCH v3 00/12] drm/i915: Add support for HDCP 1.4 over MST connectors
by Sean Paul 18 Feb '20

18 Feb '20

From: Sean Paul <seanpaul(a)chromium.org> Hey all, Here's v3, which addresses all review comments in v2. Sean Sean Paul (12): drm/i915: Fix sha_text population code drm/i915: Clear the repeater bit on HDCP disable drm/i915: WARN if HDCP signalling is enabled upon disable drm/i915: Intercept Aksv writes in the aux hooks drm/i915: Use the cpu_transcoder in intel_hdcp to toggle HDCP signalling drm/i915: Factor out hdcp->value assignments drm/i915: Protect workers against disappearing connectors drm/i915: Don't fully disable HDCP on a port if multiple pipes are using it drm/i915: Support DP MST in enc_to_dig_port() function drm/i915: Use ddi_update_pipe in intel_dp_mst drm/i915: Factor out HDCP shim functions from dp for use by dp_mst drm/i915: Add HDCP 1.4 support for MST connectors drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/display/intel_ddi.c | 27 +- drivers/gpu/drm/i915/display/intel_ddi.h | 2 + .../drm/i915/display/intel_display_types.h | 27 +- drivers/gpu/drm/i915/display/intel_dp.c | 619 +--------------- drivers/gpu/drm/i915/display/intel_dp.h | 7 + drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 680 ++++++++++++++++++ drivers/gpu/drm/i915/display/intel_dp_mst.c | 15 + drivers/gpu/drm/i915/display/intel_hdcp.c | 195 +++-- drivers/gpu/drm/i915/display/intel_hdmi.c | 18 +- include/drm/drm_hdcp.h | 3 + 11 files changed, 932 insertions(+), 662 deletions(-) create mode 100644 drivers/gpu/drm/i915/display/intel_dp_hdcp.c -- Sean Paul, Software Engineer, Google / Chromium OS

3 17

[PATCH] drm/msm/a5xx: Always set an OPP supported hardware value
by Jordan Crouse 18 Feb '20

18 Feb '20

If the opp table specifies opp-supported-hw as a property but the driver has not set a supported hardware value the OPP subsystem will reject all the table entries. Set a "default" value that will match the default table entries but not conflict with any possible real bin values. Also fix a small memory leak and free the buffer allocated by nvmem_cell_read(). Signed-off-by: Jordan Crouse <jcrouse(a)codeaurora.org> --- drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 27 ++++++++++++++++++++------- 1 file changed, 20 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c index 7d9e63e..724024a 100644 --- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c +++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c @@ -1446,18 +1446,31 @@ static const struct adreno_gpu_funcs funcs = { static void check_speed_bin(struct device *dev) { struct nvmem_cell *cell; - u32 bin, val; + u32 val; + + /* + * If the OPP table specifies a opp-supported-hw property then we have + * to set something with dev_pm_opp_set_supported_hw() or the table + * doesn't get populated so pick an arbitrary value that should + * ensure the default frequencies are selected but not conflict with any + * actual bins + */ + val = 0x80; cell = nvmem_cell_get(dev, "speed_bin"); - /* If a nvmem cell isn't defined, nothing to do */ - if (IS_ERR(cell)) - return; + if (!IS_ERR(cell)) { + void *buf = nvmem_cell_read(cell, NULL); + + if (!IS_ERR(buf)) { + u8 bin = *((u8 *) buf); - bin = *((u32 *) nvmem_cell_read(cell, NULL)); - nvmem_cell_put(cell); + val = (1 << bin); + kfree(buf); + } - val = (1 << bin); + nvmem_cell_put(cell); + } dev_pm_opp_set_supported_hw(dev, &val, 1); } -- 2.7.4

2 1

[RESEND][PATCH] drm/bridge: analogix-anx78xx: Fix drm_dp_link helper removal
by Torsten Duwe 18 Feb '20

18 Feb '20

drm_dp_link_rate_to_bw_code and ...bw_code_to_link_rate simply divide by and multiply with 27000, respectively. Avoid an overflow in the u8 dpcd[0] and the multiply+divide alltogether. fixes: ff1e8fb68ea06027 ("analogix-anx78xx: Avoid drm_dp_link helpers") Signed-off-by: Torsten Duwe <duwe(a)suse.de> Reviewed-by: Thierry Reding <treding(a)nvidia.com> --- https://patchwork.freedesktop.org/patch/343003/ (dropped the review mark) https://lists.freedesktop.org/archives/dri-devel/2020-January/253535.html --- diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c index 41867be03751..864423f59d66 100644 --- a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c @@ -722,10 +722,9 @@ static int anx78xx_dp_link_training(struct anx78xx *anx78xx) if (err) return err; - dpcd[0] = drm_dp_max_link_rate(anx78xx->dpcd); - dpcd[0] = drm_dp_link_rate_to_bw_code(dpcd[0]); err = regmap_write(anx78xx->map[I2C_IDX_TX_P0], - SP_DP_MAIN_LINK_BW_SET_REG, dpcd[0]); + SP_DP_MAIN_LINK_BW_SET_REG, + anx78xx->dpcd[DP_MAX_LINK_RATE]); if (err) return err;

2 1

[PATCH] dma-buf: free dmabuf->name in dma_buf_release()
by Cong Wang 18 Feb '20

18 Feb '20

dma-buff name can be set via DMA_BUF_SET_NAME ioctl, but once set it never gets freed. Free it in dma_buf_release(). Fixes: bb2bb9030425 ("dma-buf: add DMA_BUF_SET_NAME ioctls") Reported-by: syzbot+b2098bc44728a4efb3e9(a)syzkaller.appspotmail.com Cc: Greg Hackmann <ghackmann(a)google.com> Cc: Chenbo Feng <fengc(a)google.com> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Signed-off-by: Cong Wang <xiyou.wangcong(a)gmail.com> --- drivers/dma-buf/dma-buf.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index ce41cd9b758a..2427398ff22a 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -108,6 +108,7 @@ static int dma_buf_release(struct inode *inode, struct file *file) dma_resv_fini(dmabuf->resv); module_put(dmabuf->owner); + kfree(dmabuf->name); kfree(dmabuf); return 0; } -- 2.21.0

2 2

[PATCH v2 0/8] do not store GPU address in TTM
by Nirmoy Das 18 Feb '20

18 Feb '20

With this patch series I am trying to remove GPU address dependency in TTM and moving GPU address calculation to individual drm drivers. I tested this patch series on qxl, bochs and amdgpu. Christian tested it on radeon HW. It would be nice if someone test this for nouveau and vmgfx. v2: set bo->offset = 0 for drm/nouveau if bo->mem.mm_node == NULL Nirmoy Das (8): drm/amdgpu: move ttm bo->offset to amdgpu_bo drm/radeon: don't use ttm bo->offset drm/vmwgfx: don't use ttm bo->offset drm/nouveau: don't use ttm bo->offset drm/qxl: don't use ttm bo->offset drm/vram-helper: don't use ttm bo->offset drm/bochs: use drm_gem_vram_offset to get bo offset drm/ttm: do not keep GPU dependent addresses drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 22 ++++++++++++++-- drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 29 ++++++++++++++++----- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 1 + drivers/gpu/drm/bochs/bochs_kms.c | 2 +- drivers/gpu/drm/drm_gem_vram_helper.c | 2 +- drivers/gpu/drm/nouveau/dispnv04/crtc.c | 6 ++--- drivers/gpu/drm/nouveau/dispnv04/disp.c | 2 +- drivers/gpu/drm/nouveau/dispnv04/overlay.c | 6 ++--- drivers/gpu/drm/nouveau/dispnv50/base507c.c | 2 +- drivers/gpu/drm/nouveau/dispnv50/core507d.c | 2 +- drivers/gpu/drm/nouveau/dispnv50/ovly507e.c | 2 +- drivers/gpu/drm/nouveau/dispnv50/wndw.c | 2 +- drivers/gpu/drm/nouveau/dispnv50/wndwc37e.c | 2 +- drivers/gpu/drm/nouveau/nouveau_abi16.c | 8 +++--- drivers/gpu/drm/nouveau/nouveau_bo.c | 1 + drivers/gpu/drm/nouveau/nouveau_bo.h | 3 +++ drivers/gpu/drm/nouveau/nouveau_chan.c | 2 +- drivers/gpu/drm/nouveau/nouveau_dmem.c | 2 +- drivers/gpu/drm/nouveau/nouveau_fbcon.c | 2 +- drivers/gpu/drm/nouveau/nouveau_gem.c | 10 +++---- drivers/gpu/drm/qxl/qxl_drv.h | 6 ++--- drivers/gpu/drm/qxl/qxl_kms.c | 5 ++-- drivers/gpu/drm/qxl/qxl_object.h | 5 ---- drivers/gpu/drm/qxl/qxl_ttm.c | 9 ------- drivers/gpu/drm/radeon/radeon.h | 1 + drivers/gpu/drm/radeon/radeon_object.h | 16 +++++++++++- drivers/gpu/drm/radeon/radeon_ttm.c | 4 +-- drivers/gpu/drm/ttm/ttm_bo.c | 7 ----- drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 4 +-- drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 2 -- include/drm/ttm/ttm_bo_api.h | 2 -- include/drm/ttm/ttm_bo_driver.h | 1 - 35 files changed, 99 insertions(+), 76 deletions(-) -- 2.25.0

1 8

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

18 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

[RESEND][PATCH] drm/bridge: analogix-anx6345: Avoid duplicate -supply suffix
by Torsten Duwe 18 Feb '20

18 Feb '20

of_get_regulator() will unconditionally add "-supply" to form the property name. This is documented in commit 69511a452e6dc ("map consumer regulator based on device tree"). Remove the suffix from the requests. Signed-off-by: Torsten Duwe <duwe(a)suse.de> Reviewed-by: Mark Brown <broonie(a)kernel.org> --- Mark has actually reviewed this one. patchwork.freedesktop.org dropped that along with the comments(?) https://patchwork.freedesktop.org/patch/343005/ https://lists.freedesktop.org/archives/dri-devel/2020-January/253535.html --- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c @@ -712,14 +709,14 @@ static int anx6345_i2c_probe(struct i2c_client *client, DRM_DEBUG("No panel found\n"); /* 1.2V digital core power regulator */ - anx6345->dvdd12 = devm_regulator_get(dev, "dvdd12-supply"); + anx6345->dvdd12 = devm_regulator_get(dev, "dvdd12"); if (IS_ERR(anx6345->dvdd12)) { DRM_ERROR("dvdd12-supply not found\n"); return PTR_ERR(anx6345->dvdd12); } /* 2.5V digital core power regulator */ - anx6345->dvdd25 = devm_regulator_get(dev, "dvdd25-supply"); + anx6345->dvdd25 = devm_regulator_get(dev, "dvdd25"); if (IS_ERR(anx6345->dvdd25)) { DRM_ERROR("dvdd25-supply not found\n"); return PTR_ERR(anx6345->dvdd25);

1 0

[PATCH v2] drm/bridge: Fix the bridge kernel doc
by Boris Brezillon 18 Feb '20

18 Feb '20

Commit 751465913f04 ("drm/bridge: Add a drm_bridge_state object") introduced new helpers and hooks but the kernel was slightly broken. Fix that now. v2: * Fix the drm_atomic_add_encoder_bridges() doc Fixes: 751465913f04 ("drm/bridge: Add a drm_bridge_state object") Signed-off-by: Boris Brezillon <boris.brezillon(a)collabora.com> --- drivers/gpu/drm/drm_atomic.c | 5 +++-- include/drm/drm_atomic.h | 2 +- include/drm/drm_bridge.h | 15 ++++++++------- 3 files changed, 12 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 65c46ed049c5..9ccfbf213d72 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -1098,8 +1098,9 @@ EXPORT_SYMBOL(drm_atomic_get_new_bridge_state); * * This function adds all bridges attached to @encoder. This is needed to add * bridge states to @state and make them available when - * &bridge_funcs.atomic_{check,pre_enable,enable,disable_post_disable}() are - * called + * &drm_bridge_funcs.atomic_check(), &drm_bridge_funcs.atomic_pre_enable(), + * &drm_bridge_funcs.atomic_enable(), + * &drm_bridge_funcs.atomic_disable_post_disable() are called. * * Returns: * 0 on success or can fail with -EDEADLK or -ENOMEM. When the error is EDEADLK diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h index 52d65a055491..7b6cb4774e7d 100644 --- a/include/drm/drm_atomic.h +++ b/include/drm/drm_atomic.h @@ -1016,7 +1016,7 @@ struct drm_bus_cfg { * @format: format used on this bus (one of the MEDIA_BUS_FMT_* format) * * This field should not be directly modified by drivers - * (&drm_atomic_bridge_chain_select_bus_fmts() takes care of the bus + * (drm_atomic_bridge_chain_select_bus_fmts() takes care of the bus * format negotiation). */ u32 format; diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h index 45626ecf20f8..999faaaab9a1 100644 --- a/include/drm/drm_bridge.h +++ b/include/drm/drm_bridge.h @@ -349,9 +349,9 @@ struct drm_bridge_funcs { * Duplicate the current bridge state object (which is guaranteed to be * non-NULL). * - * The atomic_duplicate_state() is optional. When not implemented the - * core allocates a drm_bridge_state object and calls - * &__drm_atomic_helper_bridge_duplicate_state() to initialize it. + * The atomic_duplicate_state() hook is optional. When not implemented + * the core allocates a drm_bridge_state object and calls + * __drm_atomic_helper_bridge_duplicate_state() to initialize it. * * RETURNS: * A valid drm_bridge_state object or NULL if the allocation fails. @@ -407,11 +407,11 @@ struct drm_bridge_funcs { * Formats listed in the returned array should be listed in decreasing * preference order (the core will try all formats until it finds one * that works). When the format is not supported NULL should be - * returned and *num_output_fmts should be set to 0. + * returned and num_output_fmts should be set to 0. * * This method is called on all elements of the bridge chain as part of * the bus format negotiation process that happens in - * &drm_atomic_bridge_chain_select_bus_fmts(). + * drm_atomic_bridge_chain_select_bus_fmts(). * This method is optional. When not implemented, the core will bypass * bus format negotiation on this element of the bridge without * failing, and the previous element in the chain will be passed @@ -478,9 +478,10 @@ struct drm_bridge_funcs { * * Note that the atomic_reset() semantics is not exactly matching the * reset() semantics found on other components (connector, plane, ...). - * 1/ The reset operation happens when the bridge is attached, not when + * + * 1. The reset operation happens when the bridge is attached, not when * drm_mode_config_reset() is called - * 2/ It's meant to be used exclusively on bridges that have been + * 2. It's meant to be used exclusively on bridges that have been * converted to the ATOMIC API * * RETURNS: -- 2.24.1

2 2

← Newer
1
...
39
40
41
42
43
44
45
...
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