- 05 Sep, 2022 8 commits
-
-
Ville Syrjälä authored
Add a few comment documenting the sets of bits in the driver features block. Might make it a bit easier to check against the spec. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220715202044.11153-8-ville.syrjala@linux.intel.comReviewed-by:
Jani Nikula <jani.nikula@intel.com>
-
Ville Syrjälä authored
The VBT gained some bits to inidicate the max FRL rate for HDMI 2.1, define them. These just outright replaced the slave_port bits for ganged eDP. Apparently that feature was never actually used so someone decided that reusing the bits is fine. Although the actual ganged eDP enable bit was still left defined elsewhere for some reason. Signed-off-by:
-
Ville Syrjälä authored
VBT gained a bit to indicate whether LTTPRs should use transparent or non-transparent mode. Dunno if we should actually look at this... Signed-off-by:
-
Ville Syrjälä authored
Since version 244 the VBT can llimt the eDP/DP max lane count. Add the bits. Signed-off-by:
-
Ville Syrjälä authored
Split the DP redriver bytes into bitfields. Signed-off-by:
-
Ville Syrjälä authored
Document the VBT version dependency of several other fields. v2: s/165/155/ for custom_vbt_version (Jani) Signed-off-by:
-
Ville Syrjälä authored
Use a more standard form for the VT version number comments. One slight oddball case is the dp_max_link_rate that had two version numbers (216/230) and a platform name (GLK). The story goes that the field was introduced in the spec in version 216, along with a note that it's used on CNL+. Later in version 230 the definition of the bit was changed in bacakwards incompatible ways and the CNL note disappeard. For us the original CNL+ note in the header got changed to to GLK+ when all CNL support was dropped from the codebase. We do still need (and have) handling for both the 216+ and the 230+ defintions (parse_bdb_216_dp_max_link_rate() vs. parse_bdb_230_dp_max_link_rate()). Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Stanislav Lisovskiy authored
Lets start to use REG_BIT* macros, when working with CDCLK registers, such as CDCLK_CTL, instead of (x << 0) like expressions. Link: https://patchwork.freedesktop.org/patch/msgid/20220901113011.12080-1-stanislav.lisovskiy@intel.comReviewed-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
-
- 03 Sep, 2022 2 commits
-
-
Ville Syrjälä authored
This reverts commit d5929835. With the Parade PS8461E MUX workaround (WaEdpLinkRateDataReload) implemented we can get finally rid of the is_low_voltage_sku() check that incorrectly prevents many machines from using the 8.1Gpbs link rate. Cc: Jason A. Donenfeld <Jason@zx2c4.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5272 Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6323 Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6205Signed-off-by:
Aaron Ma <aaron.ma@canonical.com> Tested-by:
Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by:
-
Ville Syrjälä authored
A lot of modern laptops use the Parade PS8461E MUX for eDP switching. The MUX can operate in jitter cleaning mode or redriver mode, the first one resulting in higher link quality. The jitter cleaning mode needs to know the link rate used and the MUX achieves this by snooping the LINK_BW_SET, LINK_RATE_SELECT and SUPPORTED_LINK_RATES DPCD accesses. When the MUX is powered down (seems this can happen whenever the display is turned off) it loses track of the snooped link rates so when we do the LINK_RATE_SELECT write it no longer knowns which link rate we're selecting, and thus it falls back to the lower quality redriver mode. This results in unstable high link rates (eg. usually 8.1Gbps link rate no longer works correctly). In order to avoid all that let's re-snoop SUPPORTED_LINK_RATES from the sink at the start of every link training. Unfortunately we don't have a way to detect the presence of the MUX. It looks like the set of laptops equipped with this MUX is fairly large and contains devices from multiple manufacturers. It may also still be growing with new models. So a quirk doesn't seem like a very easily maintainable option, thus we shall attempt to do this unconditionally on all machines that use LINK_RATE_SELECT. Hopefully this extra DPCD read doesn't cause issues for any unaffected machine. If that turns out to be the case we'll need to convert this into a quirk in the future. Cc: stable@vger.kernel.org Cc: Jason A. Donenfeld <Jason@zx2c4.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6205Signed-off-by:
-
- 02 Sep, 2022 2 commits
-
-
Ville Syrjälä authored
The current scheme for generating the LFP data table pointers (when the block including them is missing from the VBT) expects the 0xffff sequence to only appear in the fp_timing terminator entries. However some VBTs also have extra 0xffff sequences elsewhere in the LFP data. When looking for the terminators we may end up finding those extra sequeneces insted, which means we deduce the wrong size for the fp_timing table. The code then notices the inconsistent looking values and gives up on the generated data table pointers, preventing us from parsing the LFP data table entirely. Let's give up on the "search for the terminators" approach and instead just hardcode the expected size for the fp_timing table. We have enough sanity checks in place to make sure we shouldn't end up parsing total garbage even if that size should change in the future (although that seems unlikely as the fp_timing and dvo_timing tables have been declared obsolete as of VBT version 229). Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6592Signed-off-by:
-
Ville Syrjälä authored
Validate the LFP data block a bit hardwer by making sure the fp_timing terminators (0xffff) are where we expect them to be. Signed-off-by:
-
- 01 Sep, 2022 1 commit
-
-
Mitul Golani authored
While executing i915_selftest, wakeref imbalance warning is seen with i915_selftest failure. Currently when Driver is suspended, while doing unregister it is taking wakeref without resuming the device. This patch is resuming the device, if driver is already suspended and doing unregister process. Signed-off-by:
Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Andrzej Hajda <andrzej.hajda@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220830085158.577157-1-mitulkumar.ajitkumar.golani@intel.com
-
- 31 Aug, 2022 27 commits
-
-
Ville Syrjälä authored
On some systems the panel reports alternate modes with different blanking periods. If the EDID reports them and VBT doesn't tell us otherwise then I can't really see why they should be rejected. So allow their use for the purposes of static DRRS. For seamless DRRS we still require a much more exact match of course. But that logic only kicks in when selecting the downclock mode (or in the future when determining whether we can do a seamless refresh rate change due to a user modeset). Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6374Signed-off-by:
-
Ville Syrjälä authored
Turns out the MIPI sequence block version number and new block size fields are considered part of the block header and are not included in the reported new block size field itself. Bump up the block size appropriately so that we'll copy over the last five bytes of the block as well. For this particular machine those last five bytes included parts of the GPIO op for the backlight on sequence, causing the backlight no longer to turn back on: Sequence 6 - MIPI_SEQ_BACKLIGHT_ON Delay: 20000 us - GPIO index 0, number 0, set 0 (0x00) + GPIO index 1, number 70, set 1 (0x01) Cc: stable@vger.kernel.org Fixes: e163cfb4 ("drm/i915/bios: Make copies of VBT data blocks") Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6652Signed-off-by:
-
Ville Syrjälä authored
Dump the panel PNPID and name from the VBT. Reviewed-by:
-
Jani Nikula authored
Avoid BUG_ON(). Since __i915_sw_fence_init() is always called via a wrapper macro, we can replace it with a compile time BUILD_BUG_ON(). Reviewed-by:
-
Jani Nikula authored
Avoid BUG_ON(). Replace with WARN_ON() and early return. Reviewed-by:
-
Jani Nikula authored
Avoid BUG_ON(). Replace with drm_WARN_ON(). Reviewed-by:
-
Jani Nikula authored
Avoid BUG_ON(). Actually check the dpll count and bail out loudly with drm_WARN_ON() from the loop before overflowing i915->dpll.shared_dplls[]. v2: Rebase Reviewed-by:
-
Jani Nikula authored
Avoid BUG_ON(). We don't have such checks on output type anywhere else either, so just remove. Suggested-by:
-
Jani Nikula authored
Now that gmbus no longer uses macros that assume dev_priv is implicitly available, mass rename dev_priv to i915 in gmbus code. Signed-off-by:
-
Jani Nikula authored
Remove the implicit dev_priv usage in DSPCLK_GATE_D register, and pass it as parameter. Signed-off-by:
-
Jani Nikula authored
Since the beginning of time, we've implicitly assumed dev_priv is present as a local variable in many places. We've gone a long way in removing many of them, but the register macro definitions are the last holdout. Remove them from the gmbus macros. Signed-off-by:
-
Jani Nikula authored
Don't repeat the same thing so much. Signed-off-by:
-
Jani Nikula authored
Simple whitespace cleanup and comment movement. Signed-off-by:
-
Jani Nikula authored
Declutter i915_reg.h, and also observe very few places need the gmbus register defitions. Signed-off-by:
-
Jani Nikula authored
Move display property related members under drm_i915_private display sub-struct. Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/14b14f871e322419b10166c1bd8a5a956f5430c8.1661779055.git.jani.nikula@intel.com
-
Jani Nikula authored
Move display atomic helper related members under drm_i915_private display sub-struct. Signed-off-by:
-
Jani Nikula authored
Move display quirk related members under drm_i915_private display sub-struct. Prefer adding anonymous sub-structs even for single members that aren't our own structs. Signed-off-by:
-
Jani Nikula authored
Turn the quirk ids to enums instead of bits, and hide the masking inside intel_quirks.c. Define the enums in intel_quirks.h to declutter i915_drv.h while at it. Signed-off-by:
-
Jani Nikula authored
Add intel_has_quirk() for checking if a display quirk is present. Avoid accessing i915->quirks all over the place. v2: Rebase Signed-off-by:
-
Jani Nikula authored
Move display workqueue related members under drm_i915_private display sub-struct. Signed-off-by:
-
Jani Nikula authored
Move display dbuf related members under drm_i915_private display sub-struct. Signed-off-by:
-
Jani Nikula authored
Move display frontbuffer tracking related members under drm_i915_private display sub-struct. Rename struct i915_frontbuffer_tracking to intel_frontbuffer_tracking while at it. FIXME: fb_tracking.lock mutex init should be moved away from i915_gem_init_early(). Signed-off-by:
-
Jani Nikula authored
Move display fdi related members under drm_i915_private display sub-struct. Signed-off-by:
-
Jani Nikula authored
Move display power related members under drm_i915_private display sub-struct. Arguably chv_phy_control and chv_phy_assert could be placed in a phy substruct, but they are only used in the power code. Signed-off-by:
-
Jani Nikula authored
Move display FBC related members under drm_i915_private display sub-struct. Pointers and arrays of pointers to structs that we defined are fine without a sub-struct wrapping. Signed-off-by:
-
Jani Nikula authored
Move display VBT related members under drm_i915_private display sub-struct. v2: Rebase Signed-off-by:
-
Jani Nikula authored
Move display DSI related members under drm_i915_private display sub-struct. Prefer adding anonymous sub-structs even for single members that aren't our own structs. Abstract mmio base member access in register definitions in a macro. Signed-off-by:
-
