Ville Syrjälä [Wed, 22 Jun 2022 15:54:49 +0000 (18:54 +0300)]
drm/i915: Fix g4x/vlv/chv CxSR vs. format/tiling/rotation changes
On g4x/vlv/chv the hardware seems incapable of changing the pixel
format, rotation, or YUV->RGB CSC matrix while in CxSR.
Additionally on VLV/CHV the sprites seem incapable of tiling
changes while in CxSR. On g4x CxSR is not even possible with
the sprite enabled. Curiously the primary plane seems perfectly
happy when changing tiling during CxSR.
Pimp up the code to account for these when determining whether
CxSR needs to be disabled. Since it looks like most of the plane
control register bits are affected let's just compare that.
But in the name of efficiency we'll make an exception for the
primary plane tiling changes (avoids some extra vblank waits).
v2: Just use the pre-computed plane control register values
Ville Syrjälä [Tue, 4 Oct 2022 15:09:29 +0000 (18:09 +0300)]
drm/i915: Clean up some namespacing
Rename a few functions from intel_crtc_foo_init() to
intel_foo_crtc_init() so that the namespaec clearly
indicates what feature/file we're talking about.
I left out intel_crtc_crc_init() because the whole crc
stuff uses intel_crtc_ as its namespace currently.
Radhakrishna Sripada [Wed, 5 Oct 2022 00:20:13 +0000 (17:20 -0700)]
drm/i915/mtl: Add MTP ddc pin configuration
Meteorlake PCH reuses Alderlake vbt, DE pin mapping. Extend
ADL-P pin mapping for Meteorlake.
Bspec: 20124 does not have the mapping for MTP. Based on Bspec:49306, 64051,
it is concluded that MTP and ADL-P PCH have the same vbt -> DE pin pair mapping.
José Roberto de Souza [Wed, 7 Sep 2022 08:15:43 +0000 (11:15 +0300)]
drm/i915/mtl: Extend PSR support
Meteorlake and display 14 platform don't have any PSR differences
when comparing to Alderlake-P display, so it was only necessary to
extend some checks to properly program hardware.
BSpec: 55229, 49196
Cc: Mika Kahola <mika.kahola@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220907081543.92268-1-mika.kahola@intel.com
Ville Syrjälä [Mon, 3 Oct 2022 11:32:49 +0000 (14:32 +0300)]
drm/i915: Setup final panel drrs_type already during init
Now that we track the VBT drrs type per-panel we can move the
has_drrs_modes() check to the panel init rather than doing it
for every intel_panel_drrs_type() call.
Ville Syrjälä [Mon, 3 Oct 2022 11:32:46 +0000 (14:32 +0300)]
drm/i915: Make DRRS debugfs per-crtc/connector
Since I already broke anything that relied on the old contents
of the DRRS debugfs files might as well finish the breakage
and convert the files to be per-crtc/connector so we don't need
to have annoying code in igt to parse these.
Ville Syrjälä [Mon, 3 Oct 2022 11:32:45 +0000 (14:32 +0300)]
drm/i915: Make the DRRS debugfs contents more consistent
The stuff in the DRRS debugs is currently a hodgepode mix
of camelcase, lowercase, spaces, undescores, you name it.
Convert over to a reasonably common style.
Also move the busy bits thing to be the last sine it's
generally the least interesting thing in there.
Ville Syrjälä [Tue, 27 Sep 2022 18:24:55 +0000 (21:24 +0300)]
drm/i915: Reject excessive dotclocks early
Make sure modes with crazy big dotclocks are rejected early,
so as to not cause problems for subsequent code via integer
overflows and whatnot.
These would eventually be rejected in intel_crtc_compute_pipe_mode()
but that is now too late as we do the clock computations a bit
earlier than that. And we don't want to just reorder the two since
we still want to check the final computed dotclock against the
hardware limit to make sure we didn't end up above the limit due
to rounding/etc.
Ville Syrjälä [Mon, 3 Oct 2022 11:15:43 +0000 (14:15 +0300)]
drm/i915: Fix watermark calculations for DG2 CCS+CC modifier
Take the DG2 CCS+CC modifier into account when calculating the
watermarks. Othwerwise we'll calculate the watermarks thinking this
tile-4 modifier is linear.
The rc_surface part is actually a nop since that is not used
for any glk+ platform.
Ville Syrjälä [Mon, 3 Oct 2022 11:15:42 +0000 (14:15 +0300)]
drm/i915: Fix watermark calculations for DG2 CCS modifiers
Take the DG2 CCS modifiers into account when calculating the
watermarks. Othwerwise we'll calculate the watermarks thinking these
tile-4 modifiers are linear.
The rc_surface part is actually a nop since that is not used
for any glk+ platform.
Ville Syrjälä [Mon, 3 Oct 2022 11:15:41 +0000 (14:15 +0300)]
drm/i915: Fix watermark calculations for gen12+ CCS+CC modifier
Take the gen12+ CCS+CC modifier into account when calculating the
watermarks. Othwerwise we'll calculate the watermarks thinking this
Y-tiled modifier is linear.
The rc_surface part is actually a nop since that is not used
for any glk+ platform.
Ville Syrjälä [Mon, 3 Oct 2022 11:15:40 +0000 (14:15 +0300)]
drm/i915: Fix watermark calculations for gen12+ MC CCS modifier
Take the gen12+ MC CCS modifier into account when calculating the
watermarks. Othwerwise we'll calculate the watermarks thinking this
Y-tiled modifier is linear.
The rc_surface part is actually a nop since that is not used
for any glk+ platform.
Ville Syrjälä [Mon, 3 Oct 2022 11:15:39 +0000 (14:15 +0300)]
drm/i915: Fix watermark calculations for gen12+ RC CCS modifier
Take the gen12+ RC CCS modifier into account when calculating the
watermarks. Othwerwise we'll calculate the watermarks thinking this
Y-tiled modifier is linear.
The rc_surface part is actually a nop since that is not used
for any glk+ platform.
Jouni Högander [Mon, 3 Oct 2022 07:20:11 +0000 (10:20 +0300)]
drm/i915/psr: Fix PSR_IMR/IIR field handling
Current PSR code is supposed to use TRANSCODER_EDP to force 0 shift for
bits in PSR_IMR/IIR registers:
/*
* gen12+ has registers relative to transcoder and one per transcoder
* using the same bit definition: handle it as TRANSCODER_EDP to force
* 0 shift in bit definition
*/
At the time of writing the code assumption "TRANSCODER_EDP == 0" was made.
This is not the case and all fields in PSR_IMR and PSR_IIR are shifted
incorrectly if DISPLAY_VER >= 12.
Fix this by adding separate register field defines for >=12 and add bit
getter functions to keep code readability.
v4:
- Remove EDP from TGL definitions (José)
- Use REG_BIT and REG_GENMASK (José)
v3:
- Add separate register field defines (José)
- Add bit getter functions (José)
v2:
- Improve commit message (José)
Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Fixes: 8241cfbe67f4 ("drm/i915/tgl: Access the right register when handling PSR interruptions") Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221003072011.72408-1-jouni.hogander@intel.com
Ville Syrjälä [Thu, 29 Sep 2022 07:15:12 +0000 (10:15 +0300)]
drm/i915: Remove PLL asserts from .load_luts()
.load_luts() potentially runs from the vblank worker, and is
under a deadline to complete within the vblank. Thus we can't
do expesive stuff like talk to the Punit, etc.
To that end get rid of the assert_dsi_pll_enabled() call for
vlv/chv. We'll just have to trust that the PLL is already enabled
here.
And I don't think the normal assert_pll_enabled() really buys us
anything useful on gmch platforms either, so nuke that one too.
We don't have corresponding asserts in the ilk+ codepaths anyway
despite the hardware (IIRC) still requiring the clock to be
enabled when we access the LUT.
Ville Syrjälä [Tue, 27 Sep 2022 18:06:15 +0000 (21:06 +0300)]
drm/i915: Allow alternate fixed modes always for LVDS
As with eDP let's stop considering the VBTs DRRS knobs and
just always accept all otherwise suitable EDID modes. This
appears to be how Windows does it.
Ville Syrjälä [Tue, 27 Sep 2022 18:06:14 +0000 (21:06 +0300)]
drm/i915: Allow alternate fixed modes always for eDP
Stop considering VBT's static DRRS support when deciding whether
to use alternate fixed modes or not. It looks like Windows more
or less just uses that to decide whether to automagically switch
refresh rates on AC<->battery changes, or perhaps whether to
even expose a control for that in some UI thing. Either way it
seems happy to always use all EDID modes, and I guess the
DRRS/VRR stuff more or less adjusts how said modes get
actually used.
Let's do the same and just accept all the suitable looking
modes from EDID, whether we have DRRS or VRR.
Since commit a5810f551d0a ("drm/i915: Allow more varied alternate
fixed modes for panels") intel_panel_add_edid_alt_fixed_modes()
no longer considers vrr vs. drrs separately. So no reason to
pass them as separate parameters either.
Ville Syrjälä [Mon, 26 Sep 2022 19:30:21 +0000 (22:30 +0300)]
drm/i915: Round to closest in g4x+ HDMI clock readout
On pre-ddi platforms we have slightly different code being
used for HDMI TMDS clock to dotclock conversion between the
state computation and state readout. Both of these need to
round the same way in order to not get a mismatch between
the computed and read out states. Fix up the rounding
direction in the readout path to match what is used during
state computation.
Another option would to just use intel_crtc_dotclock()
in the readout path as well, but I don't really want to
do that as the current code more accurately represents
how the hardware really works; The HDMI port register
defines whether we're actually outputting 8bpc or 12bpc
over HDMI, and the PIPECONF bpc setting just defines what
goes over FDI between the CPU and PCH. The fact that we
try to cram all that into a single pipe_bpp during state
computation is perhaps not entirely great...
Imre Deak [Thu, 22 Sep 2022 17:21:48 +0000 (20:21 +0300)]
drm/i915: Fix TypeC mode initialization during system resume
During system resume DP MST requires AUX to be working already before
the HW state readout of the given encoder. Since AUX requires the
encoder/PHY TypeC mode to be initialized, which atm only happens during
HW state readout, these AUX transfers can change the TypeC mode
incorrectly (disconnecting the PHY for an enabled encoder) and trigger
the state check WARNs in intel_tc_port_sanitize().
Fix this by initializing the TypeC mode earlier both during driver
loading and system resume and making sure that the mode can't change
until the encoder's state is read out. While at it add the missing
DocBook comments and rename
intel_tc_port_sanitize()->intel_tc_port_sanitize_mode() for consistency.
Ville Syrjälä [Thu, 22 Sep 2022 19:13:14 +0000 (22:13 +0300)]
drm/i915: Don't bail early from intel_dp_initial_fastset_check()
Do all the checks in intel_dp_initial_fastset_check() instead
of bailing out on the first condition that triggers.
This makes for better debug logs since we see all the reasons
why the full modeset computation is forced.
Also avoid the risk of someone accidentally adding a check
later in the function that would require connectors_changed=true
(ie. no fastset at all), but an earlier check may have already
bailed out with just mode_changed=true (ie. fastset is still
possible).
Pimp the debugs with the encoder id+name while at it.
v2: Call the return variable 'fastset' to convey its meaning
Ville Syrjälä [Thu, 22 Sep 2022 19:12:36 +0000 (22:12 +0300)]
drm/i915: Force DPLL calculation for TC ports after readout
We always allocate two DPLLs (TC and TBT) for TC ports. This
is because we can't know ahead of time wherher we need to put
the PHY into DP-Alt or TBT mode.
However during readout we can obviously only read out the state
of the DPLL that the port is actually using. Thus the state after
readout will not have both DPLLs populated.
We run into problems if during readout the TC port is in DP-Alt
mode, but we then perform a modeset on the port without going
through the full .compute_config() machinery, and during said
modeset the port cannot be switched back into DP-Alt mode and
we need to take the TBT fallback path. Such a modeset can
happen eg. due to cdclk reprogramming.
This wasn't a problem earlier because we did all the DPLL
calculations much later in the modeset. So even if flagged
a modeset very late we'd still have gone through the DPLL
calculations. But now all the DPLL calculations happen much
earlier and so we need to deal with it, or else we'll attempt
a modeset without a DPLL.
To guarantee that we always have both DPLLs fully cal/ulated
for TC ports force a full modeset computation during the
initial commit.
v2: Avoid bitwise operation on bool (Jani)
Call the return variable 'fastset' to convey its meaning
Jani Nikula [Fri, 16 Sep 2022 08:26:42 +0000 (11:26 +0300)]
drm/i915: fix device info for devices without display
Commit 00c6cbfd4e8a ("drm/i915: move pipe_mask and cpu_transcoder_mask
to runtime info") moved the pipe_mask member from struct
intel_device_info to intel_runtime_info, but overlooked some of our
platforms initializing device info .display = {}. This is significant,
as pipe_mask is the single point of truth for a device having a display
or not; the platforms in question left pipe_mask to whatever was set for
the platforms they "inherit" from in the complex macro scheme we have.
Add new NO_DISPLAY macro initializing .__runtime.pipe_mask = 0, which
will cause the device info .display sub-struct to be zeroed in
intel_device_info_runtime_init(). A better solution (or simply audit of
proper use of HAS_DISPLAY() checks) is required before moving forward
with [1].
Also clear all the display related members in runtime info if there's no
display. The latter is a bit tedious, but it's for completeness at this
time, to ensure similar functionality as before.
Fixes: 00c6cbfd4e8a ("drm/i915: move pipe_mask and cpu_transcoder_mask to runtime info") Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Maarten Lankhort <maarten.lankhorst@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Acked-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220916082642.3451961-1-jani.nikula@intel.com
Ville Syrjälä [Wed, 22 Jun 2022 15:54:47 +0000 (18:54 +0300)]
drm/i915: Simplify up vlv watermark sanitation
We can simplify the vlv watermark sanitation by reusing the
second half of vlv_compute_pipe_wm() to convert the sanitized
raw watermarks into the proper form to be used as the
optimal/intermediate watermarks.
Also to be consistent with normal watermark computation the sanitized
watermarks should be all 0 for any disabled plane. Previously we
zeroed out the watermarks only up to the level (ie. PM2/5/DVDFS)
that was enabled.
Ville Syrjälä [Wed, 22 Jun 2022 15:54:46 +0000 (18:54 +0300)]
drm/i915: Simplify up g4x watermark sanitation
We can simplify the g4x watermark sanitation by reusing the
second half of g4x_compute_pipe_wm() to convert the sanitized
raw watermarks into the proper form to be used as the
optimal/intermediate watermarks.
Ville Syrjälä [Wed, 22 Jun 2022 15:54:45 +0000 (18:54 +0300)]
drm/i915: Split vlv_compute_pipe_wm() into two
Split vlv_compute_pipe_wm() into two halves. The first half computes
the new raw watermarks, and the second half munges those up into real
watermarks for the particular pipe.
We can reuse the second half for watermark sanitation as well.
Ville Syrjälä [Wed, 22 Jun 2022 15:54:44 +0000 (18:54 +0300)]
drm/i915: Split g4x_compute_pipe_wm() into two
Split g4x_compute_pipe_wm() into two halves. The first half computes
the new raw watermarks, and the second half munges those up into real
watermarks for the particular pipe.
We can reuse the second half for watermark sanitation as well.
Ville Syrjälä [Mon, 12 Sep 2022 11:18:12 +0000 (14:18 +0300)]
drm/i915: Don't init eDP if we can't find a fixed mode
In the unlikely case of not finding a fixed mode don't register
the eDP connector. I think there are some places where we'd oops
if we didn't have a fixed mode for eDP so presumable this doesn't
typically happen. But better safe than sorry.
Also pimp the debugs with the encoder id+name. I think dumping
the encoder rather than the connector provides more information
here (eg. to match against the port information in the VBT).
We can also drop the extra check from intel_edp_add_properties().
Ville Syrjälä [Mon, 12 Sep 2022 11:18:11 +0000 (14:18 +0300)]
drm/i915: Clean up connector->*_allowed setup
All the connectors are zero initialized so no need to clear
the *_allowed flags we don't support. Only leave the ones we want
to set. And while at it switch to booleans instead of ints.
Consolidate the scaling_mode property setup into a single
place.
The one slight complicateion here is that GMCH platforms can't
do the CENTER mode except on the LVDS port. But we can deal with
that by just checking the connector type.
Ville Syrjälä [Mon, 12 Sep 2022 11:18:01 +0000 (14:18 +0300)]
drm/i915: Clean up transcoder_to_stream_enc_status()
Drop the pointless middle man variable and just return the
correct thing directly. And while at it change the return
type to u32 since this is a register value we're returning.
drm/i915: Move hotplug inversion logic into separate helper
Use *_hpd_invert() helpers whenever possible to isolate logic specific
to hotplug inversion from common HPD setup logic to improve readability
and maintainability of the source code.
While we only define dg1_hpd_invert() here, future platforms are likely
to have different hotplug inversion needs, thus it makes sense grouping
different implementations under a common suffix.
v2: Fix coding style and prefer to use small *_hdp_invert() helpers
instead of a generic one.
José Roberto de Souza [Fri, 16 Sep 2022 01:46:47 +0000 (18:46 -0700)]
drm/i915: Parse and set stepping for platforms with GMD
Expand the current stepping convention to accommodate the GMD
stepping info. Typically GMD step maps to letter stepping
by "A + step %4" and number to "A + step /4" i.e, GMD step
0 maps to STEP_A0, 1 to _A1, 2 to _A2, 3 to _A3, 4 to STEP_B0...
Future platforms might break this formulae and may require a table
mapping to decode GMD step compatible with the convention.
v2:
- Pass the updated ip version structure
v3:
- Skip using GMD to step table(MattR)
Cc: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220916014648.1310346-3-radhakrishna.sripada@intel.com
Matt Roper [Fri, 16 Sep 2022 01:46:46 +0000 (18:46 -0700)]
drm/i915: Read graphics/media/display arch version from hw
Going forward, the hardware teams no longer consider new platforms to
have a "generation" in the way we've defined it for past platforms.
Instead, each IP block (graphics, media, display) will have their own
architecture major.minor versions and stepping ID's which should be read
directly from a register in the MMIO space.
Bspec: 63361, 64111
v2:
- Move the IP version readout to intel_device_info.c
- Convert the macro into a function
v3:
- Move subplatform init to runtime early init
- Cache runtime ver, release info to compare with hardware values.
- Use IP_VER for snaity check(MattR)
v4:
- Minor doccumentation changes.
- Normalize HAS_GMD_ID macro value.(JaniN)
Ville Syrjälä [Fri, 16 Sep 2022 16:52:05 +0000 (19:52 +0300)]
drm/i915/fbc: Remove stale FIXME
Remove the old tales about 90/270 degree rotation
effectively preventing FBC. That hasn't been true since
we stopped demanding the fence is present in
commit 691f7ba58d52 ("drm/i915/display/fbc: Make fences
a nice-to-have for GEN9+")
Also fix up the multiline comment formatting while at it.
Ville Syrjälä [Fri, 16 Sep 2022 16:52:04 +0000 (19:52 +0300)]
drm/i915: Nuke stale plane cdclk ratio FIXMEs
The plane ratio stuff got implemented in
commit bb6ae9e653dc ("drm/i915: Allow planes to
declare their minimum acceptable cdclk") so these
FIXMEs have no business being here.
Ville Syrjälä [Mon, 20 Jun 2022 18:29:17 +0000 (21:29 +0300)]
drm/i915/fbc: Use lockdep_assert_held()
Replace the mutex_is_locked() stuff with lockdep_assert_held() since
that's what it's there for.
Also sprinkle these around so that we have more or less
mirrored coverage for the enable vs. disable instead of the
current situation where the asserts seem to be more or less
randomly thrown around.
Ville Syrjälä [Mon, 20 Jun 2022 18:29:16 +0000 (21:29 +0300)]
drm/i915/fbc: Move flip_pending assignmnt
Move the flip_pending assignment into __intel_fbc_post_update()
from intel_fbc_post_update(). Now mirrors the pre_update() side.
The only reason the assignment was in the higher level function
is that we used to call __intel_fbc_post_update() from elsewhere
as well. That got cleaned up in commit b39d2c620242 ("drm/i915/fbc:
Call intel_fbc_activate() directly from frontbuffer flush")
Ville Syrjälä [Fri, 16 Sep 2022 20:41:32 +0000 (23:41 +0300)]
drm/i915: WARN if a port should use VBT provided vswing tables
We don't parse the VBT vswing/preemphassis tables at all currently.
Let's WARN if a port wants to use them so we get a heads up that
whether we really need to implement this stuff or not. My
current stash contains no VBTs with this bit set.
Jani Nikula [Fri, 16 Sep 2022 11:38:50 +0000 (14:38 +0300)]
drm/i915/display: remove ipc_enabled from struct drm_i915_private
The ipc_enabled member was supposed to be moved under the display wm
sub-struct, but due to a rebase fail only the new one was added and the
old one was left behind. Finish the job.
Jani Nikula [Fri, 16 Sep 2022 13:06:34 +0000 (16:06 +0300)]
drm/i915/hotplug: refactor hotplug init slightly
Rename intel_hpd_init_work() to the more generic intel_hpd_init_early(),
and move the hotplug storm initialization there. This lets us move the
HPD_STORM_DEFAULT_THRESHOLD macro to intel_hotplug.c too.
drm/i915: Fix return type of mode_valid function hook
All of the functions used for intel_dvo_dev_ops.mode_valid have a return
type of enum drm_mode_status, but the mode_valid field in the struct
definition has a return type of int.
The mismatched return type breaks forward edge kCFI since the underlying
function definitions do not match the function hook definition.
The return type of the mode_valid field should be changed from int to
enum drm_mode_status.
Display version 14 platforms have different credits values
compared to ADL-P. Update the credits based on pipe usage.
v2: Simplify DBOX BW Credit definition(MattR)
v3:
- Simplify only pipe per dbuf bank check(MattR)
- Skip modeset check to handle the case when a new pipe within
dbuf bank gets added/removed.(MattR)
Bspec: 49213
Cc: Jose Roberto de Souza <jose.souza@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com>
Original Author: Caz Yokoyama Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220913183341.908028-5-radhakrishna.sripada@intel.com
Jani Nikula [Mon, 12 Sep 2022 11:45:14 +0000 (14:45 +0300)]
drm/i915/ipc: register debugfs only if IPC available
It looks like trying to enable IPC via debugfs on platforms that don't
have IPC resulted in dmesg info message about IPC being enabled, which
is clearly not possible and would not happen.
Seems sensible to register IPC debugfs only on platforms that have IPC.
Jani Nikula [Mon, 12 Sep 2022 11:45:13 +0000 (14:45 +0300)]
drm/i915/ipc: move IPC debugfs to skl_watermark.c
Follow the new direction for debugfs files, moving the details where the
implementation is. It seems quite natural skl_watermark.c is the place
that controls IPC details, even for debugfs, not
intel_display_debugfs.c.
Rename the functions and convert dev_priv->i915 while at it.
Jani Nikula [Mon, 12 Sep 2022 11:45:12 +0000 (14:45 +0300)]
drm/i915/ipc: refactor and rename IPC functions
Rename the IPC functions to have skl_watermark_ipc_ prefix, rename
enable to update to reflect what the function actually does, and add
enabled function to abstract direct ->ipc_enabled access for state
query.
Damage clips are relative to original coodrdinates provided by
user-space. To compare these against src coordinates we need to use
original coordinates as provided by user-space. These can be obtained
by using drm_plane_state_src.
drm/i915/psr: Disable PSR2 when SDP is sent on prior line
Selective update doesn't work if SU start address is 0 and start/end
SDP is configured to be sent prior to SU start/end lines. PSR2 has to be
disabled in this case for Alder Lake.
Ville Syrjälä [Fri, 9 Sep 2022 20:59:32 +0000 (23:59 +0300)]
drm/i915: Fix TV encoder clock computation
The TV encoder has its own special clocking strategy,
which means we can't just use intel_crtc_dotclock() to
figure out what the resulting dotclock will be given
the actual DPLL port_clock. Additionally the DPLL can't
always generate exactly the frequency we initially asked
for. This results in us computing a bogus dotclock/etc.,
and it won't match the readout which is handled by the
encoder itself properly. Naturally the state checker
becomes unhappy with the mismatch.
To do this sanely we'll need to move the DPLL computation
into encoder->compute_config() so that all the derived
state gets correctly computed based on the actual DPLL
output frequency. Start doing that just for the TV encoder
initally as intel_crtc_dotclock() should be able to handle
other encoder types well enough. Though eventually this
should be done for all encoder types rather than
doing it from intel_crtc_compute_config().
With this we actually do some of the DPLL state computation
twice, but we can skip the second actual .find_dpll() search
by flagging .clock_set=true after we've done it once. We also
still need to avoid clobbering the correct
adjusted_mode.crtc_clock set up by encoder->compute_config()
when called a second time from intel_crtc_compute_config().
drm/i915/mtl: Obtain SAGV values from MMIO instead of GT pcode mailbox
From Meteorlake, Latency Level, SAGV bloack time are read from
LATENCY_SAGV register instead of the GT driver pcode mailbox. DDR type
and QGV information are also to be read from Mem SS registers.
v2:
- Simplify MTL_MEM_SS_INFO_QGV_POINT macro(MattR)
- Nit: Rearrange the bit def's from higher to lower(MattR)
- Restore platform definition for ADL-P(MattR)
- Move back intel_qgv_point def to intel_bw.c(Jani)
v3:
- Rebase
Imre Deak [Fri, 2 Sep 2022 06:03:37 +0000 (23:03 -0700)]
drm/i915/mtl: Add display power wells
Add support for display power wells on MTL. The differences from XE_LPD:
- The AUX HW block is moved to the PICA block, where the registers are on
an always-on power well and the functionality needs to be powered on/off
via the AUX_CH_CTL register: [1], [2]
- The DDI IO power on/off programming sequence is moved to the PHY PLL
enable/disable sequence. [3], [4], [5]
Add tables to map the GMBUS pin pairs to GPIO registers and port to DDC.
From spec we have registers GPIO_CTL[1-5] mapped to native display phys and
GPIO_CTL[9-12] are mapped to TC ports.
drm/i915: Move display and media IP version to runtime info
Future platforms can read the IP version from a register and the
IP version numbers need not be hard coded in device info. Move the
ip version for media and display to runtime info.
On platforms where hard coding of IP version is required, update
the IP version in __runtime under device_info.
v2:
- Avoid name collision for ip versions(Jani)
v4.1:
- Fix build error in mock_gem_device.c
v4.2:
- Use ip instead of version for ip_vesion member.(MattR)
Dave Airlie [Sun, 11 Sep 2022 11:46:57 +0000 (21:46 +1000)]
Merge tag 'drm-misc-next-2022-09-09' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
drm-misc-next for v6.1-rc1:
[airlied - fix sun4i_tv build]
UAPI Changes:
- Hide unregistered connectors from GETCONNECTOR ioctl.
- drm/virtio no longer advertises LINEAR modifier, as it doesn't work.
-
Cross-subsystem Changes:
- Fix GPF in udmabuf failure path.
Core Changes:
- Rework TTM placement to use intersect/compatible functions.
- Drop legacy DP-MST support.
- More DP-MST related fixes, and move all state into atomic.
- Make DRM_MIPI_DBI select DRM_KMS_HELPER.
- Add audio_infoframe packing for DP.
- Add logging when some atomic check functions fail.
- Assorted documentation updates and fixes.
Driver Changes:
- Assorted cleanups and fixes in msm, lcdif, nouveau, virtio,
panel/ilitek, bridge/icn6211, tve200, gma500, bridge/*, panfrost, via,
bochs, qxl, sun4i.
- Add add AUO B133UAN02.1, IVO M133NW4J-R3, Innolux N120ACA-EA1 eDP panels.
- Improve DP-MST modeset state handling in amdgpu, nouveau, i915.
- Drop DP-MST from radeon driver, it was broken and only user of legacy
DP-MST.
- Handle unplugging better in vc4.
- Simplify drm cmdparser tests.
- Add DP support to ti-sn65dsi86.
- Add MT8195 DP support to mediatek.
- Support RGB565, XRGB64, and ARGB64 formats in vkms.
- Convert sun4i tv support to atomic.
- Refactor vc4/vec TV Modesetting, and fix timings.
- Use atomic helpers instead of simple display helpers in ssd130x.
Maintainer changes:
- Add Douglas Anderson as reviewer for panel-edp.
Ville Syrjälä [Thu, 8 Sep 2022 19:16:45 +0000 (22:16 +0300)]
drm/i915: Extract skl_watermark.c
Pull all the skl+ watermark code (and the dbuf/sagv/ipc code
since it's all sort of intertwined and I'm too lazy to think
of a finer grained split right now) into its own file from the
catch-all intel_pm.c.
Also sneak in the s/dev_priv/i915/ rename while at it.
Imre Deak [Wed, 7 Sep 2022 14:25:42 +0000 (17:25 +0300)]
drm/dp_mst: Avoid deleting payloads for connectors staying enabled
When an MST connector stays enabled during a commit the connector's MST
state needs to be added to the atomic state, but the corresponding MST
payload allocation shouldn't be set for deletion; fix such modesets by
ensuring the above even if the connector was already enabled before the
modeset.
projects / users / dwmw2 / linux.git / log