summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2025-04-16drm/amd/display/dml2: use vzalloc rather than kzallocAlex Deucher2-7/+10
The structures are large and they do not require contiguous memory so use vzalloc. Fixes: 70839da63605 ("drm/amd/display: Add new DCN401 sources") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4126 Cc: Aurabindo Pillai <aurabindo.pillai@amd.com> Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 20c50a9a793300a1fc82f3ddd0e3c68f8213fbef) Cc: stable@vger.kernel.org
2025-04-16drm/amdgpu: Add back JPEG to video caps for carrizo and newerDavid Rosca1-0/+7
JPEG is not supported on Vega only. Fixes: 0a6e7b06bdbe ("drm/amdgpu: Remove JPEG from vega and carrizo video caps") Signed-off-by: David Rosca <david.rosca@amd.com> Reviewed-by: Leo Liu <leo.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 0f4dfe86fe922c37bcec99dce80a15b4d5d4726d) Cc: stable@vger.kernel.org
2025-04-16drm/amdgpu: fix warning of drm_mm_cleanZhenGuo Yin1-1/+1
Kernel doorbell BOs needs to be freed before ttm_fini. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4145 Fixes: 54c30d2a8def ("drm/amdgpu: create kernel doorbell pages") Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: ZhenGuo Yin <zhenguo.yin@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 39938a8ed979e398faa3791a47e282c82bcc6f04) Cc: stable@vger.kernel.org
2025-04-16drm/amd: Forbid suspending into non-default suspend statesMario Limonciello2-1/+14
On systems that default to 'deep' some userspace software likes to try to suspend in 'deep' first. If there is a failure for any reason (such as -ENOMEM) the failure is ignored and then it will try to use 's2idle' as a fallback. This fails, but more importantly it leads to graphical problems. Forbid this behavior and only allow suspending in the last state supported by the system. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4093 Acked-by: Alex Deucher <alexander.deucher@amd.com> Link: https://lore.kernel.org/r/20250408180957.4027643-1-superm1@kernel.org Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 2aabd44aa8a3c08da3d43264c168370f6da5e81d)
2025-04-16drm/amdgpu: use a dummy owner for sysfs triggered cleaner shaders v4Christian König1-3/+11
Otherwise triggering sysfs multiple times without other submissions in between only runs the shader once. v2: add some comment v3: re-add missing cast v4: squash in semicolon fix Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 8b2ae7d492675e8af8902f103364bef59382b935)
2025-04-16drm/edid: Refactor DisplayID timing block structsEgor Vorontsov2-23/+23
Using le16 instead of u8[2]. Suggested-by: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Egor Vorontsov <sdoregor@sdore.me> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/a7967d7884d48b15ca08ae78d687e73124f0ba04.1744708239.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-04-16drm/edid: Implement DisplayID Type IX & X timing blocks parsingEgor Vorontsov2-0/+76
Some newer high refresh rate consumer monitors (including those by Samsung) make use of DisplayID 2.1 timing blocks in their EDID data, notably for their highest refresh rate modes. Such modes won't be available as of now. Implement partial support for such blocks in order to enable native support of HRR modes of most such monitors for users without having to rely on EDID patching/override (or need thereof). Closes: https://gitlab.freedesktop.org/drm/misc/kernel/-/issues/55 Suggested-by: Maximilian Boße <max@bosse.io> Signed-off-by: Egor Vorontsov <sdoregor@sdore.me> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/d795d27c6f60596df402ff151ce29938e2ad4f53.1744708239.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-04-16drm/panel: boe-bf060y8m-aj0: transition to mipi_dsi wrapped functionsTejas Vipin1-70/+44
Changes the boe-bf060y8m-aj0 panel to use multi style functions for improved error handling. Additionally the MIPI_DSI_MODE_LPM flag is set after the off commands are run in boe_bf060y8m_aj0_off regardless of any failures, and regulators are disabled if the boe_bf060y8m_aj0_on call in boe_bf060y8m_aj0_prepare fails. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Tejas Vipin <tejasvipin76@gmail.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20250413035959.255842-1-tejasvipin76@gmail.com
2025-04-16gpu: drm: xlnx: zynqmp_dp: Use dev_err_probe()Zhang Enpei1-4/+2
Replace the open-code with dev_err_probe() to simplify the code. Signed-off-by: Zhang Enpei <zhang.enpei@zte.com.cn> Signed-off-by: Shao Mingyin <shao.mingyin@zte.com.cn> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://lore.kernel.org/r/20250402193852834atJ7eho66TlnKOIMSvpfr@zte.com.cn Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
2025-04-16drm: xlnx: zynqmp_dpsub: use snd_soc_dummy_dlcKuninori Morimoto1-4/+1
struct zynqmp_dp_audio :: components has codec component, but it is used as dummy DAI. OTOH, We can use common snd_soc_dummy_dlc. Let's use common dummy_dlc instead of own component. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Tested-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://lore.kernel.org/r/87ecxvr25o.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
2025-04-16drm/i915/pxp: fix undefined reference to `intel_pxp_gsccs_is_ready_for_sessions'Chen Linxuan1-2/+6
On x86_64 with gcc version 13.3.0, I compile kernel with: make defconfig ./scripts/kconfig/merge_config.sh .config <( echo CONFIG_COMPILE_TEST=y ) make KCFLAGS="-fno-inline-functions -fno-inline-small-functions -fno-inline-functions-called-once" Then I get a linker error: ld: vmlinux.o: in function `pxp_fw_dependencies_completed': kintel_pxp.c:(.text+0x95728f): undefined reference to `intel_pxp_gsccs_is_ready_for_sessions' This is caused by not having a intel_pxp_gsccs_is_ready_for_sessions() header stub for CONFIG_DRM_I915_PXP=n. Add it. Signed-off-by: Chen Linxuan <chenlinxuan@uniontech.com> Fixes: 99afb7cc8c44 ("drm/i915/pxp: Add ARB session creation and cleanup") Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/20250415090616.2649889-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-04-16drm/xe/dma_buf: stop relying on placement in unmapMatthew Auld1-4/+1
The is_vram() is checking the current placement, however if we consider exported VRAM with dynamic dma-buf, it looks possible for the xe driver to async evict the memory, notifying the importer, however importer does not have to call unmap_attachment() immediately, but rather just as "soon as possible", like when the dma-resv idles. Following from this we would then pipeline the move, attaching the fence to the manager, and then update the current placement. But when the unmap_attachment() runs at some later point we might see that is_vram() is now false, and take the complete wrong path when dma-unmapping the sg, leading to explosions. To fix this check if the sgl was mapping a struct page. v2: - The attachment can be mapped multiple times it seems, so we can't really rely on encoding something in the attachment->priv. Instead see if the page_link has an encoded struct page. For vram we expect this to be NULL. Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/4563 Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: <stable@vger.kernel.org> # v6.8+ Acked-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20250410162716.159403-2-matthew.auld@intel.com
2025-04-16drm/xe/userptr: fix notifier vs folio deadlockMatthew Auld1-24/+0
User is reporting what smells like notifier vs folio deadlock, where migrate_pages_batch() on core kernel side is holding folio lock(s) and then interacting with the mappings of it, however those mappings are tied to some userptr, which means calling into the notifier callback and grabbing the notifier lock. With perfect timing it looks possible that the pages we pulled from the hmm fault can get sniped by migrate_pages_batch() at the same time that we are holding the notifier lock to mark the pages as accessed/dirty, but at this point we also want to grab the folio locks(s) to mark them as dirty, but if they are contended from notifier/migrate_pages_batch side then we deadlock since folio lock won't be dropped until we drop the notifier lock. Fortunately the mark_page_accessed/dirty is not really needed in the first place it seems and should have already been done by hmm fault, so just remove it. Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/4765 Fixes: 0a98219bcc96 ("drm/xe/hmm: Don't dereference struct page pointers without notifier lock") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Thomas Hellström <thomas.hellstrom@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: <stable@vger.kernel.org> # v6.10+ Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250414132539.26654-2-matthew.auld@intel.com
2025-04-16drm/virtio: Support drm_panic with non-vmapped shmem BORyosuke Yasuoka1-3/+11
Pass array of pages of the scanout buffer to shmem BO, allowing drm_panic to work even if the BO is not vmapped. Link: https://lore.kernel.org/all/20250407140138.162383-3-jfalempe@redhat.com/ Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com> Signed-off-by: Ryosuke Yasuoka <ryasuoka@redhat.com> Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> [dmitry.osipenko@collabora.com: rebased on misc-next, fixed minor checkpatch warn] [dmitry.osipenko@collabora.com: changed commit message to use link tag] Link: https://lore.kernel.org/all/20250412132012.291837-1-ryasuoka@redhat.com/
2025-04-16drm/virtio: Use dma_buf from GEM object instanceThomas Zimmermann1-3/+2
Avoid dereferencing struct drm_gem_object.import_attach for the imported dma-buf. The dma_buf field in the GEM object instance refers to the same buffer. Prepares to make import_attach optional. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://lore.kernel.org/r/20250414131507.566072-3-tzimmermann@suse.de
2025-04-16drm/virtio: Test for imported buffers with drm_gem_is_imported()Thomas Zimmermann2-5/+5
Instead of testing import_attach for imported GEM buffers, invoke drm_gem_is_imported() to do the test. The helper tests the dma_buf itself while import_attach is just an artifact of the import. Prepares to make import_attach optional. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://lore.kernel.org/r/20250414131507.566072-2-tzimmermann@suse.de
2025-04-15drm/xe: Adjust ringbuf emission for maximum possible sizeTvrtko Ursulin1-1/+1
MAX_JOB_SIZE_DW seems to be undersized. For the worst case emission from __emit_job_gen12_render_compute I hand count 57 dwords so lets bump this to an even 58. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reviewed-by: Francois Dugast <francois.dugast@intel.com> Link: https://lore.kernel.org/r/20250403190317.6064-2-tvrtko.ursulin@igalia.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-04-15drm/i915/irq: convert ibx_irq_reset() into ibx_display_irq_reset()Jani Nikula3-20/+20
Observe that ibx_irq_reset() is really ibx_display_irq_reset(). Make it so. Move to display, and call it directly from gen8_display_irq_reset() instead of gen8_irq_reset(). Remove a nearby ancient stale comment while at it. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/20250409184702.3790548-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-04-15drm/imagination: Add support for TI AM68 GPUMatt Coster1-0/+2
Since we already added a generic compatible string for all IMG Rogue GPUs ("img,img-rogue"), all that's needed here is to link the appropriate firmware for the BXS-4-64 GPU in the AM68. Reviewed-by: Frank Binns <frank.binns@imgtec.com> Link: https://lore.kernel.org/r/20250410-sets-bxs-4-64-patch-v1-v6-16-eda620c5865f@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-04-15drm/imagination: Use cached memory with dma_coherentMatt Coster3-6/+18
The TI k3-j721s2 platform does not allow us to use uncached memory (which is what the driver currently does) without disabling cache snooping on the AXI ACE-Lite interface, which would be too much of a performance hit. Given the platform is dma-coherent, we can simply force all device-accessible memory allocations through the CPU cache. In fact, this can be done whenever the dma_coherent attribute is present. Reviewed-by: Frank Binns <frank.binns@imgtec.com> Link: https://lore.kernel.org/r/20250410-sets-bxs-4-64-patch-v1-v6-15-eda620c5865f@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-04-15drm/imagination: Add RISC-V firmware processor supportSarah Walker6-8/+244
Newer PowerVR GPUs (such as the BXS-4-64 MC1) use a RISC-V firmware processor instead of the previous MIPS or META. The current version of this patch depends on a patch[1] which exists in drm-misc-fixes, but has not yet made it back to drm-misc-next (the target of this patch). That patch adds the function pvr_vm_unmap_obj() which is used here. [1]: https://lore.kernel.org/r/20250226-hold-drm_gem_gpuva-lock-for-unmap-v2-1-3fdacded227f@imgtec.com Signed-off-by: Sarah Walker <sarah.walker@imgtec.com> Reviewed-by: Frank Binns <frank.binns@imgtec.com> Link: https://lore.kernel.org/r/20250410-sets-bxs-4-64-patch-v1-v6-14-eda620c5865f@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-04-15drm/imagination: Move ELF fw utils to common fileMatt Coster4-56/+74
Currently only MIPS firmware processors use ELF-formatted firmware. When adding support for RISC-V firmware processors, it will be useful to have ELF handling functions ready to go. Reviewed-by: Frank Binns <frank.binns@imgtec.com> Link: https://lore.kernel.org/r/20250410-sets-bxs-4-64-patch-v1-v6-13-eda620c5865f@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-04-15drm/imagination: Use callbacks for fw irq handlingMatt Coster4-44/+63
This allows for more versatility in checking and clearing firmware registers used for interrupt handling. Reviewed-by: Frank Binns <frank.binns@imgtec.com> Link: https://lore.kernel.org/r/20250410-sets-bxs-4-64-patch-v1-v6-12-eda620c5865f@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-04-15drm/imagination: Use a lookup table for fw defsMatt Coster3-9/+23
With more than two firmware processor types, the if/else chain in pvr_fw_init() gets a bit ridiculous. Use a static array indexed on pvr_fw_processor_type (which is now a proper enum instead of #defines) instead. Reviewed-by: Frank Binns <frank.binns@imgtec.com> Link: https://lore.kernel.org/r/20250410-sets-bxs-4-64-patch-v1-v6-11-eda620c5865f@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-04-15drm/imagination: Make has_fixed_data_addr a valueMatt Coster4-30/+11
This is currently a callback function which takes no parameters; there's no reason for this so let's make it a straightforward value in pvr_fw_defs. Reviewed-by: Frank Binns <frank.binns@imgtec.com> Link: https://lore.kernel.org/r/20250410-sets-bxs-4-64-patch-v1-v6-10-eda620c5865f@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-04-15drm/imagination: Rename event_mask -> status_maskMatt Coster3-5/+5
Now that enable_reg isn't used, rename the previously shared event_mask to status_mask since it's only used with status_reg. Reviewed-by: Frank Binns <frank.binns@imgtec.com> Link: https://lore.kernel.org/r/20250410-sets-bxs-4-64-patch-v1-v6-9-eda620c5865f@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-04-15drm/imagination: Remove firmware enable_regMatt Coster4-13/+1
After a previous commit ("drm/imagination: Mask GPU IRQs in threaded handler"), this register is now only used to enable firmware interrupts at start-of-day. This is, however, unnecessary since they are enabled by default. In addition, the soon-to-be-added RISC-V firmware processors do not have an equivalent register. Reviewed-by: Frank Binns <frank.binns@imgtec.com> Link: https://lore.kernel.org/r/20250410-sets-bxs-4-64-patch-v1-v6-8-eda620c5865f@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-04-15drm/imagination: Handle Rogue safety event IRQsAlessio Belle3-2/+117
Extend interrupt handling logic to check for safety event IRQs, then clear and handle them in the IRQ handler thread. Safety events need to be checked and cleared with a different set of GPU registers than those the IRQ handler has been using so far. Only two safety events need to be handled on the host: FW fault (ECC error correction or detection) and device watchdog timeout. Handling right now simply consists of clearing any error and logging the event. If either of these events results in an unrecoverable GPU or FW, the driver will eventually attempt to recover from it e.g. via pvr_power_reset(). Note that Rogue GPUs may send interrupts to the host for all types of safety events, not just the two above. For events not handled by the host, clearing the associated interrupt is sufficient. Signed-off-by: Alessio Belle <alessio.belle@imgtec.com> Reviewed-by: Frank Binns <frank.binns@imgtec.com> Link: https://lore.kernel.org/r/20250410-sets-bxs-4-64-patch-v1-v6-7-eda620c5865f@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-04-15drm/imagination: Mask GPU IRQs in threaded handlerAlessio Belle1-7/+5
Pass IRQF_ONESHOT flag to request_threaded_irq(), so that interrupts will be masked by the kernel until the end of the threaded IRQ handler. Since the calls to pvr_fw_irq_enable() and pvr_fw_irq_disable() are now redundant, remove them. Interrupts to the host from the soon-to-be-added RISC-V firmware processors cannot be masked in hardware. This change allows us to continue using the threaded handler in GPUs with a RISC-V firmware. For simplicity, the same approach is taken for all firmware processors. Signed-off-by: Alessio Belle <alessio.belle@imgtec.com> Reviewed-by: Frank Binns <frank.binns@imgtec.com> Link: https://lore.kernel.org/r/20250410-sets-bxs-4-64-patch-v1-v6-6-eda620c5865f@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-04-15drm/imagination: Add power domain controlMatt Coster4-0/+132
The first supported GPU only used a single power domain so this was automatically handled by the device runtime. In order to support multiple power domains, they must be enumerated from devicetree and linked to both the GPU device and each other to ensure correct power sequencing at start time. For all Imagination Rogue GPUs, power domains are named "a", "b", etc. and the sequence A->B->... is always valid for startup with the reverse true for shutdown. Note this is not always the *only* valid sequence, but it's simple and does not require special-casing for different GPU power topologies. Reviewed-by: Frank Binns <frank.binns@imgtec.com> Link: https://lore.kernel.org/r/20250410-sets-bxs-4-64-patch-v1-v6-5-eda620c5865f@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-04-15drm/imagination: Use new generic compatible stringMatt Coster1-0/+7
Follow-on from the companion dt-bindings change ("dt-bindings: gpu: img: More explicit compatible strings"), deprecating "img,img-axe" in favour of the more explicit combination of "img,img-rogue" and "img,img-axe-1-16m". Since all relevant details are interrogated from the device at runtime, we can match on the generic "img,img-rogue" and avoid adding more entries with NULL data members (barring hardware quirks). Reviewed-by: Frank Binns <frank.binns@imgtec.com> Link: https://lore.kernel.org/r/20250410-sets-bxs-4-64-patch-v1-v6-4-eda620c5865f@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-04-15drm/imagination: Update register defs for newer GPUsAlessio Belle1-19/+134
Update the register define header to a newer version that covers more recent GPUs, including BXS-4-64. Signed-off-by: Alessio Belle <alessio.belle@imgtec.com> Reviewed-by: Frank Binns <frank.binns@imgtec.com> Link: https://lore.kernel.org/r/20250410-sets-bxs-4-64-patch-v1-v6-3-eda620c5865f@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-04-15Merge drm/drm-next into drm-misc-nextThomas Zimmermann179-4912/+5915
Backmerging to get fixes from v6.15-rc2 into drm-misc-next. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
2025-04-15drm/display: hdmi: provide central data authority for ACR paramsDmitry Baryshkov1-0/+168
HDMI standard defines recommended N and CTS values for Audio Clock Regeneration. Currently each driver implements those, frequently in somewhat unique way. Provide a generic helper for getting those values to be used by the HDMI drivers. The helper is added to drm_hdmi_helper.c rather than drm_hdmi_audio.c since HDMI drivers can be using this helper function even without switching to DRM HDMI Audio helpers. Note: currently this only handles the values per HDMI 1.4b Section 7.2 and HDMI 2.0 Section 9.2.1. Later the table can be expanded to accommodate for Deep Color TMDS char rates per HDMI 1.4 Appendix D and/or HDMI 2.0 / 2.1 Appendix C). Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/r/20250408-drm-hdmi-acr-v2-1-dee7298ab1af@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-04-15drm/i915/display: Add link rate and lane count to i915_display_infoKhaled Almahallawy1-0/+2
Adding link rate and lane count information to i915_display_info makes it easier and faster to access this data compared to checking kernel logs. This is particularly beneficial for individuals who are not familiar with i915 in the following scenarios: * Debugging DP tunnel bandwidth usage in the Thunderbolt driver. * During USB4 certification, it is necessary to know the link rate used by the monitor to prove that the DP tunnel can handle required rates. * In PHY CTS, when the connector probes are not mounted correctly, some display lanes may not appear in the DP Oscilloscope, leading to CTS failures. This change provides validation teams with an easy way to identify and troubleshoot issues. v2: separate seq_printf line (Jani) v3: separate output line (Jani) Cc: Imre Deak <imre.deak@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Khaled Almahallawy <khaled.almahallawy@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/20250409230214.963999-1-khaled.almahallawy@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-04-15drm/bridge: anx7625: Use devm_pm_runtime_enable()Chen-Yu Tsai1-8/+1
The anx7625 driver is open coding what devm_pm_runtime_enable() does. Switch to the common helper instead. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://patch.msgid.link/20250409093814.3977025-1-wenst@chromium.org Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
2025-04-15drm/i915/dp: Check for HAS_DSC_3ENGINES while configuring DSC slicesAnkit Nautiyal1-3/+4
DSC 12 slices configuration is used for some specific cases with Ultrajoiner. This can be supported only when each of the 4 joined pipes have 3 DSC engines each. Add the missing check for 3 DSC engines support before using 3 DSC slices per pipe. Fixes: be7f5fcdf4a0 ("drm/i915/dp: Enable 3 DSC engines for 12 slices") Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Suraj Kandpal <suraj.kandpal@intel.com> Cc: <stable@vger.kernel.org> # v6.14+ Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/20250414024256.2782702-3-ankit.k.nautiyal@intel.com (cherry picked from commit da9b1c61e7f7b327dd70c5f073ba04d419a55ef8) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-04-15drm/i915/display: Add macro for checking 3 DSC enginesAnkit Nautiyal1-0/+1
3 DSC engines per pipe is currently supported only for BMG. Add a macro to check whether a platform supports 3 DSC engines per pipe. v2:Fix Typo in macro argument. (Suraj). Added fixes tag. Bspec: 50175 Fixes: be7f5fcdf4a0 ("drm/i915/dp: Enable 3 DSC engines for 12 slices") Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Suraj Kandpal <suraj.kandpal@intel.com> Cc: <stable@vger.kernel.org> # v6.14+ Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/20250414085701.2802374-1-ankit.k.nautiyal@intel.com (cherry picked from commit 6998cfce0e1db58c730d08cadc6bfd71e26e2de0) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-04-15drm/i915/dp: Check for HAS_DSC_3ENGINES while configuring DSC slicesAnkit Nautiyal1-3/+4
DSC 12 slices configuration is used for some specific cases with Ultrajoiner. This can be supported only when each of the 4 joined pipes have 3 DSC engines each. Add the missing check for 3 DSC engines support before using 3 DSC slices per pipe. Fixes: be7f5fcdf4a0 ("drm/i915/dp: Enable 3 DSC engines for 12 slices") Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Suraj Kandpal <suraj.kandpal@intel.com> Cc: <stable@vger.kernel.org> # v6.14+ Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/20250414024256.2782702-3-ankit.k.nautiyal@intel.com
2025-04-15drm/i915/display: Add macro for checking 3 DSC enginesAnkit Nautiyal1-0/+1
3 DSC engines per pipe is currently supported only for BMG. Add a macro to check whether a platform supports 3 DSC engines per pipe. v2:Fix Typo in macro argument. (Suraj). Added fixes tag. Bspec: 50175 Fixes: be7f5fcdf4a0 ("drm/i915/dp: Enable 3 DSC engines for 12 slices") Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Suraj Kandpal <suraj.kandpal@intel.com> Cc: <stable@vger.kernel.org> # v6.14+ Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/20250414085701.2802374-1-ankit.k.nautiyal@intel.com
2025-04-14Merge tag 'drm-intel-next-2025-04-11' of ↵Dave Airlie128-4725/+5411
https://gitlab.freedesktop.org/drm/i915/kernel into drm-next Cross-subsystem Changes: - Update GVT MAINTAINERS (Jani) Driver Changes: - Updates for xe3lpd display (Gustavo) - Fix link training interrupted by HPD pulse (Imre) - Watermark bound checks for DSC (Ankit) - VRR Refactor and other fixes and improvements (Ankit) - More conversions towards intel_display struct (Gustavo, Jani) - Other clean-up patches towards a display separation (Jani) - Maintain asciibetical order for HAS_* macros (Ankit) - Fixes around probe/initialization (Janusz) - Fix build and doc build issue (Yue, Rodrigo) - DSI related fixes (Suraj, William, Jani) - Improve DC6 entry counter (Mohammed) - Fix xe2hpd memory type identification (Vivek) - PSR related fixes and improvements (Animesh, Jouni) - DP MST related fixes and improvements (Imre) - Fix scanline_offset for LNL+/BMG+ (Ville) - Some gvt related fixes and changes (Ville, Jani) - Some PLL code adjustment (Ville) - Display wa addition (Vinod) - DRAM type logging (Lucas) - Pimp the initial FB readout (Ville) - Some sagv/bw cleanup (Ville) - Remove i915_display_capabilities debugfs entry (Jani) - Move PCH type to display caps debugfs entry (Jani) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/Z_kTqPX5Mjruq1pL@intel.com
2025-04-14drm/i915: use graphics version instead of PCH split in error captureJani Nikula1-1/+1
Avoid using PCH checks in core i915 code, in preparation for moving PCH handling to display. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/8d73eb1d56603210003554bc6a875c53ed4c692a.1744630147.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-04-14drm/i915: don't capture DERRMR for VLV/CHVJani Nikula1-1/+1
DERRMR isn't valid for VLV/CHV. Don't capture it for them. Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/4563cc7eb567ac508b84717c3708a4e48aa8b7bb.1744630147.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-04-14drm/i915: use display snapshot mechanism for display irq regsJani Nikula5-20/+38
Move more display specific parts of GPU error logging behind the display snapshot interface. With the display register capture reduced to just one register, DERRMR, there's quite a bit of boilerplate here. However, it's still a nice abstraction and removes a DISPLAY_VER() usage from core i915. With this approach, it's also easy to add to xe as needed. v2: Remove stale comment Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/13206969df04426d290d2863dc574e22ca45193a.1744630147.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-04-14drm/i915: stop recording IER in error captureJani Nikula2-9/+0
With pre-ilk GEN2_IER capture moved to gtier[0], the remaining IER aren't all that relevant. Stop capturing them. Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/6f1130a3d0d13e08a73ba381225ab978b22a9345.1744630147.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-04-14drm/i915: record GEN2_IER in gtier[0] for pre-ilk error captureJani Nikula1-2/+3
In pre-ilk platforms the engine interrupts live in GEN2_IER. Capture it as part of gtier instead of display. Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/f637219fe3accb69963266773b9ef7c1131875e4.1744630147.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-04-14drm/i915: use 32-bit access for gen2 irq registersJani Nikula1-2/+0
We've previously switched from 16-bit to 32-bit access for gen2 irq registers, but one was left behind. Fix it. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/5a56286c94e08a02435c60ce0fbff13aca6c0d1f.1744630147.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-04-14drm/i915/dpio: have chv_data_lane_soft_reset() get/put dpio internallyJani Nikula3-20/+16
Have chv_data_lane_soft_reset() get/put dpio internally, and use a locked version of it within intel_dpio_phy.c. This drops the dependency on vlv sideband from g4x_dp.c and g4x_hdmi.c, and makes that a DPIO PHY implementation detail. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/20250411102715.613082-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-04-14drm/xe: Set LRC addresses before guc loadLucas De Marchi1-30/+45
The metadata saved in the ADS is read by GuC when it's initialized. Saving the addresses to the LRCs when they are populated is too late as GuC will keep using the old ones. This was causing GuC to use the RCS LRC for any engine class. It's not a big problem on a Linux-only scenario since the they are used by GuC only on media engines when the watchdog is triggered. However, in a virtualization scenario with Windows as the VF, it causes the wrong LRCs to be loaded as the watchdog is used for all engines. Fix it by letting guc_golden_lrc_init() initialize the metadata, like other *_init() functions, and later guc_golden_lrc_populate() to copy the LRCs to the right places. The former is called before the second GuC load, while the latter is called after LRCs have been recorded. Cc: Chee Yin Wong <chee.yin.wong@intel.com> Cc: John Harrison <john.c.harrison@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: <stable@vger.kernel.org> # v6.11+ Reviewed-by: Matthew Brost <matthew.brost@intel.com> Tested-by: Chee Yin Wong <chee.yin.wong@intel.com> Link: https://lore.kernel.org/r/20250409-fix-guc-ads-v1-1-494135f7a5d0@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-04-14drm/xe/pf: Don't show GGTT/LMEM debugfs files under media GTMichal Wajdeczko1-17/+49
Most of the PF's debugfs files (and their implementations) are based on the GT hierarchy even if files are related to GGTT or LMEM data, that are related to the tile. While we could reach the tile data from any GT, to avoid potential misuse, some functions allow to be used on the primary GT only, and may use asserts to enforce that. In our case, the following assert could be seen when reading the /sys/kernel/debug/dri/0000:00:02.0/gt1/pf/ggtt_available [ ] xe 0000:00:02.0: [drm] Assertion `!xe_gt_is_media_type(gt)` failed! [ ] WARNING: CPU: 4 PID: 10609 at drivers/gpu/drm/xe/xe_gt_sriov_pf_config.c:379 pf_get_spare_ggtt+0x256/0x4e0 [xe] [ ] RIP: 0010:pf_get_spare_ggtt+0x256/0x4e0 [xe] [ ] Call Trace: [ ] <TASK> [ ] xe_gt_sriov_pf_config_print_available_ggtt+0xb7/0x480 [xe] [ ] ? __memcg_slab_post_alloc_hook+0x12f/0x3f0 [ ] xe_gt_debugfs_simple_show+0x7b/0xb0 [xe] [ ] ? __pfx___drm_printfn_seq_file+0x10/0x10 [ ] ? __pfx___drm_puts_seq_file+0x10/0x10 [ ] seq_read_iter+0x139/0x4e0 [ ] seq_read+0x11d/0x160 [ ] full_proxy_read+0x6b/0xb0 [ ] vfs_read+0xfa/0x390 Fix that by moving GGTT/LMEM debugfs attributes to separate lists and register them only when applicable (on primary GT, on DGFX). Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Tested-by: Marcin Bernatowicz <marcin.bernatowicz@linux.intel.com> Reviewed-by: Marcin Bernatowicz <marcin.bernatowicz@linux.intel.com> Link: https://lore.kernel.org/r/20250411193030.1865-1-michal.wajdeczko@intel.com
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-12 18:16:54 +0300