summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2026-04-14drm/xe/pf: Derive admin-only PF mode from xe_device stateSatyanarayana K V P
Stop tracking admin-only PF mode in a separate `xe->sriov.pf.admin_only` field and use `xe_device_is_admin_only(xe)` as the single source of admin mode. Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20260413095637.2871287-2-satyanarayana.k.v.p@intel.com
2026-04-14drm/xe/pf: Restrict device query responses in admin-only PF modeSatyanarayana K V P
When a PF is configured in admin-only mode, it is intended for management only and must not expose workload-facing capabilities to userspace. Limit the exposed ioctl set in admin-only PF mode to XE_DEVICE_QUERY and XE_OBSERVATION, and suppress capability-bearing query payloads so that the userspace cannot discover execution-related device details in this mode. Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: Dunajski Bartosz <bartosz.dunajski@intel.com> Cc: Ashutosh Dixit <ashutosh.dixit@intel.com> Cc: dri-devel@lists.freedesktop.org Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20260409154423.2499340-5-satyanarayana.k.v.p@intel.com
2026-04-14drm/bridge: dw-mipi-dsi: Fix bridge leak when host attach failsOsama Abdelkader
dw_mipi_dsi_host_attach() and dw_mipi_dsi2_host_attach() call drm_bridge_add() before pdata->host_ops->attach(). If attach fails, the bridge stayed registered without drm_bridge_remove(), leaking the bridge reference and leaving the device on the global bridge list. Fixes: 90910a651123 ("drm/bridge/synopsys: dsi: add ability to have glue-specific attach and detach") Fixes: 0d6d86253fef ("drm/bridge/synopsys: Add MIPI DSI2 host controller bridge") Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://patch.msgid.link/20260403145208.15890-1-osama.abdelkader@gmail.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-04-14drm/arcpgu: fix device node leakLuca Ceresoli
This function gets a device_node reference via of_graph_get_remote_port_parent() and stores it in encoder_node, but never puts that reference. Add it. There used to be a of_node_put(encoder_node) but it has been removed by mistake during a rework in commit 3ea66a794fdc ("drm/arc: Inline arcpgu_drm_hdmi_init"). Fixes: 3ea66a794fdc ("drm/arc: Inline arcpgu_drm_hdmi_init") Cc: stable@vger.kernel.org Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Link: https://patch.msgid.link/20260402-drm-arcgpu-fix-device-node-leak-v2-1-d773cf754ae5@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-04-14drm/i915/wm: Verify the correct plane DDB entryVille Syrjälä
Actually verify the DDB entry for the plane we're looking at instead of always verifying the cursor DDB. Fixes: 7d4561722c3b ("drm/i915: Tweak plane ddb allocation tracking") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260324134843.2364-5-ville.syrjala@linux.intel.com Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> (cherry picked from commit f002f7c7439de18117a31ca84dc87a59719c3dd6) Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
2026-04-14drm/i915/backlight: Fix VESA backlight possible check conditionSuraj Kandpal
VESA backlight enable is possible when BACKLIGHT_AUX_ENABLE_CAPABLE is true via AUX command or when BACKLIGHT_PIN_ENABLE_CAPABLE is true via eDP connector pin. Similarly, backlight brightness adjustment can be done via AUX-based control or PWM pin-based control. It means there can be three configurations: 1) Full AUX-based: Enable and adjustment both via AUX. We currently support this (apart from the AUX luminance-based backlight control). 2) Hybrid: Enable via the BL_ENABLE pin, adjustment via either AUX or PWM. 3) Fully PWM pin-based: Enable via the BL_ENABLE pin, adjustment via PWM. Since that only 1 is supported as of now we need to make sure we do not try to manipulate backlight when BACKLIGHT_AUX_ENABLE_CAPABLE is not set. Also fix return value when condition is not fulfilled. Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/15907 Fixes: 0fb03890d182 ("drm/i915/backlight: Check if VESA backlight is possible") Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260407030710.1440046-1-suraj.kandpal@intel.com (cherry picked from commit 102d44b3a8fad96e94e9ccd0579986c14a1f2f75) Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
2026-04-13drm/xe/vf: Use drm mm instead of drm sa for CCS read/writeSatyanarayana K V P
The suballocator algorithm tracks a hole cursor at the last allocation and tries to allocate after it. This is optimized for fence-ordered progress, where older allocations are expected to become reusable first. In fence-enabled mode, that ordering assumption holds. In fence-disabled mode, allocations may be freed in arbitrary order, so limiting allocation to the current hole window can miss valid free space and fail allocations despite sufficient total space. Use DRM memory manager instead of sub-allocator to get rid of this issue as CCS read/write operations do not use fences. Fixes: 864690cf4dd6 ("drm/xe/vf: Attach and detach CCS copy commands with BO") Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Maarten Lankhorst <dev@lankhorst.se> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260408110145.1639937-6-satyanarayana.k.v.p@intel.com
2026-04-13drm/xe: Add memory pool with shadow supportSatyanarayana K V P
Add a memory pool to allocate sub-ranges from a BO-backed pool using drm_mm. Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Maarten Lankhorst <dev@lankhorst.se> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260408110145.1639937-5-satyanarayana.k.v.p@intel.com
2026-04-13Merge tag 'acpi-7.1-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI support updates from Rafael Wysocki: "These include an update of the CMOS RTC driver and the related ACPI and x86 code that, among other things, switches it over to using the platform device interface for device binding on x86 instead of the PNP device driver interface (which allows the code in question to be simplified quite a bit), a major update of the ACPI Time and Alarm Device (TAD) driver adding an RTC class device interface to it, and updates of core ACPI drivers that remove some unnecessary and not really useful code from them. Apart from that, two drivers are converted to using the platform driver interface for device binding instead of the ACPI driver one, which is slated for removal, support for the Performance Limited register is added to the ACPI CPPC library and there are some janitorial updates of it and the related cpufreq CPPC driver, the ACPI processor driver is fixed and cleaned up, and NVIDIA vendor CPER record handler is added to the APEI GHES code. Also, the interface for obtaining a CPU UID from ACPI is consolidated across architectures and used for fixing a problem with the PCI TPH Steering Tag on ARM64, there are two updates related to ACPICA, a minor ACPI OS Services Layer (OSL) update, and a few assorted updates related to ACPI tables parsing. Specifics: - Update maintainers information regarding ACPICA (Rafael Wysocki) - Replace strncpy() with strscpy_pad() in acpi_ut_safe_strncpy() (Kees Cook) - Trigger an ordered system power off after encountering a fatal error operator in AML (Armin Wolf) - Enable ACPI FPDT parsing on LoongArch (Xi Ruoyao) - Remove the temporary stop-gap acpi_pptt_cache_v1_full structure from the ACPI PPTT parser (Ben Horgan) - Add support for exposing ACPI FPDT subtables FBPT and S3PT (Nate DeSimone) - Address multiple assorted issues and clean up the code in the ACPI processor idle driver (Huisong Li) - Replace strlcat() in the ACPI processor idle drive with a better alternative (Andy Shevchenko) - Rearrange and clean up acpi_processor_errata_piix4() (Rafael Wysocki) - Move reference performance to capabilities and fix an uninitialized variable in the ACPI CPPC library (Pengjie Zhang) - Add support for the Performance Limited Register to the ACPI CPPC library (Sumit Gupta) - Add cppc_get_perf() API to read performance controls, extend cppc_set_epp_perf() for FFH/SystemMemory, and make the ACPI CPPC library warn on missing mandatory DESIRED_PERF register (Sumit Gupta) - Modify the cpufreq CPPC driver to update MIN_PERF/MAX_PERF in target callbacks to allow it to control performance bounds via standard scaling_min_freq and scaling_max_freq sysfs attributes and add sysfs documentation for the Performance Limited Register to it (Sumit Gupta) - Add ACPI support to the platform device interface in the CMOS RTC driver, make the ACPI core device enumeration code create a platform device for the CMOS RTC, and drop CMOS RTC PNP device support (Rafael Wysocki) - Consolidate the x86-specific CMOS RTC handling with the ACPI TAD driver and clean up the CMOS RTC ACPI address space handler (Rafael Wysocki) - Enable ACPI alarm in the CMOS RTC driver if advertised in ACPI FADT and allow that driver to work without a dedicated IRQ if the ACPI alarm is used (Rafael Wysocki) - Clean up the ACPI TAD driver in various ways and add an RTC class device interface, including both the RTC setting/reading and alarm timer support, to it (Rafael Wysocki) - Clean up the ACPI AC and ACPI PAD (processor aggregator device) drivers (Rafael Wysocki) - Rework checking for duplicate video bus devices and consolidate pnp.bus_id workarounds handling in the ACPI video bus driver (Rafael Wysocki) - Update the ACPI core device drivers to stop setting acpi_device_name() unnecessarily (Rafael Wysocki) - Rearrange code using acpi_device_class() in the ACPI core device drivers and update them to stop setting acpi_device_class() unnecessarily (Rafael Wysocki) - Define ACPI_AC_CLASS in one place (Rafael Wysocki) - Convert the ni903x_wdt watchdog driver and the xen ACPI PAD driver to bind to platform devices instead of ACPI devices (Rafael Wysocki) - Add devm_ghes_register_vendor_record_notifier(), use it in the PCI hisi driver, and Add NVIDIA vendor CPER record handler (Kai-Heng Feng) - Consolidate the interface for obtaining a CPU UID from ACPI across architectures and use it to address incorrect PCI TPH Steering Tag on ARM64 resulting from the invalid assumption that the ACPI Processor UID would always be the same as the corresponding logical CPU ID in Linux (Chengwen Feng)" * tag 'acpi-7.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (73 commits) ACPICA: Update maintainers information watchdog: ni903x_wdt: Convert to a platform driver ACPI: PAD: xen: Convert to a platform driver ACPI: processor: idle: Reset cpuidle on C-state list changes cpuidle: Extract and export no-lock variants of cpuidle_unregister_device() PCI/TPH: Pass ACPI Processor UID to Cache Locality _DSM ACPI: PPTT: Use acpi_get_cpu_uid() and remove get_acpi_id_for_cpu() perf: arm_cspmu: Switch to acpi_get_cpu_uid() from get_acpi_id_for_cpu() ACPI: Centralize acpi_get_cpu_uid() declaration in include/linux/acpi.h x86/acpi: Add acpi_get_cpu_uid() for unified ACPI CPU UID retrieval RISC-V: ACPI: Add acpi_get_cpu_uid() for unified ACPI CPU UID retrieval LoongArch: Add acpi_get_cpu_uid() for unified ACPI CPU UID retrieval arm64: acpi: Add acpi_get_cpu_uid() for unified ACPI CPU UID retrieval ACPI: APEI: GHES: Add NVIDIA vendor CPER record handler PCI: hisi: Use devm_ghes_register_vendor_record_notifier() ACPI: APEI: GHES: Add devm_ghes_register_vendor_record_notifier() ACPI: tables: Enable FPDT on LoongArch ACPI: processor: idle: Fix NULL pointer dereference in hotplug path ACPI: processor: idle: Reset power_setup_done flag on initialization failure ACPI: TAD: Add alarm support to the RTC class device interface ...
2026-04-13drm/xe/debugfs: Correct printing of register whitelist rangesMatt Roper
The register-save-restore debugfs prints whitelist entries as offset ranges. E.g., REG[0x39319c-0x39319f]: allow read access for a single dword-sized register. However the GENMASK value used to set the lower bits to '1' for the upper bound of the whitelist range incorrectly included one more bit than it should have, causing the whitelist ranges to sometimes appear twice as large as they really were. For example, REG[0x6210-0x6217]: allow rw access was also intended to be a single dword-sized register whitelist (with a range 0x6210-0x6213) but was printed incorrectly as a qword-sized range because one too many bits was flipped on. Similar 'off by one' logic was applied when printing 4-dword register ranges and 64-dword register ranges as well. Correct the GENMASK logic to print these ranges in debugfs correctly. No impact outside of correcting the misleading debugfs output. Fixes: d855d2246ea6 ("drm/xe: Print whitelist while applying") Reviewed-by: Stuart Summers <stuart.summers@intel.com> Link: https://patch.msgid.link/20260408-regsr_wl_range-v1-1-e9a28c8b4264@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-04-13drm/xe: Mark ROW_CHICKEN5 as a masked registerMatt Roper
ROW_CHICKEN5 is a masked register (i.e., to adjust the value of any of the lower 16 bits, the corresponding bit in the upper 16 bits must also be set). Add the XE_REG_OPTION_MASKED to its definition; failure to do so will cause workaround updates of this register to not apply properly. Bspec: 56853 Fixes: 835cd6cbb0d0 ("drm/xe/xe3p_lpg: Add initial workarounds for graphics version 35.10") Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patch.msgid.link/20260410-xe3p_tuning-v1-3-e206a62ee38f@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-04-13drm/xe/tuning: Use proper register offset for GAMSTLB_CTRLMatt Roper
From Xe2 onward (i.e., all platforms officially supported by the Xe driver), the GAMSTLB_CTRL register is located at offset 0x477C and represented by the macro "GAMSTLB_CTRL" in code. However the register formerly resided at offset 0xCF4C on Xe1-era platforms, and we also have macro XEHP_GAMSTLB_CTRL that represents this old offset in the unofficial/developer-only Xe1 code. When tuning for the register was added for Xe3p_LPG, the old Xe1-era macro was accidentally used instead of the proper macro for Xe2 and beyond, causing the tuning to not be applied properly. Use the proper definition so that the correct offset is written to. Bspec: 59298 Fixes: 377c89bfaa5d ("drm/xe/xe3p_lpg: Set STLB bank hash mode to 4KB") Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patch.msgid.link/20260410-xe3p_tuning-v1-2-e206a62ee38f@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-04-13drm/xe/tuning: Stop applying CCCHKNREG1 tuning from Xe3p onwardMatt Roper
Whereas the tuning guide gave guidance on adjusting various CCCHKNREG1 on past platforms, starting from Xe3p the guidance is "Leave register at HW default settings." Set a version range upper bound of "34.99" so that the current programming will stop being applied on any Xe3p platforms that have graphics version 35. Bspec: 72161 Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patch.msgid.link/20260410-xe3p_tuning-v1-1-e206a62ee38f@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-04-13Merge tag 'vfs-7.1-rc1.kino' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs Pull vfs i_ino updates from Christian Brauner: "For historical reasons, the inode->i_ino field is an unsigned long, which means that it's 32 bits on 32 bit architectures. This has caused a number of filesystems to implement hacks to hash a 64-bit identifier into a 32-bit field, and deprives us of a universal identifier field for an inode. This changes the inode->i_ino field from an unsigned long to a u64. This shouldn't make any material difference on 64-bit hosts, but 32-bit hosts will see struct inode grow by at least 4 bytes. This could have effects on slabcache sizes and field alignment. The bulk of the changes are to format strings and tracepoints, since the kernel itself doesn't care that much about the i_ino field. The first patch changes some vfs function arguments, so check that one out carefully. With this change, we may be able to shrink some inode structures. For instance, struct nfs_inode has a fileid field that holds the 64-bit inode number. With this set of changes, that field could be eliminated. I'd rather leave that sort of cleanups for later just to keep this simple" * tag 'vfs-7.1-rc1.kino' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs: nilfs2: fix 64-bit division operations in nilfs_bmap_find_target_in_group() EVM: add comment describing why ino field is still unsigned long vfs: remove externs from fs.h on functions modified by i_ino widening treewide: fix missed i_ino format specifier conversions ext4: fix signed format specifier in ext4_load_inode trace event treewide: change inode->i_ino from unsigned long to u64 nilfs2: widen trace event i_ino fields to u64 f2fs: widen trace event i_ino fields to u64 ext4: widen trace event i_ino fields to u64 zonefs: widen trace event i_ino fields to u64 hugetlbfs: widen trace event i_ino fields to u64 ext2: widen trace event i_ino fields to u64 cachefiles: widen trace event i_ino fields to u64 vfs: widen trace event i_ino fields to u64 net: change sock.sk_ino and sock_i_ino() to u64 audit: widen ino fields to u64 vfs: widen inode hash/lookup functions to u64
2026-04-13drm/i915/dp: Make the RGB fallback for "4:2:0 only" modes the last resortVille Syrjälä
Currently we take the Hail Mary RGB fallback for "4:2:0 only" modes already during the first pass when respect_downstream_limits==true. It seems better to try everything else first (like ignoring TMDS clock limits) while still preferring 4:2:0, and only if everything else has failed fall back to RGB. Cc: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260409101539.22032-10-ville.syrjala@linux.intel.com Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
2026-04-13drm/i915/hdmi: Make the RGB fallback for "4:2:0 only" modes the last resortVille Syrjälä
Currently we take the Hail Mary RGB fallback for "4:2:0 only" modes already during the first pass when respect_downstream_limits==true. It seems better to try everything else first (like ignoring TMDS clock limits) while still preferring 4:2:0, and only if everything else has failed fall back to RGB. Cc: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260409101539.22032-9-ville.syrjala@linux.intel.com Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
2026-04-13drm/i915/dp: Validate sink format in .mode_valid()Ville Syrjälä
Make sure the sink supports our chosen sink format. I suppose it might be at least possible that some PCONs might not snoop the EDID hard enough and filter out all the modes that they should. Also if we ever want to add a similar "force DVI" knob to DP outputs that we have for native HDMI, we'd need to manually get rid of anything DVI sinks can't handle. Cc: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260409101539.22032-8-ville.syrjala@linux.intel.com Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
2026-04-13drm/i915/dp: Require a HDMI sink for YCbCr output via PCONVille Syrjälä
DVI sinks can't deal with YCbCr. Make sure we have a HDMI sink connected after the PCON before doing YCbCr 4:2:0 output. Cc: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260409101539.22032-7-ville.syrjala@linux.intel.com Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
2026-04-13drm/i915/dp: Validate "4:2:0 also" modes twiceVille Syrjälä
Currently we only validate "4:2:0 also" modes as RGB. But if that fails we could perhaps still use the mode in with 4:2:0 output. All we have to do is retry the validation with the different sink format. So far we did the double validation only so far as it affects PCON TMDS clock limits. But validating everything twice seems a bit more sane. Note that intel_dp_output_format() might still end up picking RGB for the actual output format (and letting PCON deal with the YCbCr conversion). So I suppose we could still fail the validation due to that, and forcing even the output format to 4:2:0 might solve it on a third try. But we'd need the same fallback logic in intel_dp_compute_config(). For now this seems sufficient. v2: Pass output_format to intel_dp_mode_min_link_bpp_x16() Add TODO about remaining issues Nuke intel_dp_sink_format() Cc: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260409101539.22032-6-ville.syrjala@linux.intel.com Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
2026-04-13drm/i915/dp: Restructure the sink/output format selectionVille Syrjälä
Restructure intel_dp_compute_output_format() to resemble the new intel_hdmi_compute_output_formats(). Again, we basically have two main code paths: - YCbCr 4:2:0 only modes - everything else including YCbCr 4:2:0 also modes Take the exact same approach with the DP code, making the format selection much less convoluted. Cc: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260409101539.22032-5-ville.syrjala@linux.intel.com Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
2026-04-13drm/i915/hdmi: Restructure 4:2:0 vs. 4:4:4 mode validationVille Syrjälä
Restructure the HDMI mode validation to resemble the new intel_hdmi_compute_formats(). Keeping the two in sync helps to avoid different bugs in each. The main difference between mode_valid() and intel_hdmi_compute_formats() is that we don't want the Hail Mary RGB fallback for "4:2:0 only" modes. Cc: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260409101539.22032-4-ville.syrjala@linux.intel.com Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
2026-04-13drm/i915/hdmi: Restructure the sink/output format selectionVille Syrjälä
intel_hdmi_compute_output_format() is a bit of a mess. Try to restructure it into a more readable form. Right now we basically have two main code paths: - YCbCr 4:2:0 only modes - everything else including YCbCr 4:2:0 also modes Those two basically do the same two steps (try 4:2:0 and try 4:4:4) but in opposite orders. Let's write that out in a more explicit if-else form. And since I'm running out of function names I'll rename the function with that high level logic into intel_hdmi_compute_formats() and it will call (the new) intel_hdmi_compute_output_format() with an explicit sink_format as needed. Cc: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260409101539.22032-3-ville.syrjala@linux.intel.com Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
2026-04-13drm/i915/hdmi: Add missing intel_pfit_mode_valid() for 4:2:0 also modesVille Syrjälä
intel_hdmi_mode_valid() is calling intel_pfit_mode_valid() only on the first attempt (4:2:0 for "4:2:0 only" modes, 4:4:4 for everything else). Add the call also for the "4:2:0 also" modes case so that we actually know the pipe scaler can actually produce the 4:2:0 output. Cc: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260409101539.22032-2-ville.syrjala@linux.intel.com Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
2026-04-13Merge tag 'rust-7.1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux Pull Rust updates from Miguel Ojeda: "Toolchain and infrastructure: - Bump the minimum Rust version to 1.85.0 (and 'bindgen' to 0.71.1). As proposed in LPC 2025 and the Maintainers Summit [1], we are going to follow Debian Stable's Rust versions as our minimum versions. Debian Trixie was released on 2025-08-09 with a Rust 1.85.0 and 'bindgen' 0.71.1 toolchain, which is a fair amount of time for e.g. kernel developers to upgrade. Other major distributions support a Rust version that is high enough as well, including: + Arch Linux. + Fedora Linux. + Gentoo Linux. + Nix. + openSUSE Slowroll and openSUSE Tumbleweed. + Ubuntu 25.10 and 26.04 LTS. In addition, 24.04 LTS using their versioned packages. The merged patch series comes with the associated cleanups and simplifications treewide that can be performed thanks to both bumps, as well as documentation updates. In addition, start using 'bindgen''s '--with-attribute-custom-enum' feature to set the 'cfi_encoding' attribute for the 'lru_status' enum used in Binder. Link: https://lwn.net/Articles/1050174/ [1] - Add experimental Kconfig option ('CONFIG_RUST_INLINE_HELPERS') that inlines C helpers into Rust. Essentially, it performs a step similar to LTO, but just for the helpers, i.e. very local and fast. It relies on 'llvm-link' and its '--internalize' flag, and requires a compatible LLVM between Clang and 'rustc' (i.e. same major version, 'CONFIG_RUSTC_CLANG_LLVM_COMPATIBLE'). It is only enabled for two architectures for now. The result is a measurable speedup in different workloads that different users have tested. For instance, for the null block driver, it amounts to a 2%. - Support global per-version flags. While we already have per-version flags in many places, we didn't have a place to set global ones that depend on the compiler version, i.e. in 'rust_common_flags', which sometimes is needed to e.g. tweak the lints set per version. Use that to allow the 'clippy::precedence' lint for Rust < 1.86.0, since it had a change in behavior. - Support overriding the crate name and apply it to Rust Binder, which wanted the module to be called 'rust_binder'. - Add the remaining '__rust_helper' annotations (started in the previous cycle). 'kernel' crate: - Introduce the 'const_assert!' macro: a more powerful version of 'static_assert!' that can refer to generics inside functions or implementation bodies, e.g.: fn f<const N: usize>() { const_assert!(N > 1); } fn g<T>() { const_assert!(size_of::<T>() > 0, "T cannot be ZST"); } In addition, reorganize our set of build-time assertion macros ('{build,const,static_assert}!') to live in the 'build_assert' module. Finally, improve the docs as well to clarify how these are different from one another and how to pick the right one to use, and their equivalence (if any) to the existing C ones for extra clarity. - 'sizes' module: add 'SizeConstants' trait. This gives us typed 'SZ_*' constants (avoiding casts) for use in device address spaces where the address width depends on the hardware (e.g. 32-bit MMIO windows, 64-bit GPU framebuffers, etc.), e.g.: let gpu_heap = 14 * u64::SZ_1M; let mmio_window = u32::SZ_16M; - 'clk' module: implement 'Send' and 'Sync' for 'Clk' and thus simplify the users in Tyr and PWM. - 'ptr' module: add 'const_align_up'. - 'str' module: improve the documentation of the 'c_str!' macro to explain that one should only use it for non-literal cases (for the other case we instead use C string literals, e.g. 'c"abc"'). - Disallow the use of 'CStr::{as_ptr,from_ptr}' and clean one such use in the 'task' module. - 'sync' module: finish the move of 'ARef' and 'AlwaysRefCounted' outside of the 'types' module, i.e. update the last remaining instances and finally remove the re-exports. - 'error' module: clarify that 'from_err_ptr' can return 'Ok(NULL)', including runtime-tested examples. The intention is to hopefully prevent UB that assumes the result of the function is not 'NULL' if successful. This originated from a case of UB I noticed in 'regulator' that created a 'NonNull' on it. Timekeeping: - Expand the example section in the 'HrTimer' documentation. - Mark the 'ClockSource' trait as unsafe to ensure valid values for 'ktime_get()'. - Add 'Delta::from_nanos()'. 'pin-init' crate: - Replace the 'Zeroable' impls for 'Option<NonZero*>' with impls of 'ZeroableOption' for 'NonZero*'. - Improve feature gate handling for unstable features. - Declutter the documentation of implementations of 'Zeroable' for tuples. - Replace uses of 'addr_of[_mut]!' with '&raw [mut]'. rust-analyzer: - Add type annotations to 'generate_rust_analyzer.py'. - Add support for scripts written in Rust ('generate_rust_target.rs', 'rustdoc_test_builder.rs', 'rustdoc_test_gen.rs'). - Refactor 'generate_rust_analyzer.py' to explicitly identify host and target crates, improve readability, and reduce duplication. And some other fixes, cleanups and improvements" * tag 'rust-7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux: (79 commits) rust: sizes: add SizeConstants trait for device address space constants rust: kernel: update `file_with_nul` comment rust: kbuild: allow `clippy::precedence` for Rust < 1.86.0 rust: kbuild: support global per-version flags rust: declare cfi_encoding for lru_status docs: rust: general-information: use real example docs: rust: general-information: simplify Kconfig example docs: rust: quick-start: remove GDB/Binutils mention docs: rust: quick-start: remove Nix "unstable channel" note docs: rust: quick-start: remove Gentoo "testing" note docs: rust: quick-start: add Ubuntu 26.04 LTS and remove subsection title docs: rust: quick-start: update minimum Ubuntu version docs: rust: quick-start: update Ubuntu versioned packages docs: rust: quick-start: openSUSE provides `rust-src` package nowadays rust: kbuild: remove "dummy parameter" workaround for `bindgen` < 0.71.1 rust: kbuild: update `bindgen --rust-target` version and replace comment rust: rust_is_available: remove warning for `bindgen` < 0.69.5 && libclang >= 19.1 rust: rust_is_available: remove warning for `bindgen` 0.66.[01] rust: bump `bindgen` minimum supported version to 0.71.1 (Debian Trixie) rust: block: update `const_refs_to_static` MSRV TODO comment ...
2026-04-13drm/bridge: analogix_dp: Apply panel_bridge helperDamon Ding
In order to unify the handling of the panel and bridge, apply panel_bridge helpers for Analogix DP driver. With this patch, the bridge support will also become available. The following changes have ben made: - Apply plane_bridge helper to wrap the panel as the bridge. - Remove the explicit panel APIs calls, which can be replaced with the automic bridge APIs calls wrapped by the panel. - Remove the unnecessary analogix_dp_bridge_get_modes(). Signed-off-by: Damon Ding <damon.ding@rock-chips.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Heiko Stuebner <heiko@sntech.de> # rk3588 Link: https://patch.msgid.link/20260413132551.1049307-9-damon.ding@rock-chips.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-04-13drm/bridge: analogix_dp: Remove bridge disabing and panel unpreparing in ↵Damon Ding
analogix_dp_unbind() The analogix_dp_unbind() should be balanced with analogix_dp_bind(). There are no bridge enabling and panel preparing in analogix_dp_bind(), so it should be reasonable to remove the bridge disabing and panel unpreparing in analogix_dp_unbind(). Signed-off-by: Damon Ding <damon.ding@rock-chips.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Heiko Stuebner <heiko@sntech.de> # rk3588 Link: https://patch.msgid.link/20260413132551.1049307-8-damon.ding@rock-chips.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-04-13drm/bridge: analogix_dp: Attach the next bridge in analogix_dp_bridge_attach()Damon Ding
Uniformly, move the next bridge attachment to the Analogix side rather than scattered on Rockchip and Exynos sides. It can also help get rid of the callback &analogix_dp_plat_data.attach() and make codes more concise. Signed-off-by: Damon Ding <damon.ding@rock-chips.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Heiko Stuebner <heiko@sntech.de> # rk3588 Link: https://patch.msgid.link/20260413132551.1049307-7-damon.ding@rock-chips.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-04-13drm/exynos: exynos_dp: Apply analogix_dp_finish_probe()Damon Ding
Apply analogix_dp_finish_probe() in order to move the panel/bridge parsing from Exynos side to the Analogix side. Signed-off-by: Damon Ding <damon.ding@rock-chips.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Heiko Stuebner <heiko@sntech.de> # rk3588 Link: https://patch.msgid.link/20260413132551.1049307-6-damon.ding@rock-chips.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-04-13drm/rockchip: analogix_dp: Apply analogix_dp_finish_probe()Damon Ding
Apply analogix_dp_finish_probe() in order to move the panel/bridge parsing from Rockchip side to the Analogix side. Signed-off-by: Damon Ding <damon.ding@rock-chips.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Tested-by: Heiko Stuebner <heiko@sntech.de> # rk3588 Link: https://patch.msgid.link/20260413132551.1049307-5-damon.ding@rock-chips.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-04-13drm/bridge: analogix_dp: Add new API analogix_dp_finish_probe()Damon Ding
Since the panel/bridge should logically be positioned behind the Analogix bridge in the display pipeline, it makes sense to handle the panel/bridge parsing on the Analogix side. Therefore, we add a new API analogix_dp_finish_probe(), which combines the panel/bridge parsing with component addition, to do it. In order to process component binding right after the probe completes, the &analogix_dp_plat_data.ops is newly added to pass &component_ops, for which the &dp_aux_ep_device_with_data.done_probing() of DP AUX bus only supports passing &drm_dp_aux. Signed-off-by: Damon Ding <damon.ding@rock-chips.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Heiko Stuebner <heiko@sntech.de> # rk3588 Link: https://patch.msgid.link/20260413132551.1049307-4-damon.ding@rock-chips.com [Luca: propagate 'depends on OF' to DRM_ANALOGIX_DP and reverse dependencies] Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-04-13Merge branch 'nocache-cleanup'Linus Torvalds
This series cleans up some of the special user copy functions naming and semantics. In particular, get rid of the (very traditional) double underscore names and behavior: the whole "optimize away the range check" model has been largely excised from the other user accessors because it's so subtle and can be unsafe, but also because it's just not a relevant optimization any more. To do that, a couple of drivers that misused the "user" copies as kernel copies in order to get non-temporal stores had to be fixed up, but that kind of code should never have been allowed anyway. The x86-only "nocache" version was also renamed to more accurately reflect what it actually does. This was all done because I looked at this code due to a report by Jann Horn, and I just couldn't stand the inconsistent naming, the horrible semantics, and the random misuse of these functions. This code should probably be cleaned up further, but it's at least slightly closer to normal semantics. I had a more intrusive series that went even further in trying to normalize the semantics, but that ended up hitting so many other inconsistencies between different architectures in this area (eg 'size_t' vs 'unsigned long' vs 'int' as size arguments, and various iovec check differences that Vasily Gorbik pointed out) that I ended up with this more limited version that fixed the worst of the issues. Reported-by: Jann Horn <jannh@google.com> Tested-by: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/all/CAHk-=wgg1QVWNWG-UCFo1hx0zqrPnB3qhPzUTrWNft+MtXQXig@mail.gmail.com/ * nocache-cleanup: x86-64/arm64/powerpc: clean up and rename __copy_from_user_flushcache x86: rename and clean up __copy_from_user_inatomic_nocache() x86-64: rename misleadingly named '__copy_user_nocache()' function
2026-04-13drm/bridge: analogix_dp: Apply drm_bridge_connector helperDamon Ding
Initialize bridge_connector for both Rockchip and Exynos encoder sides. Then, make DRM_BRIDGE_ATTACH_NO_CONNECTOR mandatory for Analogix bridge side, as the private &drm_connector is no longer created. The previous &drm_connector_funcs and &drm_connector_helper_funcs APIs are replaced by the corresponding &drm_bridge_funcs APIs: analogix_dp_atomic_check() -> analogix_dp_bridge_atomic_check() analogix_dp_detect() -> analogix_dp_bridge_detect() analogix_dp_get_modes() -> analogix_dp_bridge_get_modes() analogix_dp_bridge_edid_read() Additionally, the compatibilities of Analogix DP bridge based on whether the next bridge is a 'panel'. If it is, OP_MODES and OP_DETECT are supported; If not (the next bridge is a 'monitor' or a bridge chip), OP_EDID and OP_DETECT are supported. The devm_drm_bridge_add() is placed in analogix_dp_bind() instead of analogix_dp_probe(), because the type of next bridge (the panel, monitor or bridge chip) can only be determined after the probe process has fully completed. Signed-off-by: Damon Ding <damon.ding@rock-chips.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Heiko Stuebner <heiko@sntech.de> # rk3588 Link: https://patch.msgid.link/20260413132551.1049307-3-damon.ding@rock-chips.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-04-13drm/bridge: analogix_dp: Pass struct drm_atomic_state* for ↵Damon Ding
analogix_dp_bridge_mode_set() To avoid using &analogix_dp_device.connector for compatibility with the bridge connector framework, get &drm_connector from &drm_atomic_state instead. Signed-off-by: Damon Ding <damon.ding@rock-chips.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://patch.msgid.link/20260413132551.1049307-2-damon.ding@rock-chips.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-04-13drm/panthor: Fix outdated function documentationAdrián Larumbe
'vm' is no longer allowed to be NULL. Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Fixes: 8a1cc07578bf ("drm/panthor: Add GEM logical block") Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20260408191228.537625-2-adrian.larumbe@collabora.com Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com>
2026-04-13drm/panthor: Extend VM locked region for remap case to be a supersetAdrián Larumbe
In the event of an sm_step_remap() that leads to a partial unmap of a transparent huge page, the new locked region required by an extended unmap might not be a superset of the original one. Then, if it leaves a portion of the initially requested one out, the ensuing map will trigger a warning. Fixes: 8e7460eac786 ("drm/panthor: Support partial unmaps of huge pages") Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20260408191228.537625-1-adrian.larumbe@collabora.com Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com>
2026-04-13drm/i915/mst: Remove redundant has_pch_encoder=false assignmentVille Syrjälä
The entire crtc_state is zeroed by default, there is no need to fiddle with crtc_state->has_pch_encoder unless we are actually dealing with a port on the PCH (which we never are for DP MST). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260409100841.1907-2-ville.syrjala@linux.intel.com Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
2026-04-13drm/i915/mst: Call intel_pfit_compute_config() for sharpness filterVille Syrjälä
The sharpness filter property is on the CRTC (as opposed to the connector) so the expectation is that it's usable on all output types. Since the sharpness filter is now fully integrateds into the normal pfit code intel_pfit_compute_config() must be called from the encoder .compute_config() on all relevant output types. Sharpness filter is supported on LNL+ so only HDMI and DP SST/MST outputs are actually relevant. I already took care of HDMI and DP SST, but (as usual) forgot about DP MST. Add the missing intel_pfit_compute_config() call to make the sharpness filter operational on DP MST as well. Cc: Nemesa Garg <nemesa.garg@intel.com> Fixes: d4686f34bbeb ("drm/i915/pfit: Call intel_pfit_compute_config() unconditionally on (e)DP/HDMI") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260409100841.1907-1-ville.syrjala@linux.intel.com Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
2026-04-13drm/bridge: stm_lvds: Do not fail atomic_check on disabled connectorMarek Vasut
If the connector is disabled, the new connector state has .crtc field set to NULL and there is nothing more to validate after that point. The .crtc field being NULL is not an error. Test for .crtc being NULL, and if it is NULL, exit early with return 0. This fixes a failure in suspend/resume path, where the connector is already disabled, but .atomic_check is called, fails, returns -EINVAL and blocks the suspend entry. Fixes: aca1cbc1c986 ("drm/stm: lvds: add new STM32 LVDS Display Interface Transmitter driver") Signed-off-by: Marek Vasut <marex@nabladev.com> Acked-by: Raphaël Gallais-Pou <raphael.gallais-pou@foss.st.com> Link: https://patch.msgid.link/20260409024928.344010-1-marex@nabladev.com Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
2026-04-13drm/i915: Walk crtcs in pipe orderVille Syrjälä
Currently our crtcs are registered in pipe order, and thus all the for_intel_crtc*() iterators walk the crtcs in pipe order. There are a bunch of places that more or less depend on that. Eg. during plane updates and such we want joined pipes to be processed back-to-back to give a better chance of an atomic update across the whole set. When we start to register crtcs in a different order we don't want to change the order in which the pipes get handled. Decouple the for_each_intel_crtc*() iterators from the crtc registration order by using a separate list which will be sorted by the pipe rather than the crtc index. We could probably use a simple array or something, but that would require some kind of extra iterator variable for the macros, and thus would require a lot more changes. Using a linked list keeps the fallout minimal. We can look at using a more optimal data structure later. I also added this extra junk to the atomic state iterators: "(__i) = drm_crtc_index(&(crtc)->base), (void)(__i)" even though the macro itself no longer needs the "__i" iterator. This in case the "__i" is used by the caller, and to avoid compiler warnings if it's completely unused now. v2: Flip the pipe comparison (Jani) Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260408155744.13326-3-ville.syrjala@linux.intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-04-13drm/i915/joiner: Make joiner "nomodeset" state copy independent of pipe orderVille Syrjälä
Currently the joiner primary->secondary hw state copy still happens from the main compute_config loop alongside the primary uapi->hw state copy. The primary uapi->hw state copy must therefore happen first, or else we'll end up copying stale junk into the secondary. We have a WARN in intel_atomic_check_joiner() to make sure the CRTCs will be walked in the correct order. The plan is to reoder the CRTCs, which would mess up the order, unless we also adjust the iterators to keep the pipe order. The actual plan is to do both, so technically we should be able to just remove the WARN and call it a day. But relying on the iteration order like this is fragile and confusing, so let's move the "nomodeset" joiner state copy into the later loop where the "modeset" state copy is also done. The first loop having completely finished, we are guaranteed to have up to date hw state on the primary when we do the copy to the secondary. Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260408155744.13326-2-ville.syrjala@linux.intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-04-12drm/pagemap: Fix drm_pagemap_migrate_unmap_pages kerneldocMatthew Brost
Replace @dma_addr with @pagemap_addr in the function documentation, as @pagemap_addr is the actual name of the function argument. Suggested-by: Francois Dugast <francois.dugast@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Francois Dugast <francois.dugast@intel.com> Link: https://patch.msgid.link/20260410205929.3914474-6-matthew.brost@intel.com
2026-04-12drm/pagemap: Use dma-map IOVA alloc, link, and sync API for DRM pagemapMatthew Brost
The dma-map IOVA alloc, link, and sync APIs perform significantly better than dma-map / dma-unmap, as they avoid costly IOMMU synchronizations. This difference is especially noticeable when mapping a 2MB region in 4KB pages. Use the IOVA alloc, link, and sync APIs for DRM pagemap, which create DMA mappings between the CPU and GPU for copying data. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Francois Dugast <francois.dugast@intel.com> Link: https://patch.msgid.link/20260410205929.3914474-5-matthew.brost@intel.com
2026-04-12drm/pagemap: Split drm_pagemap_migrate_map_pages into device / systemMatthew Brost
Split drm_pagemap_migrate_map_pages into device / system helpers clearly seperating these operations. Will help with upcoming changes to split IOVA allocation steps. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Francois Dugast <francois.dugast@intel.com> Link: https://patch.msgid.link/20260410205929.3914474-4-matthew.brost@intel.com
2026-04-12drm/pagemap: Drop source_peer_migrates flag and assume trueMatthew Brost
All current users of DRM pagemap set source_peer_migrates to true during migration, and it is unclear whether any user would ever want to disable this for performance reasons or for features such as compression. It is also questionable whether this flag could be made to work with high-speed fabric mapping APIs. Drop the flag and make DRM pagemap unconditionally assume that source_peer_migrates is true. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Francois Dugast <francois.dugast@intel.com> Link: https://patch.msgid.link/20260410205929.3914474-3-matthew.brost@intel.com
2026-04-12drm/gpusvm: Use dma-map IOVA alloc, link, and sync API in GPU SVMMatthew Brost
The dma-map IOVA alloc, link, and sync APIs perform significantly better than dma-map / dma-unmap, as they avoid costly IOMMU synchronizations. This difference is especially noticeable when mapping a 2MB region in 4KB pages. Use the IOVA alloc, link, and sync APIs for GPU SVM, which create DMA mappings between the CPU and GPU. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/20260410205929.3914474-2-matthew.brost@intel.com
2026-04-12drm/xe/pf: Perform fair scheduling auto-provisioningMichal Wajdeczko
Default VF scheduling configuration is the same as for the PF and includes unlimited execution quantum (EQ) and unlimited preemption timeout (PT). While this setup gives the most flexibility it does not protect the PF or VFs from other VF that could constantly submit workloads without any gaps that would let GuC do a VF-switch. To avoid that, do some trivial auto-provisioning and configure PF and all VFs with 16ms EQ and PT. This setup should allow GuC to perform a full round-robin with up to 63 VFs within 2s, which in turn should match expectations from most of the VMs using VFs. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> #v1 Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Link: https://patch.msgid.link/20260402191726.4932-14-michal.wajdeczko@intel.com
2026-04-12drm/xe/pf: Extract helpers for bulk EQ/PT provisioningMichal Wajdeczko
We already have functions to bulk provision execution quantum and preemption timeout, but they are applying changes to all possible VFs, while in upcoming patch we would like to provision only subset of available VFs. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://patch.msgid.link/20260402191726.4932-13-michal.wajdeczko@intel.com
2026-04-12drm/xe/pf: Extract helper to show which VFs are provisionedMichal Wajdeczko
In upcoming patches we will want to show which VFs were already provisioned with resources other than LMEM(VRAM). Convert code from the LMEM reporting function into a more generic helper that can handle both u32 and u64 resources and can report also PF. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://patch.msgid.link/20260402191726.4932-12-michal.wajdeczko@intel.com
2026-04-12drm/xe/pf: Reprovision scheduling to default when no VFsMichal Wajdeczko
Once we have disabled VFs there is no point in keeping potentially limited PF scheduling provisioning as we want to complete a cleanup of the VFs resources and return to the pure native mode, the same as before VFs were enabled, as soon as possible. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://patch.msgid.link/20260402191726.4932-11-michal.wajdeczko@intel.com
2026-04-12drm/xe/pf: Allow to change sched_if_idle policy under lockMichal Wajdeczko
In upcoming patch we will need to update sched_if_idle policy when we already hold the provisioning mutex. Split existing function into two variants to allow that. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://patch.msgid.link/20260402191726.4932-10-michal.wajdeczko@intel.com
generated by cgit v1.2.3 (git 2.25.1) at 2026-09-13 08:13:08 +0000