Jouni Högander [Thu, 28 Mar 2024 14:19:27 +0000 (16:19 +0200)]
drm/i915/psr: Enable ALPM on source side for eDP Panel replay
Enable ALPM AUX-Less on source side for Panel Replay eDP. Also write all
calculated AUX-Less configuration values accordingly. Enabling it on sink
side is in upcoming patch.
Bspec: 71477
v5:
- mention enable is only on source side in commit message
v4:
- add comment explaining why AUX less is enabled on eDP panel replay
without any extra checks
v3:
- do not use alpm_ctl as uninitialized variable
v2:
- do not set AUX-Wake related bits for AUX-Less case
- drop switch to active latency
- add SLEEP_HOLD_TIME_50_SYMBOLS
- add PORT_ALPM_CTL_MAX_PHY_SWING_HOLD
Jouni Högander [Thu, 28 Mar 2024 14:19:26 +0000 (16:19 +0200)]
drm/i915/psr: Silence period and lfps half cycle
Add get function for silence period and lfps half cycle. Values are taken
from the tables in bspec.
Bspec: 71632
v3:
- use PORT_ALPM_CTL_SILENCE_PERIOD_MASK instead of value 255
- use PORT_ALPM_LFPS_CTL_LAST_LFPS_HALF_CYCLE_DURATION_MASK instead of
value 31
v2:
- fix some checks
- add some more comments
Jouni Högander [Thu, 28 Mar 2024 14:19:25 +0000 (16:19 +0200)]
drm/i915/psr: Calculate aux less wake time
Calculate aux less wake time and store it into alpm_params struct
Bspec: 71477
v4:
- re-use fast_wake_lines to store aux_less_wake_lines
v3:
- use ALPM_CTL_AUX_LESS_WAKE_TIME_MASK instead of value 63
v2:
- use variables instead of values directly
- fix max value
- move converting port clock to Mhz into _lnl_compute_aux_less_wake_time
Jani Nikula [Thu, 21 Mar 2024 16:18:56 +0000 (18:18 +0200)]
drm/i915/display: move dmc_firmware_path to display params
The dmc_firmware_path parameter is clearly a display parameter. Move it
there so it's available to both i915 and xe modules. This also cleans up
the ugly member in struct xe_device.
Jani Nikula [Thu, 28 Mar 2024 10:24:55 +0000 (12:24 +0200)]
drm/i915: use fine grained -Woverride-init disable
Use localized __diag_push(), __diag_ignore_all() with rationale, and
__diag_pop() for specific initializations instead of blanket disabling
of -Woverride-init across several files.
Note that we've tried this before with commit 88e9664434c9 ("drm/i915:
use localized __diag_ignore_all() instead of per file") and reverted in
commit 290d16104575 ("Revert "drm/i915: use localized
__diag_ignore_all() instead of per file""). The issue turned out to be
in __diag_ignore_all() and it was fixed by commit 689b097a06ba
("compiler-gcc: Suppress -Wmissing-prototypes warning for all supported
GCC"). So we should be able to pull this off now.
Ankit Nautiyal [Tue, 5 Mar 2024 05:44:43 +0000 (11:14 +0530)]
drm/i915/dp: Fix the computation for compressed_bpp for DISPLAY < 13
For DISPLAY < 13, compressed bpp is chosen from a list of
supported compressed bpps. Fix the condition to choose the
appropriate compressed bpp from the list.
Fixes: 1c56e9a39833 ("drm/i915/dp: Get optimal link config to have best compressed bpp") Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: <stable@vger.kernel.org> # v6.7+ Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10162 Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240305054443.2489895-1-ankit.k.nautiyal@intel.com
Currently we are not aligning selective update area to cover cursor fully
when cursor is not updated by itself but still in the selective update
area. Fix this by checking cursor separately after
drm_atomic_add_affected_planes.
Jouni Högander [Tue, 19 Mar 2024 12:33:24 +0000 (14:33 +0200)]
drm/i915/psr: Move writing early transport pipe src
Currently PIPE_SRCSZ_ERLY_TPT is written in
intel_display.c:intel_set_pipe_src_size. This doesn't work as
intel_set_pipe_src_size is called only on modeset.
Jouni Högander [Tue, 19 Mar 2024 12:33:23 +0000 (14:33 +0200)]
drm/i915/psr: Calculate PIPE_SRCSZ_ERLY_TPT value
When early transport is enabled we need to write PIPE_SRCSZ_ERLY_TPT on
every flip doing selective update. This patch calculates
PIPE_SRCSZ_ERLY_TPT same way as is done for PSR2_MAN_TRK_CTL value and
stores i in intel_crtc_state->pipe_srcsz_early_tpt to be written later
during flip.
Lucas De Marchi [Mon, 25 Mar 2024 14:47:28 +0000 (07:47 -0700)]
drm/i915: Delete stray .rej file
drivers/gpu/drm/i915/gt/intel_workarounds.c.rej was incorrectly added to
the tree after solving a conflict. Remove it.
Fixes: 326e30e4624c ("drm/i915: Drop dead code for pvc") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Closes: https://lore.kernel.org/r/20240325083435.4f970eec@canb.auug.org.au Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240325144728.537855-1-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Gareth Yu [Thu, 21 Mar 2024 04:53:11 +0000 (12:53 +0800)]
drm/i915/backlight: Do not bump min brightness to max on enable
Historically the expectation was to set brightness to max on enable, if
it was zero. However, the policy should be to preserve brightness across
disable/enable, for example the userspace might want to dim the
brightness before disable (e.g. on suspend) and gradually bring it back
up after enable (e.g. on resume). If the brightness gets bumped to max
at enable, this causes flicker as the userspace expects the brightness
to have been preserved across disable/enable.
Reduce the check to respecting the minimum brightness, and avoid bumping
min brightness to max on enable.
Note: It's possible there's still userspace out there that relies on the
old behaviour. It would be unfortunate, but there's really only one way
to find out.
Cc: Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Gareth Yu <gareth.yu@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com>
[Jani: Rewrote the commit message.] Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240321045311.2124111-1-gareth.yu@intel.com
Ville Syrjälä [Tue, 19 Mar 2024 09:24:43 +0000 (11:24 +0200)]
drm/i915/bios: Use the platform's port_mask when there is no VBT
When we have no VBT we currently assume ports A-F are
all pontially valid for every platform. That is nonsense.
Grab the bitmask of valid ports from the runtime info
instead.
Although the defaults we actually fill here look semi-sensible
only for hsw-skl era hardware. Dunno if we should try to do
something more appropriate here for other platforms,
or just try to nuke the whole thing?
Ville Syrjälä [Mon, 25 Mar 2024 17:57:38 +0000 (19:57 +0200)]
drm/i915: Pre-populate the cursor physical dma address
Calling i915_gem_object_get_dma_address() from the vblank
evade critical section triggers might_sleep().
While we know that we've already pinned the framebuffer
and thus i915_gem_object_get_dma_address() will in fact
not sleep in this case, it seems reasonable to keep the
unconditional might_sleep() for maximum coverage.
So let's instead pre-populate the dma address during
fb pinning, which all happens before we enter the
vblank evade critical section.
We can use u32 for the dma address as this class of
hardware doesn't support >32bit addresses.
Lucas De Marchi [Wed, 20 Mar 2024 06:03:03 +0000 (23:03 -0700)]
drm/i915: Remove special handling for !RCS_MASK()
With both XEHPSDV and PVC removed (as platforms, most of their code
remain used by others), there's no need to handle !RCS_MASK() as
other platforms don't ever have fused-off render. Remove those code
paths and the special WA flag when initializing GuC.
Lucas De Marchi [Wed, 20 Mar 2024 06:03:01 +0000 (23:03 -0700)]
drm/i915: Update IP_VER(12, 50)
With no platform using graphics/media IP_VER(12, 50), replace the
checks throughout the code with IP_VER(12, 55) so the code makes sense
by itself with no additional explanation of previous baggage.
Lucas De Marchi [Wed, 20 Mar 2024 06:03:00 +0000 (23:03 -0700)]
drm/i915: Stop inheriting IP_VER(12, 50)
All the platforms that inherit the media/graphics version
from XE_HPM_FEATURES / XE_HP_FEATURES just override it to another
version. Just set the version directly in the respective struct
and remove the versions from the _FEATURES macros. Since that was the
only use for XE_HPM_FEATURES, remove it completely.
Lucas De Marchi [Wed, 20 Mar 2024 06:02:58 +0000 (23:02 -0700)]
drm/i915: Drop dead code for xehpsdv
PCI IDs for XEHPSDV were never added and platform always marked with
force_probe. Drop what's not used and rename some places to either be
xehp or dg2, depending on the platform/IP checks.
Ville Syrjälä [Thu, 21 Mar 2024 16:18:05 +0000 (18:18 +0200)]
drm/i915/bios: Define the (obsolete) backlight i2c VBT stuff
The VBT backlight entries include various fields for i2c
controlled backlights. These have been obsoleted at some
unknown point in time, but let's define them anyway so that
we have a full picture of what has been in there.
Ville Syrjälä [Thu, 21 Mar 2024 16:18:04 +0000 (18:18 +0200)]
drm/i915/bios: Add the old DPST field into VBT LFP power block
According to some VBIOS sources the LFP power block used to
have a single bit for DPST support. In version 159 that bit
got moved into the driver features block, and then in version
228 back into the LFP power block (but this time as a
per-panel thing). We have definitions for the last two, but
not the original bit. Define it as well.
Ville Syrjälä [Thu, 21 Mar 2024 16:18:03 +0000 (18:18 +0200)]
drm/i915/bios: Update VBT driver feature block version numbers
While the spec does claim that most of the driver feature flags
start from BDB version 165, reality and some VBIOS code disagrees.
The VBIOS code says it starts from version 159, and my ILK
with version 162 definitely has these things already in its
VBT. Update the version number comments to say 159+ for all
the bits that seem relevant for pre-hsw hardware.
Jani Nikula [Wed, 20 Mar 2024 15:48:04 +0000 (17:48 +0200)]
drm/i915/cx0: pass encoder instead of i915 and port around
The encoder is a much more useful thing to pass around than the i915 and
port combo. Also drive-by clean up some cases where both i915 and
encoder are passed; only the latter is needed.
Jani Nikula [Wed, 20 Mar 2024 15:48:01 +0000 (17:48 +0200)]
drm/i915/display: add intel_encoder_is_*() and _to_*() functions
Add a number of encoder based functions to check if the port/phy of the
encoder is of a certain type, or to convert to phy or tc_port. Initially
these are just wrappers around the existing functions, but they can be
improved to use VBT data or use some cached info in the future.
Jani Nikula [Wed, 20 Mar 2024 15:47:58 +0000 (17:47 +0200)]
drm/i915/hdmi: convert *_port_to_ddc_pin() to *_encoder_to_ddc_pin()
Pass encoder to the _port_to_ddc_pin() functions, and rename to
_encoder_to_ddc_pin(). The encoder will be more helpful than just port
in the subsequent changes.
Jani Nikula [Tue, 19 Mar 2024 09:12:53 +0000 (11:12 +0200)]
drm/i915/mst: enable MST mode for 128b/132b single-stream sideband
If the sink supports 128b/132b and single-stream sideband messaging,
enable MST mode.
With this, the topology manager will still write DP_MSTM_CTRL, which
should be ignored by the sink. In the future, the topology manager
should probably only set the sideband messaging related parts of the
register.
Jani Nikula [Tue, 19 Mar 2024 09:12:51 +0000 (11:12 +0200)]
drm/i915/mst: use the MST mode detected previously
Drop the duplicate read of DP_MSTM_CAP DPCD register, and the duplicate
logic for choosing MST mode, and store the chosen mode in struct
intel_dp. Rename intel_dp_configure_mst() to intel_dp_mst_configure()
while at it.
v2: Rebase on drm_dp_mst_detect() returning the mode, not bool
Jani Nikula [Tue, 19 Mar 2024 09:12:50 +0000 (11:12 +0200)]
drm/i915/mst: abstract choosing the MST mode to use
Clarify the conditions for choosing the MST mode to use by adding a new
function intel_dp_mst_mode_choose(). This also prepares for being able
to extend the MST modes to single-stream sideband messaging.
Jani Nikula [Tue, 19 Mar 2024 09:12:49 +0000 (11:12 +0200)]
drm/i915/mst: improve debug logging of DP MST mode detect
Rename intel_dp_can_mst() to intel_dp_mst_detect(), and move all DP MST
detect debug logging there. Debug log the sink's MST capability,
including single-stream sideband messaging support, and the decision
whether to enable MST mode or not. Do this regardless of whether we're
actually enabling MST or not.
We need to detect MST in intel_dp_detect_dpcd() before the earlier
returns, but try not to change the logic otherwise.
v2:
- Use "MST", "SST w/ sideband messaging", and "SST" for logging (Ville)
- Return MST mode from intel_dp_mst_detect()
- Do MST detect before early returns from intel_dp_detect_dpcd()
Jani Nikula [Tue, 19 Mar 2024 09:12:48 +0000 (11:12 +0200)]
drm/mst: read sideband messaging cap
Amend drm_dp_read_mst_cap() to return an enum, indicating "SST", "SST
with sideband messaging", or "MST". Modify all call sites to take the
new return value into account.
v2:
- Rename enumerators (Ville)
Cc: Arun R Murthy <arun.r.murthy@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Karol Herbst <kherbst@redhat.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Danilo Krummrich <dakr@redhat.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Maxime Ripard <mripard@kernel.org> Acked-by: Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/b32a3704934871a67d06420b760e148b76c5ced8.1710839496.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Ville Syrjälä [Fri, 8 Mar 2024 07:24:00 +0000 (09:24 +0200)]
drm/i915: Rename ICL_PORT_TX_DW6 bits
Our definitions for bit 7 and bit 0 of ICL_PORT_TX_DW6 are
swapped. Functionally it doesn't matter as we always set both
bits, but let's rename the bits to match bspec 100%.
And while at it, add the definition for bits 1-6 as well, just
to have it all fully documented.
Ankit Nautiyal [Wed, 13 Mar 2024 14:38:25 +0000 (20:08 +0530)]
drm/i915/scaler: Update Pipe src size check in skl_update_scaler
For Earlier platforms, the Pipe source size is 12-bits so
max pipe source width and height is 4096. For newer platforms it is
13-bits so theoretically max width/height is 8192. For few of the
earlier platforms the scaler did not use all bits of the PIPESRC,
so max scaler source size was used to make that the pipe source
size is programmed within limits, before using scaler.
This creates a problem, for MTL where scaler source size is 4096, but
max pipe source width can theroretically be 8192.
Switch the check to use the max scaler destination size, which closely
match the limits.
Jonathon Hall [Wed, 13 Mar 2024 13:54:25 +0000 (09:54 -0400)]
drm/i915: Do not match JSL in ehl_combo_pll_div_frac_wa_needed()
Since commit 0c65dc062611 ("drm/i915/jsl: s/JSL/JASPERLAKE for
platform/subplatform defines"), boot freezes on a Jasper Lake tablet
(Librem 11), usually with graphical corruption on the eDP display,
but sometimes just a black screen. This commit was included in 6.6 and
later.
That commit was intended to refactor EHL and JSL macros, but the change
to ehl_combo_pll_div_frac_wa_needed() started matching JSL incorrectly
when it was only intended to match EHL.
Ville Syrjälä [Thu, 15 Feb 2024 16:40:52 +0000 (18:40 +0200)]
drm/i915: Skip intel_crtc_state_dump() if debugs aren't enabled
intel_crtc_state_dump() does a whole boatload of string formatting
which is all wasted energy if the debugs aren't even enabled. Skip
the whole thing in that case.
Ville Syrjälä [Thu, 29 Feb 2024 18:40:49 +0000 (20:40 +0200)]
drm/i915: Convert intel_dpll_dump_hw_state() to drm_printer
Utilize drm_printer in pipe_config_pll_mismatch() to avoid
a bit of code duplication.
To achieve this we need to plumb the printer all way to the
dpll_mgr .dump_hw_state() functions. Those are also used by
intel_crtc_state_dump() which needs to be adjusted as well.
v2: Convert a few misplaecd drm_dbg_kms() calls (Rodrigo)
Drop the redundant drm_debug_enabled() check here
instead of later (Jani)
Ville Syrjälä [Thu, 15 Feb 2024 16:40:48 +0000 (18:40 +0200)]
drm/i915: Convert pipe_config_buffer_mismatch() to drm_printer
Utilize drm_printer in pipe_config_infoframe_mismatch() to avoid
a bit of code duplication.
print_hex_dump() doesn't know anything about the printer so
it still needs the DRM_UT_KMS check and special handling for
the loglevel. But at least we end up with a bit less copy-pasta.
Ville Syrjälä [Thu, 15 Feb 2024 16:40:47 +0000 (18:40 +0200)]
drm/i915: Convert pipe_config_infoframe_mismatch() to drm_printer
Utilize drm_printer in pipe_config_infoframe_mismatch() to avoid
a bit of code duplication.
hdmi_infoframe_log() can't use the printer of course, but for that
we can just figure out which loglevel to use. And we do need to keep
the explicit drm_debug_enabled(DRM_UT_KMS) since hdmi_infoframe_log()
won't do it for us.
Ville Syrjälä [Thu, 7 Mar 2024 15:18:09 +0000 (17:18 +0200)]
drm/i915: Use container_of_const() for states
commit 64f6a5d1922b ("container_of: add container_of_const()
that preserves const-ness of the pointer") is nice. Let's use
it so that we don't accidentally cast away the const from our
state pointers.
The only thing I don't particularly like about container_of_const()
is that it still accepts void* in addition to the proper pointer
types, but that's how most other things in C work anyway so I
guess we can live with it.
And while at it rename the macro arguments to be a bit more
descriptive than just 'x'.
TODO: maybe convert *all* container_of() uses to container_of_const()?
Jouni Högander [Wed, 13 Mar 2024 13:32:21 +0000 (15:32 +0200)]
drm/i915/display: Increase number of fast wake precharge pulses
Increasing number of fast wake sync pulses seem to fix problems with
certain PSR panels. This should be ok for other panels as well as the eDP
specification allows 10...16 precharge pulses and we are still within that
range.
v3: mention laptop model and panel manufacturer and model in comment
v2: add comment explaining pulse count is increased
Jouni Högander [Wed, 13 Mar 2024 13:32:20 +0000 (15:32 +0200)]
drm/i915/psr: Calculate IO wake and fast wake lines for DISPLAY_VER < 12
Bspec mentions 50 us for IO wake time and 32 us for fast wake time. 32 us
is most probably wrong as it doesn't meet the specification as fast wake
time is calculated in Bspec like this:
10..16 us (precharge) + 8 us (preamble) + 4 us (phy_wake) + 20 us
(tfw_exit_latency)
Instead of using these constants calculate IO wake and fast wake for
DISPLAY_VER < 12 as well.
v3:
- do not handle < 9 separately
- add own helper for skl and tgl io buffer wake times
v2:
- initialize io/fast_wake_time for display version < 9
Jouni Högander [Wed, 13 Mar 2024 13:32:19 +0000 (15:32 +0200)]
drm/i915/psr: Improve fast and IO wake lines calculation
Current fast and IO wake lines calculation is assuming fast wake sync
length is 18 pulses. Let's improve this by checking actual length.
Add getter for IO buffer wake time and return 10 us there which was assumed
with static 42 us IO wake time. Upcoming patches will extent this for
different display versions.
Bspec: 65450
v3:
- s/get_io_buffer_wake_time/io_buffer_wake_time/ and use it directly in
calculation.
v2:
- rename io_wake_time in if block to io_buffer_wake_time
- rename get_io_wake_time to get_io_buffer_wake_time
Jouni Högander [Wed, 13 Mar 2024 13:32:18 +0000 (15:32 +0200)]
drm/i915/display: Make intel_dp_aux_fw_sync_len available for PSR code
ALPM AUX-Wake fast wake sync pulse count is needed by PSR to calculate IO
wake and fast wake lines. Convert intel_dp_aux_fw_sync_len as non-static
to make it available for PSR code.
Shekhar Chauhan [Mon, 11 Mar 2024 04:15:04 +0000 (09:45 +0530)]
drm/i915/dp: Increase idle pattern wait timeout to 2ms
The driver currently waits 1ms for idle patterns,
but for Xe2LPD and possibly future display IPs,
it requires a 1640us (rounded up to 2ms) timeout
whilst waiting for idle patterns for MST streams.
To simplify the code, the timeout is uniformly
increased by 1ms across all platforms/display IPs.
v1: Introduced the 2ms wait timeout.
v2: Segregated the wait timeout for platforms before & after LNL.
v3: Fixed 2 cosmetic changes.
v4: Revert to v2 design with commit message enhancements.
v5: Minor cosmetic changes to the commit message.
Acquire the wakeref before the lock and hold it as long as the lock is
also held. Follow that pattern across the whole source file where similar
lock inversion can happen.
v2: Keep hardware read under the lock so the whole operation of updating
energy from hardware is still atomic (Guenter),
- instead, acquire the rpm wakeref before the lock and hold it as long
as the lock is held,
- use the same aproach for other similar places across the i915_hwmon.c
source file (Rodrigo).
Balasubramani Vivekanandan [Tue, 12 Mar 2024 16:36:39 +0000 (13:36 -0300)]
drm/xe/lnl: Enable display support
Enable display support for Lunar Lake.
Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240312163639.172321-9-gustavo.sousa@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Gustavo Sousa [Tue, 12 Mar 2024 16:36:37 +0000 (13:36 -0300)]
drm/i915/xe2lpd: Support MDCLK:CDCLK ratio changes
Commit 394b4b7df9f7 ("drm/i915/lnl: Add CDCLK table") and commit 3d3696c0fed1 ("drm/i915/lnl: Start using CDCLK through PLL") started
adding support for CDCLK programming support for Xe2LPD. One final piece
is missing, which is the programming necessary for changed in the ratio
between MDCLK and CDCLK. Let's do that now.
BSpec instructs us to update MBUS_CTL and DBUF_CTL_S* registers when the
ratio between MDCLK and CDCLK changes. The updates must be done before
changing the CDCLK when decreasing the frequency; or after it when
increasing the frequency.
Ratio-related updates to MBUS_CTL also depend on the state of MBus
joining, so they are performed by either CDCLK change sequence or by
changes in MBus joining. Since one might happen independently of the
other, we need to make sure that both logics see the necessary state
values when programming that register. MBus joining logic needs to know
the MDCLK:CDCLK ratio and that's already provided via mdclk_cdclk_ratio
field of struct intel_dbuf_state.
For the CDCLK logic, we need to have something similar: we need to
propagate the status of MBus joining to struct intel_cdclk_state. Do
that by adding the field joined_mbus to struct intel_cdclk_config.
(Preferably, that field would be added to intel_cdclk_state, however
currently only intel_cdclk_config is passed down to the functions that
do the register programming. We might revisit this decision if we find
that refactoring the code to pass the whole intel_cdclk_state is worth
it.)
Gustavo Sousa [Tue, 12 Mar 2024 16:36:36 +0000 (13:36 -0300)]
drm/i915: Add mdclk_cdclk_ratio to intel_dbuf_state
Xe2LPD always selects the CDCLK PLL as source for the MDCLK. Because of
that, the ratio between MDCLK and CDCLK is not be constant anymore. As
such, make sure to have the current ratio available in intel_dbuf_state
so that it can be used during dbuf programming.
Note that we write-lock the global state instead of serializing to a
hardware commit because a change in the ratio should be rather handled
in the CDCLK change sequence, which will need to take care of updating
the necessary registers in that case. We will implement that in upcoming
changes.
That said, changes in the MBus joining state should be handled by the
DBUF/MBUS logic, just like it is already done, but the logic will need
to know the ratio to properly update the registers.
v2:
- Make first sentence of commit message more intelligible. (Matt)
As of Xe2LPD, it is now possible to select the source of the MDCLK
as either the CD2XCLK or the CDCLK PLL.
Previous display IPs were hardcoded to use the CD2XCLK. For those, the
ratio between MDCLK and CDCLK remained constant, namely 2. For Xe2LPD,
when we select the CDCLK PLL as the source, the ratio will vary
according to the squashing configuration (since the cd2x divisor is
fixed for all supported configurations).
To help the transition to supporting changes in the ratio, extract the
function intel_dbuf_mdclk_cdclk_ratio_update() from the existing logic
and call it using 2 as hardcoded ratio. Upcoming changes will use that
function for updates in the ratio due to CDCLK changes.
Gustavo Sousa [Tue, 12 Mar 2024 16:36:34 +0000 (13:36 -0300)]
drm/i915/cdclk: Only compute squash waveform when necessary
It is no use computing the squash waveform if we are not going to use
it. Move the call to cdclk_squash_waveform() inside the block guarded by
HAS_CDCLK_SQUASH(dev_priv).
v2:
- Move "u16 waveform" declaration to inside the block where it is
initialized and used. (Matt)
Gustavo Sousa [Tue, 12 Mar 2024 16:36:33 +0000 (13:36 -0300)]
drm/i915/cdclk: Add and use mdclk_source_is_cdclk_pll()
Currently, only Xe2LPD uses CDCLK PLL as the source of MDCLK and
previous display IPs use the CD2XCLK. There will be changes in code
paths common to those platforms that will rely on which source is being
used. As such, let's make that information explicit with the addition of
the predicate function mdclk_source_is_cdclk_pll().
Arguably, an enum could be created, but using a boolean should suffice
here, since we there are only two possible sources and the logic that
will rely on it will be very localized.
In order to get the code into a more consistent state, let's also take
this opportunity to hook the selection of CDCLK_CTL's "MDCLK Source
Select" to that new function. Even though currently only
MDCLK_SOURCE_SEL_CDCLK_PLL will be returned, having this extra logic is
arguably better than keeping stuff untied and prone to bugs.
v2:
- Extract mdclk_source_is_cdclk_pll() out of xe2lpd_mdclk_source_sel()
to make latter only about the register's field.
Imre Deak [Mon, 11 Mar 2024 14:56:26 +0000 (16:56 +0200)]
drm/i915/dp: Fix DSC state HW readout for SST connectors
Commit a62e14598150 ("drm/i915/dp: Fix connector DSC HW state readout")
moved the DSC HW state readout to a connector specific hook, however
only added the hook for DP MST connectors, not for DP SST ones. Fix
adding the hook for SST connectors as well.
This fixes the following warn on platforms where BIOS enables DSC:
Radhakrishna Sripada [Wed, 28 Feb 2024 21:48:54 +0000 (13:48 -0800)]
drm/i915: Reuse RPLU cdclk fns for MTL+
MTL/LNL use the same cdclk functions as RPLU albeit with different
tables. Having separate tables and not requiring special handling
for the platforms, reuse RPLU cdclk functions.
Radhakrishna Sripada [Mon, 4 Mar 2024 21:23:31 +0000 (13:23 -0800)]
drm/i915: Show bios vbt when read from firmware/spi/oprom
Make debugfs vbt only shows valid vbt when read from ACPI opregion.
Make it work when read from firmware/spi/pci oprom cases. In the cases
where VBT needs to be read from spi/pci oprom, take the wakeref to
prevent WARN while reading DE registers during debugfs vbt dump.
v2: Extract getting vbt from different sources to its own function.
Protect sysfs write with vbt check(Jani)
v3: Fix CI error by probing bios vbt with runtime_pm wakeref
v4: Update commit message and skip waking up runtime while accessing
vbt from opregion/firmware(Jani)
v5: Skip grabbing unnecessary wakeref(Jani)
Radhakrishna Sripada [Wed, 28 Feb 2024 21:32:34 +0000 (13:32 -0800)]
drm/i915: Duplicate opregion vbt memory
In the case of vbt residing in opregion, we simply remap the region
into the kernel and pass the memory reference. Instead duplicate the
memory to handle a saner cleanup in intel_bios_init.
Radhakrishna Sripada [Wed, 28 Feb 2024 21:32:33 +0000 (13:32 -0800)]
drm/i915: Extract opregion vbt presence check
We want to later change intel_opregion_get_vbt to duplicate the vbt
memory if present, which would be an overkill when we just want to
peek into the presence of opregion vbt. Carve out the presence check
into its own function to use in places where only the presence of vbt
is required.
Radhakrishna Sripada [Wed, 28 Feb 2024 21:32:32 +0000 (13:32 -0800)]
drm/i915: Move vbt read from firmware to intel_bios.c
VBT read from firmware is currently nested within opregion vbt read.
Extract it and place it together with other vbt read mechanisms and
dis-associate vbt-firmware from opregion structure.
v2: Return NULL in failure cases and use a null check in
intel_bios_init(Jani)
Ville Syrjälä [Tue, 5 Mar 2024 08:47:29 +0000 (10:47 +0200)]
drm/i915: Disable planes more atomically during modesets
Follow in the footsteps of commit c610e841f19d ("drm/i915:
Do plane/etc. updates more atomically across pipes") and
do the plane disables back to back for all pipes also when
we are disabling pipes.
This should provide for a potentially more atomic user
experience, which might be especially nice when using
joiner or tiled displays.
Ville Syrjälä [Tue, 5 Mar 2024 08:47:28 +0000 (10:47 +0200)]
drm/i915: Precompute disable_pipes bitmask in intel_commit_modeset_disables()
Copy the pipe bitmask based approach from skl_commit_modeset_enables()
into intel_commit_modeset_disables(). This avoids doing so many
duplicated checks in all the loops, and also let's WARN at the
end if we screwed up somewhere and forgot to disable some pipe.
Ville Syrjälä [Tue, 23 Jan 2024 09:00:51 +0000 (11:00 +0200)]
drm/i915/fbc: Move DPFC_CHICKEN programming into intel_fbc_program_workarounds()
Move all DPFC_CHICKEN programming into intel_fbc_program_workarounds().
We already have one thing programmed there, whereas the rest is strewn
about in intel_display_wa_apply() and init_clock_gating(). Since we have
a single place doing all the programming (and it's serialized by the
crtc commits) there should be no danger of rmw races.
Other FBC related workarounds also exist, but those require fiddling
with other registers that may also get programmed from other places,
so we'll need to think harder what to do with those.
Ville Syrjälä [Thu, 29 Feb 2024 20:03:57 +0000 (22:03 +0200)]
drm/i915: Streamline eDP handling in icl_combo_phy_aux_power_well_enable()
Drop the pointless phy/port detour from the eDP handling
in icl_combo_phy_aux_power_well_enable(). We can just directly
consult the dig_port and determine whether it's eDP or not.
This also removes the assumption that port==phy, although that is
always trued on ICL, so it wasn't really doing any harm.
Ville Syrjälä [Thu, 29 Feb 2024 20:03:56 +0000 (22:03 +0200)]
drm/i915: Use pw_idx to derive PHY for ICL_LANE_ENABLE_AUX override
We don't actually know whether we should be picking the PHY
simply based on the AUX_CH/power well, or based on the VBT
defined AUX_CH->DDI->PHY relationship. At the moment we are
doing the former for the ANAOVRD workaround, and the latter
for the ICL_LANE_ENABLE_AUX override. Windows seems to use the
first approach for everything. So let's unify this to follow
that same approach for both.
Eventually we should try to figure out which is actually
correct, or whether any of this even matters (ie. whether there
are any real machines where the DDI and its AUX_CH do not match
1:1).
Note that this also changes the behaviour if we do end up
poking an AUX power well not associated with any port (as
per VBT). Previously we would have skipped the PHY register
write, but now we always write it.
Ville Syrjälä [Wed, 6 Mar 2024 04:08:06 +0000 (06:08 +0200)]
drm/i915/dsb: Always set DSB_SKIP_WAITS_EN
Bspec asks us to always set the DSB_SKIP_WAITS_EN bit in
DSB_CHICKEN. This seems to instruct DSB to skip vblank and
scanline waits when PSR is entered.
I don't think we have any cases currently where we would want
to enter PSR while DSB is waiting for something, but let's
set the bit anyway to align with Bspec's wishes.
Ville Syrjälä [Wed, 6 Mar 2024 04:08:05 +0000 (06:08 +0200)]
drm/i915/dsb: Fix DSB vblank waits when using VRR
Looks like the undelayed vblank gets signalled exactly when
the active period ends. That is a problem for DSB+VRR when
we are already in vblank and expect DSB to start executing
as soon as we send the push. Instead of starting, the DSB
just keeps on waiting for the undelayed vblank which won't
signal until the end of the next frame's active period,
which is far too late.
The end result is that DSB won't have even started
executing by the time the flips/etc. have completed.
We then wait for an extra 1ms, after which we terminate
the DSB and report a timeout:
[drm] *ERROR* [CRTC:80:pipe A] DSB 0 timed out waiting for idle (current head=0xfedf4000, head=0x0, tail=0x1080)
To fix this let's configure DSB to use the so called VRR
"safe window" instead of the undelayed vblank to trigger
the DSB vblank logic, when VRR is enabled.
projects / users / jedix / linux-maple.git / log