dri-devel May 2022

dri-devel@lists.freedesktop.org

344 participants
736 discussions

[RFC PATCH] drm/edid: drm_add_modes_noedid() should set lowest resolution as preferred
by Douglas Anderson 11 May '22

11 May '22

If we're unable to read the EDID for a display because it's corrupt / bogus / invalid then we'll add a set of standard modes for the display. When userspace looks at these modes it doesn't really have a good concept for which mode to pick and it'll likely pick the highest resolution one by default. That's probably not ideal because the modes were purely guesses on the part of the Linux kernel. Let's instead set 640x480 as the "preferred" mode when we have no EDID. Signed-off-by: Douglas Anderson <dianders(a)chromium.org> --- drivers/gpu/drm/drm_edid.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 7a8482b75071..64ccfff4167e 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -5839,6 +5839,15 @@ int drm_add_modes_noedid(struct drm_connector *connector, continue; mode = drm_mode_duplicate(dev, ptr); if (mode) { + /* + * The drm_dmt_modes array is sorted so that lower + * resolutions come first. We'll set the lowest + * resolution mode as preferred. We have no EDID so + * we should prefer the lowest resolution mode as + * the safest one. + */ + if (num_modes == 0) + mode->type |= DRM_MODE_TYPE_PREFERRED; drm_mode_probed_add(connector, mode); num_modes++; } -- 2.36.0.rc2.479.g8af0fa9b8e-goog

5 11

[PATCH v2 0/3] Clear TLB caches in all tiles when object is removed
by Andi Shyti 10 May '22

10 May '22

Hi, The real fix is in patch 2. The rest is a helper that adds the with_intel_gt_pm_if_awake() (from Chris) and one more check on the status of the engine before accessing it for clearing the TLB. Andi Andi Shyti (2): drm/i915/gem: Flush TLBs for all the tiles when clearing an obj drm/i915/gt: Skip TLB invalidation if the engine is not awake Chris Wilson (1): drm/i915/gt: Ignore TLB invalidations on idle engines drivers/gpu/drm/i915/gem/i915_gem_pages.c | 12 +++++++++--- drivers/gpu/drm/i915/gt/intel_gt.c | 3 +++ drivers/gpu/drm/i915/gt/intel_gt_pm.h | 4 ++++ 3 files changed, 16 insertions(+), 3 deletions(-) -- 2.36.0

1 3

[PATCH v3 0/3] Fixes for selective fetch area calculation
by Jouni Högander 10 May '22

10 May '22

Currently selective fetch area calculation ends up as bogus area in at least following cases: 1. Updated plane is partially or fully outside pipe area 2. Big fb with only part of memory area used for plane These end up as y1 = 0, y2 = 4 or y2 being outside pipe area. This patch set addresses these by ensuring update area is within pipe area or by falling back to full update. Patch set also adds drm_dbg_once* macros to print out debug message only once. drm_dbg_once_kms is used to printout debug message when selective fetch area calculation fails. v3: - Add drm_dbg_once* and use it when sel fetch area calculation fails - Move drm_rect_intersect to clip_area_update v2: - Update commit message of first patch - Set damaged_area x1 and x2 during initialization Cc: José Roberto de Souza <jose.souza(a)intel.com> Cc: Mika Kahola <mika.kahola(a)intel.com> Cc: Mark Pearson <markpearson(a)lenovo.com> Jouni Högander (3): drm/print: Add drm_debug_once* macros drm/i915/psr: Use full update In case of area calculation fails drm/i915: Ensure damage clip area is within pipe area drivers/gpu/drm/i915/display/intel_psr.c | 36 +++++++++++++++++++----- include/drm/drm_print.h | 29 +++++++++++++++++++ 2 files changed, 58 insertions(+), 7 deletions(-) -- 2.25.1

2 6

[PATCH] drm/bridge: simplify the return expression of ps8640_bridge_host_attach
by cgel.zte＠gmail.com 10 May '22

10 May '22

From: Minghao Chi <chi.minghao(a)zte.com.cn> Simplify the return expression. Reported-by: Zeal Robot <zealci(a)zte.com.cn> Signed-off-by: Minghao Chi <chi.minghao(a)zte.com.cn> --- drivers/gpu/drm/bridge/parade-ps8640.c | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c b/drivers/gpu/drm/bridge/parade-ps8640.c index edb939b14c04..e2467e58b5b7 100644 --- a/drivers/gpu/drm/bridge/parade-ps8640.c +++ b/drivers/gpu/drm/bridge/parade-ps8640.c @@ -542,7 +542,6 @@ static int ps8640_bridge_host_attach(struct device *dev, struct ps8640 *ps_bridg struct device_node *in_ep, *dsi_node; struct mipi_dsi_device *dsi; struct mipi_dsi_host *host; - int ret; const struct mipi_dsi_device_info info = { .type = "ps8640", .channel = 0, .node = NULL, @@ -577,11 +576,7 @@ static int ps8640_bridge_host_attach(struct device *dev, struct ps8640 *ps_bridg dsi->format = MIPI_DSI_FMT_RGB888; dsi->lanes = NUM_MIPI_LANES; - ret = devm_mipi_dsi_attach(dev, dsi); - if (ret) - return ret; - - return 0; + return devm_mipi_dsi_attach(dev, dsi); } static int ps8640_probe(struct i2c_client *client) -- 2.25.1

2 2

[PATCH] drm/msm: Fix fb plane offset calculation
by Rob Clark 10 May '22

10 May '22

From: Rob Clark <robdclark(a)chromium.org> The offset got dropped by accident. Fixes: d413e6f97134 ("drm/msm: Drop msm_gem_iova()") Signed-off-by: Rob Clark <robdclark(a)chromium.org> --- drivers/gpu/drm/msm/msm_fb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/msm_fb.c b/drivers/gpu/drm/msm/msm_fb.c index 362775ae50af..4269da268a4a 100644 --- a/drivers/gpu/drm/msm/msm_fb.c +++ b/drivers/gpu/drm/msm/msm_fb.c @@ -118,7 +118,7 @@ uint32_t msm_framebuffer_iova(struct drm_framebuffer *fb, struct msm_gem_address_space *aspace, int plane) { struct msm_framebuffer *msm_fb = to_msm_framebuffer(fb); - return msm_fb->iova[plane]; + return msm_fb->iova[plane] + fb->offsets[plane]; } struct drm_gem_object *msm_framebuffer_bo(struct drm_framebuffer *fb, int plane) -- 2.35.1

4 4

[PATCH] drm/i2c: tda9950: Lower severity of log message about missing interrupts
by Mark Brown 10 May '22

10 May '22

The tda9950 driver prints an error message if it is instantiated without an interrupt being available since the device is non-functional in that case. Unfortunately due to packaging of tda9950 with tda998x series devices the tda998x driver unconditionally instantiates a tda9950 so systems with a tda998x configured without an interrupt will trigger this error message during boot if tda9950 support is available. Reduce the severity to debug level so this is less likely to be presented to end users, the information is still there for system integrators who run into problems. We could add a check for an interrupt to the tda998x driver instead but this feels better from an encapsulation point of view, there's still a log message to help anyone doing system integration. Signed-off-by: Mark Brown <broonie(a)kernel.org> --- drivers/gpu/drm/i2c/tda9950.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i2c/tda9950.c b/drivers/gpu/drm/i2c/tda9950.c index 5b03fdd1eaa4..781d5665cd04 100644 --- a/drivers/gpu/drm/i2c/tda9950.c +++ b/drivers/gpu/drm/i2c/tda9950.c @@ -397,7 +397,7 @@ static int tda9950_probe(struct i2c_client *client, /* We must have an interrupt to be functional. */ if (client->irq <= 0) { - dev_err(&client->dev, "driver requires an interrupt\n"); + dev_dbg(&client->dev, "driver requires an interrupt\n"); return -ENXIO; } -- 2.30.2

1 0

Re: [Bug 215958] New: thunderbolt3 egpu cannot disconnect cleanly
by Bjorn Helgaas 10 May '22

10 May '22

On Sun, May 8, 2022 at 3:29 PM <bugzilla-daemon(a)kernel.org> wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=215958 > > Bug ID: 215958 > Summary: thunderbolt3 egpu cannot disconnect cleanly > Product: Drivers > Version: 2.5 > Kernel Version: 5.17.0-1003-oem #3-Ubuntu SMP PREEMPT > Hardware: All > OS: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: PCI > Assignee: drivers_pci(a)kernel-bugs.osdl.org > Reporter: r087r70(a)yahoo.it > Regression: No I assume this is not a regression, right? If it is a regression, what previous kernel worked correctly? > I have an external egpu (Radeon 6600 RX) connected through thunderbolt3 to my > Thinkpad X1 carbon 6th Gen.. When I disconnect the thunderbolt3 cable I get the > following error in dmesg: > > [21874.194994] amdgpu 0000:0c:00.0: amdgpu: SMU: response:0xFFFFFFFF for > index:18 param:0x00000005 message:TransferTableSmu2Dram? > [21874.195006] amdgpu 0000:0c:00.0: amdgpu: Failed to export SMU metrics table! > [21874.195123] amdgpu 0000:0c:00.0: amdgpu: SMU: response:0xFFFFFFFF for > index:18 param:0x00000005 message:TransferTableSmu2Dram? > [21874.195129] amdgpu 0000:0c:00.0: amdgpu: Failed to export SMU metrics table! > [21874.195271] amdgpu 0000:0c:00.0: amdgpu: SMU: response:0xFFFFFFFF for > index:18 param:0x00000005 message:TransferTableSmu2Dram? > [21874.195276] amdgpu 0000:0c:00.0: amdgpu: Failed to export SMU metrics table! > [21874.195406] amdgpu 0000:0c:00.0: amdgpu: SMU: response:0xFFFFFFFF for > index:18 param:0x00000005 message:TransferTableSmu2Dram? > [21874.195411] amdgpu 0000:0c:00.0: amdgpu: Failed to export SMU metrics table! > [21874.195544] amdgpu 0000:0c:00.0: amdgpu: SMU: response:0xFFFFFFFF for > index:51 param:0x00000000 message:GetPptLimit? > [21874.195550] amdgpu 0000:0c:00.0: amdgpu: [smu_v11_0_get_current_power_limit] > get PPT limit failed! > [21874.195582] amdgpu 0000:0c:00.0: amdgpu: SMU: response:0xFFFFFFFF for > index:18 param:0x00000005 message:TransferTableSmu2Dram? > [21874.195587] amdgpu 0000:0c:00.0: amdgpu: Failed to export SMU metrics table! > [21874.227454] amdgpu 0000:0c:00.0: amdgpu: SMU: response:0xFFFFFFFF for > index:18 param:0x00000005 message:TransferTableSmu2Dram? > [21874.227463] amdgpu 0000:0c:00.0: amdgpu: Failed to export SMU metrics table! > [21874.227532] amdgpu 0000:0c:00.0: amdgpu: SMU: response:0xFFFFFFFF for > index:18 param:0x00000005 message:TransferTableSmu2Dram? > [21874.227536] amdgpu 0000:0c:00.0: amdgpu: Failed to export SMU metrics table! > [21874.227618] amdgpu 0000:0c:00.0: amdgpu: SMU: response:0xFFFFFFFF for > index:18 param:0x00000005 message:TransferTableSmu2Dram? > [21874.227621] amdgpu 0000:0c:00.0: amdgpu: Failed to export SMU metrics table! > [21874.227700] amdgpu 0000:0c:00.0: amdgpu: SMU: response:0xFFFFFFFF for > index:18 param:0x00000005 message:TransferTableSmu2Dram? > [21874.227703] amdgpu 0000:0c:00.0: amdgpu: Failed to export SMU metrics table! > [21874.227784] amdgpu 0000:0c:00.0: amdgpu: [smu_v11_0_get_current_power_limit] > get PPT limit failed! > [21874.227804] amdgpu 0000:0c:00.0: amdgpu: Failed to export SMU metrics table! > [21874.514661] snd_hda_codec_hdmi hdaudioC1D0: Unable to sync register > 0x2f0d00. -5 > [21874.568360] amdgpu 0000:0c:00.0: amdgpu: Failed to switch to AC mode! > [21874.599292] amdgpu 0000:0c:00.0: amdgpu: Failed to switch to AC mode! > [21874.718562] amdgpu 0000:0c:00.0: amdgpu: amdgpu: finishing device. > [21878.722376] amdgpu: cp queue pipe 4 queue 0 preemption failed > [21878.722422] amdgpu 0000:0c:00.0: amdgpu: Failed to disable gfxoff! > [21879.134918] amdgpu 0000:0c:00.0: [drm:amdgpu_ring_test_helper [amdgpu]] > *ERROR* ring kiq_2.1.0 test failed (-110) > [21879.135144] [drm:gfx_v10_0_hw_fini [amdgpu]] *ERROR* KGQ disable failed > [21879.338158] amdgpu 0000:0c:00.0: [drm:amdgpu_ring_test_helper [amdgpu]] > *ERROR* ring kiq_2.1.0 test failed (-110) > [21879.338402] [drm:gfx_v10_0_hw_fini [amdgpu]] *ERROR* KCQ disable failed > [21879.543318] [drm:gfx_v10_0_cp_gfx_enable.isra.0 [amdgpu]] *ERROR* failed to > halt cp gfx > [21879.544216] __smu_cmn_reg_print_error: 5 callbacks suppressed > [21879.544220] amdgpu 0000:0c:00.0: amdgpu: SMU: response:0xFFFFFFFF for > index:7 param:0x00000000 message:DisableAllSmuFeatures? > [21879.544226] amdgpu 0000:0c:00.0: amdgpu: Failed to disable smu features. > [21879.544230] amdgpu 0000:0c:00.0: amdgpu: Fail to disable dpm features! > [21879.544238] [drm] free PSP TMR buffer The above looks like what amdgpu would see when the GPU is no longer accessible (writes are dropped and reads return 0xffffffff). It's possible amdgpu could notice this and shut down more gracefully, but I don't think it's the main problem here and it probably wouldn't force you to reboot. > [21880.455935] i915 0000:00:02.0: vgaarb: changed VGA decodes: > olddecodes=none,decodes=io+mem:owns=io+mem > [21880.456218] pci 0000:0c:00.0: Removing from iommu group 14 > [21880.456715] pci 0000:0c:00.1: Removing from iommu group 14 > [21880.456798] pci_bus 0000:0c: busn_res: [bus 0c] is released > [21880.456950] pci 0000:0b:00.0: Removing from iommu group 14 > [21880.456985] pci_bus 0000:0b: busn_res: [bus 0b-0c] is released > [21880.457106] pci 0000:0a:00.0: Removing from iommu group 14 > [21880.457156] pci_bus 0000:0a: busn_res: [bus 0a-0c] is released > [21880.457279] pci 0000:09:01.0: Removing from iommu group 14 > [21880.457311] pci_bus 0000:09: busn_res: [bus 09-3a] is released > [21880.457543] pci 0000:08:00.0: Removing from iommu group 14 This looks like removing 0c:00.0 (the GPU) and two switches leading to it (probably part of the Thunderbolt topology), so to be expected. > [21880.457847] pci_bus 0000:06: Allocating resources > [21880.457888] pcieport 0000:06:02.0: bridge window [io 0x1000-0x0fff] to [bus > 3b] add_size 1000 > [21880.457897] pcieport 0000:06:04.0: bridge window [io 0x1000-0x0fff] to [bus > 3c-6f] add_size 1000 > [21880.457913] pcieport 0000:06:02.0: BAR 13: no space for [io size 0x1000] > [21880.457919] pcieport 0000:06:02.0: BAR 13: failed to assign [io size > 0x1000] > [21880.457924] pcieport 0000:06:04.0: BAR 13: no space for [io size 0x1000] > [21880.457928] pcieport 0000:06:04.0: BAR 13: failed to assign [io size > 0x1000] > [21880.457934] pcieport 0000:06:04.0: BAR 13: no space for [io size 0x1000] > [21880.457938] pcieport 0000:06:04.0: BAR 13: failed to assign [io size > 0x1000] > [21880.457943] pcieport 0000:06:02.0: BAR 13: no space for [io size 0x1000] > [21880.457947] pcieport 0000:06:02.0: BAR 13: failed to assign [io size > 0x1000] I'm not sure why we're allocating resources as part of the removal. The hierarchies under 06:02.0 (to [bus 3b]) and 06:04.0 (to [bus 3c-6f]) seem to be siblings of the hierarchy you just removed (my guess is that was 06:01.0 to [bus 08-3a]). But again, shouldn't require a reboot. > upon reconnection of the cable I get: > > [22192.753261] input: HDA ATI HDMI HDMI/DP,pcm=3 as > /devices/pci0000:00/0000:00:1d.0/0000:05:00.0/0000:06:01.0/0000:08:00.0/0000:09:01.0/0000:0a:00.0/0000:0b:00.0/0000:0c:00.1/sound/card1/input98 > [22192.753738] input: HDA ATI HDMI HDMI/DP,pcm=7 as > /devices/pci0000:00/0000:00:1d.0/0000:05:00.0/0000:06:01.0/0000:08:00.0/0000:09:01.0/0000:0a:00.0/0000:0b:00.0/0000:0c:00.1/sound/card1/input99 > [22192.753952] input: HDA ATI HDMI HDMI/DP,pcm=8 as > /devices/pci0000:00/0000:00:1d.0/0000:05:00.0/0000:06:01.0/0000:08:00.0/0000:09:01.0/0000:0a:00.0/0000:0b:00.0/0000:0c:00.1/sound/card1/input100 > [22192.755234] input: HDA ATI HDMI HDMI/DP,pcm=9 as > /devices/pci0000:00/0000:00:1d.0/0000:05:00.0/0000:06:01.0/0000:08:00.0/0000:09:01.0/0000:0a:00.0/0000:0b:00.0/0000:0c:00.1/sound/card1/input101 > [22192.763885] input: HDA ATI HDMI HDMI/DP,pcm=10 as > /devices/pci0000:00/0000:00:1d.0/0000:05:00.0/0000:06:01.0/0000:08:00.0/0000:09:01.0/0000:0a:00.0/0000:0b:00.0/0000:0c:00.1/sound/card1/input102 > [22192.975773] thunderbolt 0-1: new device found, vendor=0x127 device=0x1 > [22192.975786] thunderbolt 0-1: Razer Core X > > but the egpu no longer appears in `xrandr --listproviders`. Full reboot is > needed. Can you please build with CONFIG_DYNAMIC_DEBUG=y, boot with 'dyndbg="file pciehp* +p"', and attach the complete dmesg log to the bugzilla? Also please attach the complete "sudo lspci -vv" output (before the unplug and after the replug)?

4 4

[PATCH] drm/amdgpu: clean up some inconsistent indenting
by Jiapeng Chong 10 May '22

10 May '22

Eliminate the follow smatch warning: drivers/gpu/drm/amd/amdgpu/nbio_v7_7.c:35 nbio_v7_7_get_rev_id() warn: inconsistent indenting. drivers/gpu/drm/amd/amdgpu/nbio_v7_7.c:214 nbio_v7_7_init_registers() warn: inconsistent indenting. Reported-by: Abaci Robot <abaci(a)linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong(a)linux.alibaba.com> --- drivers/gpu/drm/amd/amdgpu/nbio_v7_7.c | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/nbio_v7_7.c b/drivers/gpu/drm/amd/amdgpu/nbio_v7_7.c index e32c874b42b5..cdc0c9779848 100644 --- a/drivers/gpu/drm/amd/amdgpu/nbio_v7_7.c +++ b/drivers/gpu/drm/amd/amdgpu/nbio_v7_7.c @@ -32,8 +32,7 @@ static u32 nbio_v7_7_get_rev_id(struct amdgpu_device *adev) { u32 tmp; - tmp = RREG32_SOC15(NBIO, 0, regRCC_STRAP0_RCC_DEV0_EPF0_STRAP0); - + tmp = RREG32_SOC15(NBIO, 0, regRCC_STRAP0_RCC_DEV0_EPF0_STRAP0); tmp &= RCC_STRAP0_RCC_DEV0_EPF0_STRAP0__STRAP_ATI_REV_ID_DEV0_F0_MASK; tmp >>= RCC_STRAP0_RCC_DEV0_EPF0_STRAP0__STRAP_ATI_REV_ID_DEV0_F0__SHIFT; @@ -211,14 +210,14 @@ static void nbio_v7_7_init_registers(struct amdgpu_device *adev) { uint32_t def, data; - def = data = RREG32_SOC15(NBIO, 0, regBIF0_PCIE_MST_CTRL_3); - data = REG_SET_FIELD(data, BIF0_PCIE_MST_CTRL_3, - CI_SWUS_MAX_READ_REQUEST_SIZE_MODE, 1); - data = REG_SET_FIELD(data, BIF0_PCIE_MST_CTRL_3, - CI_SWUS_MAX_READ_REQUEST_SIZE_PRIV, 1); + def = data = RREG32_SOC15(NBIO, 0, regBIF0_PCIE_MST_CTRL_3); + data = REG_SET_FIELD(data, BIF0_PCIE_MST_CTRL_3, + CI_SWUS_MAX_READ_REQUEST_SIZE_MODE, 1); + data = REG_SET_FIELD(data, BIF0_PCIE_MST_CTRL_3, + CI_SWUS_MAX_READ_REQUEST_SIZE_PRIV, 1); - if (def != data) - WREG32_SOC15(NBIO, 0, regBIF0_PCIE_MST_CTRL_3, data); + if (def != data) + WREG32_SOC15(NBIO, 0, regBIF0_PCIE_MST_CTRL_3, data); } -- 2.20.1.7.g153144c

2 1

[PATCH] drm/amdgpu: Remove duplicated argument in vcn_v4_0
by Wan Jiabing 10 May '22

10 May '22

Fix following coccicheck warning: ./drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c:724:4-36: duplicated argument to & or | Remove duplicated UVD_SUVD_CGC_GATE__SRE_H264_MASK. Signed-off-by: Wan Jiabing <wanjiabing(a)vivo.com> --- drivers/Gap/drm/amd/amdgpu/vcn_v4_0.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c index c37dbac9d96b..9119e966ffff 100644 --- a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c +++ b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c @@ -722,7 +722,6 @@ static void vcn_v4_0_disable_clock_gating(struct amdgpu_device *adev, int inst) | UVD_SUVD_CGC_GATE__SCM_MASK | UVD_SUVD_CGC_GATE__SDB_MASK | UVD_SUVD_CGC_GATE__SRE_H264_MASK - | UVD_SUVD_CGC_GATE__SRE_H264_MASK | UVD_SUVD_CGC_GATE__SRE_HEVC_MASK | UVD_SUVD_CGC_GATE__SIT_H264_MASK | UVD_SUVD_CGC_GATE__SIT_HEVC_MASK -- 2.36.0

2 1

[PATCH] drm/stm: ltdc: fix unchecked dereferenced pointer
by Raphael Gallais-Pou 10 May '22

10 May '22

Pointer of struct *drm_crtc was dereferenced before checking it was non NULL. This could potentially create a kernel panic. Fixes: 79b44684a14e ("drm/stm: ltdc: add support for CRC hashing feature") Reported-by: kernel test robot <lkp(a)intel.com> Reported-by: Dan Carpenter <dan.carpenter(a)oracle.com> Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou(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 6bd45df8f5a7..9c0fadd58d2a 100644 --- a/drivers/gpu/drm/stm/ltdc.c +++ b/drivers/gpu/drm/stm/ltdc.c @@ -1120,7 +1120,7 @@ static void ltdc_crtc_disable_vblank(struct drm_crtc *crtc) static int ltdc_crtc_set_crc_source(struct drm_crtc *crtc, const char *source) { - struct ltdc_device *ldev = crtc_to_ltdc(crtc); + struct ltdc_device *ldev; int ret; DRM_DEBUG_DRIVER("\n"); @@ -1128,6 +1128,8 @@ static int ltdc_crtc_set_crc_source(struct drm_crtc *crtc, const char *source) if (!crtc) return -ENODEV; + ldev = crtc_to_ltdc(crtc); + if (source && strcmp(source, "auto") == 0) { ldev->crc_active = true; ret = regmap_set_bits(ldev->regmap, LTDC_GCR, GCR_CRCEN); -- 2.25.1

1 0

← Newer
1
...
51
52
53
54
55
56
57
...
74
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel May 2022