We include the Y/RGB .min_ddb_alloc in the wm state change dumps.
Do the same for .min_ddb_alloc_uv, on the platforms where it is
used.
Also adjust the whitespace in the other debug prints to keep
the values for each wm level lined up across all the lines.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260319114034.7093-10-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Pre-icl doesn't use a separate hardware plane for Y scanout,
and instead it's all handled magically by the hardware. We
do still need to allocate DDB space for the Y color plane
though (PLANE_NV12_BUF_CFG). Include that information in the
debugs so that we know where it ended up.
On icl+ the equivalent information is dumped as the hardware
Y plane's normal ddb allocation.
v2: Use prink field width for ddb_name alignment
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260319114034.7093-9-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
We have skl_print_plane_wm_changes() but the DDB counterpart is
just inline in the main loop. Extract it into a function. We'll
have a second use for this soon.
The "ddb" part is already parametrized in anticipation of the
second user.
v2: Use prink field width for ddb_name alignment
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260319114034.7093-8-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
We currently keep around the full watermarks for the UV plane
on pre-icl, even though the hardware doesn't need most of this
information. The only thing we need to keep is the min_ddb_alloc
for the UV plane. Move that into the main wm->wm[].min_ddb_alloc_uv
alongside the other min_ddb_alloc (used for Y/RGB).
This makes our state tracking match the hardware more closely,
and avoids having to justify everwhere why uv_wm[] is being
ignored.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260319114034.7093-6-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Extract skl_allocate_plane_ddb_nv12() as the compute counterpart to
skl_check_wm_level_nv12(). Mainly to hide some of the clutter from
skl_crtc_allocate_plane_ddb().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260319114034.7093-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Rename skl_check_nv12_wm_level() to skl_check_wm_level_nv12(). There
will be a sort of DDB counterparts to skl_check_wm_level*(), and
putting the "nv12" part to the end will allow consistent naming.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260319114034.7093-4-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Group the ddb and data_rate together in the skl_allocate_plane_ddb()
arguments. Upcoming changes will adjust the UV plane handling and
keeing the ddb allocation and the data rate used to calculate it
together will help with clarity.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260319114034.7093-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
We don't need is_planar in either the actual watermarks or the
wm_params structure used during the wm computation. Get rid
of both.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260319114034.7093-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
plane_atomic_check() will already have unlinked the
old NV12 planes by the time icl_check_nv12_planes()
gets called. Drop the redundant second unlinking.
Cc: Khaled Almahallawy <khaled.almahallawy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260316163953.12905-4-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Move unlink_nv12_plane() ahead of its first caller to
avoid the forward declaration.
Cc: Khaled Almahallawy <khaled.almahallawy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260316163953.12905-3-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
unlink_nv12_plane() will clobber parts of the plane state
potentially already set up by plane_atomic_check(), so we
must make sure not to call the two in the wrong order.
The problem happens when a plane previously selected as
a Y plane is now configured as a normal plane by user space.
plane_atomic_check() will first compute the proper plane
state based on the userspace request, and unlink_nv12_plane()
later clears some of the state.
This used to work on account of unlink_nv12_plane() skipping
the state clearing based on the plane visibility. But I removed
that check, thinking it was an impossible situation. Now when
that situation happens unlink_nv12_plane() will just WARN
and proceed to clobber the state.
Rather than reverting to the old way of doing things, I think
it's more clear if we unlink the NV12 planes before we even
compute the new plane state.
Cc: stable@vger.kernel.org
Reported-by: Khaled Almahallawy <khaled.almahallawy@intel.com>
Closes: https://lore.kernel.org/intel-gfx/20260212004852.1920270-1-khaled.almahallawy@intel.com/
Tested-by: Khaled Almahallawy <khaled.almahallawy@intel.com>
Fixes: 6a01df2f1b ("drm/i915: Remove pointless visible check in unlink_nv12_plane()")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260316163953.12905-2-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Put the barrier() before the OP so that anything we read out in
OP and check in COND will actually be read out after the timeout
has been evaluated.
Currently the only place where we use OP is __intel_wait_for_register(),
but the use there is precisely susceptible to this reordering, assuming
the ktime_*() stuff itself doesn't act as a sufficient barrier:
__intel_wait_for_register(...)
{
...
ret = __wait_for(reg_value = intel_uncore_read_notrace(...),
(reg_value & mask) == value, ...);
...
}
Cc: stable@vger.kernel.org
Fixes: 1c3c1dc66a ("drm/i915: Add compiler barrier to wait_for")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260313110740.24620-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Add new quirk (QUIRK_DISABLE_PANEL_REPLAY) for disabling Panel Replay as
quirk for problematic setups. Apply this newly added quirk on Dell XPS 14
DA14260 if specific panel model is installed.
We are observing problems with Dell XPS 14 DA14260. This device has certain
LGD panel model which seems to be problematic. We have seen other LGD panel
model with same OUI is working fine. Due to this we can't apply the quirk
only based on panel OUI. There are also cases where same device model has
differing panel model. We don't want to disable Panel Replay on such
devices. Best we can do is to apply the quirk based on both device model
and panel model.
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/7521
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patch.msgid.link/20260317062402.1888624-1-jouni.hogander@intel.com
If CONFIG_DRM_FBDEV_EMULATION is disabled but CONFIG_FRAMEBUFFER_CONSOLE
is turned on, the i915 driver now fails to link:
ERROR: modpost: "intel_fbdev_fb_prefer_stolen" [drivers/gpu/drm/i915/i915.ko] undefined!
Fix the contition to include a check for the symbol that controls compilation
of intel_fbdev_fb.c.
Fixes: 94c7d28612 ("drm/i915/fbdev: Extract intel_fbdev_fb_prefer_stolen()")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patch.msgid.link/20260304083701.724908-1-arnd@kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Fix a typo inside a comment message from ("generata" -> "generate")
in function do_gmbus_xfer() before calling intel_de_write_fw()
Signed-off-by: Samasth Norway Ananda <samasth.norway.ananda@oracle.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260316231920.135438-3-samasth.norway.ananda@oracle.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
When reading exactly 512 bytes with burst read enabled, the
extra_byte_added path breaks out of the inner do-while without
decrementing len. The outer while(len) then re-enters and gmbus_wait()
times out since all data has been delivered. Decrement len before the
break so the outer loop terminates correctly.
Fixes: d5dc0f43f2 ("drm/i915/gmbus: Enable burst read")
Signed-off-by: Samasth Norway Ananda <samasth.norway.ananda@oracle.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260316231920.135438-2-samasth.norway.ananda@oracle.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Check if BACKLIGHT_BRIGHTNESS_AUX_SET_CAPABLE bit is
set then EDP_PWMGEN_BIT_COUNT_CAP_MIN and EDP_PWMGEN_BIT_COUNT_CAP_MAX
follow the eDP 1.4b Section 10.3. Which states min should
be >= 1 and max should be >= min. Some legacy panels
do not follow this properly. They set the
BACKLIGHT_BRIGHTNESS_AUX_SET_CAPABLE bit while not correctly
populating the min and max fields leading to a 0 max value.
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/7514
Fixes: 40d2f58209 ("drm/i915/backlight: Remove try_vesa_interface")
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Pranay Samala <pranay.samala@intel.com>
Link: https://patch.msgid.link/20260316031850.81794-1-suraj.kandpal@intel.com
Initialize the stepping name in display runtime info. This avoids having
to use intel_step_name().
For display device info print at boot, debugfs and snapshot this changes
the unknown step name from ** to N/A, which is more user friendly
anyway.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://patch.msgid.link/aab445dedb8235d9fdddfe2ee5bb624cdf453a18.1773663208.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Having intel_get_stepping_info() return the pointer that was passed in
isn't necessary. Just use a pointer to the local variable instead.
The initialization to ** didn't make a difference, because it was always
overridden.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://patch.msgid.link/c9affb82fd3e9fb464778013bb7c8fab06232bfd.1773663208.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The function intel_gvt_i2c_handle_aux_ch_write currently does not
support the DP_AUX_I2C_WRITE operation. Notably, we check if
op & 0x1 == DP_AUX_I2C_WRITE (one), and if it does not, assert that
op & 0x1 == DP_AUX_I2C_READ (zero). This is unnecessary because if
op & 0x1 != 1, then op & 0x1 == 0. But beyond that, it probably makes
more sense to check for the condition that is implemented, rather than
check for the condition that is not.
Swap the conditions. We can also get rid of the unnecessary drm_WARN_ON
while we're here.
Suggested-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260204161945.8127-2-jonathan.cavitt@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Static analysis issue:
In assert_port_valid, add a check to ensure port != PORT_NONE, as that
is not a valid port. The check must be explicit to prevent a bad bit
shift operation in the general case via short-circuiting. It's not
likely this will ever come up in a real use case, but it's at least
worth guarding against.
It would probably also be pertinent to modify the behavior of the
port_name function to correctly print PORT_NONE in this case, as
currently the port would be reported as 'port @' by the debugger. But
that should be done separately, and given port_name is mostly just a
debug printing helper function anyways, fixing it is a low priority.
v2:
- Conditional check was backwards. Fix it. (Jani)
Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260123152121.7042-2-jonathan.cavitt@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
PSR entry_setup_frames is currently computed directly into struct
intel_dp:intel_psr:entry_setup_frames. This causes a problem if mode change
gets rejected after PSR compute config: Psr_entry_setup_frames computed for
this rejected state is in intel_dp:intel_psr:entry_setup_frame. Fix this by
computing it into intel_crtc_state and copy the value into
intel_dp:intel_psr:entry_setup_frames on PSR enable.
Fixes: 2b981d57e4 ("drm/i915/display: Support PSR entry VSC packet to be transmitted one frame earlier")
Cc: Mika Kahola <mika.kahola@intel.com>
Cc: <stable@vger.kernel.org> # v6.8+
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260312083710.1593781-3-jouni.hogander@intel.com
PSR/PR parameters might change based on update_m_n or update_lrr. Disable
on update_m_n and update_lrr to ensure proper parameters are taken into use
on next PSR enable in intel_psr_post_plane_update.
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15771
Fixes: 2bc98c6f97 ("drm/i915/alpm: Compute ALPM parameters into crtc_state->alpm_state")
Cc: <stable@vger.kernel.org> # v6.19+
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260312083710.1593781-2-jouni.hogander@intel.com
Add .framebuffer_init, .framebuffer_fini and .framebuffer_lookup to the
bo parent interface. While they're about framebuffers, they're
specifically about framebuffer objects, so the bo interface is a good
enough fit, and there's no need to add another interface struct.
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/848d32a44bf844cba3d66e44ba9f20bea4a8352d.1773238670.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
intel_fb_bo.c is i915 core specific code, and should use struct
drm_i915_private instead of struct intel_display.
Switch one DISPLAY_VER() to GRAPHICS_VER(). The check is for < 4, where
they're effectively the same thing.
Reviewed-by: Suraj Kandpal@intel.com>
Link: https://patch.msgid.link/13087bd24bd5af5265ca6af67f086b93e26e311f.1773238670.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Continue i915 and xe separation from display by moving the bo calls to
the display parent interface. Instead of adding all these functions to
intel_parent.[ch], reuse the now vacated intel_bo.[ch], and avoid mass
renames to calls of these functions. This is similar to
intel_display_rpm.[ch].
Make many of the hooks optional to avoid having to implement dummy
functions in xe. Indeed now we can remove many of the existing dummy
functions.
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/7899eef2ccf0cd603df69099df065226a0df917b.1773238670.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Since both the DP SST and MST HPD IRQ handlers call
intel_dp_handle_link_service_irq() with LINK_STATUS_CHANGED set in
irq_mask if intel_dp->link.force_retrain is set, checking for the former
flag is sufficient to determine if the link status needs to be checked
(which includes retraining the link if this is forced); remove checking
for the latter flag.
Since LINK_STATUS_CHANGED is currently set unconditionally for DP SST,
extend the related comment to note that it must be set if
intel_dp->link.force_retrain is set (in case setting LINK_STATUS_CHANGED
becomes conditional on DPCD_REV).
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260311153152.133744-2-imre.deak@intel.com
Handling of a forced link retraining debugfs request via the DP MST HPD
IRQ handler is incorrectly skipped, if the IRQ handler doesn't see any
HPD IRQs raised by the sink. Fix this by ensuring that the request is
always handled (in the Fixes: commit below by directly calling
intel_dp_check_link_state(), later by the same call moved to
intel_dp_handle_link_service_irq()).
Cc: Luca Coelho <luciano.coelho@intel.com>
Fixes: db4855d903 ("drm/i915/dp_mst: Reuse intel_dp_check_link_state() in the HPD IRQ handler")
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260311153152.133744-1-imre.deak@intel.com
During intel_hdcp_check_link phase we need to take into account
if we are currently forcing HDCP 1.4 or not. This is because
we check for HDCP 2.x Link first and only if HDCP 2.x is not being
used check for HDCP 1.4. With force_hdcp14 in picture we should not
be going into intel_hdcp2_check_link because of which we may end
up trying to disable HDCP2.x even if HDCP 1.4 was enabled causing
a lot of issues while IGT tests this.
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/20260225065045.3040787-1-suraj.kandpal@intel.com
intel_dmc_update_dc6_allowed_count() oopses when DMC hasn't been
initialized, and dmc is thus NULL.
That would be the case when the call path is
intel_power_domains_init_hw() -> {skl,bxt,icl}_display_core_init() ->
gen9_set_dc_state() -> intel_dmc_update_dc6_allowed_count(), as
intel_power_domains_init_hw() is called *before* intel_dmc_init().
However, gen9_set_dc_state() calls intel_dmc_update_dc6_allowed_count()
conditionally, depending on the current and target DC states. At probe,
the target is disabled, but if DC6 is enabled, the function is called,
and an oops follows. Apparently it's quite unlikely that DC6 is enabled
at probe, as we haven't seen this failure mode before.
It is also strange to have DC6 enabled at boot, since that would require
the DMC firmware (loaded by BIOS); the BIOS loading the DMC firmware and
the driver stopping / reprogramming the firmware is a poorly specified
sequence and as such unlikely an intentional BIOS behaviour. It's more
likely that BIOS is leaving an unintentionally enabled DC6 HW state
behind (without actually loading the required DMC firmware for this).
The tracking of the DC6 allowed counter only works if starting /
stopping the counter depends on the _SW_ DC6 state vs. the current _HW_
DC6 state (since stopping the counter requires the DC5 counter captured
when the counter was started). Thus, using the HW DC6 state is incorrect
and it also leads to the above oops. Fix both issues by using the SW DC6
state for the tracking.
This is v2 of the fix originally sent by Jani, updated based on the
first Link: discussion below.
Link: https://lore.kernel.org/all/3626411dc9e556452c432d0919821b76d9991217@intel.com
Link: https://lore.kernel.org/all/20260228130946.50919-2-ltao@redhat.com
Fixes: 88c1f9a4d3 ("drm/i915/dmc: Create debugfs entry for dc6 counter")
Cc: Mohammed Thasleem <mohammed.thasleem@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Tao Liu <ltao@redhat.com>
Cc: <stable@vger.kernel.org> # v6.16+
Tested-by: Tao Liu <ltao@redhat.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260309164803.1918158-1-imre.deak@intel.com
Move the get/put/ref/flush_for_display calls to the display parent
interface.
For i915, move the hooks next to the other i915 core frontbuffer code in
i915_gem_object_frontbuffer.c. For xe, add new file xe_frontbuffer.c for
the same.
Note: The intel_frontbuffer_flush() calls from
i915_gem_object_frontbuffer.c will partially route back to i915 core via
the parent interface. This is less than stellar.
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patch.msgid.link/f69b967ed82bbcfd60ffa77ba197b26a1399f09f.1772475391.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The intel_frontbuffer_get() and intel_frontbuffer_put() calls are routed
through intel_frontbuffer.c to i915_gem_object_frontbuffer.c. We might
as well call the functions directly, instead of going through display
code. This would only get worse with get/put being moved to the parent
interface.
To make this easier, convert overlay code from struct intel_frontbuffer
to struct i915_frontbuffer, and add a
i915_gem_object_frontbuffer_track() wrapper for clarity.
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patch.msgid.link/829b304a6451e80fbce554bdc7788077245e803a.1772475391.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Move __i915_gem_object_{flush,invalidate}_frontbuffer() to
i915_gem_object_frontbuffer.c. All the other i915 gem object frontbuffer
functions are there already, and the relevant declarations are in
i915_gem_object_frontbuffer.h too.
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patch.msgid.link/d779ef44b4b43feda9df63f1225a947a9cd23ba8.1772475391.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The vga_get_uninterruptible() function can return an error if it fails to
set up VGA decoding for the requested device.
If VGA decoding is unavailable, we don't need to be careful to leave the
VGA emulation in a usable state, as vgacon will also be unable to get
access later on, so just skip over the VGA accesses and the vga_put() call
matching the failed vga_get_uninterruptible().
Signed-off-by: Simon Richter <Simon.Richter@hogyros.de>
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1824
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260306151347.758836-1-Simon.Richter@hogyros.de
Correct the function parameter names to avoid kernel-doc warnings
and to emphasize this function is atomic (non-sleeping).
Warning: include/linux/iopoll.h:169 function parameter 'sleep_us' not
described in 'read_poll_timeout_atomic'
Warning: ../include/linux/iopoll.h:169 function parameter
'sleep_before_read' not described in 'read_poll_timeout_atomic'
Fixes: 9df8043a54 ("iopoll: Generalize read_poll_timeout() into poll_timeout_us()")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260306221033.2357305-1-rdunlap@infradead.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Convert the low-hanging fruits of workaround checks to the workaround
framework. Instead of having display structure checks for the
workarounds all over, concentrate the checks in intel_display_wa.c.
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260305100100.332956-17-luciano.coelho@intel.com
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Convert the low-hanging fruits of workaround checks to the workaround
framework. Instead of having display structure checks for the
workarounds all over, concentrate the checks in intel_display_wa.c.
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260305100100.332956-16-luciano.coelho@intel.com
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Convert the low-hanging fruits of workaround checks to the workaround
framework. Instead of having display structure checks for the
workarounds all over, concentrate the checks in intel_display_wa.c.
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260305100100.332956-15-luciano.coelho@intel.com
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Convert the low-hanging fruits of workaround checks to the workaround
framework. Instead of having display structure checks for the
workarounds all over, concentrate the checks in intel_display_wa.c.
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260305100100.332956-14-luciano.coelho@intel.com
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Convert the low-hanging fruits of workaround checks to the workaround
framework. Instead of having display structure checks for the
workarounds all over, concentrate the checks in intel_display_wa.c.
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260305100100.332956-13-luciano.coelho@intel.com
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
