Currently, vrr.enable is intended only for variable refresh rate timings.
At this point, we do not set fixed refresh rate timings, but the GOP can,
which creates a problem during the readback of vrr.enable.
The GOP enables the VRR timing generator with fixed timings, while the
driver only recognizes the VRR timing generator as enabled with
variable timings. This discrepancy causes an issue due to the
fixed refresh rate check during readback. Since the VRR timing generator
is enabled and we do not support fixed timings, the readback should set
vrr.enable so that the driver can disable the VRR timing generator.
However, the current check does not allow this.
Therefore, remove the fixed refresh rate check during readback.
Fixes: 27217f9d18 ("drm/i915/vrr: Track vrr.enable only for variable timing")
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
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-3-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
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: 9fa154f40e ("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 ec3e00b4ee ("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
69d6bf5c37 ("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 f67986b011 ("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
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
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>
