summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
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
2026-04-12drm/xe/pf: Check EQ/PT/PRIO when testing VF configMichal Wajdeczko
In addition to the hard resources (like GGTT, CTXs, DBs) we should also check if VF was already configured (by sysfs or debugfs) with optional parameters like execution quantum (EQ), preemption timeout (PT) or scheduling priority (PRIO) as otherwise we might miss to send to the GuC updated latest values after a resume or GT reset. 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-9-michal.wajdeczko@intel.com
2026-04-12drm/xe/pf: Encode scheduling priority KLV if neededMichal Wajdeczko
After a reset we missed to reprovision VFs scheduling priority config. But as of today, the GuC firmware allows to change scheduling priority using config SCHED_PRIORITY KLV only for the PF and configuration of all VFs relies on the previously applied value of the SCHED_IF_IDLE policy. Use this policy value to check and decide whether we need to encode VF priority KLV while reprovisioning this VF. 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-8-michal.wajdeczko@intel.com
2026-04-12drm/xe/pf: Don't reprovision policies if already defaultMichal Wajdeczko
There is no need to send policy updates to the GuC if policies were not changed from the default settings (usually zero value). 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-7-michal.wajdeczko@intel.com
2026-04-12drm/xe/pf: Reprovision policy settings after GT resetMichal Wajdeczko
In addition to the reprovisioning of individual VFs configurations, we should also reprovision GuC global policy settings. Note that we already had a draft function for that but we missed to call it once we started handling GT reset. Reuse it now but don't take extra RPM as this is now a caller responsibility and drop unused parameter. 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-6-michal.wajdeczko@intel.com
2026-04-12drm/xe/pf: Print applied policy KLVsMichal Wajdeczko
Under CONFIG_DRM_XE_DEBUG_SRIOV print all policy KLVs sent to the GuC for better diagnostics. This is similar what we are already doing with VF configuration KLVs. 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-5-michal.wajdeczko@intel.com
2026-04-12drm/xe/pf: Force new VFs prorities only onceMichal Wajdeczko
We should force change of VFs scheduling priorities only after initial change of the SCHED_IF_IDLE policy. Doing that also during any later policy reprovisioning will overwrite changes done on the individual per-VF scheduling priorities (currently only for PF). While around also move priority change code to the _config component to maintain a proper isolation. Also document our expectation about the GuC version where the new meaning of the policy KLV is present. 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-4-michal.wajdeczko@intel.com
2026-04-12drm/xe/pf: Fix pf_get_sched_priority() function signatureMichal Wajdeczko
The pf_get_sched_priority() function returns scheduling priority that we defined as u32 so while it works we shouldn't return int. 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-3-michal.wajdeczko@intel.com
2026-04-12drm/xe/guc: Update POLICY_SCHED_IF_IDLE documentationMichal Wajdeczko
Starting from the GuC firmware version 70.12.0 the meaning of the POLICY_SCHED_IF_IDLE has changed, which now acts as a bulk update of the VF_CFG_SCHED_PRIORITY configurations of all 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-2-michal.wajdeczko@intel.com
2026-04-11drm/xe/guc: Add support for NO_RESPONSE_BUSY in CTBMichal Wajdeczko
We only have support for G2H NO_RESPONSE_BUSY messages over MMIO, but it turned out that GuC also uses that type of messages in CTB. The following error was recently observed on BMG after adding VGT policy updates to the GT restart sequence: [] xe 0000:03:00.0: [drm] *ERROR* Tile0: GT1: G2H channel broken on read, type=3, reset required [] xe 0000:03:00.0: [drm] *ERROR* Tile0: GT1: CT dequeue failed: -95 ... [] xe 0000:03:00.0: [drm] *ERROR* Tile0: GT1: Timed out wait for G2H, fence 21965, action 5502, done no [] xe 0000:03:00.0: [drm] PF: Tile0: GT1: Failed to push 1 policy KLV (-ETIME) [] xe 0000:03:00.0: [drm] Tile0: GT1: { key 0x8004 : no value } # engine_group_config where type=3 was this unrecognized NO_RESPONSE_BUSY message. Note that GuC might send the real RESPONSE message right after the BUSY message, so we must be prepared to update our g2h_fence data twice before sender actually wakes up and clears the flags. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patch.msgid.link/20260410110457.573-1-michal.wajdeczko@intel.com
2026-04-11Merge tag 'drm-intel-fixes-2026-04-09' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/i915/kernel into drm-fixes - Drop check for changed VM in EXECBUF - Fix refcount underflow race in intel_engine_park_heartbeat - Do not use pipe_src as borders for SU area in PSR Signed-off-by: Dave Airlie <airlied@redhat.com> From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patch.msgid.link/add6fPHRC7Bc8Uri@jlahtine-mobl
2026-04-10drm/connector: Make drm_connector_attach_hdr_output_metadata_property() ↵Maíra Canal
return void drm_connector_attach_hdr_output_metadata_property() always returns zero, since drm_object_attach_property() returns void. No caller checks the return value, so change the return type to void. Also fix a typo in the kerneldoc ("HDR_OUTPUT_METADA" -> "HDR_OUTPUT_METADATA"). Reviewed-by: Melissa Wen <mwen@igalia.com> Link: https://patch.msgid.link/20260330133446.3265938-2-mcanal@igalia.com Signed-off-by: Maíra Canal <mcanal@igalia.com>
2026-04-10drm/i915/fb: Use intel_fb_needs_pot_stride_remap() in intel_fb_view_init()Ville Syrjälä
Replace the open coded intel_fb_needs_pot_stride_remap() check inside intel_fb_view_init() with the real thing. The current check doesn't have the intel_fb_uses_dpt() in there, but that is the only situation when we use the remapped view, and thus was always implied. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260407155053.32156-13-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2026-04-10drm/i915/fb: Use i915_gtt_view_is_*()Ville Syrjälä
Replace the naked GTT view type checks with the new i915_gtt_view_is_*() helpers. This isolates some of the code from GTT view implementation details. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260407155053.32156-10-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2026-04-10drm/i915/vma: Add helpers to check GTT view typeVille Syrjälä
I915_GTT_VIEW_ROTATED is going away and being replaced by just I915_GTT_VIEW_REMAPPED, so we're going to need another way to determine if the view is rotated or not (since width/height will need to be swapped when operating on the destination coordinate space). Provide small helper functions to hide such implementation details from most of the code using GTT views. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260407155053.32156-8-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
generated by cgit v1.2.3 (git 2.39.1) at 2026-09-21 07:49:05 +0000