dri-devel August 2019

dri-devel@lists.freedesktop.org

318 participants
2338 discussions

[PATCH][drm-next] drm/amd/display: fix a potential null pointer dereference
by Colin King 22 Aug '19

22 Aug '19

From: Colin Ian King <colin.king(a)canonical.com> Currently the pointer init_data is dereferenced on the assignment of fw_info before init_data is sanity checked to see if it is null. Fix te potential null pointer dereference on init_data by only performing dereference after it is null checked. Addresses-Coverity: ("Dereference before null check") Fixes: 9adc8050bf3c ("drm/amd/display: make firmware info only load once during dc_bios create") Signed-off-by: Colin Ian King <colin.king(a)canonical.com> --- drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c b/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c index bee81bf288be..926954c804a6 100644 --- a/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c +++ b/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c @@ -1235,7 +1235,7 @@ static bool calc_pll_max_vco_construct( struct calc_pll_clock_source_init_data *init_data) { uint32_t i; - struct dc_firmware_info *fw_info = &init_data->bp->fw_info; + struct dc_firmware_info *fw_info; if (calc_pll_cs == NULL || init_data == NULL || init_data->bp == NULL) @@ -1244,6 +1244,7 @@ static bool calc_pll_max_vco_construct( if (init_data->bp->fw_info_valid) return false; + fw_info = &init_data->bp->fw_info; calc_pll_cs->ctx = init_data->ctx; calc_pll_cs->ref_freq_khz = fw_info->pll_info.crystal_frequency; calc_pll_cs->min_vco_khz = -- 2.20.1

4 3

[PATCH] drm/amdgpu/powerplay: remove redundant assignment to variable baco_state
by Colin King 22 Aug '19

22 Aug '19

From: Colin Ian King <colin.king(a)canonical.com> Variable baco_state is initialized to a value that is never read and it is re-assigned later. The initialization is redundant and can be removed. Addresses-Coverity: ("Unused Value") Signed-off-by: Colin Ian King <colin.king(a)canonical.com> --- drivers/gpu/drm/amd/powerplay/smu_v11_0.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/powerplay/smu_v11_0.c b/drivers/gpu/drm/amd/powerplay/smu_v11_0.c index 89749b1d2019..a4aba8576900 100644 --- a/drivers/gpu/drm/amd/powerplay/smu_v11_0.c +++ b/drivers/gpu/drm/amd/powerplay/smu_v11_0.c @@ -1656,7 +1656,7 @@ static bool smu_v11_0_baco_is_support(struct smu_context *smu) static enum smu_baco_state smu_v11_0_baco_get_state(struct smu_context *smu) { struct smu_baco_context *smu_baco = &smu->smu_baco; - enum smu_baco_state baco_state = SMU_BACO_STATE_EXIT; + enum smu_baco_state baco_state; mutex_lock(&smu_baco->mutex); baco_state = smu_baco->state; -- 2.20.1

2 1

[PATCH] drm/i915: Call dma_set_max_seg_size() in i915_ggtt_probe_hw()
by Lyude Paul 22 Aug '19

22 Aug '19

Currently, we don't call dma_set_max_seg_size() for i915 because we intentionally do not limit the segment length that the device supports. However, this results in a warning being emitted if we try to map anything larger than SZ_64K on a kernel with CONFIG_DMA_API_DEBUG_SG enabled: [ 7.751926] DMA-API: i915 0000:00:02.0: mapping sg segment longer than device claims to support [len=98304] [max=65536] [ 7.751934] WARNING: CPU: 5 PID: 474 at kernel/dma/debug.c:1220 debug_dma_map_sg+0x20f/0x340 This was originally brought up on https://bugs.freedesktop.org/show_bug.cgi?id=108517 , and the consensus there was it wasn't really useful to set a limit (and that dma-debug isn't really all that useful for i915 in the first place). Unfortunately though, CONFIG_DMA_API_DEBUG_SG is enabled in the debug configs for various distro kernels. Since a WARN_ON() will disable automatic problem reporting (and cause any CI with said option enabled to start complaining), we really should just fix the problem. Note that as me and Chris Wilson discussed, the other solution for this would be to make DMA-API not make such assumptions when a driver hasn't explicitly set a maximum segment size. But, taking a look at the commit which originally introduced this behavior, commit 78c47830a5cb ("dma-debug: check scatterlist segments"), there is an explicit mention of this assumption and how it applies to devices with no segment size: Conversely, devices which are less limited than the rather conservative defaults, or indeed have no limitations at all (e.g. GPUs with their own internal MMU), should be encouraged to set appropriate dma_parms, as they may get more efficient DMA mapping performance out of it. So unless there's any concerns (I'm open to discussion!), let's just follow suite and call dma_set_max_seg_size() with UINT_MAX as our limit to silence any warnings. Signed-off-by: Lyude Paul <lyude(a)redhat.com> Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: <stable(a)vger.kernel.org> # v4.18+ --- drivers/gpu/drm/i915/i915_gem_gtt.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c index 0b81e0b64393..a1475039d182 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.c +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c @@ -3152,6 +3152,11 @@ static int ggtt_probe_hw(struct i915_ggtt *ggtt, struct intel_gt *gt) if (ret) return ret; + /* We don't have a max segment size, so set it to the max so sg's + * debugging layer doesn't complain + */ + dma_set_max_seg_size(ggtt->vm.dma, UINT_MAX); + if ((ggtt->vm.total - 1) >> 32) { DRM_ERROR("We never expected a Global GTT with more than 32bits" " of address space! Found %lldM!\n", -- 2.21.0

1 1

[PATCH v2 00/19] drm: rcar-du: Add Color Management Module (CMM)
by Jacopo Mondi 22 Aug '19

22 Aug '19

Hello, second iteration of CMM support for Renesas R-Car devices, where I have fixed comments from Laurent, Geert and Daniel. A reference to the v1 cover letter, with some background on the CMM is available here: https://lkml.org/lkml/2019/6/6/583 Notable changes: - Rebased on v5.2-rc7 - clock patches rebased, but already collected by Geert for v5.3 - Changed cmm compatible string as suggested by Geert in bindings and DTS files - CMM driver updated to include comments from Laurent, thanks! - Integration in R-Car DU is very similar, I have squashed a few patches - Add legagy gamma interface support with .gamma_set callback as suggested by Daniel. Thanks j Jacopo Mondi (19): dt-bindings: display: renesas,cmm: Add R-Car CMM documentation dt-bindings: display, renesas,du: Document cmms property arm64: renesas: Update 'vsps' property clk: renesas: r8a7796: Add CMM clocks clk: renesas: r8a7795: Add CMM clocks clk: renesas: r8a77965: Add CMM clocks clk: renesas: r8a77990: Add CMM clocks clk: renesas: r8a77995: Add CMM clocks arm64: dts: renesas: r8a7796: Add CMM units arm64: dts: renesas: r8a7795: Add CMM units arm64: dts: renesas: r8a77965: Add CMM units arm64: dts: renesas: r8a77990: Add CMM units arm64: dts: renesas: r8a77995: Add CMM units drm: rcar-du: Add support for CMM drm: rcar-du: Claim CMM support for Gen3 SoCs drm: rcar-du: kms: Collect CMM instances drm: rcar-du: crtc: Enable and disable CMMs drm: rcar-du: crtc: Register GAMMA_LUT properties drm: rcar-du: kms: Update CMM in atomic commit tail .../bindings/display/renesas,cmm.txt | 25 ++ .../bindings/display/renesas,du.txt | 5 + arch/arm64/boot/dts/renesas/r8a774c0.dtsi | 2 +- arch/arm64/boot/dts/renesas/r8a7795.dtsi | 36 ++- arch/arm64/boot/dts/renesas/r8a7796.dtsi | 25 ++ arch/arm64/boot/dts/renesas/r8a77965.dtsi | 27 +- arch/arm64/boot/dts/renesas/r8a77990.dtsi | 20 +- arch/arm64/boot/dts/renesas/r8a77995.dtsi | 20 +- drivers/clk/renesas/r8a7795-cpg-mssr.c | 4 + drivers/clk/renesas/r8a7796-cpg-mssr.c | 3 + drivers/clk/renesas/r8a77965-cpg-mssr.c | 3 + drivers/clk/renesas/r8a77990-cpg-mssr.c | 2 + drivers/clk/renesas/r8a77995-cpg-mssr.c | 2 + drivers/gpu/drm/rcar-du/Kconfig | 7 + drivers/gpu/drm/rcar-du/Makefile | 1 + drivers/gpu/drm/rcar-du/rcar_cmm.c | 291 ++++++++++++++++++ drivers/gpu/drm/rcar-du/rcar_cmm.h | 38 +++ drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 17 + drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 + drivers/gpu/drm/rcar-du/rcar_du_drv.c | 12 +- drivers/gpu/drm/rcar-du/rcar_du_drv.h | 4 + drivers/gpu/drm/rcar-du/rcar_du_group.c | 8 + drivers/gpu/drm/rcar-du/rcar_du_group.h | 2 + drivers/gpu/drm/rcar-du/rcar_du_kms.c | 86 ++++++ drivers/gpu/drm/rcar-du/rcar_du_regs.h | 5 + 25 files changed, 638 insertions(+), 9 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/renesas,cmm.txt create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.c create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.h -- 2.21.0

6 51

[Bug 110659] pageflipping seems to cause jittering on mouse input when running Hitman 2 in Wine/DXVK with amdgpu.dc=1
by bugzilla-daemon＠freedesktop.org 22 Aug '19

22 Aug '19

https://bugs.freedesktop.org/show_bug.cgi?id=110659 --- Comment #45 from tempel.julian(a)gmail.com --- Created attachment 145140 --> https://bugs.freedesktop.org/attachment.cgi?id=145140&action=edit new dmesg log with debug patch applied after starting Hitman 2 -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 110659] pageflipping seems to cause jittering on mouse input when running Hitman 2 in Wine/DXVK with amdgpu.dc=1
by bugzilla-daemon＠freedesktop.org 22 Aug '19

22 Aug '19

https://bugs.freedesktop.org/show_bug.cgi?id=110659 --- Comment #44 from tempel.julian(a)gmail.com --- I applied the patch to linux 5.2 (among 0001-drm-amd-display-Allow-fast-updates-again-for-swappin.patch) and as expected, gamma adjustments have stopped working. Unfortunately, the games still show the issue. Should the debug information be contained in dmesg? After doing echo 0x4 > /sys/module/drm/parameters/debug and starting Hitman 2, there don't seem to be any comprehensive debug information inside the dmesg log, at least not to my layman eyes (attaching right now nonetheless). -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 110659] pageflipping seems to cause jittering on mouse input when running Hitman 2 in Wine/DXVK with amdgpu.dc=1
by bugzilla-daemon＠freedesktop.org 22 Aug '19

22 Aug '19

https://bugs.freedesktop.org/show_bug.cgi?id=110659 --- Comment #43 from Nicholas Kazlauskas <nicholas.kazlauskas(a)amd.com> --- Created attachment 145139 --> https://bugs.freedesktop.org/attachment.cgi?id=145139&action=edit 0001-drm-amd-display-Test-patch-for-disabling-color-adjus.patch >From your video it looks like something is issuing a lot of full updates. Those are slow enough that they can miss the current vblank window and be forced to wait until the next one with vsync on. I've attached a debug patch you can try that should disable color adjustments from triggering full updates. I've also added some debug information to know when full updates are being issued in case it was something other than color management. You can view that output with log level 4, ie. echo 0x4 > /sys/module/drm/parameters/debug -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 110659] pageflipping seems to cause jittering on mouse input when running Hitman 2 in Wine/DXVK with amdgpu.dc=1
by bugzilla-daemon＠freedesktop.org 22 Aug '19

22 Aug '19

https://bugs.freedesktop.org/show_bug.cgi?id=110659 --- Comment #42 from tempel.julian(a)gmail.com --- (In reply to Nicholas Kazlauskas from comment #39) > Disabling the compositor doesn't make a difference as far as stuttering goes > for Hitman 2's DXVK - I don't see any commits in the log that are lock the > connector and all the planes. Thanks for trying! > I don't have Oblivion on my machine to test, but I tried running the DX9 > version of Heaven under proton and I don't see stuttering or any gamma/color > adjustment commits under that either. No issues with FreeSync when running > it either from what I can tell with vsync both on/off. I've given Heaven a try, it doesn't show the issue for me either (DX9 via D9VK). > Those commits are definitely what's causing your stuttering, but I'm not > sure what's actually creating them. My initial guess was something in the > compatibility layer for DX9 games, but I don't see that on my setup. I've attached a debug dmesg log after triggering the issue in Hitman 2. It is also what is shown in the new video capture I've provided. As you can see, there are no rendering spikes, but instead the mouse input (and perhaps partially also keyboard) seems to be discarded a lot, causing such jumps. This is also there without vsync enabled, but less obvious. Just like the render spikes in Oblivion/Skyrim, this issue completely disappears by turning off pageflipping in xorg config, switching to modesetting DDX or disabling atomic modesetting via amdgpu.dc=0. I wonder if the log confirms that it's the same issue (or the issue has the same roots)? > Is it only Oblivion that has this issue for you? I found out that also the native OpenGL renderer of Doom 2016 (which also has a free demo on Steam) shows the same behavior as Oblivion/Skyrim, despite of no 3D API wrapper involved. For whatever reason, the Vulkan renderer of the game doesn't show the issue, it seems to run flawlessly with both pageflipping + vsync. > I'm not sure how much of this can be a kernel level fix - I think we need to > lock all the planes whenever gamma or color adjustments have been made and > that probably includes the cursor plane as well. If the cursor plane is > included that will block asynchronous cursor updates from occurring until > the color adjustments have been done. This is why the cursor causes > stuttering. Would it be possible to provide a test patch that completely blocks any gamma adjustment either in Xorg or the kernel? Then we'd have ultimate proof. :) > A check could potentially be made to not lock all the planes for redundant > color management commits, but I'm not sure if the color adjustments > requested are redundant or not. It could be the case that the application is > requesting different color adjustments every single time. It seems some suboptimal behavior of Wine can trigger this issue, but I suppose it would automatically be fixed together with this issue which I reported regarding gamma adjustment performance and atomic modesetting: https://bugs.freedesktop.org/show_bug.cgi?id=108917 I btw. can reproduce that issue by simply booting Fedora 30 Workstation Gnome Live and enable the nightlight feature, the color grading phase makes everything stutter. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 110659] pageflipping seems to cause jittering on mouse input when running Hitman 2 in Wine/DXVK with amdgpu.dc=1
by bugzilla-daemon＠freedesktop.org 22 Aug '19

22 Aug '19

https://bugs.freedesktop.org/show_bug.cgi?id=110659 --- Comment #41 from tempel.julian(a)gmail.com --- Created attachment 145138 --> https://bugs.freedesktop.org/attachment.cgi?id=145138&action=edit debug dmesg.log after running Hitman 2 with the issue -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 110659] pageflipping seems to cause jittering on mouse input when running Hitman 2 in Wine/DXVK with amdgpu.dc=1
by bugzilla-daemon＠freedesktop.org 22 Aug '19

22 Aug '19

https://bugs.freedesktop.org/show_bug.cgi?id=110659 --- Comment #40 from tempel.julian(a)gmail.com --- Created attachment 145137 --> https://bugs.freedesktop.org/attachment.cgi?id=145137&action=edit video demonstrating the issue in Hitman 2 (different to Oblivion/Skyrim) -- You are receiving this mail because: You are the assignee for the bug.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel August 2019