summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2025-10-15drm/bridge: dw-hdmi-qp: Fixup timer base setupCristian Ciocaltea
Currently the TIMER_BASE_CONFIG0 register gets initialized to a fixed value as initially found in vendor driver code supporting the RK3588 SoC. As a matter of fact the value matches the rate of the HDMI TX reference clock, which is roughly 428.57 MHz. However, on RK3576 SoC that rate is slightly lower, i.e. 396.00 MHz, and the incorrect register configuration breaks CEC functionality. Set the timer base according to the actual reference clock rate that shall be provided by the platform driver. Otherwise fallback to the vendor default. While at it, also drop the unnecessary empty lines in dw_hdmi_qp_init_hw(). Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250903-rk3588-hdmi-cec-v4-2-fa25163c4b08@collabora.com
2025-10-15drm/bridge: dw-hdmi-qp: Add CEC supportCristian Ciocaltea
Add support for the CEC interface of the Synopsys DesignWare HDMI QP TX controller. This is based on the downstream implementation, but rewritten on top of the CEC helpers added recently to the DRM HDMI connector framework. Also note struct dw_hdmi_qp_plat_data has been extended to include the CEC IRQ number to be provided by the platform driver. Co-developed-by: Algea Cao <algea.cao@rock-chips.com> Signed-off-by: Algea Cao <algea.cao@rock-chips.com> Co-developed-by: Derek Foreman <derek.foreman@collabora.com> Signed-off-by: Derek Foreman <derek.foreman@collabora.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250903-rk3588-hdmi-cec-v4-1-fa25163c4b08@collabora.com
2025-10-15drm/xe/evict: drop bogus assertMatthew Auld
This assert can trigger here with non pin_map users that select LATE_RESTORE, since the vmap is allowed to be NULL given that save/restore can now use the blitter instead. The check here doesn't seem to have much value anymore given that we no longer move pinned memory, so any existing vmap is left well alone, and doesn't need to be recreated upon restore, so just drop the assert here. Fixes: 86f69c26113c ("drm/xe: use backup object for pinned save/restore") Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6213 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> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://lore.kernel.org/r/20251010152457.177884-2-matthew.auld@intel.com
2025-10-15drm/xe/migrate: don't misalign current bytesMatthew Auld
If current bytes exceeds the max copy size, ensure the clamped size still accounts for the XE_CACHELINE_BYTES alignment, otherwise we trigger the assert in xe_migrate_vram with the size now being out of alignment. Fixes: 8c2d61e0e916 ("drm/xe/migrate: don't overflow max copy size") Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6212 Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Stuart Summers <stuart.summers@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20251010162020.190962-2-matthew.auld@intel.com
2025-10-15drm/i915/psr: Deactivate PSR only on LNL and when selective fetch enabledJouni Högander
Using intel_psr_exit in frontbuffer flush on older platforms seems to be causing problems. Sending single full frame update using intel_psr_force_update is anyways more optimal compared to psr deactivate/activate -> move back to this approach on PSR1, PSR HW tracking and Panel Replay full frame update and use deactivate/activate only on LunarLake and only when selective fetch is enabled. Tested-by: Lemen <lemen@lemen.xyz> Tested-by: Koos Vriezen <koos.vriezen@gmail.com> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14946 Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Link: https://lore.kernel.org/r/20250922102725.2752742-1-jouni.hogander@intel.com (cherry picked from commit 924adb0bbdd8fef25fd229c76e3f602c3e8752ee) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-10-15drm/i915/fbc: update the impacted platforms in wa_22014263786Vinod Govindapillai
wa_22014263786 is not applicable to the BMG and hence exclude it from the wa. v2: Limit this wa to display verion 11 to 14, drop DG2 from the exclusion list, use intel_display_wa (Lucas) v3: simplify the wa handling loop (Jani) Description of wa moved to place where wa is applied (Ville) v4: drop the platforms line from wa comments (Lucas) Bspec: 74212, 66624 Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20251007214317.875781-1-vinod.govindapillai@intel.com
2025-10-15drm/qxl: Use vblank timerThomas Zimmermann
Use a vblank timer to simulate the vblank interrupt. The DRM vblank helpers provide an implementation on top of Linux' hrtimer. Qxl enables and disables the timer as part of the CRTC. The atomic_flush callback sets up the event. Like vblank interrupts, the vblank timer fires at the rate of the display refresh. Most userspace limits its page flip rate according to the DRM vblank event. Qxl's virtual hardware does not provide vblank interrupts, so DRM sends each event ASAP. With the fast access times of virtual display memory, the event rate is much higher than the display mode's refresh rate; creating the next page flip almost immediately. This leads to excessive CPU overhead from even small display updates, such as moving the mouse pointer. This problem affects qxl and all other virtual displays. See [1] for a discussion in the context of hypervdrm. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/dri-devel/SN6PR02MB415702B00D6D52B0EE962C98D46CA@SN6PR02MB4157.namprd02.prod.outlook.com/ # [1] Acked-by: Gerd Hoffmann <kraxel@redhat.com> Link: https://lore.kernel.org/r/20251008122911.231674-1-tzimmermann@suse.de
2025-10-15drm/cirrus-qemu: Use vblank timerThomas Zimmermann
Use a vblank timer to simulate the vblank interrupt. The DRM vblank helpers provide an implementation on top of Linux' hrtimer. Cirrus-qemu enables and disables the timer as part of the CRTC. The atomic_flush callback sets up the event. Like vblank interrupts, the vblank timer fires at the rate of the display refresh. Most userspace limits its page flip rate according to the DRM vblank event. Cirrus-qemu' virtual hardware does not provide vblank interrupts, so DRM sends each event ASAP. With the fast access times of virtual display memory, the event rate is much higher than the display mode's refresh rate; creating the next page flip almost immediately. This leads to excessive CPU overhead from even small display updates, such as moving the mouse pointer. This problem affects cirrus-qemu and all other virtual displays. See [1] for a discussion in the context of hypervdrm. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/dri-devel/SN6PR02MB415702B00D6D52B0EE962C98D46CA@SN6PR02MB4157.namprd02.prod.outlook.com/ # [1] Acked-by: Gerd Hoffmann <kraxel@redhat.com> Link: https://lore.kernel.org/r/20251008121450.227997-1-tzimmermann@suse.de
2025-10-15drm/bochs: Use vblank timerThomas Zimmermann
Use a vblank timer to simulate the vblank interrupt. The DRM vblank helpers provide an implementation on top of Linux' hrtimer. Bochs enables and disables the timer as part of the CRTC. The atomic_flush callback sets up the event. Like vblank interrupts, the vblank timer fires at the rate of the display refresh. Most userspace limits its page flip rate according to the DRM vblank event. Bochs' virtual hardware does not provide vblank interrupts, so DRM sends each event ASAP. With the fast access time of virtual display memory, the event rate is much higher than the display mode's refresh rate; creating the next page flip almost immediately. This leads to excessive CPU overhead from even small display updates, such as moving the mouse pointer. This problem affects bochs and all other virtual displays. See [1] for a discussion in the context of hypervdrm. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/dri-devel/SN6PR02MB415702B00D6D52B0EE962C98D46CA@SN6PR02MB4157.namprd02.prod.outlook.com/ # [1] Acked-by: Gerd Hoffmann <kraxel@redhat.com> Link: https://lore.kernel.org/r/20251008093931.19138-1-tzimmermann@suse.de
2025-10-15drm/ast: Store HSync adjustment in device quirksThomas Zimmermann
Add the add4 flag to struct ast_device_quirks and set it on AST2600. Replaces a call to IS_AST_GEN7() in ast_set_crtc_reg(). Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>> Link: https://lore.kernel.org/r/20251007150343.273718-6-tzimmermann@suse.de
2025-10-15drm/ast: Store precatch settings in struct ast_device_quirksThomas Zimmermann
Add a precatch flag in struct ast_device_info and set it on AST2500 and AST2600. Remove calls to IS_AST_GENn() from ast_set_crtc_reg(). Also fix the coding style in several places. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20251007150343.273718-5-tzimmermann@suse.de
2025-10-15drm/ast: Store CRTC memory request threshold in device quirksThomas Zimmermann
Store each hardware's CRTC memory threshold in the specific instance of struct ast_device_quirks. Removes the calls to IS_AST_GENn() from ast_set_crtthd_reg(). The values stored in the registers appear to be plain limits. Hence write them in the driver in decimal format instead of hexadecimal. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20251007150343.273718-4-tzimmermann@suse.de
2025-10-15drm/ast: Support device quirksThomas Zimmermann
Define struct ast_device_quirks and add an instance for each hardware generation. The type will provide information about per-gen constants and oddities. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>> Link: https://lore.kernel.org/r/20251007150343.273718-3-tzimmermann@suse.de
2025-10-15drm/ast: Store DRAM clock table in struct ast_deviceThomas Zimmermann
Init the new field dclk_table in struct ast_device to the per-gen table of DRAM clock parameters. Use the field during modesetting. The table is static, so a setup is only required once. Removes the call to IS_AST_GEN() from the atomic commit's code path. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20251007150343.273718-2-tzimmermann@suse.de
2025-10-15drm/i915: drop unused non-i915 IS_<PLATFORM> macrosJani Nikula
The IS_LUNARLAKE(), IS_BATTLEMAGE(), and IS_PANTHERLAKE() macros were added for compatibility with the xe driver, for display needs, even though i915 does not support the platforms in question. Display has since moved away from the macros, and they are no longer needed. Remove. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20251010080021.1087315-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-10-15drm/ast: Blank with VGACR17 sync enable, always clear VGACRB6 sync offThomas Zimmermann
Blank the display by disabling sync pulses with VGACR17<7>. Unblank by reenabling them. This VGA setting should be supported by all Aspeed hardware. Ast currently blanks via sync-off bits in VGACRB6. Not all BMCs handle VGACRB6 correctly. After disabling sync during a reboot, some BMCs do not reenable it after the soft reset. The display output remains dark. When the display is off during boot, some BMCs set the sync-off bits in VGACRB6, so the display remains dark. Observed with Blackbird AST2500 BMCs. Clearing the sync-off bits unconditionally fixes these issues. Also do not modify VGASR1's SD bit for blanking, as it only disables GPU access to video memory. v2: - init vgacrb6 correctly (Jocelyn) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: ce3d99c83495 ("drm: Call drm_atomic_helper_shutdown() at shutdown time for misc drivers") Tested-by: Nick Bowler <nbowler@draconx.ca> Reported-by: Nick Bowler <nbowler@draconx.ca> Closes: https://lore.kernel.org/dri-devel/wpwd7rit6t4mnu6kdqbtsnk5bhftgslio6e2jgkz6kgw6cuvvr@xbfswsczfqsi/ Cc: Douglas Anderson <dianders@chromium.org> Cc: Dave Airlie <airlied@redhat.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Jocelyn Falempe <jfalempe@redhat.com> Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v6.7+ Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20251014084743.18242-1-tzimmermann@suse.de
2025-10-14drm/xe/sriov: Disable SR-IOV if primary GT is disabled via configfsMatt Roper
SR-IOV operation relies on the primary GT's GuC to operate (in both PF and VF mode). Don't enable the .has_sriov flag if the primary-GT was disabled by configfs. v2: - Move handling to xe_info_init(). (Michal) v3: - Just update the .has_sriov flag in xe_info_init_early(). (Michal) v4: - Drop unnecessary comment. (Michal) - Flip condition order for consistency with other checks. (Michal) Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://lore.kernel.org/r/20251013200944.2499947-48-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-14drm/xe/configfs: Add attribute to disable GT typesMatt Roper
Preventing the driver from initializing GTs of specific type(s) can be useful for debugging and early hardware bringup. Add a configfs attribute to allow this kind of control for debugging. With today's platforms and software design, this configuration setting is only effective for disabling the media GT since the driver currently requires that there always be a primary GT to probe the device. However this might change in the future --- in theory it should be possible (with some additional driver work) to allow an igpu device to come up with only the media GT and no primary GT. Or to allow an igpu device to come up with no GTs at all (for display-only usage). A primary GT will likely always be required on dgpu platforms because we rely on the BCS engines inside the primary GT for various vram operations. v2: - Expand/clarify kerneldoc for configfs attribute. (Gustavo) - Tighten type usage in gt_types[] structure. (Gustavo) - Adjust string parsing/name matching to match exact GT names and not accept partial names. (Gustavo) v3: - Switch to scope-based cleanup in gt_types_allowed_store() to fix a leak if the device is already bound. (Gustavo) - Switch configfs lookup interface to two boolean functions that specify whether primary/media are supported rather than one function that returns a mask. This is simpler to use and understand. v4: - Rename xe_configfs_*_gt_supported to xe_configfs_*_gt_allowed for consistency with configfs interface and other functions. (Gustavo) - Simplify boolean check in xe_configfs_*_gt_allowed. (Michal) - Use xe_info() for message printing. (Michal) - Use guard() instead of scoped_guard(). (Michal) - Make new functions take 'struct pci_dev' for consistency with other configfs lookup functions. (Michal) Cc: Gustavo Sousa <gustavo.sousa@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/20251013200944.2499947-47-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-14drm/xe: Break GT setup out of xe_info_init()Matt Roper
xe_info_init() is getting a bit long and hard to follow. Break the allocation and basic initialization of the xe_gt structures out to their own functions. v2: - Rename new functions from init_* to alloc_*. (Gustavo) - Move early NULL return of media GT before allocation. (Gustavo) Cc: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/20251013200944.2499947-46-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-14drm/xe: Don't check BIOS-disabled FlatCCS if primary GT is disabledMatt Roper
If the primary is GT is disabled via configfs, we can't read the GT registers that would tell us whether the BIOS has disabled FlatCCS on a platform that would otherwise have it; we'll just proceed as if the FlatCCS is still enabled. This is similar to the situation seen by SRIOV VFs and doesn't cause any functional problems since the hardware will simply drop writes to the CCS region and reads will always come back as 0 (indicating uncompressed data). We'll simply miss out on the chance to avoid some unnecessary overhead during BO creation and migration. Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/20251013200944.2499947-45-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-14drm/xe: Check that GT is not NULL before testing Wa_16023588340Matt Roper
If the primary GT is disabled, skip the check for this workaround (which only applies to dgpu platforms where the primary GT cannot be NULL). Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Link: https://lore.kernel.org/r/20251013200944.2499947-44-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-14drm/xe: Correct lineage for Wa_22014953428 and only check with valid GTMatt Roper
Wa_22014953428 was incorrectly labelled with a release-specific ID number rather than the cross-platform lineage number; fix that. Also check that the GT is not NULL before trying to lookup the workaround in it. Since this workaround only applies to DG2 discrete GPUs (where the primary GT cannot be disabled), no coverage is lost. Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/20251013200944.2499947-43-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-14drm/xe: Bypass Wa_14018094691 when primary GT is disabledMatt Roper
Don't try to lookup Wa_14018094691 on a NULL GT when the primary GT is disabled. Since this whole workaround centers around mid-thread preemption behavior, the workaround isn't relevant if the primary GT (where the engines that can do MTP live) is disabled. Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/20251013200944.2499947-42-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-14drm/xe/rtp: Pass xe_device parameter to FUNC matchesMatt Roper
FUNC matches in RTP only pass the GT and hwe, preventing them from being used effectively in device workarounds. Add an additional xe_device parameter so that we can use them in device workarounds where a GT may not be available. Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/20251013200944.2499947-41-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-14drm/xe: Handle Wa_22010954014 and Wa_14022085890 as device workaroundsMatt Roper
When Wa_22010954014 and Wa_14022085890 were first implemented, we didn't have a device workaround infrastructure so we hacked them into the GT workaround list. Now that we have proper device workaround support, move them to the proper place. Note that Wa_14022085890 specifically applies to BMG-G21 platforms, so this requires defining a BMG subplatform to capture the correct subset of device IDs. Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/20251013200944.2499947-40-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-14drm/xe/irq: Don't try to lookup engine masks for non-existent primary GTMatt Roper
If the primary GT is disabled via configfs, we shouldn't try to access it to lookup BCS/CCS engine masks. For the purposes of IRQ reset (which masks & disables interrupts in an sgunit register), assume all possible instances are present. Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Link: https://lore.kernel.org/r/20251013200944.2499947-39-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-14drm/xe: Make display part of Wa_22019338487 a device workaroundMatt Roper
The display part of Wa_22019338487 (i.e., avoiding use of stolen memory) is using a platform test rather than an graphics/media IP test. Since this workaround is focused on non-GT uses of stolen memory, it makes sense that we'd want to still apply the workaround on affected platforms even if the GTs themselves are disabled via configfs. Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/20251013200944.2499947-38-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-14drm/xe: Check for primary GT before looking up Wa_22019338487Matt Roper
If the primary GT is disabled via configfs, we need to make sure that we don't search for this workaround on a NULL xe_gt pointer. Since we can disable the primary GT only on igpu platforms, the media GT is the one we'd want to check anyway for this workaround. The ternary operators in ggtt_update_access_counter() were getting a bit long/complicated, so rewrite them with regular if/else statements. While we're at it, throw in a couple extra assertions to make sure that we're truly picking the expected GT according to igpu/dgpu type. v2: - Adjust indentation/wrapping; it's easier to read this with longer, unwrapped lines. (Lucas) - Tweak wording of commit message to remove ambiguity. (Gustavo) Cc: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/20251013200944.2499947-37-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-14drm/xe/pmu: Initialize PMU event types based on first available GTMatt Roper
GT ID#0 (primary GT on tile 0) may not always be available if the primary GT has been disabled via configfs. Instead use the first available GT when determining which PMU events are supported. If there are no GTs, then don't advertise any GT-related events. Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20251013200944.2499947-36-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-14drm/xe/query: Report hwconfig size as 0 if primary GT is disabledMatt Roper
The hwconfig table is part of the primary GT's GuC firmware. If the primary GT is disabled, the hwconfig is unavailable and should be reported to userspace as having size 0. Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Link: https://lore.kernel.org/r/20251013200944.2499947-35-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-14drm/xe: Skip L2 / TDF cache flushes if primary GT is disabledMatt Roper
If the primary GT is disabled via configfs, GT-side L2 and TD cache flushes are unnecessary since nothing is using/filling these caches. Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Link: https://lore.kernel.org/r/20251013200944.2499947-34-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-14drm/xe: Move primary GT allocation from xe_tile_init_early to xe_tile_initMatt Roper
During the early days of the Xe driver, there were cases where we accessed some fields in the primary GT's xe_gt structure before the GT itself was formally initialized; this required that the structure itself be allocated during xe_tile_init_early(). A lot of refactoring of the device probe has happened since that time and there's no longer a need to allocate the primary GT early. Move the allocation into xe_info_init() where GT initialization happens and where we're doing the allocation of the media GT. v2: - Only make this change after a separate patch to perform VF GMD_ID lookup with a dummy GT instead of xe_root_mmio_gt(). Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20251013200944.2499947-33-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-14drm/xe: Read VF GMD_ID with a specifically-allocated dummy GTMatt Roper
SRIOV VF initialization has a bit of a chicken and egg design problem. Determining the IP version of the graphics and media IPs can't be done via direct register reads as it is on PF or native and instead requires querying the GuC. However initialization of the GT, including its GuC, needs to wait until after we know the IP versions so that the proper initialization steps for the platform/IP are followed. Currently the (somewhat hacky) solution is to manually fill out just enough fields in tile 0's primary GT structure to make it look as if the GT has been initialized so that the GuC can be partially initialized and queried to obtain the GMD_ID values. When the GT gets properly initialized during the regular flows, the hacked-up values will get overwritten as part of the general initialization flows. Rather than using tile 0's primary GT structure to hold the hacked up values for querying every GT on every tile, instead allocate a dedicated dummy structure. This will allow us to move the tile->primary_gt's allocation to a more consistent place later in the initialization flow in future patches (i.e., we shouldn't even allocate this GT structure if the GT is disabled/unavailable). It also helps ensure there can't be any accidental leakage of initialization or state between the dummy initialization for GMD_ID and the real driver initialization of the GT. v2: - Initialize gt->tile for temporary GT. (CI, Michal) - Use scope-based cleanup handler to free temp GT. (Michal) - Propagate actual error code from xe_gt_sriov_vf_bootstrap() rather than just setting IP version to 0.0 now that read_gmdid() can return an error. (Michal) v3: - Explicitly initialize gt to NULL, just in case something else gets inserted before the kzalloc() in the future. (Lucas) Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20251013200944.2499947-32-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-14drm/xe: Move 'has_flatccs' flag back to platform descriptorMatt Roper
FlatCCS presence/absence is a flag that should be tracked at the platform level rather than the IP level. FlatCCS affects the device-wide memory initialization and reservations so its effects are not confined to a single IP block or GT. This is also a trait that should be tied to the platform even if the graphics IP itself is not present (e.g., if we disable the primary GT via configfs). Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20251013200944.2499947-31-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-14drm/xe: Move 'vram_flags' flag back to platform descriptorMatt Roper
Restrictions and requirements on VRAM alignment are something that should be tracked at the platform level rather than the IP level. Even when mixing and matching various graphics, media, and display IP blocks, the platform as a whole has to have consistent memory allocation handling. This is also a trait that should be tied to the platform even if the graphics IP itself is not present (e.g., if we disable the primary GT via configfs). Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20251013200944.2499947-30-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-14drm/xe: Move 'vm_max_level' flag back to platform descriptorMatt Roper
The number of page table levels for PPGTT virtual addresses is something that should be tracked at the platform level rather than the IP level. Even when mixing and matching various graphics, media, and display IP blocks, the platform as a whole has to have consistent page table handling. This is also a trait that should be tied to the platform even if the graphics IP itself is not present (e.g., if we disable the primary GT via configfs). v2: - Drop default value of 4 and explicitly set the value in each platform descriptor. (Lucas) v3: - Drop outdated code comment and commit message paragraph about default value. (Gustavo) v4: - Add missing setting for tgl_desc. (Gustavo) Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/20251013200944.2499947-29-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-14drm/xe: Move 'va_bits' flag back to platform descriptorMatt Roper
The number of virtual address bits is something that should be tracked at the platform level rather than the IP level. Even when mixing and matching various graphics, media, and display IP blocks, the platform as a whole has to have consistent page table handling. This is also a trait that should be tied to the platform even if the graphics IP itself is not present (e.g., if we disable the primary GT via configfs). v2: - Drop the default value of 48 and explicitly set it in each relevant descriptor. (Lucas, Michal) v3: - Drop an outdated comment about default value. (Michal) Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20251013200944.2499947-28-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-14drm/xe: Drop GT parameter to xe_display_irq_postinstall()Matt Roper
Display interrupt handling has no relation to GT(s) on the platforms supported by the Xe driver. We only call xe_display_irq_postinstall with the first tile's primary GT, so the single condition that uses the GT pointer within the function always evaluates to true. Drop the unnecessary parameter and the condition. Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20251013200944.2499947-27-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-14drm/xe/huc: Adjust HuC check on primary GTMatt Roper
The HuC initialization code determines whether a platform can have a HuC on the primary GT by checking whether tile->media_gt is NULL; old Xe1 platforms that combined render+media into a single GT will always have a NULL media_gt pointer. However once we allow media to be disabled via configfs, there will also be cases where tile->media_gt is NULL on more modern platforms, causing this condition to behave incorrectly. To handle cases where media gets disabled via configfs (or theoretical cases where media is truly fused off in hardware), change the condition to consider the graphics version of the primary GT; only the old Xe1 platforms with graphics versions 12.55 or earlier should try to initialize a HuC on the primary GT. Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Link: https://lore.kernel.org/r/20251013200944.2499947-26-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-14drm/xe/kunit: Fix kerneldoc for parameterized testsMatt Roper
Kunit's generate_params() was recently updated to take an additional test context parameter. Xe's IP and platform parameter generators were updated accordingly at the same time, but the new parameter was not added to the functions' kerneldoc, resulting in the following warnings: Warning: drivers/gpu/drm/xe/tests/xe_pci.c:78 function parameter 'test' not described in 'xe_pci_fake_data_gen_params' Warning: drivers/gpu/drm/xe/tests/xe_pci.c:254 function parameter 'test' not described in 'xe_pci_graphics_ip_gen_param' Warning: drivers/gpu/drm/xe/tests/xe_pci.c:278 function parameter 'test' not described in 'xe_pci_media_ip_gen_param' Warning: drivers/gpu/drm/xe/tests/xe_pci.c:302 function parameter 'test' not described in 'xe_pci_id_gen_param' Warning: drivers/gpu/drm/xe/tests/xe_pci.c:390 function parameter 'test' not described in 'xe_pci_live_device_gen_param' 5 warnings as errors Document the new parameter to eliminate the warnings and make CI happy. Fixes: b9a214b5f6aa ("kunit: Pass parameterized test context to generate_params()") Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com> Link: https://lore.kernel.org/r/20251013153014.2362879-2-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-14drm/rockchip: vop: add lut_size for RK3368 vop_dataWeiHao Li
VOP driver need a correct lut_size to work normally. According to rockchip downstream kernel source [1], the lut_size is 0x400. [1] https://github.com/rockchip-linux/kernel/blob/develop-4.4/arch/arm64/boot/dts/rockchip/rk3368.dtsi#L1497 Signed-off-by: WeiHao Li <cn.liweihao@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250905025632.222422-3-cn.liweihao@gmail.com
2025-10-14drm/rockchip: dsi: Add support for RK3368WeiHao Li
RK3368 has DesignWare MIPI DSI controller and an external inno D-PHY. Signed-off-by: WeiHao Li <cn.liweihao@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250905025632.222422-2-cn.liweihao@gmail.com
2025-10-14drm/rockchip: analogix_dp: Apply devm_clk_get_optional() for ↵Damon Ding
&rockchip_dp_device.grfclk The "grf" clock is optional for Rockchip eDP controller(RK3399 needs while RK3288 and RK3588 do not). It can make the code more concise to use devm_clk_get_optional() instead of devm_clk_get() with extra checks. In addtion, DRM_DEV_ERROR() is replaced by dev_err_probe(). Signed-off-by: Damon Ding <damon.ding@rock-chips.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250928103734.4007257-1-damon.ding@rock-chips.com
2025-10-14drm/xe/svm: Ensure data will be migrated to system if indicated by madvise.Thomas Hellström
If the location madvise() is set to DRM_XE_PREFERRED_LOC_DEFAULT_SYSTEM, the drm_pagemap in the SVM gpu fault handler will be set to NULL. However there is nothing that explicitly migrates the data to system if it is already present in device memory. In that case, set the device memory owner to NULL to ensure data gets properly migrated to system on page-fault. v2: - Remove redundant dpagemap assignment (Himal Prasad Ghimiray) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> #v1 Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://lore.kernel.org/r/20251010104149.72783-2-thomas.hellstrom@linux.intel.com Fixes: 10aa5c806030 ("drm/gpusvm, drm/xe: Fix userptr to not allow device private pages")
2025-10-14drm/xe/ct: Separate waiting for retry from ct send functionTomasz Lis
The function `guc_ct_send_locked()` is really quite simple, but still looks complex due to exposed internals. It is sending a message, and in case of lack of space, waiting for a proper moment to send a retry. Clear separation of send function and wait function will help with readability. This is a cosmetic change only, no functional difference is expected. This patch introduces `guc_ct_send_wait_for_retry()`, and uses it to greatly simplify `guc_ct_send_locked()`. Signed-off-by: Tomasz Lis <tomasz.lis@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://lore.kernel.org/r/20251009170844.178199-1-tomasz.lis@intel.com
2025-10-14drm/i915/display: add HAS_AUX_CCS() feature checkJani Nikula
We should try to get rid of checks that depend on struct drm_i915_private (or struct xe_device) in display code. HAS_FLAT_CCS() is one of them. In the interest of simplicity, add a reversed HAS_AUX_CCS() feature check macro, as that's we mostly use it for in display. v2: include adl-p (Ville) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/20251013144552.1710851-1-jani.nikula@intel.com
2025-10-14drm/i915/display: duplicate 128-byte Y-tiling feature checkJani Nikula
We should try to get rid of checks that depend on struct drm_i915_private (or struct xe_device) in display code. HAS_128_BYTE_Y_TILING() is one of them. In the interest of simplicity, just duplicate the check as HAS_128B_Y_TILING() in display. v2: gen2 also has 128-byte Y-tile Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/2a7877f8f1d11114c1a17869bd24d83e13b1fac2.1760094361.git.jani.nikula@intel.com
2025-10-14drm/i915: include gen 2 in HAS_128_BYTE_Y_TILING()Jani Nikula
Gen 2 platforms actually have 128-byte Y-tile, it's just different from the 128-byte Y-tile on i945+. Make the HAS_128_BYTE_Y_TILING() feature check macro and its usage slightly less convoluted by including gen 2 in it. i915_tiling_ok() would strictly not need changing, but separate the if clauses to emphasize gen 2 X-tile also being 128 bytes. Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/41bf9d67a11f38f4ab0f82740f38d5c8fe0bb58b.1760094361.git.jani.nikula@intel.com
2025-10-14Merge drm/drm-next into drm-xe-nextThomas Hellström
Backmerging to bring in 6.18-rc1. Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-10-14drm: atmel-hlcdc: fix atmel_xlcdc_plane_setup_scaler()Cyrille Pitchen
On SoCs, like the SAM9X75, which embed the XLCDC ip, the registers that configure the unified scaling engine were not filled with proper values. Indeed, for YCbCr formats, the VXSCFACT bitfield of the HEOCFG25 register and the HXSCFACT bitfield of the HEOCFG27 register were incorrect. For 4:2:0 formats, both vertical and horizontal factors for chroma chanels should be divided by 2 from the factors for the luma channel. Hence: HEOCFG24.VXSYFACT = VFACTOR HEOCFG25.VSXCFACT = VFACTOR / 2 HEOCFG26.HXSYFACT = HFACTOR HEOCFG27.HXSCFACT = HFACTOR / 2 However, for 4:2:2 formats, only the horizontal factor for chroma chanels should be divided by 2 from the factor for the luma channel; the vertical factor is the same for all the luma and chroma channels. Hence: HEOCFG24.VXSYFACT = VFACTOR HEOCFG25.VXSCFACT = VFACTOR HEOCFG26.HXSYFACT = HFACTOR HEOCFG27.HXSCFACT = HFACTOR / 2 Fixes: d498771b0b83 ("drm: atmel_hlcdc: Add support for XLCDC using IP specific driver ops") Signed-off-by: Cyrille Pitchen <cyrille.pitchen@microchip.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20241014094942.325211-1-manikandan.m@microchip.com Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
generated by cgit v1.2.3 (git 2.0.4) at 2026-01-08 12:20:17 +0000