- 28 Sep, 2022 1 commit
-
-
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:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220927180615.25476-2-ville.syrjala@linux.intel.comReviewed-by:
Jani Nikula <jani.nikula@intel.com>
-
- 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 25 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:
-
Ville Syrjälä authored
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. Signed-off-by:
-
Ville Syrjälä authored
We have an eDP specific intel_edp_add_properties() so move the eDP scaling_mode property setup there from intel_dp_add_properties(). Signed-off-by:
-
Ville Syrjälä authored
Move the LVDS connector property setup to a dedicated function to depollute intel_lvds_init() a bit. Signed-off-by:
-
Ville Syrjälä authored
Move the DP MST connector property setup into its own function so it's not spread all over intel_dp_add_mst_connector(). Signed-off-by:
-
Ville Syrjälä authored
Pull all the TV connector property setup into its own neat function. Signed-off-by:
-
Ville Syrjälä authored
Pull the eDP backlight setup into its own function. No reason to pollute intel_edp_init_connector() with all the mundane details. Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Reviewed-by:
-
Ville Syrjälä authored
Most of our encoder type cast stuff already operates on intel_encoder rather than drm_encoder. Switch to_lvds_encoder() over as well. Signed-off-by:
-
Ville Syrjälä authored
Most places that deal with output types already use BIT() but a few places still use manual shifts. Convert the stragglers over to BIT(). Signed-off-by:
-
Ville Syrjälä authored
Just return the thing directly from the switch statement. Signed-off-by:
-
Ville Syrjälä authored
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. Signed-off-by:
-
Ville Syrjälä authored
No need for the 'procmon' variable here. Just return the correct thing from the switch statement directly. Signed-off-by:
-
- 24 Sep, 2022 4 commits
-
-
Gustavo Sousa authored
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. CC: Jani Nikula <jani.nikula@linux.intel.com> CC: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by:
-
Niranjana Vishwanathapura authored
The function parameter 'exclude' in funciton i915_sw_fence_await_reservation() is not used. Remove it. Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220922213916.12112-1-niranjana.vishwanathapura@intel.com
-
José Roberto de Souza authored
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:
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 authored
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:
-
- 23 Sep, 2022 2 commits
-
-
Ville Syrjälä authored
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 691f7ba5 ("drm/i915/display/fbc: Make fences a nice-to-have for GEN9+") Also fix up the multiline comment formatting while at it. Signed-off-by:
-
Ville Syrjälä authored
The plane ratio stuff got implemented in commit bb6ae9e6 ("drm/i915: Allow planes to declare their minimum acceptable cdclk") so these FIXMEs have no business being here. Signed-off-by:
-
- 20 Sep, 2022 2 commits
-
-
Ville Syrjälä authored
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. Signed-off-by:
-
Ville Syrjälä authored
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 b39d2c62 ("drm/i915/fbc: Call intel_fbc_activate() directly from frontbuffer flush") Signed-off-by:
-
- 19 Sep, 2022 3 commits
-
-
Ville Syrjälä authored
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. v2: Move to print_ddi_port() (Jani) Reviewed-by:
-
Jani Nikula authored
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. Fixes: 70296670 ("drm/i915/display: move IPC under display wm sub-struct") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Jani Nikula authored
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. Signed-off-by:
-
