- 06 Sep, 2022 4 commits
-
-
Stanislav Lisovskiy authored
Whenever we are not able to get enough timeslots for required PBN, let's try to allocate those using DSC, just same way as we do for SST. v2: Removed intel_dp_mst_dsc_compute_config and refactored intel_dp_dsc_compute_config to support timeslots as a parameter(Ville Syrjälä) v3: - Rebased - Added a debug to see that we at least try reserving VCPI slots using DSC, because currently its not visible from the logs, thus making debugging more tricky. - Moved timeslots to numerator, where it should be. v4: - Call drm_dp_mst_atomic_check already during link config computation, because we need to know already by this moment if uncompressed amount of VCPI slots needed can fit, otherwise we need to use DSC. (thanks to Vinod Govindapillai for pointing this out) v5: - Put pipe_config->bigjoiner_pipes back to original condition in intel_dp_dsc_compute_config (don't remember when I lost it) v6: - Removed unnecessary drm_dp_mst_atomic_check as it is now always called in a newly introduced intel_dp_mst_find_vcpi_slots_for_bpp function (Vinod Govindapillai) Reviewed-by:Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220905085744.29637-5-stanislav.lisovskiy@intel.com
-
Stanislav Lisovskiy authored
We would be using almost same code to loop through bpps while calling drm_dp_atomic_find_vcpi_slots - lets remove this duplication by introducing a new function intel_dp_mst_find_vcpi_slots_for_bpp v2: Fix pbn_div calculation - shouldn't matter if its DSC or not. Reviewed-by:
-
Stanislav Lisovskiy authored
We currently always exit that bpp loop because drm_dp_atomic_find_vcpi_slots doesn't care if we actually can fit those or not. I think that wasn't the initial intention here, especially when we keep trying with lower bpps, we are supposed to keep trying until we actually find some _working_ configuration, which isn't the case here. So added that drm_dp_mst_check here, so that we can make sure that try all the bpps before we fail. Reviewed-by:
-
Stanislav Lisovskiy authored
Adding DP DSC register definitions, we might need for further DSC implementation, supporting MST and DP branch pass-through mode. v2: - Fixed checkpatch comment warning v3: - Removed function which is not yet used(Jani Nikula) Reviewed-by:
-
- 05 Sep, 2022 15 commits
-
-
Andrzej Hajda authored
In case of deferred FB setup core can try to create new framebuffer. Disallow it if hpd_suspended flag is set. Signed-off-by:
Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by:
Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Andrzej Hajda authored
HPD event after fbdev unregistration can cause registration of deferred fbdev which will not be unregistered later, causing use-after-free. To avoid it HPD handling should be suspended before fbdev unregistration. It should fix following GPF: [272.634530] general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI [272.634536] CPU: 0 PID: 6030 Comm: i915_selftest Tainted: G U 5.18.0-rc5-CI_DRM_11603-g12dccf4f5eef+ #1 [272.634541] Hardware name: Intel Corporation Raptor Lake Client Platform/RPL-S ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.2397.A01.2109300731 09/30/2021 [272.634545] RIP: 0010:fb_do_apertures_overlap.part.14+0x26/0x60 ... [272.634582] Call Trace: [272.634583] <TASK> [272.634585] do_remove_conflicting_framebuffers+0x59/0xa0 [272.634589] remove_conflicting_framebuffers+0x2d/0xc0 [272.634592] remove_conflicting_pci_framebuffers+0xc8/0x110 [272.634595] drm_aperture_remove_conflicting_pci_framebuffers+0x52/0x70 [272.634604] i915_driver_probe+0x63a/0xdd0 [i915] Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5329 Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5510Signed-off-by:
Arun R Murthy <arun.r.murthy@intel.com> Reviewed-by:
-
Andrzej Hajda authored
i915->hotplug.dig_port_work can be queued from intel_hpd_irq_handler called by IRQ handler or by intel_hpd_trigger_irq called from dp_mst. Since dp_mst is suspended after irq handler uninstall, a cleaner approach is to cancel hpd work after intel_dp_mst_suspend, otherwise we risk use-after-free. It should fix following WARNINGS: [283.405824] cpu_latency_qos_update_request called for unknown object [283.405866] WARNING: CPU: 2 PID: 240 at kernel/power/qos.c:296 cpu_latency_qos_update_request+0x2d/0x100 [283.405912] CPU: 2 PID: 240 Comm: kworker/u64:9 Not tainted 5.18.0-rc6-Patchwork_103738v3-g1672d1c43e43+ #1 [283.405915] Hardware name: Intel Corporation Raptor Lake Client Platform/RPL-S ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.2397.A01.2109300731 09/30/2021 [283.405916] Workqueue: i915-dp i915_digport_work_func [i915] [283.406020] RIP: 0010:cpu_latency_qos_update_request+0x2d/0x100 ... [283.406040] Call Trace: [283.406041] <TASK> [283.406044] intel_dp_aux_xfer+0x60e/0x8e0 [i915] [283.406131] ? finish_swait+0x80/0x80 [283.406139] intel_dp_aux_transfer+0xc5/0x2b0 [i915] [283.406218] drm_dp_dpcd_access+0x79/0x130 [drm_display_helper] [283.406227] drm_dp_dpcd_read+0xe2/0xf0 [drm_display_helper] [283.406233] intel_dp_hpd_pulse+0x134/0x570 [i915] [283.406308] ? __down_killable+0x70/0x140 [283.406313] i915_digport_work_func+0xba/0x150 [i915] Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4586 Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5558Signed-off-by:
-
Ville Syrjälä authored
Limit the DP lane count based on the new VBT DP/eDP max lane count field. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220715202044.11153-13-ville.syrjala@linux.intel.comReviewed-by:
Jani Nikula <jani.nikula@intel.com>
-
Ville Syrjälä authored
The allow vs. block display switch bits are named rather inconsistently. Fix it up. Signed-off-by:
-
Ville Syrjälä authored
We already have LFP1 and LFP2 device handles define. Just add all the rest as well. Signed-off-by:
-
Ville Syrjälä authored
Define some additional bits in the driver features VBT block. Signed-off-by:
-
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ä 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:
-
- 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:
-
- 31 Aug, 2022 16 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:
-
