- 03 Mar, 2021 3 commits
-
-
Ville Syrjälä authored
Let's handle the SAGV WM0 more like the other wm levels and just totally zero it out when we don't have the DDB space to back it up. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210226153204.1270-3-ville.syrjala@linux.intel.comReviewed-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
-
Ville Syrjälä authored
When we switch between SAGV on vs. off we need to reprogram all plane wateramrks accordingly. Currently skl_wm_add_affected_planes() totally ignores the SAGV watermark and just assumes we will use the normal WM0. Fix this by utilizing skl_plane_wm_level() which picks the correct watermark based on use_sagv_wm. Thus we will force an update on all the planes whose watermark registers need to be reprogrammed. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Populate conn_state->max_bpc with something sensible from the start. Otherwise it's possible that we get to compute_sink_pipe_bpp() with max_bpc==0. The specific scenario goes as follows: 1. Initial connector state allocated with max_bpc==0 2. Trigger a modeset on the crtc feeding the connector, without actually adding the connector to the commit 3. drm_atomic_connector_check() is skipped because the connector has not yet been added, hence conn_state->max_bpc retains its current value 4. drm_atomic_helper_check_modeset() -> drm_atomic_add_affected_connectors() -> the connector is now part of the commit 5. compute_baseline_pipe_bpp() -> MISSING_CASE(max_bpc==0) Note that pipe_bpp itself may not be populated on pre-g4x machines, in which case we just fall back to max_bpc==8 and let .compute_config() limit the resulting pipe_bpp further if necessary. Cc: Daniel Vetter <daniel@ffwll.ch> Reported-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com>
-
- 02 Mar, 2021 2 commits
-
-
Lyude Paul authored
While reviewing patches for handling workarounds related to gen9 bc, Imre from Intel discovered that we're using spt_hpd_irq_setup() on ICP+ PCHs despite it being almost the same as icp_hpd_irq_setup(). Since we need to be calling icp_hpd_irq_setup() to ensure that CML-S/TGP platforms function correctly anyway, let's move platforms using PCH_ICP which aren't handled by gen11_hpd_irq_setup() over to icp_hpd_irq_setup(). Cc: Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com> Signed-off-by:
Lyude Paul <lyude@redhat.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210217025337.1929015-2-lyude@redhat.com
-
Tejas Upadhyay authored
For Legacy S3 suspend/resume GEN9 BC needs to enable and setup TGP PCH. v2: * Move Wa_14010685332 into it's own function - vsyrjala * Add TODO comment about figuring out if we can move this workaround - imre v3: * Rename cnp_irq_post_reset() to cnp_display_clock_wa() * Add TODO item mentioning we need to clarify which platforms this workaround applies to * Just use ibx_irq_reset() in gen8_irq_reset(). This code should be functionally equivalent on gen9 bc to the code v2 added * Drop icp_hpd_irq_setup() call in spt_hpd_irq_setup(), this looks to be more or less identical to spt_hpd_irq_setup() minus additionally enabling one port. Will update i915 to use icp_hpd_irq_setup() for ICP in a separate patch. v4: * Revert Wa_14010685332 system list in comments to how it was before * Add back HAS_PCH_SPLIT() check before calling ibx_irq_reset() Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210217180016.1937401-1-lyude@redhat.com
-
- 24 Feb, 2021 1 commit
-
-
Imre Deak authored
In Bspec the TGL TypeC ports are TC1-6, the AUX power well request flags are USBC1-6/TBT1-6, so for clarity use these names in the port power domain names instead of the D-I terminology (which Bspec uses only for the ICL TypeC ports). A domain name should follow the <domain>_<pipe/transcoder/port/aux_ch> format. Add the new aliases based on this, leaving a change to rename all the rest accordingly for a follow-up. No functional change. v2: Add comment to commit log about unifying domain names. (Jose) Cc: Souza Jose <jose.souza@intel.com> Signed-off-by:
-
- 23 Feb, 2021 1 commit
-
-
Gwan-gyeong Mun authored
Even though GEN12+ HW supports PSR + DC3CO, DMC's HW DC3CO exit mechanism has an issue with using of Selective Fecth and PSR2 manual tracking. And as some GEN12+ platforms (RKL, ADL-S) don't support PSR2 HW tracking, Selective Fetch will be enabled by default on that platforms. Therefore if the system enables PSR Selective Fetch / PSR manual tracking, it does not allow DC3CO dc state, in that case. When this DC3CO exit issue is addressed while PSR Selective Fetch is enabled, this restriction should be removed. v2: Address Jose's review comment. - Fix typo - Move check routine of DC3CO ability to tgl_dc3co_exitline_compute_config() v3: Change the check routine of enablement of psr2 sel fetch. (Jose) Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by:Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by:
-
- 22 Feb, 2021 10 commits
-
-
Jani Nikula authored
The splitter configuration is required for eDP MSO. Bspec: 50174 Cc: Nischal Varide <nischal.varide@intel.com> Reviewed-by:
Uma Shankar <uma.shankar@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/443ad1fbf908800ee4e09315cb6a7ba26c64d136.1613054234.git.jani.nikula@intel.com
-
Jani Nikula authored
Read and debug log the eDP sink MSO configuration. Do not actually do anything with the information yet besides logging. FIXME: The pixel overlap is present in DisplayID 2.0, but we don't have parsing for that. Assume zero for now. We could also add quirks for non-zero pixel overlap before DisplayID 2.0 parsing. v3: Add placeholder for pixel overlap. v2: Rename intel_dp_mso_init -> intel_edp_mso_init Cc: Nischal Varide <nischal.varide@intel.com> Reviewed-by:
-
Jani Nikula authored
Unconditionally add fixed mode to probed modes even if EDID is present and has modes. Prepare for cases where the fixed mode is not present in EDID (such as eDP MSO). Cc: Nischal Varide <nischal.varide@intel.com> Reviewed-by:
-
Jani Nikula authored
Be more strict about filtering modes for eDP. Cc: Nischal Varide <nischal.varide@intel.com> Reviewed-by:
-
Jani Nikula authored
Add DPCD register definitions for eDP 1.4 Multi-SST Operation. Cc: Nischal Varide <nischal.varide@intel.com> Cc: dri-devel@lists.freedesktop.org Reviewed-by:
Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
José Roberto de Souza authored
This will set the right value of source_support when the port encoder/port supports PSR but sink don't. This change will also be needed in future for panel replay as psr struct needs to be initialized even if disconnected or current sink don't support PSR. Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by:
-
José Roberto de Souza authored
If source_support is set the platform supports PSR so no need to check it again at every CAN_PSR(). Also removing the intel_dp_is_edp() calls, if sink_support is set the sink connected is for sure a eDP panel. Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by:
-
José Roberto de Souza authored
There is no support for two pipes one transcoder for PSR and if we had that the current code should not use cpu_transcoder. Also I can't see a scenario where crtc_state->enable_psr2_sel_fetch is set and PSR is not enabled and if by a bug it happens PSR HW will just ignore any value in set in PSR2_MAN_TRK_CTL. So dropping all the rest and keeping the same behavior that we have with intel_psr2_program_plane_sel_fetch(). Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by:
-
José Roberto de Souza authored
for_each_intel_encoder.*_"can_psr" sounds strange, in my opinion "with_psr" is better. Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by:
-
José Roberto de Souza authored
Right now CI is blacklisting module reload, so we need to be able to enable PSR2 selective fetch in run time to test this feature before enable it by default. Changes in IGT will also be needed. v2: - Fixed handling of I915_PSR_DEBUG_ENABLE_SEL_FETCH in intel_psr_debug_set() Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by:
-
- 20 Feb, 2021 1 commit
-
-
Lee Shawn C authored
According to Bspec #20124, max link rate table for DP was updated at BDB version 230. Max link rate can support upto UHBR. After migrate to BDB v230, the definition for LBR, HBR2 and HBR3 were changed. For backward compatibility. If BDB version was from 216 to 229. Driver have to follow original rule to configure DP max link rate value from VBT. v2: split the mapping table to two for old and new BDB definition. v3: return link rate instead of assigning it. v4: remove the useless variable. Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Cooper Chiou <cooper.chiou@intel.com> Cc: William Tseng <william.tseng@intel.com> Signed-off-by:
Lee Shawn C <shawn.c.lee@intel.com> [vsyrjala: Try to retain the comment that VBT version 216 added some of this] Signed-off-by:
-
- 18 Feb, 2021 2 commits
-
-
Ville Syrjälä authored
When we sanitize planes let's wait for the scanout to stop before we let the subsequent code tear down the ggtt mappings and whatnot. Cures an underrun on my ivb when I boot with VT-d enabled and the BIOS fb gets thrown out due to stolen being considered unusable with VT-d active. Signed-off-by:
-
Ville Syrjälä authored
We tend to use output_format!=RGB as a shorthand for YCbCr, but this fails if we have a disabled crtc where output_format==INVALID. We're now getting some fail from intel_color_check() when we have: hw.enable==false hw.ctm!=NULL output_format==INVALID Let's avoid that by throwing INTEL_OUTPUT_FORMAT_INVALID to the dumpster, and thus everything defaults to RGB when the crtc is disabled. This does beg the deeper question of how much of the state should we in fact be validating when hw/uapi.enable==false. And should we even be doing the uapi->hw copy when uapi.enable==false? So far I've not been able to come up with satisfactory answers for myself, so I'm putting it off for the moment. Cc: Lee Shawn C <shawn.c.lee@intel.com> Fixes: 0aa5c383 ("drm/i915: support two CSC module on gen11 and later") Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2964Signed-off-by:
-
- 17 Feb, 2021 2 commits
-
-
José Roberto de Souza authored
There is nothing else to be executed after this if block. Signed-off-by:
-
Nathan Chancellor authored
-Wunintialized was disabled in commit c5627461 ("drm/i915: Disable -Wuninitialized") because there were two warnings that were false positives. The first was due to DECLARE_WAIT_QUEUE_HEAD_ONSTACK, which was fixed in LLVM 9.0.0. The second was in busywait_stop, which was fixed in LLVM 10.0.0 (issue 415). The kernel's minimum version for LLVM is 10.0.1 so this warning can be safely enabled, where it has already caught a couple bugs. Link: https://github.com/ClangBuiltLinux/linux/issues/220 Link: https://github.com/ClangBuiltLinux/linux/issues/415 Link: https://github.com/ClangBuiltLinux/linux/issues/499 Link: https://github.com/llvm/llvm-project/commit/2e040398f8d691cc378c1abb098824ff49f3f28f Link: https://github.com/llvm/llvm-project/commit/c667cdc850c2aa821ffeedbc08c24bc985c59edd Fixes: c5627461 ("drm/i915: Disable -Wuninitialized") References: 2ea4a7ba ("drm/i915/gt: Avoid uninitialized use of rpcurupei in frequency_show") References: 2034c212 ("drm/i915/display: Ensure that ret is always initialized in icl_combo_phy_verify_state") Reported-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Nathan Chancellor <nathan@kernel.org> Reviewed-by:
-
- 16 Feb, 2021 15 commits
-
-
Ville Syrjälä authored
Convert the remaining 'dev_priv's to 'i915's in the DDI clock routing functions. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com>
-
Ville Syrjälä authored
Move icl_sanitize_encoder_pll_mapping() out from the middle of the .{enable,disable}_clock() functions. Reviewed-by: -
Ville Syrjälä authored
Instead of every new platform having yet another masive copy of the whole PLL sanitation code, let's just reuse the .disable_clock() hook for this purpose. We do need to plug this into the ICL+ DSI code for that, but fortunately it already has a suitable function we can use. We do lose the debug message though on account of not bothering to check if the clock is actually enabled or not before turning it off. We could introduce yet another vfunc to query the current state, but not sure it's worth the hassle? Reviewed-by:
-
Ville Syrjälä authored
Since .{enable,disable}_clock() are already vfuncs it's a bit silly to have if-ladders inside them. Just provide specialized version for adl-s and rkl so we don't need any of that. v2: s/dev_priv/i915/ (Lucas) Fix typos in platform names (Lucas) Reviewed-by: -
Ville Syrjälä authored
All the DPCLKA_CFGCR handling follows a common pattern. Let's extract that to a small helper that just takes a few parameters each caller can customize. Reviewed-by:
-
Ville Syrjälä authored
The other DDI .enable_clock() functions are trying to protect us against pll==NULL. A bit tempted to throw out all the WARNs as just unnecessary noise, but I guess they might have some use when poking around the shared_dpll code (not sure it wouldn't oops elsewhere though). So let's unify it all and sprinkle in the missing WARNs for icl/dg1. Reviewed-by:
-
Ville Syrjälä authored
The current code attempts to protect the RMWs into global clock routing registers with a mutex, but forgets to do so in a few places. Let's remedy that. Note that at the moment we serialize all modesets onto single wq, so this shouldn't actually matter. But maybe one day we wish to attempt parallel modesets again... Reviewed-by:
-
Ville Syrjälä authored
The DDI clock routing programming is riddled with shared registers, forcing us to do a lot of RMW. Switch over to intel_de_rmw() to make that a bit less obnoxious. Reviewed-by:
-
Ville Syrjälä authored
For ICL+ we have several styles of clock routing for DDIs: 1) TC DDI + TC PHY -> needs DDI_CLK_SEL==MG/TBT part form intel_ddi_clk_{select,disable}() and ICL_DPCLKA_CFGCR0_TC_CLK_OFF part form icl_{map,unmap}_plls_to_ports() 2) ICL/TGL combo DDI + combo PHY -> just need the stuff from icl_{map,unmap}_plls_to_ports() 3) JSL/EHL TC DDI + combo PHY -> needs DDI_CLK_SEL==MG part from intel_ddi_clk_{select,disable}() and the full combo style clock selection from icl_{map,unmap}_plls_to_ports() 4) ADLS/RKL -> these use both TC and combo DDIs with combo PHYs, however they always use the full combo style clock selection as per icl_{map,unmap}_plls_to_ports() and do not use DDI_CLK_SEL at all, thus get treated the same as 2) We extract all that from the current mess in the following way: 1) icl_ddi_tc_{enable,disable}_clock() 2) icl_ddi_combo_{enable,disable}_clock() 3) jsl_ddi_tc_{enable,disable}_clock() 4) for now we reuse icl_ddi_combo_{enable,disable}_clock() here v2: s/dev_priv/i915/ (Lucas) Reviewed-by: -
Ville Syrjälä authored
Replace dg1_{map,unmap}_plls_to_ports() with the appropriate encoder vfuncs. And let's relocate the disable function next to the enable function while at it. Reviewed-by: -
Ville Syrjälä authored
Extract the DDI clock routing for CNL into the new vfuncs. v2: s/dev_priv/i915/ (Lucas) Reviewed-by:
-
Ville Syrjälä authored
Extract the DDI clock routing clode for skl/derivatives into the new encoder vfuncs. v2: s/dev_priv/i915/ (Lucas) Reviewed-by:
-
Ville Syrjälä authored
Yank out the HSW/BDW code from intel_ddi_clk_{select,disable}() and put it into the new encoder .{enable,disable}_clock() vfuncs. v2: s/dev_priv/i915/ (Lucas) v3: Deal with FDI Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> #v2 Signed-off-by: -
Ville Syrjälä authored
The current code dealing with the clock routing for DDI encoders is a maintenance nightmare. Let's start cleaning it up by allowing the encoder to provide vfuncs for enablign/disabling the clock. We leave them initially unimplemented, falling back to the old if-else approach. v2: Convert the FDI enable sequence Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> #v2 Signed-off-by:
-
Ville Syrjälä authored
We want to put all DDI clock routing code into one place. Unify the FDI enable sequence to use the standard function instead of hand rolling its own. The disable sequence already uses the normal thing. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
- 13 Feb, 2021 3 commits
-
-
Lucas De Marchi authored
intel_init_audio_hooks() sets up hooks in the display struct and only makes sense when we have display. Move it inside intel_init_display_hooks() so it isn't called when we don't have display. Signed-off-by:
-
Lucas De Marchi authored
Now that all display-related functions are grouped in i915_driver_register(), move them to display/ so we reduce the amount of display calls from the rest of the driver. Signed-off-by:
-
Lucas De Marchi authored
intel_gt_driver_register() may be called earlier than intel_opregion_register() and acpi_video_register(), so move it up. intel_display_debugfs_register() may be called later, together with the other display-related initializations. There is a slight change in behavior that sysfs files will show up before the display-related debugfs files, but that shouldn't be a problem - userspace shouldn't be relying in debugfs. This allows us to group all the display-related calls under a single check for "HAS_DISPLAY()" that can be later moved to a better place. Signed-off-by:
-
