summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915
AgeCommit message (Collapse)Author
2025-03-21drm/i915/hotplug: convert intel_hotplug.[ch] to struct intel_displayJani Nikula
Going forward, struct intel_display is the main display device data pointer. Convert as much as possible of intel_hotplug.[ch] to struct intel_display. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/cf382dbfacf1445b26fbe1e7c011e7a3ea6e1594.1742481923.git.jani.nikula@intel.com
2025-03-21drm/i915/connector: convert intel_connector.c to struct intel_displayJani Nikula
Going forward, struct intel_display is the main display device data pointer. Convert as much as possible of intel_connector.c to struct intel_display. i915_inject_probe_failure() remains the only call that requires i915 pointer. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/398e3210459a65f74e78f2d34584cda6eea6a99b.1742481923.git.jani.nikula@intel.com
2025-03-21drm/i915/color: prefer display->platform.<platform> checksJani Nikula
This let's us drop the dependency on i915_drv.h. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/d57fd6444c512b3cc35c0e216c86eeb95124eead.1742481923.git.jani.nikula@intel.com
2025-03-20drm/i915/display: Fix build error without DRM_FBDEV_EMULATIONYue Haibing
In file included from <command-line>: ./drivers/gpu/drm/i915/display/intel_fbdev.h: In function ‘intel_fbdev_framebuffer’: ./drivers/gpu/drm/i915/display/intel_fbdev.h:32:16: error: ‘NULL’ undeclared (first use in this function) 32 | return NULL; | ^~~~ ./drivers/gpu/drm/i915/display/intel_fbdev.h:1:1: note: ‘NULL’ is defined in header ‘<stddef.h>’; did you forget to ‘#include <stddef.h>’? +++ |+#include <stddef.h> 1 | /* SPDX-License-Identifier: MIT */ ./drivers/gpu/drm/i915/display/intel_fbdev.h:32:16: note: each undeclared identifier is reported only once for each function it appears in 32 | return NULL; | ^~~~ Build fails if CONFIG_DRM_FBDEV_EMULATION is n, add missing header file. Fixes: 9fa154f40eb6 ("drm/{i915,xe}: Run DRM default client setup") Signed-off-by: Yue Haibing <yuehaibing@huawei.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20250315120143.2344958-1-yuehaibing@huawei.com Signed-off-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 97e81f78d3cbf061a809bbb8180a5b96395b8e03) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-03-20drm/i915/watermark: Check bounds for scaler_users for dsc prefill latencyAnkit Nautiyal
Currently, during the computation of global watermarks, the latency for each scaler user is calculated to compute the DSC prefill latency. At this point, the number of scaler users can exceed the number of supported scalers, which is checked later in intel_atomic_setup_scalers(). This can cause issues when the number of scaler users exceeds the number of supported scalers. While checking for DSC prefill, ensure that the number of scaler users does not exceed the number of supported scalers. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/4341 Fixes: a9b14af999b0 ("drm/i915/dsc: Check if vblank is sufficient for dsc prefill") Cc: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250227034106.1638203-1-ankit.k.nautiyal@intel.com (cherry picked from commit 5d6c69b712f9cb34063ef32168ce6a12af8acf0c) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-03-20drm/i915/display: Fix build error without DRM_FBDEV_EMULATIONYue Haibing
In file included from <command-line>: ./drivers/gpu/drm/i915/display/intel_fbdev.h: In function ‘intel_fbdev_framebuffer’: ./drivers/gpu/drm/i915/display/intel_fbdev.h:32:16: error: ‘NULL’ undeclared (first use in this function) 32 | return NULL; | ^~~~ ./drivers/gpu/drm/i915/display/intel_fbdev.h:1:1: note: ‘NULL’ is defined in header ‘<stddef.h>’; did you forget to ‘#include <stddef.h>’? +++ |+#include <stddef.h> 1 | /* SPDX-License-Identifier: MIT */ ./drivers/gpu/drm/i915/display/intel_fbdev.h:32:16: note: each undeclared identifier is reported only once for each function it appears in 32 | return NULL; | ^~~~ Build fails if CONFIG_DRM_FBDEV_EMULATION is n, add missing header file. Fixes: 9fa154f40eb6 ("drm/{i915,xe}: Run DRM default client setup") Signed-off-by: Yue Haibing <yuehaibing@huawei.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20250315120143.2344958-1-yuehaibing@huawei.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-03-19drm/i915: Fix harmful driver register/unregister asymmetryJanusz Krzysztofik
Starting with commit ec3e00b4ee27 ("drm/i915: stop registering if drm_dev_register() fails"), we return from i915_driver_register() immediately if drm_dev_register() fails, skipping remaining registration steps, and continue only with remaining probe steps. However, the _unregister() counterpart called at driver remove knows nothing about that skip and executes reverts of all those steps. As a consequence, a number of kernel warnings that taint the kernel are triggered: <3> [525.823143] i915 0000:00:02.0: [drm] *ERROR* Failed to register driver for userspace access! ... <4> [525.831069] ------------[ cut here ]------------ <4> [525.831071] i915 0000:00:02.0: [drm] drm_WARN_ON(power_domains->init_wakeref) <4> [525.831095] WARNING: CPU: 6 PID: 3440 at drivers/gpu/drm/i915/display/intel_display_power.c:2074 intel_power_domains_disable+0xc2/0xd0 [i915] ... <4> [525.831328] CPU: 6 UID: 0 PID: 3440 Comm: i915_module_loa Tainted: G U 6.14.0-rc1-CI_DRM_16076-g7a632b6798b6+ #1 ... <4> [525.831334] RIP: 0010:intel_power_domains_disable+0xc2/0xd0 [i915] ... <4> [525.831483] Call Trace: <4> [525.831484] <TASK> ... <4> [525.831943] i915_driver_remove+0x4b/0x140 [i915] <4> [525.832028] i915_pci_remove+0x1e/0x40 [i915] <4> [525.832099] pci_device_remove+0x3e/0xb0 <4> [525.832103] device_remove+0x40/0x80 <4> [525.832107] device_release_driver_internal+0x215/0x280 ... Moreover, that unexpected PM reference is left untouched (not released) but overwritten, then that triggers another kernel warning at driver release phase: <4> [526.685700] ------------[ cut here ]------------ <4> [526.685706] i915 0000:00:02.0: [drm] i915 raw-wakerefs=1 wakelocks=1 on cleanup <4> [526.685734] WARNING: CPU: 1 PID: 3440 at drivers/gpu/drm/i915/intel_runtime_pm.c:443 intel_runtime_pm_driver_release+0x75/0x90 [i915] ... <4> [526.686090] RIP: 0010:intel_runtime_pm_driver_release+0x75/0x90 [i915] ... <4> [526.686294] Call Trace: <4> [526.686296] <TASK> ... <4> [526.687025] i915_driver_release+0x7e/0xb0 [i915] <4> [526.687243] drm_dev_put.part.0+0x47/0x90 <4> [526.687250] devm_drm_dev_init_release+0x13/0x30 <4> [526.687255] devm_action_release+0x12/0x30 <4> [526.687261] release_nodes+0x3a/0x120 <4> [526.687268] devres_release_all+0x97/0xe0 <4> [526.687277] device_unbind_cleanup+0x12/0x80 <4> [526.687282] device_release_driver_internal+0x23a/0x280 ... A call to intel_power_domains_disable() was already there. It triggers the drm_WARN_ON() when it finds a reference to a wakeref taken on device probe and not released after device registration failure. That wakeref is then left held forever once its handle gets lost overwritten with another wakeref, hence another WARN() is called from intel_runtime_pm_driver_release(). The WARN() triggered by kernfs_remove_by_name_ns() from i915_teardown_sysfs()->i915_gpu_error_sysfs_teardown(), formerly i915_teardown_error_capture(), was also there when the return was added. A call to intel_gt_sysfs_unregister() that triggers the WARN() from kobject_put() was added to intel_gt_driver_unregister() with commit 69d6bf5c3754ff ("drm/i915/gt: Fix memory leaks in per-gt sysfs"). Fix the asymmetry by failing the driver probe on device registration failure and going through rewind paths. For that to work as expected, we apparently need to start the rewind path of i915_driver_register() with drm_dev_unregister(), even if drm_dev_register() returned an error. v5: Drop unsigned keyword from ret variable declaration (Krzysztof), - keep the "Failed to register driver for userspace access" error message (Krzysztof), - split PXP cleanup addition to rewind path out to a separate patch. v4: Switch to taking an error rewind path on device registration failure (Krzysztof, Lucas). v3: Based on Andi's commitment on introducing a flag, try to address Jani's "must find another way" by finding a better place and name for the flag (in hope that's what Jani had on mind), - split into a series of patches and limit the scope of the first (this) one to a minimum of omitting conditionally only those unregister (sub)steps that trigger kernel warnings when not registered. v2: Check in _unregister whether the drm_dev_register has succeeded and skip some of the _unregister() steps. (Andi) Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10047 Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10131 Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10887 Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12817 Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Chris Wilson <chris.p.wilson@linux.intel.com> Cc: Ashutosh Dixit <ashutosh.dixit@intel.com> Cc: Andi Shyti <andi.shyti@linux.intel.com> Cc: Krzysztof Niemiec <krzysztof.niemiec@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Reviewed-by: Krzysztof Niemiec <krzysztof.niemiec@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250314205202.809563-8-janusz.krzysztofik@linux.intel.com
2025-03-19drm/i915: Fix PXP cleanup missing from probe error rewindJanusz Krzysztofik
Commit f67986b0119c04 ("drm/i915/pxp: Promote pxp subsystem to top-level of i915") added PXP initialization to driver probe path, but didn't add a respective PXP cleanup on probe error. That lack of cleanup seems harmless as long as PXP is still unused and idle when a probe failure occurs and error rewind path is entered, but as soon as PXP starts consuming device and driver resources keeping them busy, kernel warnings may be triggered when cleaning up resources provided by memory regions, GGTT, GEM and/or VMA cache from the probe error rewind and/or module unload paths because of missing PXP cleanup. That scenario was observed on attempts to fail the probe and enter the rewind path on injection of now ignored error in device registration path. Fix it. Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Reviewed-by: Krzysztof Niemiec <krzysztof.niemiec@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250314205202.809563-7-janusz.krzysztofik@linux.intel.com
2025-03-19drm/i915: Downgrade device register error if injectedJanusz Krzysztofik
Commit 8f460e2c78f2 ("drm/i915: Demidlayer driver loading") which introduced manual device registration also added a message that is submitted on device registration failure as an error. If that failure is triggered by error injection test, that's an expected error, but CI still reports it as a bug. Fix it. Suggested-by: Krzysztof Niemiec <krzysztof.niemiec@intel.com> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/9820 Cc: Chris Wilson <chris.p.wilson@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Reviewed-by: Krzysztof Niemiec <krzysztof.niemiec@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250314205202.809563-6-janusz.krzysztofik@linux.intel.com
2025-03-19drm/i915/gt: Use proper sleeping functions for timeouts shorter than 20msAndi Shyti
msleep is very imprecise for timeouts shorter than 20 milliseconds and most probably will sleep longer. Use uslee_range() instead. Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com> Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250314021225.11813-5-andi.shyti@linux.intel.com
2025-03-19drm/i915/gt: Remove trailing blank linesAndi Shyti
Remove useless blank lines before and after the brackets. Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com> Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250314021225.11813-4-andi.shyti@linux.intel.com
2025-03-19drm/i915/gt: Fix SPDX license formatAndi Shyti
Header files need to declare the SPDX under /* ... */ style comments at the beginning of the file. Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com> Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250314021225.11813-3-andi.shyti@linux.intel.com
2025-03-14i915/gt/selftests: Disable lrc_timestamp testMikolaj Wasiak
This test was designed to isolate a bug in tigerlake and dg2 hardware. The bug was found and fixed in newer generations. Since we won't support any new hardware with this driver, the test should now be turned off in the CI to not pollute it with random failures on previous hardware. For reference, the issue has been discssued here[*]. [*] https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13697 Signed-off-by: Mikolaj Wasiak <mikolaj.wasiak@intel.com> Reviewed-by: Chris Wilson <chris.p.wilson@linux.intel.com> Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com> Reviewed-by: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/uxxb22n667zb3aic6zs4mr2krv5zavav5v2zjgqnhnabgxgzif@4icszicjakex
2025-03-14i915/selftest/igt_mmap: let mmap tests run in kthreadMikolaj Wasiak
When the driver is loaded on the system with numa nodes it might be run in a kthread, which makes it impossible to use current->mm in the selftest. This patch allows the selftest to use current->mm by using active_mm. Signed-off-by: Mikolaj Wasiak <mikolaj.wasiak@intel.com> Reviewed-by: Eugene Kobyak <eugene.kobyak@intel.com> Reviewed-by: Krzysztof Niemiec <krzysztof.niemiec@intel.com> Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/2w6pt2hnemndwmanwhyn3keexa6vtha7rmo6rqoerkmyxhbrh2@ls7lndjpia6z
2025-03-14drm/i915/display: Maintain asciibetical order for HAS_* macrosAnkit Nautiyal
Move HAS_* macros to maintain asciibetical order. Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250312054424.1628358-1-ankit.k.nautiyal@intel.com
2025-03-13drm/i915/xe3lpd: Update bandwidth parametersGustavo Sousa
Bandwidth parameters for Xe3_LPD have been updated with respect to previous display releases. Encode them into xe3lpd_sa_info and use that new struct. Bspec: 68859 Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250311-xe3lpd-bandwidth-update-v5-3-a95a9d90ad71@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2025-03-13drm/i915/display: Convert intel_bw.c externally to intel_displayGustavo Sousa
We already have internal interface for intel_bw.c converted to use intel_display. Now convert the external interface as well. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250311-xe3lpd-bandwidth-update-v5-2-a95a9d90ad71@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2025-03-13drm/i915/display: Convert intel_bw.c internally to intel_displayGustavo Sousa
Update intel_bw.c internally use intel_display. Conversion of the public interface will come as a follow-up. v2: - Prefer intel_uncore_read() for MCHBAR registers. (Ville) v3: - Remove the unnecessary inclusion of intel_de.h after changes from v2. (Ville) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250311-xe3lpd-bandwidth-update-v5-1-a95a9d90ad71@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2025-03-13drm/i915/display: Enable MSA Ignore Timing PAR only when in not fixed_rr modeAnkit Nautiyal
MSA Ignore Timing PAR enable is set in the DP sink when we enable variable refresh rate. Currently for link training we depend on flipline to decide whether we want to ignore the msa timings. With fixed refresh rate we will still fill the flipline in all cases whether panel supports VRR or not. Change the condition for link training to ignore the msa timings if vrr.in_range. v2: Add more documentation and a #TODO for readout of vrr.in_range. (Ville) Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250311093751.1329043-9-ankit.k.nautiyal@intel.com
2025-03-13drm/i915/vrr: Prepare for fixed refresh rate timingsAnkit Nautiyal
Currently we always compute the timings as if vrr is enabled. With this approach the state checker becomes complicated when we introduce fixed refresh rate mode with vrr timing generator. To avoid the complications, instead of always computing vrr timings, we compute vrr timings based on uapi.vrr_enable knob. So when the knob is disabled we always compute vmin=flipline=vmax. v2: Use actual timings without any adjustments while preparing for fixed timings in compute_config. (Ville) v3: Avoid setting fixed timings if !vrr_possible(). v4: Move vmin adjustement after all other timings are complete. (Ville) Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (#v2) Link: https://patchwork.freedesktop.org/patch/msgid/20250311093751.1329043-8-ankit.k.nautiyal@intel.com
2025-03-13drm/i915/vrr: Use crtc_vtotal for vminAnkit Nautiyal
To have fixed refresh rate with VRR timing generator the guardband/pipeline full can't be programmed on the fly. So we need to ensure that the values satisfy both the fixed and variable refresh rates. Since we compute these value based on vmin, lets set the vmin to crtc_vtotal for both fixed and variable timings instead of using the current refresh rate based approach. This way the guardband remains sufficient for both cases. v2: Avoid using vblank delay while computing vtotal, as this comes into the picture later. (Ville) Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250311093751.1329043-7-ankit.k.nautiyal@intel.com
2025-03-13drm/i915/vrr: Track vrr.enable only for variable timingAnkit Nautiyal
Since CMRR is now disabled, use the flag vrr.enable to tracks if vrr timing generator is used with variable timings. Avoid setting vrr.enable for CMRR and adjust readout to not set vrr.enable when vmax == vmin == flipline (fixed refresh rate timing). v2: Use intel_vrr_vmin_flipline() to account for adjustments required for icl/tgl. (Ville) v3: Add a #TODO for handling I915_MODE_FLAG_VRR better for CMRR. (Ville) Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250311093751.1329043-6-ankit.k.nautiyal@intel.com
2025-03-13drm/i915/vrr: Disable CMRRAnkit Nautiyal
Switching between variable and fixed timings is possible as for that we just need to flip between VRR timings. However for CMRR along with the timings, few other bits also need to be changed on the fly, which might cause issues. So disable CMRR for now, till we have variable and fixed timings sorted out. Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250311093751.1329043-5-ankit.k.nautiyal@intel.com
2025-03-13drm/i915/vrr: Make helpers for cmrr and vrr timingsAnkit Nautiyal
Separate out functions for computing cmrr and vrr timings. Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250311093751.1329043-4-ankit.k.nautiyal@intel.com
2025-03-13drm/i915:vrr: Separate out functions to compute vmin and vmaxAnkit Nautiyal
Make helpers to compute vmin and vmax. v2: Make the adjusted mode const (Ville) Use reverse xmas tree order of declarations. (Ville) Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250311093751.1329043-3-ankit.k.nautiyal@intel.com
2025-03-13drm/i915/vrr: Remove unwanted commentAnkit Nautiyal
The comment about fixed average vtotal is incorrect. Remove it. Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250311093751.1329043-2-ankit.k.nautiyal@intel.com
2025-03-13drm/i915/watermark: Check bounds for scaler_users for dsc prefill latencyAnkit Nautiyal
Currently, during the computation of global watermarks, the latency for each scaler user is calculated to compute the DSC prefill latency. At this point, the number of scaler users can exceed the number of supported scalers, which is checked later in intel_atomic_setup_scalers(). This can cause issues when the number of scaler users exceeds the number of supported scalers. While checking for DSC prefill, ensure that the number of scaler users does not exceed the number of supported scalers. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/4341 Fixes: a9b14af999b0 ("drm/i915/dsc: Check if vblank is sufficient for dsc prefill") Cc: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250227034106.1638203-1-ankit.k.nautiyal@intel.com
2025-03-13Merge tag 'drm-intel-gt-next-2025-02-26' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/i915/kernel into drm-next UAPI Changes: - Add sysfs for SLPC power profiles [slpc] (Vinay Belgaumkar) Driver Changes: Fixes/improvements/new stuff: - Fix zero delta busyness issue [pmu] (Umesh Nerlige Ramappa) - Fix page cleanup on DMA remap failure (Brian Geffon) - Debug print LRC state entries only if the context is pinned [guc] (Daniele Ceraolo Spurio) - Drop custom hotplug code [pmu] (Lucas De Marchi) - Use spin_lock_irqsave() in interruptible context [guc] (Krzysztof Karas) - Add wait on depth stall done bit handling [gen12] (Juha-Pekka Heikkila) Miscellaneous: - Change throttle criteria for rps [selftest] (Raag Jadav) - Add debug print about hw config table size (John Harrison) - Include requested frequency in slow firmware load messages [uc] (John Harrison) - Remove i915_pmu_event_event_idx() [pmu] (Lucas De Marchi) - Remove unused live_context_for_engine (Dr. David Alan Gilbert) - Add Wa_22010465259 in its respective WA list (Ranu Maurya) - Correct frequency handling in RPS power measurement [selftests] (Sk Anirban) - Add helper function slpc_measure_power [guc/slpc] (Sk Anirban) - Revert "drm/i915/gt: Log reason for setting TAINT_WARN at reset" [gt] (Sebastian Brzezinka) - Avoid using uninitialized context [selftests] (Krzysztof Karas) - Use struct_size() helper in kmalloc() (luoqing) - Use prandom in selftest [selftests] (Markus Theil) - Replace kmap with its safer kmap_local_page counterpart [gt] (Andi Shyti) Merges: - Merge drm/drm-next into drm-intel-gt-next (Tvrtko Ursulin) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Tvrtko Ursulin <tursulin@igalia.com> Link: https://patchwork.freedesktop.org/patch/msgid/Z77NLt2mR7SqxJ4u@linux
2025-03-11drm/i915: Increase I915_PARAM_MMAP_GTT_VERSION version to indicate support ↵José Roberto de Souza
for partial mmaps Commit 255fc1703e42 ("drm/i915/gem: Calculate object page offset for partial memory mapping") was the last patch of several patches fixing multiple partial mmaps. But without a bump in I915_PARAM_MMAP_GTT_VERSION there is no clean way for UMD to know if it can do multiple partial mmaps. Fixes: 255fc1703e42 ("drm/i915/gem: Calculate object page offset for partial memory mapping") Cc: Andi Shyti <andi.shyti@linux.intel.com> Cc: Nirmoy Das <nirmoy.das@intel.com> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250306210827.171147-1-jose.souza@intel.com (cherry picked from commit bfef148f3680e6b9d28e7fca46d9520f80c5e50e) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-03-11drm/i915: Increase I915_PARAM_MMAP_GTT_VERSION version to indicate support ↵José Roberto de Souza
for partial mmaps Commit 255fc1703e42 ("drm/i915/gem: Calculate object page offset for partial memory mapping") was the last patch of several patches fixing multiple partial mmaps. But without a bump in I915_PARAM_MMAP_GTT_VERSION there is no clean way for UMD to know if it can do multiple partial mmaps. Fixes: 255fc1703e42 ("drm/i915/gem: Calculate object page offset for partial memory mapping") Cc: Andi Shyti <andi.shyti@linux.intel.com> Cc: Nirmoy Das <nirmoy.das@intel.com> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250306210827.171147-1-jose.souza@intel.com
2025-03-11drm/i915/crt: Use intel_hpd_block/unblock() instead of ↵Imre Deak
intel_hpd_disable/enable() intel_hpd_disable/enable() have the same purpose as intel_hpd_block/unblock(), except that disable/enable will drop any HPD IRQs which were triggered while the HPD was disabled, while block/unblock will handle such IRQs after the IRQ handling is unblocked. Use intel_hpd_block/unblock() for crt as well, by adding a helper to explicitly clear any pending IRQs before unblocking. v2: - Handle encoders without a port assigned to them. - Rebase on change in intel_hpd_suspend() documentation. v3: - Rebase on the suspend/resume -> block/unblock rename change. - Clear the pending events only after all encoders have unblocked the HPD handling. - Clear the short/long port events for all encoders using the given HPD pin. v4: - Rebase on port->hpd_pin tracking. (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250304152917.3407080-7-imre.deak@intel.com
2025-03-11drm/i915/dp: Queue a link check after link training is completeImre Deak
After link training - both in case of a passing and failing LT result - a work is scheduled to check the link state. This check should take place after the link training is completed by disabling the link training pattern and setting intel_dp::link_trained=true. Atm, the work is scheduled before these steps, which may result in checking the link state too early (and thus not retraining the link as expected). Fix the above by scheduling the link check work after link training is complete. v2: - Add MAX_SEQ_TRAIN_FAILURES instead of open-coding it. (Jani) Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250305114820.3523077-2-imre.deak@intel.com
2025-03-11drm/i915/dp: Fix link training interrupted by a short HPD pulseImre Deak
During Display Port link training the handling of HPD pulses should be prevented, as that handling can interfere with the link training: - Accessing DPCD registers outside the range of link training registers are not allowed by the Standard (see DP Standard v2.1, 3.5.2.16.1, 3.6.6.1). The pulse handler reads the DPRX capability registers, which are outside of the allowed range. - Switching of the LTTPR transparent/non-transparent mode may reset the LTTPRs on the link, thus aborting any ongoing link training. The pulse handler does set the LTTPR mode, thus it could unexpectedly abort the ongoing link training. Block/unblock the HPD pulse handling for the duration of the link training to prevent the above DPCD register accesses / LTTPR mode change. Apart from the above scenarios, there are other ways a non-link training DPCD register could be accessed during link training: via the DRM AUX device node, or via DPCD register probing (as performed by drm_dp_dpcd_probe()). These will be addressed by a follow-up change. v2: Rebase on the intel_hpd_suspend/resume -> intel_hpd_block/unblock() rename change. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250304152917.3407080-5-imre.deak@intel.com
2025-03-11drm/i915/hpd: Add support for blocking the IRQ handling on an HPD pinImre Deak
Add support for blocking the IRQ handling on the HPD pin of a given encoder, handling IRQs that arrived while in the blocked state after unblocking the IRQ handling. This will be used by a follow-up change, which blocks/unblocks the IRQ handling around DP link training. This is similar to the intel_hpd_disable/enable() functionality, by also handling encoders/ports with a pulse handler (i.e. also blocking/unblocking the short/long pulse handling) and handling the IRQs arrived in the blocked state after the handling is unblocked (vs. just dropping such IRQs). v2: - Handle encoders without a port assigned to them. - Fix clearing IRQs from intel_hotplug::short_port_mask. v3: - Rename intel_hpd_suspend/resume() to intel_hpd_block/unblock(). (Jani) - Refer to HPD pins as hpd_pin vs. hpd. - Flush dig_port_work in intel_hpd_block() if any encoder using the HPD pin has a pulse handler. v4: - Fix hpd_pin_has_pulse(), checking the encoder's HPD pin. v5: - Rebase on port->hpd_pin tracking. (Ville) v6: (Jani) - Add hpd_pin_is_blocked() helper. - Use the hpd_pin_mask term for a mask of pins instead of hpd_pins. - Prevent decrementing a 0 refcount in unblock_hpd_pin(). Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250305114820.3523077-1-imre.deak@intel.com
2025-03-11drm/i915/hpd: Let an HPD pin be in the disabled state when handling missed IRQsImre Deak
After suspending and resuming the detection on connectors, HPD IRQs that arrived while the detection was suspended, are handled by scheduling the intel_hotplug::hotplug work for them. All HPD pins must be at this point in either the HPD_ENABLED (set for all pins during driver loading/system resuming) or HPD_MARK_DISABLED (set by IRQ storm detection) state: the HPD_DISABLED state for a pin can be set only from the HPD_MARK_DISABLED state by the hotplug work after a storm detection (enabling polling on the given pin/connector), however the hotplug work won't be scheduled while the detection is suspended. A follow-up change will add support for blocking the HPD IRQ handling on a given HPD pin (without disabling the IRQ generation on it), after which it becomes possible to see a pin in the HPD_DISABLED state when unblocking the IRQ handling (since the blocking could've happened for an already disabled pin). Adjust queue_work_for_missed_irqs() accordingly, so that this function can be reused for unblocking the IRQ handling. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250304152917.3407080-3-imre.deak@intel.com
2025-03-11Merge tag 'drm-intel-next-2025-03-10' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/i915/kernel into drm-next drm/i915 feature pull #2 for v6.15: Features and functionality: - FBC dirty rectangle support for display version 30+ (Vinod) - Update plane scalers via DSB based commits (Ville) - Move runtime power status info to display power debugfs (Jani) Refactoring and cleanups: - Convert i915 and xe to DRM client setup (Thomas) - Refactor and clean up CDCLK/bw/dbuf readout/sanitation (Ville) - Conversions from drm_i915_private to struct intel_display (Jani, Suraj) - Refactor display reset for better separation between display and core (Jani) - Move panel fitter code together (Jani) - Add mst and hdcp sub-structs to display structs for clarity (Jani) - Header refactoring to clarify separation between display and i915 core (Jani) Fixes: - Fix DP MST max stream count to match number of pipes (Jani) - Fix encoder HW state readout of DP MST UHBR (Imre) - Fix ICL+ combo PHY cursor and coeff polarity programming (Ville) - Fix pipeDMC and ATS fault handling (Ville) - Display workarounds (Gustavo) - Remove duplicate forward declaration (Vinod) - Improve POWER_DOMAIN_*() macro type safety (Gustavo) - Move CDCLK post plane programming later (Ville) DRM core changes: - Add client-hotplug helper (Thomas) - Send pending hotplug events after client resume (Thomas) - Add fb_restore and fb_set_suspend fb helper hooks (Thomas) - Remove struct fb_probe fb helper hook (Thomas) - Add const qualifier to drm_atomic_helper_damage_merged() (Vinod) Xe driver changes: - Convert i915 and xe to DRM client setup (Thomas) - Refactor i915 compat headers (Jani) - Fix fbdev GGTT mapping handling (Maarten) - Figure out pxp instance from the gem object (Jani) Merges: - Backmerge drm-next to fix conflicts with drm-xe-next (Jani) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/87o6y9gpub.fsf@intel.com
2025-03-10drm/i915/hpd: Track HPD pins instead of ports for HPD pulse eventsImre Deak
Track the HPD pin instead of the corresponding encoder ports for pending short/long HPD pulse events. This is how the pending hotplug events are tracked and there is no reason for tracking the pulse events differently. After this change intel_hpd_trigger_irq() will set the short pulse event pending for all encoders using the given HPD pin. This doesn't change the behavior, as atm in case of multiple (2) encoders sharing the same pin only one will have a pulse handler, so for other encoders without a pulse handler the event is ignored. Also setting the pulse event pending for all encoders using the HPD pin is what happens after an actual HPD IRQ, the effect of calling intel_hpd_trigger_irq() should match this. In a following change this also makes it simpler to block the handling of a short/long pulse event on an HPD pin for all the encoders using this HPD pin. Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250304152917.3407080-2-imre.deak@intel.com
2025-03-10Merge 6.14-rc6 into driver-core-nextGreg Kroah-Hartman
We need the driver core fix in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-10drm/i915/cdclk: Do cdclk post plane programming laterVille Syrjälä
We currently call intel_set_cdclk_post_plane_update() far too early. When pipes are active during the reprogramming the current spot only works for the cd2x divider update case, as that is synchronize to the pipe's vblank. Squashing and crawling are not synchronized in any way, so doing the programming while the pipes/planes are potentially still using the old hardware state could lead to underruns. Move the post plane reprgramming to a spot where we know that the pipes/planes have switched over the new hardware state. Cc: stable@vger.kernel.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250218211913.27867-2-ville.syrjala@linux.intel.com Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> (cherry picked from commit fb64f5568c0e0b5730733d70a012ae26b1a55815) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-03-10drm/i915/xe3lpd: Map POWER_DOMAIN_AUDIO_PLAYBACK to DC_offGustavo Sousa
In Xe3_LPD, display audio has the core audio logic located in PG0 and per-transcoder logic in the same power well that provides power for the transcoder [1]. For stuff like audio device enumeration, we need to ensure that PG0 is turned on. For playback, we additionally need the transcoder's power well to be enabled. That essentially means that, for audio playback, there isn't a special power well that needs to be enabled, because modeset sequences will ensure that the required power wells are enabled. That said, there might be cases where PG0 could be disabled due to display entering DC6 while the audio driver tries to interact with the graphics driver for stuff like audio device enumeration. We recently hit that kind of scenario, where "aplay -l" was being used to enumerate audio devices on a PTL machine with PSR enabled and no external displays attached. Since intel_audio_component_get_power() uses POWER_DOMAIN_AUDIO_PLAYBACK, make sure to map that power domain to DC_off power well, so that we disable dynamic DC states (which includes DC6) while the audio driver needs display audio power. [1] The core-audio vs per-transcoder logic split is not really new in Xe3_LPD. This is also true for previous display generations. We need to figure out the correct version where this split happened so that we can apply fixes in the current power domain mapping. Bspec: 72519 Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250227-xe3lpd-power-domain-audio-playback-v1-1-5765f21da977@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2025-03-07drm/i915: Relocate intel_bw_crtc_update()Ville Syrjälä
intel_bw_crtc_update() is only used by the readout path, so relocate the function next its only caller. Easier to read the code when related things are nearby. Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250306163420.3961-19-ville.syrjala@linux.intel.com
2025-03-07drm/i915: Move dbuf_state->active_pipes into skl_wm_get_hw_state()Ville Syrjälä
Move the dbuf_state readout parts into skl_wm_get_hw_state() so that the details are better hidden from sight. This will stop updating this on pre-skl, but that's what we want since the dbuf state is only used on skl+. Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250306163420.3961-18-ville.syrjala@linux.intel.com
2025-03-07drm/i915: Do wm readout ealier for skl+Ville Syrjälä
Move the wm readout to happen earlier. This is needed because the bw_state readout will need ddb information populated by the wm readout. For now limit this to skl+ as I've not really analyzed the implications of doing this on other platforms. Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250306163420.3961-17-ville.syrjala@linux.intel.com
2025-03-07drm/i915: Split wm sanitize from readoutVille Syrjälä
I'll need to move the wm readout to an earlier point in the sequence (since the bw state readout will need ddb information from the wm readout). But (at least for now) the wm sanitation will need to stay put as it needs to also sanitize things for any pipes/planes we disable later during the hw state takeover. Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250306163420.3961-16-ville.syrjala@linux.intel.com
2025-03-07drm/i915: Simplify cdclk_disable_noatomic()Ville Syrjälä
Instead of hand rolling the cdclk state disabling for a pipe in noatomic() let's just recompute the whole thing from scratch. Less code we have to remember to keep in sync. Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250306163420.3961-15-ville.syrjala@linux.intel.com
2025-03-07sem/i915: Simplify intel_cdclk_update_hw_state()Ville Syrjälä
intel_crtc_calculate_min_cdclk() can't return an error (since commit 5ac860cc5254 ("drm/i915: Fix DBUF bandwidth vs. cdclk handling")) so there is no point in checking for one. Also we can just call it unconditionally since it itself checks crtc_state->hw.enabled. We are currently checking crtc_state->hw.active in the readout path, but active==enabled during readout, and arguably enabled is the more correct thing to check anyway. Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250306163420.3961-14-ville.syrjala@linux.intel.com
2025-03-07drm/i915: Skip some bw_state readout on pre-iclVille Syrjälä
We only compute bw_state->data_rate and bw_state->num_active_planes on icl+. Do the same during readout so that we don't leave random junk inside the state. v2: Skip the whole intel_bw_crtc_update() (Vinod) Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250306163420.3961-13-ville.syrjala@linux.intel.com
2025-03-07drm/i915: Update bw_state->active_pipes during readoutVille Syrjälä
Update bw_state->active_pipes during readout. This was completely missing from the current readout code. Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250306163420.3961-12-ville.syrjala@linux.intel.com
2025-03-07drm/i915: Extract intel_bw_update_hw_state()Ville Syrjälä
Hoist the bw stuff into a separate function from intel_modeset_readout_hw_state() so that the details are better hidden inside intel_bw.c. We can also skip the whole thing on pre-skl since the dbuf state isn't actually used on those platforms. Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250306163420.3961-11-ville.syrjala@linux.intel.com
2025-03-07drm/i915: Extract intel_cdclk_update_hw_state()Ville Syrjälä
Hoist the cdclk stuff into a separate function from intel_modeset_readout_hw_state() so that the details are better hidden inside intel_cdclk.c. Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250306163420.3961-10-ville.syrjala@linux.intel.com
generated by cgit (git 2.34.1) at 2025-07-18 12:00:07 +0000