- 04 Oct, 2022 2 commits
-
-
Ville Syrjälä authored
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. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221003113249.16213-7-ville.syrjala@linux.intel.comReviewed-by:
Jani Nikula <jani.nikula@intel.com>
-
Ville Syrjälä authored
Only report DRRS capability for the connector if its fixed_modes list contains at least two modes capable of seamless DRRS switch between them. Signed-off-by:
-
- 03 Oct, 2022 12 commits
-
-
Ville Syrjälä authored
Grab the crtc mutex so that looking at the crtc state is actually safe. Reviewed-by:
-
Ville Syrjälä authored
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. Reviewed-by:
-
Ville Syrjälä authored
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. Reviewed-by:
-
Ville Syrjälä authored
Move the DRRS debugfs stuff next to the actual implementation so that it's easier to deal with the whole. Reviewed-by:
-
Ville Syrjälä authored
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. Fixes: 0ff0e219 ("drm/i915: Compute clocks earlier") Signed-off-by:
-
Ville Syrjälä authored
Replace the huge modifier lists in the watermark code with a few calls to intel_fb.c. Reviewed-by:
Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Signed-off-by:
-
Ville Syrjälä authored
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. Cc: stable@vger.kernel.org Fixes: 680025dc ("drm/i915/dg2: Add support for DG2 clear color compression") Reviewed-by:
-
Ville Syrjälä authored
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. Cc: stable@vger.kernel.org Fixes: 4c3afa72 ("drm/i915/dg2: Add support for DG2 render and media compression") Reviewed-by:
-
Ville Syrjälä authored
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. Cc: stable@vger.kernel.org Fixes: d1e2775e ("drm/i915/tgl: Add Clear Color support for TGL Render Decompression") Reviewed-by:
-
Ville Syrjälä authored
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. v2: Split RC CCS vs. MC CCS to separate patches Cc: stable@vger.kernel.org Fixes: 2dfbf9d2 ("drm/i915/tgl: Gen-12 display can decompress surfaces compressed by the media engine") Reviewed-by:
-
Ville Syrjälä authored
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. v2: Split RC CCS vs. MC CCS to separate patches Cc: stable@vger.kernel.org Fixes: b3e57bcc ("drm/i915/tgl: Gen-12 render decompression") Reviewed-by:
-
Jouni Högander authored
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: 8241cfbe ("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:
-
- 30 Sep, 2022 6 commits
-
-
Ville Syrjälä authored
Print out on which pipes, and for what reason, we are forcing a full modeset. Signed-off-by:
-
Ville Syrjälä authored
Make glk_load_degamma_lut() more like most everyone else and pass in the LUT explicitly. Signed-off-by:
-
Ville Syrjälä authored
Remove a bunch of pointless curly brackets and do the s/dev_priv/i915/ while at it. Signed-off-by:
-
Ville Syrjälä authored
Get rid of the funny hsw vs. ivb extra indentation level in intel_color_init_hooks(). Signed-off-by:
-
Ville Syrjälä authored
intel_color_init() does both device level and crtc level stuff. Split it up accordingly. Signed-off-by:
-
Ville Syrjälä authored
.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. Signed-off-by:
-
- 28 Sep, 2022 3 commits
-
-
Ville Syrjälä authored
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. Signed-off-by:
-
Ville Syrjälä authored
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. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6323 Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6484Signed-off-by:
-
Ville Syrjälä authored
Since commit a5810f55 ("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. Signed-off-by:
-
- 27 Sep, 2022 3 commits
-
-
Alan Previn authored
Add firmware status using a drm_warn when ARB session fails or else a drm_dbg when the ARB session register slot bit did get set. Signed-off-by:
Alan Previn <alan.previn.teres.alexis@intel.com> Reviewed-by:
Juston Li <justonli@chromium.org> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220923064542.415252-2-alan.previn.teres.alexis@intel.com
-
Ville Syrjälä authored
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... Fixes: f2c9df10 ("drm/i915: Round TMDS clock to nearest") Signed-off-by:
-
Imre Deak authored
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. Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220922172148.2913088-1-imre.deak@intel.com
-
- 26 Sep, 2022 14 commits
-
-
Ville Syrjälä authored
Each PLL knows its own ID so intel_get_shared_dpll_id() is pointless. Get rid of it. Signed-off-by:
-
Ville Syrjälä authored
Initialize the dll.lock mutex whether or not we manage to initialize the rest of the dpll mgr. Signed-off-by:
-
Ville Syrjälä authored
Spew a WARN if we try to ref/unref the same DPLL multiple times for the same pipe. Signed-off-by:
-
Ville Syrjälä authored
We currently have a debug message in intel_reference_shared_dpll() but no counterpart in intel_unreference_shared_dpll(). Add one. Switch to the [CRTC:...] notation for the pipe name while at it. v2: Use drm_dbg_kms() instead of drm_dbg() (Jani) Signed-off-by:
-
Ville Syrjälä authored
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ä authored
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: b000abd3 ("drm/i915: Do .crtc_compute_clock() earlier") Signed-off-by:
-
Jani Nikula authored
Commit 00c6cbfd ("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: 00c6cbfd ("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:
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ä authored
Let's not forget to mark the unused watermark levels as invalid after the readout. The vlv/chv codepath has this but the g4x didn't for some reason. Signed-off-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
-
Ville Syrjälä authored
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ä authored
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. Signed-off-by:
-
Ville Syrjälä authored
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. Signed-off-by:
Stanislav Lisovskiy <stanslav.lisovskiy@intel.com>
-
Ville Syrjälä authored
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. Reviewed-by:
-
Ville Syrjälä authored
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ä authored
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. Signed-off-by:
-
