[Bug 109161] Kernel crash shortly after gnome-shell login - refcount_t: increment on 0; use-after-free
https://bugs.freedesktop.org/show_bug.cgi?id=109161 Yanko Kaneti changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Yanko Kaneti --- The fix landed on Linus's tree yesterday , so closing -- 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 109238] [DC] Polaris10: Missing modes when enabling DC
https://bugs.freedesktop.org/show_bug.cgi?id=109238 Raman Gupta changed: What|Removed |Added See Also|https://bugs.freedesktop.or | |g/show_bug.cgi?id=103953| -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109238] [DC] Polaris10: Missing modes when enabling DC
https://bugs.freedesktop.org/show_bug.cgi?id=109238 Raman Gupta changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=103953 -- You are receiving this mail because: You are on the CC list for the bug. 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 103953] [DC] Polaris10: Missing modes when enabling DC
https://bugs.freedesktop.org/show_bug.cgi?id=103953 Raman Gupta changed: What|Removed |Added See Also|https://bugs.freedesktop.or | |g/show_bug.cgi?id=109238| -- 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 103953] [DC] Polaris10: Missing modes when enabling DC
https://bugs.freedesktop.org/show_bug.cgi?id=103953 Raman Gupta changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=109238 -- 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 109238] [DC] Polaris10: Missing modes when enabling DC
https://bugs.freedesktop.org/show_bug.cgi?id=109238 --- Comment #2 from Raman Gupta --- Created attachment 142993 --> https://bugs.freedesktop.org/attachment.cgi?id=142993&action=edit dmesg with modesetting -- You are receiving this mail because: You are on the CC list for the bug. 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 109238] [DC] Polaris10: Missing modes when enabling DC
https://bugs.freedesktop.org/show_bug.cgi?id=109238 --- Comment #3 from Raman Gupta --- Created attachment 142994 --> https://bugs.freedesktop.org/attachment.cgi?id=142994&action=edit dmesg without modesetting -- You are receiving this mail because: You are on the CC list for the bug. 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 109238] [DC] Polaris10: Missing modes when enabling DC
https://bugs.freedesktop.org/show_bug.cgi?id=109238 --- Comment #1 from Raman Gupta --- Created attachment 142992 --> https://bugs.freedesktop.org/attachment.cgi?id=142992&action=edit Xorg.0.log without modesetting -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109238] [DC] Polaris10: Missing modes when enabling DC
https://bugs.freedesktop.org/show_bug.cgi?id=109238 Bug ID: 109238 Summary: [DC] Polaris10: Missing modes when enabling DC Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: rocketra...@gmail.com CC: alex3...@zoho.com, cousinm...@gmail.com, dri-devel@lists.freedesktop.org, fds...@krutt.org, freedesktop-bugzi...@dominik-paulus.de Depends on: 103953 Created attachment 142991 --> https://bugs.freedesktop.org/attachment.cgi?id=142991&action=edit Xorg.0.log with modesetting +++ This bug was initially created as a clone of Bug #103953 +++ I have 3 Dell WQHD Screens (2560x1440) screens, connected to a Radeon RX580 (XFX, RX-580 GTS Black Edition, 1425 MHz 8GB). My kernel is: Linux edison 4.19.13-300.fc29.x86_64 #1 SMP Sat Dec 29 22:54:28 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux With the default boot settings, which enable amdgpu.dc, I am unable to get the native resolution on one of the three monitors. If I disable amdgpu.dc on the kernel command line, I am able to get the native resolution on all three monitors. I have attached the Xorg.0.conf.old from the startup with amdgpu.dc at the default setting, and Xorg.0.conf from the startup with amdgpu.dc=0. I have also attached the initial part of the dmesg log from both boots: dmesg-amdgpudcdefault.log : default amdgpu.dc setting (enabled) dmesg-amdgpudc0.log : amdgpu.dc=0 The only relevant difference I see between the two is that with modesetting, I see the following errors: edison kernel: amdgpu: [powerplay] Failed to retrieve minimum clocks. edison kernel: amdgpu: [powerplay] Error in phm_get_clock_info whereas without modesetting I do not see those errors. Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=103953 [Bug 103953] [DC] Polaris10: Missing modes when enabling DC -- You are receiving this mail because: You are on the CC list for the bug. 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 103953] [DC] Polaris10: Missing modes when enabling DC
https://bugs.freedesktop.org/show_bug.cgi?id=103953 Raman Gupta changed: What|Removed |Added Blocks||109238 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=109238 [Bug 109238] [DC] Polaris10: Missing modes when enabling DC -- 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 201815] Mouse Pointer Disappears when touching top of the screen
https://bugzilla.kernel.org/show_bug.cgi?id=201815 siyia (eutychio...@gmail.com) changed: What|Removed |Added Kernel Version|4.20|4.20-5.0rc1 --- Comment #11 from siyia (eutychio...@gmail.com) --- bug exists in kernel 5.0rc1 too -- 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 201727] Hardware Error reported on Ryzen 5 2500U
https://bugzilla.kernel.org/show_bug.cgi?id=201727 --- Comment #15 from tones...@hotmail.com --- Created attachment 280291 --> https://bugzilla.kernel.org/attachment.cgi?id=280291&action=edit v5.0-rc1 boot lockup Boot log running v5.0-rc1 attached -- 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 107978] [amdgpu] Switching to tty fails with DisplayPort 1.2 monitor going to sleep (REG_WAIT timeout / dce110_stream_encoder_dp_blank)
https://bugs.freedesktop.org/show_bug.cgi?id=107978 --- Comment #40 from Shmerl --- Just tested kernel 5.0-rc1, the boot problem with monitor going to sleep is still happening. Same workaround (turn the monitor off / on, switch to tty1, restart sddm) helps. -- 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 109234] amdgpu random hangs with 4.21+
https://bugs.freedesktop.org/show_bug.cgi?id=109234 --- Comment #1 from bmil...@gmail.com --- Still happens in 5.0-rc1 -- 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 107978] [amdgpu] Switching to tty fails with DisplayPort 1.2 monitor going to sleep (REG_WAIT timeout / dce110_stream_encoder_dp_blank)
https://bugs.freedesktop.org/show_bug.cgi?id=107978 --- Comment #39 from Shmerl --- FYI: the dmesg message fix should be already included in 5.0-rc1: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/amd/display/dc/core/dc_link.c?h=v5.0-rc1&id=8c9d90eebd23b6d40ddf4ce5df5ca2b932336a06 -- 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 109229] glLinkProgram locks up for ~30 seconds
https://bugs.freedesktop.org/show_bug.cgi?id=109229 --- Comment #1 from Timothy Arceri --- Can you try to bisect the commit where things chnages between 18.2 and 18.3? -- 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 101731] System freeze with AMDGPU when playing The Witcher 3 (GOG GOTY)
https://bugs.freedesktop.org/show_bug.cgi?id=101731 --- Comment #86 from Shmerl --- (In reply to Dmitry from comment #85) > This problem is still there on the new Mesa 18.3.1. On AMDLK there is no > such problem, but I would not like to use it. This bug was about radeonsi, not about Vulkan drivers. -- 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 101731] System freeze with AMDGPU when playing The Witcher 3 (GOG GOTY)
https://bugs.freedesktop.org/show_bug.cgi?id=101731 --- Comment #85 from Dmitry --- This problem is still there on the new Mesa 18.3.1. On AMDLK there is no such problem, but I would not like to use it. -- 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 109161] Kernel crash shortly after gnome-shell login - refcount_t: increment on 0; use-after-free
https://bugs.freedesktop.org/show_bug.cgi?id=109161 --- Comment #3 from mikhail.v.gavri...@gmail.com --- I am also confirm that patch https://cgit.freedesktop.org/~agd5f/linux/patch/?id=77acd1cd912987ffd62dad6a09275a1fb406f0c2 fix this. -- 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 109235] Using named pixmap of window right after resizing results in garbage content
https://bugs.freedesktop.org/show_bug.cgi?id=109235 --- Comment #1 from Yuxuan Shui --- BTW, this problem doesn't happen with intel, or proprietary nvidia drivers. -- 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 109235] Using named pixmap of window right after resizing results in garbage content
https://bugs.freedesktop.org/show_bug.cgi?id=109235 Bug ID: 109235 Summary: Using named pixmap of window right after resizing results in garbage content Product: Mesa Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: yshu...@gmail.com QA Contact: dri-devel@lists.freedesktop.org compton is a glx based compositor, when a window is resized, compton release the previously bound pixmap, and create a new named pixmap and bind that to a texture, and then render the screen with that. With the amdgpu/radeonsi driver, that sometimes result in garbage content. You can find more details, screenshot, and recordings here [1] [1]: https://github.com/yshui/compton/issues/85 -- 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 109234] amdgpu random hangs with 4.21+
https://bugs.freedesktop.org/show_bug.cgi?id=109234 Bug ID: 109234 Summary: amdgpu random hangs with 4.21+ 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: bmil...@gmail.com This bug happens for me like once a day, at seemingly random times with latest kernel from torvalds tree. Last merge was yesterday https://github.com/torvalds/linux/commit/0fe4e2d5cd931ad2ff99d61cfdd5c6dc0c3ec60b but in the previous drm merge the bug was also present. System:Host: mjb Kernel: 4.20.0-1-tkg-cfs x86_64 bits: 64 Desktop: KDE Plasma 5.14.4 Distro: Manjaro Linux Machine: Type: Desktop Mobo: ASUSTeK model: TUF B450M-PLUS GAMING v: Rev X.0x serial: UEFI: American Megatrends v: 0601 date: 10/29/2018 CPU: 6-Core: AMD Ryzen 5 2600 type: MT MCP speed: 3885 MHz min/max: 1550/3900 MHz Graphics: Device-1: Advanced Micro Devices [AMD/ATI] Ellesmere [Radeon RX 470/480/570/570X/580/580X] driver: amdgpu v: kernel Display: x11 server: X.Org 1.20.3 driver: amdgpu resolution: 1920x1080~60Hz OpenGL: renderer: Radeon RX 580 Series (POLARIS10 DRM 3.27.0 4.21.0-torvaldsgit LLVM 8.0.0) v: 4.5 Mesa 19.0.0-devel (git-8847370424) Network: Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169 Drives:Local Storage: total: 1.59 TiB used: 283.09 GiB (17.3%) Info: Processes: 262 Uptime: 6m Memory: 15.66 GiB used: 1.22 GiB (7.8%) Shell: zsh inxi: 3.0.28 dmesg from previous boot always shows a trace like this: jan 06 18:37:32 mjb kernel: general protection fault: [#1] PREEMPT SMP NOPTI jan 06 18:37:32 mjb kernel: CPU: 4 PID: 676 Comm: Xorg:cs0 Tainted: G O 4.21.0-torvaldsgit #1 jan 06 18:37:32 mjb kernel: Hardware name: System manufacturer System Product Name/TUF B450M-PLUS GAMING, BIOS 0601 10/29/2018 jan 06 18:37:32 mjb kernel: RIP: 0010:__memcpy+0x12/0x20 jan 06 18:37:32 mjb kernel: Code: 48 89 c8 e9 f9 fc ff ff 48 89 f0 e9 f1 fc ff ff 90 90 90 90 90 90 90 90 0f 1f 44 00 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 48 a5 89 d1 f3 a4 c3 66> jan 06 18:37:32 mjb kernel: RSP: 0018:c9000327bc30 EFLAGS: 00010246 jan 06 18:37:32 mjb kernel: RAX: a0050f003b80 RBX: 888105fdb0b0 RCX: 0200 jan 06 18:37:32 mjb kernel: RDX: RSI: 8880d3369000 RDI: a0050f003b80 jan 06 18:37:32 mjb kernel: RBP: R08: R09: 01cc jan 06 18:37:32 mjb kernel: R10: R11: 8883fa6a4828 R12: 1000 jan 06 18:37:32 mjb kernel: R13: R14: d3369000 R15: 88840bf6fb28 jan 06 18:37:32 mjb kernel: FS: 7fc0419a4700() GS:88840eb0() knlGS: jan 06 18:37:32 mjb kernel: CS: 0010 DS: ES: CR0: 80050033 jan 06 18:37:32 mjb kernel: CS: 0010 DS: ES: CR0: 80050033 jan 06 18:37:32 mjb kernel: CR2: 7fa2d142d210 CR3: 00040108 CR4: 003406e0 jan 06 18:37:32 mjb kernel: Call Trace: jan 06 18:37:32 mjb kernel: dma_direct_unmap_page+0x92/0xa0 jan 06 18:37:32 mjb kernel: ttm_unmap_and_unpopulate_pages+0x148/0x170 [ttm] jan 06 18:37:32 mjb kernel: ttm_tt_destroy+0x81/0xd0 [ttm] jan 06 18:37:32 mjb kernel: ttm_bo_put+0x25e/0x2f0 [ttm] jan 06 18:37:32 mjb kernel: amdgpu_bo_unref+0x1a/0x30 [amdgpu] jan 06 18:37:32 mjb kernel: amdgpu_gem_object_free+0x23/0x30 [amdgpu] jan 06 18:37:32 mjb kernel: drm_gem_handle_delete+0x9b/0x130 [drm] jan 06 18:37:32 mjb kernel: ? drm_gem_handle_create+0x40/0x40 [drm] jan 06 18:37:32 mjb kernel: drm_ioctl_kernel+0x8b/0xd0 [drm] jan 06 18:37:32 mjb kernel: drm_ioctl+0x1e5/0x390 [drm] jan 06 18:37:32 mjb kernel: ? drm_gem_handle_create+0x40/0x40 [drm] jan 06 18:37:32 mjb kernel: ? tlb_finish_mmu+0x1f/0x30 jan 06 18:37:32 mjb kernel: ? unmap_region+0xc9/0xf0 jan 06 18:37:32 mjb kernel: amdgpu_drm_ioctl+0x49/0x80 [amdgpu] jan 06 18:37:32 mjb kernel: do_vfs_ioctl+0x97/0x720 jan 06 18:37:32 mjb kernel: ? __do_munmap.constprop.9+0x263/0x3a0 jan 06 18:37:32 mjb kernel: __x64_sys_ioctl+0x62/0x90 jan 06 18:37:32 mjb kernel: do_syscall_64+0x55/0x100 jan 06 18:37:32 mjb kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 jan 06 18:37:32 mjb kernel: RIP: 0033:0x7fc04ba0580b jan 06 18:37:32 mjb kernel: Code: 0f 1e fa 48 8b 05 55 b6 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3> jan 06 18:37:32 mjb kernel: RSP: 002b:7fc0419a3968 EFLAGS: 0246 ORIG_RAX: 0010 jan 06 18:37:32 mjb kernel: RAX: ffda RBX: 562b657e9710 RCX: 7fc04ba0580b jan 06 18:37:32 mjb kernel: RDX: 7fc0419a39a0 RSI: 40086409 RDI: 000e jan 06 18:37:32
Re: [PATCH libdrm] amdgpu: Allow amdgpu device creation without merging fds.
On Sun, Jan 6, 2019 at 9:23 PM Christian König wrote: > > Am 06.01.19 um 10:46 schrieb Bas Nieuwenhuizen: > > For radv we want to be able to pass in a master fd and be sure that > > the created libdrm_amdgpu device also uses that master fd, so we can > > use it for prioritized submission. > > > > radv does all interaction with other APIs/processes with dma-bufs, > > so we should not need the functionality in libdrm_amdgpu to only have > > a single fd for a device in the process. > > > > Signed-off-by: Bas Nieuwenhuizen > > Well NAK. > > This breaks a couple of design assumptions we used for the kernel driver > and is strongly discouraged. What assumptions are these? As far as I can tell everything is per drm fd, not process? > > Instead radv should not use the master fd for command submission. High priority submission needs to be done through a master fd, so not using a master fd is not an option ... > > Regards, > Christian. > > > > --- > > amdgpu/amdgpu-symbol-check | 1 + > > amdgpu/amdgpu.h| 37 > > amdgpu/amdgpu_device.c | 59 -- > > 3 files changed, 76 insertions(+), 21 deletions(-) > > > > diff --git a/amdgpu/amdgpu-symbol-check b/amdgpu/amdgpu-symbol-check > > index 6f5e0f95..bbf48985 100755 > > --- a/amdgpu/amdgpu-symbol-check > > +++ b/amdgpu/amdgpu-symbol-check > > @@ -56,6 +56,7 @@ amdgpu_cs_wait_fences > > amdgpu_cs_wait_semaphore > > amdgpu_device_deinitialize > > amdgpu_device_initialize > > +amdgpu_device_initialize2 > > amdgpu_find_bo_by_cpu_mapping > > amdgpu_get_marketing_name > > amdgpu_query_buffer_size_alignment > > diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h > > index dc51659a..e5ed39bb 100644 > > --- a/amdgpu/amdgpu.h > > +++ b/amdgpu/amdgpu.h > > @@ -66,6 +66,13 @@ struct drm_amdgpu_info_hw_ip; > >*/ > > #define AMDGPU_QUERY_FENCE_TIMEOUT_IS_ABSOLUTE (1 << 0) > > > > +/** > > + * Uses in amdgpu_device_initialize2(), meaning that the passed in fd > > should > > + * not be deduplicated against other libdrm_amdgpu devices referring to > > the > > + * same kernel device. > > + */ > > +#define AMDGPU_DEVICE_DEDICATED_FD (1 << 0) > > + > > > > /*--*/ > > /* - Enums > > */ > > > > /*--*/ > > @@ -526,6 +533,36 @@ int amdgpu_device_initialize(int fd, > >uint32_t *minor_version, > >amdgpu_device_handle *device_handle); > > > > +/** > > + * > > + * \param fd- \c [in] File descriptor for AMD GPU device > > + * received previously as the result of > > + * e.g. drmOpen() call. > > + * For legacy fd type, the DRI2/DRI3 > > + * authentication should be done before > > + * calling this function. > > + * \param flags - \c [in] Bitmask of flags for device creation. > > + * \param major_version - \c [out] Major version of library. It is > > assumed > > + * that adding new functionality will > > cause > > + * increase in major version > > + * \param minor_version - \c [out] Minor version of library > > + * \param device_handle - \c [out] Pointer to opaque context which should > > + * be passed as the first parameter on > > each > > + * API call > > + * > > + * > > + * \return 0 on success\n > > + * <0 - Negative POSIX Error code > > + * > > + * > > + * \sa amdgpu_device_deinitialize() > > +*/ > > +int amdgpu_device_initialize2(int fd, > > + uint32_t flags, > > + uint32_t *major_version, > > + uint32_t *minor_version, > > + amdgpu_device_handle *device_handle); > > + > > /** > >* > >* When access to such library does not needed any more the special > > diff --git a/amdgpu/amdgpu_device.c b/amdgpu/amdgpu_device.c > > index 362494b1..b4bf3f76 100644 > > --- a/amdgpu/amdgpu_device.c > > +++ b/amdgpu/amdgpu_device.c > > @@ -100,7 +100,8 @@ static void > > amdgpu_device_free_internal(amdgpu_device_handle dev) > > pthread_mutex_lock(&fd_mutex); > > while (*node != dev && (*node)->next) > > node = &(*node)->next; > > - *node = (*node)->next; > > + if (*node == dev) > > + *node = (*node)->next; > > pthread_mutex_unlock(&fd_mutex); > > > > close(dev->fd); > > @@ -144,6 +145,16 @@ drm_public int amdgpu_device_initialize(int fd, > > uint32_t *major_version, > >
Re: [PATCH libdrm] amdgpu: Allow amdgpu device creation without merging fds.
Am 06.01.19 um 10:46 schrieb Bas Nieuwenhuizen:
For radv we want to be able to pass in a master fd and be sure that
the created libdrm_amdgpu device also uses that master fd, so we can
use it for prioritized submission.
radv does all interaction with other APIs/processes with dma-bufs,
so we should not need the functionality in libdrm_amdgpu to only have
a single fd for a device in the process.
Signed-off-by: Bas Nieuwenhuizen
Well NAK.
This breaks a couple of design assumptions we used for the kernel driver
and is strongly discouraged.
Instead radv should not use the master fd for command submission.
Regards,
Christian.
---
amdgpu/amdgpu-symbol-check | 1 +
amdgpu/amdgpu.h| 37
amdgpu/amdgpu_device.c | 59 --
3 files changed, 76 insertions(+), 21 deletions(-)
diff --git a/amdgpu/amdgpu-symbol-check b/amdgpu/amdgpu-symbol-check
index 6f5e0f95..bbf48985 100755
--- a/amdgpu/amdgpu-symbol-check
+++ b/amdgpu/amdgpu-symbol-check
@@ -56,6 +56,7 @@ amdgpu_cs_wait_fences
amdgpu_cs_wait_semaphore
amdgpu_device_deinitialize
amdgpu_device_initialize
+amdgpu_device_initialize2
amdgpu_find_bo_by_cpu_mapping
amdgpu_get_marketing_name
amdgpu_query_buffer_size_alignment
diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
index dc51659a..e5ed39bb 100644
--- a/amdgpu/amdgpu.h
+++ b/amdgpu/amdgpu.h
@@ -66,6 +66,13 @@ struct drm_amdgpu_info_hw_ip;
*/
#define AMDGPU_QUERY_FENCE_TIMEOUT_IS_ABSOLUTE (1 << 0)
+/**
+ * Uses in amdgpu_device_initialize2(), meaning that the passed in fd should
+ * not be deduplicated against other libdrm_amdgpu devices referring to the
+ * same kernel device.
+ */
+#define AMDGPU_DEVICE_DEDICATED_FD (1 << 0)
+
/*--*/
/* - Enums */
/*--*/
@@ -526,6 +533,36 @@ int amdgpu_device_initialize(int fd,
uint32_t *minor_version,
amdgpu_device_handle *device_handle);
+/**
+ *
+ * \param fd- \c [in] File descriptor for AMD GPU device
+ * received previously as the result of
+ * e.g. drmOpen() call.
+ * For legacy fd type, the DRI2/DRI3
+ * authentication should be done before
+ * calling this function.
+ * \param flags - \c [in] Bitmask of flags for device creation.
+ * \param major_version - \c [out] Major version of library. It is assumed
+ * that adding new functionality will cause
+ * increase in major version
+ * \param minor_version - \c [out] Minor version of library
+ * \param device_handle - \c [out] Pointer to opaque context which should
+ * be passed as the first parameter on each
+ * API call
+ *
+ *
+ * \return 0 on success\n
+ * <0 - Negative POSIX Error code
+ *
+ *
+ * \sa amdgpu_device_deinitialize()
+*/
+int amdgpu_device_initialize2(int fd,
+ uint32_t flags,
+ uint32_t *major_version,
+ uint32_t *minor_version,
+ amdgpu_device_handle *device_handle);
+
/**
*
* When access to such library does not needed any more the special
diff --git a/amdgpu/amdgpu_device.c b/amdgpu/amdgpu_device.c
index 362494b1..b4bf3f76 100644
--- a/amdgpu/amdgpu_device.c
+++ b/amdgpu/amdgpu_device.c
@@ -100,7 +100,8 @@ static void
amdgpu_device_free_internal(amdgpu_device_handle dev)
pthread_mutex_lock(&fd_mutex);
while (*node != dev && (*node)->next)
node = &(*node)->next;
- *node = (*node)->next;
+ if (*node == dev)
+ *node = (*node)->next;
pthread_mutex_unlock(&fd_mutex);
close(dev->fd);
@@ -144,6 +145,16 @@ drm_public int amdgpu_device_initialize(int fd,
uint32_t *major_version,
uint32_t *minor_version,
amdgpu_device_handle *device_handle)
+{
+ return amdgpu_device_initialize2(fd, 0, major_version, minor_version,
+device_handle);
+}
+
+drm_public int amdgpu_device_initialize2(int fd,
+uint32_t flags,
+uint32_t *major_version,
+uint32_t *minor_version,
+amdgpu_device_handle *device_handle)
{
struct amdgpu_device *dev;
drmVersionPtr version;
@@ -164,26 +1
[Bug 109232] Raven Ridge with ABM enabled turns display off erroneously on mostly black colored windows
https://bugs.freedesktop.org/show_bug.cgi?id=109232 --- Comment #2 from Samantha McVey --- I logged the actual and brightness settings with 1 second delay: actual: 771 brightness: 0 abm level: 0 actual: 771 brightness: 0 abm level: 0 actual: 771 brightness: 0 abm level: 0 actual: 771 brightness: 0 abm level: 0 ABM is turned to 4 /* Screen is on initially, but */ actual: 593 brightness: 0 abm level: 4 actual: 428 brightness: 0 abm level: 4 /* About here the screen is basically off */ actual: 368 brightness: 0 abm level: 4 actual: 339 brightness: 0 abm level: 4 -- 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 109232] Raven Ridge with ABM enabled turns display off erroneously on mostly black colored windows
https://bugs.freedesktop.org/show_bug.cgi?id=109232 Bug ID: 109232 Summary: Raven Ridge with ABM enabled turns display off erroneously on mostly black colored windows 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: samant...@posteo.net Created attachment 142986 --> https://bugs.freedesktop.org/attachment.cgi?id=142986&action=edit xorg log With ABM off and brightness at the minimum (0), the screen is on but low brightness. If you set ABM to 4 and then maximize a black terminal window, the screen will for all intents and purposes turn itself off. When going back to a bright screen it will turn on again. By on and off here I don't mean actually off, but the brightness is almost not visible. I am using a Lenovo A485 -- 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 109232] Raven Ridge with ABM enabled turns display off erroneously on mostly black colored windows
https://bugs.freedesktop.org/show_bug.cgi?id=109232 --- Comment #1 from Samantha McVey --- Created attachment 142987 --> https://bugs.freedesktop.org/attachment.cgi?id=142987&action=edit dmesg log -- 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 v6 2/2] drm/panel: Add Sitronix ST7701 panel driver
On Sat, Dec 15, 2018 at 2:16 AM Jagan Teki wrote: > > ST7701 designed for small and medium sizes of TFT LCD display, is > capable of supporting up to 480RGBX864 in resolution. It provides > several system interfaces like MIPI/RGB/SPI. > > Currently added support for Techstar TS8550B which is ST7701 based > 480x854, 2-lane MIPI DSI LCD panel. > > Driver now registering mipi_dsi device, but indeed it can extendable > for RGB if any requirement trigger in future. > > Signed-off-by: Jagan Teki > --- > Changes for v6: > - use sleep delay value as per datasheet > - add panel_sleep_delay variable for panel specific delay > - use command sequnce display on and off instead panel > functions > - add proper comments on the delays > - remove delays from command switch > - move mode type on struct display mode > - drop refresh rate value, let drm compute > Changes for v5: > - found the chip from vendor, so added new panel driver > - here is v4: https://patchwork.kernel.org/patch/10680335/ Any comments? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 07/17] drm/sun4i: sun6i_mipi_dsi: Refactor vertical video start delay
On Fri, Dec 21, 2018 at 2:26 AM Jagan Teki wrote: > > On Tue, Dec 11, 2018 at 10:19 PM Maxime Ripard > wrote: > > > > On Mon, Dec 10, 2018 at 09:47:19PM +0530, Jagan Teki wrote: > > > Video start delay can be computed by subtracting total vertical > > > timing with front porch timing and with adding 1 delay line for TCON. > > > > > > BSP code form BPI-M64-bsp is computing video start delay as > > > (from linux-sunxi/ > > > drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c) > > > > > > u32 vfp = panel->lcd_vt - panel->lcd_y - panel->lcd_vbp; > > > => (panel->lcd_vt) - panel->lcd_y - (panel->lcd_vbp) > > > => (timmings->ver_front_porch + panel->lcd_vbp + panel->lcd_y) > > >- panel->lcd_y - (panel->lcd_vbp) > > > => timmings->ver_front_porch + panel->lcd_vbp + panel->lcd_y > > >- panel->lcd_y - panel->lcd_vbp > > > => timmings->ver_front_porch > > > > > > So, update the start delay computation accordingly. > > > > > > Signed-off-by: Jagan Teki > > > > Even though it's a bit better now on my A33 board and I don't have the > > white stripes on the bottom of the display, there's still some > > flickering with your patches applied. > > > > Bisecting it seems to point at that patch, but reverting it doesn't > > make the issue go away, so it's not really clear which one exactly is > > at fault. > > Is reverting this patch, work fine or not? > > This patch is trying to make use of front porch instead of existing > back porch to compute the delay. Since we revert the VBP fix patch[1] > to assume VBP as VFP value look like your setup would also require to > revert this change. But as per BSP or drm_mode details all of my > displays even work with and w/o reverting these two. > > I'm thinking your display should work in the same behavior since the > dsi controller making this route. Any further comments on this? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/2] drm/panel: Add Feiyang FY07024DI26A30-D MIPI-DSI LCD panel
On Thu, Dec 20, 2018 at 10:34 PM Sean Paul wrote:
>
> On Tue, Dec 18, 2018 at 05:06:38PM +0530, Jagan Teki wrote:
> > On Sat, Dec 15, 2018 at 3:32 AM Sean Paul wrote:
> > >
> > > On Sat, Dec 15, 2018 at 02:11:01AM +0530, Jagan Teki wrote:
> > > > Feiyang FY07024DI26A30-D is 1024x600, 4-lane MIPI-DSI LCD panel.
> > > >
> > > > Add panel driver for it.
> > > >
> > > > Signed-off-by: Jagan Teki
> > > > ---
> > > > Changes for v2:
> > > > - use simple structure for command init
> > > > - update proper comments on power, reset delay sequnce
> > > > - fix to use set_display_off in disable function
> > > > - move mode type to structure
> > > > - drop refres rate value, let drm compute
> > > >
> > > > MAINTAINERS | 6 +
> > > > drivers/gpu/drm/panel/Kconfig | 9 +
> > > > drivers/gpu/drm/panel/Makefile| 1 +
> > > > .../drm/panel/panel-feiyang-fy07024di26a30d.c | 296 ++
> > > > 4 files changed, 312 insertions(+)
> > > > create mode 100644
> > > > drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
> > > >
> > > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > > index d2928a4d2847..e643238855ea 100644
> > > > --- a/MAINTAINERS
> > > > +++ b/MAINTAINERS
> > > > @@ -4732,6 +4732,12 @@ T: git
> > > > git://anongit.freedesktop.org/drm/drm-misc
> > > > S: Maintained
> > > > F: drivers/gpu/drm/tve200/
> > > >
> > > > +DRM DRIVER FOR FEIYANG FY07024DI26A30-D MIPI-DSI LCD PANELS
> > > > +M: Jagan Teki
> > > > +S: Maintained
> > > > +F: drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
> > > > +F:
> > > > Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.txt
> > > > +
> > > > DRM DRIVER FOR ILITEK ILI9225 PANELS
> > > > M: David Lechner
> > > > S: Maintained
> > >
> > > As I mentioned on IRC, this will be drm-misc maintained with the other
> > > panels,
> > > no need to have a dedicated MAINTAINERS entry. You'll get pulled from
> > > get_maintainers.pl as a majority commit signer
> >
> > This I missed it on IRC, sorry will drop.
> >
> > >
> > > > diff --git a/drivers/gpu/drm/panel/Kconfig
> > > > b/drivers/gpu/drm/panel/Kconfig
> > > > index d93b2ba709bc..cb8ca93550cf 100644
> > > > --- a/drivers/gpu/drm/panel/Kconfig
> > > > +++ b/drivers/gpu/drm/panel/Kconfig
> > > > @@ -38,6 +38,15 @@ config DRM_PANEL_SIMPLE
> > > > that it can be automatically turned off when the panel goes
> > > > into a
> > > > low power state.
> > > >
> > > > +config DRM_PANEL_FEIYANG_FY07024DI26A30D
> > > > + tristate "Feiyang FY07024DI26A30-D MIPI-DSI LCD panel"
> > > > + depends on OF
> > > > + depends on DRM_MIPI_DSI
> > > > + depends on BACKLIGHT_CLASS_DEVICE
> > > > + help
> > > > + Say Y if you want to enable support for panels based on the
> > > > + Feiyang FY07024DI26A30-D MIPI-DSI interface.
> > > > +
> > > > config DRM_PANEL_ILITEK_IL9322
> > > > tristate "Ilitek ILI9322 320x240 QVGA panels"
> > > > depends on OF && SPI
> > > > diff --git a/drivers/gpu/drm/panel/Makefile
> > > > b/drivers/gpu/drm/panel/Makefile
> > > > index 6a9b4cec1891..0fa0ef69e109 100644
> > > > --- a/drivers/gpu/drm/panel/Makefile
> > > > +++ b/drivers/gpu/drm/panel/Makefile
> > > > @@ -2,6 +2,7 @@
> > > > obj-$(CONFIG_DRM_PANEL_ARM_VERSATILE) += panel-arm-versatile.o
> > > > obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o
> > > > obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
> > > > +obj-$(CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D) +=
> > > > panel-feiyang-fy07024di26a30d.o
> > > > obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += panel-ilitek-ili9322.o
> > > > obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) += panel-ilitek-ili9881c.o
> > > > obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
> > > > diff --git a/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
> > > > b/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
> > > > new file mode 100644
> > > > index ..4abccbf62c3c
> > > > --- /dev/null
> > > > +++ b/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
> > > > @@ -0,0 +1,296 @@
>
> /snip
>
> > > > +static const struct drm_display_mode feiyang_default_mode = {
> > > > + .clock = 55000,
> > > > +
> > > > + .hdisplay = 1024,
> > > > + .hsync_start = 1024 + 396,
> > > > + .hsync_end = 1024 + 396 + 20,
> > > > + .htotal = 1024 + 396 + 20 + 100,
> > > > +
> > > > + .vdisplay = 600,
> > > > + .vsync_start = 600 + 12,
> > > > + .vsync_end = 600 + 12 + 2,
> > > > + .vtotal = 600 + 12 + 2 + 21,
> > >
> > > These timings are still incorrect, they'll give a 56.2Hz refresh rate. Is
> > > that
> > > really what you want?
> >
> > I would like to go with same rate as of now since BSP is using the
> > same, since I don't have any information from chip vendor(even I wrote
> > it and waiting for response). I will update accordingly once I get the
> > information from vendor.
> >
> > Let me know your
[Bug 108892] kernel BUG at kernel/time/timer.c:1137 in drm_sched_job_finish [gpu_sched]
https://bugs.freedesktop.org/show_bug.cgi?id=108892 Vik-T changed: What|Removed |Added Priority|medium |high Severity|normal |critical -- 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 108892] kernel BUG at kernel/time/timer.c:1137 in drm_sched_job_finish [gpu_sched]
https://bugs.freedesktop.org/show_bug.cgi?id=108892 Vik-T changed: What|Removed |Added CC||vik...@troja.ch --- Comment #7 from Vik-T --- Created attachment 142985 --> https://bugs.freedesktop.org/attachment.cgi?id=142985&action=edit Journalctl Output re Kernel Bug Since I upgraded to 4.19 from 4.18 about a 2 weeks, I'm experiencing the same issue, unfortunately. Sometimes once a day, sometimes several times per day. I don't always get an entry in syslog so it wasn't clear to me from the start where the problem lies. I have attached the respective log entry for your reference. I now just upgraded to 4.20 and hope the error won't appear there, too. -- 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 109217] clock management is disabled for the 4K resolution with polaris 10
https://bugs.freedesktop.org/show_bug.cgi?id=109217 --- Comment #1 from fin4...@hotmail.com --- It is the PP_OVERDRIVE_MASK bit that fixes this bug. AMD developers, use find in files for "od_enabled" and review the code in polaris 10 related files. -- 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 107694] [wine] RAGE: texture problems
https://bugs.freedesktop.org/show_bug.cgi?id=107694 --- Comment #10 from Michael Monreal --- (In reply to James B from comment #8) > Heres a video I made comparing 32/64-bit versions on my system: > https://www.youtube.com/watch?v=EUwq4dbnFkA Same results on my system (RX 580) running Ubuntu and Padoka PPA. It would be nice to be able to play the 32 bit version as it supports achievements, which the 64 bit version does not. -- 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 107694] [wine] RAGE: texture problems
https://bugs.freedesktop.org/show_bug.cgi?id=107694 --- Comment #9 from Michael Monreal --- (In reply to Sven Arvidsson from comment #6) > There's also this an entry about a similar problem on the PC Gaming Wiki The Wiki as well as many other guides recommend to set fc_maxcachememoryMB to a higher value. I noticed that on Proton, the highest value I can set is 96 (which is the default). Can this actually be set to values of 1024 and higher on Windows? -- 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
[PATCH libdrm] amdgpu: Allow amdgpu device creation without merging fds.
For radv we want to be able to pass in a master fd and be sure that
the created libdrm_amdgpu device also uses that master fd, so we can
use it for prioritized submission.
radv does all interaction with other APIs/processes with dma-bufs,
so we should not need the functionality in libdrm_amdgpu to only have
a single fd for a device in the process.
Signed-off-by: Bas Nieuwenhuizen
---
amdgpu/amdgpu-symbol-check | 1 +
amdgpu/amdgpu.h| 37
amdgpu/amdgpu_device.c | 59 --
3 files changed, 76 insertions(+), 21 deletions(-)
diff --git a/amdgpu/amdgpu-symbol-check b/amdgpu/amdgpu-symbol-check
index 6f5e0f95..bbf48985 100755
--- a/amdgpu/amdgpu-symbol-check
+++ b/amdgpu/amdgpu-symbol-check
@@ -56,6 +56,7 @@ amdgpu_cs_wait_fences
amdgpu_cs_wait_semaphore
amdgpu_device_deinitialize
amdgpu_device_initialize
+amdgpu_device_initialize2
amdgpu_find_bo_by_cpu_mapping
amdgpu_get_marketing_name
amdgpu_query_buffer_size_alignment
diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
index dc51659a..e5ed39bb 100644
--- a/amdgpu/amdgpu.h
+++ b/amdgpu/amdgpu.h
@@ -66,6 +66,13 @@ struct drm_amdgpu_info_hw_ip;
*/
#define AMDGPU_QUERY_FENCE_TIMEOUT_IS_ABSOLUTE (1 << 0)
+/**
+ * Uses in amdgpu_device_initialize2(), meaning that the passed in fd should
+ * not be deduplicated against other libdrm_amdgpu devices referring to the
+ * same kernel device.
+ */
+#define AMDGPU_DEVICE_DEDICATED_FD (1 << 0)
+
/*--*/
/* - Enums */
/*--*/
@@ -526,6 +533,36 @@ int amdgpu_device_initialize(int fd,
uint32_t *minor_version,
amdgpu_device_handle *device_handle);
+/**
+ *
+ * \param fd- \c [in] File descriptor for AMD GPU device
+ * received previously as the result of
+ * e.g. drmOpen() call.
+ * For legacy fd type, the DRI2/DRI3
+ * authentication should be done before
+ * calling this function.
+ * \param flags - \c [in] Bitmask of flags for device creation.
+ * \param major_version - \c [out] Major version of library. It is assumed
+ * that adding new functionality will cause
+ * increase in major version
+ * \param minor_version - \c [out] Minor version of library
+ * \param device_handle - \c [out] Pointer to opaque context which should
+ * be passed as the first parameter on each
+ * API call
+ *
+ *
+ * \return 0 on success\n
+ * <0 - Negative POSIX Error code
+ *
+ *
+ * \sa amdgpu_device_deinitialize()
+*/
+int amdgpu_device_initialize2(int fd,
+ uint32_t flags,
+ uint32_t *major_version,
+ uint32_t *minor_version,
+ amdgpu_device_handle *device_handle);
+
/**
*
* When access to such library does not needed any more the special
diff --git a/amdgpu/amdgpu_device.c b/amdgpu/amdgpu_device.c
index 362494b1..b4bf3f76 100644
--- a/amdgpu/amdgpu_device.c
+++ b/amdgpu/amdgpu_device.c
@@ -100,7 +100,8 @@ static void
amdgpu_device_free_internal(amdgpu_device_handle dev)
pthread_mutex_lock(&fd_mutex);
while (*node != dev && (*node)->next)
node = &(*node)->next;
- *node = (*node)->next;
+ if (*node == dev)
+ *node = (*node)->next;
pthread_mutex_unlock(&fd_mutex);
close(dev->fd);
@@ -144,6 +145,16 @@ drm_public int amdgpu_device_initialize(int fd,
uint32_t *major_version,
uint32_t *minor_version,
amdgpu_device_handle *device_handle)
+{
+ return amdgpu_device_initialize2(fd, 0, major_version, minor_version,
+device_handle);
+}
+
+drm_public int amdgpu_device_initialize2(int fd,
+uint32_t flags,
+uint32_t *major_version,
+uint32_t *minor_version,
+amdgpu_device_handle *device_handle)
{
struct amdgpu_device *dev;
drmVersionPtr version;
@@ -164,26 +175,28 @@ drm_public int amdgpu_device_initialize(int fd,
return r;
}
- for (dev = fd_list; dev; dev = dev->next)
- if (fd_compare(dev->fd, fd) == 0)
- break;
-
- if (dev) {
- r = amdgpu_get_
Re: [PATCH 2/2] fbdev: fbmem: add config option to center the bootup logo
Hi Peter,
On Mon, Nov 26, 2018 at 10:59 PM Peter Rosin wrote:
> If there are extra logos (CONFIG_FB_LOGO_EXTRA) the heights of these
> extra logos are not considered when centering the first logo vertically.
>
> Signed-off-by: Peter Rosin
> --- a/drivers/video/logo/Kconfig
> +++ b/drivers/video/logo/Kconfig
> @@ -10,6 +10,15 @@ menuconfig LOGO
>
> if LOGO
>
> +config FB_LOGO_CENTER
> + bool "Center the logo"
> + depends on FB=y
> + help
> + When this option is selected, the bootup logo is centered both
> + horizontally and vertically. If more than one logo is displayed
> + due to multiple CPUs, the collected line of logos is centered
> + as a whole.
> +
Isn't a kernel command line option more suitable to configure the position
of the logo?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
