| Age | Commit message (Collapse) | Author |
|---|
|
Add fixed refresh rate mode in crtc_state dump.
VRR Timing Generator is running in fixed refresh rate mode when
vrr.vmin = vrr.vmax = vrr.flipline.
v2: s/fixed_rr/fixed rr for consistency with the other stuff. (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/20250322044345.3827137-2-ankit.k.nautiyal@intel.com
|
|
Some DSI panel vendors end up hardcoding PPS params because of which
it does not listen to the params sent from the source. We use the
default config tables for DSI panels when using DSC 1.1 rather than
calculate our own rc parameters.
--v2
-Use intel_crtc_has_type [Jani]
--v4
-Use a function to check Mipi dsi dsc 1.1 condition [Ankit]
-Add documentation for using this condition [Ankit]
-Rebase
--v5
-Pass only the crtc_state [Jani]
-Fixup the comment [Jani]
-Check for dsc major version [Jani]
-Use co-developed-by tag [Jani]
--v6
-Add more definition of the issue and solution in the comment [Ankit]
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13719
Co-developed-by: William Tseng <william.tseng@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250228152531.403026-1-suraj.kandpal@intel.com
|
|
Now that all display code has been converted to display specific runtime
PM interfaces, there's no need for the compat header anymore.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://lore.kernel.org/r/037ed1f38c96715c76514e9eb7069b896ce06ba1.1742483007.git.jani.nikula@intel.com
|
|
Finish the conversions to display specific runtime PM interfaces in the
power code.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://lore.kernel.org/r/b08a074d466a966b7f0fda9ef35c8ef81d180ebb.1742483007.git.jani.nikula@intel.com
|
|
Convert i915 runtime PM interfaces to display runtime PM interfaces all
over the place in display code.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://lore.kernel.org/r/494d0bd0348e4aa99560f1aed21aaaff31706c44.1742483007.git.jani.nikula@intel.com
|
|
Convert intel_atomic_commit() and intel_atomic_commit_tail() to use
display runtime PM interfaces. Also convert the wakeref member type to
struct ref_tracker *, which is the same as intel_wakeref_t, but without
the typedef.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://lore.kernel.org/r/2682fa92089ab87429eef4d45f931839f0d32077.1742483007.git.jani.nikula@intel.com
|
|
Convert all with_intel_runtime_pm() uses to with_intel_display_rpm().
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://lore.kernel.org/r/888566433ca5f31b3fa3c0a192fd495d86c2f201.1742483007.git.jani.nikula@intel.com
|
|
Add display specific wrappers around the i915 and xe dedicated runtime
PM interfaces. There are no conversions here, just the wrappers.
Implement with_intel_display_rpm() without needing to provide a local
variable, which neatly narrows the scope and hides the type of the
wakeref cookie.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://lore.kernel.org/r/086b312367fa0fbd8de92e9764117aa7ff4a8cc5.1742483007.git.jani.nikula@intel.com
|
|
Most of the other display feature check macros are just
HAS_<something>. Follow suit with hotplug check.
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/c386ef007ae8bdda1bb9b1b353b1cd2957897842.1742481923.git.jani.nikula@intel.com
|
|
Going forward, struct intel_display is the main display device data
pointer. Convert as much as possible of intel_display_irq.[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/b6e281875278ad84772938f81129fde6065b2745.1742481923.git.jani.nikula@intel.com
|
|
Going forward, struct intel_display is the main display device data
pointer. Convert the external interfaces of intel_display_irq.[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/83b552154761d2790d8c774707e8d7612037bdf5.1742481923.git.jani.nikula@intel.com
|
|
Going forward, struct intel_display is the main display device data
pointer. Convert as much as possible of intel_hotplug_irq.[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/8ddf27ea31b543f88c5f124f029c2eaa06a9aae7.1742481923.git.jani.nikula@intel.com
|
|
All the registers handled here are display registers. Switch from
intel_uncore_*() to intel_de_*() functions.
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/cd1149b3ebcb7a9f73830b99957f09e468cd5fd9.1742481923.git.jani.nikula@intel.com
|
|
Pass struct intel_display as the cookie to debugfs functions.
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/b1cbf64d366ca97005f9b139e85d8a32b460623a.1742481923.git.jani.nikula@intel.com
|
|
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
|
|
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
|
|
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
|
|
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>
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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>
|
|
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>
|
|
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>
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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>
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
