dri-devel November 2020

dri-devel@lists.freedesktop.org

316 participants
811 discussions

[PATCH v5 0/7] dma-buf: Performance improvements for system heap & a system-uncached implementation
by John Stultz 21 May '21

21 May '21

Hey All, So just wanted to send my last revision of my patch series of performance optimizations to the dma-buf system heap. This series reworks the system heap to use sgtables, and then consolidates the pagelist method from the heap-helpers into the CMA heap. After which the heap-helpers logic is removed (as it is unused). I'd still like to find a better way to avoid some of the logic duplication in implementing the entire dma_buf_ops handlers per heap. But unfortunately that code is tied somewhat to how the buffer's memory is tracked. As more heaps show up I think we'll have a better idea how to best share code, so for now I think this is ok. After this, the series introduces an optimization that Ørjan Eide implemented for ION that avoids calling sync on attachments that don't have a mapping. Next, an optimization to use larger order pages for the system heap. This change brings us closer to the current performance of the ION allocation code (though there still is a gap due to ION using a mix of deferred-freeing and page pools, I'll be looking at integrating those eventually). Finally, a reworked version of my uncached system heap implementation I was submitting a few weeks back. Since it duplicated a lot of the now reworked system heap code, I realized it would be much simpler to add the functionality to the system_heap implementation itself. While not improving the core allocation performance, the uncached heap allocations do result in *much* improved performance on HiKey960 as it avoids a lot of flushing and invalidating buffers that the cpu doesn't touch often. Feedback on these would be great! thanks -john New in v5: * Added a comment explaining why the order sizes are chosen as they are Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: Liam Mark <lmark(a)codeaurora.org> Cc: Laura Abbott <labbott(a)kernel.org> Cc: Brian Starkey <Brian.Starkey(a)arm.com> Cc: Hridya Valsaraju <hridya(a)google.com> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: Sandeep Patil <sspatil(a)google.com> Cc: Daniel Mentz <danielmentz(a)google.com> Cc: Chris Goldsworthy <cgoldswo(a)codeaurora.org> Cc: Ørjan Eide <orjan.eide(a)arm.com> Cc: Robin Murphy <robin.murphy(a)arm.com> Cc: Ezequiel Garcia <ezequiel(a)collabora.com> Cc: Simon Ser <contact(a)emersion.fr> Cc: James Jones <jajones(a)nvidia.com> Cc: linux-media(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org John Stultz (7): dma-buf: system_heap: Rework system heap to use sgtables instead of pagelists dma-buf: heaps: Move heap-helper logic into the cma_heap implementation dma-buf: heaps: Remove heap-helpers code dma-buf: heaps: Skip sync if not mapped dma-buf: system_heap: Allocate higher order pages if available dma-buf: dma-heap: Keep track of the heap device struct dma-buf: system_heap: Add a system-uncached heap re-using the system heap drivers/dma-buf/dma-heap.c | 33 +- drivers/dma-buf/heaps/Makefile | 1 - drivers/dma-buf/heaps/cma_heap.c | 324 +++++++++++++++--- drivers/dma-buf/heaps/heap-helpers.c | 270 --------------- drivers/dma-buf/heaps/heap-helpers.h | 53 --- drivers/dma-buf/heaps/system_heap.c | 494 ++++++++++++++++++++++++--- include/linux/dma-heap.h | 9 + 7 files changed, 753 insertions(+), 431 deletions(-) delete mode 100644 drivers/dma-buf/heaps/heap-helpers.c delete mode 100644 drivers/dma-buf/heaps/heap-helpers.h -- 2.17.1

5 18

BUG: unable to handle kernel paging request in vga16fb_imageblit (2)
by syzbot 17 May '21

17 May '21

Hello, syzbot found the following crash on: HEAD commit: 262f7a6b Merge tag 'for-5.7-rc3-tag' of git://git.kernel.o.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=12786888100000 kernel config: https://syzkaller.appspot.com/x/.config?x=5b075813ec8b93cd dashboard link: https://syzkaller.appspot.com/bug?extid=1f29e126cf461c4de3b3 compiler: gcc (GCC) 9.0.0 20181231 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+1f29e126cf461c4de3b3(a)syzkaller.appspotmail.com BUG: unable to handle page fault for address: ffff8880ffca0e80 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD d401067 P4D d401067 PUD 0 Oops: 0002 [#1] PREEMPT SMP KASAN CPU: 0 PID: 710 Comm: syz-executor.5 Not tainted 5.7.0-rc3-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:writeb arch/x86/include/asm/io.h:65 [inline] RIP: 0010:vga_imageblit_expand drivers/video/fbdev/vga16fb.c:1168 [inline] RIP: 0010:vga16fb_imageblit+0xa5b/0x2210 drivers/video/fbdev/vga16fb.c:1260 Code: 48 89 fa 48 c1 ea 03 0f b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 09 84 d2 74 05 e8 ee 59 ed fd 41 8b 47 14 48 8b 74 24 08 <88> 06 0f ae e8 8a 06 b8 05 00 00 00 ba ce 03 00 00 ee 48 c7 c2 18 RSP: 0000:ffffc90002ea71f0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000007 RCX: ffffc90014391000 RDX: 0000000000000000 RSI: ffff8880ffca0e80 RDI: ffffc90002ea739c RBP: ffffc90002ea738c R08: ffff8880922ac200 R09: 0000000000000000 R10: ffffffff8a895007 R11: fffffbfff1512a00 R12: 0000000000000000 R13: ffff888218de5140 R14: 0000000000000001 R15: ffffc90002ea7388 FS: 00007fbeeb282700(0000) GS:ffff8880ae600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff8880ffca0e80 CR3: 000000008e9c5000 CR4: 00000000001406f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: bit_putcs_unaligned drivers/video/fbdev/core/bitblit.c:139 [inline] bit_putcs+0x910/0xe10 drivers/video/fbdev/core/bitblit.c:188 fbcon_putcs+0x345/0x3f0 drivers/video/fbdev/core/fbcon.c:1362 con_flush drivers/tty/vt/vt.c:2569 [inline] do_con_write.part.0+0x7d1/0x1dc0 drivers/tty/vt/vt.c:2772 do_con_write drivers/tty/vt/vt.c:2588 [inline] con_write+0x41/0xe0 drivers/tty/vt/vt.c:3154 process_output_block drivers/tty/n_tty.c:595 [inline] n_tty_write+0x3f0/0xf90 drivers/tty/n_tty.c:2333 do_tty_write drivers/tty/tty_io.c:962 [inline] tty_write+0x495/0x800 drivers/tty/tty_io.c:1046 __vfs_write+0x76/0x100 fs/read_write.c:495 __kernel_write+0x11c/0x3a0 fs/read_write.c:516 write_pipe_buf+0x153/0x1e0 fs/splice.c:809 splice_from_pipe_feed fs/splice.c:512 [inline] __splice_from_pipe+0x3e6/0x7b0 fs/splice.c:636 splice_from_pipe+0xd9/0x140 fs/splice.c:671 default_file_splice_write+0x37/0x90 fs/splice.c:821 do_splice_from fs/splice.c:863 [inline] direct_splice_actor+0x115/0x160 fs/splice.c:1037 splice_direct_to_actor+0x38c/0x980 fs/splice.c:992 do_splice_direct+0x1b4/0x280 fs/splice.c:1080 do_sendfile+0x555/0xc50 fs/read_write.c:1521 __do_sys_sendfile64 fs/read_write.c:1582 [inline] __se_sys_sendfile64 fs/read_write.c:1568 [inline] __x64_sys_sendfile64+0x1cc/0x210 fs/read_write.c:1568 do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295 entry_SYSCALL_64_after_hwframe+0x49/0xb3 RIP: 0033:0x45c829 Code: 0d b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 db b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007fbeeb281c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000028 RAX: ffffffffffffffda RBX: 00000000004fc0c0 RCX: 000000000045c829 RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000003 RBP: 000000000078bf00 R08: 0000000000000000 R09: 0000000000000000 R10: 0800000080004103 R11: 0000000000000246 R12: 00000000ffffffff R13: 00000000000008d6 R14: 00000000004cb7a1 R15: 00007fbeeb2826d4 Modules linked in: CR2: ffff8880ffca0e80 ---[ end trace 5bb103c4fc7bf525 ]--- RIP: 0010:writeb arch/x86/include/asm/io.h:65 [inline] RIP: 0010:vga_imageblit_expand drivers/video/fbdev/vga16fb.c:1168 [inline] RIP: 0010:vga16fb_imageblit+0xa5b/0x2210 drivers/video/fbdev/vga16fb.c:1260 Code: 48 89 fa 48 c1 ea 03 0f b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 09 84 d2 74 05 e8 ee 59 ed fd 41 8b 47 14 48 8b 74 24 08 <88> 06 0f ae e8 8a 06 b8 05 00 00 00 ba ce 03 00 00 ee 48 c7 c2 18 RSP: 0000:ffffc90002ea71f0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000007 RCX: ffffc90014391000 RDX: 0000000000000000 RSI: ffff8880ffca0e80 RDI: ffffc90002ea739c RBP: ffffc90002ea738c R08: ffff8880922ac200 R09: 0000000000000000 R10: ffffffff8a895007 R11: fffffbfff1512a00 R12: 0000000000000000 R13: ffff888218de5140 R14: 0000000000000001 R15: ffffc90002ea7388 FS: 00007fbeeb282700(0000) GS:ffff8880ae600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff8880ffca0e80 CR3: 000000008e9c5000 CR4: 00000000001406f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkaller(a)googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

5 20

[PATCH] drm/msm/dsi: save PLL registers across first PHY reset
by benl-kernelpatches＠squareup.com 15 May '21

15 May '21

From: Benjamin Li <benl(a)squareup.com> Take advantage of previously-added support for persisting PLL registers across DSI PHY disable/enable cycles (see 328e1a6 'drm/msm/dsi: Save/Restore PLL status across PHY reset') to support persisting across the very first DSI PHY enable at boot. The bootloader may have left the PLL registers in a non-default state. For example, for dsi_pll_28nm.c on 8x16/8x39, the byte clock mux's power-on reset configuration is to bypass DIV1, but depending on bandwidth requirements[1] the bootloader may have set the DIV1 path. When the byte clock mux is registered with the generic clock framework at probe time, the framework reads & caches the value of the mux bit field (the initial clock parent). After PHY enable, when clk_set_rate is called on the byte clock, the framework assumes there is no need to reparent, and doesn't re-write the mux bit field. But PHY enable resets PLL registers, so the mux bit field actually silently reverted to the DIV1 bypass path. This causes the byte clock to be off by a factor of e.g. 2 for our tested WXGA panel. The above issue manifests as the display not working and a constant stream of FIFO/LP0 contention errors. [1] The specific requirement for triggering the DIV1 path (and thus this issue) on 28nm is a panel with pixel clock <116.7MHz (one-third the minimum VCO setting). FHD/1080p (~145MHz) is fine, WXGA/1280x800 (~75MHz) is not. Signed-off-by: Benjamin Li <benl(a)squareup.com> --- drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c index 009f5b843dd1..139b4a5aaf86 100644 --- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c +++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c @@ -621,6 +621,22 @@ static int dsi_phy_driver_probe(struct platform_device *pdev) phy->pll = NULL; } + /* + * As explained in msm_dsi_phy_enable, resetting the DSI PHY (as done + * in dsi_mgr_phy_enable) silently changes its PLL registers to power-on + * defaults, but the generic clock framework manages and caches several + * of the PLL registers. It initializes these caches at registration + * time via register read. + * + * As a result, we need to save DSI PLL registers once at probe in order + * for the first call to msm_dsi_phy_enable to successfully bring PLL + * registers back in line with what the generic clock framework expects. + * + * Subsequent PLL restores during msm_dsi_phy_enable will always be + * paired with PLL saves in msm_dsi_phy_disable. + */ + msm_dsi_pll_save_state(phy->pll); + dsi_phy_disable_resource(phy); platform_set_drvdata(pdev, phy); -- 2.17.1

3 5

[Bug 51381] New: [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting, when disabled via vgaswitcheroo
by bugzilla-daemon＠bugzilla.kernel.org 11 May '21

11 May '21

https://bugzilla.kernel.org/show_bug.cgi?id=51381 Summary: [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting, when disabled via vgaswitcheroo Product: Drivers Version: 2.5 Kernel Version: Linux version 3.6.9-1-ARCH (tobias@T-POWA-LX) (gcc version 4.7.2 (GCC) ) #1 SMP PREEMPT Tue Dec 4 08:04:10 CET 2012 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri(a)kernel-bugs.osdl.org ReportedBy: a(a)anrd.net Regression: Yes Created an attachment (id=88591) --> (https://bugzilla.kernel.org/attachment.cgi?id=88591) journald log After updating from 3.6.6 to 3.6.9 my laptop with Intel graphics and ATI HD 5650 will not resume from suspend. I use vgaswitcheroo to disable the ATI card at boot. On resume the computer almost hangs (I can press power button and wait 5 minutes for a proper shutdown, but no other interaction is possible). It logs a lot of messages saying: [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting [drm:atom_execute_table_locked] *ERROR* atombios stuck executing D098 (len 72, WS 0, PS 0) @ 0xD0C7 Steps to reproduce: echo "OFF" > /sys/kernel/debug/vgaswitcheroo/switch [suspend and resume] Actual results: Almost freeze. Expected results: Resume and work as normal. Log is attached, but if you need anything else just ask. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.

1 62

[PATCH 1/3] drm/exynos: Init the DSIM PHY in samsung_dsim_enable()
by Marek Vasut 10 May '21

10 May '21

In case the PHY is not initialized, do it in samsung_dsim_enable(), otherwise the link configuration registers are not programmed at all. Signed-off-by: Marek Vasut <marex(a)denx.de> Cc: Fabio Estevam <festevam(a)gmail.com> Cc: Guido Günther <agx(a)sigxcpu.org> Cc: Jaehoon Chung <jh80.chung(a)samsung.com> Cc: Lucas Stach <l.stach(a)pengutronix.de> Cc: Marek Szyprowski <m.szyprowski(a)samsung.com> Cc: Michael Tretter <m.tretter(a)pengutronix.de> Cc: NXP Linux Team <linux-imx(a)nxp.com> Cc: Shawn Guo <shawnguo(a)kernel.org> Cc: linux-arm-kernel(a)lists.infradead.org Cc: linux-samsung-soc(a)vger.kernel.org To: dri-devel(a)lists.freedesktop.org -- NOTE: This depends on https://patchwork.kernel.org/project/dri-devel/list/?series=347439 --- drivers/gpu/drm/bridge/samsung-dsim.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c index 6d2d8dc027de..fbd87a74eb9f 100644 --- a/drivers/gpu/drm/bridge/samsung-dsim.c +++ b/drivers/gpu/drm/bridge/samsung-dsim.c @@ -1244,6 +1244,13 @@ static void samsung_dsim_enable(struct samsung_dsim *dsi) pm_runtime_get_sync(dsi->dev); dsi->state |= DSIM_STATE_ENABLED; + if (!(dsi->state & DSIM_STATE_INITIALIZED)) { + ret = samsung_dsim_init(dsi); + if (ret) + return; + dsi->state |= DSIM_STATE_INITIALIZED; + } + if (dsi->panel) { ret = drm_panel_prepare(dsi->panel); if (ret < 0) -- 2.28.0

5 6

[PATCH v3 0/4] drm/bridge: ti-sn65dsi86: Support EDID reading
by Stephen Boyd 07 May '21

07 May '21

This patch series cleans up the DDC code a little bit so that it is more efficient time wise and supports grabbing the EDID of the eDP panel over the aux channel. I timed this on a board I have on my desk and it takes about 20ms to grab the EDID out of the panel and make sure it is valid. The first two patches seem less controversial so I stuck them at the beginning. The third patch does the EDID reading and caches it so we don't have to keep grabbing it over and over again. And finally the last patch updates the reply field so that short reads and nacks over the channel are reflected properly instead of treating them as some sort of error that can't be discerned. Stephen Boyd (4): drm/bridge: ti-sn65dsi86: Combine register accesses in ti_sn_aux_transfer() drm/bridge: ti-sn65dsi86: Make polling a busy loop drm/bridge: ti-sn65dsi86: Read EDID blob over DDC drm/bridge: ti-sn65dsi86: Update reply on aux failures drivers/gpu/drm/bridge/ti-sn65dsi86.c | 103 ++++++++++++++++++-------- 1 file changed, 71 insertions(+), 32 deletions(-) Cc: Douglas Anderson <dianders(a)chromium.org> Cc: Laurent Pinchart <Laurent.pinchart(a)ideasonboard.com> Cc: Jonas Karlman <jonas(a)kwiboo.se> Cc: Jernej Skrabec <jernej.skrabec(a)siol.net> Cc: Sean Paul <seanpaul(a)chromium.org> base-commit: 3650b228f83adda7e5ee532e2b90429c03f7b9ec -- Sent by a computer, using git, on the internet

4 10

[Bug 207833] New: Brightness control not working on ASUS TUF FA506IU (AMD Ryzen 7 4800H / Nvidia GTX 1660 Ti)
by bugzilla-daemon＠bugzilla.kernel.org 06 May '21

06 May '21

https://bugzilla.kernel.org/show_bug.cgi?id=207833 Bug ID: 207833 Summary: Brightness control not working on ASUS TUF FA506IU (AMD Ryzen 7 4800H / Nvidia GTX 1660 Ti) Product: Drivers Version: 2.5 Kernel Version: 5.6.12-1 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: julen.pardo(a)outlook.es Regression: No Hello, I've just bought an ASUS TUF FA506IU with and AMD Ryzen 7 4800H / Nvidia GTX 1660 Ti setup. Even if this is quite new hardware, I'd say that the only thing that is not working at all is the brightness control. It's not working with the function keys, nor from the energy settings, nor with xbacklight. Actually, it's working a little; I can find a subtle difference between the max value and the last 5 values, but that's it. Setting it to the minimum still makes it way too bright. I've noticed that this could be a range mismatch between "brightness" and "max_brightness", and "actual_brightness". First are in 8 bit ranges, whereas the actual brightness is in 16 bit range. I've tried some luck patching the kernel to return an 8-bit value (https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/amd/display/d…), but doing just that doesn't work (even if the "actual_brightness" was showing an 8 bit value). In my case, the full path is "/sys/class/backlight/amdgpu_bl1/". I've also tried different acpi_backlight parameters with no luck. I leave the output of lsmod | grep asus: asus_wmi 40960 0 sparse_keymap 16384 1 asus_wmi rfkill 28672 9 asus_wmi,bluetooth,cfg80211 battery 24576 1 asus_wmi wmi 36864 2 asus_wmi,wmi_bmof asus_wireless 20480 0 inxi -F: System: Host: TUF-FA506IU Kernel: 5.6.12-1-MANJARO x86_64 bits: 64 Desktop: KDE Plasma 5.18.5 Distro: Manjaro Linux Machine: Type: Laptop System: ASUSTeK product: TUF Gaming FA506IU_FA506IU v: 1.0 serial: <root required> Mobo: ASUSTeK model: FA506IU v: 1.0 serial: <root required> UEFI: American Megatrends v: FA506IU.302 date: 03/04/2020 Battery: ID-1: BAT1 charge: 47.9 Wh condition: 47.9/48.1 Wh (100%) CPU: Topology: 8-Core model: AMD Ryzen 7 4800H with Radeon Graphics bits: 64 type: MT MCP L2 cache: 4096 KiB Speed: 2405 MHz min/max: 1400/2900 MHz Core speeds (MHz): 1: 1875 2: 2497 3: 1397 4: 1397 5: 1397 6: 1397 7: 1397 8: 1397 9: 1397 10: 1396 11: 2963 12: 1673 13: 1800 14: 1548 15: 1397 16: 1396 Graphics: Device-1: NVIDIA TU116M [GeForce GTX 1660 Ti Mobile] driver: nvidia v: 440.82 Device-2: Advanced Micro Devices [AMD/ATI] Renoir driver: amdgpu v: kernel Display: x11 server: X.Org 1.20.8 driver: amdgpu,nvidia resolution: 1920x1080~144Hz, 2560x1440~60Hz OpenGL: renderer: AMD RENOIR (DRM 3.36.0 5.6.12-1-MANJARO LLVM 10.0.0) v: 4.6 Mesa 20.0.6 Audio: Device-1: NVIDIA TU116 High Definition Audio driver: snd_hda_intel Device-2: Advanced Micro Devices [AMD/ATI] driver: snd_hda_intel Device-3: Advanced Micro Devices [AMD] Raven/Raven2/FireFlight/Renoir Audio Processor driver: N/A Device-4: Advanced Micro Devices [AMD] Family 17h HD Audio driver: snd_hda_intel Sound Server: ALSA v: k5.6.12-1-MANJARO Network: Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169 IF: enp2s0 state: down mac: a8:5e:45:36:94:32 Device-2: Realtek RTL8822CE 802.11ac PCIe Wireless Network Adapter driver: rtw_pci IF: wlp3s0 state: up mac: 70:66:55:09:8c:e3 Drives: Local Storage: total: 476.94 GiB used: 32.41 GiB (6.8%) ID-1: /dev/nvme0n1 vendor: Kingston model: OM8PCP3512F-AB size: 476.94 GiB Partition: ID-1: / size: 48.97 GiB used: 25.95 GiB (53.0%) fs: ext4 dev: /dev/nvme0n1p5 ID-2: /home size: 108.67 GiB used: 6.46 GiB (5.9%) fs: ext4 dev: /dev/nvme0n1p7 ID-3: swap-1 size: 3.03 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/nvme0n1p8 Sensors: Message: No sensors data was found. Is sensors configured? Info: Processes: 349 Uptime: 27m Memory: 7.20 GiB used: 3.04 GiB (42.2%) Shell: zsh inxi: 3.0.37 -- You are receiving this mail because: You are watching the assignee of the bug.

1 6

[Bug 203905] New: amdgpu:actual_brightness has unreal/wrong value
by bugzilla-daemon＠bugzilla.kernel.org 06 May '21

06 May '21

https://bugzilla.kernel.org/show_bug.cgi?id=203905 Bug ID: 203905 Summary: amdgpu:actual_brightness has unreal/wrong value Product: Drivers Version: 2.5 Kernel Version: 5.1.9 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: bjo(a)nord-west.org Regression: No Radeon R5/R6/R7 Graphics in a Thinkpad A275 has wrong values on actual_brightness of amdgpu_bl0. While max_brightness is 255 and it can be set to 255, actual_brightness reports a 5 digit number like 12470. As a result, tools which want to change the brightness related to actual_brightness fail, as brightness does not accept any 5 digit number, -- You are receiving this mail because: You are watching the assignee of the bug.

1 33

[PATCH 1/2] mm: cma: export functions to get CMA base and size
by Lucas Stach 03 May '21

03 May '21

Make them usable in modules. Some drivers want to know where their device CMA area is located to make better decisions about the DMA programming. Signed-off-by: Lucas Stach <l.stach(a)pengutronix.de> --- mm/cma.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/mm/cma.c b/mm/cma.c index 3340ef34c154..191c89bf038d 100644 --- a/mm/cma.c +++ b/mm/cma.c @@ -44,11 +44,13 @@ phys_addr_t cma_get_base(const struct cma *cma) { return PFN_PHYS(cma->base_pfn); } +EXPORT_SYMBOL_GPL(cma_get_base); unsigned long cma_get_size(const struct cma *cma) { return cma->count << PAGE_SHIFT; } +EXPORT_SYMBOL_GPL(cma_get_size); const char *cma_get_name(const struct cma *cma) { -- 2.20.1

2 2

[PATCH] ASoC: fsl: imx-pcm-dma: Don't request dma channel in probe
by Shengjiu Wang 22 Apr '21

22 Apr '21

There are two requirements that we need to move the request of dma channel from probe to open. - When dma device binds with power-domains, the power will be enabled when we request dma channel. If the request of dma channel happen on probe, then the power-domains will be always enabled after kernel boot up, which is not good for power saving, so we need to move the request of dma channel to .open(); - With FE-BE case, if the dma channel is requested in probe, then there will be below issue, which is caused by that the dma channel will be requested duplicately [ 638.906268] sysfs: cannot create duplicate filename '/devices/soc0/soc/2000000.bus/2000000.spba-bus/2024000.esai/dma:tx' [ 638.919061] CPU: 1 PID: 673 Comm: aplay Not tainted 5.7.0-rc1-12956-gfc64b2585593 #287 [ 638.927113] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) [ 638.933690] [<c0110dd8>] (unwind_backtrace) from [<c010b8ec>] (show_stack+0x10/0x14) [ 638.941464] [<c010b8ec>] (show_stack) from [<c0557fc0>] (dump_stack+0xe4/0x118) [ 638.948808] [<c0557fc0>] (dump_stack) from [<c032aeb4>] (sysfs_warn_dup+0x50/0x64) [ 638.956406] [<c032aeb4>] (sysfs_warn_dup) from [<c032b1a8>] (sysfs_do_create_link_sd+0xc8/0xd4) [ 638.965134] [<c032b1a8>] (sysfs_do_create_link_sd) from [<c05dc668>] (dma_request_chan+0xb0/0x210) [ 638.974120] [<c05dc668>] (dma_request_chan) from [<c05dc7d0>] (dma_request_slave_channel+0x8/0x14) [ 638.983111] [<c05dc7d0>] (dma_request_slave_channel) from [<c09d5548>] (fsl_asrc_dma_hw_params+0x1e0/0x438) [ 638.992881] [<c09d5548>] (fsl_asrc_dma_hw_params) from [<c09c1654>] (soc_pcm_hw_params+0x4a0/0x6a8) [ 639.001952] [<c09c1654>] (soc_pcm_hw_params) from [<c09c39d4>] (dpcm_fe_dai_hw_params+0x70/0xe4) [ 639.010765] [<c09c39d4>] (dpcm_fe_dai_hw_params) from [<c099b274>] (snd_pcm_hw_params+0x158/0x418) [ 639.019750] [<c099b274>] (snd_pcm_hw_params) from [<c099c5a0>] (snd_pcm_ioctl+0x734/0x183c) [ 639.028129] [<c099c5a0>] (snd_pcm_ioctl) from [<c029ff94>] (ksys_ioctl+0x2ac/0xb98) [ 639.035812] [<c029ff94>] (ksys_ioctl) from [<c0100080>] (ret_fast_syscall+0x0/0x28) [ 639.043490] Exception stack(0xec529fa8 to 0xec529ff0) [ 639.048565] 9fa0: bee84650 01321870 00000004 c25c4111 bee84650 0002000f [ 639.056766] 9fc0: bee84650 01321870 01321820 00000036 00001f40 00000000 0002c2f8 00000003 [ 639.064964] 9fe0: b6f483fc bee8451c b6ee2655 b6e1dcf8 [ 639.070339] fsl-esai-dai 2024000.esai: Cannot create DMA dma:tx symlink Signed-off-by: Shengjiu Wang <shengjiu.wang(a)nxp.com> --- sound/soc/fsl/imx-pcm-dma.c | 173 +++++++++++++++++++++++++++++++++--- 1 file changed, 159 insertions(+), 14 deletions(-) diff --git a/sound/soc/fsl/imx-pcm-dma.c b/sound/soc/fsl/imx-pcm-dma.c index 04a9bc749016..dae53b384df4 100644 --- a/sound/soc/fsl/imx-pcm-dma.c +++ b/sound/soc/fsl/imx-pcm-dma.c @@ -11,6 +11,7 @@ #include <linux/dmaengine.h> #include <linux/types.h> #include <linux/module.h> +#include <linux/dma-mapping.h> #include <sound/core.h> #include <sound/pcm.h> @@ -29,24 +30,168 @@ static bool filter(struct dma_chan *chan, void *param) return true; } -static const struct snd_dmaengine_pcm_config imx_dmaengine_pcm_config = { - .prepare_slave_config = snd_dmaengine_pcm_prepare_slave_config, - .compat_filter_fn = filter, -}; +static int imx_pcm_hw_params(struct snd_soc_component *component, + struct snd_pcm_substream *substream, + struct snd_pcm_hw_params *params) +{ + struct snd_pcm_runtime *runtime = substream->runtime; + struct snd_soc_pcm_runtime *rtd = substream->private_data; + struct snd_soc_dai *cpu_dai = asoc_rtd_to_cpu(rtd, 0); + struct snd_dmaengine_dai_dma_data *dma_data; + struct dma_slave_config config; + struct dma_chan *chan; + int ret = 0; -int imx_pcm_dma_init(struct platform_device *pdev, size_t size) + snd_pcm_set_runtime_buffer(substream, &substream->dma_buffer); + runtime->dma_bytes = params_buffer_bytes(params); + + chan = snd_dmaengine_pcm_get_chan(substream); + if (!chan) + return -EINVAL; + + ret = snd_hwparams_to_dma_slave_config(substream, params, &config); + if (ret) + return ret; + + dma_data = snd_soc_dai_get_dma_data(cpu_dai, substream); + if (!dma_data) + return -EINVAL; + + snd_dmaengine_pcm_set_config_from_dai_data(substream, + dma_data, + &config); + return dmaengine_slave_config(chan, &config); +} + +static int imx_pcm_hw_free(struct snd_soc_component *component, + struct snd_pcm_substream *substream) { - struct snd_dmaengine_pcm_config *config; + snd_pcm_set_runtime_buffer(substream, NULL); + return 0; +} + +static snd_pcm_uframes_t imx_pcm_pointer(struct snd_soc_component *component, + struct snd_pcm_substream *substream) +{ + return snd_dmaengine_pcm_pointer(substream); +} + +static int imx_pcm_trigger(struct snd_soc_component *component, + struct snd_pcm_substream *substream, int cmd) +{ + return snd_dmaengine_pcm_trigger(substream, cmd); +} + +static int imx_pcm_open(struct snd_soc_component *component, + struct snd_pcm_substream *substream) +{ + struct snd_soc_pcm_runtime *rtd = substream->private_data; + bool tx = substream->stream == SNDRV_PCM_STREAM_PLAYBACK; + struct snd_soc_dai *cpu_dai = asoc_rtd_to_cpu(rtd, 0); + struct snd_dmaengine_dai_dma_data *dma_data; + struct device *dev = component->dev; + struct snd_pcm_hardware hw; + struct dma_chan *chan; + int ret; + + ret = snd_pcm_hw_constraint_integer(substream->runtime, + SNDRV_PCM_HW_PARAM_PERIODS); + if (ret < 0) { + dev_err(dev, "failed to set pcm hw params periods\n"); + return ret; + } + + dma_data = snd_soc_dai_get_dma_data(cpu_dai, substream); + if (!dma_data) + return -EINVAL; + + chan = dma_request_slave_channel(cpu_dai->dev, tx ? "tx" : "rx"); + if (!chan) { + /* Try to request channel using compat_filter_fn */ + chan = snd_dmaengine_pcm_request_channel(filter, + dma_data->filter_data); + if (!chan) + return -ENXIO; + } - config = devm_kzalloc(&pdev->dev, - sizeof(struct snd_dmaengine_pcm_config), GFP_KERNEL); - if (!config) - return -ENOMEM; - *config = imx_dmaengine_pcm_config; + ret = snd_dmaengine_pcm_open(substream, chan); + if (ret) + goto pcm_open_fail; - return devm_snd_dmaengine_pcm_register(&pdev->dev, - config, - SND_DMAENGINE_PCM_FLAG_COMPAT); + memset(&hw, 0, sizeof(hw)); + hw.info = SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_MMAP_VALID | + SNDRV_PCM_INFO_INTERLEAVED; + hw.periods_min = 2; + hw.periods_max = UINT_MAX; + hw.period_bytes_min = 256; + hw.period_bytes_max = dma_get_max_seg_size(chan->device->dev); + hw.buffer_bytes_max = IMX_DEFAULT_DMABUF_SIZE; + hw.fifo_size = dma_data->fifo_size; + + /* Refine the hw according to caps of DMA. */ + ret = snd_dmaengine_pcm_refine_runtime_hwparams(substream, + dma_data, + &hw, + chan); + if (ret < 0) + goto refine_runtime_hwparams_fail; + + snd_soc_set_runtime_hwparams(substream, &hw); + + /* Support allocate memory from IRAM */ + ret = snd_dma_alloc_pages(SNDRV_DMA_TYPE_DEV_IRAM, + chan->device->dev, + hw.buffer_bytes_max, + &substream->dma_buffer); + if (ret < 0) + goto alloc_pagas_fail; + + return 0; + +alloc_pagas_fail: +refine_runtime_hwparams_fail: + snd_dmaengine_pcm_close(substream); +pcm_open_fail: + dma_release_channel(chan); + + return ret; +} + +static int imx_pcm_close(struct snd_soc_component *component, + struct snd_pcm_substream *substream) +{ + if (substream) { + snd_dma_free_pages(&substream->dma_buffer); + substream->dma_buffer.area = NULL; + substream->dma_buffer.addr = 0; + } + + return snd_dmaengine_pcm_close_release_chan(substream); +} + +static int imx_pcm_new(struct snd_soc_component *component, + struct snd_soc_pcm_runtime *rtd) +{ + struct snd_card *card = rtd->card->snd_card; + + return dma_coerce_mask_and_coherent(card->dev, DMA_BIT_MASK(32)); +} + +static const struct snd_soc_component_driver imx_pcm_component = { + .name = "imx-pcm-dma", + .pcm_construct = imx_pcm_new, + .open = imx_pcm_open, + .close = imx_pcm_close, + .hw_params = imx_pcm_hw_params, + .hw_free = imx_pcm_hw_free, + .trigger = imx_pcm_trigger, + .pointer = imx_pcm_pointer, +}; + +int imx_pcm_dma_init(struct platform_device *pdev, size_t size) +{ + return devm_snd_soc_register_component(&pdev->dev, + &imx_pcm_component, NULL, 0); } EXPORT_SYMBOL_GPL(imx_pcm_dma_init); -- 2.21.0

5 17

← Newer
1
2
3
4
5
6
7
8
9
...
82
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel November 2020