dri-devel September 2021

dri-devel@lists.freedesktop.org

348 participants
817 discussions

Enabling TTM kerneldoc
by Christian König 09 Sep '21

09 Sep '21

Last round for this set I think, already got RBs for most patches. Only patch #2 is currently missing anything. Please point out anything which can be quickly improved and keep in mind that it's better to have this enabled with some typos than not enabled at all. Cheers, Christian.

4 11

[PATCH 01/14] drm/kmb: Enable LCD DMA for low TVDDCV
by Anitha Chrisanthus 09 Sep '21

09 Sep '21

From: Edmund Dea <edmund.j.dea(a)intel.com> There's an undocumented dependency between LCD layer enable bits [2-5] and the AXI pipelined read enable bit [28] in the LCD_CONTROL register. The proper order of operation is: 1) Clear AXI pipelined read enable bit 2) Set LCD layers 3) Set AXI pipelined read enable bit With this update, LCD can start DMA when TVDDCV is reduced down to 700mV. Fixes: 7f7b96a8a0a1 ("drm/kmb: Add support for KeemBay Display") Signed-off-by: Edmund Dea <edmund.j.dea(a)intel.com> --- drivers/gpu/drm/kmb/kmb_drv.c | 14 ++++++++++++++ drivers/gpu/drm/kmb/kmb_plane.c | 15 +++++++++++++-- 2 files changed, 27 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/kmb/kmb_drv.c b/drivers/gpu/drm/kmb/kmb_drv.c index 96ea1a2c11dd..c0b1c6f99249 100644 --- a/drivers/gpu/drm/kmb/kmb_drv.c +++ b/drivers/gpu/drm/kmb/kmb_drv.c @@ -203,6 +203,7 @@ static irqreturn_t handle_lcd_irq(struct drm_device *dev) unsigned long status, val, val1; int plane_id, dma0_state, dma1_state; struct kmb_drm_private *kmb = to_kmb(dev); + u32 ctrl = 0; status = kmb_read_lcd(kmb, LCD_INT_STATUS); @@ -227,6 +228,19 @@ static irqreturn_t handle_lcd_irq(struct drm_device *dev) kmb_clr_bitmask_lcd(kmb, LCD_CONTROL, kmb->plane_status[plane_id].ctrl); + ctrl = kmb_read_lcd(kmb, LCD_CONTROL); + if (!(ctrl & (LCD_CTRL_VL1_ENABLE | + LCD_CTRL_VL2_ENABLE | + LCD_CTRL_GL1_ENABLE | + LCD_CTRL_GL2_ENABLE))) { + /* If no LCD layers are using DMA, + * then disable DMA pipelined AXI read + * transactions. + */ + kmb_clr_bitmask_lcd(kmb, LCD_CONTROL, + LCD_CTRL_PIPELINE_DMA); + } + kmb->plane_status[plane_id].disable = false; } } diff --git a/drivers/gpu/drm/kmb/kmb_plane.c b/drivers/gpu/drm/kmb/kmb_plane.c index d5b6195856d1..2888dd5dcc2c 100644 --- a/drivers/gpu/drm/kmb/kmb_plane.c +++ b/drivers/gpu/drm/kmb/kmb_plane.c @@ -427,8 +427,14 @@ static void kmb_plane_atomic_update(struct drm_plane *plane, kmb_set_bitmask_lcd(kmb, LCD_CONTROL, ctrl); - /* FIXME no doc on how to set output format,these values are - * taken from the Myriadx tests + /* Enable pipeline AXI read transactions for the DMA + * after setting graphics layers. This must be done + * in a separate write cycle. + */ + kmb_set_bitmask_lcd(kmb, LCD_CONTROL, LCD_CTRL_PIPELINE_DMA); + + /* FIXME no doc on how to set output format,these values are taken + * from the Myriadx tests */ out_format |= LCD_OUTF_FORMAT_RGB888; @@ -526,6 +532,11 @@ struct kmb_plane *kmb_plane_init(struct drm_device *drm) plane->id = i; } + /* Disable pipeline AXI read transactions for the DMA + * prior to setting graphics layers + */ + kmb_clr_bitmask_lcd(kmb, LCD_CONTROL, LCD_CTRL_PIPELINE_DMA); + return primary; cleanup: drmm_kfree(drm, plane); -- 2.25.1

5 34

[PATCH 00/23] Clean up GuC CI failures, simplify locking, and kernel DOC
by Matthew Brost 09 Sep '21

09 Sep '21

Daniel Vetter pointed out that locking in the GuC submission code was overly complicated, let's clean this up a bit before introducing more features in the GuC submission backend. Also fix some CI failures, port fixes from our internal tree, and add a few more selftests for coverage. Lastly, add some kernel DOC explaining how the GuC submission backend works. v2: Fix logic error in 'Workaround reset G2H is received after schedule done G2H', don't propagate errors to dependent fences in execlists submissiom, resolve checkpatch issues, resend to correct lists v3: Fix issue kicking tasklet, drop guc_active, fix ref counting in xarray, add guc_id sub structure, drop inline fuctions, and various other cleanup suggested by Daniel v4: Address Daniele's feedback, rebase to tip, resend for CI v5 [Daniele taking over while Matt is out]: drop patches 8 and 27 for now (not critical, Matt will update and resend when he's back), address review comments, improve kerneldoc. Also move all code related to busy loop to patch 2 so we have a standalone fix. v6: Drop allocate of error capture in nowait context, drop flushing of work queue (will get respun individually). Signed-off-by: Matthew Brost <matthew.brost(a)intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio(a)intel.com> #v5 Matthew Brost (23): drm/i915/guc: Fix blocked context accounting drm/i915/guc: Fix outstanding G2H accounting drm/i915/guc: Unwind context requests in reverse order drm/i915/guc: Don't drop ce->guc_active.lock when unwinding context drm/i915/guc: Process all G2H message at once in work queue drm/i915/guc: Workaround reset G2H is received after schedule done G2H Revert "drm/i915/gt: Propagate change in error status to children on unhold" drm/i915/guc: Kick tasklet after queuing a request drm/i915/guc: Don't enable scheduling on a banned context, guc_id invalid, not registered drm/i915/guc: Copy whole golden context, set engine state size of subset drm/i915/selftests: Add initial GuC selftest for scrubbing lost G2H drm/i915/guc: Take context ref when cancelling request drm/i915/guc: Don't touch guc_state.sched_state without a lock drm/i915/guc: Reset LRC descriptor if register returns -ENODEV drm/i915/guc: Release submit fence from an irq_work drm/i915/guc: Move guc_blocked fence to struct guc_state drm/i915/guc: Rework and simplify locking drm/i915/guc: Proper xarray usage for contexts_lookup drm/i915/guc: Drop pin count check trick between sched_disable and re-pin drm/i915/guc: Move GuC priority fields in context under guc_active drm/i915/guc: Move fields protected by guc->contexts_lock into sub structure drm/i915/guc: Drop guc_active move everything into guc_state drm/i915/guc: Add GuC kernel doc Documentation/gpu/i915.rst | 2 + drivers/gpu/drm/i915/gt/intel_context.c | 19 +- drivers/gpu/drm/i915/gt/intel_context_types.h | 80 +- .../drm/i915/gt/intel_execlists_submission.c | 4 - drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 6 +- drivers/gpu/drm/i915/gt/uc/intel_guc.h | 75 +- drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 26 +- drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 6 +- .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 904 +++++++++++------- drivers/gpu/drm/i915/gt/uc/selftest_guc.c | 127 +++ drivers/gpu/drm/i915/i915_request.h | 26 +- drivers/gpu/drm/i915/i915_trace.h | 12 +- .../drm/i915/selftests/i915_live_selftests.h | 1 + .../i915/selftests/intel_scheduler_helpers.c | 12 + .../i915/selftests/intel_scheduler_helpers.h | 2 + 15 files changed, 872 insertions(+), 430 deletions(-) create mode 100644 drivers/gpu/drm/i915/gt/uc/selftest_guc.c -- 2.32.0

1 23

[PATCH 0/2] Add support for querying hw info that UMDs need
by John.C.Harrison＠Intel.com 09 Sep '21

09 Sep '21

From: John Harrison <John.C.Harrison(a)Intel.com> Various UMDs require hardware configuration information about the current platform. A bunch of static information is available in a fixed table that can be retrieved from the GuC. Test-with: 20210727002812.43469-2-John.C.Harrison(a)Intel.com UMD: https://github.com/intel/compute-runtime/pull/432/files UMD: https://github.com/intel/media-driver/pull/1239/files CC: Katarzyna Cencelewska <katarzyna.cencelewska(a)intel.com> CC: Tony Ye <tony.ye(a)intel.com> CC: Jason Ekstrand <jason.ekstrand(a)intel.com> Signed-off-by: John Harrison <John.C.Harrison(a)Intel.com> John Harrison (1): drm/i915/guc: Add fetch of hwconfig table Rodrigo Vivi (1): drm/i915/uapi: Add query for hwconfig table drivers/gpu/drm/i915/Makefile | 1 + .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 1 + .../gpu/drm/i915/gt/uc/abi/guc_errors_abi.h | 4 + drivers/gpu/drm/i915/gt/uc/intel_guc.c | 3 +- drivers/gpu/drm/i915/gt/uc/intel_guc.h | 2 + .../gpu/drm/i915/gt/uc/intel_guc_hwconfig.c | 156 ++++++++++++++++++ .../gpu/drm/i915/gt/uc/intel_guc_hwconfig.h | 19 +++ drivers/gpu/drm/i915/gt/uc/intel_uc.c | 6 + drivers/gpu/drm/i915/i915_query.c | 23 +++ include/uapi/drm/i915_drm.h | 1 + 10 files changed, 215 insertions(+), 1 deletion(-) create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.h -- 2.25.1

2 4

[PATCH] drm/i915/request: fix early tracepoints
by Matthew Auld 09 Sep '21

09 Sep '21

Currently we blow up in trace_dma_fence_init, when calling into get_driver_name or get_timeline_name, since both the engine and context might be NULL(or contain some garbage address) in the case of newly allocated slab objects via the request ctor. Note that we also use SLAB_TYPESAFE_BY_RCU here, which allows requests to be immediately freed, but delay freeing the underlying page by an RCU grace period. With this scheme requests can be re-allocated, at the same time as they are also being read by some lockless RCU lookup mechanism. One possible fix, since we don't yet have a fully initialised request when in the ctor, is just setting the context/engine as NULL and adding some extra handling in get_driver_name etc. And since the ctor is only called for new slab objects(i.e allocate new page and call the ctor for each object) it's safe to reset the context/engine prior to calling into dma_fence_init, since we can be certain that no one is doing an RCU lookup which might depend on peeking at the engine/context, like in active_engine(), since the object can't yet be externally visible. In the recycled case(which might also be externally visible) the request refcount always transitions from 0->1 after we set the context/engine etc, which should ensure it's valid to dereference the engine for example, when doing an RCU list-walk, so long as we can also increment the refcount first. If the refcount is already zero, then the request is considered complete/released. If it's non-zero, then the request might be in the process of being re-allocated, or potentially still in flight, however after successfully incrementing the refcount, it's possible to carefully inspect the request state, to determine if the request is still what we were looking for. Note that all externally visible requests returned to the cache must have zero refcount. An alternative fix then is to instead move the dma_fence_init out from the request ctor. Originally this was how it was done, but it was moved in: commit 855e39e65cfc33a73724f1cc644ffc5754864a20 Author: Chris Wilson <chris(a)chris-wilson.co.uk> Date: Mon Feb 3 09:41:48 2020 +0000 drm/i915: Initialise basic fence before acquiring seqno where it looks like intel_timeline_get_seqno() relied on some of the rq->fence state, but that is no longer the case since: commit 12ca695d2c1ed26b2dcbb528b42813bd0f216cfc Author: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Date: Tue Mar 23 16:49:50 2021 +0100 drm/i915: Do not share hwsp across contexts any more, v8. intel_timeline_get_seqno() could also be cleaned up slightly by dropping the request argument. Moving dma_fence_init back out of the ctor, should ensure we have enough of the request initialised in case of trace_dma_fence_init. Functionally this should be the same, and is effectively what we were already open coding before, except now we also assign the fence->lock and fence->ops, but since these are invariant for recycled requests(which might be externally visible), and will therefore already hold the same value, it shouldn't matter. We still leave the spin_lock_init() in the ctor, since we can't re-init the rq->lock in case it is already held. Fixes: 855e39e65cfc ("drm/i915: Initialise basic fence before acquiring seqno") Signed-off-by: Matthew Auld <matthew.auld(a)intel.com> Cc: Michael Mason <michael.w.mason(a)intel.com> Cc: Daniel Vetter <daniel(a)ffwll.ch> --- drivers/gpu/drm/i915/i915_request.c | 11 ++--------- 1 file changed, 2 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c index ce446716d092..79da5eca60af 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -829,8 +829,6 @@ static void __i915_request_ctor(void *arg) i915_sw_fence_init(&rq->submit, submit_notify); i915_sw_fence_init(&rq->semaphore, semaphore_notify); - dma_fence_init(&rq->fence, &i915_fence_ops, &rq->lock, 0, 0); - rq->capture_list = NULL; init_llist_head(&rq->execute_cb); @@ -905,17 +903,12 @@ __i915_request_create(struct intel_context *ce, gfp_t gfp) rq->ring = ce->ring; rq->execution_mask = ce->engine->mask; - kref_init(&rq->fence.refcount); - rq->fence.flags = 0; - rq->fence.error = 0; - INIT_LIST_HEAD(&rq->fence.cb_list); - ret = intel_timeline_get_seqno(tl, rq, &seqno); if (ret) goto err_free; - rq->fence.context = tl->fence_context; - rq->fence.seqno = seqno; + dma_fence_init(&rq->fence, &i915_fence_ops, &rq->lock, + tl->fence_context, seqno); RCU_INIT_POINTER(rq->timeline, tl); rq->hwsp_seqno = tl->hwsp_seqno; -- 2.26.3

2 2

[PATCH v2 0/7] drm/gud: Add some more pixel formats
by Noralf Trønnes 09 Sep '21

09 Sep '21

Hi, This adds some more pixel formats and gives the user the ability to choose the xrgb8888 emulation format. Pixel formats: R8: For greyscale e-ink displays RGB332: For e-ink displays and some niche displays RGB888: Same color depth as XRGB8888 but the smaller buffer gives better fps Changes since first version: - RGB332: Support Big Endian in the emulation (Daniel) Noralf. Noralf Trønnes (7): drm/fourcc: Add R8 to drm_format_info drm/format-helper: Add drm_fb_xrgb8888_to_rgb332() drm/format-helper: Add drm_fb_xrgb8888_to_rgb888() drm/gud: Add GUD_PIXEL_FORMAT_R8 drm/gud: Add GUD_PIXEL_FORMAT_RGB332 drm/gud: Add GUD_PIXEL_FORMAT_RGB888 drm/gud: Add module parameter to control emulation: xrgb8888 drivers/gpu/drm/drm_format_helper.c | 88 +++++++++++++++++++++++++++++ drivers/gpu/drm/drm_fourcc.c | 1 + drivers/gpu/drm/gud/gud_drv.c | 19 ++++++- drivers/gpu/drm/gud/gud_internal.h | 12 ++++ drivers/gpu/drm/gud/gud_pipe.c | 6 ++ include/drm/drm_format_helper.h | 4 ++ include/drm/gud.h | 6 +- 7 files changed, 131 insertions(+), 5 deletions(-) -- 2.32.0

2 9

[PATCH AUTOSEL 5.14 001/252] drm/bridge: ti-sn65dsi86: Don't read EDID blob over DDC
by Sasha Levin 09 Sep '21

09 Sep '21

From: Douglas Anderson <dianders(a)chromium.org> [ Upstream commit a70e558c151043ce46a5e5999f4310e0b3551f57 ] This is really just a revert of commit 58074b08c04a ("drm/bridge: ti-sn65dsi86: Read EDID blob over DDC"), resolving conflicts. The old code failed to read the EDID properly in a very important case: before the bridge's pre_enable() was called. The way things need to work: 1. Read the EDID. 2. Based on the EDID, decide on video settings and pixel clock. 3. Enable the bridge w/ the desired settings. The way things were working: 1. Try to read the EDID but fail; fall back to hardcoded values. 2. Based on hardcoded values, decide on video settings and pixel clock. 3. Enable the bridge w/ the desired settings. 4. Try again to read the EDID, it works now! 5. Realize that the hardcoded settings weren't quite right. 6. Disable / reenable the bridge w/ the right settings. The reasons for the failures were twofold: a) Since we never ran the bridge chip's pre-enable then we never set the bit to ignore HPD. This meant the bridge chip didn't even _try_ to go out on the bus and communicate with the panel. b) Even if we fixed things to ignore HPD, the EDID still wouldn't read if the panel wasn't on. Instead of reverting the code, we could fix it to set the HPD bit and also power on the panel. However, it also works nicely to just let the panel code read the EDID. Now that we've split the driver up we can expose the DDC AUX channel bus to the panel node. The panel can take charge of reading the EDID. NOTE: in order for things to work, anyone that needs to read the EDID will need to instantiate their panel using the new DP AUX bus (AKA by listing their panel under the "aux-bus" node of the bridge chip in the device tree). In the future if we want to use the bridge chip to provide a full external DP port (which won't have a panel) then we will have to conditinally add EDID reading back in. Suggested-by: Andrzej Hajda <a.hajda(a)samsung.com> Signed-off-by: Douglas Anderson <dianders(a)chromium.org> Reviewed-by: Bjorn Andersson <bjorn.andersson(a)linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210611101711.v10.9.I9330684… Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/bridge/ti-sn65dsi86.c | 22 ---------------------- 1 file changed, 22 deletions(-) diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c b/drivers/gpu/drm/bridge/ti-sn65dsi86.c index 45a2969afb2b..aef850296756 100644 --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c @@ -124,7 +124,6 @@ * @connector: Our connector. * @host_node: Remote DSI node. * @dsi: Our MIPI DSI source. - * @edid: Detected EDID of eDP panel. * @refclk: Our reference clock. * @panel: Our panel. * @enable_gpio: The GPIO we toggle to enable the bridge. @@ -154,7 +153,6 @@ struct ti_sn65dsi86 { struct drm_dp_aux aux; struct drm_bridge bridge; struct drm_connector connector; - struct edid *edid; struct device_node *host_node; struct mipi_dsi_device *dsi; struct clk *refclk; @@ -403,24 +401,6 @@ connector_to_ti_sn65dsi86(struct drm_connector *connector) static int ti_sn_bridge_connector_get_modes(struct drm_connector *connector) { struct ti_sn65dsi86 *pdata = connector_to_ti_sn65dsi86(connector); - struct edid *edid = pdata->edid; - int num, ret; - - if (!edid) { - pm_runtime_get_sync(pdata->dev); - edid = pdata->edid = drm_get_edid(connector, &pdata->aux.ddc); - pm_runtime_put_autosuspend(pdata->dev); - } - - if (edid && drm_edid_is_valid(edid)) { - ret = drm_connector_update_edid_property(connector, edid); - if (!ret) { - num = drm_add_edid_modes(connector, edid); - if (num) - return num; - } - } - return drm_panel_get_modes(pdata->panel, connector); } @@ -1358,8 +1338,6 @@ static void ti_sn_bridge_remove(struct auxiliary_device *adev) mipi_dsi_device_unregister(pdata->dsi); } - kfree(pdata->edid); - drm_bridge_remove(&pdata->bridge); of_node_put(pdata->host_node); -- 2.30.2

2 10

[PATCH v2] drm/stm: ltdc: add layer alpha support
by Raphael Gallais-Pou 09 Sep '21

09 Sep '21

Android Hardware Composer supports alpha values applied to layers. Enabling non-opaque layers for the STM CRTC could help offload GPU resources for screen composition. Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou(a)foss.st.com> Acked-by: Yannick Fertre <yannick.fertre(a)foss.st.com> Reviewed-by: Yannick Fertre <yannick.fertre(a)foss.st.com> --- drivers/gpu/drm/stm/ltdc.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c index 195de30eb90c..e0fef8bacfa8 100644 --- a/drivers/gpu/drm/stm/ltdc.c +++ b/drivers/gpu/drm/stm/ltdc.c @@ -845,7 +845,7 @@ static void ltdc_plane_atomic_update(struct drm_plane *plane, LXCFBLR_CFBLL | LXCFBLR_CFBP, val); /* Specifies the constant alpha value */ - val = CONSTA_MAX; + val = newstate->alpha >> 8; reg_update_bits(ldev->regs, LTDC_L1CACR + lofs, LXCACR_CONSTA, val); /* Specifies the blending factors */ @@ -997,6 +997,8 @@ static struct drm_plane *ltdc_plane_create(struct drm_device *ddev, drm_plane_helper_add(plane, &ltdc_plane_helper_funcs); + drm_plane_create_alpha_property(plane); + DRM_DEBUG_DRIVER("plane:%d created\n", plane->base.id); return plane; -- 2.17.1

2 1

[PATCH v2] drm/stm: ltdc: attach immutable zpos property to planes
by Raphael Gallais-Pou 09 Sep '21

09 Sep '21

Defines plane ordering by hard-coding an immutable Z position from the first plane, used as primary layer, to the next ones as overlay in order of instantiation. This zpos is only an information as it is not possible to modify it, blending operations are still applied from the top to the bottom layer. This patch helps to remove a warning message from the Android Hardware Composer. Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou(a)foss.st.com> Acked-by: Yannick Fertre <yannick.fertre(a)foss.st.com> Reviewed-by: Yannick Fertre <yannick.fertre(a)foss.st.com> --- drivers/gpu/drm/stm/ltdc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c index 195de30eb90c..bd603ef5e935 100644 --- a/drivers/gpu/drm/stm/ltdc.c +++ b/drivers/gpu/drm/stm/ltdc.c @@ -1024,6 +1024,8 @@ static int ltdc_crtc_init(struct drm_device *ddev, struct drm_crtc *crtc) return -EINVAL; } + drm_plane_create_zpos_immutable_property(primary, 0); + ret = drm_crtc_init_with_planes(ddev, crtc, primary, NULL, &ltdc_crtc_funcs, NULL); if (ret) { @@ -1046,6 +1048,7 @@ static int ltdc_crtc_init(struct drm_device *ddev, struct drm_crtc *crtc) DRM_ERROR("Can not create overlay plane %d\n", i); goto cleanup; } + drm_plane_create_zpos_immutable_property(overlay, i); } return 0; -- 2.17.1

2 1

[PATCH AUTOSEL 4.4 22/35] gpu: drm: amd: amdgpu: amdgpu_i2c: fix possible uninitialized-variable access in amdgpu_i2c_router_select_ddc_port()
by Sasha Levin 09 Sep '21

09 Sep '21

From: Tuo Li <islituo(a)gmail.com> [ Upstream commit a211260c34cfadc6068fece8c9e99e0fe1e2a2b6 ] The variable val is declared without initialization, and its address is passed to amdgpu_i2c_get_byte(). In this function, the value of val is accessed in: DRM_DEBUG("i2c 0x%02x 0x%02x read failed\n", addr, *val); Also, when amdgpu_i2c_get_byte() returns, val may remain uninitialized, but it is accessed in: val &= ~amdgpu_connector->router.ddc_mux_control_pin; To fix this possible uninitialized-variable access, initialize val to 0 in amdgpu_i2c_router_select_ddc_port(). Reported-by: TOTE Robot <oslab(a)tsinghua.edu.cn> Signed-off-by: Tuo Li <islituo(a)gmail.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c index 31a676376d73..3490d300bed2 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c @@ -340,7 +340,7 @@ static void amdgpu_i2c_put_byte(struct amdgpu_i2c_chan *i2c_bus, void amdgpu_i2c_router_select_ddc_port(struct amdgpu_connector *amdgpu_connector) { - u8 val; + u8 val = 0; if (!amdgpu_connector->router.ddc_valid) return; -- 2.30.2

1 0

← Newer
1
...
62
63
64
65
66
67
68
...
82
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel September 2021