Imre Deak [Fri, 25 Oct 2024 16:02:52 +0000 (19:02 +0300)]
drm/i915/dp: Flush modeset commits during connector detection
Make sure that a DP connector detection doesn't happen in parallel
with an ongoing modeset on the connector. The reasons for this are:
- Besides reading the capabilities, EDID etc. the detection may change
the state of the sink (via the AUX bus), for instance by setting the
LTTPR mode or the source OUI (the latter introduced by an upcoming
patch). It's better to avoid such changes affecting an onging modeset
in any way.
- During a modeset's link training any access to DPCD registers, besides
the registers used for link training should be avoided, at least in
the LTTPR non-transparent and transparent link training modes.
Such asynchronous accesses - besides connector detection - can also
happen via the AUX device node for instance, for those a parallel
modeset will have to be avoided in a similar way to the change in this
patch. (A topic for a follow-up change.)
- The source OUI written to an eDP sink is valid only while the panel
power is enabled. A modeset on eDP will enable/disable the panel power
synchronously; this should be prevented in the middle of the connector
detection, to ensure a consistent sink state (which depends on the
source OUI) for the whole duration of detection. The panel power could
still get disabled during detection after an idle period (1 sec), this
will be prevented by the next patch.
v2: (Ville)
- s/wait_for_crtc_hw_done/wait_for_connector_hw_done
- Get drm_device using an intel_display instead of drm_i915_private ptr.
Jani Nikula [Mon, 28 Oct 2024 20:07:27 +0000 (22:07 +0200)]
drm/i915/power: convert assert_chv_phy_status() to struct intel_display
struct intel_display will replace struct drm_i915_private as the main
device pointer for display code. Switch assert_chv_phy_status() and its
callers to it. Main motivation to do just one function is to stop
passing i915 to intel_de_wait(), so its generic wrapper can be removed.
Jani Nikula [Mon, 28 Oct 2024 20:07:26 +0000 (22:07 +0200)]
drm/i915/display: convert vlv_wait_port_ready() to struct intel_display
struct intel_display will replace struct drm_i915_private as the main
device pointer for display code. Switch vlv_wait_port_ready() over to
it. The main motivation to do just one function is to stop passing i915
to intel_de_wait(), so its generic wrapper can be removed.
Jani Nikula [Mon, 28 Oct 2024 19:48:43 +0000 (21:48 +0200)]
drm/i915/display: add subplatform group for HSW/BDW ULT
Add support for defining aliases for subplatform groups, such as HSW/BDW
ULT that covers both ULT and ULX.
ULT is a special case, because we slightly abuse the ULT subplatform
both as a subplatform and group, but with the way this is defined, it
should be fairly clear.
This follows i915 core and IS_HASWELL_ULT()/IS_BROADWELL_ULT()
conventions, i.e. "is ULT" also matches ULX platforms.
Note: Pedantically, this should have been done earlier, but it's only
feasible now that we no longer have a subplatform enum and can actually
initialize multiple subplatforms.
Jani Nikula [Mon, 28 Oct 2024 19:48:41 +0000 (21:48 +0200)]
drm/i915/display: remove the display platform enum as unnecessary
The display platform enums are not really needed for anything. Remove.
Without the enum, PLATFORM_UNINITIALIZED is also no longer needed for
keeping the first enum 0. Also need to switch from sp->subplatform to
sp->pciidlist as the check for array end.
Jani Nikula [Mon, 28 Oct 2024 19:48:39 +0000 (21:48 +0200)]
drm/i915/display: add display platforms structure with platform members
Add a structure with a bitfield member for each platform and
subplatform, and initialize them in platform and subplatform descs.
The structure also contains a bitmap in a union for easier manipulation
of the bits. This, in turn, requires a bit of trickery with
INTEL_DISPLAY_PLATFORMS() to count the number of bits required for
DECLARE_BITMAP().
Jani Nikula [Mon, 28 Oct 2024 19:48:35 +0000 (21:48 +0200)]
drm/i915/display: use a macro to initialize subplatforms
Make it easier to change the underlying structures by using a macro
similar to PLATFORM() for initialization.
The subplatform names in debug logs change slightly as they now reflect
the enum rather than manually entered names. For example, RAPTORLAKE_S
rather than RPL-S.
Ville Syrjälä [Thu, 24 Oct 2024 16:53:55 +0000 (19:53 +0300)]
drm/i915/color: Convert color management code to intel_display
struct intel_display will replace struct drm_i915_private as
the main thing for display code. Convert the color management
code to use it (as much as possible at this stage).
Ville Syrjälä [Thu, 24 Oct 2024 16:53:53 +0000 (19:53 +0300)]
drm/i915/color: Pimp debugs
Include the CRTC id+name information in the color management
debug prints to help identify who is at fault. And also specify
which LUT check_lut_size() is unhappy about.
Clint Taylor [Mon, 28 Oct 2024 19:30:11 +0000 (12:30 -0700)]
drm/i915/cx0: Remove bus reset after every c10 transaction
C10 phy timeouts occur on xe3lpd if the c10 bus is reset every
transaction. Although not required by BSPEC bus resets were added for
prior platforms as a workaround. Starting with xe3_lpd this bus reset is
not necessary.
When deciding the type of the phy, add PTL support to make
sure the correct path is taken for selection of C10 PHY.
Only port A is connected C10 PHY for Pantherlake.
Suraj Kandpal [Mon, 28 Oct 2024 19:30:08 +0000 (12:30 -0700)]
drm/i915/xe3lpd: Add check to see if edp over type c is allowed
Read PICA register to see if edp over type C is possible and then
add the appropriate tables for it.
--v2
-remove bool from intel_encoder have it in runtime_info [Jani]
-initialize the bool in runtime_info init [Jani]
-dont abbreviate the bool [Jani]
--v3
-Remove useless display version check [Jani]
-change the warn on condition [Jani]
-no need for a different function for edp type c check [Jani]
-dont add register in i915_reg [Jani]
Matt Roper [Mon, 28 Oct 2024 19:30:07 +0000 (12:30 -0700)]
drm/i915/xe3lpd: Update pmdemand programming
There are some minor changes to pmdemand handling on Xe3:
- Active scalers are no longer tracked. We can simply skip the readout
and programming of this field.
- Active dbuf slices are no longer tracked. We should skip the readout
and programming of this field and also make sure that it stays 0 in
our software bookkeeping so that we won't erroneously return true
from intel_pmdemand_needs_update() due to mismatches.
- Even though there aren't enough pipes to utilize them, the size of
the 'active pipes' field has expanded to four bits, taking over the
register bits previously used for dbuf slices. Since the lower bits
of the mask have moved, we need to update our reads/writes to handle
this properly.
v2: active pipes is no longer always max 3, add in the ability to go to
4 for PTL.
v3: use intel_display for display_ver check, use INTEL_NUM_PIPES
v4: add a conditional for number of pipes macro vs using 3.
v5: reverse conditional order of v4.
v6: undo v5 and fix num_pipes assignment
v7: pass display struct instead of i915, checkpatch fix
v8: Alignment issue
Jani Nikula [Tue, 22 Oct 2024 09:41:49 +0000 (12:41 +0300)]
drm/i915/pciids: add PVC PCI ID macros
The xe PCI ID macros are a subset of the i915 PCI IDs macros, apart from
the PVC PCI IDs (naturally, because i915 does not and will not support
PVC). In preparation of using a shared file, add PVC PCI IDs to
i915_pciids.h.
Jani Nikula [Thu, 24 Oct 2024 16:25:10 +0000 (19:25 +0300)]
drm/i915/display: convert I915_STATE_WARN() to struct intel_display
Convert I915_STATE_WARN() to struct intel_display *, and rename to
INTEL_DISPLAY_STATE_WARN(). Do some minor opportunistic struct
drm_i915_private to struct intel_display conversions while at it.
v2: crtc_state may be NULL in intel_connector_verify_state()
Gustavo Sousa [Wed, 23 Oct 2024 15:33:46 +0000 (12:33 -0300)]
drm/i915/xe2lpd: Update C20 algorithm to include tx_misc
There has been an update to the BSpec in which we need to set
tx_misc=0x5 field for C20 TX Context programming for HDMI TMDS for
Xe2_LPD and newer. That field is mapped to the bits 7:0 of
SRAM_GENERIC_<A/B>_TX_CNTX_CFG_1, which in turn translates to tx[1] of
our state struct. Update the algorithm to reflect this change.
v2:
- Fix Bspec reference (Sai Teja)
- Use struct intel_display instead of drm_i915_private. (Jani)
- Use the correct bit width for C20_PHY_TX_MISC_MASK. (Jani)
Gustavo Sousa [Wed, 23 Oct 2024 15:33:45 +0000 (12:33 -0300)]
drm/i915/cx0: Pass crtc_state to intel_c20_compute_hdmi_tmds_pll()
The variable crtc_state already contains everything that
intel_c20_compute_hdmi_tmds_pll() needs. Simplify the function's
signature by passing that struct instead of separate variables.
Gustavo Sousa [Wed, 16 Oct 2024 13:52:31 +0000 (10:52 -0300)]
drm/i915/display: Cover all possible pipes in TP_printk()
Tracepoints that display frame and scanline counters for all pipes were
added with commit 1489bba82433 ("drm/i915: Add cxsr toggle tracepoint")
and commit 0b2599a43ca9 ("drm/i915: Add pipe enable/disable
tracepoints"). At that time, we only had pipes A, B and C. Now that we
can also have pipe D, the TP_printk() calls are missing it.
As a quick and dirty fix for that, let's define two common macros to be
used for the format and values respectively, and also ensure we raise a
build bug if more pipes are added to enum pipe.
In the future, we should probably have a way of printing information for
available pipes only.
Gustavo Sousa [Wed, 16 Oct 2024 13:52:30 +0000 (10:52 -0300)]
drm/i915/display: Do not use ids from enum pipe in TP_printk()
Because much of kernel tracepoints is implemented at the C preprocessor
level, C identifiers used in TP_printk() are saved verbatim in the event
format, even when they represent compile-time constant values.
As an example, we can look at the format for the intel_pipe_enable
event:
We see that PIPE_A, PIPE_B and PIPE_C are pasted directly in the format.
Because tools that interact with kernel tracepoints don't know about
those ids, they'll endup failing to parse the format or produce
corrupted output.
For example, we can see below that trace-cmd repeats PIPE_A's
frame/scanline counts for all pipes (probably because it evaluates
unknown ids as zero):
To fix that, we need a fix that looks more like a hack: use macros that
result to integer constants instead of enum pipe values. This fixes the
issue, but could break if, for whatever unlikely reason, the underlying
values in the enum are changed.
In the future, we should find a better way to handle this, but for now,
the hack took care of the job:
Gustavo Sousa [Wed, 16 Oct 2024 13:52:29 +0000 (10:52 -0300)]
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
Gustavo Sousa [Wed, 16 Oct 2024 13:52:28 +0000 (10:52 -0300)]
drm/i915/display: Zero-initialize frame/scanline counts in tracepoints
In an upcoming change, we will also add support for logging
frame/scanline counts for pipe D in relevant tracepoints.
In [1], Matt mentioned the possibility of having garbage in those counts
for pipe D on a platform containing only 3 pipes. Indeed, it has been
verified that the counts for the extra pipe would not be
zero-initialized by the tracing system.
Since it is also possible that the same would happen for a fused-off
pipe, let's go ahead and add the logic to zero-initialize the arrays
now.
Gustavo Sousa [Wed, 16 Oct 2024 13:52:27 +0000 (10:52 -0300)]
drm/i915/display: Fix out-of-bounds access in pipe-related tracepoints
Some display trace events use array members to store frame and scanline
counts for each pipe. However, those arrays are declared with 3 as the
hardcoded size, which cause out-of-bounds access when the trace event is
enabled on a platform that contains pipe D.
For example, when looking at the last 10 intel_pipe_enable events after
running IGT's testdisplay, we see the following on a MTL machine that
has pipe D available:
Jani Nikula [Mon, 30 Sep 2024 12:49:48 +0000 (15:49 +0300)]
drm/i915: remove all IS_<PLATFORM>_GT<N>() macros
There aren't many users for the IS_<PLATFORM>_GT<N>() macros, and many
of them are in fact unused. Even among the users, the platform check is
often redundant. Just remove the macros.
From DISPLAY_VER() >= 30 C20 PHY consolidated programming table of
DP and eDP been merged and now use the same rates and values. eDP
over TypeC has also been introduced.
Moreover it allows more granular and higher rates. Add new table to
represent this change.
Xe3_LPD has new max cdclk of 691200 which requires reusing the lnl table
and modify/add higher frequencies. Updating the max cdclk supported by
the platform and voltage_level determination is also updated.
There are minor changes in cdclk programming sequence compared to lnl,
where programming cd2x divider needs to be skipped. This is already handled
by the calculations in existing code.
v2: update tables
v3: xe3lpd doesn't supply the power control unit the voltage index
Ville Syrjälä [Wed, 16 Oct 2024 14:31:34 +0000 (17:31 +0300)]
drm/i915: Remove ckey/format checks from skl_update_scaler_plane()
skl_plane_check() already takes care to reject scaling when an
unsupported pixel format or color keying is used. No need to
replicate that in the scaler code.
Ville Syrjälä [Wed, 16 Oct 2024 14:31:32 +0000 (17:31 +0300)]
drm/i915/panel: Convert panel code to intel_display
struct intel_display will replace struct drm_i915_private as
the main thing for display code. Convert the panel code to
use it (as much as possible at this stage).
Ville Syrjälä [Wed, 16 Oct 2024 14:31:31 +0000 (17:31 +0300)]
drm/i915/pfit: Check pfit destination window on ILK-BDW
The ILK-BDW panel fitter has several restrictions on the
destination window size. Check for those and reject the
configuration if things aren't entirely proper.
Ville Syrjälä [Wed, 16 Oct 2024 14:31:30 +0000 (17:31 +0300)]
drm/i915/pfit: Reject cloning when using pfit on ILK-BDW
The panel fitter lives inside the pipe and so would affect all cloned
outputs. However the relevant properties (scaling mode, TV margins)
are per-connector so we could end up with a situation where each cloned
output wants a different pfit configuration. Let's just reject pfit
usage with cloning entirely.
Currently not an issue as we don't yet expose the TV margin
properties, but if/when we add those to HDMI we could end up
in this situation. For eDP/DP we don't support cloning anyyway.
Ville Syrjälä [Wed, 16 Oct 2024 14:31:29 +0000 (17:31 +0300)]
drm/i915/pfit: Check pfit minimum timings in pre-SKL
Transcoder hdisplay/vdisplay have documented minimum limits
when using the panel fitter. Enforce those limits for all
pre-SKL platforms. SKL+ handles everything in the unified
scaler code instead.
Ville Syrjälä [Wed, 16 Oct 2024 14:31:28 +0000 (17:31 +0300)]
drm/i915/pfit: Reject pfit downscaling for GMCH platforms
Gen2/3 pfit doesn't support downscaling at all, so reject it.
On i965+ downscaling is supported by the hardware (max scale
factor < 2.0), but as downscaling increases the effective
pixel rate we can't safely allow it unless
intel_crtc_compute_pixel_rate() gets fixed. Probably the
best solution would be to calculate (at least an
apporiximate) pfit destination window and use
ilk_pipe_pixel_rate() for all platforms. For now reject
downscaling on all gmch platforms.
The intel ddx has a similar check for this in userspace,
modesetting ddx does not. And presumably wayland compositors
also do not make such assumptions in userspace.
Ville Syrjälä [Wed, 16 Oct 2024 14:31:27 +0000 (17:31 +0300)]
drm/i915/pfit: Check pfit scaling factors on ILK-BDW
Make sure we're not exceeding the max scaling factors for the panel
fitter on ILK-BDW. SKL+ is skipped here since this is all supposed to
be handled by the unified scaler code.
Ville Syrjälä [Wed, 16 Oct 2024 14:31:26 +0000 (17:31 +0300)]
drm/i915/pfit: Check pipe source size against pfit limits on ILK-BDW
The ILK-BDW panel fitter imposes extra limits on the maximum
pipe source size we can use. Check for that.
Only HSW/BDW are really affected by this since on older platforms
the max hdisplay/vdisplay matches the max PIPESRC. But we'll
put in the limits for all the platforms just to keep things
clear.
Note that pch_panel_fitting() is also used on SKL+, but we'll
skip the checks for those as it's all supposed to be handled
in the unified scaler code.
drm/i915/display: Remove kstrdup_const() and kfree_const() usage
kstrdup_const() and kfree_const() can be confusing in code built as a
module. In such a case, it does not do what one could expect from the name
of the functions.
The code is not wrong by itself, but in such a case, it is equivalent to
kstrdup() and kfree().
So, keep thinks simple and straightforward.
This reverts commit 379b63e7e682 ("drm/i915/display: Save a few bytes of
memory in intel_backlight_device_register()")
Jani Nikula [Mon, 30 Sep 2024 13:53:42 +0000 (16:53 +0300)]
drm/i915/gvt: use macros from drm_dp.h instead of duplication
Use the existing macros in drm_dp.h for DPCD and DP AUX instead of
duplicating. Remove unused macros, as well as the duplicate definition
of DPCD_SIZE.
AUX_NATIVE_REPLY_NAK is left unchanged, as it does not match
DP_AUX_NATIVE_REPLY_NACK, and I'm not sure what the right thing to do is
here.
Jani Nikula [Tue, 22 Oct 2024 08:09:43 +0000 (11:09 +0300)]
drm/xe: fix build failure originating from backmerge
../drivers/gpu/drm/xe/display/xe_display.c: In function ‘xe_display_pm_shutdown’:
../drivers/gpu/drm/xe/display/xe_display.c:382:27: error: passing argument 1 of ‘intel_dmc_suspend’ from incompatible pointer type [-Werror=incompatible-pointer-types]
382 | intel_dmc_suspend(xe);
| ^~
| |
| struct xe_device *
In file included from ../drivers/gpu/drm/xe/display/xe_display.c:24:
../drivers/gpu/drm/i915/display/intel_dmc.h:22:46: note: expected ‘struct intel_display *’ but argument is of type ‘struct xe_device *’
22 | void intel_dmc_suspend(struct intel_display *display);
| ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
Alan Previn [Wed, 16 Oct 2024 00:16:58 +0000 (17:16 -0700)]
drm/i915/pxp: Add missing tag for Wa_14019159160
Add missing tag for "Wa_14019159160 - Case 2" (for existing
PXP code that ensures run alone mode bit is set to allow
PxP-decryption.
v5: - remove the max IP_VER check since new platforms that
i915 supports needs this fix and tag the caller too
(John Harrison).
v4: - Include IP_VER 12.71. (Matt Roper)
v3: - Check targeted platforms using IP_VAL. (John Harrison)
v2: - Fix WA id number (John Harrison).
- Improve comments and code to be specific
for the targeted platforms (John Harrison)
Underrun recovery was defeatured and was never brought into usage.
Thus we can remove the underrun recovery interrupt/reporting
register bits and related logic introduced to detect/report soft,
hard, port underruns.
Essentially this is a revert of the commit 8bcc0840cf7c
("drm/i915/xelpd: Enhanced pipe underrun reporting") which originally
added this functionality. Also note that PIPE_STATUS_UNDERRUN bit in
PIPESTATUS still stays relevant but we would move back to not
clearing this sticky bit as we are not using any information from
this register.
v2: Extend commit message to add more details (Matt Roper)
v3: Fix the old commit mention in commit message
Arnd Bergmann [Tue, 15 Oct 2024 15:21:48 +0000 (15:21 +0000)]
i915: fix DRM_I915_GVT_KVMGT dependencies
Depending on x86 and KVM is not enough, as the kvm helper functions
that get called here are controlled by CONFIG_KVM_X86, which is
disabled if both KVM_INTEL and KVM_AMD are turned off.
Shuicheng Lin [Wed, 16 Oct 2024 15:01:54 +0000 (15:01 +0000)]
drm/i915/dp: Fix memory leak in parse_lfp_panel_dtd()
The function parse_lfp_panel_dtd() is called when the driver
attempts to initialize the eDP connector, and it allocates memory,
which is recorded in panel->vbt.lfp_vbt_mode. However, since no
eDP panel is connected, the driver fails at intel_edp_init_dpcd()
and follows the failure path. Unfortunately, the allocated memory
is not freed in this case.
To fix this issue, free the memory in the failure path.
Animesh Manna [Thu, 10 Oct 2024 04:05:03 +0000 (09:35 +0530)]
drm/i915/panelreplay: Panel replay workaround with VRR
Panel Replay VSC SDP not getting sent when VRR is enabled
and W1 and W2 are 0. So Program Set Context Latency in
TRANS_SET_CONTEXT_LATENCY register to at least a value of 1.
The same is applicable for PSR1/PSR2 as well.
v1: Initial version.
v2: Update timings stored in adjusted_mode struct. [Ville]
v3: Add WA in compute_config(). [Ville]
v4:
- Add DISPLAY_VER() check and improve code comment. [Rodrigo]
- Introduce centralized intel_crtc_vblank_delay(). [Ville]
v5: Move to crtc_compute_config(). [Ville]
v6: Restrict DISPLAY_VER till 14. [Mitul]
v7:
- Corrected code-comment. [Mitul]
- dev_priv local variable removed. [Jani]
v8: Introduce late_compute_config() which will take care late
vblank-delay adjustment. [Ville]
v9: Implementation simplified and split into multiple patches.
v10:
- Split vrr changes and use struct intel_display in DISPLAY_VER(). [Ankit]
- Use for_each_new_intel_connector_in_state(). [Jani]
v11: Remove loop and use flipline instead of vrr.enable flag. [Ville]
v12:
- Use intel_Vrr_possible helper.
- Correct flag check for flipline.
v13:
- Refactor workaround [Jonathan]
- Drop the comment around woraround number. [Ville]
Animesh Manna [Thu, 10 Oct 2024 04:05:02 +0000 (09:35 +0530)]
drm/i915/vrr: Split vrr-compute-config in two phases
As vrr guardband calculation is dependent on modified
vblank start so better to compute late after all
vblank adjustement.
v1: Initial version.
v2: Split in a separate patch from panel-replay workaround. [Ankit]
v3: Add a function for late vrr related computation. [Ville]
v4: Use flipline instead of vrr.enable and some cosmetic changes. [Ville]
v5: Use intel_vrr_possible helper.
Currently workaround is not applied when vblank is enabled on crtc that
needs the workaround if vblank is already enabled for another crtc that
doesn't need the workaround. Fix this by increasing counter only if crtc
needs the workaround.
Jouni Högander [Wed, 9 Oct 2024 13:42:24 +0000 (16:42 +0300)]
drm/i915/display: Add own counter for Panel Replay vblank workaround
We are about to change meaning of vblank_enabled to fix Panel Replay vblank
workaround. For sake of clarity we need to rename it. Vblank_enabled is
used for i915gm/i945gm vblank irq workaround as well -> instead of rename
add new counter named as vblank_wa_pipes.
v2:
- s/vblank_wa_pipes/vblank_wa_num_pipes/
- use int as a type for the counter
Imre Deak [Wed, 9 Oct 2024 11:01:35 +0000 (14:01 +0300)]
drm/i915/dp_mst: Don't require DSC hblank quirk for a non-DSC compatible mode
If an MST branch device doesn't support DSC for a given mode, but the
MST link has enough BW for the mode, assume that the branch device does
support the mode using an uncompressed stream.
Matt Roper [Thu, 10 Oct 2024 22:43:04 +0000 (15:43 -0700)]
drm/i915/xe3lpd: Add new display power wells
Xe3's power well handling is similar to previous platforms, but there
are a few changes that need to be handled to ensure optimal power
management:
- PGB now only depends on PG1, not PG2
- Transcoder B is now in PG1 (was previously in PGB)
- Transcoders C & D are now in PG2 (were previously in PGC/PGD)
- DC states now require PG2 to be off (whereas on Xe2 it could remain
on as a dependency of PGB, although the features inside of it could
not be used).
Clint Taylor [Thu, 10 Oct 2024 22:43:02 +0000 (15:43 -0700)]
drm/i915/xe3lpd: reuse xe2lpd definition
xe3_lpd display is functionally identical to xe2_lpd for now so reuse
the device description. A separate xe3 definition will be added in the
future if/when new feature flags are required.
projects / linux.git / log