dri-devel February 2022

dri-devel@lists.freedesktop.org

394 participants
865 discussions

DMA-buf and uncached system memory
by Christian König 24 Jun '22

24 Jun '22

Hi guys, we are currently working an Freesync and direct scan out from system memory on AMD APUs in A+A laptops. On problem we stumbled over is that our display hardware needs to scan out from uncached system memory and we currently don't have a way to communicate that through DMA-buf. For our specific use case at hand we are going to implement something driver specific, but the question is should we have something more generic for this? After all the system memory access pattern is a … [View More]

11 43

[Bug 201957] New: amdgpu: ring gfx timeout
by bugzilla-daemon＠bugzilla.kernel.org 23 Jun '22

23 Jun '22

https://bugzilla.kernel.org/show_bug.cgi?id=201957 Bug ID: 201957 Summary: amdgpu: ring gfx timeout Product: Drivers Version: 2.5 Kernel Version: 4.19.8, 4.20-rc5 Hardware: Intel OS: Linux Tree: Mainline Status: NEW Severity: blocking Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: felix.… [View More]

2 79

[PATCH v1 0/9] drm/bridge: ps8640 and ti-sn65dsi86 updates
by Sam Ravnborg 22 Jun '22

22 Jun '22

Add a new macro DRM_BRIDGE_STATE_OPS that can be used to assign atomic_reset and atomic_{duplicate,destroy}_state to the default implementations. They will be valid in most cases. Add a drm variant of media-bus-format.h to hold a single function to get the bpc from the bus format. Also add a small drm_atomic_helper_bridge_dsi_input_bus_fmt helper. Update ti-sn65dsi86 to support atomic and NO_CONNECTOR. The NO_CONNECTOR support was from Rob Clark - I just rebased it. To support NO_CONNECTOR … [View More]

4 29

[PATCH v7, 00/15] media: mtk-vcodec: support for M8192 decoder
by Yunfei Dong 21 Jun '22

21 Jun '22

This series adds support for mt8192 h264/vp8/vp9 decoder drivers. Firstly, refactor power/clock/interrupt interfaces for mt8192 is lat and core architecture. Secondly, add new functions to get frame buffer size and resolution according to decoder capability from scp side. Then add callback function to get/put capture buffer in order to enable lat and core decoder in parallel. Then add to support MT21C compressed mode and fix v4l2-compliance fail. Next, extract H264 request api driver to let … [View More]mt8183 and mt8192 use the same code, and adds mt8192 frame based h264 driver for stateless decoder. Lastly, add vp8 and vp9 stateless decoder drivers. Patches 1 refactor power/clock/interrupt interface. Patches 2~4 get frame buffer size and resolution according to decoder capability. Patches 5~6 enable lat and core decode in parallel. Patch 7~10 add to support MT21C compressed mode and fix v4l2-compliance fail. patch 11 record capture queue format type. Patch 12~13 extract h264 driver and add mt8192 frame based driver for h264 decoder. Patch 14~15 add vp8 and vp9 stateless decoder drivers. --- changes compared with v6: - rebase to the latest media stage and fix conficts - fix memcpy to memcpy_fromio or memcpy_toio - fix h264 crash when test field bitstream changes compared with v5: - fix vp9 comments for patch 15 - fix vp8 comments for patch 14. - fix comments for patch 12. - fix build errors. changes compared with v4: - fix checkpatch.pl fail. - fix kernel-doc fail. - rebase to the latest media codec driver. changes compared with v3: - remove enum mtk_chip for patch 2. - add vp8 stateless decoder drivers for patch 14. - add vp9 stateless decoder drivers for patch 15. changes compared with v2: - add new patch 11 to record capture queue format type. - separate patch 4 according to tzung-bi's suggestion. - re-write commit message for patch 5 according to tzung-bi's suggestion. changes compared with v1: - rewrite commit message for patch 12. - rewrite cover-letter message. --- Yunfei Dong (15): media: mtk-vcodec: Add vdec enable/disable hardware helpers media: mtk-vcodec: Using firmware type to separate different firmware architecture media: mtk-vcodec: get capture queue buffer size from scp media: mtk-vcodec: Read max resolution from dec_capability media: mtk-vcodec: Call v4l2_m2m_set_dst_buffered() set capture buffer buffered media: mtk-vcodec: Refactor get and put capture buffer flow media: mtk-vcodec: Refactor supported vdec formats and framesizes media: mtk-vcodec: Add format to support MT21C media: mtk-vcodec: disable vp8 4K capability media: mtk-vcodec: Fix v4l2-compliance fail media: mtk-vcodec: record capture queue format type media: mtk-vcodec: Extract H264 common code media: mtk-vcodec: support stateless H.264 decoding for mt8192 media: mtk-vcodec: support stateless VP8 decoding media: mtk-vcodec: support stateless VP9 decoding drivers/media/platform/mtk-vcodec/Makefile | 4 + .../platform/mtk-vcodec/mtk_vcodec_dec.c | 47 +- .../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 5 - .../platform/mtk-vcodec/mtk_vcodec_dec_pm.c | 166 +- .../platform/mtk-vcodec/mtk_vcodec_dec_pm.h | 6 +- .../mtk-vcodec/mtk_vcodec_dec_stateful.c | 14 +- .../mtk-vcodec/mtk_vcodec_dec_stateless.c | 282 ++- .../platform/mtk-vcodec/mtk_vcodec_drv.h | 40 +- .../platform/mtk-vcodec/mtk_vcodec_enc_drv.c | 5 - .../media/platform/mtk-vcodec/mtk_vcodec_fw.c | 6 + .../media/platform/mtk-vcodec/mtk_vcodec_fw.h | 1 + .../mtk-vcodec/vdec/vdec_h264_req_common.c | 310 +++ .../mtk-vcodec/vdec/vdec_h264_req_common.h | 253 +++ .../mtk-vcodec/vdec/vdec_h264_req_if.c | 440 +--- .../mtk-vcodec/vdec/vdec_h264_req_multi_if.c | 621 ++++++ .../mtk-vcodec/vdec/vdec_vp8_req_if.c | 445 ++++ .../mtk-vcodec/vdec/vdec_vp9_req_lat_if.c | 1971 +++++++++++++++++ .../media/platform/mtk-vcodec/vdec_drv_if.c | 36 +- .../media/platform/mtk-vcodec/vdec_drv_if.h | 3 + .../media/platform/mtk-vcodec/vdec_ipi_msg.h | 36 + .../platform/mtk-vcodec/vdec_msg_queue.c | 2 + .../media/platform/mtk-vcodec/vdec_vpu_if.c | 53 +- .../media/platform/mtk-vcodec/vdec_vpu_if.h | 15 + .../media/platform/mtk-vcodec/venc_vpu_if.c | 2 +- include/linux/remoteproc/mtk_scp.h | 2 + 25 files changed, 4180 insertions(+), 585 deletions(-) create mode 100644 drivers/media/platform/mtk-vcodec/vdec/vdec_h264_req_common.c create mode 100644 drivers/media/platform/mtk-vcodec/vdec/vdec_h264_req_common.h create mode 100644 drivers/media/platform/mtk-vcodec/vdec/vdec_h264_req_multi_if.c create mode 100644 drivers/media/platform/mtk-vcodec/vdec/vdec_vp8_req_if.c create mode 100644 drivers/media/platform/mtk-vcodec/vdec/vdec_vp9_req_lat_if.c -- 2.25.1 [View Less]

5 35

[PATCH v2 0/4] Add PSR support for eDP
by Vinod Polimera 21 Jun '22

21 Jun '22

*** BLURB HERE *** Vinod Polimera (4): drm/msm/dp: Add basic PSR support for eDP drm/bridge: use atomic enable/disable for bridge callbacks drm/msm/disp/dpu1: use atomic enable/disable callbacks for encoder functions drm/msm/disp/dpu1: add PSR support for eDP interface in dpu driver drivers/gpu/drm/bridge/panel.c | 102 ++++++++++++++-- drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 31 ++++- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 40 ++++++- drivers/gpu/drm/… [View More]

7 18

[Bug 172421] New: radeon: allow to set the TMDS frequency by a special kernel parameter
by bugzilla-daemon＠bugzilla.kernel.org 19 Jun '22

19 Jun '22

https://bugzilla.kernel.org/show_bug.cgi?id=172421 Bug ID: 172421 Summary: radeon: allow to set the TMDS frequency by a special kernel parameter Product: Drivers Version: 2.5 Kernel Version: 4.8.0-rc7+ Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: enhancement Priority: P1 Component: Video(DRI - non Intel) Assignee: … [View More]drivers_video-dri(a)kernel-bugs.osdl.org Reporter: estellnb(a)elstel.org Regression: No Despite different claims by ATI in 2016 Radeon R5 230 graphics cards featuring HDMI, DVI and VGA had originally been sold as 4K-ready up to the year 2015. The only prove I have for this is a comercial invoice from Nexus Mobile and a packaging card. As far as I know Radeon R5 230 cards currently sold can still be run stable and reliable under UltraHD provided that you apply the right kernel patch (see for the attachement). Unfortunately neither my former merchant nor ATI have responded about my questions concerning this change in trade and marketing policy. My request would now be to integrate the provided patch into the mainline kernel. It does not change the behaviour of the radeon driver unless you specify a nonzero value for the radeon.hdmimhz parameter. If you do I have tested the R5 230 cards I have to run stable and reliably for days. At least the 2GB variant of this card has largely sufficient resources for proficient desktop computing under UltraHD including image manipulation in 3840x2160. While never officially discussed for the radeon driver nouveau is already implementing a similar parameter called nouveau.hdmimhz since kernel 4.5.x. Though it thereby becomes possible to specify a hdmimhz that is far above the cards technical possibilties the nouveau developers I have talked with say that it would rarely be possible to damage any card by overcloking the TMDS. In deed I have successfully been overclocking my GeForce 9600M GT to feature 4K/2160p. Even specifying values considerable higher than 225MHz did not damage my GeForce 9600M GT though the screen stayed black upon the nouveau driver initialization. While the Radeon R5 230 works well at 297MHz (as long as you specify that via radeon.hdmimhz) I have similarly to the GeForce 9600M GT tried to overclock a Radeon R7 240. It did produce stable images at a higher hdmimhz like 330 though the HDMI input of my monitor features no more than 30Hz at 3840x2160 (tested with or without a DP-adapter). While it remains questionable if the provided patch can improve things for newer Radeon cards I would believe it to be beneficial for some elder cards. At least it is known to be beneficial for the R5 230 initially marketed as 4K-ready. The according radeon patch provided with this report has so far already been accepted by the Mageia 6 distribution. Though the attached patch is for application at the current 4.8.0-rcX+ kernels most of my machines that rely on it still run with 4.6.0. -- You are receiving this mail because: You are watching the assignee of the bug. [View Less]

2 23

[Bug 213145] New: AMDGPU resets, timesout and crashes after "*ERROR* Waiting for fences timed out!"
by bugzilla-daemon＠bugzilla.kernel.org 13 Jun '22

13 Jun '22

https://bugzilla.kernel.org/show_bug.cgi?id=213145 Bug ID: 213145 Summary: AMDGPU resets, timesout and crashes after "*ERROR* Waiting for fences timed out!" Product: Drivers Version: 2.5 Kernel Version: 5.10.37 and 5.10.38 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Video(DRI - non Intel) … [View More]Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: tgayoso(a)gmail.com Regression: No Created attachment 296867 --> https://bugzilla.kernel.org/attachment.cgi?id=296867&action=edit lspci output AMDGPU driver crashes randomly corrupting screen and freezing X with: [ 60.449781] [drm:0xffffffffc25a7a57] *ERROR* Waiting for fences timed out! [ 60.971941] [drm:0xffffffffc25281ae] *ERROR* ring gfx timeout, signaled seq=3658, emitted seq=3660 [ 60.971946] [drm:0xffffffffc25281cb] *ERROR* Process information: process Xorg pid 1192 thread Xorg:cs0 pid 1193 [ 60.971952] amdgpu 0000:05:00.0: amdgpu: GPU reset begin! ... (some output suppressed for clarity, look at attached dmesg, please). [ 61.800343] amdgpu 0000:05:00.0: amdgpu: recover vram bo from shadow start [ 61.800346] amdgpu 0000:05:00.0: amdgpu: recover vram bo from shadow done [ 61.800348] [drm] Skip scheduling IBs! [ 61.800350] [drm] Skip scheduling IBs! [ 61.800382] [drm] Skip scheduling IBs! [ 61.800398] amdgpu 0000:05:00.0: amdgpu: GPU reset(2) succeeded! [ 61.800566] [drm] Skip scheduling IBs! [ 61.800580] [drm] Skip scheduling IBs! [ 61.800627] [drm] Skip scheduling IBs! [ 61.801012] [drm] Skip scheduling IBs! [ 61.801024] [drm] Skip scheduling IBs! [ 61.801052] [drm] Skip scheduling IBs! [ 61.801062] [drm] Skip scheduling IBs! [ 61.801096] [drm] Skip scheduling IBs! [ 61.801105] [drm] Skip scheduling IBs! [ 61.801137] [drm] Skip scheduling IBs! [ 61.801806] [drm:0xffffffffc24219b8] *ERROR* Failed to initialize parser -125! [ 61.808746] [drm:0xffffffffc24219b8] *ERROR* Failed to initialize parser -125! [ 61.809392] [drm:0xffffffffc24219b8] *ERROR* Failed to initialize parser -125! [ 61.809764] [drm:0xffffffffc24219b8] *ERROR* Failed to initialize parser -125! [ 61.810389] [drm:0xffffffffc24219b8] *ERROR* Failed to initialize parser -125! [ 61.810866] [drm:0xffffffffc24219b8] *ERROR* Failed to initialize parser -125! [ 61.812529] [drm:0xffffffffc24219b8] *ERROR* Failed to initialize parser -125! [ 61.813359] [drm:0xffffffffc24219b8] *ERROR* Failed to initialize parser -125! [ 61.814770] [drm:0xffffffffc24219b8] *ERROR* Failed to initialize parser -125! [ 61.816488] [drm:0xffffffffc24219b8] *ERROR* Failed to initialize parser -125! [ 62.541982] ucsi_acpi USBC000:00: PPM init failed (-110) [ 67.004898] amdgpu_cs_ioctl: 1467 callbacks suppressed Hardware: ASUS TUF506IU laptop (dual GPU Renoir and Nvidia GeForce GTX 1660 Ti Mobile) Detailed hardware in lspci.txt. Detailed modules in lsmod.txt. Kernle config attached in Kernel_config. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. [View Less]

2 20

[Bug 210301] New: *ERROR* IB test failed on gfx (-110) on Ryzen 4750u
by bugzilla-daemon＠bugzilla.kernel.org 11 Jun '22

11 Jun '22

https://bugzilla.kernel.org/show_bug.cgi?id=210301 Bug ID: 210301 Summary: *ERROR* IB test failed on gfx (-110) on Ryzen 4750u Product: Drivers Version: 2.5 Kernel Version: 5.9.8 Hardware: Intel OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org … [View More]Reporter: ar_registration(a)mailbox.org Regression: No Boting in a new Thinkpad T14 AMD (4750u), I get *sometimes* the following errors: 2020-11-21T16:45:15.53245 kern.err: [ 5.934142] amdgpu 0000:07:00.0: [drm:amdgpu_ib_ring_tests [amdgpu]] *ERROR* IB test failed on gfx (-110). 2020-11-21T16:45:15.53247 kern.err: [ 5.935598] [drm:process_one_work] *ERROR* ib ring test failed (-110). When this happens (typically 9/10 times) the machine eventually hangs. Sometimes with a page fault, sometimes with a general protection fault, but *always* in what appears to be the zfs calls. When the machine boots without the "*ERROR* IB test failed on gfx ", the machines *never* produces segmentation faults/general protection faults, even under very heavy i/o load. I have reproduced this problem: - In kernels 5.8.18, 5.9.6, 5.9.7, 5.9.8 - With two different SSD - With the firmware versions 20201118, 20201022, 20200918 - I have updated te BIOS two times (versions 1.09, 1.25, 1.27) I boot with the kernel command line options amd_iommu=on iommu=soft in order to avoid *another* error (AMD-Vi: Unable to read/write to IOMMU perf counter.) For example: 2020-10-24T22:00:29.88940 kern.warn: [ 1021.160344] general protection fault, probably for non-canonical address 0x3ff800040000000: 0000 [#1] SMP NOPTI 2020-10-24T22:00:29.89005 kern.warn: [ 1021.160348] CPU: 10 PID: 12746 Comm: bonnie++ Tainted: P O 5.8.16_1 #1 2020-10-24T22:00:29.89014 kern.warn: [ 1021.160349] Hardware name: LENOVO 20UDCTO1WW/20UDCTO1WW, BIOS R1BET40W(1.09 ) 08/07/2020 2020-10-24T22:00:29.89005 kern.warn: [ 1021.160348] CPU: 10 PID: 12746 Comm: bonnie++ Tainted: P O 5.8.16_1 #1 2020-10-24T22:00:29.89014 kern.warn: [ 1021.160349] Hardware name: LENOVO 20UDCTO1WW/20UDCTO1WW, BIOS R1BET40W(1.09 ) 08/07/2020 2020-10-24T22:00:29.89021 kern.warn: [ 1021.160385] RIP: 0010:dbuf_find+0x86/0x190 [zfs] 2020-10-24T22:00:29.89030 kern.warn: [ 1021.160387] Code: 7b 01 00 49 89 57 28 4a 8b 04 f0 48 85 c0 0f 84 b2 00 00 00 48 8b 0c 24 49 89 d6 eb 0d 48 8b 40 38 48 85 c0 0f 84 9c 00 00 00 <48> 39 18 75 ee 48 39 68 20 75 e8 44 38 68 50 75 e2 48 39 48 40 75 2020-10-24T22:00:29.89033 kern.warn: [ 1021.160387] RSP: 0018:ffffb3ff15a4ba28 EFLAGS: 00010206 2020-10-24T22:00:29.89030 kern.warn: [ 1021.160387] Code: 7b 01 00 49 89 57 28 4a 8b 04 f0 48 85 c0 0f 84 b2 00 00 00 48 8b 0c 24 49 89 d6 eb 0d 48 8b 40 38 48 85 c0 0f 84 9c 00 00 00 <48> 39 18 75 ee 48 39 68 20 75 e8 44 38 68 50 75 e2 48 39 48 40 75 2020-10-24T22:00:29.89033 kern.warn: [ 1021.160387] RSP: 0018:ffffb3ff15a4ba28 EFLAGS: 00010206 2020-10-24T22:00:29.89041 kern.warn: [ 1021.160389] RAX: 03ff800040000000 RBX: 00000000000587ce RCX: 0000000000001fd4 2020-10-24T22:00:29.89044 kern.warn: [ 1021.160389] RDX: ffff98bc4b6dbe00 RSI: 00000000000587ce RDI: ffffffffc11be4d0 2020-10-24T22:00:29.89046 kern.warn: [ 1021.160390] RBP: ffff98bc9cfa3000 R08: 99de27c9bb992351 R09: 9ae16a3b2f90404f 2020-10-24T22:00:29.89049 kern.warn: [ 1021.160391] R10: 0000000000000000 R11: ffff98bcca928000 R12: 0000000000030fc0 2020-10-24T22:00:29.89061 kern.warn: [ 1021.160391] R13: 0000000000000000 R14: ffff98bc4b6dbe00 R15: ffffffffc11be4d0 2020-10-24T22:00:29.89065 kern.warn: [ 1021.160392] FS: 00007f739cf48740(0000) GS:ffff98bccf080000(0000) knlGS:0000000000000000 2020-10-24T22:00:29.89070 kern.warn: [ 1021.160393] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 2020-10-24T22:00:29.89077 kern.warn: [ 1021.160393] CR2: 00007f790e77d280 CR3: 0000000757346000 CR4: 0000000000340ee0 2020-10-24T22:00:29.89081 kern.warn: [ 1021.160394] Call Trace: 2020-10-24T22:00:29.89084 kern.warn: [ 1021.160400] ? _cond_resched+0x15/0x30 2020-10-24T22:00:29.89088 kern.warn: [ 1021.160410] dbuf_hold_impl_arg+0x41/0x610 [zfs] 2020-10-24T22:00:29.89091 kern.warn: [ 1021.160413] ? spl_kmem_alloc+0xbf/0x100 [spl] 2020-10-24T22:00:29.89095 kern.warn: [ 1021.160424] dbuf_hold_impl+0x94/0xc0 [zfs] 2020-10-24T22:00:29.89098 kern.warn: [ 1021.160434] dbuf_hold_level+0x2b/0x60 [zfs] 2020-10-24T22:00:29.89102 kern.warn: [ 1021.160446] dmu_tx_check_ioerr+0x35/0xd0 [zfs] 2020-10-24T22:00:29.89105 kern.warn: [ 1021.160457] dmu_tx_count_write+0xe5/0x1a0 [zfs] 2020-10-24T22:00:29.89109 kern.warn: [ 1021.160468] dmu_tx_hold_write_by_dnode+0x35/0x50 [zfs] 2020-10-24T22:00:29.89112 kern.warn: [ 1021.160481] zfs_write+0x410/0xe00 [zfs] 2020-10-24T22:00:29.89116 kern.warn: [ 1021.160485] ? enqueue_entity+0xf1/0x580 2020-10-24T22:00:29.89121 kern.warn: [ 1021.160497] zpl_write_common_iovec+0xaf/0x100 [zfs] 2020-10-24T22:00:29.89126 kern.warn: [ 1021.160509] zpl_iter_write+0xed/0x120 [zfs] 2020-10-24T22:00:29.89129 kern.warn: [ 1021.160511] new_sync_write+0x11b/0x1b0 2020-10-24T22:00:29.89133 kern.warn: [ 1021.160513] vfs_write+0x1c3/0x1f0 2020-10-24T22:00:29.89136 kern.warn: [ 1021.160515] ksys_write+0x5f/0xe0 2020-10-24T22:00:29.89140 kern.warn: [ 1021.160516] do_syscall_64+0x44/0x70 2020-10-24T22:00:29.89145 kern.warn: [ 1021.160518] entry_SYSCALL_64_after_hwframe+0x44/0xa9 2020-10-24T22:00:29.89150 kern.warn: [ 1021.160519] RIP: 0033:0x7f739d4f7de3 2020-10-24T22:00:29.89155 kern.warn: [ 1021.160521] Code: 75 05 48 83 c4 58 c3 e8 9b 43 ff ff 66 2e 0f 1f 84 00 00 00 00 00 90 64 8b 04 25 18 00 00 00 85 c0 75 14 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 55 c3 0f 1f 40 00 48 83 ec 28 48 89 54 24 18 2020-10-24T22:00:29.89160 kern.warn: [ 1021.160521] RSP: 002b:00007ffee6a2caa8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 2020-10-24T22:00:29.89165 kern.warn: [ 1021.160522] RAX: ffffffffffffffda RBX: 00007ffee6a2caf0 RCX: 00007f739d4f7de3 2020-10-24T22:00:29.89177 kern.warn: [ 1021.160523] RDX: 0000000000002000 RSI: 00005623e29fd000 RDI: 0000000000000003 2020-10-24T22:00:29.89188 kern.warn: [ 1021.160523] RBP: 0000000000001d41 R08: 0000000000000000 R09: 0036343732312e00 2020-10-24T22:00:29.89202 kern.warn: [ 1021.160524] R10: 0000000000000180 R11: 0000000000000246 R12: 000000000001fd40 2020-10-24T22:00:29.89207 kern.warn: [ 1021.160524] R13: 00007ffee6a2caf0 R14: 00007ffee6a2cad0 R15: 00005623e29fd000 2020-10-24T22:00:29.89212 2020-10-24T22:00:29.89212 2020-10-24T22:00:29.89212 kern.warn: [ 1021.160525] Modules linked in: ctr ccm acpi_call(O) 8021q garp mrp stp llc uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev btusb mc btrtl btbcm btintel joydev snd_soc_dmic snd_acp3x_pdm_dma snd_acp3x_rn snd_soc_core snd_compress snd_pcm_dmaengine ac97_bus tps6598x typec roles edac_mce_amd kvm_amd iwlmvm kvm mac80211 irqbypass crct10dif_pclmul ghash_clmulni_intel snd_hda_codec_realtek aesni_intel libarc4 snd_hda_codec_generic snd_hda_codec_hdmi crypto_simd cryptd snd_hda_intel glue_helper snd_intel_dspcfg rapl iwlwifi snd_hda_codec psmouse input_leds pcspkr wmi_bmof snd_hda_core snd_hwdep ipmi_devintf cfg80211 r8169 snd_rn_pci_acp3x sp5100_tco tpm_crb snd_pcm snd_pci_acp3x ccp ipmi_msghandler realtek k10temp i2c_piix4 thinkpad_acpi i2c_multi_instantiate ledtrig_audio ac tpm_tis tpm_tis_core evdev mac_hid tpm i2c_scmi rng_core acpi_cpufreq i2c_designware_platform tiny_power_button i2c_designware_core snd_seq snd_seq_device snd_timer snd soundcore kern.warn: [ 1021.160525] Modules linked in: ctr ccm acpi_call(O) 8021q garp mrp stp llc uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev btusb mc btrtl btbcm btintel joydev snd_soc_dmic snd_acp3x_pdm_dma snd_acp3x_rn snd_soc_core snd_compress snd_pcm_dmaengine ac97_bus tps6598x typec roles edac_mce_amd kvm_amd iwlmvm kvm mac80211 irqbypass crct10dif_pclmul ghash_clmulni_intel snd_hda_codec_realtek aesni_intel libarc4 snd_hda_codec_generic snd_hda_codec_hdmi crypto_simd cryptd snd_hda_intel glue_helper snd_intel_dspcfg rapl iwlwifi snd_hda_codec psmouse input_leds pcspkr wmi_bmof snd_hda_core snd_hwdep ipmi_devintf cfg80211 r8169 snd_rn_pci_acp3x sp5100_tco tpm_crb snd_pcm snd_pci_acp3x ccp ipmi_msghandler realtek k10temp i2c_piix4 thinkpad_acpi i2c_multi_instantiate ledtrig_audio ac tpm_tis tpm_tis_core evdev mac_hid tpm i2c_scmi rng_core acpi_cpufreq i2c_designware_platform tiny_power_button i2c_designware_core snd_seq snd_seq_device snd_timer snd soundcore 2020-10-24T22:00:29.89238 kern.warn: [ 1021.160552] vhost_vsock vmw_vsock_virtio_transport_common vsock vhost_net vhost tap vhost_iotlb uhid hid hci_vhci bluetooth ecdh_generic rfkill ecc crc16 vfio_iommu_type1 vfio dm_mod uinput userio ppp_generic slhc tun loop nvram btrfs blake2b_generic xor raid6_pq libcrc32c crc32c_generic cuse fuse zfs(PO) zunicode(PO) zlua(PO) zavl(PO) icp(PO) amdgpu iommu_v2 gpu_sched i2c_algo_bit ttm rtsx_pci_sdmmc mmc_core drm_kms_helper syscopyarea sysfillrect zcommon(PO) sysimgblt fb_sys_fops cec znvpair(PO) rc_core xhci_pci xhci_pci_renesas spl(O) xhci_hcd ehci_pci crc32_pclmul drm crc32c_intel ehci_hcd serio_raw usbcore agpgart rtsx_pci wmi button battery video 2020-10-24T22:00:29.89243 kern.warn: [ 1021.160577] ---[ end trace 17b0063aeadb5c32 ]--- 2020-10-24T22:00:29.89248 kern.warn: [ 1021.160589] RIP: 0010:dbuf_find+0x86/0x190 [zfs] 2020-10-24T22:00:29.89253 kern.warn: [ 1021.160589] Code: 7b 01 00 49 89 57 28 4a 8b 04 f0 48 85 c0 0f 84 b2 00 00 00 48 8b 0c 24 49 89 d6 eb 0d 48 8b 40 38 48 85 c0 0f 84 9c 00 00 00 <48> 39 18 75 ee 48 39 68 20 75 e8 44 38 68 50 75 e2 48 39 48 40 75 2020-10-24T22:00:29.89267 kern.warn: [ 1021.160590] RSP: 0018:ffffb3ff15a4ba28 EFLAGS: 00010206 2020-10-24T22:00:29.89271 kern.warn: [ 1021.160591] RAX: 03ff800040000000 RBX: 00000000000587ce RCX: 0000000000001fd4 2020-10-24T22:00:29.89276 kern.warn: [ 1021.160591] RDX: ffff98bc4b6dbe00 RSI: 00000000000587ce RDI: ffffffffc11be4d0 2020-10-24T22:00:29.89281 kern.warn: [ 1021.160592] RBP: ffff98bc9cfa3000 R08: 99de27c9bb992351 R09: 9ae16a3b2f90404f 2020-10-24T22:00:29.89287 kern.warn: [ 1021.160592] R10: 0000000000000000 R11: ffff98bcca928000 R12: 0000000000030fc0 2020-10-24T22:00:29.89292 kern.warn: [ 1021.160593] R13: 0000000000000000 R14: ffff98bc4b6dbe00 R15: ffffffffc11be4d0 2020-10-24T22:00:29.89297 kern.warn: [ 1021.160593] FS: 00007f739cf48740(0000) GS:ffff98bccf080000(0000) knlGS:0000000000000000 2020-10-24T22:00:29.89302 kern.warn: [ 1021.160594] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 2020-10-24T22:00:29.89307 kern.warn: [ 1021.160594] CR2: 00007f790e77d280 CR3: 0000000757346000 CR4: 0000000000340ee0 -- You are receiving this mail because: You are watching the assignee of the bug. [View Less]

2 4

[PATCH] drm: adv7511: override i2c address of cec before accessing it
by Antonio Borneo 10 Jun '22

10 Jun '22

Commit 680532c50bca ("drm: adv7511: Add support for i2c_new_secondary_device") allows a device tree node to override the default addresses of the secondary i2c devices. This is useful for solving address conflicts on the i2c bus. In adv7511_init_cec_regmap() the new i2c address of cec device is read from device tree and immediately accessed, well before it is written in the proper register to override the default address. This can cause an i2c error during probe and a consequent probe failure. … [View More]

3 5

[PATCH] drm/msm: Switch ordering of runpm put vs devfreq_idle
by Rob Clark 09 Jun '22

09 Jun '22

From: Rob Clark <robdclark(a)chromium.org> I've seen a few crashes like: Internal error: synchronous external abort: 96000010 [#1] PREEMPT SMP Modules linked in: snd_seq_dummy snd_seq snd_seq_device bridge stp llc tun nf_nat_tftp nf_conntrack_tftp nf_nat_ftp nf_conntrack_ftp esp6 ah6 ip6t_REJECT ip6t_ipv6header vhost_vsock vhost vmw_vsock_virtio_transport_common vsock rfcomm algif_hash algif_skcipher af_alg uinput veth xt_cgroup xt_MASQUERADE venus_enc venus_dec … [View More]videobuf2_dma_contig qcom_spmi_adc5 qcom_spmi_adc_tm5 hci_uart qcom_vadc_common cros_ec_typec qcom_spmi_temp_alarm typec btqca snd_soc_rt5682_i2c snd_soc_rt5682 snd_soc_sc7180 bluetooth snd_soc_qcom_common snd_soc_rl6231 ecdh_generic ecc venus_core v4l2_mem2mem snd_soc_lpass_sc7180 snd_soc_lpass_hdmi snd_soc_lpass_cpu snd_soc_lpass_platform snd_soc_max98357a ip6table_nat fuse iio_trig_sysfs cros_ec_lid_angle cros_ec_sensors cros_ec_sensors_core industrialio_triggered_buffer kfifo_buf cros_ec_sensorhub lzo_rle ath10k_snoc lzo_compress ath10k_core ath zram mac80211 cfg80211 ax88179_178a usbnet mii uvcvideo videobuf2_vmalloc joydev CPU: 3 PID: 212 Comm: A618-worker Tainted: G W 5.4.139-16300-g88d8e1285982 #1 Hardware name: Google Pompom (rev1) with LTE (DT) pstate: 60c00009 (nZCv daif +PAN +UAO) pc : a6xx_gmu_set_oob+0x114/0x200 lr : a6xx_gmu_set_oob+0x10c/0x200 sp : ffffffc011b7bc20 x29: ffffffc011b7bc20 x28: ffffffdad27c5000 x27: 0000000000000001 x26: ffffffdad1521044 x25: ffffffbef7498338 x24: 0000000000000018 x23: 0000000000000002 x22: 0000000000014648 x21: 0000033732fe638b x20: 0000000080000000 x19: ffffffbef7433bc8 x18: 0000000040000000 x17: 000000243508d982 x16: 000000000000b67e x15: 00000000000090d4 x14: 0000000000000024 x13: 0000000000000024 x12: 0000000000017521 x11: 0000000000000b48 x10: 0000000000326a48 x9 : 1a130d33f6371600 x8 : ffffffc011e54648 x7 : 614948e00005003c x6 : ffffffbe3cd17e60 x5 : 0000000000000040 x4 : 0000000000000004 x3 : 0000000000000000 x2 : ffffffbef7488000 x1 : ffffffbef7488000 x0 : 0000000000000000 Call trace: a6xx_gmu_set_oob+0x114/0x200 a6xx_gmu_set_freq+0xe0/0x1fc msm_devfreq_target+0x80/0x13c msm_devfreq_idle+0x54/0x94 retire_submit+0x170/0x254 retire_submits+0xa4/0xdc retire_worker+0x1c/0x28 kthread_worker_fn+0xf4/0x1bc kthread+0x140/0x158 ret_from_fork+0x10/0x18 Code: 52800c81 9415bbe5 f9400a68 8b160108 (b9400108) ---[ end trace 16b871df2482cd61 ]--- Kernel panic - not syncing: Fatal exception SMP: stopping secondary CPUs Kernel Offset: 0x1ac1400000 from 0xffffffc010000000 PHYS_OFFSET: 0xffffffc280000000 CPU features: 0x88102e,2a80aa38 Memory Limit: none Which smells a lot like touching hw after power collapse. I'm not *entirely* sure how it could have taken 66ms (the autosuspend delay) before we get to a6xx_gmu_set_oob(), but to be safe we should move the pm_runtime_put_autosuspend() after msm_devfreq_idle(). Fixes: 9bc95570175a ("drm/msm: Devfreq tuning") Signed-off-by: Rob Clark <robdclark(a)chromium.org> --- drivers/gpu/drm/msm/msm_gpu.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c index d1a16642ecd5..2b2bbe7499e6 100644 --- a/drivers/gpu/drm/msm/msm_gpu.c +++ b/drivers/gpu/drm/msm/msm_gpu.c @@ -667,9 +667,6 @@ static void retire_submit(struct msm_gpu *gpu, struct msm_ringbuffer *ring, msm_submit_retire(submit); - pm_runtime_mark_last_busy(&gpu->pdev->dev); - pm_runtime_put_autosuspend(&gpu->pdev->dev); - spin_lock_irqsave(&ring->submit_lock, flags); list_del(&submit->node); spin_unlock_irqrestore(&ring->submit_lock, flags); @@ -683,6 +680,9 @@ static void retire_submit(struct msm_gpu *gpu, struct msm_ringbuffer *ring, mutex_unlock(&gpu->active_lock); msm_gem_submit_put(submit); + + pm_runtime_mark_last_busy(&gpu->pdev->dev); + pm_runtime_put_autosuspend(&gpu->pdev->dev); } static void retire_submits(struct msm_gpu *gpu) -- 2.31.1 [View Less]

4 8

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel February 2022