summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/display
AgeCommit message (Collapse)AuthorFilesLines
2022-04-05drm/i915/dp: Rework HDMI DFP TMDS clock handlingVille Syrjälä1-10/+25
Rework the HDMI DFP TMDS clock checks to also check at 8bpc. Previously we only checked the deep color cases. But I suppose a sink could potentially declare "4:2:0 also" modes that only actually fit within its own limits when using 4:2:0. Even if that is too nuts to be real there is no real harm in running through the full checks for everything. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220322120015.28074-9-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2022-04-05drm/i915/dp: Make intel_dp_output_format() usable for "4:2:0 also" modesVille Syrjälä1-6/+7
Hoist the drm_mode_is_420_only() from intel_dp_output_format() into the caller. This will allow intel_dp_output_format() to be reused for "4:2:0 also" modes. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220322120015.28074-8-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2022-04-05drm/i915/dp: Pass around intel_connector rather than drm_connectorVille Syrjälä1-20/+18
Prefer to use intel_connector over drm_connector. Also clean up the related variable names a bit. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220322120015.28074-7-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2022-04-05drm/i915/dp: Reorder intel_dp_compute_config() a bitVille Syrjälä1-13/+10
Consolidate the double pfit call, and reorder things so that intel_dp_output_format() and intel_dp_compute_link_config() are back-to-back. They are intimately related, and will need to be called twice to properly handle the "4:2:0 also" modes. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220322120015.28074-6-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2022-04-05drm/i915/dp: s/intel_dp_hdmi_ycbcr420/intel_dp_is_ycbcr420/Ville Syrjälä1-3/+3
intel_dp_hdmi_ycbcr420() does account for native DP 4:2:0 output as well, so lets rename it a bit. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220322120015.28074-5-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2022-04-05drm/i915/dp: Extract intel_dp_has_audio()Ville Syrjälä1-10/+20
Declutter intel_dp_compute_config() a bit by moving the has_audio computation into a helper. HDMI already does the same thing. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220322120015.28074-4-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2022-04-05drm/i915/dp: Respect the sink's max TMDS clock when dealing with DP->HDMI DFPsVille Syrjälä1-5/+19
Currently we only look at the DFPs max TMDS clock limit when considering whether the mode is valid, or whether we can do deep color. The sink's max TMDS clock limit may be lower than the DFPs, so we need to account for it as well. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4095 Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2844 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220322120015.28074-3-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2022-04-05drm/i915/dp: Extract intel_dp_tmds_clock_valid()Ville Syrjälä1-33/+26
We're currently duplicating the DFP min/max TMDS clock checks in .mode_valid() and .compute_config(). Extract a helper suitable for both use cases. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220322120015.28074-2-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2022-04-04drm/i915/bios: Extract struct lvds_lfp_data_ptr_tableVille Syrjälä2-11/+12
All the LFP data table pointers have uniform layout. Turn that into a struct. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220317171948.10400-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-04-04drm/i915: Use drm_connector_attach_hdr_output_metadata_property()Ville Syrjälä1-6/+2
Stop hand rolling drm_connector_attach_hdr_output_metadata_property(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220321195006.775-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-03-31drm/i915: Allow static DRRS on LVDSVille Syrjälä1-1/+2
Nothing special about static DRRS on LVDS, it's just your bog standard modeset. Let's allow it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220331112822.11462-12-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-03-31drm/i915: Allow static DRRS on all eDP portsVille Syrjälä1-34/+20
Only seamless DRRS has specific hardware requirements so we can allow static DRRS on any eDP port. And we can replace these port checks and whatnot with a simple check to make sure the transcoder(s) we're about to use are capable of seamless DRRS. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220331112822.11462-11-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com>
2022-03-31drm/i915: Move intel_drrs_compute_config() into intel_dp.cVille Syrjälä3-60/+56
intel_drrs_compute_config() is 100% DP specific. DRRS on other types of encoders wouldn't do any of these M2/N2 calculations etc. So let's move this into intel_dp.c so all the DP state calculation is more concentrated into one place. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220331112822.11462-10-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-03-31drm/i915: Allow higher refresh rate alternate fixed modesVille Syrjälä1-11/+11
We shouldn't restrict ourselves to just downclock modes with lower refresh rate than the preferred mode. Laptops these days can offer higher refresh rate modes as well. Remove the arbitrary limit and allow all modes that, apart from the clock, match the preferred mode. v2: s/add_edid_downclock_modes/add_edid_alt_fixed_modes/ (Jani) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220331112822.11462-9-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-03-31drm/i915: Allow an arbitrary number of downclock modesVille Syrjälä1-30/+12
Remove the "two fixed modes only" limit and grab as many downclock modes from the EDID as we can find. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220331112822.11462-8-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-03-31drm/i915: Stop duplicating the EDID fixed/downclock modesVille Syrjälä1-33/+29
Instead of duplicating the fixed/downclock modes we can just grab the originals straight from the probed_modes list and keep them. The next .get_modes() is going to repopulate the probed_modes list anyway so whatever we leave there is just going to sit around until that time wasting memory. In fact let's clear out the probed modes list entirely to make sure we get 100% consistent behaviour starting already from the very first real .get_modes(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220331112822.11462-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-03-31drm/i915: Combine the EDID fixed_mode+downclock_mode lookup into oneVille Syrjälä5-10/+14
The intel_panel_add_edid_fixed_mode() vs. intel_panel_add_edid_downclock_mode() split is not really helpful. Let's just roll those into a single function so that the connector init code doesn't have to care too much about this. All we need to know is whether DRRS should be allowed or not. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220331112822.11462-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-03-31drm/i915: Nuke intel_drrs_init()Ville Syrjälä4-26/+7
intel_drrs_init() is a mostly pointless wrapper around intel_panel_add_edid_downclock_mode(), get rid of it. The only really useful thing left in there is the debug print regarding the DRRS type supported by the connector. Let's just move that into intel_panel_init(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220331112822.11462-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-03-31drm/i915: Refactor non-EDID fixed mode duplicationVille Syrjälä1-36/+30
All the non-EDID fixed mode functions basically do the exact same thing. Let's refactor the common bits into a shared function. There are minor differences on how the mode types are populated, whether the display info physical size is updated, and the debug print. The differences are purely accidental, so unifying them is actually a good thing. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220331112822.11462-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-03-31drm/i915: Put fixed modes directly onto the panel's fixed_modes listVille Syrjälä10-118/+82
Rather than having the connector init get the fixed mode back from intel_panel and then feed it straight back into intel_panel_init() let's just make the fixed mode lookup put the mode directly onto the panel's fixed_modes list. Avoids the pointless round trip and opens the door for further enhancements to the fixed mode handling. v2: Make the debug message correct by using intel_panel_drrs_type() (Jani) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220331112822.11462-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-03-31drm/i915: Extract intel_edp_has_drrs()Ville Syrjälä2-25/+34
Pull all the eDP specific platform/port checks out from intel_drrs_init() into intel_edp_has_drrs(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220331112822.11462-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-04-01drm/i915/dmc: split out dmc registers to a separate fileJani Nikula2-0/+31
Clean up the massive i915_reg.h a bit with this isolated set of registers. v2: Remove stale comment (Lucas) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220330113417.220964-3-jani.nikula@intel.com
2022-04-01drm/i915/dmc: hide DMC version macrosJani Nikula2-4/+4
The macros are now only needed within intel_dmc.c, so move them there. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220330113417.220964-2-jani.nikula@intel.com
2022-04-01drm/i915/dmc: abstract GPU error state dumpJani Nikula2-0/+18
Only intel_dmc.c should be accessing dmc details directly. Need to add an i915_error_printf() stub for CONFIG_DRM_I915_CAPTURE_ERROR=n. v2: Add the stub (kernel test robot <lkp@intel.com>) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> # v1 Link: https://patchwork.freedesktop.org/patch/msgid/20220330113417.220964-1-jani.nikula@intel.com
2022-03-31drm/i915: Handle the DG2 max bw properlyVinod Govindapillai1-10/+15
Update DG2 init bw info similar to other platforms even though DG2 has constant bandwidh. This will avoid branching out DG2 specific max bw calls. V3: Fix dg2_get_bw_info() and avoid handle special cases for DG2 (Ville Syrjälä) cc: Ville Syrjälä <ville.syrjala@linux.intel.com> cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220328230000.215094-1-vinod.govindapillai@intel.com
2022-03-30drm/i915/display/adlp: Fix programing of PIPE_MBUS_DBOX_CTLJosé Roberto de Souza1-40/+1
PIPE_MBUS_DBOX_CTL was only being programmed when a pipe is being enabled but that could potentially cause issues as it could have mismatching values while pipes are being enabled. So here moving the PIPE_MBUS_DBOX_CTL programming of all pipes to be executed before the function that enables all pipes, leaving all pipes with a matching A_CREDIT value. While at it, also moving it to intel_pm.c as we are trying to reduce the gigantic size of intel_display.c and intel_pm.c have other MBUS programing sequences. v2: - do not program PIPE_MBUS_DBOX_CTL if pipe will not be active or when it do not needs modeset - remove the checks to wait a vblank v3: - checking if dbuf state is present in state before using it v4: - removing redundant checks - calling intel_atomic_get_new_dbuf_state instead of intel_atomic_get_dbuf_state BSpec: 49213 BSpec: 50343 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220330155724.255226-3-jose.souza@intel.com
2022-03-30drm/i915/display/adlp: Adjust MBUS DBOX BW and B creditsCaz Yokoyama1-1/+4
Alderlake-P has different MBUS DBOX BW and B credits than other platforms, so here setting it properly. BSpec: 49213 BSpec: 50343 Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Caz Yokoyama <caz.yokoyama@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220330155724.255226-2-jose.souza@intel.com
2022-03-30drm/i915/display/tgl+: Set default values for all registers in ↵José Roberto de Souza1-3/+10
PIPE_MBUS_DBOX_CTL MBUS_DBOX_B2B_TRANSACTIONS_MAX, MBUS_DBOX_B2B_TRANSACTIONS_DELAY and MBUS_DBOX_REGULATE_B2B_TRANSACTIONS_EN were being programmed with zeros while specification has different default values for this registers in display 12 and newer. While at it also converting all MBUS_DBOX macros to use REG_* macros. BSpec: 50343 BSpec: 20231 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220330155724.255226-1-jose.souza@intel.com
2022-03-30drm/i915/dp: make DSC usage logging actually usefulJani Nikula1-7/+12
Debug log when DSC is going to be used, and why, instead of unconditionally logging the rarely used debug option setting, which might not have any bearing on whether DSC is going to be used or not. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220330093019.4150386-1-jani.nikula@intel.com
2022-03-30drm/i915/audio: move has_audio checks to within codec enable/disableJani Nikula5-42/+26
Reduce duplication. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220330094109.4164326-2-jani.nikula@intel.com
2022-03-30drm/i915/audio: unify audio codec enable/disable debug loggingJani Nikula3-38/+11
The audio codec enable/disable debug logging is spread around in callers and the platform specific hooks. Put them all together in one place on both the enable and disable paths. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220330094109.4164326-1-jani.nikula@intel.com
2022-03-30drm/i915: Move intel_vtd_active and run_as_guest to i915_utilsTvrtko Ursulin4-3/+13
Continuation of the effort to declutter i915_drv.h. Also, component specific helpers which consult the iommu/virtualization helpers moved to respective component source/header files as appropriate. v2: * s/dev_priv/i915/ in intel_scanout_needs_vtd_wa. (Lucas) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220329090204.2324499-1-tvrtko.ursulin@linux.intel.com [tursulin: fixup conflict in i915_drv.h]
2022-03-30drm/i915/dmc: fix i915_reg_t usageJani Nikula1-2/+2
i915_reg_t is supposed to be a somewhat opaque data type, not to be looked inside. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/b813d0cf1b800386742eb3f919b0ba8d5c182a2a.1647870374.git.jani.nikula@intel.com
2022-03-30drm/i915/dmc: move dmc debugfs to intel_dmc.cJani Nikula3-74/+85
Continue localizing DMC register and data access to intel_dmc.c. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/3b7bc0fc117b030d59dd74891af104c165bf9b39.1647870374.git.jani.nikula@intel.com
2022-03-30drm/i915/dmc: move assert_dmc_loaded() to intel_dmc.cJani Nikula3-12/+13
Start localizing DMC register and data access to intel_dmc.c. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/4b96fe56c9c01bc671992dd6fe619638b157878f.1647870374.git.jani.nikula@intel.com
2022-03-30drm/i915/dmc: simplify intel_dmc_load_program() conditionsJani Nikula2-13/+4
intel_dmc_load_program() is only ever called when intel_dmc_has_payload() is true. Move the condition within intel_dmc_load_program() to let it be called directly. Also note that intel_dmc_has_payload() will always return false when HAS_DMC() is false. Remove the redundant check. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/c8ec46a44071f80b9c97617391b30e0c61ebc3e6.1647870374.git.jani.nikula@intel.com
2022-03-29drm/i915: Change SDVO fixed mode handlingVille Syrjälä1-19/+10
SDVO is the only connector type currently returning the VBT fixed mode directly from .get_modes(), everyone else just adds it to the fixed_modes list and then returns that from .get_modes(). Adjust SDVO to follow the common behaviour. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220323182935.4701-10-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-03-29drm/i915: Use intel_panel_edid_fixed_mode() for sdvoVille Syrjälä1-10/+3
Despite the name intel_panel_edid_fixed_mode() doesn't actually look in the EDID. All it does is dig out the preferred mode from the connector's probed_modes list. That is also what the SDVO LVDS code is doing by hand. Let's just call intel_panel_edid_fixed_mode(). The slight difference in behaviour is that the SDVO code currently bails if it can't find the preferred mode, whereas intel_panel_edid_fixed_mode() will fall back to just returning the first mode from the probed_modes list. Can't imagine why such an LVDS panel would even exist, and also why would you have a panel and be expected to not use it? So I'm going to assume this is a total non-issue. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220323182935.4701-9-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-03-29drm/i915: Extract intel_panel_encoder_fixed_mode()Ville Syrjälä4-30/+31
Apart from the EDID and VBT based mechanism we also sometimes use the encoder's current mode as the panel fixed mode. We currently have the same code for that duplicated in two places. Let's unify. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220323182935.4701-8-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-03-29drm/i915: Extract intel_panel_vbt_sdvo_fixed_mode()Ville Syrjälä3-10/+26
We have a function for duplicating the VBT LFP mode. Add the same for the VBT SDVO mode. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220323182935.4701-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-03-29drm/i915: Rename intel_panel_vbt_fixed_mode()Ville Syrjälä6-6/+6
Rename intel_panel_vbt_fixed_mode() to intel_panel_vbt_lfp_fixed_mode() to be more descriptive. We'll have another VBT fixed mode function soon and we don't want to confuse the two. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220323182935.4701-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-03-29drm/i915: Use intel_panel_preferred_fixed_mode() moreVille Syrjälä4-14/+18
Use intel_panel_preferred_fixed_mode() for all the orientation quirk setup and compute_is_dual_link_lvds()). All of these happen after intel_panel_init() so the panel fixed_mode list is already in place. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220323182935.4701-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-03-29drm/i915: Extract intel_edp_add_properties()Ville Syrjälä1-5/+17
Pull the drm_connector_set_panel_orientation_with_quirk() into intel_edp_add_properties() to match how the DSI encoders do it. Less clutter in intel_edp_init_connector() overall. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220323182935.4701-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-03-29drm/i915: Use DRM_MODE_FMT+DRM_MODE_ARG()Ville Syrjälä7-37/+37
Replace all drm_mode_debug_printmodeline() calls with DRM_MODE_FMT+DRM_MODE_ARG(). Makes the debug output a bit more terse in places where we previously had a newline in the precedeing drm_dbg_kms(), and avoids anything else sneaking in between the two printk()s in all cases. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220323182935.4701-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-03-29drm/i915: Pass intel_connector to intel_panel_{init,fini}()Ville Syrjälä9-15/+15
All the other intel_panel functions take struct intel_connector, so might as well make init()/fini() take one as well. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220323182935.4701-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-03-29drm/i915: Split pipe+output CSC programming to noarm+arm pairVille Syrjälä1-13/+23
Move most of the pipe+output CSC programming to the .color_commit_noarm() hook which runs before vblank evasion. Only PIPE_CSC_MODE (the arming register) needs to remain in inside the critical section. A test case that just updates the CTM in a loop produces the following i915_update_info numbers on ilk (w/o lockdep): old new Updates: 10012 Updates: 10008 | | 1us |** 1us |********** |************* |************* 4us |********* 4us |* |* |** 16us | 16us | | | 66us | 66us | | | 262us | 262us | | | 1ms | 1ms | | | 4ms | 4ms | | | 17ms | 17ms | | | Min update: 1345ns Min update: 1268ns Max update: 16672ns Max update: 15656ns Average update: 3914ns Average update: 2185ns Overruns > 100us: 0 Overruns > 100us: 0 And here is tgl (forced to update both pipe CSC and output CSC, and with lockdep enabled): old new Updates: 10012 Updates: 10012 | | 1us | 1us | | | 4us |* 4us |** |** |********** 16us |************* 16us |************* |* | 66us | 66us | | | 262us | 262us | | | 1ms | 1ms | | | 4ms | 4ms | | | 17ms | 17ms | | | Min update: 5204ns Min update: 5176ns Max update: 176038ns Max update: 186685ns Average update: 23931ns Average update: 16654ns Overruns > 250us: 0 Overruns > 250us: 0 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220224165103.15682-5-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2022-03-29drm/i915: Split color_commit() into noarm+arm pairVille Syrjälä3-28/+56
To reduce the amount of registers written during the vblank evade critical section let's also split the .color_commit() hook to noarm+arm pair. The noarm hook runs before the vblank evasion with the arm hook staying inside the critical section. Just the framework here, actually moving stuff out into the noarm hook will follow. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220224165103.15682-4-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2022-03-29drm/i915: Make ilk+ pfit regiser unlockedVille Syrjälä1-9/+9
The ilk+ panel fitter register are sitting nicely on their own cacheline, so no need for global serialization via uncore.lock. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220224165103.15682-3-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2022-03-29drm/i915: Remove locks around skl+ scaler programmingVille Syrjälä1-10/+0
All the skl+ scaler registers are suitably confined to their own cachelines so we don't need the uncore.lock to globally serialize access to these registers. We actually already dropped some of this in commit 14ad15296d1f ("drm/i915: Make skl+ universal plane registers unlocked") as the plane scaler enabling/reconfiguration became lockless. So let's complete that and remove the rest of the locks from the scaler programming as well. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220224165103.15682-2-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2022-03-29drm/i915: Add a DP1.2 compatible way to read LTTPR capabilitiesImre Deak1-9/+22
At least some DELL monitors (P2715Q) with DPCD_REV 1.2 return corrupted DPCD register values when reading from the 0xF0000- LTTPR range with an AUX transaction block size bigger than 1. The DP standard requires 0 to be returned - as for any other reserved/invalid addresses - but these monitors return the DPCD_REV register value repeated in each byte of the read buffer. This will in turn corrupt the values returned by the LTTPRs between the source and the monitor: LTTPRs must adjust the values they read from the downstream DPRX, for instance right-shift/init the downstream DP_PHY_REPEATER_CNT value. Since the value returned by the monitor's DPRX is non-zero the adjusted values will be corrupt. Reading the LTTPR registers one-by-one instead of reading all of them with a single AUX transfer works around the issue. According to the DP standard's 0xF0000 register description: "LTTPR-related registers at DPCD Addresses F0000h through F02FFh are valid only for DPCD r1.4 (or higher)." While it's unclear if DPCD r1.4 refers to the DPCD_REV or to the LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV register (tickets filed at the VESA site to clarify this haven't been addressed), one possibility is that it's a restriction due to non-compliant monitors described above. Disabling the non-transparent LTTPR mode for all such monitors is not a viable solution: the transparent LTTPR mode has its own issue causing link training failures and this would affect a lot of monitors in use with DPCD_REV < 1.4. Instead this patch works around the problem by reading the LTTPR common and PHY cap registers one-by-one for any monitor with a DPCD_REV < 1.4. The standard requires the DPCD capabilities to be read after the LTTPR common capabilities are read, so re-read the DPCD capabilities after the LTTPR common and PHY caps were read out. v2: - Use for instead of a while loop. (Ville) - Add to code comment the monitor model with the problem. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4531 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220322143844.42616-1-imre.deak@intel.com
generated by cgit v1.2.3 (git 2.39.0) at 2025-10-01 09:04:14 +0300