- Jun 17, 2022
-
-
Jani Nikula authored
By moving wm state verification to intel_pm.c, we can make a bunch of functions static, hiding the wm details better. Also declutter intel_display.c. v2: intel_wm_state_verify -> intel_wm_verify_state (Ville) 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/2a7e3141e87181c07eaddcd9c352b8810550b0ce.1655372759.git.jani.nikula@intel.com
-
Ville Syrjälä authored
adl-s needs the combo PLL DCO fraction w/a as well. Gets us slightly more accurate clock out of the PLL. Cc: stable@vger.kernel.org Signed-off-by:
Matt Roper <matthew.d.roper@intel.com>
-
- Jun 16, 2022
-
-
Ville Syrjälä authored
Abstract the bit extraction from the VBT per-panel bitfields slightly. Signed-off-by:
-
Ville Syrjälä authored
Older VBTs don't have all the stuff we've defined for the LVDS options block (40). In particular we're currently parsing the DPS panel type bits even though they may not exist, which could mean we end up flagging the machine as supporting static DRRS when the VBT declared no such thing. We don't actually have a clear idea which VBT versions have which bits so we rely on the block size instead. Here's a quick list from my VBT stash: mgm version 108 -> 4 bytes alv version 120 -> 4 bytes cst version 134 -> 14 bytes pnv version 144 -> 14 bytes cl version 142 -> 16 bytes ctg version 155 -> 24 bytes Signed-off-by:
-
Ville Syrjälä authored
Parsing the panel_type is a bit special and should be done before we parse anything else potentially panel-specific from the VBT. So move it out from parse_panel_options(). It doesn't neet to be there anyway since it'll do its own LVDS options block lookup. Signed-off-by:
-
Ville Syrjälä authored
The WARN shouldn't have been added yet. For the moment the clock that gets passed here is just what the user has requested (via the modeline) and may not be exactly what iCLKIP can generate. Later on the plan is to change things so that we already get passed the exact clock here, at which point the WARN should be reintroduced. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6246 Fixes: 97708335 ("drm/i915: Introduce struct iclkip_params") Signed-off-by:
-
Ville Syrjälä authored
Make sure FIFO underrun reporting is flagged as disabled very early during the state readout so that we don't get any spurious FIFO underruns reports from intel_crtc_disable_noatomic(). Signed-off-by:
-
Ville Syrjälä authored
Pull the underrun status sanitation into its own helper. Signed-off-by:
-
Jouni Högander authored
Connector polling is waking up the polled device. Polling is unnecessary if our device is known to not have display. Fix this and save some power by disabling starting connector polling when we are having headless sku. Use information from opregion. v2: Move headless sku check into INTEL_DISPLAY_ENABLED macro Signed-off-by:
Jouni Högander <jouni.hogander@intel.com> Reviewed-by:
-
Jouni Högander authored
Currently we are starting connector polling if display is disabled using disable_display module parameter. Polling is just returning always "not connected" state. This can be optimized by not starting polling at all. Signed-off-by:
-
Jouni Högander authored
Export headless sku bit (bit 13) from opregion->header->pcon as an interface to check if our device is headless configuration. This is mainly targeted for hybrid gfx systems. E.g. when display is not supposed to be connected discrete graphics card it's opregion can inform this is headless graphics card. v3: Dummy version is now static inline function v2: Check also opregion version Bspec: 53441 Reviewed-by:
-
- Jun 15, 2022
-
-
Jani Nikula authored
Split ddi port parsing and debug printing to clarify the functional parts of parse_ddi_port(), which are quite small nowadays. Signed-off-by:
-
Jani Nikula authored
i915 is available via devdata, grab it there instead of passing. Signed-off-by:
-
Jani Nikula authored
Improve clarity by using the helpers we have. Signed-off-by:
-
- Jun 14, 2022
-
-
Ville Syrjälä authored
The VBIOS/GOP may not program the FDI M/n vs. dotclock entirely consistently. Eg. on a SNB Thinkpad X220 LVDS I see dotclock of 69.286 MHz (the best the DPLL can do) vs. FDI M/N 69.3 MHz (matches what the EDID actually declares). Signed-off-by:
-
Ville Syrjälä authored
Pull the various iCLKIP parameters into a struct. Later on we'll reuse this during the state computation to determine the exact dotclock the hardware will be generating for us. v2: Don't lose the phaseinc calculation v3: Drop the misplaced '#include <intel_pch_refclk.h>' from intel_crt.c (Jani) Signed-off-by:
-
Ville Syrjälä authored
Extract intel_crtc_dotclock() from ddi_dotclock_get(). We'll reuse this during state computation in order to determine the actual final dotclcok after the DPLL computation has been done (which may not give us the exact same port_clock that we fed in). v2: Add the prototype Signed-off-by:
-
- Jun 10, 2022
-
-
José Roberto de Souza authored
Commit 3cf05076 ("drm/i915/bios: Split VBT data into per-panel vs. global parts") cause PSR to be disabled when enable_psr has the default value and there is at least one DP port that do not supports PSR. That was happening because intel_psr_init() is called for every DP port and then enable_psr is globaly set to 0 based on the PSR support of the DP port. Here dropping the enable_psr overwritten and using the VBT PSR value when enable_psr is set as default. Fixes: 3cf05076 ("drm/i915/bios: Split VBT data into per-panel vs. global parts") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Jouni Högander <jouni.hogander@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
-
- Jun 08, 2022
-
-
Ville Syrjälä authored
The eDP BDB block has gained yet another max link rate field. Let's parse it and consult it during the source rate filtering. v2: *20 instead of *2 to get the correct units (Jani) Reviewed-by:
-
Ville Syrjälä authored
We're not parsing the 5.4 Gbps value for the old eDP fast link training link rate, nor are we parsing the new fast link training link rate field. Remedy both. Also we'll now use the actual link rate instead of the DPCD BW register value. Note that we're not even using this information for anything currently, so should perhaps just nuke it all unless someone is planning on implementing fast link training finally... v2: Stop using the DPCD BW values (Jani) *20 instead of *2 to get the rate in correct units (Jani) Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: -
Ville Syrjälä authored
We'll need to know the VBT panel_type before we can determine the maximum link rate for eDP. To that end move intel_dp_set_source_rates() & co. to be called after the per-panel VBT parsing has been done. intel_dp_mst_encoder_init() depends on the source rates so we'll have to do it a bit later as well. v2: Fix the intel_dp_mst_encoder_init() oops Reviewed-by: Jani Nikula <jani.nikula@intel.com> #v1 Signed-off-by:
-
Jani Nikula authored
There's an early return for !engine->kernel_context. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220516081015.1058987-1-jani.nikula@intel.com
-
Jani Nikula authored
Fix: drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c:61:6: warning: symbol 'intel_pxp_debugfs_register' was not declared. Should it be static? Sort and remove the redundant pxp prefixes from the includes while at it. Signed-off-by:
-
Luca Coelho authored
The intel_dp_dsc_get_output_bpp() function outputs two lines of unconditional logs, which was okay when it was called only once. But now, we also call this function from intel_dp_mode_valid(), which is in turn called for every mode we need to validate. This causes a lot of useless noise. Remove the unconditional prints to avoid spamming the logs. Also remove one more print that is not unconditional, but is related. Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Signed-off-by:
-
Jani Nikula authored
Remove some of the unused helpers from i915_utils.h. Signed-off-by:
-
Jani Nikula authored
No longer needed after panel data was moved. Signed-off-by:
-
Jani Nikula authored
Add a dedicated file for the local functions around struct tasklet_struct. Far from ideal, but better placed in a dedicated file than i915_gem.h. Signed-off-by:
-
- Jun 06, 2022
-
-
José Roberto de Souza authored
This workaround brings some regressions to DG2 and if really necessary for DG2 an alternative workaround will be implemented. BSpec: 54077 Signed-off-by:
-
- Jun 03, 2022
-
-
Jani Nikula authored
Split out audio registers to a header of its own to reduce the size of i915_reg.h. TODO: Remove direct audio register access from intel_ddi.c. However, unification of audio get config is cumbersome due to the audio enable bit being in the DP or HDMI registers on older platforms. Signed-off-by:
-
Balasubramani Vivekanandan authored
Voltage swing table updated for eDP HBR3 Bspec: 49291 Signed-off-by:
Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by:
Matt Atwood <matthew.s.atwood@intel.com> Signed-off-by:
-
- Jun 01, 2022
-
-
Ville Syrjälä authored
Some machines declare DRRS type = seamless, DRRS = no, DMRRS = yes. I *think* DMRRS stands for "dynamcic media refresh rate", and I suspect the way it's meant to work is that it lets the driver switch refresh rates to match the frame rate for media playback. Obviously for us all that kind of policy stuff is entirely up to userspace, so the only thing we may do is make the extra refresh rate(s) available. So let's treat this case as just static DRRS for now. In the future We might want to differentiate the "seamless w/ downclocking" vs. "seamless w/o downclocking" cases so that we could do seamless refresh rate changes for systems that only claim to support DMRRS. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/125 Acked-by:
-
Ville Syrjälä authored
Add a bunch of new struff we're missing in various BDB blocks. TODO: Bunch of these might actually need to be taken into use... v2: s/lfp_features/lfp_power/features/ (Jani) Reviewed-by:
-
Ville Syrjälä authored
Fix various typos around "aggressiveness". Note that the VBT spec also sometimes missspells it as "agressiveness" so I guess that's where some of the typos came from. Reviewed-by:
-
Ville Syrjälä authored
It seem that when dealing with VRR capable eDP panels we need to accept fixed modes with variable vblank length (which is what VRR varies dynamically). Typically the preferred mode seems to be a non-VRR more (lowish dotclock/refresh rate + short vblank). We also have examples where it looks like even the hblank length is a bit different between the preferred mode vs. VRR mode(s). So let's just accept anything that has matching hdisp+vdisp+flags. v2: Document that is_alt_drrs_mode() is a subset of is_alt_vrr_mode() (Jani) Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/125 Reviewed-by:
-
Ville Syrjälä authored
To help with debugging DRRS/VRR panel init let's dump out all the fixed modes we rejected for whatever reason. Reviewed-by:
-
Ville Syrjälä authored
VBT seems to have an extra flag for VRR vs. not. Let's consult that for eDP panels. Reviewed-by:
-
Jani Nikula authored
Avoid bringing the entire machine down even if there's a bug that shouldn't happen, but won't corrupt the system either. Log them loudly and limp on. Signed-off-by:
Andrzej Hajda <andrzej.hajda@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220531162527.1062319-1-jani.nikula@intel.com
-
Ville Syrjälä authored
No idea why the DG2 PLL DP link frequency calculation is allowing a non-exact match. That makes no sense so get rid of it. Signed-off-by:
-
Ville Syrjälä authored
Don't see a real reson not to check hw.active and hw.enable in intel_pipe_config_compare(). We do have some checks for them at a higher level, but I think better check them also in intel_pipe_config_compare() in case something else doesn't do a thorough enough job. Also shuffle the mst_master_transcoder check next to the cpu_transcoder check for a bit of consistency. Signed-off-by:
-
Ville Syrjälä authored
Use the "[CRTC:%d:%s]'/etc. format for some of the modeset debugs so we know more about what has happened during the modeset state computation. Also tweak the connector bpp debug message a bit to make it less confusing. Signed-off-by:
-
