aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-03-08drm/i915: Call primary encoder's .get_config() from MST .get_config()Ville Syrjälä1-1/+1
Stop assuming intel_ddi_get_config() is all we need from the primary encoder, and instead call it via the .get_config() vfunc. This will allow customized .get_config() for the primary, which I plan to use to handle the differences in the clock readout between various platforms. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210224144214.24803-2-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2021-03-05drm/i915: Fix DSI TE max_vblank_count handlingVille Syrjälä1-3/+2
commit 33267703df15 ("drm/i915/dsi: Enable software vblank counter") claims to get the mode_flags from the crtc_state, but in fact does not. Fix it to do it right. Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210304170421.10901-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2021-03-05drm/i915: Return zero as the scanline counter for disabled pipesVille Syrjälä1-1/+1
We print the scanline counters as unsigned integers so the -1 here just makes the debugs/traces look a bit messy. Zero seems equally valid for this usecase. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210304170421.10901-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2021-03-05drm/i915: Don't try to query the frame counter for disabled pipesVille Syrjälä1-0/+3
For platforms/outputs without hardware frame counters we can't call drm_crtc_accurate_vblank_count() when the vblank support is disabled or we just get a WARN due to the crtc timings (vblank->hwmode) being considered invalid. Note that until the pipe in question has been enabled and drm_crtc_set_max_vblank_count() has been called on it we would also take this path on platforms which have a working frame counter. So getting the WARN is rather likely on any platform unless you always boot with lots of displays plugged in. Also even on hardware with a working frame counter we may not be able to read the actual frame counter register on disabled pipes due the relevant power well being disabled. Ie. would just result in the unclaimed reg spew. So let's just avoid all this an directly report zero in case the pipe is disabled. Reported-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Tested-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210304170421.10901-3-ville.syrjala@linux.intel.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2021-03-05drm/i915: Move pipe enable/disable tracepoints to intel_crtc_vblank_{on,off}()Ville Syrjälä3-10/+15
On platforms/outputs without a working frame counter we rely on the vblank code to cook up the frame counter from the timestamps. That requires that vblank support is enabled. Thus we need to move the pipe enable/disable tracepoints to the other side of the drm_vblank_{on,off}() calls. There shouldn't really be much happening between these old and new call sites so the tracepoints should still provide reasonable data. The alternative would be to give up on having the frame counter values in the trace which would render the tracepoints more or less pointless. v2: Missed one case in intel_ddi_post_disable() Drop the now useless i915_trace.h includes Reported-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Tested-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210304170421.10901-2-ville.syrjala@linux.intel.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2021-03-04drm/i915/edp: enable eDP MSO during link trainingJani Nikula3-4/+89
If the source and sink support MSO, enable it during link training. v4: Divide DRRS pixel clock by link count before M/N calculation v3: Adjust timings, refer to splitter v2: Limit MSO to pipe A using ->pipe_mask Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2711 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/66da48b4b3c5ccffaac7989097cd96d6c6af8243.1614682842.git.jani.nikula@intel.com
2021-03-04drm/i915/edp: modify fixed and downclock modes for MSOJani Nikula1-0/+29
In the case of MSO (Multi-SST Operation), the EDID contains the timings for a single panel segment. We'll want to hide the fact from userspace, and expose modes that span the entire display. Don't modify the EDID, as the userspace should not use that for modesetting, only modify the actual modes. v3: Use pixel overlap if available. v2: Rename intel_dp_mso_mode_fixup -> intel_edp_mso_mode_fixup 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/2862284eb033bb0ffc96134b7d5b11bf29e4587f.1614682842.git.jani.nikula@intel.com
2021-03-04drm/i915/mso: add splitter state checkJani Nikula1-0/+4
For starters, we expect the state to be zero, as we don't enable MSO anywhere. v2: Refer to splitter. 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/459a332f3cdce941c57312150872559db68f88c1.1614682842.git.jani.nikula@intel.com
2021-03-04drm/i915/mso: add splitter state readout for platforms that support itJani Nikula4-2/+79
Add splitter configuration to crtc state, and read it where supported. Also add splitter state dumping. The stream splitter will be required for eDP MSO. v4: - Catch invalid splitter configuration (Uma) v3: - Convert segment timings to full panel timings. - Refer to splitter instead of mso in crtc state. - Dump splitter state. v2: Add warning for mso being enabled on pipes other than A. Cc: Nischal Varide <nischal.varide@intel.com> Cc: Uma Shankar <uma.shankar@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/95cbe1c9d45edf3e3ec252e49fb49055def98155.1614682842.git.jani.nikula@intel.com
2021-03-03drm/i915: Clean up verify_wm_state()Ville Syrjälä2-76/+17
Get rid of the nonsense cursor special case in verify_wm_state() by just iterating through all the planes. And let's use the canonical [PLANE:..] style in the debug prints while at it. 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-8-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2021-03-03drm/i915: Check tgl+ SAGV watermarks properlyVille Syrjälä3-50/+47
We know which WM0 (normal vs. SAGV) we supposedly programmed into the hardware, so just check against that instead of accepting either watermark as valid. 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-7-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2021-03-03drm/i915: Introduce SAGV transtion watermarkVille Syrjälä3-34/+65
Seems to me that if we calculate WM0 using the bumped up SAGV latency we need to calculate the transition watermark accordingly. Track it alongside the other watermarks. 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-6-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2021-03-03drm/i915: Stuff SAGV watermark into a sub-structureVille Syrjälä3-18/+20
We'll want a SAGV transition watermark as well. Prepare for that by collecting SAGV wm0 into a sub-strcture. 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-5-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2021-03-03drm/i915: Print wm changes if sagv_wm0 changesVille Syrjälä1-1/+2
Let's consider sagv_wm0 as well when deciding whether to dump out the watermark changes. 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-4-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2021-03-03drm/i915: Zero out SAGV wm when we don't have enough DDB for itVille Syrjälä1-5/+6
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.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2021-03-03drm/i915: Fix TGL+ plane SAGV watermark programmingVille Syrjälä1-23/+37
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210226153204.1270-2-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2021-03-03drm/i915: Readout conn_state->max_bpcVille Syrjälä1-8/+16
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: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210216160035.4780-1-ville.syrjala@linux.intel.com Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2021-03-02drm/i915/icp+: Use icp_hpd_irq_setup() instead of spt_hpd_irq_setup()Lyude Paul1-0/+2
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
2021-03-02drm/i915/gen9bc: Handle TGP PCH during suspend/resumeTejas Upadhyay1-17/+32
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: Lyude Paul <lyude@redhat.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210217180016.1937401-1-lyude@redhat.com
2021-02-24drm/i915/tgl+: Sanitize the DDI LANES/IO and AUX power domain namesImre Deak2-114/+130
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: Imre Deak <imre.deak@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210222210400.940158-1-imre.deak@intel.com
2021-02-23drm/i915/display: Do not allow DC3CO if PSR SF is enabledGwan-gyeong Mun1-0/+7
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: 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/20210222213006.1609085-1-gwan-gyeong.mun@intel.com
2021-02-22drm/i915/reg: add stream splitter configuration definitionsJani Nikula1-0/+3
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
2021-02-22drm/i915/edp: read sink MSO configuration for eDP 1.4+Jani Nikula2-0/+35
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: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/24ef61574e5af12cd86d5b85afbfbd4ac2f9de25.1613054234.git.jani.nikula@intel.com
2021-02-22drm/i915/edp: always add fixed mode to probed modes in ->get_modes()Jani Nikula1-7/+9
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: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/6979f123f3e4ed948333f1b181202bbced3c3e85.1613054234.git.jani.nikula@intel.com
2021-02-22drm/i915/edp: reject modes with dimensions other than fixed modeJani Nikula1-2/+2
Be more strict about filtering modes for eDP. 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/feb4c3b2b9c4da56a840bdb3c0e7fd0e58ee50de.1613054234.git.jani.nikula@intel.com
2021-02-22drm/dp: add MSO related DPCD registersJani Nikula1-0/+5
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: Uma Shankar <uma.shankar@intel.com> Acked-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ab57627f373ec4a80494bb51ea51080810d9bfb0.1613054234.git.jani.nikula@intel.com
2021-02-22drm/i915/display: Set source_support even if panel do not support PSRJosé Roberto de Souza1-3/+0
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 <jose.souza@intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210209181439.215104-4-jose.souza@intel.com
2021-02-22drm/i915/display: Remove some redundancy around CAN_PSR()José Roberto de Souza3-6/+5
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 <jose.souza@intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210209181439.215104-3-jose.souza@intel.com
2021-02-22drm/i915/display: Only write to register in ↵José Roberto de Souza1-12/+2
intel_psr2_program_trans_man_trk_ctl() 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 <jose.souza@intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210209181439.215104-2-jose.souza@intel.com
2021-02-22drm/i915/display: Rename for_each_intel_encoder.*_can_psr to ↵José Roberto de Souza4-13/+13
for_each_intel_encoder.*_with_psr 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 <jose.souza@intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210209181439.215104-1-jose.souza@intel.com
2021-02-22drm/i915/display: Allow PSR2 selective fetch to be enabled at run-timeJosé Roberto de Souza2-3/+6
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: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210209205036.351076-1-jose.souza@intel.com
2021-02-20drm/i915/vbt: update DP max link rate tableLee Shawn C2-21/+60
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: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210218052333.16109-1-shawn.c.lee@intel.com
2021-02-18drm/i915: Wait for scanout to stop when sanitizing planesVille Syrjälä1-0/+1
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210217162050.13803-1-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2021-02-18drm/i915: Nuke INTEL_OUTPUT_FORMAT_INVALIDVille Syrjälä3-4/+1
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: 0aa5c3835c8a ("drm/i915: support two CSC module on gen11 and later") Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2964 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210205202322.27608-1-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2021-02-17drm/i915: Remove dead code from skl_pipe_wm_get_hw_state()José Roberto de Souza1-3/+0
There is nothing else to be executed after this if block. Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210212182201.155043-2-jose.souza@intel.com
2021-02-17drm/i915: Enable -WuninitializedNathan Chancellor1-1/+0
-Wunintialized was disabled in commit c5627461490e ("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: c5627461490e ("drm/i915: Disable -Wuninitialized") References: 2ea4a7ba9bf6 ("drm/i915/gt: Avoid uninitialized use of rpcurupei in frequency_show") References: 2034c2129bc4 ("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: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20210216212953.24458-1-nathan@kernel.org
2021-02-16drm/i915: s/dev_priv/i915/ for the remainder of DDI clock routingVille Syrjälä1-19/+19
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: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210205214634.19341-16-ville.syrjala@linux.intel.com Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
2021-02-16drm/i915: Relocate icl_sanitize_encoder_pll_mapping()Ville Syrjälä1-56/+56
Move icl_sanitize_encoder_pll_mapping() out from the middle of the .{enable,disable}_clock() functions. Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210205214634.19341-15-ville.syrjala@linux.intel.com
2021-02-16drm/i915: Use .disable_clock() for pll sanitationVille Syrjälä2-90/+3
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: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210205214634.19341-14-ville.syrjala@linux.intel.com
2021-02-16drm/i915: Split adl-s/rkl from icl_ddi_combo_{enable,disable}_clock()Ville Syrjälä1-29/+62
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: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210205214634.19341-13-ville.syrjala@linux.intel.com
2021-02-16drm/i915: Extract _cnl_ddi_{enable,disable}_clock()Ville Syrjälä1-64/+44
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: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210205214634.19341-12-ville.syrjala@linux.intel.com
2021-02-16drm/i915: Sprinkle WARN(!pll) into icl/dg1 .clock_enable()Ville Syrjälä1-0/+6
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: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210205214634.19341-11-ville.syrjala@linux.intel.com
2021-02-16drm/i915: Sprinkle a few missing locks around shared DDI clock registersVille Syrjälä1-0/+8
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: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210205214634.19341-10-ville.syrjala@linux.intel.com
2021-02-16drm/i915: Use intel_de_rmw() for DDI clock routingVille Syrjälä1-49/+28
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: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210205214634.19341-9-ville.syrjala@linux.intel.com
2021-02-16drm/i915: Extract icl+ .{enable,disable}_clock() vfuncsVille Syrjälä1-58/+99
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: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210205214634.19341-8-ville.syrjala@linux.intel.com
2021-02-16drm/i915: Convert DG1 over to .{enable,disable}_clock()Ville Syrjälä1-22/+21
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: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210205214634.19341-7-ville.syrjala@linux.intel.com
2021-02-16drm/i195: Extract cnl_ddi_{enable,disable}_clock()Ville Syrjälä1-20/+42
Extract the DDI clock routing for CNL into the new vfuncs. v2: s/dev_priv/i915/ (Lucas) Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210205214634.19341-6-ville.syrjala@linux.intel.com
2021-02-16drm/i915: Extract skl_ddi_{enable,disable}_clock()Ville Syrjälä1-15/+38
Extract the DDI clock routing clode for skl/derivatives into the new encoder vfuncs. v2: s/dev_priv/i915/ (Lucas) Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210205214634.19341-5-ville.syrjala@linux.intel.com
2021-02-16drm/i915: Extract hsw_ddi_{enable,disable}_clock()Ville Syrjälä3-6/+31
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210205214634.19341-4-ville.syrjala@linux.intel.com
2021-02-16drm/i915: Introduce .{enable,disable}_clock() encoder vfuncsVille Syrjälä4-9/+32
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210205214634.19341-3-ville.syrjala@linux.intel.com
Powered by cgit, Gruvboxed by Blaster4385.