dri-devel September 2019

dri-devel@lists.freedesktop.org

315 participants
2278 discussions

potential regression in drm/mgag200
by Davidlohr Bueso 04 Sep '19

04 Sep '19

Hi, While doing some changes to x86's pat code and thus having 'debugpat', I noticed some weird behavior in a server running linux-next as of -- yes, reverting does 'fix' the issue: 90f479ae51a (drm/mgag200: Replace struct mga_fbdev with generic framebuffer emulation) Where the following splat is seen over and over endlessly for the same range: x86/PAT: Overlap at 0xd0000000-0xd1000000 x86/PAT: reserve_memtype added [mem 0xd0000000-0xd02fffff], track write-combining, req write-combining, ret write-combining x86/PAT: free_memtype request [mem 0xd0000000-0xd02fffff] And all these are doing ioremap from drm_fb_helper_dirty_work(): [ 114.330825] reserve_memtype+0x1b0/0x410 [ 114.330829] ? ttm_bo_kmap+0x1d7/0x270 [ttm] [ 114.330830] __ioremap_caller.constprop.14+0xf6/0x300 [ 114.330832] ? soft_cursor+0x1f9/0x220 [ 114.330835] ttm_bo_kmap+0x1d7/0x270 [ttm] [ 114.330838] ? ttm_bo_del_sub_from_lru+0x29/0x40 [ttm] [ 114.330841] drm_gem_vram_kmap+0x54/0x70 [drm_vram_helper] [ 114.330842] drm_gem_vram_object_vmap+0x23/0x40 [drm_vram_helper] [ 114.330853] drm_gem_vmap+0x1f/0x60 [drm] [ 114.477697] drm_client_buffer_vmap+0x1d/0x30 [drm] [ 114.477703] drm_fb_helper_dirty_work+0x92/0x180 [drm_kms_helper] [ 114.477706] process_one_work+0x1f4/0x3e0 [ 114.477707] worker_thread+0x2d/0x3e0 Before, the same range was also added, but only once, and fwiw it was the same either with 24 or 32 bpp. Any thoughts? Thanks, Davidlohr

2 1

[PATCH -next] fbdev: wm8505fb: use devm_platform_ioremap_resource() to simplify code
by YueHaibing 04 Sep '19

04 Sep '19

Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by: Hulk Robot <hulkci(a)huawei.com> Signed-off-by: YueHaibing <yuehaibing(a)huawei.com> --- drivers/video/fbdev/wm8505fb.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/video/fbdev/wm8505fb.c b/drivers/video/fbdev/wm8505fb.c index 17c7803..351d27b 100644 --- a/drivers/video/fbdev/wm8505fb.c +++ b/drivers/video/fbdev/wm8505fb.c @@ -261,7 +261,6 @@ static struct fb_ops wm8505fb_ops = { static int wm8505fb_probe(struct platform_device *pdev) { struct wm8505fb_info *fbi; - struct resource *res; struct display_timings *disp_timing; void *addr; int ret; @@ -299,8 +298,7 @@ static int wm8505fb_probe(struct platform_device *pdev) addr = addr + sizeof(struct wm8505fb_info); fbi->fb.pseudo_palette = addr; - res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - fbi->regbase = devm_ioremap_resource(&pdev->dev, res); + fbi->regbase = devm_platform_ioremap_resource(pdev, 0); if (IS_ERR(fbi->regbase)) return PTR_ERR(fbi->regbase); -- 2.7.4

1 0

[PATCH] drm: bridge/dw_hdmi: add audio sample channel status setting
by Cheng-Yi Chiang 04 Sep '19

04 Sep '19

From: Yakir Yang <ykk(a)rock-chips.com> When transmitting IEC60985 linear PCM audio, we configure the Audio Sample Channel Status information of all the channel status bits in the IEC60958 frame. Refer to 60958-3 page 10 for frequency, original frequency, and wordlength setting. This fix the issue that audio does not come out on some monitors (e.g. LG 22CV241) Signed-off-by: Yakir Yang <ykk(a)rock-chips.com> Signed-off-by: Cheng-Yi Chiang <cychiang(a)chromium.org> --- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 59 +++++++++++++++++++++++ drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 20 ++++++++ 2 files changed, 79 insertions(+) diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index bd65d0479683..34d46e25d610 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c @@ -582,6 +582,63 @@ static unsigned int hdmi_compute_n(unsigned int freq, unsigned long pixel_clk) return n; } +static void hdmi_set_schnl(struct dw_hdmi *hdmi) +{ + u8 aud_schnl_samplerate; + u8 aud_schnl_8; + + /* These registers are on RK3288 using version 2.0a. */ + if (hdmi->version != 0x200a) + return; + + switch (hdmi->sample_rate) { + case 32000: + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_32K; + break; + case 44100: + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_44K1; + break; + case 48000: + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_48K; + break; + case 88200: + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_88K2; + break; + case 96000: + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_96K; + break; + case 176400: + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_176K4; + break; + case 192000: + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_192K; + break; + case 768000: + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_768K; + break; + default: + dev_warn(hdmi->dev, "Unsupported audio sample rate (%u)\n", + hdmi->sample_rate); + return; + } + + /* set channel status register */ + hdmi_modb(hdmi, aud_schnl_samplerate, HDMI_FC_AUDSCHNLS7_SMPRATE_MASK, + HDMI_FC_AUDSCHNLS7); + + /* + * Set original frequency to be the same as frequency. + * Use one-complement value as stated in IEC60958-3 page 13. + */ + aud_schnl_8 = (~aud_schnl_samplerate) << + HDMI_FC_AUDSCHNLS8_ORIGSAMPFREQ_OFFSET; + + /* This means word length is 16 bit. Refer to IEC60958-3 page 12. */ + aud_schnl_8 |= 2 << HDMI_FC_AUDSCHNLS8_WORDLEGNTH_OFFSET; + + hdmi_writeb(hdmi, aud_schnl_8, HDMI_FC_AUDSCHNLS8); +} + static void hdmi_set_clk_regenerator(struct dw_hdmi *hdmi, unsigned long pixel_clk, unsigned int sample_rate) { @@ -620,6 +677,8 @@ static void hdmi_set_clk_regenerator(struct dw_hdmi *hdmi, hdmi->audio_cts = cts; hdmi_set_cts_n(hdmi, cts, hdmi->audio_enable ? n : 0); spin_unlock_irq(&hdmi->audio_lock); + + hdmi_set_schnl(hdmi); } static void hdmi_init_clk_regenerator(struct dw_hdmi *hdmi) diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h index 6988f12d89d9..619ebc1c8354 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h @@ -158,6 +158,17 @@ #define HDMI_FC_SPDDEVICEINF 0x1062 #define HDMI_FC_AUDSCONF 0x1063 #define HDMI_FC_AUDSSTAT 0x1064 +#define HDMI_FC_AUDSV 0x1065 +#define HDMI_FC_AUDSU 0x1066 +#define HDMI_FC_AUDSCHNLS0 0x1067 +#define HDMI_FC_AUDSCHNLS1 0x1068 +#define HDMI_FC_AUDSCHNLS2 0x1069 +#define HDMI_FC_AUDSCHNLS3 0x106a +#define HDMI_FC_AUDSCHNLS4 0x106b +#define HDMI_FC_AUDSCHNLS5 0x106c +#define HDMI_FC_AUDSCHNLS6 0x106d +#define HDMI_FC_AUDSCHNLS7 0x106e +#define HDMI_FC_AUDSCHNLS8 0x106f #define HDMI_FC_DATACH0FILL 0x1070 #define HDMI_FC_DATACH1FILL 0x1071 #define HDMI_FC_DATACH2FILL 0x1072 @@ -706,6 +717,15 @@ enum { /* HDMI_FC_AUDSCHNLS7 field values */ HDMI_FC_AUDSCHNLS7_ACCURACY_OFFSET = 4, HDMI_FC_AUDSCHNLS7_ACCURACY_MASK = 0x30, + HDMI_FC_AUDSCHNLS7_SMPRATE_MASK = 0x0f, + HDMI_FC_AUDSCHNLS7_SMPRATE_192K = 0xe, + HDMI_FC_AUDSCHNLS7_SMPRATE_176K4 = 0xc, + HDMI_FC_AUDSCHNLS7_SMPRATE_96K = 0xa, + HDMI_FC_AUDSCHNLS7_SMPRATE_768K = 0x9, + HDMI_FC_AUDSCHNLS7_SMPRATE_88K2 = 0x8, + HDMI_FC_AUDSCHNLS7_SMPRATE_32K = 0x3, + HDMI_FC_AUDSCHNLS7_SMPRATE_48K = 0x2, + HDMI_FC_AUDSCHNLS7_SMPRATE_44K1 = 0x0, /* HDMI_FC_AUDSCHNLS8 field values */ HDMI_FC_AUDSCHNLS8_ORIGSAMPFREQ_MASK = 0xf0, -- 2.23.0.187.g17f5b7556c-goog

6 13

[PATCH v3 0/3] Send a hotplug when edid changes
by Stanislav Lisovskiy 04 Sep '19

04 Sep '19

This series introduce to drm a way to determine if something else except connection_status had changed during probing, which can be used by other drivers as well. Another i915 specific part uses this approach to determine if edid had changed without changing the connection status and send a hotplug event. Stanislav Lisovskiy (3): drm: Add helper to compare edids. drm: Introduce change counter to drm_connector drm/i915: Send hotplug event if edid had changed. drivers/gpu/drm/drm_connector.c | 1 + drivers/gpu/drm/drm_edid.c | 33 ++++++++++++++++++++ drivers/gpu/drm/drm_probe_helper.c | 29 +++++++++++++++-- drivers/gpu/drm/i915/display/intel_dp.c | 16 +++++++++- drivers/gpu/drm/i915/display/intel_hdmi.c | 16 ++++++++-- drivers/gpu/drm/i915/display/intel_hotplug.c | 21 ++++++++++--- include/drm/drm_connector.h | 3 ++ include/drm/drm_edid.h | 9 ++++++ 8 files changed, 117 insertions(+), 11 deletions(-) -- 2.17.1

4 19

[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 04 Sep '19

04 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=110659 --- Comment #65 from tempel.julian(a)gmail.com --- @Nicholas Since this commit, the modesetting driver shows the same behavior as xf86-video-amdgpu: https://gitlab.freedesktop.org/xorg/xserver/commit/f0d78b47ac49977a6007f5fe… So, now only xwayland isn't affected. But I think this can very well be just because Wayland compositors yet don't support turning compositing off in fullscreen. We might see the same effect as on Xorg, where keeping some compositors enabled seems to "fix" the issue (at the cost of high input latency, other performance issues and non-functional FreeSync). -- You are receiving this mail because: You are the assignee for the bug.

1 0

Re: [PATCH v2 1/4] x86/mm: Export force_dma_unencrypted
by Thomas Hellström (VMware) 04 Sep '19

04 Sep '19

On 9/4/19 8:58 AM, Christoph Hellwig wrote: > On Tue, Sep 03, 2019 at 10:46:18PM +0200, Thomas Hellström (VMware) wrote: >> What I mean with "from an engineering perspective" is that drivers would end >> up with a non-trivial amount of code supporting purely academic cases: >> Setups where software rendering would be faster than gpu accelerated, and >> setups on platforms where the driver would never run anyway because the >> device would never be supported on that platform... > And actually work on cases you previously called academic and which now > matter to you because your employer has a suddent interest in SEV. > Academic really is in the eye of the beholder (and of those who pay > the bills). But in this particular case we *do* adhere to the dma api, at least as far as we can. But we're missing functionality. > >> That is not really true. The dma API can't handle faulting of coherent pages >> which is what this series is really all about supporting also with SEV >> active. To handle the case where we move graphics buffers or send them to >> swap space while user-space have them mapped. > And the only thing we need to support the fault handler is to add an > offset to the dma_mmap_* APIs. Which I had planned to do for Christian > (one of the few grapics developers who actually tries to play well > with the rest of the kernel instead of piling hacks over hacks like > many others) anyway, but which hasn't happened yet. That sounds great. Is there anything I can do to help out? I thought this was more or less a dead end since the current dma_mmap_ API requires the mmap_sem to be held in write mode (modifying the vma->vm_flags) whereas fault() only offers read mode. But that would definitely work. > >> Still, I need a way forward and my questions weren't really answered by >> this. > This is pretty demanding. If you "need" a way forward just work with > all the relevant people instead of piling ob local hacks. But I think that was what I was trying to initiate. The question was "If it's the latter, then I would like to reiterate that it would be better that we work to come up with a long term plan to add what's missing to the DMA api to help graphics drivers use coherent memory?" And since you NAK'd the original patches, I was sort of hoping for a point in the right direction. Thanks, Thomas

1 0

[Bug 108973] The game Evil Twin segfaults when loading saved state.
by bugzilla-daemon＠freedesktop.org 04 Sep '19

04 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=108973 Bug ID: 108973 Summary: The game Evil Twin segfaults when loading saved state. Product: Mesa Version: 18.2 Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: inferrna(a)gmail.com QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 142747 --> https://bugs.freedesktop.org/attachment.cgi?id=142747&action=edit Backtrace with dbg wine 3.21 mesa 18.2.5 radeon rx560 architecture: amd64, the game itself is i386 -- You are receiving this mail because: You are the assignee for the bug.

1 3

[PATCH v3 01/11] checkpatch: check for nested (un)?likely() calls
by Denis Efremov 04 Sep '19

04 Sep '19

IS_ERR(), IS_ERR_OR_NULL(), IS_ERR_VALUE() and WARN*() already contain unlikely() optimization internally. Thus, there is no point in calling these functions and defines under likely()/unlikely(). This check is based on the coccinelle rule developed by Enrico Weigelt https://lore.kernel.org/lkml/1559767582-11081-1-git-send-email-info@metux.n… Signed-off-by: Denis Efremov <efremov(a)linux.com> Cc: Joe Perches <joe(a)perches.com> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Andy Whitcroft <apw(a)canonical.com> --- scripts/checkpatch.pl | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl index 93a7edfe0f05..56969ce06df4 100755 --- a/scripts/checkpatch.pl +++ b/scripts/checkpatch.pl @@ -6480,6 +6480,12 @@ sub process { "Using $1 should generally have parentheses around the comparison\n" . $herecurr); } +# nested likely/unlikely calls + if ($line =~ /\b(?:(?:un)?likely)\s*\(\s*!?\s*(IS_ERR(?:_OR_NULL|_VALUE)?|WARN)/) { + WARN("LIKELY_MISUSE", + "nested (un)?likely() calls, $1 already uses unlikely() internally\n" . $herecurr); + } + # whine mightly about in_atomic if ($line =~ /\bin_atomic\s*\(/) { if ($realfile =~ m@^drivers/@) { -- 2.21.0

3 7

[PATCH 10/10] [v10] drm/panel: Add Boe Himax8279d MIPI-DSI LCD panel
by Jerry Han 04 Sep '19

04 Sep '19

3 4

Re: gnome-shell stuck because of amdgpu driver [5.3 RC5]
by Mikhail Gavrilov 04 Sep '19

04 Sep '19

On Tue, 3 Sep 2019 at 13:21, Hillf Danton <hdanton(a)sina.com> wrote: > > Describe the problems you are experiencing please. > Say is the screen locked up? Machine lockedup? > Anything unnormal after you see the warning? > According to my observations, all "gnome shell stuck warning" happened when me not sitting on the computer and the computer was locked. I did not notice any problems at the morning (I did not even look at the kernel logs), I found that the problem happened when I remotely connected to my computer via ssh from work and accidently look dmesg output. At the evening after work, I even played in the "Division", and still not noted any problems. Now 11:01pm and "gnome shell stuck warning" not appear since 19:17. So looks like issue happens only when computer blocked and monitor in power save mode. $ dmesg -T | grep gnome ---> I am goto sleep [Tue Sep 3 01:00:10 2019] gnome shell stuck warning [Tue Sep 3 01:00:55 2019] gnome shell stuck warning [Tue Sep 3 06:54:50 2019] gnome shell stuck warning <--- I am wake up at 8:00 am and sitting again on the computer ---> I am went to work at 9:30 [Tue Sep 3 10:00:05 2019] gnome shell stuck warning [Tue Sep 3 10:10:01 2019] gnome shell stuck warning [Tue Sep 3 10:13:43 2019] gnome shell stuck warning [Tue Sep 3 10:23:37 2019] gnome shell stuck warning [Tue Sep 3 10:42:07 2019] gnome shell stuck warning [Tue Sep 3 10:42:57 2019] gnome shell stuck warning [Tue Sep 3 10:59:25 2019] gnome shell stuck warning [Tue Sep 3 11:08:35 2019] gnome shell stuck warning [Tue Sep 3 11:13:19 2019] gnome shell stuck warning [Tue Sep 3 11:15:20 2019] gnome shell stuck warning [Tue Sep 3 11:26:20 2019] gnome shell stuck warning [Tue Sep 3 11:26:20 2019] gnome shell stuck warning [Tue Sep 3 11:36:30 2019] gnome shell stuck warning [Tue Sep 3 11:46:08 2019] gnome shell stuck warning [Tue Sep 3 11:53:52 2019] gnome shell stuck warning [Tue Sep 3 11:56:36 2019] gnome shell stuck warning [Tue Sep 3 12:17:10 2019] gnome shell stuck warning [Tue Sep 3 12:20:20 2019] gnome shell stuck warning [Tue Sep 3 12:20:20 2019] gnome shell stuck warning [Tue Sep 3 12:30:46 2019] gnome shell stuck warning [Tue Sep 3 12:40:52 2019] gnome shell stuck warning [Tue Sep 3 12:55:30 2019] gnome shell stuck warning [Tue Sep 3 12:57:52 2019] gnome shell stuck warning [Tue Sep 3 13:04:00 2019] gnome shell stuck warning [Tue Sep 3 13:12:38 2019] gnome shell stuck warning [Tue Sep 3 13:14:32 2019] gnome shell stuck warning [Tue Sep 3 13:53:12 2019] gnome shell stuck warning [Tue Sep 3 14:12:52 2019] gnome shell stuck warning [Tue Sep 3 14:15:54 2019] gnome shell stuck warning [Tue Sep 3 14:17:04 2019] gnome shell stuck warning [Tue Sep 3 14:21:57 2019] gnome shell stuck warning [Tue Sep 3 14:22:10 2019] gnome shell stuck warning [Tue Sep 3 14:37:42 2019] gnome shell stuck warning [Tue Sep 3 14:41:51 2019] gnome shell stuck warning [Tue Sep 3 14:42:52 2019] gnome shell stuck warning [Tue Sep 3 14:46:35 2019] gnome shell stuck warning [Tue Sep 3 15:03:18 2019] gnome shell stuck warning [Tue Sep 3 15:16:50 2019] gnome shell stuck warning [Tue Sep 3 15:27:30 2019] gnome shell stuck warning [Tue Sep 3 15:27:41 2019] gnome shell stuck warning [Tue Sep 3 16:08:06 2019] gnome shell stuck warning [Tue Sep 3 16:24:16 2019] gnome shell stuck warning [Tue Sep 3 16:33:04 2019] gnome shell stuck warning [Tue Sep 3 16:52:10 2019] gnome shell stuck warning [Tue Sep 3 17:18:27 2019] gnome shell stuck warning [Tue Sep 3 17:25:30 2019] gnome shell stuck warning [Tue Sep 3 17:41:16 2019] gnome shell stuck warning [Tue Sep 3 17:43:32 2019] gnome shell stuck warning [Tue Sep 3 17:51:10 2019] gnome shell stuck warning [Tue Sep 3 18:41:44 2019] gnome shell stuck warning [Tue Sep 3 18:44:18 2019] gnome shell stuck warning [Tue Sep 3 19:03:07 2019] gnome shell stuck warning [Tue Sep 3 19:17:58 2019] gnome shell stuck warning <--- Returned to home and sitting again on the computer -- Best Regards, Mike Gavrilov.

3 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel September 2019