summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-10-31Merge tag 'drm-misc-next-2025-10-28' of ↵Simona Vetter
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next for v6.19-rc1: UAPI Changes: Cross-subsystem Changes: - Update DT bindings for renesas and powervr-rogue. - Update MAINTAINERS email and add spsc_queue. Core Changes: - Allow ttm page protection flags on risc-v. - Move freeing of drm client memory to driver. Driver Changes: - Assorted small fixes and updates to qaic, ivpu, st7571-i2c, gud, amdxdna. - Allow configuration of vkms' display through configfs. - Add Arm Ethos-U65/U85 accel driver. Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch> From: Maarten Lankhorst <dev@lankhorst.se> Link: https://patch.msgid.link/32b43261-3c99-49d9-92ee-615ada1d01e8@lankhorst.se
2025-10-31Merge tag 'drm-xe-next-2025-10-28' of ↵Simona Vetter
https://gitlab.freedesktop.org/drm/xe/kernel into drm-next Driver Changes: More xe3p support (Harish, Brian, Balasubramani, Matt Roper) Make panic support work on VRAM for display (Maarten) Fix stolen size check (Shuicheng) xe_pci_test update (Gustavo) VF migration updates (Tomasz) A couple of fixes around allocation and PM references (Matt Brost) Migration update for the MEM_COPY instruction (Matt Auld) Initial CRI support (Balasubramani, Matt Roper) Use SVM range helpers in PT layer (Matt Brost) Drop MAX_GT_TYPE_CHARS constant (Matt Roper) Fix spelling and typos (Sanjay) Fix VF FLR synchronization between all GTs (Michal) Add a Workaround (Nitin) Access VF's register using dedicated MMIO view (Michal) Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch> From: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/aQCl9uJxN6CWJ8Vg@fedora
2025-10-31Merge tag 'amd-drm-next-6.19-2025-10-24' of ↵Simona Vetter
https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-6.19-2025-10-24: amdgpu: - HMM cleanup - Add new RAS framework - DML2.1 updates - YCbCr420 fixes - DC FP fixes - DMUB fixes - LTTPR fixes - DTBCLK fixes - DMU cursor offload handling - Userq validation improvements - Misc code cleanups - Unify shutdown callback handling - Suspend improvements - Power limit code cleanup - Fence cleanup - IP Discovery cleanup - SR-IOV fixes - AUX backlight fixes - DCN 3.5 fixes - HDMI compliance fixes - DCN 4.0.1 cursor updates - DCN interrupt fix - DC KMS full update improvements - Add additional HDCP traces - DCN 3.2 fixes - DP MST fixes - Add support for new SR-IOV mailbox interface Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch> From: Alex Deucher <alexander.deucher@amd.com> Link: https://lore.kernel.org/r/20251024175249.58099-1-alexander.deucher@amd.com
2025-10-28drm/ttm: add pgprot handling for RISC-VIcenowy Zheng
The RISC-V Svpbmt privileged extension provides support for overriding page memory coherency attributes, and, along with vendor extensions like Xtheadmae, supports pgprot_{writecombine,noncached} on RISC-V. Adapt the codepath that maps ttm_write_combined to pgprot_writecombine and ttm_noncached to pgprot_noncached to RISC-V, to allow proper page access attributes. Signed-off-by: Icenowy Zheng <uwu@icenowy.me> Tested-by: Han Gao <rabenda.cn@gmail.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20251020053523.731353-1-uwu@icenowy.me
2025-10-27accel/qaic: Rename constant for clarityTroy Hanson
QAIC_MANAGE_EXT_MSG_LENGTH is ambiguous and has been confused with QAIC_MANAGE_MAX_MSG_LENGTH. Rename it to clarify it's a wire length. Signed-off-by: Troy Hanson <thanson@qti.qualcomm.com> Signed-off-by: Youssef Samir <youssef.abdulrahman@oss.qualcomm.com> Reviewed-by: Carl Vanderlip <carl.vanderlip@oss.qualcomm.com> Reviewed-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com> [jhugo: capitalize subject] Signed-off-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com> Link: https://patch.msgid.link/20251022141606.3740470-1-youssef.abdulrahman@oss.qualcomm.com
2025-10-27accel/qaic: Fix commentAswin Venkatesan
Replace the word "Qranium" with "qaic" in the function parameter description. Signed-off-by: Aswin Venkatesan <aswivenk@qti.qualcomm.com> Signed-off-by: Youssef Samir <youssef.abdulrahman@oss.qualcomm.com> Reviewed-by: Carl Vanderlip <carl.vanderlip@oss.qualcomm.com> Reviewed-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com> [jhugo: adjust word wrapping in commit text] Signed-off-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com> Link: https://patch.msgid.link/20251022124107.3712466-1-youssef.abdulrahman@oss.qualcomm.com
2025-10-27accel/qaic: Update the sahara image table for AIC200Youssef Samir
Update the Sahara image table for the AIC200 to add entries for: - qupv3fw.elf at id 54 - xbl_config.elf at id 38 - tz_qti_config.mbn at id 76 And move pvs.bin to id 78 to avoid firmware conflict. Co-developed-by: Zack McKevitt <zmckevit@qti.qualcomm.com> Signed-off-by: Zack McKevitt <zmckevit@qti.qualcomm.com> Co-developed-by: Aswin Venkatesan <aswivenk@qti.qualcomm.com> Signed-off-by: Aswin Venkatesan <aswivenk@qti.qualcomm.com> Signed-off-by: Youssef Samir <quic_yabdulra@quicinc.com> Signed-off-by: Youssef Samir <youssef.abdulrahman@oss.qualcomm.com> Reviewed-by: Karol Wachowski <karol.wachowski@linux.intel.com> Reviewed-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com> Signed-off-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com> Link: https://patch.msgid.link/20251017173432.1207656-1-youssef.abdulrahman@oss.qualcomm.com
2025-10-27drm/xe/pf: Access VF's register using dedicated MMIO viewMichal Wajdeczko
Instead of creating ad-hoc new register definitions with altered register addresses to mimic the VF's access to these registers, prepare new MMIO instance per required VF, with shifted internal location of the register map. This will allow to use unmodified register definitions in all calls to xe_mmio() functions. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20251024205826.4652-1-michal.wajdeczko@intel.com
2025-10-27drm/xe/xe3: Add WA_14024681466 for Xe3_LPGNitin Gote
Apply WA_14024681466 to Xe3_LPG graphics IP versions from 30.00 to 30.05. v2: (Matthew Roper) - Remove stepping filter as workaround applies to all steppings. - Add an engine class filter so it only applies to the RENDER engine. Signed-off-by: Nitin Gote <nitin.r.gote@intel.com> Link: https://patch.msgid.link/20251027092643.335904-1-nitin.r.gote@intel.com Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-27dt-bindings: gpu: img,powervr-rogue: Document GX6250 GPU in Renesas R-Car ↵Marek Vasut
M3-W/M3-W+ Document Imagination Technologies PowerVR Rogue GX6250 BNVC 4.45.2.58 present in Renesas R-Car R8A77960 M3-W and R8A77961 M3-W+ SoC. Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Matt Coster <matt.coster@imgtec.com> Link: https://patch.msgid.link/20251022033847.471106-1-marek.vasut+renesas@mailbox.org Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-10-27drm/xe/pf: Fix VF FLR synchronization between all GTsMichal Wajdeczko
If subsequent VF FLR request is triggered when previous VF FLR sequence is still being processed, we ignore it as not needed. But in case of the multi-GT platforms, one GT may already finish its VF FLR processing and will start a new sequence, which includes new cross-GT synchronization point. However, since other GT may be still busy with post-sync cleanup steps, this will put on hold this new FLR sequence, which might never finish due to lack of any future synchronization checkouts. Add additional cross-GT FLR synchronization point when each GT ends processing its own FLR sequence. This should also help to cover the case when one GT fails FLR processing before reaching the first synchronization point. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6287 Fixes: 2a8fcf7cc950 ("drm/xe/pf: Synchronize VF FLR between all GTs") Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://patch.msgid.link/20251025124906.5264-1-michal.wajdeczko@intel.com
2025-10-27drm/xe: Fix spelling and typos across Xe driver filesSanjay Yadav
Corrected various spelling mistakes and typos in multiple files under the Xe directory. These fixes improve clarity and maintain consistency in documentation. v2 - Replaced all instances of "XE" with "Xe" where it referred to the driver name - of -> for - Typical -> Typically v3 - Revert "Xe" to "XE" for macro prefix reference Signed-off-by: Sanjay Yadav <sanjay.kumar.yadav@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Stuart Summers <stuart.summers@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20251023121453.1182035-2-sanjay.kumar.yadav@intel.com
2025-10-27MAINTAINERS: Maintain spsc_queue through drm_schedPhilipp Stanner
Back in the day a specialized lockless queue was designed solely for the DRM GPU Scheduler: spsc_queue. This queue's only user is drm_sched, and there is no dedicated maintainer entry for the queue. Add the spsc_queue header to the DRM GPU Scheduler MAINTAINERS' section. Acked-by: Simona Vetter <simona.vetter@ffwll.ch> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patch.msgid.link/20251024081459.164634-2-phasta@kernel.org
2025-10-26drm/gem-atomic: Reset plane state to NULL if allocation failedThomas Zimmermann
Unconditionally reset plane->state to NULL if the allocation of the shadow plane state fails. Avoids an invalid address in the field. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patch.msgid.link/20251017091919.58770-1-tzimmermann@suse.de
2025-10-24drm/xe/configfs: Drop MAX_GT_TYPE_CHARS constantMatt Roper
Early revisions of commit 7abd69278bb5 ("drm/xe/configfs: Add attribute to disable GT types") used MAX_GT_TYPE_CHARS not only to size the constant name field, but also for some of the string matching logic. By the time the patch finally landed, the constant was no longer needed for parsing. Stop using it for the string field definition as well; this eliminates the risk that we forget to update the constant if we ever add a GT type name longer than seven characters. Suggested-by: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patch.msgid.link/20251024200834.1512329-2-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-24accel: Add Arm Ethos-U NPU driverRob Herring (Arm)
Add a driver for Arm Ethos-U65/U85 NPUs. The Ethos-U NPU has a relatively simple interface with single command stream to describe buffers, operation settings, and network operations. It supports up to 8 memory regions (though no h/w bounds on a region). The Ethos NPUs are designed to use an SRAM for scratch memory. Region 2 is reserved for SRAM (like the downstream driver stack and compiler). Userspace doesn't need access to the SRAM. The h/w has no MMU nor external IOMMU and is a DMA engine which can read and write anywhere in memory without h/w bounds checks. The user submitted command streams must be validated against the bounds of the GEM BOs. This is similar to the VC4 design which validates shaders. The job submit is based on the rocket driver for the Rockchip NPU utilizing the GPU scheduler. It is simpler as there's only 1 core rather than 3. Tested on i.MX93 platform (U65) and FVP (U85) with Mesa Teflon support. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Tomeu Vizoso <tomeu@tomeuvizoso.net> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20251020-ethos-v6-2-ecebc383c4b7@kernel.org Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2025-10-24dt-bindings: npu: Add Arm Ethos-U65/U85Rob Herring (Arm)
Add a binding schema for Arm Ethos-U65/U85 NPU. The Arm Ethos-U NPUs are designed for edge AI inference applications. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Acked-by: Tomeu Vizoso <tomeu@tomeuvizoso.net> Link: https://patch.msgid.link/20251020-ethos-v6-1-ecebc383c4b7@kernel.org Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2025-10-24accel/amdxdna: Fix uninitialized return valueLizhi Hou
In aie2_get_hwctx_status() and aie2_query_ctx_status_array(), the functions could return an uninitialized value in some cases. Update them to always return 0. The amount of valid results is indicated by the returned buffer_size, element_size, and num_element fields. Fixes: 2f509fe6a42c ("accel/amdxdna: Add ioctl DRM_IOCTL_AMDXDNA_GET_ARRAY") Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Link: https://patch.msgid.link/20251024165503.1548131-1-lizhi.hou@amd.com
2025-10-24accel/amdxdna: Fix incorrect return value in aie2_hwctx_sync_debug_bo()Lizhi Hou
When the driver issues the SYNC_DEBUG_BO command, it currently returns 0 even if the firmware fails to execute the command. Update the driver to return -EINVAL in this case to properly indicate the failure. Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/dri-devel/aPsadTBXunUSBByV@stanley.mountain/ Fixes: 7ea046838021 ("accel/amdxdna: Support firmware debug buffer") Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Link: https://patch.msgid.link/20251024162608.1544842-1-lizhi.hou@amd.com
2025-10-24drm/gud: rearrange gud_probe() to prepare for function splittingRuben Wauters
gud_probe() is currently very large and does many things, including pipeline setup and feature detection, as well as having USB functions. This patch re-orders the code in gud_probe() to make it more organised and easier to split apart in the future. Signed-off-by: Ruben Wauters <rubenru09@aol.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20251020140147.5017-1-rubenru09@aol.com/
2025-10-24Merge drm/drm-next into drm-misc-nextThomas Zimmermann
Backmerging to get fixes and features of v6.18-rc2. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
2025-10-24Merge tag 'drm-misc-next-2025-10-21' of ↵Simona Vetter
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next for v6.19: UAPI Changes: amdxdna: - Support reading last hardware error Cross-subsystem Changes: dma-buf: - heaps: Create heap per CMA reserved location; Improve user-space documentation Core Changes: atomic: - Clean up and improve state-handling interfaces, update drivers bridge: - Improve ref counting buddy: - Optimize block management Driver Changes: amdxdna: - Fix runtime power management - Support firmware debug output ast: - Set quirks for each chip model atmel-hlcdc: - Set LCDC_ATTRE register in plane disable - Set correct values for plane scaler bochs: - Use vblank timer bridge: - synopsis: Support CEC; Init timer with correct frequency cirrus-qemu: - Use vblank timer imx: - Clean up ivu: - Update JSM API to 3.33.0 - Reset engine on more job errors - Return correct error codes for jobs komeda: - Use drm_ logging functions panel: - edp: Support AUO B116XAN02.0 panfrost: - Embed struct drm_driver in Panfrost device - Improve error handling - Clean up job handling panthor: - Support custom ASN_HASH for mt8196 renesas: - rz-du: Fix dependencies rockchip: - dsi: Add support for RK3368 - Fix LUT size for RK3386 sitronix: - Fix output position when clearing screens qaic: - Support dma-buf exports - Support new firmware's READ_DATA implementation - Replace kcalloc with memdup - Replace snprintf() with sysfs_emit() - Avoid overflows in arithmetics - Clean up - Fixes qxl: - Use vblank timer rockchip: - Clean up mode-setting code vgem: - Fix fence timer deadlock virtgpu: - Use vblank timer Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20251021111837.GA40643@linux.fritz.box
2025-10-24drm/client: Do not free client memory by defaultThomas Zimmermann
Make no assumption on the allocation of the client's memory. For example, amdgpu stores a client within another data structures, where it cannot be freed by itself. The correct place to free the client's memory is the client's free callback. All existing clients implement this. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20251009132006.45834-5-tzimmermann@suse.de
2025-10-24drm/log: Add free callbackThomas Zimmermann
Free the client memory in the client free callback. Also move the debugging output into the free callback: drm_client_release() puts the reference on the DRM device, so pointers to the device should be considered dangling afterwards. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>> Link: https://lore.kernel.org/r/20251009132006.45834-4-tzimmermann@suse.de
2025-10-24drm/log: Do not hold lock across drm_client_release()Thomas Zimmermann
When calling drm_client_release(), the client is already quiescent. Internal locks should therefore be dropped before the caller releases the client. In the case of the DRM log, concurrency originates from the console or from client events. The console has been unregistered in the previous line. The caller of the unregister callback, drm_log_client_unregister(), holds clientlist_mutex from struct drm_device to protect against concurrent client events. It is therefore safe to release the client without holding locks. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>> Link: https://lore.kernel.org/r/20251009132006.45834-3-tzimmermann@suse.de
2025-10-24drm/client: Add client free callback to unprepare fb_helperThomas Zimmermann
Add free callback to struct drm_client_funcs. Invoke function to free the client memory as part of the release process. Implement free for fbdev emulation. Fbdev emulation allocates and prepares client memory in drm_fbdev_client_setup(). The release happens in fb_destroy from struct fb_ops. Multiple implementations of this callback exist in the various drivers that provide an fbdev implementation. Each of them needs to follow the implementation details of the fbdev setup code. Adding a free callback for the client puts the unprepare and release of the fbdev client in a single place. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> # core, msm Acked-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> # omapdrm Acked-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> # gma500 Acked-by: Alex Deucher <alexander.deucher@amd.com> Link: https://lore.kernel.org/r/20251009132006.45834-2-tzimmermann@suse.de
2025-10-23drm/xe/xe3p_xpc: Add MCR steering for NODE and L3BANK rangesMatt Roper
The bspec was originally missing the information related to steering of L3-related ranges. Now that a late-breaking spec update has added the necessary information, implement the steering rules in the code. Note that the sole L3BANK range is the same as the one used on Xe_LPG, so we can re-use the existing table for that MCR type. Bspec: 74418 Fixes: be614ea19dad ("drm/xe/xe3p_xpc: Add MCR steering") Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20251021224556.437970-3-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-23drm/xe/xe3p_xpc: Treat all PSMI MCR ranges as "INSTANCE0"Matt Roper
Early versions of the B-spec originally indicated that Xe3p_XPC had two ranges of PSMI registers requiring MCR steering (one starting at 0xB500, one starting at 0xB600), and that reads of registers in these ranges required different grpid values to ensure that a non-terminated value is obtained. A late-breaking spec update has simplified this; both ranges can be safely steered to grpid=0 for reads. Drop the "PSMI19" replication type and related code, and consolidate both register ranges into a single entry in the "INSTANCE0" steering table. Bspec: 74418 Fixes: be614ea19dad ("drm/xe/xe3p_xpc: Add MCR steering") Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20251021224556.437970-2-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-23drm/xe: Use SVM range helpers in PT layerMatthew Brost
We have helpers SVM range start, end, and size. Use them in the PT layer rather than directly looking at the struct. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://lore.kernel.org/r/20251022230122.922382-1-matthew.brost@intel.com
2025-10-23drm/xe/cri: Setup MOCS tableMatt Roper
CRI has a new MOCS table, but uses the same general ops as other Xe2/Xe3 platforms. Bspec: 71582 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Link: https://patch.msgid.link/20251021-cri-v1-3-bf11e61d9f49@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-23accel/ivpu: Add support for Nova Lake's NPUMaciej Falkowski
Add support for NPU6 generation that will be present on Nova Lake CPUs. As with previous generations, it maintains compatibility so no bigger functional changes apart from removing deprecated call to soc_cpu_drive() function. Quiescing TOP_MMIO in SOC_CPU_NOC as part of boot procedure is no longer needed starting from 60XX. Remove soc_cpu_drive() call from NPU6 onward. The VPU_CPU_NOC_QREQN, VPU_CPU_NOC_QACCEPTN, and VPU_CPU_NOC_QDENY registers are deprecated and non-functional on 60XX. They will be removed in future generations. Signed-off-by: Karol Wachowski <karol.wachowski@linux.intel.com> Reviewed-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com> Signed-off-by: Maciej Falkowski <maciej.falkowski@linux.intel.com> Link: https://lore.kernel.org/r/20251022105348.2237273-1-maciej.falkowski@linux.intel.com
2025-10-23drm/xe/cri: Add CRI platform definitionBalasubramani Vivekanandan
Add platform definition and PCI IDs for Crescent Island. Other platforms use INTEL_VGA_DEVICE since they have a PCI_BASE_CLASS_DISPLAY class. This is not the case for CRI, so just match on devid, which should be sufficient. Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by: Shekhar Chauhan <shekhar.chauhan@intel.com> Link: https://lore.kernel.org/r/20251021-cri-v1-1-bf11e61d9f49@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-23drm/xe/migrate: skip bounce buffer path on xe2Matthew Auld
Now that we support MEM_COPY we should be able to use the PAGE_COPY mode, otherwise falling back to BYTE_COPY mode when we have odd sizing/alignment. v2: - Use info.has_mem_copy_instr - Rebase on latest changes. v3 (Matt Brost): - Allow various pitches including 1byte pitch for MEM_COPY Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20251022163836.191405-8-matthew.auld@intel.com
2025-10-23drm/xe/migrate: support MEM_COPY instructionMatthew Auld
Make this the default on xe2+ when doing a copy. This has a few advantages over the exiting copy instruction: 1) It has a special PAGE_COPY mode that claims to be optimised for page-in/page-out, which is the vast majority of current users. 2) It also has a simple BYTE_COPY mode that supports byte granularity copying without any restrictions. With 2) we can now easily skip the bounce buffer flow when copying buffers with strange sizing/alignment, like for memory_access. But that is left for the next patch. v2 (Matt Brost): - Use device info to check whether device should use the MEM_COPY path. This should fit better with making this a configfs tunable. - And with that also keep old path still functional on xe2 for possible experimentation. - Add a define for PAGE_COPY page-size. v3 (Matt Brost): - Fallback to an actual linear copy for pitch=1. - Also update NVL. BSpec: 57561 Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20251022163836.191405-7-matthew.auld@intel.com
2025-10-23drm/xe/migrate: trim batch buffer sizingMatthew Auld
We have an extra two dwords, but it looks like we should only need one for the extra bb_end. Likely this is just leftover from back when the arb handling was moved into the ring programming. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20251022163836.191405-6-matthew.auld@intel.com
2025-10-23drm/xe/migrate: fix batch buffer sizingMatthew Auld
In xe_migrate_vram() the copy can straddle page boundaries, so the len might look like a single page, but actually accounting for the offset within the page we will need to emit more than one PTE. Otherwise in some cases the batch buffer will be undersized leading to warnings later. We already have npages so use that instead. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20251022163836.191405-5-matthew.auld@intel.com
2025-10-23drm/xe/migrate: fix chunk handling for 2M page emitMatthew Auld
On systems with PAGE_SIZE > 4K the chunk will likely be rounded down to zero, if say we have single 2M page, so one huge pte, since we also try to align the chunk to PAGE_SIZE / XE_PAGE_SIZE, which will be 16 on 64K systems. Make the ALIGN_DOWN conditional for 4K PTEs where we can encounter gpu_page_size < PAGE_SIZE. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20251022163836.191405-4-matthew.auld@intel.com
2025-10-23drm/xe/migrate: rework size restrictions for sram pte emitMatthew Auld
We allow the input size to not be aligned to PAGE_SIZE, which leads to various bugs in build_pt_update_batch_sram() for PAGE_SIZE > 4K systems. For example if ptes is exactly one gpu_page_size then the chunk size is rounded down to zero. The simplest fix looks to be forcing PAGE_SIZE aligned inputs. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20251022163836.191405-3-matthew.auld@intel.com
2025-10-23drm/xe/migrate: fix offset and len checkMatthew Auld
Restriction here is pitch of 4bytes to match pixel width (32b), and hw restriction where src and dst must be aligned to 64bytes. If any of that is not possible then we need a bounce buffer. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20251022163836.191405-2-matthew.auld@intel.com
2025-10-23drm/sysfb: Use new CRTC state in begin_fb_accessThomas Zimmermann
Retrieve the CRTC's new state with drm_atomic_get_new_crtc_state() in drm_sysfb_plane_helper_begin_fb_access(). The blit function might be incorrect otherwise. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: cb71de092553 ("drm/sysfb: Lookup blit function during atomic check") Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Closes: https://lore.kernel.org/dri-devel/aPJrs7_u8KcalNsC@intel.com/ Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: dri-devel@lists.freedesktop.org Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20251020125227.41308-1-tzimmermann@suse.de
2025-10-22drm/xe: Avoid PM wake reference during VF migrationMatthew Brost
Virtual Functions (VFs) do not use runtime PM. Avoid taking PM references during VF migration, as lockdep may get confused—VF migration occurs in the reclaim path, and waking a PM reference can trigger memory allocation warnings. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://lore.kernel.org/r/20251022005538.828980-4-matthew.brost@intel.com
2025-10-22drm/xe: Do not wake device during a GT resetMatthew Brost
Waking the device during a GT reset can lead to unintended memory allocation, which is not allowed since GT resets occur in the reclaim path. Prevent this by holding a PM reference while a reset is in flight. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: stable@vger.kernel.org Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://lore.kernel.org/r/20251022005538.828980-3-matthew.brost@intel.com
2025-10-22drm/xe: Check return value of GGTT workqueue allocationMatthew Brost
Workqueue allocation can fail, so check the return value of the GGTT workqueue allocation and fail driver initialization if the allocation fails. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: stable@vger.kernel.org Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://lore.kernel.org/r/20251022005538.828980-2-matthew.brost@intel.com
2025-10-22drm/xe/vf: Do not disable VF migration on ATS-MTomasz Lis
Our current support for the VF migration depends on the availability of the MEMIRQ rather than specific graphics version 20. Relax our early migration support checks to allow also use some older platforms like ATS-M for experiments and testing. Do not allow ADL, as supporting VF migration through MMIO interrupts would require additional changes in order to achieve reliability. Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Tomasz Lis <tomasz.lis@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://lore.kernel.org/r/20251021224817.1593817-5-tomasz.lis@intel.com
2025-10-22drm/xe: Assert that VF will never use fixed placement of BOsTomasz Lis
Most BOs do not care at which offset they will be accessed within GGTT or PPGTT. The few which do care, should be only created on PF, and mapped within GGTT. On VFs, mapping at fixed offset is prohibited, as each VF is granted access to a range of GGTT address space. Since fixed addresses of GGTT mapping can only be used on PF, add an assert which makes sure no attempt of fixed placement will happen for a driver probed on a VF. Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Tomasz Lis <tomasz.lis@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://lore.kernel.org/r/20251021224817.1593817-4-tomasz.lis@intel.com
2025-10-22drm/xe/vf: Fix GuC FW check for VF migration supportTomasz Lis
The check whether GuC ABI version meets requirements shall be performed after said version is received from GuC. Doing it in wrong order was triggering a warning: xe 0000:00:02.1: [drm] Assertion `gt->sriov.vf.guc_version.major` failed! With this change, dislodge part of the VF migration support check and moved it to after GuC handshake. Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Tested-by: Matthew Brost <matthew.brost@intel.com> #v1 Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6349 Fixes: ff1d2b5e3d28 ("drm/xe: Read VF GMD_ID with a specifically-allocated dummy GT") Signed-off-by: Tomasz Lis <tomasz.lis@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://lore.kernel.org/r/20251021224817.1593817-3-tomasz.lis@intel.com
2025-10-22drm/xe/vf: Revert logic of vf.migration.enabledTomasz Lis
Convert `enabled` property into `disabled`. Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Tomasz Lis <tomasz.lis@intel.com> Suggested-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://lore.kernel.org/r/20251021224817.1593817-2-tomasz.lis@intel.com
2025-10-22drm/xe/tests/pci: Check dma_mask_size, va_bits and vm_max_levelGustavo Sousa
Members dma_mask_size, va_bits and vm_max_level of struct xe_device_desc are all expected to be non-zero. Add checks for that in check_platform_desc(). Suggested-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20251020-xe-kunit-dma_mask_size-va_bits-vm_max_level-v2-2-27b03971bc7e@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2025-10-22drm/xe/tests/pci: Convert GT count check to general device checkGustavo Sousa
We already have check_graphics_ip() and check_media_ip() as general functions to check the IP descriptors. The check in check_platform_gt_count() is simple enough such that we can convert the function to a more general device check. In an upcoming change, we will also add some checks for other members of struct xe_device_desc. As such, rename check_platform_gt_count() to check_platform_desc(). While at it, use inline (unsigned int) casting of max_gt_per_tile to keep checks for each member localized; and use KUNIT_EXPECT_*() variants of the macros to allow multiple issues to be reported. Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20251020-xe-kunit-dma_mask_size-va_bits-vm_max_level-v2-1-27b03971bc7e@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2025-10-22drm/vkms: Allow to configure connector status via configfsJosé Expósito
When a connector is created, add a `status` file to allow to update the connector status to: - 1 connector_status_connected - 2 connector_status_disconnected - 3 connector_status_unknown If the device is enabled, updating the status hot-plug or unplugs the connector. Tested-by: Mark Yacoub <markyacoub@google.com> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: José Expósito <jose.exposito89@gmail.com> Link: https://lore.kernel.org/r/20251016175618.10051-17-jose.exposito89@gmail.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
generated by cgit (git 2.34.1) at 2025-12-31 18:39:56 +0000