drm/i915 feature pull #2 for v7.3:

Features and functionality:
- Enable UHBR link rates on Thunderbolt tunneled links (Imre)
- Reduce Xe3+ PM demand peak bandwidth for power savings (Vinod)
- Add the blend mode property to all planes that support alpha blending (Chaitanya)
- Enable pipe DMC error interrupts for display 30+ (Dibin)
- Add KUnit tests for DP link config selection and fallback (Imre)

Refactoring and cleanups:
- Refactor DP link config selection and unify across use cases (Imre)
- Unify i915 and xe display runtime PM calls (Jani)
- Refactor BIOS framebuffer takeover (Ville)

Fixes:
- Fix HD audio on DP UHBR SST (Kai Vehmanen)
- Fixes to xe driver BIOS framebuffer takeover (Ville)
- Fix 2 pixels-per-clock CDCLK calculation to avoid underruns (Ville)
- Fix incorrectly set VSC SDP Main Stream Attribute (Chaitanya)
- Fix BPC and DSC selection for HDMI sinks (Alexander Kaplan)
- Fix PCON max FRL rate selection (Alexander Kaplan)
- Workaround Xe3P PSR2 screen corruption (Dibin)
- Fix NVL A & B stepping vtotal setting (Suraj)
- Fix xe DPT allocation paths (Maarten)
- Prefer system memory instead of stolen for new framebuffers in xe (Maarten)
- Fix transcoder mask sizes (John Harrison)
- Clear stale UV/Y plane DDB entries on plane disable (Vinod)
- Fix some DP AUX backlight control issues, again (Suraj)
- Fix switching between HDCP 1.4 and 2.2 authentication (Suraj)
- Remove unnecessary Xe2_LPD+ FBC plane width and surface size limits (Vinod)
- Ensure non-zero DSB safe window for PTL+ (Ankit)
- Fix bandwidth calculation to account for 16 DRAM channels (Uma)
- Fix NV12 ceiling division for bigjoiner case (Vidya)

DRM core changes:
- Add Thunderbolt UHBR tunneling support (Imre)

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/cb1b5a644d75589cbcdcc8ec8160968140426439@intel.com

Prefer to use system memory for global framebuffers, and reserve
the space for FBC use only.

Now that multiple CRTC's can use FBC's, the simple heuristic
of using less than half of stolen is no longer sufficient.

Additionally, there are reports of system hangs when using stolen
memory, and there are also various workarounds that are avoided
by using system memory instead.

Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7513
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patch.msgid.link/20260630135523.1775379-4-dev@lankhorst.se
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
Acked-by: Matthew Brost <matthew.brost@intel.com> #teams

Remove the fallback for VRAM to system memory, I tested it and that
doesn't work at all, only a black screen with pipe fault errors were
observed.

On systems with media GT, extra latency is added when accessing stolen
memory when the GT is in MC6. Since we additionally aren't counting how
much memory is used for stolen and we could in theory fill up the
entire stolen area with DPT's, avoid using stolen and only use the
default memory region.

Using stolen may also result in random system hangs under load.

Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7513
Fixes: 775d0adc01a5 ("drm/xe/fbdev: Limit the usage of stolen for LNL+")
Cc: <stable@vger.kernel.org> # v6.12+
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patch.msgid.link/20260630135523.1775379-2-dev@lankhorst.se
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
Acked-by: Matthew Brost <matthew.brost@intel.com> #teams

Do the PTE local memory bit check also for the case when
the initial FB lives in stolen. We have two cases to worry about
here: MTL+ with LMEMBAR, and pre-MTL with stolen being just
(slightly special) physical memory.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260511214122.8468-11-ville.syrjala@linux.intel.com
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
Acked-by: Matthew Brost <matthew.brost@intel.com> #teams

Add a few helpers that allow us to abstract the xe initial FB PTE
check a bit. Still very ad-hoc compared to the nicely abstracted
i915 counterpart, but whatever.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260511214122.8468-10-ville.syrjala@linux.intel.com
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
Acked-by: Matthew Brost <matthew.brost@intel.com> #teams

Inform the poor sop reading the logs why the initial FB was rejected
if there is no stolen memory.

Technically this should perhaps be an error since the plane is known
to be enabled at this point, and if there is no stolen then it clearly
can't be scanning out from anywhere. But maybe there are some
virtualization passthrough cases and whatnot where we might not be
able to get access to stolen, so keep it as debug (same as i915).

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260511214122.8468-9-ville.syrjala@linux.intel.com
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
Acked-by: Matthew Brost <matthew.brost@intel.com> #teams

For some reason we've split the alignment of 'base' vs. 'size'
to live on separate sides of the xe initial plane PTE readout.
There's no reason for this split, so make things less confusing
by aligning both at the same time.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260511214122.8468-7-ville.syrjala@linux.intel.com
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
Acked-by: Matthew Brost <matthew.brost@intel.com> #teams

The initial FB stuff is ultimately about display stuff, so
use the proper display specific debug level for it.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260511214122.8468-6-ville.syrjala@linux.intel.com
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>

Hook the shared i915 display DP link KUnit tests into the xe display
test build.

Build the shared display test source from the i915 display test directory
when xe display support is enabled.

v2: Unchanged.
v3: Add SPDX license header. (Michał)

Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260707124849.135319-2-imre.deak@intel.com

drm/i915 feature pull for v7.3:

Features and functionality:
- Novalake (NVL, display versio 35) Common Mode Timing Generator (CMTG) enabling (Animesh)
- NVL DC3CO enabling (Dibin)

Refactoring and cleanups:
- Refactor and document DP link recovery and capability tracking (Imre)
- i915 and xe driver display probe/remove/suspend/resume/shutdown cleanup and unification (Jani)
- Clean up bandwidth/SAGV code (Ville)
- Streamline Pre/Post-CSC LUT loops (Jani)
- Remove unused TGL DC3DO support (Dibin)
- Make read-only array rates static const (Colin Ian King)
- CDCLK sanitization improvements and cleanups (Ville)
- Break i915 and xe panic dependency on struct intel_framebuffer (Jani)
- GPIO pin renames and cleanups (Ville)
- Unify generic irq handler error messages (Jonathan)

Fixes:
- Various color pipeline fixes (Chaitanya)
- Fix step discontinuity in Pre/Post-CSC Gamma LUT (Sean Paul)
- Improve refresh rate changes without full modeset on VRR capable eDP (Ville)
- Display suspend/resume fixes (Imre)
- Fix LPE audio irq for PREEMPT-RT (Maarten)
- Fix HDMI scrambling enable (Jerome Tollet)
- LNL bandwidth buddy programming update (Vinod)
- Streamline display register wait timeouts (Ville)
- Fix DP MSA VTotal (Mitul)
- Fix LTPHY SSC enabling (Suraj)
- Fix LOBF requirements with optimized guardband (Ankit)
- Avoid full modeset for LRR vsync changes (Ankit)
- Fix vtotal-vsync distance when adjusting vtotal for lower refresh rate (Ankit)
- Extend VRR safe window wait for default VRR timing generator usage (Ankit)

Merges:
- Backmerge for v7.2-rc1 (Jani)

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/934cacdbf2a37856eb5cd6337d8774b449405bd8@intel.com