Make the intel_fb_bo.h interfaces operated purely in base
drm_ types so that each driver (i915 and xe) doesn't have to
know about each other, or the display stuff.
v2: s/dev/drm/ (Jani)
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250206185533.32306-4-ville.syrjala@linux.intel.com
Pass the device argument as drm_device to intel_plane_fb_max_stride()
to decouple i915_gem_dumb_create() vs. the display code a bit.
xe currently doesn't even call this, but it probably should...
v2: s/dev/drm/ (Jani)
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250206185533.32306-3-ville.syrjala@linux.intel.com
Now that intel_scanout_needs_vtd_wa() is no longer used from
the gem code we can convert it to take struct intel_display.
which will help with converting the low level plane code over
as well.
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250206185533.32306-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
With the debugfs implementation moved next to the implementation, we no
longer need to expose some of the functions. Make them static.
Cc: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250207105838.179805-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Disable the minimum HBlank time only on LNL+, where this functionality
and corresponding register exists.
Bspec: 74379
Fixes: a5ebe00c2a ("drm/i915/dp: Guarantee a minimum HBlank time")
Cc: Arun R Murthy <arun.r.murthy@intel.com>
Cc: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250206164624.3185280-1-imre.deak@intel.com
Modify backlight setup function for VESA interface to take into
account the nits based luminance.
--v2
-Prefer using luminance over nits [Jani]
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Tested-by: Ben Kao <ben.kao@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250206063253.2827017-8-suraj.kandpal@intel.com
Create a function that fills in the value for
PANEL_TARGET_LUMINANCE_VALUE which helps in changing the luminance in
nits using VESA interface.
--v2
-Prefer using luminance over nits [Jani]
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Tested-by: Ben Kao <ben.kao@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250206063253.2827017-7-suraj.kandpal@intel.com
Modify vesa_get_brightness function to take into account
luminance_control_support and based on that read the appropriate
register and return the value.
--v2
-Changes since we now use luminance instead of nits
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Tested-by: Ben Kao <ben.kao@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250206063253.2827017-6-suraj.kandpal@intel.com
Check if we are capable of controlling brightness via luminance
which is dependent on PANEL_LUMINANCE_CONTROL_CAPABLE bit being set
on EDP_GENERAL_CAPABILITY_2 register.
--v2
-Prefer using luminance rather than nits [Jani]
-Fix commit message
--v3
-Fix the bit name used in commit message [Arun]
-Use correct edp_dpcd[] to check the capability [Arun]
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Tested-by: Ben Kao <ben.kao@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250206063253.2827017-5-suraj.kandpal@intel.com
eDP is supposed to use VESA interface when using revision 1.5 and above,
use Intel interface for backlight control otherwise. Add check to
use correct interface.
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Tested-by: Ben Kao <ben.kao@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250206063253.2827017-4-suraj.kandpal@intel.com
Increase the eDP display control capability size to take into
account the general capability register 703 and 704 that have
recently been added.
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250206063253.2827017-3-suraj.kandpal@intel.com
Add the eDP revision bit value for 1.5.
Spec: eDPv1.5 Table 16-5
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Tested-by: Ben Kao <ben.kao@intel.com>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250206063253.2827017-2-suraj.kandpal@intel.com
The MST intel_connector::encoder pointer is NULL if the connector hasn't
been enabled before, so it can't be used to retrieve the display
pointer. Use instead the crtc_state and drop the unused connector
parameter.
v2: Use the crtc_state and drop the unused connector parameter.
Fixes: a5ebe00c2a ("drm/i915/dp: Guarantee a minimum HBlank time")
Reported-and-tested-by: Khaled Almahallawy <khaled.almahallawy@intel.com>
Closes: https://lore.kernel.org/all/16754ee4cd21d99c1e81c5953134b496dd07630f.camel@intel.com
Reviewed-by: Khaled Almahallawy <khaled.almahallawy@intel.com> #v1
Cc: Arun R Murthy <arun.r.murthy@intel.com>
Cc: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250206001726.3021787-1-imre.deak@intel.com
Grab the GTT view for the fbdev fb pinning from
fb->normal_view.gtt instead of having and extra one on
the stack. Seems safer in case we ever put any new
information into normal GTT views.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250122151755.6928-6-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Bspec lists different VT-d guard numbers (the number of dummy
padding PTEs) for different platforms and plane types. Use those
instead of just assuming the max glk+ number for everything.
This could avoid a bit of overhead on older platforms due to
reduced padding, and it makes it easier to cross check with the
spec.
Note that VLV/CHV do not document this w/a at all, so not sure
if it's actually needed or not. Nor do we actually know how much
padding is required if it is needed. For now use the same 128
PTEs that we use for snb-bdw primary planes.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250122151755.6928-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Currently i915_gem_object_pin_to_display_plane() uses
i915_gem_object_get_tile_row_size() to calculate the tile row
size for the VT-d guard w/a. That's not really proper since
i915_gem_object_get_tile_row_size() only works for fenced BOs,
nor does it take rotation into account.
Remedy the situation by calculating the VT-d guard size in the
display code where we have more information readily available.
Although the default guard size (168 PTEs now) should cover
the more typical fb size use cases anyway, and only very large
Y/Yf-tiled framebuffers might have tile row size that exceeds it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250122151755.6928-4-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Depending on the platform and/or plane type we can get away
with a bit less alignment in the VT-d w/a. Reduce the numbers
accordingly.
Note that it's not actually clear in VLV/CHV need this w/a,
and if they do we don't actually know what kind of alignment
is sufficient. Leave the 256k alignment in place for now, but
toss in a FIXME.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250122151755.6928-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Currently we don't account for the VT-d alignment w/a in
plane->min_alignment() which means that panning inside a larger
framebuffer can still cause the plane SURF to be misaligned.
Fix the issue by moving the VT-d alignment w/a into
plane->min_alignment() itself (for the affected platforms).
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250122151755.6928-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Make the conditions easier to follow. We don't do anything for
!psr->enabled, so hoist psr->enabled check higher, avoiding all the
checks when !psr->enabled. Stop the bitwise OR abuse on booleans by
removing the temporary variable altogether.
v2: Rebase
Cc: Jouni Högander <jouni.hogander@intel.com>
Cc: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com> # v1
Link: https://patchwork.freedesktop.org/patch/msgid/20250204140518.2971530-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Going forward, struct intel_display will be the main display data
structure. Convert as much as possible of backlight code to use it.
There are some stragglers mainly around PCH checks.
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250204132423.2910978-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Switch the IS_<PLATFORM>() checks to display->platform.<platform>, and
drop a number of struct drm_i915_private pointers in the process.
While at it, replace
/* NOOP */;
with
; /* NOOP */
to avoid a checkpatch warning on misleading indentation.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250204134228.2934744-2-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Going forward, struct intel_display is the main device data structure
for display. Switch to it.
For MISSING_CASE(), log the PCI ID instead of the platform to get rid of
the i915_drv.h dependency.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250204134228.2934744-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Enabling and disabling of DMC wakelock is already coupled with enabling
and disabling of dynamic DC states, which already depend on the DMC
being properly loaded. As such, we do not need to check if we already
have a DMC payload parsed in __intel_dmc_wl_supported().
Furthermore, the presence of such a check causes inconsistencies in the
refcount if the following sequence of events happen:
1. A call to one of the register accessors from intel_de.h is done
before the DMC payload is parsed. That causes intel_dmc_wl_get() to
be called. Suppose the register offset qualifies as needing the
wakelock.
In normal circumstances, the refcount would be incremented, but,
because __intel_dmc_wl_supported() returns false, the refcount is
untouched.
2. In a separate worker thread, the DMC firmware is parsed. Parsing of
the DMC payload is finished before the corresponding
intel_dmc_wl_put() from (1) is called.
3. When in the context of (1), intel_dmc_wl_put() gets called, now we
have __intel_dmc_wl_supported() returning true and we hit the
warning, because the code doesn't expect a zero refcount.
Let's remove that check, since it is unnecessary and causes the
inconsistency illustrated above.
Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com>
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250124191250.56833-1-gustavo.sousa@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
intel_dp_mtp_tu_compute_config() conversion to use .4 fixed point didn't
take into account that intel_dp_mst_max_dpt_bpp() may return INT_MAX
when the transport limitation is not relevant. Converting INT_MAX to .4
fixed point results in -1.0, which then gets used as if it were a real
max BPP value:
i915 0000:00:02.0: [drm:intel_dp_mtp_tu_compute_config [i915]] Limiting bpp to max DPT bpp (24.0000 -> -1.0000)
i915 0000:00:02.0: [drm:intel_dp_mtp_tu_compute_config [i915]] Looking for slots in range min bpp 18.0000 max bpp -1.0000
Just return 0 for "no max DPT BPP", and handle it explicitly.
Fixes: 67782bf6e8 ("drm/i915/mst: Convert intel_dp_mtp_tu_compute_config() to .4 format")
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13624
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250204153717.2996923-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Mandate a minimum Hblank symbol cycle count between BlankingStart and
BlankingEnd in 8b/10b MST and 128b/132b mode.
v2: Affine calculation/updation of min HBlank to dp_mst (Jani)
v3: moved min_hblank from struct intel_dp to intel_crtc_state (Jani)
v4: use max/min functions, change intel_xx *intel_xx to intel_xx *xx
(Jani)
Limit hblank to 511 and accommodate BS/BE in calculated value
(Srikanth)
v5: Some spelling corrections (Suraj)
v6: Removed DP2.1 in comment as this is applicable for both DP2.1 and
DP1.4 (Suraj)
v7: crtc_state holds the logical values and the register value
computation is moved to mst_enable() (Jani)
v8: Limit max hblank to 0x10, disable min_hblank on mst_disable (Jani)
Bspec: 74379
Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250122-hblank-v9-1-90afda006685@intel.com
The Bspec has been updated to include INITIATE_PM_DMD_REQ in the set of
register offsets that require the DMC wakelock for access during DC5.
Update our table accordingly.
Bspec: 71583
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250203205941.251754-1-gustavo.sousa@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
With just the one platform independent loop left in
do_dsc_compute_compressed_bpp(), we don't really need the extra function
that is simply becoming increasingly hard to even figure out a decent
name for. Just merge the whole thing to
dsc_compute_compressed_bpp(). Good riddance to the short lived
do_dsc_compute_compressed_bpp().
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/91ae42cbdffe4938a665667955c577f887b92b9d.1738327620.git.jani.nikula@intel.com
