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).
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:
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.
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)
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.
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.
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.
Ville Syrjälä [Wed, 6 Mar 2024 04:08:04 +0000 (06:08 +0200)]
drm/i915/vrr: Generate VRR "safe window" for DSB
Looks like TRANS_CHICKEN bit 31 means something totally different
depending on the platform:
TGL: generate VRR "safe window" for DSB
ADL/DG2: make TRANS_SET_CONTEXT_LATENCY effective with VRR
So far we've only set this on ADL/DG2, but when using DSB+VRR
we also need to set it on TGL.
And a quick test on MTL says it doesn't need this bit for either
of those purposes, even though it's still documented as valid
in bspec.
Ville Syrjälä [Tue, 5 Mar 2024 08:36:59 +0000 (10:36 +0200)]
drm/i915/dsi: Go back to the previous INIT_OTP/DISPLAY_ON order, mostly
Reinstate commit 88b065943cb5 ("drm/i915/dsi: Do display on
sequence later on icl+"), for the most part. Turns out some
machines (eg. Chuwi Minibook X) really do need that updated order.
It is also the order the Windows driver uses.
However we can't just undo the revert since that would again
break Lenovo 82TQ. After staring at the VBT sequences for both
machines I've concluded that the Lenovo 82TQ sequences look
somewhat broken:
- INIT_OTP is not present at all
- what should be in INIT_OTP is found in DISPLAY_ON
- what should be in DISPLAY_ON is found in BACKLIGHT_ON
(along with the actual backlight stuff)
The Chuwi Minibook X on the other hand has a full complement
of sequences in its VBT.
So let's try to deal with the broken sequences in the
Lenovo 82TQ VBT by simply swapping the (non-existent)
INIT_OTP sequence with the DISPLAY_ON sequence. Thus we
execute DISPLAY_ON when intending to execute INIT_OTP,
and execute nothing at all when intending to execute
DISPLAY_ON. That should be 100% equivalent to the
revert, for such broken VBTs.
Cc: stable@vger.kernel.org Fixes: dc524d05974f ("Revert "drm/i915/dsi: Do display on sequence later on icl+"")
References: https://gitlab.freedesktop.org/drm/intel/-/issues/10071 Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10334 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240305083659.8396-1-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com>
drm/i915/display: Disable AuxCCS framebuffers if built for Xe
AuxCCS framebuffers don't work on Xe driver hence disable them
from plane capabilities until they are fixed. FlatCCS framebuffers
work and they are left enabled. CCS is left untouched for i915
driver.
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/933 Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Tested-by: José Roberto de Souza <jose.souza@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Fixes: 44e694958b95 ("drm/xe/display: Implement display support") Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240228140225.858145-1-juhapekka.heikkila@gmail.com
Ville Syrjälä [Mon, 26 Feb 2024 19:32:50 +0000 (21:32 +0200)]
drm/i915: Stop doing double audio enable/disable on SDVO and g4x+ DP
Looks like I misplaced a few hunks when I moved the audio
enable/disable out from the encoder enable/disable hooks.
So we are now doing a double audio enable/disable on SDVO
and g4x+ DP. Probably harmless as doing it twice shouldn't
really change anything, but let's do it just once, as intended.
Imre Deak [Mon, 5 Feb 2024 13:26:31 +0000 (15:26 +0200)]
drm/i915/dp: Fix connector DSC HW state readout
The DSC HW state of DP connectors is read out during driver loading and
system resume in intel_modeset_update_connector_atomic_state(). This
function is called for all connectors though and so the state of DSI
connectors will also get updated incorrectly, triggering a WARN there
wrt. the DSC decompression AUX device.
Fix the above by moving the DSC state readout to a new DP connector
specific sync_state() hook. This is anyway the logical place to update
the connector object's state vs. the connector's atomic state.
Fixes: b2608c6b3212 ("drm/i915/dp_mst: Enable MST DSC decompression for all streams") Reported-and-tested-by: Drew Davenport <ddavenport@chromium.org> Closes: https://lore.kernel.org/all/Zb0q8IDVXS0HxJyj@chromium.org Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240205132631.1588577-1-imre.deak@intel.com
Imre Deak [Wed, 28 Feb 2024 16:46:36 +0000 (18:46 +0200)]
drm/dp: Fix documentation of DP tunnel functions
Fix the documentation issues below, also reported by 'make htmldocs':
drivers/gpu/drm/display/drm_dp_tunnel.c:447: warning: Function parameter or struct member 'tunnel' not described in 'drm_dp_tunnel_put'
drivers/gpu/drm/display/drm_dp_tunnel.c:447: warning: Function parameter or struct member 'tracker' not described in 'drm_dp_tunnel_put'
drivers/gpu/drm/display/drm_dp_tunnel.c:1185: warning: expecting prototype for drm_dp_tunnel_atomic_get_allocated_bw(). Prototype was for drm_dp_tunnel_get_allocated_bw() instead
drivers/gpu/drm/display/drm_dp_tunnel.c:1903: warning: Function parameter or struct member 'max_group_count' not described in 'drm_dp_tunnel_mgr_create'
Animesh Manna [Thu, 29 Feb 2024 04:37:16 +0000 (10:07 +0530)]
drm/i915/panelreplay: Move out psr_init_dpcd() from init_connector()
Move psr_init_dpcd() from init-connector to connector-detect
function. The dpcd probe for checking panel replay capability
for external dp connector is causing delay during boot which can
be optimized by moving dpcd probe to connector specific detect().
v1: Initial version.
v2: Add details in commit description. [Jani]
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10284 Signed-off-by: Animesh Manna <animesh.manna@intel.com> Fixes: cceeaa312d39 ("drm/i915/panelreplay: Enable panel replay dpcd initialization for DP") Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240229043716.4065760-1-animesh.manna@intel.com
Ville Syrjälä [Fri, 23 Feb 2024 20:32:16 +0000 (22:32 +0200)]
drm/i915: Simplify aux_ch_to_digital_port()
Just return the correct thing from within the loop to make
the code more readable. We have no ref counts/etc. to deal
with here so no point in breaking from the loop just to return
something.
Ville Syrjälä [Fri, 23 Feb 2024 20:32:15 +0000 (22:32 +0200)]
drm/i915: Don't explode when the dig port we don't have an AUX CH
The icl+ power well code currently assumes that every AUX power
well maps to an encoder which is using said power well. That is
by no menas guaranteed as we:
- only register encoders for ports declared in the VBT
- combo PHY HDMI-only encoder no longer get an AUX CH since
commit 9856308c94ca ("drm/i915: Only populate aux_ch if really needed")
However we have places such as intel_power_domains_sanitize_state()
that blindly traverse all the possible power wells. So these bits
of code may very well encounbter an aux power well with no associated
encoder.
In this particular case the BIOS seems to have left one AUX power
well enabled even though we're dealing with a HDMI only encoder
on a combo PHY. We then proceed to turn off said power well and
explode when we can't find a matching encoder. As a short term fix
we should be able to just skip the PHY related parts of the power
well programming since we know this situation can only happen with
combo PHYs.
Another option might be to go back to always picking an AUX CH for
all encoders. However I'm a bit wary about that since we might in
theory end up conflicting with the VBT AUX CH assignment. Also
that wouldn't help with encoders not declared in the VBT, should
we ever need to poke the corresponding power wells.
Longer term we need to figure out what the actual relationship
is between the PHY vs. AUX CH vs. AUX power well. Currently this
is entirely unclear.
drm/i915/display: Save a few bytes of memory in intel_backlight_device_register()
'name' may still be "intel_backlight" when backlight_device_register()
is called. In such a case, using kstrdup_const() saves a memory
duplication when dev_set_name() is called in
backlight_device_register().
Add a function to return the expected child device size. Flip the if
ladder around and use the same versions as in documentation to make it
easier to verify. Return an error for unknown versions. No functional
changes.
v2: Move BUILD_BUG_ON() next to the expected sizes
projects / thirdparty / kernel / linux.git / log
