drm/i915/dsi: convert parameter printing to drm_printer

The DSI VBT initialization debug logs a lot of parameters. Convert this
to use struct drm_printer with a prefix.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/50ff85e66c058a12b2fe0d0cba6a542f7cfa71cf.1742554320.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/dsi: convert vlv_dsi_pll.[ch] to struct intel_display

Going forward, struct intel_display is the main display device data
pointer. Convert as much as possible of vlv_dsi_pll.[ch] to struct
intel_display.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/9d34d8b91c6bc8b2dd8e2081194ee496b251bbf3.1742554320.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/dsi: convert vlv_dsi.[ch] to struct intel_display

Going forward, struct intel_display is the main display device data
pointer. Convert as much as possible of vlv_dsi.[ch] to struct
intel_display.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/320449f3b58c6eca6fdbb16e4e819cd0e133887a.1742554320.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/display: Read panel replay source status through PSR2 status register

PTL onwards get panel replay status from PSR2 status register
instead of SRD status.

Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250324100823.3111564-1-animesh.manna@intel.com

drm/i915/xe2hpd: Identify the memory type for SKUs with GDDR + ECC

Some SKUs of Xe2_HPD platforms (such as BMG) have GDDR memory type
with ECC enabled. We need to identify this scenario and add a new
case in xelpdp_get_dram_info() to handle it. In addition, the
derating value needs to be adjusted accordingly to compensate for
the limited bandwidth.

Bspec: 64602
Cc: Matt Roper <matthew.d.roper@intel.com>
Fixes: 3adcf970dc7e ("drm/xe/bmg: Drop force_probe requirement")
Cc: stable@vger.kernel.org
Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Acked-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250324-tip-v2-1-38397de319f8@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>

drm/i915/fbc: update the panel_replay dependency in fbc wa's

There are two panel_replay scenarios fbc wa need to be aware of,
panel replay with and without selective update capability.
Panel replay without selective update don't have any fbc wa.
So keep the fbc psr1 wa as it is.

The current fbc psr2 wa is mainly about selective fetch and we
need to apply the fbc wa if selective fetch is on - irrespective
of panel replay. Hence we can't exclude panel replay from the
fbc psr2 wa.

v1: keep panel_replay exclusion in PSR1 case (Jouni)
    Patch description updated

Bspec: 66624, 50442
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250321094529.197397-3-vinod.govindapillai@intel.com

drm/i915/fbc: keep FBC disabled if selective update is on in xe2lpd

FBC was disabled in case PSR2 selective update in display 12 to
14 as part of a wa. From xe2lpd onwards there is a logic to be
implemented to decide between FBC and selective update. Until
that logic is implemented keep FBC disabled in case selective
update is enabled.

v1: updated patch description and some explanation and todo

Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250321094529.197397-2-vinod.govindapillai@intel.com

drm/i915/dmc: Create debugfs entry for dc6 counter

Starting from MTL we don't have a platform agnostic way to validate
DC6 state due to dc6 counter has been removed to validate DC state.

The goal is to validate that the display HW can reach the DC6 power
state. There is no HW DC6 residency counter (and there wasn't such
a counter earlier either), so an alternative way is required. According
to the HW team the display driver has programmed everything correctly in
order to allow the DC6 power state if the DC5 power state is reached
(indicated by the HW DC5 residency counter incrementing) and DC6 is
enabled by the driver.

Driver could take a snapshot of the DC5 residency counter right
after it enables DC6 (dc5_residency_start) and increment the SW
DC6 residency counter right before it disables DC6 or when user space
reads the DC6 counter. So the driver would update the counter at these
two points in the following way:
dc6_residency_counter += dc5_current_count - dc5_start_count

v2: Update the discription. (Imre)
    Read dc5 count during dc6 enable and disable then and update
    dc6 residency counter. (Imre)
    Remove variable from dmc structure. (Jani)
    Updated the subject title.
v3: Add i915_power_domains lock to updated dc6 count in debugfs. (Imre)
    Use flags to check dc6 enable/disable states. (Imre)
    Move the display version check and counter read/update to
    a helper. (Imre)
    Resize the variable length. (Rodrigo)
    Use old dc6 debugfs entry for every platform. (Rodrigo)
v4: Remove superfluous whitespace. (Jani)
    Read DMC registers in intel_dmc.c (Jani)
    Rename dc6_en_dis to dc6_enabled and change its type to bool. (Jani)
    Rename update_dc6_count and move it to intel_dmc.c (Jani)
    Rename dc6_en_dis to start_tracking. (Imre)
    Have lock for dc6 state read aswelll. (Imre)
    Keep the existing way print 'DC5 -> DC6 count' along with
    new 'DC6 Allowed Count' print. (Imre)
    Add counters in intel_dmc struct. (Imre)
    Have interface to return dc6 allowed count. (Imre)
    Rename dc6_count to dc6_allowed_count. (Rodrigo)
v5: Rename counters and move in to dc6_allowed structure. (Imre)
    Order declaration lines in decreasing line length. (Imre)
    Update start_tacking logic. (Imre)
    Move get couner inside lock and DISPLAY_VER code to helper. (Imre)
v6: Change intel_dmc_get_dc6_allowed_count return type to bool. (Imre)
    Update debugfs print to better allien with old print. (Imre)
    Remove braces at if/else for signle line statements. (Imre)
v7: Remove in line variable declaration. (Imre)
v8: Rebase the changes.

Signed-off-by: Mohammed Thasleem <mohammed.thasleem@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250321123707.287745-1-mohammed.thasleem@intel.com

drm/i915/vrr: Avoid reading vrr.enable based on fixed_rr check

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: 27217f9d1856 ("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

drm/i915/display: Add fixed_rr to crtc_state dump

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

drm/i915/vdsc: Use the DSC config tables for DSI panels

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

drm/xe/compat: remove intel_runtime_pm.h

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

drm/i915/power: convert to display runtime PM interfaces

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

drm/i915/display: convert to display runtime PM interfaces

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

drm/i915/display: use display runtime PM interfaces for for atomic state

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

drm/i915/display: conversions to with_intel_display_rpm()

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

drm/i915/display: add display specific runtime PM wrappers

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

drm/i915/display: rename I915_HAS_HOTPLUG() to HAS_HOTPLUG

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

drm/i915/irq: convert rest of intel_display_irq.[ch] to struct intel_display

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

drm/i915/irq: convert intel_display_irq.[ch] interfaces to struct intel_display

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

drm/i915/hotplug: convert intel_hotplug_irq.[ch] to struct intel_display

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

drm/i915/hotplug: convert hotplug irq handling to intel_de_*()

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

drm/i915/hotplug: convert hotplug debugfs to struct intel_display

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

drm/i915/hotplug: convert intel_hotplug.[ch] to struct intel_display

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

drm/i915/connector: convert intel_connector.c to struct intel_display

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

drm/i915/color: prefer display->platform.<platform> checks

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

drm/i915/display: Fix build error without DRM_FBDEV_EMULATION

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>

drm/i915: Fix harmful driver register/unregister asymmetry

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

drm/i915: Fix PXP cleanup missing from probe error rewind

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

drm/i915: Downgrade device register error if injected

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

drm/i915/display: Maintain asciibetical order for HAS_* macros

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

drm/i915/xe3lpd: Update bandwidth parameters

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>

drm/i915/display: Convert intel_bw.c externally to intel_display

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>

drm/i915/display: Convert intel_bw.c internally to intel_display

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>

drm/i915/display: Enable MSA Ignore Timing PAR only when in not fixed_rr mode

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

drm/i915/vrr: Prepare for fixed refresh rate timings

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

drm/i915/vrr: Use crtc_vtotal for vmin

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

drm/i915/vrr: Track vrr.enable only for variable timing

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

drm/i915/vrr: Disable CMRR

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

drm/i915/vrr: Make helpers for cmrr and vrr timings

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

drm/i915:vrr: Separate out functions to compute vmin and vmax

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

drm/i915/vrr: Remove unwanted comment

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

drm/i915/watermark: Check bounds for scaler_users for dsc prefill latency

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

drm/i915/crt: Use intel_hpd_block/unblock() instead of 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

drm/i915/dp: Queue a link check after link training is complete

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

drm/i915/dp: Fix link training interrupted by a short HPD pulse

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

drm/i915/hpd: Add support for blocking the IRQ handling on an HPD pin

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

drm/i915/hpd: Let an HPD pin be in the disabled state when handling missed IRQs

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

drm/i915/hpd: Track HPD pins instead of ports for HPD pulse events

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

drm/i915/xe3lpd: Map POWER_DOMAIN_AUDIO_PLAYBACK to DC_off

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>

drm/i915: Relocate intel_bw_crtc_update()

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

drm/i915: Move dbuf_state->active_pipes into skl_wm_get_hw_state()

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

drm/i915: Do wm readout ealier for skl+

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

drm/i915: Split wm sanitize from readout

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

drm/i915: Simplify cdclk_disable_noatomic()

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

sem/i915: Simplify intel_cdclk_update_hw_state()

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

drm/i915: Skip some bw_state readout on pre-icl

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

drm/i915: Update bw_state->active_pipes during readout

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

drm/i915: Extract intel_bw_update_hw_state()

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

drm/i915: Extract intel_cdclk_update_hw_state()

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

drm/i915: Extract intel_bw_crtc_disable_noatomic()

Hoist the bw stuff into a separate function from
intel_crtc_disable_noatomic_complete() 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-9-ville.syrjala@linux.intel.com

drm/i915: Add skl_wm_plane_disable_noatomic()

Add skl_wm_plane_disable_noatomic() which will clear out all
the ddb and wm state for the plane. And let's do this _before_
we call plane->disable_arm() so that it'll actually clear out
the state in the hardware as well.

Currently this won't do anything new for most of the
intel_plane_disable_noatomic() calls since those are done before
wm readout, and thus everything wm/ddb related in the state
will still be zeroed anyway. The only difference will be for
skl_dbuf_sanitize() is happens after wm readout. But I'll be
reordering thigns so that wm readout happens earlier and at that
point this will guarantee that we still clear out the old
wm/ddb junk from the state.

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-8-ville.syrjala@linux.intel.com

drm/i915: clean up pipe's ddb usage in intel_crtc_disable_noatomic()

Update the ddb tracking information when we disable a pipe
during sanitization. Avoids leaving stale junk in the states.

Currently this doesn't do anything as we haven't read out this
state yet when we do the sanitization, but that will change soon.

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-7-ville.syrjala@linux.intel.com

drm/i915: Extract skl_wm_crtc_disable_noatomic()

Hoist the dbuf stuff into a separate function from
intel_crtc_disable_noatomic_complete() so that the details
are better hidden inside skl_watermark.c.

We can also skip the whole thing on pre-skl since the dbuf state
isn't actually used on those platforms. The readout path does
still fill dbuf_state->active_pipes but we'll remedy that later.

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-6-ville.syrjala@linux.intel.com

drm/i915: Extract intel_cdclk_crtc_disable_noatomic()

Hoist the cdclk stuff into a separate function from
intel_crtc_disable_noatomic_complete() 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-5-ville.syrjala@linux.intel.com

drm/i915: Use intel_plane_set_invisible() in intel_plane_disable_noatomic()

Reuse intel_plane_set_invisible() in intel_plane_disable_noatomic()
instead of hand rolling the same stuff.

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-4-ville.syrjala@linux.intel.com

drm/i915: Don't clobber crtc_state->cpu_transcoder for inactive crtcs

Inactive crtcs are supposed to have their crtc_state completely
cleared. Currently we are clobbering crtc_state->cpu_transcoder
before determining whether it's actually enabled or not. Don't
do that.

I want to rework the inherited flag handling for inactive crtcs
a bit, and having a bogus cpu_transcoder in the crtc state can
then cause confusing fastset mismatches even when the crtc never
changes state during the commit.

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-3-ville.syrjala@linux.intel.com

drm/i915: Drop redundant shared_dpll=NULL assignments

The crtc state is expected to be fully cleared before readout,
so there is no need to clear the shared_dpll pointers by hand.

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-2-ville.syrjala@linux.intel.com

drm/i915: Program CURSOR_PROGRAM and COEFF_POLARITY for icl+ combo PHYs

Bspec asks us to clear the CURSOR_PROGRAM and COEFF_POLARITY
bits in PORT_TX_DW5 on icl+ combo PHYs. Make it so.

Bspec: 21257, 49291
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250303123952.5669-2-ville.syrjala@linux.intel.com
Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>

drm/i915/plane: convert intel_atomic_plane.[ch] to struct intel_display

Going forward, struct intel_display is the main display device data
pointer. Convert intel_atomic_plane.[ch] to struct intel_display.

Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/d7e28ad43f67d92e54fb7e14373872b5e561038c.1741192597.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/xe/compat: refactor compat i915_drv.h

The compat i915_drv.h contains things that aren't there in the original
i915_drv.h. Split out gem/i915_gem_object.h and i915_scheduler_types.h,
moving the corresponding pieces out, including FORCEWAKE_ALL to
intel_uncore.h.

Technically I915_PRIORITY_DISPLAY should be in i915_priolist_types.h,
but it's a bit overkill to split out another file just for
that. i915_scheduler_types.h shall do.

With this, the compat i915_drv.h becomes a strict subset of the
original.

Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/d6bd95bf52aa37f48ddec3e675b7a3cc66829eef.1741192597.git.jani.nikula@intel.com
[Jani: fix i915_gem_object.h header guard while applying]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/cdclk: Do cdclk post plane programming later

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>

drm/fb-helper: Remove struct drm_fb_helper.fb_probe

The callback fb_probe in struct drm_fb_helper is unused. Remove it.
New drivers should set struct drm_driver.fbdev_probe instead and call
drm_client_setup() to instantiate in-kernel DRM clients.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241212170913.185939-13-tzimmermann@suse.de
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>

drm/i915/display: Remove compile guard around fbdev debugfs output

If fbdev support has been disabled, no output will be shown. Remove
the fbdev-related compile guard from the driver's debugfs code.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241212170913.185939-12-tzimmermann@suse.de
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>

drm/{i915,xe}: Run DRM default client setup

Rework fbdev probing to support fbdev_probe in struct drm_driver
and remove the old fb_probe callback. Provide an initializer macro
that sets the callback in struct drm_driver according to the kernel
configuration. Call drm_client_setup_with_color_mode() to run the
kernel's default client setup for DRM.

This commit also prepares support for the kernel's drm_log client
(or any future client) in i915. Using drm_log will also require vmap
support in GEM objects.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241212170913.185939-11-tzimmermann@suse.de
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>

drm/i915/display: Move fbdev code around

Move fbdev code around in the source file before switching to DRM's
generic fbdev client. This will make the conversion less intrusive.
No functional changes.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241212170913.185939-10-tzimmermann@suse.de
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>

drm/i915/display: Remove struct drm_fb_helper from struct intel_fbdev

Store instances of drm_fb_helper and struct intel_fbdev separately.
This will allow i915 to use the common fbdev client, which allocates
its own instance of struct drm_fb_helper.

There is at most one instance of type each per DRM device, so both can
be referenced directly from the i915 and DRM device structures. A later
patchset might rework the common fbdev client to allow for storing
both, drm_fb_helper and intel_fbdev, together in the same place.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241212170913.185939-9-tzimmermann@suse.de
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>

drm/i915/display: Remove preferred_bpp from struct intel_fbdev

The value preferred_bpp in struct intel_fbdev duplicates preferred_bpp
in struct drm_fb_helper. Remove the former.

Instead let intel_fbdev_init_bios() read the framebuffer from the
hardware. Then derive preferred_bpp from its format and initialize
struct drm_fb_helper with the value. The default is 32 (i.e., XRGB8888).

Also removes one of those deprecated references to the cpp field of
struct drm_format_info.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241212170913.185939-8-tzimmermann@suse.de
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>

drm/i915/display: fbdev: Move custom suspend code to new callback

If the fbdev buffer is backed by stolen memory, it has to be cleared
upon resume from hibernation. Move the code into the new callback
fb_set_suspend, so that it can run from DRM's generic fbdev client.
No functional change. Other drivers are not affected.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241212170913.185939-7-tzimmermann@suse.de
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>

drm/i915/display: fbdev: Move custom restore code to new callback

i915's fbdev contains code for restoring the client's framebuffer. It
is specific to i195 and cannot be ported to the common fbdev client.

Introduce the callback struct drm_fb_helper.fb_restore and implement
it for i915. The fbdev helpers invoke the callback after restoring the
fbdev client.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241212170913.185939-6-tzimmermann@suse.de
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>

drm/i915/display: Remove fbdev suspend and hotplug tracking

The DRM client code already tracks suspend status and hotplug events
for each client. Remove similar code from i915's fbdev client.

Allows for the removal of all hdp_* fields form struct intel_fbdev.
Calls to intel_fbdev_output_poll_changed() are reduced the shared
helper drm_fb_helper_hotplug_event().

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241212170913.185939-5-tzimmermann@suse.de
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>

drm/client: Send pending hotplug events after resume

If a hotplug event arrives while the client has been suspended,
DRM's client code will deliver the event after resuming. The
functionality has been taken form i915, where it can be removed
by a later commit.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241212170913.185939-4-tzimmermann@suse.de
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>

drm/client: Add client-hotplug helper

Move client hotplug calls to drm_client_hotplug(). We'll need this
helper to send hotplug events after resuming.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241212170913.185939-3-tzimmermann@suse.de
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>

drm/{i915, xe}: Suspend/resume fbdev emulation via client interfaces

Implement drm_client_dev_suspend() and drm_client_dev_resume() for
i915's fbdev emulation and call the helper via DRM client interfaces.
This is required to convert i915 and xe to DRM's generic fbdev client.
No functional changes.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241212170913.185939-2-tzimmermann@suse.de
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>

drm/xe/display: Fix fbdev GGTT mapping handling.

FBDEV ggtt is not restored correctly, add missing GGTT flag to
intel_fbdev_fb_alloc to make it work. This ensures that the global
GGTT mapping is always restored on resume. The GGTT mapping would
otherwise be created in intel_fb_pin_to_ggtt() by intel_fbdev anyway.

This fixes the fbdev device not working after resume.

Fixes: 67a98f7e27ba ("drm/xe/display: Re-use display vmas when possible")
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250305110106.564366-1-dev@lankhorst.se
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>

drm/i915/display: convert intel_display.c to struct intel_display

Going forward, struct intel_display is the main display device data
pointer. Convert as much as possible of intel_display.c to struct
intel_display.

This exposes a couple of outside issues that need to be fixed as well,
in a register macro and a DSI PLL stub.

Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1c0bafcb978d1cf4f4d54be2f497386f5302f7c8.1741084010.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/display: remove dupe intel_update_watermarks() declaration

intel_wm.h already has intel_update_watermarks() declaration. Remove the
dupe.

Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/67eeebff3ec9459f7854fbc56cfd7f2aa8c1fdc6.1741084010.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/display: convert intel_has_pending_fb_unpin() to struct intel_display

Going forward, struct intel_display is the main display device data
pointer. The intel_display.[ch] files are too big to convert in one
go. Convert intel_has_pending_fb_unpin() to struct intel_display.

Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/d70ad8f9cbba5ee32d985b76047b56996ad4b31e.1741084010.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/display: convert some intel_display.[ch] functions to struct intel_display

Going forward, struct intel_display is the main display device data
pointer. The intel_display.[ch] files are too big to convert in one
go. Convert the interface towards intel_display_driver.c to struct
intel_display.

Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ee8b108420763cbf47ee77fa35b782a7293f9cfe.1741084010.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/display: convert various port/phy helpers to struct intel_display

Going forward, struct intel_display is the main display device data
pointer. The intel_display.[ch] files are too big to convert in one
go. Convert the various port/phy helpers to struct intel_display.

Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/e28e53bad5014ba3ef17431557b517f1b8530963.1741084010.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/reset: add modeset_stuck callback to intel_display_reset_prepare()

Drop the dependency on gt by providing a callback for trying to unbreak
stuck modeset. Do intel_gt_set_wedged() via the callback.

It's by no means pretty, but this is perhaps the most straightforward
alternative.

Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/d322e20927326afa47c0df8a4d4776ee77010e6d.1741001054.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/reset: pass test only parameter to intel_display_reset_finish()

Deduplicate the gpu_reset_clobbers_display() part by passing the
information in from gt side.

Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/a36481db334fedcde50ae0e66c4d57825cae8cb7.1741001054.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/reset: decide whether display reset is needed on gt side

Move the checks for whether display reset is needed at all to gt side of
things. This way, we can decide to skip the display calls altogether if
display reset is not required.

Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/c32a88f292f516ec702bd07001ac609b8acc2888.1741001054.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/reset: remove I915_RESET_MODESET flag

Since commit d59cf7bb73f3 ("drm/i915/display: Use dma_fence interfaces
instead of i915_sw_fence") we don't have anyone waiting on the
I915_RESET_MODESET bit, and there's no need for its semantics. Instead,
simply return true from intel_display_reset_prepare() to indicate that
intel_display_reset_finish() should be called.

Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/294690db3fae8fec7f356edf467e79882ed494db.1741001054.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/reset: add intel_display_reset_test()

Add a helper for checking if we want to test display reset regardless of
whether it's strictly necessary. This will come in handy in follow-up
work where we want to check this from gt reset side.

v2: Drop superfluous newline

Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/487dec72f753302cd565c3a8164afa7fc1e12ed7.1741001054.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/reset: add intel_gt_gpu_reset_clobbers_display() helper

Add a helper for checking the gpu_reset_clobbers_display flag to make it
easier to relocate the flag later.

Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/434d5db7675ed9717b3beae1389008b68a961855.1741001054.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: move pending_fb_pin to struct intel_display

pending_fb_pin is more about display than GPU reset. Move it to struct
intel_display. The restore sub-struct already contains reset related
members, so move it there.

Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ff779ae318610e6f6813474bcaa53851ffff909d.1741001054.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/display: convert display reset to struct intel_display *

Going forward, struct intel_display will be the main display device
structure. Convert display reset to it as much as possible.

Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/060c309189f1c084e012521822f4a0247f64528e.1741001054.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/fbc: handle dirty rect coords for the first frame

During enabling FBC, for the very first frame, the prepare dirty
rect routine wouldnt have executed as at that time the plane
reference in the fbc_state would be NULL. So this could make
driver program some invalid entries as the damage area. Though
fbc hw ignores the dirty rect values programmed for the first
frame after enabling FBC, driver must ensure that valid dirty
rect coords are programmed. So ensure that for the first frame
correct dirty rect coords are updated to the HW.

Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250228093802.27091-10-vinod.govindapillai@intel.com

drm/i915/fbc: disable FBC if PSR2 selective fetch is enabled

It is not recommended to have both FBC dirty rect and PSR2
selective fetch be enabled at the same time. Mark FBC as not
possible, if PSR2 selective fetch is enabled.

v2: fix the condition to disable FBC if PSR2 enabled (Jani)

v3: use HAS_FBC_DIRTY_RECT()

v4: Update to patch description

Bspec: 68881
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250228093802.27091-9-vinod.govindapillai@intel.com