aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2024-04-15drm/fb_dma: Add generic get_scanout_buffer() for drm_panicJocelyn Falempe1-0/+42
This was initialy done for imx6, but should work on most drivers using drm_fb_dma_helper. v8: * Replace get_scanout_buffer() logic with drm_panic_set_buffer() (Thomas Zimmermann) v9: * go back to get_scanout_buffer() * move get_scanout_buffer() to plane helper functions v12: * Rename drm_panic_gem_get_scanout_buffer to drm_fb_dma_get_scanout_buffer (Thomas Zimmermann) * Remove the #ifdef CONFIG_DRM_PANIC, and build it unconditionnaly, as it's a small function. (Thomas Zimmermann) Signed-off-by: Jocelyn Falempe <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Acked-by: Daniel Vetter <[email protected]>
2024-04-15drm/panic: Add debugfs entry to test without triggering panic.Jocelyn Falempe2-1/+52
Add a debugfs file, so you can test drm_panic without freezing your machine. This is unsafe, and should be enabled only for developer or tester. To display the drm_panic screen on the device 0: echo 1 > /sys/kernel/debug/dri/0/drm_panic_plane_0 v9: * Create a debugfs file for each plane in the device's debugfs directory. This allows to test for each plane of each GPU independently. Signed-off-by: Jocelyn Falempe <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Acked-by: Daniel Vetter <[email protected]>
2024-04-15drm/panic: Add support for color format conversionJocelyn Falempe1-10/+263
Add support for the following formats: DRM_FORMAT_RGB565 DRM_FORMAT_RGBA5551 DRM_FORMAT_XRGB1555 DRM_FORMAT_ARGB1555 DRM_FORMAT_RGB888 DRM_FORMAT_XRGB8888 DRM_FORMAT_ARGB8888 DRM_FORMAT_XBGR8888 DRM_FORMAT_XRGB2101010 DRM_FORMAT_ARGB2101010 v10: * move and simplify the functions from the drm format helper to drm_panic v12: * Use array for map and pitch in struct drm_scanout_buffer to support multi-planar format later. (Thomas Zimmermann) Signed-off-by: Jocelyn Falempe <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Acked-by: Daniel Vetter <[email protected]>
2024-04-15drm/panic: Add a drm panic handlerJocelyn Falempe4-0/+318
This module displays a user friendly message when a kernel panic occurs. It currently doesn't contain any debug information, but that can be added later. v2 * Use get_scanout_buffer() instead of the drm client API. (Thomas Zimmermann) * Add the panic reason to the panic message (Nerdopolis) * Add an exclamation mark (Nerdopolis) v3 * Rework the drawing functions, to write the pixels line by line and to use the drm conversion helper to support other formats. (Thomas Zimmermann) v4 * Use drm_fb_r1_to_32bit for fonts (Thomas Zimmermann) * Remove the default y to DRM_PANIC config option (Thomas Zimmermann) * Add foreground/background color config option * Fix the bottom lines not painted if the framebuffer height is not a multiple of the font height. * Automatically register the device to drm_panic, if the function get_scanout_buffer exists. (Thomas Zimmermann) v5 * Change the drawing API, use drm_fb_blit_from_r1() to draw the font. * Also add drm_fb_fill() to fill area with background color. * Add draw_pixel_xy() API for drivers that can't provide a linear buffer. * Add a flush() callback for drivers that needs to synchronize the buffer. * Add a void *private field, so drivers can pass private data to draw_pixel_xy() and flush(). v6 * Fix sparse warning for panic_msg and logo. v7 * Add select DRM_KMS_HELPER for the color conversion functions. v8 * Register directly each plane to the panic notifier (Sima) * Add raw_spinlock to properly handle concurrency (Sima) * Register plane instead of device, to avoid looping through plane list, and simplify code. * Replace get_scanout_buffer() logic with drm_panic_set_buffer() (Thomas Zimmermann) * Removed the draw_pixel_xy() API, will see later if it can be added back. v9 * Revert to using get_scanout_buffer() (Sima) * Move get_scanout_buffer() and panic_flush() to the plane helper functions (Thomas Zimmermann) * Register all planes with get_scanout_buffer() to the panic notifier * Use drm_panic_lock() to protect against race (Sima) v10 * Move blit and fill functions back in drm_panic (Thomas Zimmermann). * Simplify the text drawing functions. * Use kmsg_dumper instead of panic_notifier (Sima). v12 * Use array for map and pitch in struct drm_scanout_buffer to support multi-planar format later. (Thomas Zimmermann) * Better indent struct drm_scanout_buffer declaration. (Thomas Zimmermann) Signed-off-by: Jocelyn Falempe <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Acked-by: Daniel Vetter <[email protected]>
2024-04-15drm/panic: Add drm panic lockingDaniel Vetter2-0/+5
Rough sketch for the locking of drm panic printing code. The upshot of this approach is that we can pretty much entirely rely on the atomic commit flow, with the pair of raw_spin_lock/unlock providing any barriers we need, without having to create really big critical sections in code. This also avoids the need that drivers must explicitly update the panic handler state, which they might forget to do, or not do consistently, and then we blow up in the worst possible times. It is somewhat racy against a concurrent atomic update, and we might write into a buffer which the hardware will never display. But there's fundamentally no way to avoid that - if we do the panic state update explicitly after writing to the hardware, we might instead write to an old buffer that the user will barely ever see. Note that an rcu protected deference of plane->state would give us the the same guarantees, but it has the downside that we then need to protect the plane state freeing functions with call_rcu too. Which would very widely impact a lot of code and therefore doesn't seem worth the complexity compared to a raw spinlock with very tiny critical sections. Plus rcu cannot be used to protect access to peek/poke registers anyway, so we'd still need it for those cases. Peek/poke registers for vram access (or a gart pte reserved just for panic code) are also the reason I've gone with a per-device and not per-plane spinlock, since usually these things are global for the entire display. Going with per-plane locks would mean drivers for such hardware would need additional locks, which we don't want, since it deviates from the per-console takeoverlocks design. Longer term it might be useful if the panic notifiers grow a bit more structure than just the absolute bare EXPORT_SYMBOL(panic_notifier_list) - somewhat aside, why is that not EXPORT_SYMBOL_GPL ... If panic notifiers would be more like console drivers with proper register/unregister interfaces we could perhaps reuse the very fancy console lock with all it's check and takeover semantics that John Ogness is developing to fix the console_lock mess. But for the initial cut of a drm panic printing support I don't think we need that, because the critical sections are extremely small and only happen once per display refresh. So generally just 60 tiny locked sections per second, which is nothing compared to a serial console running a 115kbaud doing really slow mmio writes for each byte. So for now the raw spintrylock in drm panic notifier callback should be good enough. Another benefit of making panic notifiers more like full blown consoles (that are used in panics only) would be that we get the two stage design, where first all the safe outputs are used. And then the dangerous takeover tricks are deployed (where for display drivers we also might try to intercept any in-flight display buffer flips, which if we race and misprogram fifos and watermarks can hang the memory controller on some hw). For context the actual implementation on the drm side is by Jocelyn and this patch is meant to be combined with the overall approach in v7 (v8 is a bit less flexible, which I think is the wrong direction): https://lore.kernel.org/dri-devel/[email protected]/ Note that the locking is very much not correct there, hence this separate rfc. Starting from v10, I (Jocelyn) have included this patch in the drm_panic series, and done the corresponding changes. v2: - fix authorship, this was all my typing - some typo oopsies - link to the drm panic work by Jocelyn for context v10: - Use spinlock_irqsave/restore (John Ogness) v11: - Use macro instead of inline functions for drm_panic_lock/unlock (John Ogness) Signed-off-by: Daniel Vetter <[email protected]> Cc: Jocelyn Falempe <[email protected]> Cc: Andrew Morton <[email protected]> Cc: "Peter Zijlstra (Intel)" <[email protected]> Cc: Lukas Wunner <[email protected]> Cc: Petr Mladek <[email protected]> Cc: Steven Rostedt <[email protected]> Cc: John Ogness <[email protected]> Cc: Sergey Senozhatsky <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Signed-off-by: Jocelyn Falempe <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Acked-by: Daniel Vetter <[email protected]>
2024-04-15drm: prefer DRM_MODE_FMT/ARG over drm_mode_debug_printmodeline()Jani Nikula5-20/+17
We have DRM_MODE_FMT and DRM_MODE_ARG() macros to allow unified debug printing of modes in any printk-formatted logging. Prefer them over drm_mode_debug_printmodeline(). This allows drm device specific logging of modes, in the right drm debug category, and inline with the rest of the logging instead of split to multiple lines. Suggested-by: Ville Syrjälä <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Reviewed-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/6df18588dfa17c5d0a1501f5af9ff21f25a1981b.1712568037.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-04-15drm/crtc-helper: switch to drm device based logging and warnsJani Nikula1-43/+52
Prefer drm device based drm_dbg_kms(), drm_err(), drm_WARN_ON() over DRM_DEBUG_KMS(), DRM_ERROR(), and WARN_ON(). Also update encoder, connector, and crtc logging to include the object id and name, where possible. Reviewed-by: Ville Syrjälä <[email protected]> Reviewed-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/b8557c4b2db0e5c931a6d82b5cc8ac5f3a3e1a77.1712568037.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-04-15drm/crtc: switch to drm device based loggingJani Nikula1-19/+17
Prefer drm device based drm_dbg_kms() over DRM_DEBUG_KMS(). Reviewed-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/187a7e8e350569a78ebe02ff83ac3b933c8a5355.1712568037.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-04-15drm/client: switch to drm device based logging, and moreJani Nikula1-59/+70
Switch to drm device based logging and WARNs, and unify connector and crtc logging formats. Pass drm device around a bit more to be able to do this. Drop logging for -ENOMEM. Reviewed-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/4fb77e6039bcda7448d1187bc5cd7a5ac4d393aa.1712568037.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-04-15drm/sysfs: switch to drm device based loggingJani Nikula1-10/+10
Prefer drm_dbg_kms() and drm_dbg_lease() over DRM_DEBUG_KMS() and DRM_DEBUG() to debug log the drm device info. Fix some debug categories and unify connector logging while at it. v2: Drop superfluous newline Reviewed-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/7f3dd5b4a33f964c6903c7a964da5397f4084aeb.1712568037.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-04-15drm/modes: switch to drm device based error loggingJani Nikula1-16/+17
Prefer drm_err() and drm_dbg_kms() over DRM_ERROR() and DRM_DEBUG_KMS(). Reviewed-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/3342dd2e98fedd618e5aeef26c44044cd32ead20.1712568037.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-04-15drm/probe-helper: switch to drm device based loggingJani Nikula1-19/+17
Prefer drm_dbg_kms() over DRM_DEBUG_KMS() to debug log the drm device info. v2: Drop changes to mode printing (Ville) Reviewed-by: Thomas Zimmermann <[email protected]> # v1 Link: https://patchwork.freedesktop.org/patch/msgid/8b6a83edd1c3896b9d652b5368702eba5f382a1c.1712568037.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-04-15drm/i915/bios: return drm_edid_product_id from get_lvds_pnp_id()Jani Nikula1-4/+4
Use a more suitable type to avoid the cast. Cc: Ville Syrjälä <[email protected]> Acked-by: Melissa Wen <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/4dc7bfc48e65d29829843941a70c8bf97b87abcc.1712655867.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-04-15drm/i915/bios: switch to struct drm_edid and struct drm_edid_product_idJani Nikula1-25/+18
To avoid accessing and parsing the raw EDID with drm_edid_raw(), switch to the struct drm_edid based function to extract product id, and use the drm printer function to debug log it. The underlying assumption is that struct drm_edid_product_id and struct lvds_pnp_id describe identical data, albeit with slightly different member definitions. Cc: Ville Syrjälä <[email protected]> Acked-by: Melissa Wen <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/ec5148dd43221b32cb2066bc7fd264a069c1188b.1712655867.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-04-15drm/edid: add drm_edid_print_product_id()Jani Nikula1-0/+44
Add a function to print a decoded EDID vendor and product id to a drm printer, optionally with the raw data. v2: - refactor date printing - use seq_buf to avoid kasprintf() (Ville) - handle week == 0 (Ville) - use be16_to_cpu() on manufacturer_name Cc: Ville Syrjälä <[email protected]> Acked-by: Melissa Wen <[email protected]> # v1 Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/32bbc83ee6557809ef6d7a5edb1bc8ef4d56d10f.1712655867.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-04-15drm/edid: add drm_edid_get_product_id()Jani Nikula1-0/+15
Add a struct drm_edid based function to get the vendor and product ID from an EDID. Add a separate struct for defining this part of the EDID, with defined byte order for manufacturer name, product code and serial number. v2: Define manufacturer_name as __be16 instead of u8[2] (Ville) Cc: Ville Syrjälä <[email protected]> Acked-by: Melissa Wen <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/df0e7dedbf7f2c190039d6e6eae3e126eba113c9.1712655867.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-04-15drm: nv04: Fix out of bounds accessMikhail Kobuk1-6/+7
When Output Resource (dcb->or) value is assigned in fabricate_dcb_output(), there may be out of bounds access to dac_users array in case dcb->or is zero because ffs(dcb->or) is used as index there. The 'or' argument of fabricate_dcb_output() must be interpreted as a number of bit to set, not value. Utilize macros from 'enum nouveau_or' in calls instead of hardcoding. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 2e5702aff395 ("drm/nouveau: fabricate DCB encoder table for iMac G4") Fixes: 670820c0e6a9 ("drm/nouveau: Workaround incorrect DCB entry on a GeForce3 Ti 200.") Signed-off-by: Mikhail Kobuk <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-15nouveau: fix instmem race condition around ptr storesDave Airlie1-1/+6
Running a lot of VK CTS in parallel against nouveau, once every few hours you might see something like this crash. BUG: kernel NULL pointer dereference, address: 0000000000000008 PGD 8000000114e6e067 P4D 8000000114e6e067 PUD 109046067 PMD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 7 PID: 53891 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27 Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021 RIP: 0010:gp100_vmm_pgt_mem+0xe3/0x180 [nouveau] Code: c7 48 01 c8 49 89 45 58 85 d2 0f 84 95 00 00 00 41 0f b7 46 12 49 8b 7e 08 89 da 42 8d 2c f8 48 8b 47 08 41 83 c7 01 48 89 ee <48> 8b 40 08 ff d0 0f 1f 00 49 8b 7e 08 48 89 d9 48 8d 75 04 48 c1 RSP: 0000:ffffac20c5857838 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 00000000004d8001 RCX: 0000000000000001 RDX: 00000000004d8001 RSI: 00000000000006d8 RDI: ffffa07afe332180 RBP: 00000000000006d8 R08: ffffac20c5857ad0 R09: 0000000000ffff10 R10: 0000000000000001 R11: ffffa07af27e2de0 R12: 000000000000001c R13: ffffac20c5857ad0 R14: ffffa07a96fe9040 R15: 000000000000001c FS: 00007fe395eed7c0(0000) GS:ffffa07e2c980000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 000000011febe001 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ... ? gp100_vmm_pgt_mem+0xe3/0x180 [nouveau] ? gp100_vmm_pgt_mem+0x37/0x180 [nouveau] nvkm_vmm_iter+0x351/0xa20 [nouveau] ? __pfx_nvkm_vmm_ref_ptes+0x10/0x10 [nouveau] ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] ? __lock_acquire+0x3ed/0x2170 ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] nvkm_vmm_ptes_get_map+0xc2/0x100 [nouveau] ? __pfx_nvkm_vmm_ref_ptes+0x10/0x10 [nouveau] ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] nvkm_vmm_map_locked+0x224/0x3a0 [nouveau] Adding any sort of useful debug usually makes it go away, so I hand wrote the function in a line, and debugged the asm. Every so often pt->memory->ptrs is NULL. This ptrs ptr is set in the nv50_instobj_acquire called from nvkm_kmap. If Thread A and Thread B both get to nv50_instobj_acquire around the same time, and Thread A hits the refcount_set line, and in lockstep thread B succeeds at refcount_inc_not_zero, there is a chance the ptrs value won't have been stored since refcount_set is unordered. Force a memory barrier here, I picked smp_mb, since we want it on all CPUs and it's write followed by a read. v2: use paired smp_rmb/smp_wmb. Cc: <[email protected]> Fixes: be55287aa5ba ("drm/nouveau/imem/nv50: embed nvkm_instobj directly into nv04_instobj") Signed-off-by: Dave Airlie <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-15drm: fix DRM_DISPLAY_DP_HELPER dependencies, part 2Arnd Bergmann2-2/+2
After my fix yesterday, I ran into another problem of the same kind: aarch64-linux-ld: drivers/gpu/drm/bridge/analogix/analogix_dp_core.o: in function `drm_dp_dpcd_readb': analogix_dp_core.c:(.text+0x194): undefined reference to `drm_dp_dpcd_read' aarch64-linux-ld: drivers/gpu/drm/bridge/analogix/analogix_dp_core.o: in function `drm_dp_dpcd_writeb': analogix_dp_core.c:(.text+0x214): undefined reference to `drm_dp_dpcd_write' aarch64-linux-ld: drivers/gpu/drm/bridge/analogix/analogix_dp_core.o: in function `analogix_dp_stop_crc': analogix_dp_core.c:(.text+0x4b0): undefined reference to `drm_dp_stop_crc' aarch64-linux-ld: drivers/gpu/drm/bridge/analogix/analogix_dp_core.o: in function `analogix_dp_start_crc': analogix_dp_core.c:(.text+0xbe8): undefined reference to `drm_dp_start_crc' Add the same dependency again to ROCKCHIP_ANALOGIX_DP after checking that nothing else selects the analogix driver. Also add a dependency to DRM_ANALOGIX_DP to make it easier to identifier future problems of this type when they get introduced. Fixes: 0323287de87d ("drm: Switch DRM_DISPLAY_DP_HELPER to depends on") Fixes: d1ef8fc18be6 ("drm: fix DRM_DISPLAY_DP_HELPER dependencies") Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-15drm: vc4: Fix possible null pointer dereferenceAleksandr Mishin1-0/+2
In vc4_hdmi_audio_init() of_get_address() may return NULL which is later dereferenced. Fix this bug by adding NULL check. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: bb7d78568814 ("drm/vc4: Add HDMI audio support") Signed-off-by: Aleksandr Mishin <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-15drm/lima: fix void pointer to enum lima_gpu_id cast warningErico Nunes2-3/+23
Create a simple data struct to hold compatible data so that we don't have to do the casts to void pointer to hold data. Fixes the following warning: drivers/gpu/drm/lima/lima_drv.c:387:13: error: cast to smaller integer type 'enum lima_gpu_id' from 'const void *' Signed-off-by: Erico Nunes <[email protected]> Signed-off-by: Qiang Yu <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-15drm/lima: fix shared irq handling on driver removeErico Nunes3-0/+11
lima uses a shared interrupt, so the interrupt handlers must be prepared to be called at any time. At driver removal time, the clocks are disabled early and the interrupts stay registered until the very end of the remove process due to the devm usage. This is potentially a bug as the interrupts access device registers which assumes clocks are enabled. A crash can be triggered by removing the driver in a kernel with CONFIG_DEBUG_SHIRQ enabled. This patch frees the interrupts at each lima device finishing callback so that the handlers are already unregistered by the time we fully disable clocks. Signed-off-by: Erico Nunes <[email protected]> Signed-off-by: Qiang Yu <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-15drm/lima: mask irqs in timeout path before hard resetErico Nunes1-0/+7
There is a race condition in which a rendering job might take just long enough to trigger the drm sched job timeout handler but also still complete before the hard reset is done by the timeout handler. This runs into race conditions not expected by the timeout handler. In some very specific cases it currently may result in a refcount imbalance on lima_pm_idle, with a stack dump such as: [10136.669170] WARNING: CPU: 0 PID: 0 at drivers/gpu/drm/lima/lima_devfreq.c:205 lima_devfreq_record_idle+0xa0/0xb0 ... [10136.669459] pc : lima_devfreq_record_idle+0xa0/0xb0 ... [10136.669628] Call trace: [10136.669634] lima_devfreq_record_idle+0xa0/0xb0 [10136.669646] lima_sched_pipe_task_done+0x5c/0xb0 [10136.669656] lima_gp_irq_handler+0xa8/0x120 [10136.669666] __handle_irq_event_percpu+0x48/0x160 [10136.669679] handle_irq_event+0x4c/0xc0 We can prevent that race condition entirely by masking the irqs at the beginning of the timeout handler, at which point we give up on waiting for that job entirely. The irqs will be enabled again at the next hard reset which is already done as a recovery by the timeout handler. Signed-off-by: Erico Nunes <[email protected]> Reviewed-by: Qiang Yu <[email protected]> Signed-off-by: Qiang Yu <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-15drm/lima: include pp bcast irq in timeout handler checkErico Nunes1-0/+2
In commit 53cb55b20208 ("drm/lima: handle spurious timeouts due to high irq latency") a check was added to detect an unexpectedly high interrupt latency timeout. With further investigation it was noted that on Mali-450 the pp bcast irq may also be a trigger of race conditions against the timeout handler, so add it to this check too. Signed-off-by: Erico Nunes <[email protected]> Signed-off-by: Qiang Yu <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-15drm/lima: add mask irq callback to gp and ppErico Nunes5-0/+42
This is needed because we want to reset those devices in device-agnostic code such as lima_sched. In particular, masking irqs will be useful before a hard reset to prevent race conditions. Signed-off-by: Erico Nunes <[email protected]> Signed-off-by: Qiang Yu <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-14drm/i915/guc: Remove usage of the deprecated ida_simple_xx() APIChristophe JAILLET1-7/+6
ida_alloc() and ida_free() should be preferred to the deprecated ida_simple_get() and ida_simple_remove(). Note that the upper limit of ida_simple_get() is exclusive, but the one of ida_alloc_range() is inclusive. So a -1 has been added when needed. Signed-off-by: Christophe JAILLET <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/7108c1871c6cb08d403c4fa6534bc7e6de4cb23d.1705245316.git.christophe.jaillet@wanadoo.fr Signed-off-by: Rodrigo Vivi <[email protected]>
2024-04-12drm/xe/pf: Add support to configure GuC SR-IOV policiesMichal Wajdeczko6-0/+502
There are few knobs inside GuC firmware to control VFs scheduling. Add basic functions to support their reconfigurations. We will start using them shortly once we prepare debugfs. Signed-off-by: Michal Wajdeczko <[email protected]> Cc: Piotr Piórkowski <[email protected]> Reviewed-by: Piotr Piórkowski <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-12drm/xe/guc: Add helpers for GuC KLVsMichal Wajdeczko3-0/+186
Many of the GuC actions use KLVs to pass additional parameters or configuration data. Add few helper functions for better reporting any information related to KLVs. Cc: Himal Prasad Ghimiray <[email protected]> Reviewed-by: Piotr Piórkowski <[email protected]> Acked-by: Himal Prasad Ghimiray <[email protected]> Signed-off-by: Michal Wajdeczko <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-12drm/xe/guc: Add PF2GUC_UPDATE_VGT_POLICY to ABIMichal Wajdeczko1-0/+47
In upcoming patches the PF driver will add support to change GuC policies and will need to use PF2GUC_UPDATE_VGT_POLICY messages. Add necessary definitions to our GuC firmware ABI header. Reviewed-by: Piotr Piórkowski <[email protected]> Signed-off-by: Michal Wajdeczko <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-12drm/xe/pf: Introduce helper functions for use by PFMichal Wajdeczko2-0/+81
PF driver will maintain VF's configuration data mostly on the GT level, but some internal data is located at the device level. To allow easy access to that data from the GT level functions, and to minimize code duplications, introduce set of helper functions and macros for explicit use by the PF driver. We will use these helpers in upcoming patches. Reviewed-by: Piotr Piórkowski <[email protected]> Signed-off-by: Michal Wajdeczko <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-12drm/xe/pf: Introduce mutex to protect VFs configurationsMichal Wajdeczko4-0/+32
PF driver will maintain configurations and resources for every VF and this data could span multiple tiles and/or GTs. Prepare mutex to protect data that we will add in upcoming patches. Reviewed-by: Piotr Piórkowski <[email protected]> Signed-off-by: Michal Wajdeczko <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-12Merge drm/drm-next into drm-xe-nextThomas Hellström719-9883/+181421
Backmerging drm-next in order to get up-to-date and in particular to access commit 9ca5facd0400f610f3f7f71aeb7fc0b949a48c67. Signed-off-by: Thomas Hellström <[email protected]>
2024-04-12drm/xe: Use hmm_range_fault to populate user pagesOak Zeng1-111/+6
This is an effort to unify hmmptr (aka system allocator) and userptr code. hmm_range_fault is used to populate a virtual address range for both hmmptr and userptr, instead of hmmptr using hmm_range_fault and userptr using get_user_pages_fast. This also aligns with AMD gpu driver's behavior. In long term, we plan to put some common helpers in this area to drm layer so it can be re-used by different vendors. -v1 use the function with parameter to confirm whether lock is acquired by the caller or needs to be acquired in hmm_range_fault. Reviewed-by: Matthew Brost <[email protected]> Cc: Matthew Brost <[email protected]> Signed-off-by: Oak Zeng <[email protected]> Signed-off-by: Himal Prasad Ghimiray <[email protected]> Signed-off-by: Thomas Hellström <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-12drm/xe: Introduce helper to populate userptrOak Zeng4-0/+267
Introduce a helper function xe_userptr_populate_range to populate a userptr range. This functions calls hmm_range_fault to read CPU page tables and populate all pfns/pages of this virtual address range. For system memory page, dma-mapping is performed to get a dma-address which can be used later for GPU to access pages. v1: Address review comments: separate a npage_in_range function (Matt) reparameterize function xe_userptr_populate_range function (Matt) move mmu_interval_read_begin() call into while loop (Thomas) s/mark_range_accessed/xe_mark_range_accessed (Thomas) use set_page_dirty_lock (vs set_page_dirty) (Thomas) move a few checking in xe_vma_userptr_pin_pages to hmm.c (Matt) v2: Remove device private page support. Only support system pages for now. use dma-map-sg rather than dma-map-page (Matt/Thomas) v3: Address review comments: Squash patch "drm/xe: Introduce a helper to free sg table" to current patch (Matt) start and end addresses are already page aligned (Matt) Do mmap_read_lock and mmap_read_unlock for hmm_range_fault incase of non system allocator call. (Matt) Drop kthread_use_mm and kthread_unuse_mm. (Matt) No need of kernel-doc for static functions.(Matt) Modify function names. (Matt) Free sgtable incase of dma_map_sgtable failure.(Matt) Modify loop for hmm_range_fault.(Matt) v4: Remove the dummy function for xe_hmm_userptr_populate_range since CONFIG_HMM_MIRROR is needed. (Matt) Change variable names start/end to userptr_start/userptr_end.(Matt) v5: Remove device private page support info from commit message. Since the patch doesn't support device page handling. (Thomas) Signed-off-by: Oak Zeng <[email protected]> Co-developed-by: Niranjana Vishwanathapura <[email protected]> Signed-off-by: Niranjana Vishwanathapura <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Cc: Matthew Brost <[email protected]> Cc: Thomas Hellström <[email protected]> Cc: Brian Welty <[email protected]> Signed-off-by: Himal Prasad Ghimiray <[email protected]> Signed-off-by: Thomas Hellström <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-12drm/arm/malidp: fix a possible null pointer dereferenceHuai-Yuan Liu1-1/+4
In malidp_mw_connector_reset, new memory is allocated with kzalloc, but no check is performed. In order to prevent null pointer dereferencing, ensure that mw_state is checked before calling __drm_atomic_helper_connector_reset. Fixes: 8cbc5caf36ef ("drm: mali-dp: Add writeback connector") Signed-off-by: Huai-Yuan Liu <[email protected]> Signed-off-by: Liviu Dudau <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-12drm/xe: Fix bo leak in intel_fb_bo_framebuffer_initMaarten Lankhorst1-2/+6
Add a unreference bo in the error path, to prevent leaking a bo ref. Return 0 on success to clarify the success path. Signed-off-by: Maarten Lankhorst <[email protected]> Fixes: 44e694958b95 ("drm/xe/display: Implement display support") Cc: <[email protected]> # v6.8+ Reviewed-by: Nirmoy Das <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-12gpu: host1x: Add Tegra SE to SID tableAkhil R1-0/+24
Add Tegra Security Engine details to the SID table in host1x driver. These entries are required to be in place to configure the stream ID for SE. Register writes to stream ID registers fail otherwise. Signed-off-by: Akhil R <[email protected]> Acked-by: Mikko Perttunen <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2024-04-12drm/amd/display: Add a function for checking tmds modeChris Park1-0/+13
[Why] DVI is TMDS signal like HDMI but without audio. Current signal check does not correctly reflect DVI clock programming. [How] Define a new signal check for TMDS that includes DVI to HDMI TMDS programming. Reviewed-by: Dillon Varone <[email protected]> Acked-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Chris Park <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2024-04-12drm/amd/display: Modify power sequenceSung Joon Kim5-12/+247
Need to update the power sequence to help prevent potential issues like multi-display or multi-plane. Reviewed-by: Duncan Ma <[email protected]> Acked-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Sung Joon Kim <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2024-04-12drm/amd/display: 3.2.280Aric Cyr1-1/+1
This version brings along the following: - DCN10 fixes - DCN316 fixes - DML2 fixes - DWB fixes - Expanded FAMS support - Misc code style fixes - ODM fixes - VSC SDP fixes Acked-by: Hamza Mahfooz <[email protected]> Signed-off-by: Aric Cyr <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2024-04-12drm/amd/display: Reorganize dwb headerRodrigo Siqueira1-11/+19
This commit makes some small adjustments in the dwb header. Acked-by: Hamza Mahfooz <[email protected]> Signed-off-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2024-04-12drm/amdkfd: Fix memory leak in create_process failureFelix Kuehling1-2/+2
Fix memory leak due to a leaked mmget reference on an error handling code path that is triggered when attempting to create KFD processes while a GPU reset is in progress. Fixes: 0ab2d7532b05 ("drm/amdkfd: prepare per-process debug enable and disable") CC: Xiaogang Chen <[email protected]> Signed-off-by: Felix Kuehling <[email protected]> Tested-by: Harish Kasiviswanthan <[email protected]> Reviewed-by: Mukul Joshi <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2024-04-12drm/amd/display: Change DPCD address rangeRodrigo Siqueira1-1/+1
Change DP_PHY_REPEATER_EXTENDED_WAIT_TIMEOUT with DP_PHY_REPEATER_128B132B_RATES. Acked-by: Hamza Mahfooz <[email protected]> Signed-off-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2024-04-12drm/amd/display: Add fallback configuration for set DRR in DCN10Rodrigo Siqueira1-3/+12
Set OTG/OPTC parameters to 0 if something goes wrong on DCN10. Acked-by: Hamza Mahfooz <[email protected]> Signed-off-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2024-04-12drm/amd/display: Add fallback configuration when set DRRRodrigo Siqueira1-2/+9
Set OTG/OPTC parameter to 0 if failed to set DRR. Acked-by: Hamza Mahfooz <[email protected]> Signed-off-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2024-04-12drm/amd/display: Update DCN10 resourceRodrigo Siqueira1-0/+2
Update DCN10 to use legacy fast update and ensure that the MPCC count is the same as the pipe_count. Acked-by: Hamza Mahfooz <[email protected]> Signed-off-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2024-04-12drm/amd/display: Disable P010 Support of DCN 1.0Rodrigo Siqueira1-1/+1
[WHY] DCN 1.0 is not ready for the P010 support. [HOW] 1. Set the P010 plan_cap of DCN 1.0 to be false. 2. Let the DM do the plan cap initialization of DCN 1.0. Reviewed-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Figo Wang <[email protected]> Signed-off-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2024-04-12drm/amd/display: Update resource capabilities and debug struct for DCN201Rodrigo Siqueira1-1/+3
Some of the resource capabilities for DCN201 and the debug default option are outdated. This commit just set some of the missing configurations for DCN201. Acked-by: Hamza Mahfooz <[email protected]> Signed-off-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2024-04-12drm/amd/display: Drop legacy codeRodrigo Siqueira4-53/+1
This commit removes code that are not used by display anymore. Acked-by: Hamza Mahfooz <[email protected]> Signed-off-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2024-04-12drm/amd/display: Adjust some includes used by displayRodrigo Siqueira7-7/+1
Some of the includes used in the DC can be removed and others need to be update. This commit adjusts some of those headers in the display code. Acked-by: Hamza Mahfooz <[email protected]> Signed-off-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.