drm/i915: Completely reject DPT BIOS FBs.

Our BIOS FB handling can't deal with DPT, and instead everything
just assumes a direct GGTT mapping. Reject any BIOS FB using DPT.
Most likely this should never happen anyway.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260410150449.9699-10-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Reject X/Y tiled BIOS FB if we don't have fenced regions

The CPU always needs linear view into the BIOS FB, and for X/Y tiled
buffers that is achieved by the use of a fenced region. If the
underlying driver doesn't support fenced regions then we can't keep
the X/Y tiled BIOS FB. i915 has fenced regions, xe does not.

Probably not a big deal since I don't think we've seen tiled BIOS
FBs outside of some MacBooks. See eg. commit d9a515867bdb
("drm/i915/gen9+: Fix initial readout for Y tiled framebuffers").

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260410150449.9699-9-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Reject tile4 BIOS FB

There is no such thing as tile4 fenced region, so there is no
way to have a linear view of the tile4 framebuffer for the CPU.
Thus we should never encounter a tile4 BIOS FB, but if we somehow
do, then reject it.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260410150449.9699-8-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Use a 1 second timeout for the polling vblank wait

40 msec seems like a very random number for a vblank wait timeout.
Considering ~24Hz display modes are definitely a thing this seems
way too low. Just bump it to a full second to match what we've been
using for normal vblank waits.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260410150449.9699-7-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Move initial plane vblank wait into display code

The initial plane vblank wait operates on display registers,
so it really belongs in the display code proper. Move it there.

We can use intel_parent_irq_enabled() to determine if we can
rely on interrupts or not.

On average we should end up waiting half a frame here, so the
polling interval can be fairly long. 1 ms (which actually
makes poll_timeout_us() use ~250-1000 usec) seems good enough
to me.

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

drm/i915: Make plane_config->fb a struct drm_framebuffer*

There's no need to use the intel specific struct intel_framebuffer*
type in the initial plane_config structure. Just make it a
struct drm_framebuffer*.

I think the fewer special types we expose in the interface (even
if just pointers) the better. At least then there is no need to
change the interface definition if we ever change the internal
types. And I hope that the existing examples will generally
encourage people to not expose more special types unless
absolutely necessary.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260410150449.9699-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Don't pass the whole plane_config to initial_plane_phys()

initial_plane_phys() only needs the 'base' (== ggtt virtual address)
from the plane_config. Stop passing the whole plane_config and just
pass the 'base'.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260410150449.9699-4-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Remove 'mem' and 'phy_base' from struct intel_initial_plane_config

The 'mem' and 'phy_base' members of struct intel_initial_plane_config
only exist to be passed from initial_plane_phys() to its sole caller.
Just return them via function arguments.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260410150449.9699-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Introduce sanity to the plane_config pointer vs. array thing

The "plane_config" vs. "plane_configs" naming difference is very
subtle, making it far too easy to use the wrong thing by accident.
Introduce a separate type for the array, making it impossible to
pass in the wrong thing. And while at it name the variable
"all_plane_configs" to help the poor reader make sense of things.

The .config_fini() prototype also mistakenly used the plural
form despite only taking in a singular plane_config. So fix that
one up as well.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260410150449.9699-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/psr: Init variable to avoid early exit from et alignment loop

Uninitialized boolean variable may cause unwanted exit from et alignment
loop. Fix this by initializing it as false.

Fixes: 681e12440d8b ("drm/i915/psr: Repeat Selective Update area alignment")
Cc: <stable@vger.kernel.org> # v6.9+
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Reported-by: Dan Carpenter <error27@gmail.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patch.msgid.link/20260413112345.88853-1-jouni.hogander@intel.com

drm/i915/dp: Make the RGB fallback for "4:2:0 only" modes the last resort

Currently we take the Hail Mary RGB fallback for "4:2:0 only" modes
already during the first pass when respect_downstream_limits==true.
It seems better to try everything else first (like ignoring TMDS
clock limits) while still preferring 4:2:0, and only if everything
else has failed fall back to RGB.

Cc: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260409101539.22032-10-ville.syrjala@linux.intel.com
Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>

drm/i915/hdmi: Make the RGB fallback for "4:2:0 only" modes the last resort

Currently we take the Hail Mary RGB fallback for "4:2:0 only" modes
already during the first pass when respect_downstream_limits==true.
It seems better to try everything else first (like ignoring TMDS
clock limits) while still preferring 4:2:0, and only if everything
else has failed fall back to RGB.

Cc: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260409101539.22032-9-ville.syrjala@linux.intel.com
Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>

drm/i915/dp: Validate sink format in .mode_valid()

Make sure the sink supports our chosen sink format. I suppose it
might be at least possible that some PCONs might not snoop the EDID
hard enough and filter out all the modes that they should.

Also if we ever want to add a similar "force DVI" knob to DP
outputs that we have for native HDMI, we'd need to manually
get rid of anything DVI sinks can't handle.

Cc: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260409101539.22032-8-ville.syrjala@linux.intel.com
Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>

drm/i915/dp: Require a HDMI sink for YCbCr output via PCON

DVI sinks can't deal with YCbCr. Make sure we have a HDMI sink connected
after the PCON before doing YCbCr 4:2:0 output.

Cc: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260409101539.22032-7-ville.syrjala@linux.intel.com
Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>

drm/i915/dp: Validate "4:2:0 also" modes twice

Currently we only validate "4:2:0 also" modes as RGB. But
if that fails we could perhaps still use the mode in with
4:2:0 output. All we have to do is retry the validation with
the different sink format.

So far we did the double validation only so far as it affects
PCON TMDS clock limits. But validating everything twice seems
a bit more sane.

Note that intel_dp_output_format() might still end up picking
RGB for the actual output format (and letting PCON deal with
the YCbCr conversion). So I suppose we could still fail the
validation due to that, and forcing even the output format
to 4:2:0 might solve it on a third try. But we'd need the
same fallback logic in intel_dp_compute_config(). For now
this seems sufficient.

v2: Pass output_format to intel_dp_mode_min_link_bpp_x16()
    Add TODO about remaining issues
    Nuke intel_dp_sink_format()

Cc: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260409101539.22032-6-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>

drm/i915/dp: Restructure the sink/output format selection

Restructure intel_dp_compute_output_format() to resemble the new
intel_hdmi_compute_output_formats().

Again, we basically have two main code paths:
- YCbCr 4:2:0 only modes
- everything else including YCbCr 4:2:0 also modes

Take the exact same approach with the DP code, making the
format selection much less convoluted.

Cc: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260409101539.22032-5-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>

drm/i915/hdmi: Restructure 4:2:0 vs. 4:4:4 mode validation

Restructure the HDMI mode validation to resemble the new
intel_hdmi_compute_formats(). Keeping the two in sync helps
to avoid different bugs in each.

The main difference between mode_valid() and
intel_hdmi_compute_formats() is that we don't want the
Hail Mary RGB fallback for "4:2:0 only" modes.

Cc: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260409101539.22032-4-ville.syrjala@linux.intel.com
Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>

drm/i915/hdmi: Restructure the sink/output format selection

intel_hdmi_compute_output_format() is a bit of a mess. Try to
restructure it into a more readable form.

Right now we basically have two main code paths:
- YCbCr 4:2:0 only modes
- everything else including YCbCr 4:2:0 also modes

Those two basically do the same two steps (try 4:2:0 and try 4:4:4)
but in opposite orders. Let's write that out in a more explicit
if-else form. And since I'm running out of function names I'll
rename the function with that high level logic into
intel_hdmi_compute_formats() and it will call (the new)
intel_hdmi_compute_output_format() with an explicit sink_format
as needed.

Cc: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260409101539.22032-3-ville.syrjala@linux.intel.com
Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>

drm/i915/hdmi: Add missing intel_pfit_mode_valid() for 4:2:0 also modes

intel_hdmi_mode_valid() is calling intel_pfit_mode_valid() only
on the first attempt (4:2:0 for "4:2:0 only" modes, 4:4:4 for
everything else). Add the call also for the "4:2:0 also" modes case
so that we actually know the pipe scaler can actually produce the
4:2:0 output.

Cc: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260409101539.22032-2-ville.syrjala@linux.intel.com
Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>

drm/i915/mst: Remove redundant has_pch_encoder=false assignment

The entire crtc_state is zeroed by default, there is no need
to fiddle with crtc_state->has_pch_encoder unless we are actually
dealing with a port on the PCH (which we never are for DP MST).

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260409100841.1907-2-ville.syrjala@linux.intel.com
Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>

drm/i915/mst: Call intel_pfit_compute_config() for sharpness filter

The sharpness filter property is on the CRTC (as opposed to the
connector) so the expectation is that it's usable on all output
types. Since the sharpness filter is now fully integrateds into
the normal pfit code intel_pfit_compute_config() must be called
from the encoder .compute_config() on all relevant output types.

Sharpness filter is supported on LNL+ so only HDMI and DP SST/MST
outputs are actually relevant. I already took care of HDMI and
DP SST, but (as usual) forgot about DP MST. Add the missing
intel_pfit_compute_config() call to make the sharpness filter
operational on DP MST as well.

Cc: Nemesa Garg <nemesa.garg@intel.com>
Fixes: d4686f34bbeb ("drm/i915/pfit: Call intel_pfit_compute_config() unconditionally on (e)DP/HDMI")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260409100841.1907-1-ville.syrjala@linux.intel.com
Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>

drm/i915/fb: Use intel_fb_needs_pot_stride_remap() in intel_fb_view_init()

Replace the open coded intel_fb_needs_pot_stride_remap() check
inside intel_fb_view_init() with the real thing.

The current check doesn't have the intel_fb_uses_dpt() in there, but
that is the only situation when we use the remapped view, and thus
was always implied.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260407155053.32156-13-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/fb: Use i915_gtt_view_is_*()

Replace the naked GTT view type checks with the new
i915_gtt_view_is_*() helpers. This isolates some of
the code from GTT view implementation details.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260407155053.32156-10-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/vma: Add helpers to check GTT view type

I915_GTT_VIEW_ROTATED is going away and being replaced by just
I915_GTT_VIEW_REMAPPED, so we're going to need another way to
determine if the view is rotated or not (since width/height
will need to be swapped when operating on the destination
coordinate space). Provide small helper functions to hide
such implementation details from most of the code using GTT views.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260407155053.32156-8-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/fb: Reject per-plane remapping with DPT

We currently create a single DPT for the entire FB, so we can't
actually do the per-plane remap. Reject it for now.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260407155053.32156-4-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/fb: Make intel_fb_needs_pot_stride_remap() static

intel_fb_needs_pot_stride_remap() isn't needed outside intel_fb.c.
Make it static.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260407155053.32156-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/fb: Nuke intel_tile_row_size()

intel_tile_row_size() is unused. Nuke it.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260407155053.32156-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

Merge tag 'topic/step-2026-04-09' of https://gitlab.freedesktop.org/drm/i915/kernel into drm-intel-next

topic/step to unify xe and i915 on common steppings header and enum

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
From: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/cc1ff0a476ff457e88251e22b83c1a45ada11ecc@intel.com

drm/i915/wm: Allow SAGV with multiple pipes on pre-icl

There was never any documented reason for limiting SAGV to
single active pipe configuration on pre-icl. Allow SAGV
with multiple active pipes.

At least my CFL NUC seems happy with this when using
multiple displays. The machine actually has working
SAGV because the memory clock can be observed changing
via SA_PERF_STATUS/mchbar:0x5918.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260324134843.2364-10-ville.syrjala@linux.intel.com
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>

drm/i915/wm: Reduce copy-pasta in skl_print_plane_wm_changes()

skl_print_plane_wm_changes() is rather ugly with the copy-pasted
massive printk arguments. Reduce the duplication a bit by defining
a few FMT/ARG macros. Still ugly, but perhaps a bit less fragile.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260324134843.2364-9-ville.syrjala@linux.intel.com
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>

drm/i915/wm: Verify 'ddb_y' as well as 'ddb'

Verify the pre-icl NV12 Y color plane DDB entry. Thus far
we've only verified the RGB/UV DDB entry.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260324134843.2364-8-ville.syrjala@linux.intel.com
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>

drm/i915/wm: Extract skl_ddb_entry_verify()

Extract the DDB entry verification to a helper function.
We'll have another caller soon.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260324134843.2364-7-ville.syrjala@linux.intel.com
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>

drm/i915/wm: Extract skl_wm_level_verify()

Reduce duplicated code by extracting the code to
verify a single WM level to a common function.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260324134843.2364-6-ville.syrjala@linux.intel.com
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>

drm/i915/wm: Verify the correct plane DDB entry

Actually verify the DDB entry for the plane we're looking
at instead of always verifying the cursor DDB.

Fixes: 7d4561722c3b ("drm/i915: Tweak plane ddb allocation tracking")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260324134843.2364-5-ville.syrjala@linux.intel.com
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>

drm/i915/wm: Consolidate SAGV pipe active/interlace checks to common code

There are no differences between the platforms when
considering whether SAGV can be used when the pipe is
inactive or using an interlaced mode. Consolidate the
checks to common code.

Note that we weren't even checking for interlaced modes
on TGL+, but since we've previously soft defeatured
interlaced modes on TGL+ that was more or less fine.
The hardware does still have the capability though,
and in case we ever decide to resurrect it having the
check seems like a good idea.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260324134843.2364-4-ville.syrjala@linux.intel.com
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>

drm/i915/wm: Don't compute separate SAGV watermarks for RKL

RKL is supposed to use the old SKL/ICL method for determining
whether the watermarks tolerate SAGV or not, not the TGL+ method.
Make it so.

BSpec: 49325
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260324134843.2364-3-ville.syrjala@linux.intel.com
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>

drm/i915/wm: Reject SAGV consistently when block_time_us==0

We have three ways for the platform to indicate that
SAGV is not supported:
- pcode returns zero block time
- pcode returns only a single QGV point (icl+)
- pcode rejects the SAGV enable/disable command (pre-icl)

We don't currently consider all those factors when computing
pipe_sagv_reject, meaning we might still try to enable
SAGV when we should not.

I think one plausible scenario is when pcode returns a
zero block time, and all the pipes are disabled. In
that case intel_crtc_can_enable_sagv() will return true
for all pipes, and thus we might try to enable SAGV
despite pcode indicating that it's not supported.

Make sure pipe_sagv_reject will consistently reject
SAGV when our cached block time is zero. That will cover
all the aforementioned mechanisms by which SAGV can be
disabled.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260324134843.2364-2-ville.syrjala@linux.intel.com
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>

drm/i915/display: switch to including common step file directly

Instead of using the proxy intel_step.h in display, just include the
common step file directly where needed. This allows us to remove the
compat intel_step.h header.

Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patch.msgid.link/83b5f13b7f863b9cbc61499bcff22af5cd822a0b.1774875688.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/xe/step: switch from enum xe_step to intel_step naming

Remove the xe_step macro, and use the enum intel_step name directly.

Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patch.msgid.link/87530eaa2052ae4a3c97c7fb87e261d1f73341a7.1774875688.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/xe/step: switch to the shared step definitions with i915

Use the shared stepping enums from include/drm/intel/step.h.

For now, define xe_step as intel_step to avoid mass renames at the same
time. For compat, we can remove the reverse macro.

Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patch.msgid.link/8173d9d753b343ba127d86277344248a6b1d0c3f.1774875688.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/dmc: Reduce wakelock hold time

__intel_dmc_wl_release() schedules delayed work which releases the DMC
wakelock after a fixed timeout of 50 ms. Until the delayed work runs,
the wakelock remains held and prevents entry into deeper DC states.

Reduce DMC_WAKELOCK_HOLD_TIME from 50 ms to 5 ms.
This should allow the system to enter deeper DC states sooner once MMIO
activity settles down.

Changes in v2:
- Drop detailed explanation from commit message
  and keep it concise (Suraj Kandpal, Luca Coelho)

Signed-off-by: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com>
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260407105102.3730973-1-dibin.moolakadan.subrahmanian@intel.com

drm/i915/dp: Don't use DP link min bpp for the FRL link bandwidth check

intel_dp_mode_min_link_bpp_x16() gives us the min bpp for the
DP link before the PCON, however intel_dp_mode_valid_downstream()
is trying to check for sufficient bandwidth on the HDMI FRL link
after the PCON. So the use of intel_dp_mode_min_link_bpp_x16() here
is incorrect.

Presumably even with FRL HDMI still can't go below 8bpc, so we should
just use that to give us the minimum required FRL bandwidth. And this
needs to account for the sink format (for 4:2:0 sub-sampling) since
that is what will be flowing over the HDMI link.

Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260407183015.16256-1-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>

Merge drm/drm-next into drm-intel-next

Backmerge to unblock a topic branch for i915 and xe.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/casf: Integrate the sharpness filter properly into the scaler code

The sharpness filter is just a special mode of the pipe scaler.
It doesn't warrant all this special casing everywhere. Just
integrate it properly into the scaler code so that it's treated
no different from the other pipe scaler uses (scaling,centering,
YCbCr 4:2:0 output).

v2: Also reject scaling_filter vs. sharpness

Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260407175244.19654-10-ville.syrjala@linux.intel.com

drm/i915/pfit: Call intel_pfit_compute_config() unconditionally on (e)DP/HDMI

We now have three different reasons for calling
intel_pfit_compute_config():
- actual pfit scaling/centering
- YCbCr 4:2:0 output
- sharpness filter

So let's just call intel_pfit_compute_config() unconditionally
from both the DP and HDMI code. Both gmch and ilk+ pfit code
should be capable of judging whether anything actually
needs the pfit.

The only slightly questionable thing in the gmch code is
the dithering knob, but that's only a thing on gen2/3 which
don't even have HDMI/DP outputs, and so not an issue here.

Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260407175244.19654-9-ville.syrjala@linux.intel.com

drm/i915/casf: Remove redundant argument from intel_casf_filter_lut_load()

intel_casf_filter_lut_load() can find the crtc from the crtc_state.
No need to pass in both.

Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260407175244.19654-8-ville.syrjala@linux.intel.com

drm/i915/casf: Constify crtc_state

Make the crtc_state const everywhere in the sharpness filter
code where it doesn't need to be mutated.

Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260407175244.19654-7-ville.syrjala@linux.intel.com

drm/i915/casf: Handle CASF in skl_scaler_get_filter_select()

Nuke the duplicate CASF_SCALER_FILTER_SELECT and just have
skl_scaler_get_filter_select() return the proper value for
sharpness filter use. It is the same "use programmable coefficients"
value we already use for the nearest neighbor filtering.

Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260407175244.19654-6-ville.syrjala@linux.intel.com

drm/i915/casf: Extract scaler_has_casf()

Extract a small helper to determine if the scaler supports
the sharpness filter or not.

Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260407175244.19654-5-ville.syrjala@linux.intel.com

drm/i915/casf: Move the casf state to better place

The casf state is placed inside the 'hw' state for some reason.
That is only really meant for things we have to duplicate from
the uapi state. The rest can live on its own in our actual state.

And since casf is just one aspect of the pfit/pipe scaler the
proper place for it seems to be under pch_pfit.

Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260407175244.19654-4-ville.syrjala@linux.intel.com

drm/i915/casf: Make a proper hw state copy of the sharpness_strength

Make a copy of the uapi.sharpness_strength property value in our hw
state. This is how we deal with having proper state for joined pipes.

Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260407175244.19654-3-ville.syrjala@linux.intel.com

drm/i915/casf: s/casf_enable/enable/

The 'casf_enable' boolean is already inside a casf specific
structure, so drop the extra 'casf_' namespace from the bool.

Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260407175244.19654-2-ville.syrjala@linux.intel.com

drm/i915/pci: move intel_pci_config.h under include/drm/intel

Since the PCI registers are used from both i915 display and core, move
intel_pci_config.h to include/drm/intel/pci_config.h. Drop the intel_
prefix from the name to reduce tautology.

With this, we can drop the corresponding xe display compat header.

v2: Rebase

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/5aac6c711c3f0a09fc52f322455a4a4b35f80a82.1775590536.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: drop unnecessary intel_pci_config.h include

There's an unnecessary include. Drop it.

Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/8323c99f379809b2973c99ebe54c21fd274d246c.1775590536.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/mchbar: move intel_mchbar_regs.h under include/drm/intel

Since the mchbar registers are used from both i915 display and core,
move intel_mchbar_regs.h to include/drm/intel/mchbar_regs.h. Drop the
intel_ prefix from the name to reduce tautology.

With this, we can drop the corresponding xe display compat header.

v2: Rebase

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/6c951b2c05db74ea517d52a3912986f7eb886422.1775590536.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/mchbar: drop unnecessary intel_mchbar_regs.h include

There are some unnecessary includes. Remove.

Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/7eaf98e648240e3011bfb85d0330787074c39205.1775590536.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/mchbar: include intel_mchbar_regs.h from intel_mchbar.h

As an exception to the rule of not including unnecessary headers from
headers, include intel_mchbar_regs.h from intel_mchbar.h. In order to
use the interfaces in intel_mchbar.h you will always have to include the
registers anyway, so the includes are in pairs everywhere. There is zero
asymmetry. Simplify.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/e44dc2daf3fc39d02c3f598c323caa3c08a54304.1775590536.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/backlight: Fix VESA backlight possible check condition

VESA backlight enable is possible when
BACKLIGHT_AUX_ENABLE_CAPABLE is true via AUX command or when
BACKLIGHT_PIN_ENABLE_CAPABLE is true via eDP connector pin.
Similarly, backlight brightness adjustment can be
done via AUX-based control or PWM pin-based control.
It means there can be three configurations:
1) Full AUX-based: Enable and adjustment both via AUX. We currently
   support this (apart from the AUX luminance-based backlight control).
2) Hybrid: Enable via the BL_ENABLE pin, adjustment via either AUX or
   PWM.
3) Fully PWM pin-based: Enable via the BL_ENABLE pin, adjustment via
   PWM.
Since that only 1 is supported as of now we need to make
sure we do not try to manipulate backlight when
BACKLIGHT_AUX_ENABLE_CAPABLE is not set.
Also fix return value when condition is not fulfilled.

Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/15907
Fixes: 0fb03890d182 ("drm/i915/backlight: Check if VESA backlight is possible")
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/20260407030710.1440046-1-suraj.kandpal@intel.com

ttm/pool: track allocated_pages per numa node.

This gets the memory sizes from the nodes and stores the limit
as 50% of those. I think eventually we should drop the limits
once we have memcg aware shrinking, but this should be more NUMA
friendly, and I think seems like what people would prefer to
happen on NUMA aware systems.

Cc: Christian Koenig <christian.koenig@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

ttm/pool: make pool shrinker NUMA aware (v2)

This enable NUMA awareness for the shrinker on the
ttm pools.

Cc: Christian Koenig <christian.koenig@amd.com>
Cc: Dave Chinner <david@fromorbit.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

ttm/pool: drop numa specific pools

The list_lru will now handle numa for us, so no need to keep
separate pool types for it. Just consolidate into the global ones.

This adds a debugfs change to avoid dumping non-existant orders due
to this change.

Cc: Christian Koenig <christian.koenig@amd.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>

ttm/pool: port to list_lru. (v2)

This is an initial port of the TTM pools for
write combined and uncached pages to use the list_lru.

This makes the pool's more NUMA aware and avoids
needing separate NUMA pools (later commit enables this).

Cc: Christian Koenig <christian.koenig@amd.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Dave Chinner <david@fromorbit.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/ttm: use gpu mm stats to track gpu memory allocations. (v4)

This uses the newly introduced per-node gpu tracking stats,
to track GPU memory allocated via TTM and reclaimable memory in
the TTM page pools.

These stats will be useful later for system information and
later when mem cgroups are integrated.

Cc: Christian Koenig <christian.koenig@amd.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: linux-mm@kvack.org
Cc: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

mm: add gpu active/reclaim per-node stat counters (v2)

While discussing memcg intergration with gpu memory allocations,
it was pointed out that there was no numa/system counters for
GPU memory allocations.

With more integrated memory GPU server systems turning up, and
more requirements for memory tracking it seems we should start
closing the gap.

Add two counters to track GPU per-node system memory allocations.

The first is currently allocated to GPU objects, and the second
is for memory that is stored in GPU page pools that can be reclaimed,
by the shrinker.

Cc: Christian Koenig <christian.koenig@amd.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: linux-mm@kvack.org
Cc: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Zi Yan <ziy@nvidia.com>
Acked-by: Shakeel Butt <shakeel.butt@linux.dev>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/i915/pin: switch to i915 core runtime pm

Remove a dependency on struct intel_display from i915 core code.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/c06366c1c6f9202be5d0b6ea649c20aba414e5bc.1775556190.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/pin: s/dev_priv/i915/ and drop struct drm_device usage

Improve consistency within i915_fb_pin.c by replacing dev_priv naming
with i915, and dropping struct drm_device usage.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/3a4ac0a732a561a487e46838bde6327cff5ccb38.1775556190.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: move intel_fb_pin.c to i915_fb_pin.c

intel_fb_pin.c is the final file in display/ that's specific to i915
only. Move it to i915 core, renaming it to i915_fb_pin.c. It'll still
depend on a lot of display stuff, unfortunately.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/ab1ffc08bcd1364715396142f91780b6261bbe65.1775556190.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/pfit: Prevent negative coordinates in center mode

When the pipe_src width or height are greater than adjusted_mode hdisplay
and vdisplay, computed x and y offsets for center mode can be negative.
Writing negative values into the pch_fit registers result in a state error.
Add a check to clamp these values so that they are never negative.

v2: Compare in terms of pipe_src width and height.[Ville]
v3: Change width/height to pipe_src_w/h in logging. [Ville]

Signed-off-by: Nemesa Garg <nemesa.garg@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260402061310.111073-1-nemesa.garg@intel.com

Merge v7.0-rc7 into drm-next

Thomas Zimmermann needs 2f42c1a61616 ("drm/ast: dp501: Fix
initialization of SCU2C") for drm-misc-next.

Conflicts:
- drivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c

Just between e927b36ae18b ("drm/amd/display: Fix NULL pointer
dereference in dcn401_init_hw()") and it's cherry-pick that confused
git.

- drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c

Deleted in 6b0a6116286e ("drm/amd/pm: Unify version check in SMUv11")
but some cherry-picks confused git. Same for v12/v14.

Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch>

drm/i915/display: Panel Replay BW optimization for DP2.0 tunneling

Unused bandwidth can be used by external display agents for Panel Replay
enabled DP panel during idleness with link on. Enable source to replace
dummy data from the display with data from another agent by programming
TRANS_DP2_CTL [Panel Replay Tunneling Enable].

v2:
- Enable pr bw optimization along with panel replay enable. [Jani]

v3:
- Write TRANS_DP2_CTL once for both bw optimization and panel replay
enable. [Jani]

v4:
- Read DPCD once in init() and store in panel_replay_caps. [Jouni]

v5:
- Avoid reading DPCD for edp. [Jouni]
- Use drm_dp_dpcd_read_byte() and some cosmetic changes. [Jani]

v6:
- Extend the corresponding interface defined in drm_dp_tunnel.c
to query the Panel Replay optimization capability. [Imre]

v7:
- Clear TRANS_DP2_PR_TUNNELING_ENABLE if pr bw optimization
is not allowed. [Jouni]
- Move intel_dp_is_edp() check. [Jouni]

Bspec: 68920
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patch.msgid.link/20260330133620.3750559-4-animesh.manna@intel.com

drm/i915/display: Add hook to check optimization support for Intel platforms

Add a hook that uses the drm core tunneling function to check
whether panel replay bandwidth optimization support is present.

v2: Move DISPLAY_VER() check to
intel_dp_tunnel_pr_optimization_supported(). [Jouni]

Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patch.msgid.link/20260330133620.3750559-3-animesh.manna@intel.com

drm/display: Add drm helper to check pr optimization support

Add api to check panel replay optimization supported or not to
drm-core DP tunneling framework which can be used by other driver
as well.

v2: Split generic drm changes from Intel specific changes. [Jouni]

Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Suggested-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Acked-by: Maarten Lankhorst <dev@lankhorst.se>
Link: https://patch.msgid.link/20260330133620.3750559-2-animesh.manna@intel.com

Linux 7.0-rc7

Merge tag 'riscv-for-linus-7.0-rc7' of git://git./linux/kernel/git/riscv/linux

Pull RISC-V fixes from Paul Walmsley:

 - Fix a CONFIG_SPARSEMEM crash on RV32 by avoiding early phys_to_page()

 - Prevent runtime const infrastructure from being used by modules,
   similar to what was done for x86

 - Avoid problems when shutting down ACPI systems with IOMMUs by adding
   a device dependency between IOMMU and devices that use it

 - Fix a bug where the CPU pointer masking state isn't properly reset
   when tagged addresses aren't enabled for a task

 - Fix some incorrect register assignments, and add some missing ones,
   in kgdb support code

 - Fix compilation of non-kernel code that uses the ptrace uapi header
   by replacing BIT() with _BITUL()

 - Fix compilation of the validate_v_ptrace kselftest by working around
   kselftest macro expansion issues

* tag 'riscv-for-linus-7.0-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
  ACPI: RIMT: Add dependency between iommu and devices
  selftests: riscv: Add braces around EXPECT_EQ()
  riscv: use _BITUL macro rather than BIT() in ptrace uapi and kselftests
  riscv: Reset pmm when PR_TAGGED_ADDR_ENABLE is not set
  riscv: make runtime const not usable by modules
  riscv: patch: Avoid early phys_to_page()
  riscv: kgdb: fix several debug register assignment bugs

Merge tag 'x86-urgent-2026-04-05' of git://git./linux/kernel/git/tip/tip

Pull x86 fixes from Ingo Molnar:

 - Fix kexec crash on KCOV-instrumented kernels (Aleksandr Nogikh)

 - Fix Geode platform driver on-stack property data use-after-return
   bug (Dmitry Torokhov)

* tag 'x86-urgent-2026-04-05' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/platform/geode: Fix on-stack property data use-after-return bug
  x86/kexec: Disable KCOV instrumentation after load_segments()

Merge tag 'sched-urgent-2026-04-05' of git://git./linux/kernel/git/tip/tip

Pull scheduler fixes from Ingo Molnar:

 - Fix zero_vruntime tracking again (Peter Zijlstra)

 - Fix avg_vruntime() usage in sched_debug (Peter Zijlstra)

* tag 'sched-urgent-2026-04-05' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  sched/debug: Fix avg_vruntime() usage
  sched/fair: Fix zero_vruntime tracking fix

Merge tag 'perf-urgent-2026-04-05' of git://git./linux/kernel/git/tip/tip

Pull perf fix from Ingo Molnar:

 - Fix potential bad container_of() in intel_pmu_hw_config() (Ian
   Rogers)

* tag 'perf-urgent-2026-04-05' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  perf/x86: Fix potential bad container_of in intel_pmu_hw_config

Merge tag 'irq-urgent-2026-04-05' of git://git./linux/kernel/git/tip/tip

Pull irq fix from Ingo Molnar:

 - Fix RISC-V APLIC irqchip driver setup errors on ACPI systems (Jessica
   Liu)

* tag 'irq-urgent-2026-04-05' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  irqchip/riscv-aplic: Restrict genpd notifier to device tree only

i915: don't use a vma that didn't match the context VM

In eb_lookup_vma(), the code checks that the context vm matches before
incrementing the i915 vma usage count, but for the non-matching case it
didn't clear the non-matching vma pointer, so it would then mistakenly
be returned, causing potential UaF and refcount issues.

Reported-by: Yassine Mounir <sosohero200@gmail.com>
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Merge tag 'mips-fixes_7.0_1' of git://git./linux/kernel/git/mips/linux

Pull MIPS fixes from Thomas Bogendoerfer:

 - Fix TLB uniquification for systems with TLB not initialised by
   firmware

 - Fix allocation in TLB uniquification

 - Fix SiByte cache initialisation

 - Check uart parameters from firmware on Loongson64 systems

 - Fix clock id mismatch for Ralink SoCs

 - Fix GCC version check for __mutli3 workaround

* tag 'mips-fixes_7.0_1' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux:
  mips: mm: Allocate tlb_vpn array atomically
  MIPS: mm: Rewrite TLB uniquification for the hidden bit feature
  MIPS: mm: Suppress TLB uniquification on EHINV hardware
  MIPS: Always record SEGBITS in cpu_data.vmbits
  MIPS: Fix the GCC version check for `__multi3' workaround
  MIPS: SiByte: Bring back cache initialisation
  mips: ralink: update CPU clock index
  MIPS: Loongson64: env: Check UARTs passed by LEFI cautiously

Merge tag 'char-misc-7.0-rc7' of git://git./linux/kernel/git/gregkh/char-misc

Pull char/misc/iio driver fixes from Greg KH:
 "Here are a relativly large number of small char/misc/iio and other
  driver fixes for 7.0-rc7. There's a bunch, but overall they are all
  small fixes for issues that people have been having that I finally
  caught up with getting merged due to delays on my end.

  The "largest" change overall is just some documentation updates to the
  security-bugs.rst file to hopefully tell the AI tools (and any users
  that actually read the documentation), how to send us better security
  bug reports as the quantity of reports these past few weeks has
  increased dramatically due to tools getting better at "finding"
  things.

  Included in here are:
   - lots of small IIO driver fixes for issues reported in 7.0-rc
   - gpib driver fixes
   - comedi driver fixes
   - interconnect driver fix
   - nvmem driver fixes
   - mei driver fix
   - counter driver fix
   - binder rust driver fixes
   - some other small misc driver fixes

  All of these have been in linux-next this week with no reported issues"

* tag 'char-misc-7.0-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (63 commits)
  Documentation: fix two typos in latest update to the security report howto
  Documentation: clarify the mandatory and desirable info for security reports
  Documentation: explain how to find maintainers addresses for security reports
  Documentation: minor updates to the security contacts
  .get_maintainer.ignore: add myself
  nvmem: zynqmp_nvmem: Fix buffer size in DMA and memcpy
  nvmem: imx: assign nvmem_cell_info::raw_len
  misc: fastrpc: check qcom_scm_assign_mem() return in rpmsg_probe
  misc: fastrpc: possible double-free of cctx->remote_heap
  comedi: dt2815: add hardware detection to prevent crash
  comedi: runflags cannot determine whether to reclaim chanlist
  comedi: Reinit dev->spinlock between attachments to low-level drivers
  comedi: me_daq: Fix potential overrun of firmware buffer
  comedi: me4000: Fix potential overrun of firmware buffer
  comedi: ni_atmio16d: Fix invalid clean-up after failed attach
  gpib: fix use-after-free in IO ioctl handlers
  gpib: lpvo_usb: fix memory leak on disconnect
  gpib: Fix fluke driver s390 compile issue
  lis3lv02d: Omit IRQF_ONESHOT if no threaded handler is provided
  lis3lv02d: fix kernel-doc warnings
  ...

Merge tag 'tty-7.0-rc7' of git://git./linux/kernel/git/gregkh/tty

Pull tty fixes from Greg KH:
 "Here are two small tty vt fixes for 7.0-rc7 to resolve some reported
  issues with the resize ability of the alt screen buffer. Both of these
  have been in linux-next all week with no reported issues"

* tag 'tty-7.0-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
  vt: resize saved unicode buffer on alt screen exit after resize
  vt: discard stale unicode buffer on alt screen exit after resize

Merge tag 'usb-7.0-rc7' of git://git./linux/kernel/git/gregkh/usb

Pull USB/Thunderbolt fixes from Greg KH:
 "Here are a bunch of USB and Thunderbolt fixes (most all are USB) for
  7.0-rc7. More than I normally like this late in the release cycle,
  partly due to my recent travels, and partly due to people banging away
  on the USB gadget interfaces and apis more than normal (big shoutout
  to Android for getting the vendors to actually work upstream on this,
  that's a huge win overall for everyone here)

  Included in here are:
   - Small thunderbolt fix
   - new USB serial driver ids added
   - typec driver fixes
   - gadget driver fixes for some disconnect issues
   - other usb gadget driver fixes for reported problems with binding
     and unbinding devices as happens when a gadget device connects /
     disconnects from a system it is plugged into (or it switches device
     mode at a user's request, these things are complex little
     beasts...)
   - usb offload fixes (where USB audio tunnels through the controller
     while the main CPU is asleep) for when EMP spikes hit the system
     causing disconnects to happen (as often happens with static
     electricity in the winter months). This has been much reported by
     at least one vendor, and resolves the issues they have been seeing
     with this codepath. Can't wait for the "formal methods are the
     answer!" people to try to model that one properly...
   - Other small usb driver fixes for issues reported.

  All of these have been in linux-next this week, and before, with no
  reported issues, and I've personally been stressing these harder than
  normal on my systems here with no problems"

* tag 'usb-7.0-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (39 commits)
  usb: gadget: f_hid: move list and spinlock inits from bind to alloc
  usb: host: xhci-sideband: delegate offload_usage tracking to class drivers
  usb: core: use dedicated spinlock for offload state
  usb: cdns3: gadget: fix state inconsistency on gadget init failure
  usb: dwc3: imx8mp: fix memory leak on probe failure path
  usb: gadget: f_uac1_legacy: validate control request size
  usb: ulpi: fix double free in ulpi_register_interface() error path
  usb: misc: usbio: Fix URB memory leak on submit failure
  USB: core: add NO_LPM quirk for Razer Kiyo Pro webcam
  usb: cdns3: gadget: fix NULL pointer dereference in ep_queue
  usb: core: phy: avoid double use of 'usb3-phy'
  USB: serial: option: add MeiG Smart SRM825WN
  usb: gadget: f_rndis: Fix net_device lifecycle with device_move
  usb: gadget: f_subset: Fix net_device lifecycle with device_move
  usb: gadget: f_eem: Fix net_device lifecycle with device_move
  usb: gadget: f_ecm: Fix net_device lifecycle with device_move
  usb: gadget: u_ncm: Add kernel-doc comments for struct f_ncm_opts
  usb: gadget: f_rndis: Protect RNDIS options with mutex
  usb: gadget: f_subset: Fix unbalanced refcnt in geth_free
  dt-bindings: connector: add pd-disable dependency
  ...

ACPI: RIMT: Add dependency between iommu and devices

EPROBE_DEFER ensures IOMMU devices are probed before the devices that
depend on them. During shutdown, however, the IOMMU may be removed
first, leading to issues. To avoid this, a device link is added
which enforces the correct removal order.

Fixes: 8f7729552582 ("ACPI: RISC-V: Add support for RIMT")
Signed-off-by: Sunil V L <sunilvl@oss.qualcomm.com>
Link: https://patch.msgid.link/20260303061605.722949-1-sunilvl@oss.qualcomm.com
Signed-off-by: Paul Walmsley <pjw@kernel.org>

selftests: riscv: Add braces around EXPECT_EQ()

EXPECT_EQ() expands to multiple lines, breaking up one-line if
statements. This issue was not present in the patch on the mailing list
but was instead introduced by the maintainer when attempting to fix up
checkpatch warnings. Add braces around EXPECT_EQ() to avoid the error
even though checkpatch suggests them to be removed:

validate_v_ptrace.c:626:17: error: ‘else’ without a previous ‘if’

Fixes: 3789d5eecd5a ("selftests: riscv: verify syscalls discard vector context")
Fixes: 30eb191c895b ("selftests: riscv: verify ptrace rejects invalid vector csr inputs")
Fixes: 849f05ae1ea6 ("selftests: riscv: verify ptrace accepts valid vector csr values")
Signed-off-by: Charlie Jenkins <thecharlesjenkins@gmail.com>
Reviewed-and-tested-by: Sergey Matyukevich <geomatsi@gmail.com>
Link: https://patch.msgid.link/20260309-fix_selftests-v2-2-9d5a553a531e@gmail.com
Signed-off-by: Paul Walmsley <pjw@kernel.org>

riscv: use _BITUL macro rather than BIT() in ptrace uapi and kselftests

Fix the build of non-kernel code that includes the RISC-V ptrace uapi
header, and the RISC-V validate_v_ptrace.c kselftest, by using the
_BITUL() macro rather than BIT().  BIT() is not available outside
the kernel.

Based on patches and comments from Charlie Jenkins, Michael Neuling,
and Andreas Schwab.

Fixes: 30eb191c895b ("selftests: riscv: verify ptrace rejects invalid vector csr inputs")
Fixes: 2af7c9cf021c ("riscv/ptrace: expose riscv CFI status and state via ptrace and in core files")
Cc: Andreas Schwab <schwab@suse.de>
Cc: Michael Neuling <mikey@neuling.org>
Cc: Charlie Jenkins <thecharlesjenkins@gmail.com>
Link: https://patch.msgid.link/20260330024248.449292-1-mikey@neuling.org
Link: https://lore.kernel.org/linux-riscv/20260309-fix_selftests-v2-1-9d5a553a531e@gmail.com/
Link: https://lore.kernel.org/linux-riscv/20260309-fix_selftests-v2-3-9d5a553a531e@gmail.com/
Signed-off-by: Paul Walmsley <pjw@kernel.org>

riscv: Reset pmm when PR_TAGGED_ADDR_ENABLE is not set

In set_tagged_addr_ctrl(), when PR_TAGGED_ADDR_ENABLE is not set, pmlen
is correctly set to 0, but it forgets to reset pmm. This results in the
CPU pmm state not corresponding to the software pmlen state.

Fix this by resetting pmm along with pmlen.

Fixes: 2e1743085887 ("riscv: Add support for the tagged address ABI")
Signed-off-by: Zishun Yi <vulab@iscas.ac.cn>
Reviewed-by: Samuel Holland <samuel.holland@sifive.com>
Link: https://patch.msgid.link/20260322160022.21908-1-vulab@iscas.ac.cn
Signed-off-by: Paul Walmsley <pjw@kernel.org>

riscv: make runtime const not usable by modules

Similar as commit 284922f4c563 ("x86: uaccess: don't use runtime-const
rewriting in modules") does, make riscv's runtime const not usable by
modules too, to "make sure this doesn't get forgotten the next time
somebody wants to do runtime constant optimizations". The reason is
well explained in the above commit: "The runtime-const infrastructure
was never designed to handle the modular case, because the constant
fixup is only done at boot time for core kernel code."

Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Link: https://patch.msgid.link/20260221023731.3476-1-jszhang@kernel.org
Signed-off-by: Paul Walmsley <pjw@kernel.org>

riscv: patch: Avoid early phys_to_page()

Similarly to commit 8d09e2d569f6 ("arm64: patching: avoid early
page_to_phys()"), avoid using phys_to_page() for the kernel address case
in patch_map().

Since this is called from apply_boot_alternatives() in setup_arch(), and
commit 4267739cabb8 ("arch, mm: consolidate initialization of SPARSE
memory model") has moved sparse_init() to after setup_arch(),
phys_to_page() is not available there yet, and it panics on boot with
SPARSEMEM on RV32, which does not use SPARSEMEM_VMEMMAP.

Reported-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Closes: https://lore.kernel.org/r/20260223144108-dcace0b9-02e8-4b67-a7ce-f263bed36f26@linutronix.de/
Fixes: 4267739cabb8 ("arch, mm: consolidate initialization of SPARSE memory model")
Suggested-by: Mike Rapoport <rppt@kernel.org>
Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn>
Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Tested-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Link: https://patch.msgid.link/20260310-riscv-sparsemem-alternatives-fix-v1-1-659d5dd257e2@iscas.ac.cn
[pjw@kernel.org: fix the subject line to align with the patch description]
Signed-off-by: Paul Walmsley <pjw@kernel.org>

riscv: kgdb: fix several debug register assignment bugs

Fix several bugs in the RISC-V kgdb implementation:

- The element of dbg_reg_def[] that is supposed to pertain to the S1
  register embeds instead the struct pt_regs offset of the A1
  register.  Fix this to use the S1 register offset in struct pt_regs.

- The sleeping_thread_to_gdb_regs() function copies the value of the
  S10 register into the gdb_regs[] array element meant for the S9
  register, and copies the value of the S11 register into the array
  element meant for the S10 register.  It also neglects to copy the
  value of the S11 register.  Fix all of these issues.

Fixes: fe89bd2be8667 ("riscv: Add KGDB support")
Cc: Vincent Chen <vincent.chen@sifive.com>
Link: https://patch.msgid.link/fde376f8-bcfd-bfe4-e467-07d8f7608d05@kernel.org
Signed-off-by: Paul Walmsley <pjw@kernel.org>

Merge tag 'input-for-v7.0-rc6' of git://git./linux/kernel/git/dtor/input

Pull input fixes from Dmitry Torokhov:

 - new IDs for BETOP BTP-KP50B/C and Razer Wolverine V3 Pro added to
   xpad controller driver

 - another quirk for new TUXEDO InfinityBook added to i8042

 - a small fixup for Synaptics RMI4 driver to properly unlock mutex when
   encountering an error in F54

 - an update to bcm5974 touch controller driver to reliably switch into
   wellspring mode

* tag 'input-for-v7.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
  Input: xpad - add support for BETOP BTP-KP50B/C controller's wireless mode
  Input: xpad - add support for Razer Wolverine V3 Pro
  Input: synaptics-rmi4 - fix a locking bug in an error path
  Input: i8042 - add TUXEDO InfinityBook Max 16 Gen10 AMD to i8042 quirk table
  Input: bcm5974 - recover from failed mode switch

Documentation: fix two typos in latest update to the security report howto

In previous patch "Documentation: clarify the mandatory and desirable
info for security reports" I left two typos that I didn't detect in local
checks. One is "get_maintainers.pl" (no 's' in the script name), and the
other one is a missing closing quote after "Reported-by", which didn't
have effect here but I don't know if it can break rendering elsewhere
(e.g. on the public HTML page). Better fix it before it gets merged.

Signed-off-by: Willy Tarreau <w@1wt.eu>
Link: https://patch.msgid.link/20260404082033.5160-1-w@1wt.eu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Input: xpad - add support for BETOP BTP-KP50B/C controller's wireless mode

BETOP's BTP-KP50B and BTP-KP50C controller's wireless dongles are both
working as standard Xbox 360 controllers. Add USB device IDs for them to
xpad driver.

Signed-off-by: Shengyu Qu <wiagn233@outlook.com>
Link: https://patch.msgid.link/TY4PR01MB14432B4B298EA186E5F86C46B9855A@TY4PR01MB14432.jpnprd01.prod.outlook.com
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: xpad - add support for Razer Wolverine V3 Pro

Add device IDs for the Razer Wolverine V3 Pro controller in both
wired (0x0a57) and wireless 2.4 GHz dongle (0x0a59) modes.

The controller uses the Xbox 360 protocol (vendor-specific class,
subclass 93, protocol 1) on interface 0 with an identical 20-byte
input report layout, so no additional processing is needed.

Signed-off-by: Zoltan Illes <zoliviragh@gmail.com>
Link: https://patch.msgid.link/20260329220031.1325509-1-137647604+ZlordHUN@users.noreply.github.com
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Merge tag 'powerpc-7.0-4' of git://git./linux/kernel/git/powerpc/linux

Pull powerpc fix from Madhavan Srinivasan:

 - fix iommu incorrectly bypassing DMA APIs

Thanks to Dan Horak, Gaurav Batra, and Ritesh Harjani (IBM).

* tag 'powerpc-7.0-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
  powerpc/powernv/iommu: iommu incorrectly bypass DMA APIs

Merge tag 's390-7.0-7' of git://git./linux/kernel/git/s390/linux

Pull s390 fixes from Vasily Gorbik:

 - Fix a memory leak in the zcrypt driver where the AP message buffer
   for clear key RSA requests was allocated twice, once by the caller
   and again locally, causing the first allocation to never be freed

 - Fix the cpum_sf perf sampling rate overflow adjustment to clamp the
   recalculated rate to the hardware maximum, preventing exceptions on
   heavily loaded systems running with HZ=1000

* tag 's390-7.0-7' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
  s390/zcrypt: Fix memory leak with CCA cards used as accelerator
  s390/cpum_sf: Cap sampling rate to prevent lsctl exception

Merge tag 'hwmon-for-v7.0-rc7' of git://git./linux/kernel/git/groeck/linux-staging

Pull hwmon fixes from Guenter Roeck:

 - Fix temperature sensor for PRIME X670E-PRO WIFI

 - occ: Add missing newline, and fix potential division by zero

 - pmbus:
    - Fix device ID comparison and printing in tps53676_identify()
    - Add missing MODULE_IMPORT_NS("PMBUS") for ltc4286
    - Check return value of page-select write in pxe1610 probe
    - Fix array access with zero-length block tps53679 read

* tag 'hwmon-for-v7.0-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging:
  hwmon: (asus-ec-sensors) Fix T_Sensor for PRIME X670E-PRO WIFI
  hwmon: (occ) Fix missing newline in occ_show_extended()
  hwmon: (occ) Fix division by zero in occ_show_power_1()
  hwmon: (tps53679) Fix device ID comparison and printing in tps53676_identify()
  hwmon: (ltc4286) Add missing MODULE_IMPORT_NS("PMBUS")
  hwmon: (pxe1610) Check return value of page-select write in probe
  hwmon: (tps53679) Fix array access with zero-length block read

Merge tag 'sched_ext-for-7.0-rc6-fixes-2' of git://git./linux/kernel/git/tj/sched_ext

Pull sched_ext fixes from Tejun Heo:
 "These are late but both fix subtle yet critical problems and the blast
  radius is limited strictly to sched_ext.

   - Fix stale direct dispatch state in ddsp_dsq_id which can cause
     spurious warnings in mark_direct_dispatch() on task wakeup

   - Fix is_bpf_migration_disabled() false negative on non-PREEMPT_RCU
     configs which can lead to incorrectly dispatching migration-
     disabled tasks to remote CPUs"

* tag 'sched_ext-for-7.0-rc6-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/sched_ext:
  sched_ext: Fix stale direct dispatch state in ddsp_dsq_id
  sched_ext: Fix is_bpf_migration_disabled() false negative on non-PREEMPT_RCU

Merge tag 'io_uring-7.0-20260403' of git://git./linux/kernel/git/axboe/linux

Pull io_uring fixes from Jens Axboe:

 - A previous fix in this release covered the case of the rings being
   RCU protected during resize, but it missed a few spots. This covers
   the rest

 - Fix the cBPF filters when COW'ed, introduced in this merge window

 - Fix for an attempt to import a zero sized buffer

 - Fix for a missing clamp in importing bundle buffers

* tag 'io_uring-7.0-20260403' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux:
  io_uring/bpf_filters: retain COW'ed settings on parse failures
  io_uring: protect remaining lockless ctx->rings accesses with RCU
  io_uring/rsrc: reject zero-length fixed buffer import
  io_uring/net: fix slab-out-of-bounds read in io_bundle_nbufs()

Merge tag 'spi-fix-v7.0-rc6' of git://git./linux/kernel/git/broonie/spi

Pull spi fixes from Mark Brown:
 "A small collection of fixes, mostly probe/remove issues that are the
  result of Felix Gu going and auditing those areas, plus one error
  handling fix for the Cadence QSPI driver"

* tag 'spi-fix-v7.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
  spi: cadence-qspi: Fix exec_mem_op error handling
  spi: amlogic: spifc-a4: unregister ECC engine on probe failure and remove() callback
  spi: stm32-ospi: Fix DMA channel leak on stm32_ospi_dma_setup() failure
  spi: stm32-ospi: Fix reset control leak on probe error
  spi: stm32-ospi: Fix resource leak in remove() callback