- 05 Apr, 2022 3 commits
-
-
Ville Syrjälä authored
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.comReviewed-by:
Uma Shankar <uma.shankar@intel.com>
-
Ville Syrjälä authored
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/2844Signed-off-by:
-
Ville Syrjälä authored
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:
-
- 04 Apr, 2022 3 commits
-
-
Ville Syrjälä authored
All the LFP data table pointers have uniform layout. Turn that into a struct. Signed-off-by:
Jani Nikula <jani.nikula@intel.com>
-
Ville Syrjälä authored
Remove some zombies from our device structure. Signed-off-by:
-
Ville Syrjälä authored
Stop hand rolling drm_connector_attach_hdr_output_metadata_property(). Signed-off-by:
-
- 31 Mar, 2022 11 commits
-
-
Ville Syrjälä authored
Nothing special about static DRRS on LVDS, it's just your bog standard modeset. Let's allow it. Signed-off-by:
-
Ville Syrjälä authored
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ä authored
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ä authored
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ä authored
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ä authored
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ä authored
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ä authored
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ä authored
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ä authored
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ä authored
Pull all the eDP specific platform/port checks out from intel_drrs_init() into intel_edp_has_drrs(). Signed-off-by:
-
- 01 Apr, 2022 4 commits
-
-
José Roberto de Souza authored
This will make easy to extend MBUS joining support to future platforms that also supports this feature. Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220331184152.1086943-1-jose.souza@intel.com
-
Jani Nikula authored
Clean up the massive i915_reg.h a bit with this isolated set of registers. v2: Remove stale comment (Lucas) Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220330113417.220964-3-jani.nikula@intel.com
-
Jani Nikula authored
The macros are now only needed within intel_dmc.c, so move them there. Signed-off-by:
-
Jani Nikula authored
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:
-
- 31 Mar, 2022 1 commit
-
-
Vinod Govindapillai authored
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:
-
- 30 Mar, 2022 11 commits
-
-
José Roberto de Souza authored
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:
-
Caz Yokoyama authored
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:
Caz Yokoyama <caz.yokoyama@intel.com> Signed-off-by:
-
José Roberto de Souza authored
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:
-
Jani Nikula authored
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 authored
Reduce duplication. Signed-off-by:
-
Jani Nikula authored
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:
-
Tvrtko Ursulin authored
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 authored
i915_reg_t is supposed to be a somewhat opaque data type, not to be looked inside. Signed-off-by:
-
Jani Nikula authored
Continue localizing DMC register and data access to intel_dmc.c. Signed-off-by:
-
Jani Nikula authored
Start localizing DMC register and data access to intel_dmc.c. Signed-off-by:
-
Jani Nikula authored
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:
-
- 29 Mar, 2022 7 commits
-
-
Matt Roper authored
ATS-M is a server platform based on Xe_HPG and Xe_HPM, but without display support. From a driver point of view, it's easiest to just handle it as DG2 (including identifying as PLATFORM_DG2), but with the display disabled in the device info. Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220329000822.1323195-1-matthew.d.roper@intel.com
-
Tejas Upadhyay authored
Add couple of RPL-S device ids Bspec : 53655 Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com> Reviewed-by:
Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by:
-
Ville Syrjälä authored
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ä authored
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ä authored
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ä authored
We have a function for duplicating the VBT LFP mode. Add the same for the VBT SDVO mode. Signed-off-by:
-
Ville Syrjälä authored
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:
-
