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
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220922191314.4252-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
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
Reported-by: Lee Shawn C <shawn.c.lee@intel.com>
Fixes: b000abd3b3 ("drm/i915: Do .crtc_compute_clock() earlier")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220922191236.4194-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Commit 00c6cbfd4e ("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.
[1] https://lore.kernel.org/r/dfda1bf67f02ceb07c280b7a13216405fd1f7a34.1660137416.git.jani.nikula@intel.com
Fixes: 00c6cbfd4e ("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
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.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220622155452.32587-5-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
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().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220912111814.17466-14-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
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)
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220916014648.1310346-2-radhakrishna.sripada@intel.com
drm_plane_state->src is modified when offset is calculated:
before calculation:
src.x1 = 8192, src.y1 = 8192
after calculation (pitch = 65536, cpp = 4, alignment = 262144)
src.x1 = 8192, src.y1 = 0, offset = 0x20000000
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.
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220823112920.352563-3-jouni.hogander@intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
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().
Fixes: 665a7b0409 ("drm/i915: Feed the DPLL output freq back into crtc_state")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220909205932.32537-1-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
