Add static inline stubs for init_clock_gating.h functions
so that we don't need ifdefs in the actual code. We already
have one in intel_display_power.c, and now I need to bring
over intel_display_reset.c.
Cc: Jouni Högander <jouni.hogander@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260415210411.24750-6-ville.syrjala@linux.intel.com
Only i915 uses the pending_fb_pin counter to potentially whack
the GPU harder if the display gets nuked during a GPU reset.
Move the atomic counter into the i915 specific bits of code, so
that we don't need to worry about on the display side.
For some reason the overlay code kept the pending_fb_pin counter
elevated for longer than just for the pin, but from now on it'll
just cover the actual pinning part.
Cc: Jouni Högander <jouni.hogander@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260415210411.24750-5-ville.syrjala@linux.intel.com
Stop returning the "is there a display?" status from
intel_display_reset_prepare(). I plan to move the pending_fb_pin
into the i915 code, so I need to make that determination already
before intel_display_reset_prepare() is called. Add a new
intel_display_reset_supported() function for that.
v2: Also check display!=NULL for mock tests
Cc: Jouni Högander <jouni.hogander@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260415210411.24750-4-ville.syrjala@linux.intel.com
Don't leave a stale xe->display pointer hanging around after
the display driver has been torn down.
While xe shouldn't hit the display reset related issue that
affects i915, leaving stale pointer floating around still
seems like a bad idea.
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Jouni Högander <jouni.hogander@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260415210411.24750-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Don't leave a stale i915->display pointer hanging around after
the display driver has been torn down. Apparently the gt code
calls into the reset codepaths after this, and if the display
pointer is still around we may try to access freed memory.
The whole teardown sequence here seems rather suspect. Why is
display done first and then everything else via the managed
release? Who the heck knows. Someone really needs to dig into
this stuff and figure out the proper init/cleanup sequence for
both i915 (real and mock) and xe...
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Jouni Högander <jouni.hogander@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260415210411.24750-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Changes have been introduced in Bspec regarding the Tx Swing level,
Tx pre/post coefficients. Update the Tx Swing Level and the Tx
pre/post-cursor co-effecients to incorporate these changes
v2: Updated the commit message (Suraj)
BSpec: 74493
Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260415043952.3189598-1-arun.r.murthy@intel.com
With the fb pinning stuff directly returning the fence_id
there is no longer any need for the vma parent interface.
Get rid of it.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260407170942.16515-2-ville.syrjala@linux.intel.com
Get rid of the needlessly complicated PLANE_HAS_FENCE +
intel_parent_vma_fence_id() dance by simply tracking the
fence_id directly in the plane state.
v2: Don't request the redundant fence for fbdev (Jani)
Assign *out_fence_id with '=' instead of '|=' (Sashiko,Jani)
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260407170942.16515-1-ville.syrjala@linux.intel.com
When big joiner is enabled, it reserves the adjacent pipe as the
secondary pipe. This happens without the user space knowing, and
subsequent attempts at using the CRTC with that pipe will fail. If the
user space does not have a coping mechanism, i.e. trying another CRTC,
this leads to a black screen.
Try to reduce the impact of the problem on discrete platforms by mapping
the CRTCs to pipes in order A, C, B, and D. If the user space reserves
CRTCs in order, this should trick it to using pipes that are more likely
to be available for and after joining.
Limit this to discrete platforms, which have four pipes, and no eDP, a
combination that should benefit the most with least drawbacks.
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260413081609.969342-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reject 90/270 degree rotated BIOS framebuffers in common
code. Currently skl_get_initial_plane_config() already rejects
these, but we may want to implement the missing parts there
so that skl_get_initial_plane_config() could be reused for
general plane state verification purposes.
90/270 degree rotated framebuffers require two completely
separate GGTT mappings (0 degree for the CPU, 270 degree
for the display engine), and the rest of the BIOS FB
takeover code is not prepared for that.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260410150449.9699-11-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
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>
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 d9a515867b
("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>
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>
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>
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>
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>
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>
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>
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>
Uninitialized boolean variable may cause unwanted exit from et alignment
loop. Fix this by initializing it as false.
Fixes: 681e12440d ("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
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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: d4686f34bb ("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>
Currently our crtcs are registered in pipe order, and thus
all the for_intel_crtc*() iterators walk the crtcs in pipe
order. There are a bunch of places that more or less depend
on that. Eg. during plane updates and such we want joined
pipes to be processed back-to-back to give a better chance
of an atomic update across the whole set.
When we start to register crtcs in a different order we don't
want to change the order in which the pipes get handled.
Decouple the for_each_intel_crtc*() iterators from the crtc
registration order by using a separate list which will be
sorted by the pipe rather than the crtc index.
We could probably use a simple array or something, but that
would require some kind of extra iterator variable for the
macros, and thus would require a lot more changes. Using
a linked list keeps the fallout minimal. We can look at
using a more optimal data structure later.
I also added this extra junk to the atomic state iterators:
"(__i) = drm_crtc_index(&(crtc)->base), (void)(__i)"
even though the macro itself no longer needs the "__i" iterator.
This in case the "__i" is used by the caller, and to
avoid compiler warnings if it's completely unused now.
v2: Flip the pipe comparison (Jani)
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260408155744.13326-3-ville.syrjala@linux.intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Currently the joiner primary->secondary hw state copy still happens from
the main compute_config loop alongside the primary uapi->hw state copy.
The primary uapi->hw state copy must therefore happen first, or else
we'll end up copying stale junk into the secondary.
We have a WARN in intel_atomic_check_joiner() to make sure the CRTCs
will be walked in the correct order. The plan is to reoder the CRTCs,
which would mess up the order, unless we also adjust the iterators
to keep the pipe order. The actual plan is to do both, so technically
we should be able to just remove the WARN and call it a day.
But relying on the iteration order like this is fragile and confusing,
so let's move the "nomodeset" joiner state copy into the later loop
where the "modeset" state copy is also done. The first loop having
completely finished, we are guaranteed to have up to date hw state
on the primary when we do the copy to the secondary.
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260408155744.13326-2-ville.syrjala@linux.intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
