aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2023-01-10drm/panel: olimex-lcd-olinuxino: Convert to i2c's .probe_new()Uwe Kleine-König1-3/+2
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by: Uwe Kleine-König <[email protected]> Reviewed-by: Javier Martinez Canillas <[email protected]> Signed-off-by: Javier Martinez Canillas <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-01-10drm/i2c/tda998x: Convert to i2c's .probe_new()Uwe Kleine-König1-2/+2
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by: Uwe Kleine-König <[email protected]> Reviewed-by: Javier Martinez Canillas <[email protected]> Signed-off-by: Javier Martinez Canillas <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-01-10drm/i2c/tda9950: Convert to i2c's .probe_new()Uwe Kleine-König1-3/+2
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by: Uwe Kleine-König <[email protected]> Reviewed-by: Javier Martinez Canillas <[email protected]> Signed-off-by: Javier Martinez Canillas <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-01-10drm/i2c/sil164: Convert to i2c's .probe_new()Uwe Kleine-König1-2/+2
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by: Uwe Kleine-König <[email protected]> Reviewed-by: Javier Martinez Canillas <[email protected]> Signed-off-by: Javier Martinez Canillas <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-01-10drm/i2c/ch7006: Convert to i2c's .probe_new()Uwe Kleine-König1-2/+2
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by: Uwe Kleine-König <[email protected]> Reviewed-by: Javier Martinez Canillas <[email protected]> Signed-off-by: Javier Martinez Canillas <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-01-10drm/mxsfb: improve clk handling for axi clkUwe Kleine-König1-6/+4
Ignoring errors from devm_clk_get() is wrong. To handle not all platforms having an axi clk use devm_clk_get_optional() instead and do proper error handling. Also the clk API handles NULL as a dummy clk (which is also returned by devm_clk_get_optional() if there is no clk) so there is no need to check for NULL before calling clk_prepare_enable() or its counter part. Signed-off-by: Uwe Kleine-König <[email protected]> Reviewed-by: Javier Martinez Canillas <[email protected]> Signed-off-by: Javier Martinez Canillas <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-01-10drm/meson: dw-hdmi: Fix devm_regulator_*get_enable*() conversionMarek Szyprowski1-1/+1
devm_regulator_get_enable_optional() function returns 0 on success, so use it for the check if function succeeded instead of the -ENODEV value. Fixes: 429e87063661 ("drm/meson: dw-hdmi: Use devm_regulator_*get_enable*()") Signed-off-by: Marek Szyprowski <[email protected]> Acked-by: Neil Armstrong <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> [narmstrong: s/succeeded/succeeded/ in commit message] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-01-09drm/vmwgfx: Remove rcu locks from user resourcesZack Rusin6-233/+87
User resource lookups used rcu to avoid two extra atomics. Unfortunately the rcu paths were buggy and it was easy to make the driver crash by submitting command buffers from two different threads. Because the lookups never show up in performance profiles replace them with a regular spin lock which fixes the races in accesses to those shared resources. Fixes kernel oops'es in IGT's vmwgfx execution_buffer stress test and seen crashes with apps using shared resources. Fixes: e14c02e6b699 ("drm/vmwgfx: Look up objects without taking a reference") Signed-off-by: Zack Rusin <[email protected]> Reviewed-by: Martin Krastev <[email protected]> Reviewed-by: Maaz Mombasawala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-01-10drm/virtio: Fix GEM handle creation UAFRob Clark1-2/+17
Userspace can guess the handle value and try to race GEM object creation with handle close, resulting in a use-after-free if we dereference the object after dropping the handle's reference. For that reason, dropping the handle's reference must be done *after* we are done dereferencing the object. Signed-off-by: Rob Clark <[email protected]> Reviewed-by: Chia-I Wu <[email protected]> Fixes: 62fb7a5e1096 ("virtio-gpu: add 3d/virgl support") Cc: [email protected] Signed-off-by: Dmitry Osipenko <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-01-09drm/radeon: free iio for atombios when driver shutdownLiwei Song1-0/+1
Fix below kmemleak when unload radeon driver: unreferenced object 0xffff9f8608ede200 (size 512): comm "systemd-udevd", pid 326, jiffies 4294682822 (age 716.338s) hex dump (first 32 bytes): 00 00 00 00 c4 aa ec aa 14 ab 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000062fadebe>] kmem_cache_alloc_trace+0x2f1/0x500 [<00000000b6883cea>] atom_parse+0x117/0x230 [radeon] [<00000000158c23fd>] radeon_atombios_init+0xab/0x170 [radeon] [<00000000683f672e>] si_init+0x57/0x750 [radeon] [<00000000566cc31f>] radeon_device_init+0x559/0x9c0 [radeon] [<0000000046efabb3>] radeon_driver_load_kms+0xc1/0x1a0 [radeon] [<00000000b5155064>] drm_dev_register+0xdd/0x1d0 [<0000000045fec835>] radeon_pci_probe+0xbd/0x100 [radeon] [<00000000e69ecca3>] pci_device_probe+0xe1/0x160 [<0000000019484b76>] really_probe.part.0+0xc1/0x2c0 [<000000003f2649da>] __driver_probe_device+0x96/0x130 [<00000000231c5bb1>] driver_probe_device+0x24/0xf0 [<0000000000a42377>] __driver_attach+0x77/0x190 [<00000000d7574da6>] bus_for_each_dev+0x7f/0xd0 [<00000000633166d2>] driver_attach+0x1e/0x30 [<00000000313b05b8>] bus_add_driver+0x12c/0x1e0 iio was allocated in atom_index_iio() called by atom_parse(), but it doesn't got released when the dirver is shutdown. Fix this kmemleak by free it in radeon_atombios_fini(). Signed-off-by: Liwei Song <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-01-09drm/amdgpu: clean up some inconsistent indentingsYang Li1-3/+3
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c:65 amdgpu_gem_fault() warn: inconsistent indenting Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=3639 Reported-by: Abaci Robot <[email protected]> Signed-off-by: Yang Li <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-01-09drm/amd: Load GFX11 microcode during early_initMario Limonciello1-19/+7
If GFX11 microcode is required but not available during early init, the firmware framebuffer will have already been released and the screen will freeze. Move the request for GFX11 microcode into the early_init phase so that if it's not available, driver init will fail. Reviewed-by: Alex Deucher <[email protected]> Reviewed-by: Lijo Lazar <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-01-09drm/amd: Use `amdgpu_ucode_*` helpers for GFX11Mario Limonciello2-72/+39
The `amdgpu_ucode_request` helper will ensure that the return code for missing firmware is -ENODEV so that early_init can fail. The `amdgpu_ucode_release` helper will provide symmetery on unload. Reviewed-by: Alex Deucher <[email protected]> Reviewed-by: Lijo Lazar <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-01-09drm/amd: Load GFX10 microcode during early_initMario Limonciello1-66/+18
Simplifies the code so that GFX10 will get the firmware name from `amdgpu_ucode_ip_version_decode` and then use this filename to load microcode as part of the early_init process. Any failures will cause the driver to fail to probe before the firmware framebuffer has been removed. Reviewed-by: Alex Deucher <[email protected]> Reviewed-by: Lijo Lazar <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-01-09drm/amd: Use `amdgpu_ucode_*` helpers for GFX10Mario Limonciello1-51/+20
The `amdgpu_ucode_request` helper will ensure that the return code for missing firmware is -ENODEV so that early_init can fail. The `amdgpu_ucode_release` helper is for symmetry on unload. Reviewed-by: Alex Deucher <[email protected]> Reviewed-by: Lijo Lazar <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-01-09drm/amd: Load GFX9 microcode during early_initMario Limonciello1-49/+9
If GFX9 microcode is required but not available during early init, the firmware framebuffer will have already been released and the screen will freeze. Reviewed-by: Alex Deucher <[email protected]> Reviewed-by: Lijo Lazar <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-01-09drm/amd: Use `amdgpu_ucode_*` helpers for GFX9Mario Limonciello1-61/+21
The `amdgpu_ucode_request` helper will ensure that the return code for missing firmware is -ENODEV so that early_init can fail. The `amdgpu_ucode_release` helper will provide symmetry on unload. Reviewed-by: Alex Deucher <[email protected]> Reviewed-by: Lijo Lazar <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-01-09drm/amd: Remove superfluous assignment for `adev->mes.adev`Mario Limonciello2-2/+0
`amdgpu_mes_init` already sets `adev->mes.adev`, so there is no need to also set it in the IP specific versions. Reviewed-by: Alex Deucher <[email protected]> Reviewed-by: Lijo Lazar <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-01-09drm/amd: Use `amdgpu_ucode_*` helpers for MESMario Limonciello3-26/+4
The `amdgpu_ucode_request` helper will ensure that the return code for missing firmware is -ENODEV so that early_init can fail. The `amdgpu_ucode_release` helper provides symmetry for releasing firmware. Reviewed-by: Alex Deucher <[email protected]> Reviewed-by: Lijo Lazar <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-01-09drm/amd: Load MES microcode during early_initMario Limonciello4-151/+100
Add an early_init phase to MES for fetching and validating microcode from the filesystem. If MES microcode is required but not available during early init, the firmware framebuffer will have already been released and the screen will freeze. Move the request for MES microcode into the early_init phase so that if it's not available, early_init will fail. Reviewed-by: Alex Deucher <[email protected]> Reviewed-by: Lijo Lazar <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-01-09drm/amd/display: Remove unneeded semicolonYang Li1-3/+3
./drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:7431:3-4: Unneeded semicolon ./drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:7485:4-5: Unneeded semicolon ./drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:7489:3-4: Unneeded semicolon Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=3635 Reported-by: Abaci Robot <[email protected]> Signed-off-by: Yang Li <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-01-09drm/amd/display: Remove redundant assignment to variable dcYi Yang1-1/+1
Smatch report warning as follows: Line 53679: drivers/gpu/drm/amd/display/dc/core/dc_stream.c:402 dc_stream_set_cursor_position() warn: variable dereferenced before check 'stream' The value of 'dc' has been assigned after check whether 'stream' is NULL. Fix it by remove redundant assignment. Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Yi Yang <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-01-09drm/amd/display: fix PSR-SU/DSC interoperability supportHamza Mahfooz3-0/+37
Currently, there are issues with enabling PSR-SU + DSC. This stems from the fact that DSC imposes a slice height on transmitted video data and we are not conforming to that slice height in PSR-SU regions. So, pass slice_height into su_y_granularity to feed the DSC slice height into PSR-SU code. Acked-by: Harry Wentland <[email protected]> Signed-off-by: Hamza Mahfooz <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-01-09drm/amd: Load VCN microcode during early_initMario Limonciello7-48/+31
Simplifies the code so that all VCN versions will get the firmware name from `amdgpu_ucode_ip_version_decode` and then use this filename to load microcode as part of the early_init process. Reviewed-by: Lijo Lazar <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-01-09drm/amd: Use `amdgpu_ucode_*` helpers for VCNMario Limonciello1-13/+3
The `amdgpu_ucode_request` helper will ensure that the return code for missing firmware is -ENODEV so that early_init can fail. The `amdgpu_ucode_release` helper is for symmetry. Reviewed-by: Alex Deucher <[email protected]> Reviewed-by: Lijo Lazar <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-01-09drm/amd: Make SDMA firmware load failures less noisy.Mario Limonciello1-3/+1
When firmware is missing we get failures at every step. ``` [ 3.855086] amdgpu 0000:04:00.0: Direct firmware load for amdgpu/green_sardine_sdma.bin failed with error -2 [ 3.855087] [drm:amdgpu_sdma_init_microcode [amdgpu]] *ERROR* SDMA: Failed to init firmware "amdgpu/green_sardine_sdma.bin" [ 3.855398] [drm:sdma_v4_0_early_init [amdgpu]] *ERROR* Failed to load sdma firmware! ``` Realistically we don't need all of these, a user can tell from the first one that request_firmware emitted what happened. Drop the others. Reviewed-by: Alex Deucher <[email protected]> Reviewed-by: Lijo Lazar <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-01-09drm/amd: Convert SDMA to use `amdgpu_ucode_ip_version_decode`Mario Limonciello6-157/+18
Simplifies the code so that all SDMA versions will get the firmware name from `amdgpu_ucode_ip_version_decode`. v2: squash in fix from Srinivasan Reviewed-by: Alex Deucher <[email protected]> Reviewed-by: Lijo Lazar <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-01-09drm/amd: Use `amdgpu_ucode_request` helper for SDMAMario Limonciello1-7/+2
The `amdgpu_ucode_request` helper will ensure that the return code for missing firmware is -ENODEV so that early_init can fail. Reviewed-by: Alex Deucher <[email protected]> Reviewed-by: Lijo Lazar <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-01-09drm/amdgpu: Fixed bug on error when unloading amdgpuYiPeng Chai1-1/+1
Fixed bug on error when unloading amdgpu. The error message is as follows: [ 377.706202] kernel BUG at drivers/gpu/drm/drm_buddy.c:278! [ 377.706215] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [ 377.706222] CPU: 4 PID: 8610 Comm: modprobe Tainted: G IOE 6.0.0-thomas #1 [ 377.706231] Hardware name: ASUS System Product Name/PRIME Z390-A, BIOS 2004 11/02/2021 [ 377.706238] RIP: 0010:drm_buddy_free_block+0x26/0x30 [drm_buddy] [ 377.706264] Code: 00 00 00 90 0f 1f 44 00 00 48 8b 0e 89 c8 25 00 0c 00 00 3d 00 04 00 00 75 10 48 8b 47 18 48 d3 e0 48 01 47 28 e9 fa fe ff ff <0f> 0b 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 54 55 48 89 f5 53 [ 377.706282] RSP: 0018:ffffad2dc4683cb8 EFLAGS: 00010287 [ 377.706289] RAX: 0000000000000000 RBX: ffff8b1743bd5138 RCX: 0000000000000000 [ 377.706297] RDX: ffff8b1743bd5160 RSI: ffff8b1743bd5c78 RDI: ffff8b16d1b25f70 [ 377.706304] RBP: ffff8b1743bd59e0 R08: 0000000000000001 R09: 0000000000000001 [ 377.706311] R10: ffff8b16c8572400 R11: ffffad2dc4683cf0 R12: ffff8b16d1b25f70 [ 377.706318] R13: ffff8b16d1b25fd0 R14: ffff8b1743bd59c0 R15: ffff8b16d1b25f70 [ 377.706325] FS: 00007fec56c72c40(0000) GS:ffff8b1836500000(0000) knlGS:0000000000000000 [ 377.706334] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 377.706340] CR2: 00007f9b88c1ba50 CR3: 0000000110450004 CR4: 00000000003706e0 [ 377.706347] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 377.706354] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 377.706361] Call Trace: [ 377.706365] <TASK> [ 377.706369] drm_buddy_free_list+0x2a/0x60 [drm_buddy] [ 377.706376] amdgpu_vram_mgr_fini+0xea/0x180 [amdgpu] [ 377.706572] amdgpu_ttm_fini+0x12e/0x1a0 [amdgpu] [ 377.706650] amdgpu_bo_fini+0x22/0x90 [amdgpu] [ 377.706727] gmc_v11_0_sw_fini+0x26/0x30 [amdgpu] [ 377.706821] amdgpu_device_fini_sw+0xa1/0x3c0 [amdgpu] [ 377.706897] amdgpu_driver_release_kms+0x12/0x30 [amdgpu] [ 377.706975] drm_dev_release+0x20/0x40 [drm] [ 377.707006] release_nodes+0x35/0xb0 [ 377.707014] devres_release_all+0x8b/0xc0 [ 377.707020] device_unbind_cleanup+0xe/0x70 [ 377.707027] device_release_driver_internal+0xee/0x160 [ 377.707033] driver_detach+0x44/0x90 [ 377.707039] bus_remove_driver+0x55/0xe0 [ 377.707045] pci_unregister_driver+0x3b/0x90 [ 377.707052] amdgpu_exit+0x11/0x6c [amdgpu] [ 377.707194] __x64_sys_delete_module+0x142/0x2b0 [ 377.707201] ? fpregs_assert_state_consistent+0x22/0x50 [ 377.707208] ? exit_to_user_mode_prepare+0x3e/0x190 [ 377.707215] do_syscall_64+0x38/0x90 [ 377.707221] entry_SYSCALL_64_after_hwframe+0x63/0xcd Signed-off-by: YiPeng Chai <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2023-01-09drm/amd: Delay removal of the firmware framebufferMario Limonciello2-6/+8
Removing the firmware framebuffer from the driver means that even if the driver doesn't support the IP blocks in a GPU it will no longer be functional after the driver fails to initialize. This change will ensure that unsupported IP blocks at least cause the driver to work with the EFI framebuffer. Cc: [email protected] Suggested-by: Alex Deucher <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Reviewed-by: Lijo Lazar <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-01-09drm/amdgpu: Fix potential NULL dereferenceLuben Tuikov1-2/+3
Fix potential NULL dereference, in the case when "man", the resource manager might be NULL, when/if we print debug information. Cc: Alex Deucher <[email protected]> Cc: Christian König <[email protected]> Cc: AMD Graphics <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: kernel test robot <[email protected]> Fixes: 7554886daa31ea ("drm/amdgpu: Fix size validation for non-exclusive domains (v4)") Signed-off-by: Luben Tuikov <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-01-09drm/amd: Add a new helper for loading/validating microcodeMario Limonciello2-0/+39
All microcode runs a basic validation after it's been loaded. Each IP block as part of init will run both. Introduce a wrapper for request_firmware and amdgpu_ucode_validate. This wrapper will also remap any error codes from request_firmware to -ENODEV. This is so that early_init will fail if firmware couldn't be loaded instead of the IP block being disabled. Reviewed-by: Lijo Lazar <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-01-09drm/amd: Convert SMUv13 microcode to use `amdgpu_ucode_ip_version_decode`Mario Limonciello1-10/+2
The special case for the one dGPU has been moved into `amdgpu_ucode_ip_version_decode`, so simplify this code. Signed-off-by: Mario Limonciello <[email protected]> Acked-by: Christian König <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Reviewed-by: Lijo Lazar <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-01-09drm/amd: Convert SMUv11 microcode to use `amdgpu_ucode_ip_version_decode`Mario Limonciello1-32/+3
Remove the special casing from SMU v11 code. No intended functional changes. Signed-off-by: Mario Limonciello <[email protected]> Acked-by: Christian König <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Reviewed-by: Lijo Lazar <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-01-09drm/amd: Add a legacy mapping to "amdgpu_ucode_ip_version_decode"Mario Limonciello1-0/+221
This will allow other parts of the driver that currently special case firmware file names to before IP version style naming to just have a single call to `amdgpu_ucode_ip_version_decode`. Signed-off-by: Mario Limonciello <[email protected]> Acked-by: Christian König <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Reviewed-by: Lijo Lazar <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-01-09drm/amd: Delay removal of the firmware framebufferMario Limonciello2-6/+8
Removing the firmware framebuffer from the driver means that even if the driver doesn't support the IP blocks in a GPU it will no longer be functional after the driver fails to initialize. This change will ensure that unsupported IP blocks at least cause the driver to work with the EFI framebuffer. Cc: [email protected] Suggested-by: Alex Deucher <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Reviewed-by: Lijo Lazar <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-01-09drm/amdgpu: Fix potential NULL dereferenceLuben Tuikov1-2/+3
Fix potential NULL dereference, in the case when "man", the resource manager might be NULL, when/if we print debug information. Cc: Alex Deucher <[email protected]> Cc: Christian König <[email protected]> Cc: AMD Graphics <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: kernel test robot <[email protected]> Fixes: 7554886daa31ea ("drm/amdgpu: Fix size validation for non-exclusive domains (v4)") Signed-off-by: Luben Tuikov <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-01-09drm/msm: clean event_thread->worker in case of an errorDmitry Baryshkov1-1/+1
If worker creation fails, nullify the event_thread->worker, so that msm_drm_uninit() doesn't try accessing invalid memory location. While we are at it, remove duplicate assignment to the ret variable. Fixes: 1041dee2178f ("drm/msm: use kthread_create_worker instead of kthread_run") Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/490106/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2023-01-09drm/panel: add visionox vtdr6130 DSI panel driverNeil Armstrong3-0/+367
Add support for the 1080x2400 Visionox VTDR6130 AMOLED DSI panel found on the Qualcomm SM8550 MTP board. By default the the panel is configured to work with DSI compressed streams, but can work in uncompressed video mode since 1080x2400 in RGB888 fits in the 4 DSI lanes bandwidth. While display compression is preferred for performance and power reasons, let's start with the uncompressed video mode support and add the DSC support later on. Reviewed-by: Sam Ravnborg <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> [narmstrong: moved drm/display/ include file before drm/drm_] Link: https://patchwork.freedesktop.org/patch/msgid/20230103-topic-sm8550-upstream-vtdr6130-panel-v2-2-dd6200f47a76@linaro.org
2023-01-09drm/i915: Fix potential context UAFsRob Clark1-6/+18
gem_context_register() makes the context visible to userspace, and which point a separate thread can trigger the I915_GEM_CONTEXT_DESTROY ioctl. So we need to ensure that nothing uses the ctx ptr after this. And we need to ensure that adding the ctx to the xarray is the *last* thing that gem_context_register() does with the ctx pointer. Signed-off-by: Rob Clark <[email protected]> Fixes: eb4dedae920a ("drm/i915/gem: Delay tracking the GEM context until it is registered") Fixes: a4c1cdd34e2c ("drm/i915/gem: Delay context creation (v3)") Fixes: 49bd54b390c2 ("drm/i915: Track all user contexts per client") Cc: <[email protected]> # v5.10+ Reviewed-by: Tvrtko Ursulin <[email protected]> Reviewed-by: Andi Shyti <[email protected]> [tursulin: Stable and fixes tags add/tidy.] Signed-off-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit bed4b455cf5374e68879be56971c1da563bcd90c) Signed-off-by: Rodrigo Vivi <[email protected]>
2023-01-09drm/i915: Reserve enough fence slot for i915_vma_unbind_asyncNirmoy Das1-1/+1
A nested dma_resv_reserve_fences(1) will not reserve slot from the 2nd call onwards and folowing dma_resv_add_fence() might hit the "BUG_ON(fobj->num_fences >= fobj->max_fences)" check. I915 hit above nested dma_resv case in ttm_bo_handle_move_mem() with async unbind: dma_resv_reserve_fences() from --> ttm_bo_handle_move_mem() dma_resv_reserve_fences() from --> i915_vma_unbind_async() dma_resv_add_fence() from --> i915_vma_unbind_async() dma_resv_add_fence() from -->ttm_bo_move_accel_cleanup() Resolve this by adding an extra fence in i915_vma_unbind_async(). Suggested-by: Thomas Hellström <[email protected]> Fixes: 2f6b90da9192 ("drm/i915: Use vma resources for async unbinding") Cc: <[email protected]> # v5.18+ Signed-off-by: Nirmoy Das <[email protected]> Reviewed-by: Matthew Auld <[email protected]> Signed-off-by: Matthew Auld <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 4f0755c2faf7388616109717facc5bbde6850e60) Signed-off-by: Rodrigo Vivi <[email protected]>
2023-01-09drm/vc4: vec: Support progressive modesMateusz Kwiatkowski1-1/+3
The VEC is able to output progressive analog modes, but the driver has never set the proper bit to do so. Signed-off-by: Mateusz Kwiatkowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2023-01-09drm/vc4: hdmi: Correct interlaced timings againDave Stevenson1-2/+3
The back porch timings were correct, only the sync offset was wrong. Correct timing is now reported for 1080i and 576i, but the h offset is incorrect for 480i for non-obvious reasons. Fixes: fb10dc451c0f ("drm/vc4: hdmi: Correct HDMI timing registers for interlaced modes") Signed-off-by: Dave Stevenson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2023-01-09drm/vc4: crtc: Fix timings for VEC modesMateusz Kwiatkowski1-27/+44
This commit fixes vertical timings of the VEC (composite output) modes to accurately represent the 525-line ("NTSC") and 625-line ("PAL") ITU-R standards. Previous timings were actually defined as 502 and 601 lines, resulting in non-standard 62.69 Hz and 52 Hz signals being generated, respectively. Changes to vc4_crtc.c have also been made, to make the PixelValve vertical timings accurately correspond to the DRM modeline in interlaced modes. The resulting VERTA/VERTB register values have been verified against the reference values set by the Raspberry Pi firmware. Signed-off-by: Mateusz Kwiatkowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2023-01-09drm/vc4: Add comments for which HVS_PIXEL_ORDER_xxx defines applyDave Stevenson1-0/+3
The HVS_PIXEL_ORDER_xxx defines apply to specific HVS_PIXEL_FORMAT_xxx modes, so add comments to make this obvious. Signed-off-by: Dave Stevenson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2023-01-09drm/vc4: plane: Add 3:3:2 and 4:4:4:4 RGB/RGBX/RGBA formatsDave Stevenson1-0/+70
The hardware supports the 332 8bpp and 4:4:4:4 16bpp formats, but the table of supported formats didn't include them. Add them in. In theory they are supported for T-format as well as linear, but without a way to test them just add them as linear for now. Signed-off-by: Dave Stevenson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2023-01-09drm/vc4: plane: Omit pixel_order from the hvs_format for hvs5 only formatsDave Stevenson1-5/+0
pixel_order is used for the earlier versions of the HVS, so is redundant on the 10:10:10:2 and 10bit YUV formats that are only supported on HVS5. Remove the assignment from the table to avoid confusion. Signed-off-by: Dave Stevenson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2023-01-09drm/vc4: plane: Allow using 0 as a pixel order valueDave Stevenson1-6/+14
vc4_plane_mode_set for HVS5 was using pixel_order unless pixel_order_hvs5 was non-zero, except 0 is a valid value for the pixel_order. Specify pixel_order_hvs5 for all formats and remove the conditional. Signed-off-by: Dave Stevenson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2023-01-09drm/vc4: hvs: Ignore atomic_flush if we're disabledMaxime Ripard1-0/+3
atomic_flush will be called for each CRTC even if they aren't enabled. The whole code we have there will thus run without a properly affected channel, which can then result in all sorts of weird behaviour. Reviewed-by: Dave Stevenson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2023-01-09drm/vc4: hvs: Add DRM 210101010 RGB formatsDave Stevenson1-0/+28
HVS5 supports the 210101010 RGB[A|X] formats, but they were missing from the DRM to HVS mapping list, so weren't available. Add them in. Signed-off-by: Dave Stevenson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.