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>
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>
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: 0fb03890d1 ("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
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
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
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
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
Move the driver specific fbdev fb calls to the display parent
interface. Reuse the existing struct intel_display_bo_interface, as this
is mostly about gem objects.
Put everything behind IS_ENABLED(CONFIG_DRM_FBDEV_EMULATION) to catch
configuration issues at build or link time.
v2: Rebase
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> # v1
Link: https://patch.msgid.link/a6bb24909a58181cfc41b91a4c6538a181d27158.1774950508.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The struct drm_device *drm parameter of intel_fbdev_fb_fill_info() is
redundant, as you can obtain the same information via obj->dev. Drop the
drm parameter, and move obj as first (or the context) parameter.
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Link: https://patch.msgid.link/6c617dc41c07b0e3e9af01b82d0d1dadbd4760fc.1774950508.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Unify the behaviour with i915. Similar to commit b63c6b9b7f
("drm/i915/fbdev: fix link failure without FBDEV emulation"). The
difference is that unlike i915, xe doesn't build
display/intel_fbdev_fb.c conditional to CONFIG_DRM_FBDEV_EMULATION.
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Link: https://patch.msgid.link/245880a591fe5267a1c06bfbbcc42a4dd9f2e4ee.1774950508.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
This far using crtc_state->pipe_src as borders for Selective Update area
haven't caused visible problems as drm_rect_width(crtc_state->pipe_src) ==
crtc_state->hw.adjusted_mode.crtc_hdisplay and
drm_rect_height(crtc_state->pipe_src) ==
crtc_state->hw.adjusted_mode.crtc_vdisplay when pipe scaling is not
used. On the other hand using pipe scaling is forcing full frame updates and all the
Selective Update area calculations are skipped. Now this improper usage of
crtc_state->pipe_src is causing following warnings:
<4> [7771.978166] xe 0000:00:02.0: [drm] drm_WARN_ON_ONCE(su_lines % vdsc_cfg->slice_height)
after WARN_ON_ONCE was added by commit:
"drm/i915/dsc: Add helper for writing DSC Selective Update ET parameters"
These warnings are seen when DSC and pipe scaling are enabled
simultaneously. This is because on full frame update SU area is improperly
set as pipe_src which is not aligned with DSC slice height.
Fix these by creating local rectangle using
crtc_state->hw.adjusted_mode.crtc_hdisplay and
crtc_state->hw.adjusted_mode.crtc_vdisplay. Use this local rectangle as
borders for SU area.
Fixes: d6774b8c3c ("drm/i915: Ensure damage clip area is within pipe area")
Cc: <stable@vger.kernel.org> # v6.0+
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patch.msgid.link/20260327114553.195285-1-jouni.hogander@intel.com
Replace the naked intel_uncore_read*() with intel_de_read*()
in the MCHBAR code.
v2: Rebase due to intel_uncore_read64_2x32()
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260331154259.24600-12-ville.syrjala@linux.intel.com
intel_de_read64_2x32_volatile() is a complex beast because
it needs to deal with volatile register values. For simpler
cases we can simply do a pair normal intel_de_read()s.
My main reason for hating overuse of intel_de_read64_2x32_volatile()
is that it makes register tracepoints confusing. It always
does three accesses in the somewhat weird udw,ldw,udw order,
confusing the reader of the trace. Much more clear if we just
observe the two reads in the natural little endian order.
We also have no non-volatile use case where the LDW and UDW
are stored in non-consecutive registers, so we can just pass
along a single register offset.
v2: Put the function arguments on one line (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/20260331154259.24600-10-ville.syrjala@linux.intel.com
The raison d'etre of intel_de_read64_2x32() is that it can
handle registers where volatile values are split across two
registers. I don't like that it's being used needlessly.
Rename it to intel_de_read64_2x32_volatile() to make it
more clear when it should be used.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260331154259.24600-9-ville.syrjala@linux.intel.com
We'll need a replacement for intel_uncore_read16() in order to
untangle intel_mchbar_read16() from uncore. As with the 8 bit
counterpart this doesn't need to work on modern platforms
so we can forgo all the DMC wakelock stuff and whatnot.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260331154259.24600-8-ville.syrjala@linux.intel.com
Replace all the naked intel_uncore_read*() accesses to MCHBAR
registers with the dedicated intel_mchbar_read*().
v2: Rebase due to the intel_mchbar_read64_2x32() rename
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260331154259.24600-7-ville.syrjala@linux.intel.com
We are doing a few accesses to MCHBAR registers with intel_de_read().
Use the dedicated intel_mchbar_read() instead.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260331154259.24600-6-ville.syrjala@linux.intel.com
The intel_mchbar_read*() functions should only be used for
accessing MCHBAR registers. Warn if someone tries to use
them for other registers.
I suppose we could even have a dedicated type for MCHBAR
registers. But that is true for many other special register
types as well, and so far we haven't bothered adding any
special types apart from i915_mcr_reg_t.
v2: Print the register offset (Jani)
Mention i915_mcr_reg_t (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/20260331154259.24600-5-ville.syrjala@linux.intel.com
MCHBAR registers are a bit special in that:
- we access them through the mirror
- the mirror is read only on HSW+
- the mirror requires the actual MCHBAR to be enabled in device 0:0.0
- the mirror is gone on MTL+
So I'd prefer to treat MCHBAR registers as a bit special in
the code as well, and do all accesses to them via dedicated
functions. Prodive such functions in the form of
intel_mchbar_read*().
v2: Put the function arguments on one line
No intel_uncore_read64() on xe, use intel_uncore_read64_2x32()
Name the new function intel_mchbar_read64_2x32() as well
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260331154259.24600-3-ville.syrjala@linux.intel.com
Move vlv_iosf_sb_reg.h to include/drm/intel/vlv_iosf_sb_regs.h. Use
_regs.h suffix to align better with other register headers. Move enum
vlv_iosf_sb_unit there as well, breaking the final include tie related
to IOSF sideband between display and i915 core.
With this, we can completely remove the xe compat vls_iosf_sb*.h
headers.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/41b060b0d6453de39ca775eab10ee12b25c45b7d.1774957233.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Convert the VLV sideband static inline wrappers into real
functions. This will help the follow-up work of moving the VLV sideband
to the display parent interface.
The downside is that we'll have to build vlv_sideband.c as part of xe
build, to avoid a plethora of stubs.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/57740dc3a820cb5fc1cfcd28e4be58b2cb48020d.1774957233.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Implement the POST_LT_ADJ_REQ sequence, which should be used
to further fine tune the link if TPS4 is not supported.
The POST_LT_ADJ_REQ sequence will be performed after
the normal link training has succeeded.
Only the final hop between the last LTTPR and DPRX will
perform the POST_LT_ADJ_REQ adjustment. The earlier hops
will use TPS4 instead since it's mandatory for LTTPRs.
The sequence will terminate when the sink clears the
"in progress" flag, the vswing/pre-emphasis values have
changed six times, or the vswing/pre-emphasis values have
remained unchanged for 200 ms.
Tested-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260330202629.28616-2-ville.syrjala@linux.intel.com
The pipe_src dump doesn't really fit in with the rest
of the guys (pixel_rate, port_clock, min_cdclk) included
on the same line. Split pipe_src onto its own line,
next to the related pfit stuff.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260325135849.12603-4-ville.syrjala@linux.intel.com
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Looks like I missed the drm_dp_enhanced_frame_cap() in the ivb/hsw CPU
eDP code when I introduced crtc_state->enhanced_framing. Fix it up so
that the state we program to the hardware is guaranteed to match what
we computed earlier.
Cc: stable@vger.kernel.org
Fixes: 3072a24c77 ("drm/i915: Introduce crtc_state->enhanced_framing")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260325135849.12603-3-ville.syrjala@linux.intel.com
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Apparently I forgot about the pipe min_voltage_level when I
decoupled the CDCLK calculations from modesets. Even if the
CDCLK frequency doesn't need changing we may still need to
bump the voltage level to accommodate an increase in the
port clock frequency.
Currently, even if there is a full modeset, we won't notice the
need to go through the full CDCLK calculations/programming,
unless the set of enabled/active pipes changes, or the
pipe/dbuf min CDCLK changes.
Duplicate the same logic we use the pipe's min CDCLK frequency
to also deal with its min voltage level.
Note that the 'allow_voltage_level_decrease' stuff isn't
really useful here since the min voltage level can only
change during a full modeset. But I think sticking to the
same approach in the three similar parts (pipe min cdclk,
pipe min voltage level, dbuf min cdclk) is a good idea.
Cc: stable@vger.kernel.org
Tested-by: Mikhail Rudenko <mike.rudenko@gmail.com>
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15826
Fixes: ba91b9eecb ("drm/i915/cdclk: Decouple cdclk from state->modeset")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260325135849.12603-2-ville.syrjala@linux.intel.com
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Enable PIPEDMC_ERROR interrupt bit for display version 35+.
Changes in v2:
- Move PIPEDMC_ERROR interrupt enable to a separate patch (Ville Syrjala)
Changes in v3:
- Add Bspec reference (Suraj Kandpal)
Changes in v4:
- Add TODO to check the enablement of PIPEDMC_ERROR for PTL (Suraj Kandpal)
Changes in v5:
- Move TODO to the beginning of pipedmc_interrupt_mask() (Suraj Kandpal)
Bspec: 70296
Signed-off-by: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260327064453.2241523-3-dibin.moolakadan.subrahmanian@intel.com
On display version 35+ PIPEDMC_ATS_FAULT and
PIPEDMC_GTT_FAULT interrupt bits are no longer defined.
Update the interrupt mask to drop these.
Changes in v2:
- Move PIPEDMC_ERROR interrupt enable to a separate patch (Ville Syrjala)
Changes in v3:
- Add Bspec reference (Suraj Kandpal)
Changes in v4:
- Move bspec position in commit message(Suraj Kandpal)
Bspec: 70296
Signed-off-by: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260327064453.2241523-2-dibin.moolakadan.subrahmanian@intel.com
Hi Dave and Sima,
Here goes our late, final drm-xe-next PR towards 7.1. We just purgeable
BO uAPI in today, hence the late pull.
In the big things we have:
- Add support for purgeable buffer objects
Thanks,
Matt
UAPI Changes:
- Add support for purgeable buffer objects (Arvind, Himal)
Driver Changes:
- Remove useless comment (Maarten)
- Issue GGTT invalidation under lock in ggtt_node_remove (Brost, Fixes)
- Fix mismatched include guards in header files (Shuicheng)
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/acX4fWxPkZrrfwnT@gsse-cloud1.jf.intel.com
We're mixing up the GT FIFO debug checks (overflows and such)
with RMbus unclaimed register checks. The two are quite different
things as RMbus is only relevant for display registers, and the
GT FIFO only relevant for GT registers.
Split the GT FIFO debugs out from the unclaimed register logic
and just do the checks during forcewake_get() and early init.
That is still sufficient to detect if any errors have happened.
Any errors would anyway be caused by overflowing the FIFO
rather than accessing specific registers, so trying to figure
out exactly when the error happened isn't particularly useful.
To fix such issues we'd rather have to do something to slow down
the rate at which registers are accessed (eg. increase
GT_FIFO_NUM_RESERVED_ENTRIES or something).
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260323101609.8391-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
The live_forcewake_domains selftest doesn't really test anything
particularly sensible. It only runs on platforms that have RMbus
unclaimer error detection, but that only catches display registers
which the test doesn't even access.
I suppose if we really wanted to we might try to make the test
exercise the GT FIFO instead by writing GT registers as fast
as possible, and then checking GTFIFODBG to see if the FIFO has
overflowed. But dunno if there's much point in that. I think a
GT FIFO overflow might even be fatal to the machine.
So in its current for the test doesn't really make sense,
and it's in the way of moving all the RMbus noclaim stuff
to the display driver side. So let's just get rid of it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260323101609.8391-2-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
TGL/ADL DSI can be configured to place the clock lane into
LP state during LPM, if otherwise configured for continuous
HS clock.
Hook that up. VBT tells us whether this should be done.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260326111814.9800-6-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
TGL/ADL DSI can be configured to fill all BLLPs with blanking
packets. Currently we enable that always, but the VBT actually
tells us whether this is desired or not. Hook that up.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260326111814.9800-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
