dri-devel April 2022

dri-devel@lists.freedesktop.org

351 participants
951 discussions

[PATCH v3 0/4] drm/dp: Introduce wait_hpd_asserted() for the DP AUX bus
by Douglas Anderson 14 Jun '22

14 Jun '22

This is the 2nd four patches from my RFC series ("drm/dp: Improvements for DP AUX channel") [1]. I've broken the series in two so we can make progress on the two halves separately. v2 of this series changes to add wait_hpd_asserted() instead of is_hpd_asserted(). This allows us to move the extra delay needed for ps8640 into the ps8640 driver itself. The idea for this series came up during the review process of Sankeerth's series trying to add eDP for Qualcomm SoCs [2]. This _doesn't_ attempt … [View More]

4 14

[PATCH v5 0/9] Add new formats support to vkms
by Igor Torrente 13 Jun '22

13 Jun '22

Summary ======= This series of patches refactor some vkms components in order to introduce new formats to the planes and writeback connector. Now in the blend function, the plane's pixels are converted to ARGB16161616 and then blended together. The CRC is calculated based on the ARGB1616161616 buffer. And if required, this buffer is copied/converted to the writeback buffer format. And to handle the pixel conversion, new functions were added to convert from a specific format to ARGB16161616 (… [View More]the reciprocal is also true). Tests ===== This patch series was tested using the following igt tests: -t ".*kms_plane.*" -t ".*kms_writeback.*" -t ".*kms_cursor_crc*" -t ".*kms_flip.*" New tests passing ------------------- - pipe-A-cursor-size-change - pipe-A-cursor-alpha-transparent Performance ----------- It's running slightly faster than the current implementation. Results running the IGT[1] test `igt@kms_cursor_crc@pipe-a-cursor-512x512-onscreen` ten times: | Frametime | |:--------------------------------------------:| | Implementation | Current | This commit | |:---------------:|:---------:|:--------------:| | frametime range | 9~22 ms | 10~22 ms | | Average | 11.4 ms | 12.32 ms | Memory consumption ================== It consumes less memory than the current implementation in the common case (more detail in the commit message). | Memory consumption (output dimensions) | |:--------------------------------------:| | Current | This patch | |:------------------:|:-----------------:| | Width * Heigth | 2 * Width | [1] IGT commit id: bc3f6833a12221a46659535dac06ebb312490eb4 XRGB to ARGB behavior ===================== During the development, I decided to always fill the alpha channel of the output pixel whenever the conversion from a format without an alpha channel to ARGB16161616 is necessary. Therefore, I ignore the value received from the XRGB and overwrite the value with 0xFFFF. Primary plane and CRTC size =========================== This patch series reworks the blend function to accept a primary plane with a different size and position from CRTC. Because now we need to fill the background, we had a loss in performance with this change --- Igor Torrente (9): drm: vkms: Alloc the compose frame using vzalloc drm: vkms: Replace hardcoded value of `vkms_composer.map` to DRM_FORMAT_MAX_PLANES drm: vkms: Rename `vkms_composer` to `vkms_frame_info` drm: drm_atomic_helper: Add a new helper to deal with the writeback connector validation drm: vkms: Add fb information to `vkms_writeback_job` drm: vkms: Refactor the plane composer to accept new formats drm: vkms: Supports to the case where primary plane doesn't match the CRTC drm: vkms: Adds XRGB_16161616 and ARGB_1616161616 formats drm: vkms: Add support to the RGB565 format Documentation/gpu/vkms.rst | 13 +- drivers/gpu/drm/drm_atomic_helper.c | 39 ++++ drivers/gpu/drm/vkms/Makefile | 1 + drivers/gpu/drm/vkms/vkms_composer.c | 325 ++++++++++++-------------- drivers/gpu/drm/vkms/vkms_crtc.c | 4 + drivers/gpu/drm/vkms/vkms_drv.h | 41 +++- drivers/gpu/drm/vkms/vkms_formats.c | 298 +++++++++++++++++++++++ drivers/gpu/drm/vkms/vkms_formats.h | 12 + drivers/gpu/drm/vkms/vkms_plane.c | 50 ++-- drivers/gpu/drm/vkms/vkms_writeback.c | 35 ++- include/drm/drm_atomic_helper.h | 3 + 11 files changed, 596 insertions(+), 225 deletions(-) create mode 100644 drivers/gpu/drm/vkms/vkms_formats.c create mode 100644 drivers/gpu/drm/vkms/vkms_formats.h -- 2.30.2 [View Less]

5 43

[PATCH v2 0/2] drm/vkms: check plane_composer->map[0] before using it
by Tales Lelo da Aparecida 13 Jun '22

13 Jun '22

Hi, this is a follow-up of my last patch. Thanks for the reviews! Changes from v1: Edit the first commit message as suggested by Melissa and add a commit to enhance the error handling (André) Tales Lelo da Aparecida (2): drm/vkms: check plane_composer->map[0] before using it drm/vkms: return early if compose_plane fails drivers/gpu/drm/vkms/vkms_composer.c | 32 ++++++++++++++++++---------- 1 file changed, 21 insertions(+), 11 deletions(-) -- 2.35.1

2 4

[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 V2 0/3] DSI host and peripheral initialisation ordering
by Dave Stevenson 10 Jun '22

10 Jun '22

Hi All Changes from v1: - New patch to refactor drm_bridge_chain_post_disable and drm_bridge_chain_pre_enable to reuse drm_atomic_bridge_chain_post_disable / drm_atomic_bridge_chain_pre_enable but with a NULL state. - New patch that adds a pre_enable_upstream_first to drm_panel. - changed from an OPS flag to a bool "pre_enable_upstream_first" in drm_bridge. - Followed Andrzej's suggestion of using continue in the main loop to avoid needing 2 additional loops (one forward to find the last … [View More]bridge wanting upstream first, and the second backwards again). - Actioned Laurent's review comments on docs patch. Original cover letter: Hopefully I've cc'ed all those that have bashed this problem around previously, or are otherwise linked to DRM bridges. There have been numerous discussions around how DSI support is currently broken as it doesn't support initialising the PHY to LP-11 and potentially the clock lane to HS prior to configuring the DSI peripheral. There is no op where the interface is initialised but HS video isn't also being sent. Currently you have: - peripheral pre_enable (host not initialised yet) - host pre_enable - encoder enable - host enable - peripheral enable (video already running) vc4 and exynos currently implement the DSI host as an encoder, and split the bridge_chain. This fails if you want to switch to being a bridge and/or use atomic calls as the state of all the elements split off are not added by drm_atomic_add_encoder_bridges. dw-mipi-dsi[1] and now msm[2] use the mode_set hook to initialise the PHY, so the bridge/panel pre_enable can send commands. In their post_disable they then call the downstream bridge/panel post_disable op manually so that shutdown commands can be sent before shutting down the PHY. Nothing handles that fact, so the framework then continues down the bridge chain and calls the post_disable again, so we get unbalanced panel prepare/unprepare calls being reported [3]. There have been patches[4] proposing reversing the entire direction of pre_enable and post_disable, but that risks driving voltage into devices that have yet to be powered up. There have been discussions about adding either a pre_pre_enable, or adding a DSI host_op to initialise the host[5]. Both require significant reworking to all existing drivers in moving initialisation phases. We have patches that look like they may well be addressing race conditions in starting up a DSI peripheral[6]. This patch takes a hybrid of the two: an optional reversing of the order for specific links within the bridge chain within pre_enable and post_disable done within the drm_bridge framework. I'm more than happy to move where the flag exists in structures (currently as DRM_BRIDGE_OP_UPSTREAM_FIRST in drm_bridge_ops, but it isn't an op), but does this solve the problem posed? If not, then can you describe the actual scenario it doesn't cover? A DSI peripheral can set the flag to get the DSI host initialised first, and therefore it has a stable LP-11 state before pre_enable. Likewise the peripheral can still send shutdown commands prior to the DSI host being shut down in post_disable. It also handles the case where there are multiple devices in the chain that all want their upstream bridge enabled first, so should there be a DSI mux between host and peripheral, then it can still get the host to the correct state. An example tree is at [7] which is drm-misc-next with these patches and then a conversion of vc4_dsi to use the atomic bridge functions (will be upstreamed once we're over this hurdle). It is working happily with the Toshiba TC358762 on a Raspberry Pi 7" panel. The same approach but on our vendor 5.15 tree[8] has also been tested successfully on a TI SN65DSI83 and LVDS panel. Whilst here, I've also documented the expected behaviour of DSI hosts and peripherals to aid those who come along after. Thanks Dave [1] https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/bridge/synops… [2] https://lists.freedesktop.org/archives/dri-devel/2022-January/337769.html [3] https://lists.freedesktop.org/archives/dri-devel/2021-December/333908.html [4] https://lists.freedesktop.org/archives/dri-devel/2021-October/328476.html [5] https://lists.freedesktop.org/archives/dri-devel/2021-October/325853.html [6] https://lists.freedesktop.org/archives/dri-devel/2022-February/341852.html [7] https://github.com/6by9/linux/tree/drm-misc-next-vc4_dsi [8] https://github.com/6by9/linux/tree/rpi-5.15.y-sn65dsi83 Dave Stevenson (4): drm/bridge: Remove duplication from drm_bridge and drm_atomic_bridge chains drm/bridge: Introduce pre_enable_upstream_first to alter bridge init order drm/panel: Add prepare_upstream_first flag to drm_panel drm/bridge: Document the expected behaviour of DSI host controllers Documentation/gpu/drm-kms-helpers.rst | 7 ++ drivers/gpu/drm/bridge/panel.c | 3 + drivers/gpu/drm/drm_bridge.c | 181 ++++++++++++++++++++++++---------- include/drm/drm_bridge.h | 8 ++ include/drm/drm_panel.h | 10 ++ 5 files changed, 159 insertions(+), 50 deletions(-) -- 2.7.4 [View Less]

7 21

[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

[PATCH 1/3] drm/panel: ltk050h3146w: add mipi_dsi_device.mode_flags to of_match_data
by quentin.schulz＠theobroma-systems.com 09 Jun '22

09 Jun '22

From: Quentin Schulz <quentin.schulz(a)theobroma-systems.com> To prepare for a new display to be supported by this driver which has a slightly different set of DSI mode related flags, let's move the currently hardcoded mode flags to the .data field of of_device_id structure. Cc: Quentin Schulz <foss+kernel(a)0leil.net> Signed-off-by: Quentin Schulz <quentin.schulz(a)theobroma-systems.com> --- drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c | 8 ++++++-- 1 file changed, 6 … [View More]

4 7

[PATCH v2 1/3] drm/panel: nt36672a: add backlight support
by Joel Selvaraj 08 Jun '22

08 Jun '22

Add support for backlight. This panel supports backlight control through the QCOM WLED driver in Xiaomi Poco F1 device. Signed-off-by: Joel Selvaraj <jo(a)jsfamily.in> --- drivers/gpu/drm/panel/panel-novatek-nt36672a.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/panel/panel-novatek-nt36672a.c b/drivers/gpu/drm/panel/panel-novatek-nt36672a.c index 231f371901e8..6d6ce42787e2 100644 --- a/drivers/gpu/drm/panel/panel-novatek-nt36672a.c +++ b/drivers/gpu/drm/panel/… [View More]

4 7

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel April 2022