RE: [PATCH] drm/amd/powerplay: remove spurious semicolon
Reviewed-by: Evan Quan
> -Original Message-
> From: Andrea Righi
> Sent: 2019年5月4日 0:56
> To: Deucher, Alexander ; Koenig, Christian
> ; Zhou, David(ChunMing)
>
> Cc: Rex Zhu ; Wu, Hersen ;
> Quan, Evan ; amd-...@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org; linux-ker...@vger.kernel.org
> Subject: [PATCH] drm/amd/powerplay: remove spurious semicolon
>
> [CAUTION: External Email]
>
> Remove unnecessary semicolons at the end of line.
>
> Signed-off-by: Andrea Righi
> ---
> drivers/gpu/drm/amd/powerplay/amd_powerplay.c | 8
> drivers/gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c | 2 +-
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
> b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
> index 3f73f7cd18b9..1052f5119087 100644
> --- a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
> +++ b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
> @@ -1304,7 +1304,7 @@ static int pp_notify_smu_enable_pwe(void
> *handle)
>
> if (hwmgr->hwmgr_func->smus_notify_pwe == NULL) {
> pr_info_ratelimited("%s was not implemented.\n", __func__);
> - return -EINVAL;;
> + return -EINVAL;
> }
>
> mutex_lock(>smu_lock);
> @@ -1341,7 +1341,7 @@ static int pp_set_min_deep_sleep_dcefclk(void
> *handle, uint32_t clock)
>
> if (hwmgr->hwmgr_func->set_min_deep_sleep_dcefclk == NULL) {
> pr_debug("%s was not implemented.\n", __func__);
> - return -EINVAL;;
> + return -EINVAL;
> }
>
> mutex_lock(>smu_lock);
> @@ -1360,7 +1360,7 @@ static int pp_set_hard_min_dcefclk_by_freq(void
> *handle, uint32_t clock)
>
> if (hwmgr->hwmgr_func->set_hard_min_dcefclk_by_freq == NULL) {
> pr_debug("%s was not implemented.\n", __func__);
> - return -EINVAL;;
> + return -EINVAL;
> }
>
> mutex_lock(>smu_lock);
> @@ -1379,7 +1379,7 @@ static int pp_set_hard_min_fclk_by_freq(void
> *handle, uint32_t clock)
>
> if (hwmgr->hwmgr_func->set_hard_min_fclk_by_freq == NULL) {
> pr_debug("%s was not implemented.\n", __func__);
> - return -EINVAL;;
> + return -EINVAL;
> }
>
> mutex_lock(>smu_lock);
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c
> b/drivers/gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c
> index c1c51c115e57..70f7f47a2fcf 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c
> @@ -76,7 +76,7 @@ int phm_set_power_state(struct pp_hwmgr *hwmgr,
> int phm_enable_dynamic_state_management(struct pp_hwmgr *hwmgr) {
> struct amdgpu_device *adev = NULL;
> - int ret = -EINVAL;;
> + int ret = -EINVAL;
> PHM_FUNC_CHECK(hwmgr);
> adev = hwmgr->adev;
>
> --
> 2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109345] drm-next-2018-12-14 -Linux PPC
https://bugs.freedesktop.org/show_bug.cgi?id=109345 --- Comment #29 from Christian Zigotzky --- Hi All, Allan tested the third test kernel today. He wrote: Christian DRM3 boots to SI card. ace PS Thanks for doing this , much appreciated. -- This step has been marked as bad because the third test kernel doesn't boot to the FirePro. Next step: git bisect bad Output: Bisecting: 92 revisions left to test after this (roughly 7 steps) [2b02a05bdc3a62d36e0d0b015351897109e25991] drm/vc4: Set ->is_yuv to false when num_planes == 1 make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc oldconfig make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc uImage Download: http://www.xenosoft.de/uImage-drm4 @Allan (acefnq/ace) Please test it. Thanks, Christian -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Fix drm.h uapi header for GNU/kFreeBSD
On 15 Jan 2019, at 18:41, Eric Anholt wrote: > > Daniel Vetter writes: > >> On Tue, Jan 15, 2019 at 03:04:18PM +, James Clarke wrote: >>> Like GNU/Linux, GNU/kFreeBSD's sys/types.h does not define the uintX_t >>> types, which differs from the BSDs' headers. Thus we should include >>> stdint.h to ensure we have all the required integer types. >>> >>> Signed-off-by: James Clarke >> >> Would be good to get an ack from some other *bsd that this is still all >> fine. lgtm otherwise. >> -Daniel > > I think there was some need for inttypes.h instead of stdint like a > decade ago when I was working on BSDs, but that was already almost > irrelevant then. Hi, just following up on this; is there still the need for an ACK? Regards, James ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110610] kernel BUG at drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:5611
https://bugs.freedesktop.org/show_bug.cgi?id=110610 --- Comment #1 from Ernst Sjöstrand --- Kernel looks like it's based on v5.0.6 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110610] kernel BUG at drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:5611
https://bugs.freedesktop.org/show_bug.cgi?id=110610 Bug ID: 110610 Summary: kernel BUG at drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu _dm.c:5611 Product: DRI Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: ern...@gmail.com Hi, I was playing with the experimental fractional scaling for X11 in Gnome in Ubuntu Disco. When I logged out I got this error. xserver-xorg-video-amdgpu 19.0.1+git1903191844.bd4ffd4 linux-image-5.0.0-14-generic 5.0.0-14.15 libgl1-mesa-dri:amd64 19.0.2-1ubuntu1 libdrm-amdgpu1:amd64 2.4.97-1ubuntu1 [ cut here ] kernel BUG at drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:5611! invalid opcode: [#1] SMP NOPTI CPU: 10 PID: 4211 Comm: Xorg Not tainted 5.0.0-14-generic #15-Ubuntu Hardware name: System manufacturer System Product Name/PRIME X370-PRO, BIOS 4008 04/13/2018 RIP: 0010:dm_update_crtcs_state+0x60d/0x670 [amdgpu] Code: bc fc ff ff 48 85 db 0f 84 7e fd ff ff 48 c7 45 a0 00 00 00 00 48 c7 45 c0 00 00 00 00 48 c7 45 b8 00 00 00 00 e9 65 fe ff ff <0f> 0b b8 ea ff ff ff 48 8b 7d b8 48 85 ff 0f 84 4b fc ff ff 89 45 RSP: 0018:9c71c9763ab0 EFLAGS: 00010246 RAX: 0001 RBX: RCX: 2ad8 RDX: 2ad7 RSI: 8df77eca7160 RDI: 8df77e406e80 RBP: 9c71c9763b20 R08: 00027160 R09: c0882796 R10: fb221fd26a00 R11: f080 R12: 8df7749ad800 R13: 8df774076800 R14: R15: 8df71c768c80 FS: 7f009b637a80() GS:8df77ec8() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f009ba3d5c8 CR3: 00060440e000 CR4: 003406e0 Call Trace: amdgpu_dm_atomic_check+0x1c3/0x460 [amdgpu] drm_atomic_check_only+0x59e/0x7c0 [drm] drm_atomic_commit+0x18/0x50 [drm] restore_fbdev_mode_atomic+0x1bf/0x1d0 [drm_kms_helper] restore_fbdev_mode+0x51/0x160 [drm_kms_helper] ? _cond_resched+0x19/0x30 drm_fb_helper_restore_fbdev_mode_unlocked+0x4e/0xa0 [drm_kms_helper] drm_fb_helper_set_par+0x2d/0x50 [drm_kms_helper] drm_fb_helper_hotplug_event.part.38+0x97/0xc0 [drm_kms_helper] drm_fb_helper_restore_fbdev_mode_unlocked+0x7a/0xa0 [drm_kms_helper] drm_fb_helper_lastclose+0x15/0x20 [drm_kms_helper] amdgpu_driver_lastclose_kms+0xe/0x20 [amdgpu] drm_lastclose+0x35/0x100 [drm] drm_release+0xe8/0x120 [drm] __fput+0xbc/0x230 fput+0xe/0x10 task_work_run+0x9d/0xc0 do_exit+0x2da/0xb30 ? handle_mm_fault+0xe1/0x210 do_group_exit+0x43/0xb0 __x64_sys_exit_group+0x18/0x20 do_syscall_64+0x5a/0x110 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f009bb4a926 Code: Bad RIP value. RSP: 002b:7209d968 EFLAGS: 0246 ORIG_RAX: 00e7 RAX: ffda RBX: 7f009bc4f6d0 RCX: 7f009bb4a926 RDX: RSI: 003c RDI: RBP: R08: 00e7 R09: fc78 R10: 0042 R11: 0246 R12: 7f009bc4f6d0 R13: 0603 R14: 7f009bc53108 R15: Modules linked in: aufs overlay edac_mce_amd kvm irqbypass nls_iso8859_1 snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio amdgpu snd_hda_codec_hdmi input_leds joydev snd_hda_intel snd_hda_codec crct10dif_pclmul snd_hda_core crc32_pclmul snd_hwdep ghash_clmulni_intel snd_pcm chash snd_seq_midi amd_iommu_v2 snd_seq_midi_event aesni_intel gpu_sched snd_rawmidi ttm aes_x86_64 drm_kms_helper crypto_simd cryptd eeepc_wmi snd_seq glue_helper asus_wmi drm sparse_keymap video snd_seq_device mxm_wmi k10temp wmi_bmof snd_timer fb_sys_fops syscopyarea sysfillrect sysimgblt ccp snd soundcore mac_hid sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4 hid_generic usbhid hid igb i2c_piix4 i2c_algo_bit nvme ahci dca libahci nvme_core gpio_amdpt wmi gpio_generic ---[ end trace 721f50ce38f2bef8 ]--- -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 203471] Tearing on Raven Ridge and RX560X PRIME setup even with Vsync enabled
https://bugzilla.kernel.org/show_bug.cgi?id=203471 Haxk20 (haxk...@gmail.com) changed: What|Removed |Added Kernel Version|5.1 rc6 |5.1 rc6 and ||drm-next-5.2-wip -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107049] monitor not found in 4.17+ kernel
https://bugs.freedesktop.org/show_bug.cgi?id=107049 --- Comment #10 from Dan Horák --- and the dc=0 was still required for 5.0, so sound like an improvement in 5.1 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/1] drm/fb-helper: Avoid race with DRM userspace
Den 25.04.2019 10.31, skrev Noralf Trønnes:
> drm_fb_helper_is_bound() is used to check if DRM userspace is in control.
> This is done by looking at the fb on the primary plane. By the time
> fb-helper gets around to committing, it's possible that the facts have
> changed.
>
> Avoid this race by holding the drm_device->master_mutex lock while
> committing. When DRM userspace does its first open, it will now wait
> until fb-helper is done. The helper will stay away if there's a master.
>
> Locking rule: Always take the fb-helper lock first.
>
> v2:
> - Remove drm_fb_helper_is_bound() (Daniel Vetter)
> - No need to check fb_helper->dev->master in
> drm_fb_helper_single_fb_probe(), restore_fbdev_mode() has the check.
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Noralf Trønnes
> Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_auth.c | 20
> drivers/gpu/drm/drm_fb_helper.c | 90 -
> drivers/gpu/drm/drm_internal.h | 2 +
> 3 files changed, 67 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
> index 1669c42c40ed..db199807b7dc 100644
> --- a/drivers/gpu/drm/drm_auth.c
> +++ b/drivers/gpu/drm/drm_auth.c
> @@ -368,3 +368,23 @@ void drm_master_put(struct drm_master **master)
> *master = NULL;
> }
> EXPORT_SYMBOL(drm_master_put);
> +
> +/* Used by drm_client and drm_fb_helper */
> +bool drm_master_internal_acquire(struct drm_device *dev)
> +{
> + mutex_lock(>master_mutex);
> + if (dev->master) {
> + mutex_unlock(>master_mutex);
> + return false;
> + }
> +
> + return true;
> +}
> +EXPORT_SYMBOL(drm_master_internal_acquire);
> +
> +/* Used by drm_client and drm_fb_helper */
> +void drm_master_internal_release(struct drm_device *dev)
> +{
> + mutex_unlock(>master_mutex);
> +}
> +EXPORT_SYMBOL(drm_master_internal_release);
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 2339f0f8f5a8..578428461391 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -44,6 +44,7 @@
>
> #include "drm_crtc_internal.h"
> #include "drm_crtc_helper_internal.h"
> +#include "drm_internal.h"
>
> static bool drm_fbdev_emulation = true;
> module_param_named(fbdev_emulation, drm_fbdev_emulation, bool, 0600);
> @@ -509,7 +510,7 @@ static int restore_fbdev_mode_legacy(struct drm_fb_helper
> *fb_helper)
> return ret;
> }
>
> -static int restore_fbdev_mode(struct drm_fb_helper *fb_helper)
> +static int restore_fbdev_mode_force(struct drm_fb_helper *fb_helper)
> {
> struct drm_device *dev = fb_helper->dev;
>
> @@ -519,6 +520,21 @@ static int restore_fbdev_mode(struct drm_fb_helper
> *fb_helper)
> return restore_fbdev_mode_legacy(fb_helper);
> }
>
> +static int restore_fbdev_mode(struct drm_fb_helper *fb_helper)
> +{
> + struct drm_device *dev = fb_helper->dev;
> + int ret;
> +
> + if (!drm_master_internal_acquire(dev))
> + return -EBUSY;
> +
> + ret = restore_fbdev_mode_force(fb_helper);
> +
> + drm_master_internal_release(dev);
> +
> + return ret;
> +}
> +
> /**
> * drm_fb_helper_restore_fbdev_mode_unlocked - restore fbdev configuration
> * @fb_helper: driver-allocated fbdev helper, can be NULL
The Intel CI doesn't like this patch. AFAICT the reason is that the
igt@kms_fbcon_fbt@psr-suspend test expects fbcon to work while it has an
open fd that is master. This doesn't match the new rule of bailing out
if there's a master.
Adding this debug output:
@@ -558,6 +558,17 @@ int
drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper *fb_helper)
return 0;
mutex_lock(_helper->lock);
+if (READ_ONCE(fb_helper->dev->master)) {
+ int level = default_message_loglevel;
+
+ default_message_loglevel = LOGLEVEL_DEBUG;
+ printk("\n");
+ printk("\n");
+ printk("%s\n", __func__);
+ printk("THERE IS A MASTER\n");
+ dump_stack();
+ default_message_loglevel = level;
+}
ret = restore_fbdev_mode_force(fb_helper);
do_delayed = fb_helper->delayed_hotplug;
Gives these log entries:
<7> [1857.940072] drm_fb_helper_restore_fbdev_mode_unlocked
<7> [1857.940074] THERE IS A MASTER
<7> [1857.940079] CPU: 4 PID: 8209 Comm: kms_fbcon_fbt Tainted: G U
5.1.0-rc7-CI-Trybot_4252+ #1
<7> [1857.940081] Hardware name: Intel Corporation Ice Lake Client
Platform/IceLake U DDR4 SODIMM PD RVP, BIOS
ICLSFWR1.R00.3121.A00.1903190527 03/19/2019
<7> [1857.940083] Call Trace:
<7> [1857.940091] dump_stack+0x67/0x9b
<7> [1857.940099] drm_fb_helper_restore_fbdev_mode_unlocked+0xda/0xf0
<7> [1857.940104] drm_fb_helper_set_par+0x24/0x50
<7> [1857.940188] intel_fbdev_set_par+0x11/0x40 [i915]
<7> [1857.940197] fb_set_var+0x17a/0x3f0
<7> [1857.940212] ? __lock_acquire+0x49f/0x1590
<7> [1857.940230] fbcon_blank+0x192/0x2e0
<7> [1857.940235] ?
[Bug 108893] Slow redrawing of menu in Gothic 2 under wine
https://bugs.freedesktop.org/show_bug.cgi?id=108893 --- Comment #14 from andrew.m.mcma...@gmail.com --- (In reply to supercoolemail from comment #13) > You are lucky. I have this: > https://imgur.com/a/YTDyAXv Yes that is horrible :( Your Ryzen + RX580 should blow my old Phenom II + R9 285 out of the water. The only way I'm able to intentionally destroy the performance of Gothic 2 is to do the following: export LIBGL_ALWAYS_SOFTWARE=1 export GALLIUM_DRIVER=llvmpipe WINEDEBUG=+fps WINEPREFIX=~/.wineprefix/gothic2gold/ wine ~/.wineprefix/gothic2gold/drive_c/Gothic2Gold/system/Gothic2.exe https://imgur.com/a/rldthLI Or I can use softpipe which is even worse plus I get the laggy main menu: https://imgur.com/a/JwCnegN I'm sure you've already enabled 32 bit support in your distro: https://wiki.debian.org/Multiarch/HOWTO https://wiki.archlinux.org/index.php/Official_repositories#Enabling_multilib And installed all x64 and x86 Mesa related packages and firmware i.e: https://www.archlinux.org/packages/multilib/x86_64/lib32-mesa/ https://packages.debian.org/buster/firmware-amd-graphics Maybe you've exported some funny settings that you might have forgotten about? Here's my /etc/environment file: https://pastebin.com/vqMfCTVm -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110605] "*ERROR* Waiting for fences timed out." happens every time when I select "Story" in the main game menu RE2.
https://bugs.freedesktop.org/show_bug.cgi?id=110605 --- Comment #5 from mikhail.v.gavri...@gmail.com --- Created attachment 144160 --> https://bugs.freedesktop.org/attachment.cgi?id=144160=edit ./umr -O many,bits -r *.*.mmCP_PFP_HEADER_DUMP -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110605] "*ERROR* Waiting for fences timed out." happens every time when I select "Story" in the main game menu RE2.
https://bugs.freedesktop.org/show_bug.cgi?id=110605 --- Comment #6 from mikhail.v.gavri...@gmail.com --- Created attachment 144161 --> https://bugs.freedesktop.org/attachment.cgi?id=144161=edit ./umr -O many,bits -r *.*.mmCP_ME_HEADER_DUMP -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 12/17] kunit: tool: add Python wrappers for running KUnit tests
On Fri, May 03, 2019 at 04:14:49PM -0700, Brendan Higgins wrote: > In any case, it sounds like you and Greg are in agreement on the core > libraries generating the output in TAP13, so I won't argue that point > further. Great! > ## Analysis of using TAP13 > > One of my earlier concerns was that TAP13 is a bit over constrained > for what I would like to output from the KUnit core. It only allows > data to be output as either: > - test number > - ok/not ok with single line description > - directive > - diagnostics > - YAML block > > The test number must become before a set of ok/not ok lines, and does > not contain any additional information. One annoying thing about this > is it doesn't provide any kind of nesting or grouping. It should handle nesting just fine, I think we do that already today. > There is one ok/not ok line per test and it may have a short > description of the test immediately after 'ok' or 'not ok'; this is > problematic because it wants the first thing you say about a test to > be after you know whether it passes or not. Take a look at the output of our current tests, I think you might find it to be a bit more flexible than you think. Also, this isn't our standard, we picked it because we needed a standard that the tools of today already understand. It might have issues and other problems, but we are not in the business of writing test output parsing tools, and we don't want to force everyone out there to write custom parsers. We want them to be able to use the tools they already have so they can test the kernel, and to do so as easily as possible. thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110605] "*ERROR* Waiting for fences timed out." happens every time when I select "Story" in the main game menu RE2.
https://bugs.freedesktop.org/show_bug.cgi?id=110605 --- Comment #4 from mikhail.v.gavri...@gmail.com --- Created attachment 144159 --> https://bugs.freedesktop.org/attachment.cgi?id=144159=edit ./umr -O many,bits -r *.*.mmCP_EOP_* -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110605] "*ERROR* Waiting for fences timed out." happens every time when I select "Story" in the main game menu RE2.
https://bugs.freedesktop.org/show_bug.cgi?id=110605 --- Comment #3 from mikhail.v.gavri...@gmail.com --- Created attachment 144158 --> https://bugs.freedesktop.org/attachment.cgi?id=144158=edit ./umr -O many,bits -r *.*.mmGRBM_STATUS* -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110605] "*ERROR* Waiting for fences timed out." happens every time when I select "Story" in the main game menu RE2.
https://bugs.freedesktop.org/show_bug.cgi?id=110605 --- Comment #2 from mikhail.v.gavri...@gmail.com --- Created attachment 144157 --> https://bugs.freedesktop.org/attachment.cgi?id=144157=edit ./umr -R gfx[.] -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110605] "*ERROR* Waiting for fences timed out." happens every time when I select "Story" in the main game menu RE2.
https://bugs.freedesktop.org/show_bug.cgi?id=110605 --- Comment #1 from mikhail.v.gavri...@gmail.com --- Created attachment 144156 --> https://bugs.freedesktop.org/attachment.cgi?id=144156=edit ./umr -O halt_waves -wa -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 16/17] kernel/sysctl-test: Add null pointer test for sysctl.c:proc_dointvec()
On Fri, May 03, 2019 at 04:41:10PM -0700, Brendan Higgins wrote: > > On Thu, May 02, 2019 at 11:45:43AM -0700, Brendan Higgins wrote: > > > On Thu, May 2, 2019 at 11:15 AM wrote: > > > > > > > > > > > > > > > > > -Original Message- > > > > > From: Greg KH > > > > > > > > > > On Wed, May 01, 2019 at 04:01:25PM -0700, Brendan Higgins wrote: > > > > > > From: Iurii Zaikin > > > > > > > > > > > > KUnit tests for initialized data behavior of proc_dointvec that is > > > > > > explicitly checked in the code. Includes basic parsing tests > > > > > > including > > > > > > int min/max overflow. > > > > > > > > > > > > Signed-off-by: Iurii Zaikin > > > > > > Signed-off-by: Brendan Higgins > > > > > > --- > > > > > > kernel/Makefile | 2 + > > > > > > kernel/sysctl-test.c | 292 > > > > > +++ > > > > > > lib/Kconfig.debug| 6 + > > > > > > 3 files changed, 300 insertions(+) > > > > > > create mode 100644 kernel/sysctl-test.c > > > > > > > > > > > > diff --git a/kernel/Makefile b/kernel/Makefile > > > > > > index 6c57e78817dad..c81a8976b6a4b 100644 > > > > > > --- a/kernel/Makefile > > > > > > +++ b/kernel/Makefile > > > > > > @@ -112,6 +112,8 @@ obj-$(CONFIG_HAS_IOMEM) += iomem.o > > > > > > obj-$(CONFIG_ZONE_DEVICE) += memremap.o > > > > > > obj-$(CONFIG_RSEQ) += rseq.o > > > > > > > > > > > > +obj-$(CONFIG_SYSCTL_KUNIT_TEST) += sysctl-test.o > > > > > > > > > > You are going to have to have a "standard" naming scheme for test > > > > > modules, are you going to recommend "foo-test" over "test-foo"? If > > > > > so, > > > > > that's fine, we should just be consistant and document it somewhere. > > > > > > > > > > Personally, I'd prefer "test-foo", but that's just me, naming is > > > > > hard... > > > > > > > > My preference would be "test-foo" as well. Just my 2 cents. > > > > > > I definitely agree we should be consistent. My personal bias > > > (unsurprisingly) is "foo-test," but this is just because that is the > > > convention I am used to in other projects I have worked on. > > > > > > On an unbiased note, we are currently almost evenly split between the > > > two conventions with *slight* preference for "foo-test": I ran the two > > > following grep commands on v5.1-rc7: > > > > > > grep -Hrn --exclude-dir="build" -e "config [a-zA-Z_0-9]\+_TEST$" | wc -l > > > grep -Hrn --exclude-dir="build" -e "config TEST_[a-zA-Z_0-9]\+" | wc -l > > > > > > "foo-test" has 36 occurrences. > > > "test-foo" has 33 occurrences. > > > > > > The things I am more concerned about is how this would affect file > > > naming. If we have a unit test for foo.c, I think foo_test.c is more > > > consistent with our namespacing conventions. The other thing, is if we > > > already have a Kconfig symbol called FOO_TEST (or TEST_FOO) what > > > should we name the KUnit test in this case? FOO_UNIT_TEST? > > > FOO_KUNIT_TEST, like I did above? > > > > Ok, I can live with "foo-test", as you are right, in a directory listing > > and config option, it makes more sense to add it as a suffix. > > Cool, so just for future reference, if we already have a Kconfig > symbol called FOO_TEST (or TEST_FOO) what should we name the KUnit > test in this case? FOO_UNIT_TEST? FOO_KUNIT_TEST, like I did above? FOO_KUNIT_TEST is fine, I doubt that's going to come up very often. thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110605] "*ERROR* Waiting for fences timed out." happens every time when I select "Story" in the main game menu RE2.
https://bugs.freedesktop.org/show_bug.cgi?id=110605 Bug ID: 110605 Summary: "*ERROR* Waiting for fences timed out." happens every time when I select "Story" in the main game menu RE2. Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: mikhail.v.gavri...@gmail.com Created attachment 144155 --> https://bugs.freedesktop.org/attachment.cgi?id=144155=edit dmesg $ inxi -bM System:Host: localhost.localdomain Kernel: 5.1.0-0.rc7.git3.1.fc31.x86_64 x86_64 bits: 64 Desktop: Gnome 3.32.1 Distro: Fedora release 31 (Rawhide) Machine: Type: Desktop Mobo: ASUSTeK model: ROG STRIX X470-I GAMING v: Rev 1.xx serial: UEFI: American Megatrends v: 2202 date: 04/11/2019 CPU: 8-Core: AMD Ryzen 7 2700X type: MT MCP speed: 2106 MHz min/max: 2200/3700 MHz Graphics: Device-1: Advanced Micro Devices [AMD/ATI] Vega 20 [Radeon VII] driver: amdgpu v: kernel Display: wayland server: Fedora Project X.org 1.20.4 driver: amdgpu resolution: 3840x2160~60Hz OpenGL: renderer: AMD Radeon VII (VEGA20 DRM 3.30.0 5.1.0-0.rc7.git3.1.fc31.x86_64 LLVM 8.0.0) v: 4.5 Mesa 19.0.3 Network: Device-1: Intel I211 Gigabit Network driver: igb Device-2: Realtek RTL8822BE 802.11a/b/g/n/ac WiFi adapter driver: r8822be Drives:Local Storage: total: 11.57 TiB used: 7.59 TiB (65.6%) Info: Processes: 469 Uptime: 33m Memory: 31.31 GiB used: 16.16 GiB (51.6%) Shell: bash inxi: 3.0.32 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v8 01/10] drm: Add HDR source metadata property
On 2019-04-09 18:44, Uma Shankar wrote:
> This patch adds a blob property to get HDR metadata
> information from userspace. This will be send as part
> of AVI Infoframe to panel.
>
> It also implements get() and set() functions for HDR output
> metadata property.The blob data is received from userspace and
> saved in connector state, the same is returned as blob in get
> property call to userspace.
>
> v2: Rebase and modified the metadata structure elements
> as per Ville's POC changes.
>
> v3: No Change
>
> v4: Addressed Shashank's review comments
>
> v5: Rebase.
>
> v6: Addressed Brian Starkey's review comments, defined
> new structure with header for dynamic metadata scalability.
> Merge get/set property functions for metadata in this patch.
>
> v7: Addressed Jonas Karlman review comments and defined separate
> structure for infoframe to better align with CTA 861.G spec. Added
> Shashank's RB.
>
> Signed-off-by: Uma Shankar
> Reviewed-by: Shashank Sharma
> ---
> drivers/gpu/drm/drm_atomic.c | 2 ++
> drivers/gpu/drm/drm_atomic_uapi.c | 13 +
> drivers/gpu/drm/drm_connector.c | 6 ++
> include/drm/drm_connector.h | 11 +++
> include/drm/drm_mode_config.h | 6 ++
> include/linux/hdmi.h | 10 ++
> include/uapi/drm/drm_mode.h | 39
> +++
> 7 files changed, 87 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 5eb4013..8b9c126 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -881,6 +881,8 @@ static void drm_atomic_connector_print_state(struct
> drm_printer *p,
>
> drm_printf(p, "connector[%u]: %s\n", connector->base.id,
> connector->name);
> drm_printf(p, "\tcrtc=%s\n", state->crtc ? state->crtc->name :
> "(null)");
> + drm_printf(p, "\thdr_metadata_changed=%d\n",
> +state->hdr_metadata_changed);
>
> if (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK)
> if (state->writeback_job && state->writeback_job->fb)
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index ea797d4..6d0d161 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -673,6 +673,8 @@ static int drm_atomic_connector_set_property(struct
> drm_connector *connector,
> {
> struct drm_device *dev = connector->dev;
> struct drm_mode_config *config = >mode_config;
> + bool replaced = false;
> + int ret;
>
> if (property == config->prop_crtc_id) {
> struct drm_crtc *crtc = drm_crtc_find(dev, NULL, val);
> @@ -721,6 +723,14 @@ static int drm_atomic_connector_set_property(struct
> drm_connector *connector,
>*/
> if (state->link_status != DRM_LINK_STATUS_GOOD)
> state->link_status = val;
> + } else if (property == config->hdr_output_metadata_property) {
> + ret = drm_atomic_replace_property_blob_from_id(dev,
> + >hdr_output_metadata_blob_ptr,
> + val,
> + -1, sizeof(struct hdr_output_metadata),
> + );
> + state->hdr_metadata_changed |= replaced;
> + return ret;
> } else if (property == config->aspect_ratio_property) {
> state->picture_aspect_ratio = val;
> } else if (property == config->content_type_property) {
> @@ -807,6 +817,9 @@ static int drm_atomic_connector_set_property(struct
> drm_connector *connector,
> *val = state->colorspace;
> } else if (property == connector->scaling_mode_property) {
> *val = state->scaling_mode;
> + } else if (property == config->hdr_output_metadata_property) {
> + *val = (state->hdr_output_metadata_blob_ptr) ?
> + state->hdr_output_metadata_blob_ptr->base.id : 0;
> } else if (property == connector->content_protection_property) {
> *val = state->content_protection;
> } else if (property == config->writeback_fb_id_property) {
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 2355124..0bdae90 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1058,6 +1058,12 @@ int drm_connector_create_standard_properties(struct
> drm_device *dev)
> return -ENOMEM;
> dev->mode_config.non_desktop_property = prop;
>
> + prop = drm_property_create(dev, DRM_MODE_PROP_BLOB,
> +"HDR_OUTPUT_METADATA", 0);
> + if (!prop)
> + return -ENOMEM;
> + dev->mode_config.hdr_output_metadata_property = prop;
> +
> return 0;
> }
>
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 02a1312..5343f60 100644
> --- a/include/drm/drm_connector.h
> +++
