- Sep 08, 2022
-
-
Ville Syrjälä authored
Fill port_clock and hw.adjusted_mode.crtc_clock with the actual frequency we're going to be getting from the hardware. This will let us accurately compute all derived state that depends on those. v2: Reintroduce iCLKIP WARN v3: Try to deal with VLV/BXT DSI PLL as well Reviewed-by: Jani Nikula <jani.nikula@intel.com> #v1 Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220907091057.11572-8-ville.syrjala@linux.intel.com
-
Ville Syrjälä authored
Only reassign the pipe's DPLL if it's going through a full .compute_config() cycle. If OTOH it's just getting modeset eg. in order to change cdclk there doesn't seem much point in picking a new DPLL for it. This should also prevent .get_dplls() from seeing a funky port_clock for DP even in cases where the readout produces a non-standard clock and we (for some reason) have decided to not fully recompute the state to remedy the situation. Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Currently we calculate a lot of things (pixel rate, watermarks, cdclk) trusting that the DPLL can generate the exact frequency we ask it. In practice that is not true and there can be certain amount of rounding involved. To allow us to eventually get accurate numbers for all our DPLL clock derived state we need to move the DPLL calculation to hapen much earlier. To that end we hoist it up to the just after the fastset checks. For now we just do the easy code motion, and the actual back feeding of the final DPLL clock into the state will come later. A slight change here is that now .crtc_compute_clock() can get called while the shared_dpll is still assigned. But since .crtc_compute_clock() no longer assignes new shared_dplls this is perfectly fine. TODO: I'd actually like to do this before the fastset check so that if the DPLL state should change we actually do the modeset. Which I think is what the video aficionados want, but it might not be what the fans of fastboot want. Not yet sure how to reconcile those conflicting requirements... v2: s/return/goto/ in error handling Reviewed-by:
-
- Sep 07, 2022
-
-
Ankit Nautiyal authored
Currently, pic_height of vdsc_cfg structure is being used to calculate slice_height, before it is set for DP. So taking out the lines to set pic_height from the helper intel_dp_dsc_compute_params() to individual encoders, and setting pic_height, before it is used to calculate slice_height for DP. Fixes: 5a6d866f ("drm/i915: Get slice height before computing rc params") Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by:
Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220902103219.1168781-1-ankit.k.nautiyal@intel.com
-
Ville Syrjälä authored
Extract the state->freq computation for VLV/BXT DSI PLL into small helpers. We want to use these during the state computation as well. Reviewed-by:
Mika Kahola <mika.kahola@intel.com> Signed-off-by:
-
Ville Syrjälä authored
We have a couple of places that want to make distinction between double buffered M/N registers vs. the split M1/N1+M2/N2 registers. Add a helper for that. v2: Turn into a HAS_ macro (Jani) Reviewed-by: Jani Nikula <jani.nikula@intel.com> #v1 Signed-off-by:
-
Ville Syrjälä authored
Shuffle some PLL functions around a bit to avoid ugle forward declarations later on. No functional changes. Reviewed-by:
-
Ville Syrjälä authored
intel_crtc_dotclock() is a bit misplaced. In lieu of a better place let's just move it next to its friends in intel_display.c. Reviewed-by:
-
- Sep 06, 2022
-
-
Jani Nikula authored
This reverts commit 797e2c3f. Part of a series where patches were modified while applying to resolve conflicts, leading to further conflicts between drm-misc-next and drm-intel-next, resulting in build failures in drm-tip. To be applied again on a baseline with drm-misc-next and drm-intel-next in sync. Acked-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Jani Nikula authored
This reverts commit c6266862. Part of a series where patches were modified while applying to resolve conflicts, leading to further conflicts between drm-misc-next and drm-intel-next, resulting in build failures in drm-tip. To be applied again on a baseline with drm-misc-next and drm-intel-next in sync. Acked-by:
-
Jani Nikula authored
This reverts commit 7ae5ab44. Part of a series where patches were modified while applying to resolve conflicts, leading to further conflicts between drm-misc-next and drm-intel-next, resulting in build failures in drm-tip. To be applied again on a baseline with drm-misc-next and drm-intel-next in sync. Acked-by:
-
Jani Nikula authored
This reverts commit e1a84ba8. Part of a series where patches were modified while applying to resolve conflicts, leading to further conflicts between drm-misc-next and drm-intel-next, resulting in build failures in drm-tip. To be applied again on a baseline with drm-misc-next and drm-intel-next in sync. Acked-by:
-
Jani Nikula authored
Declutter i915_drv.h by splitting out the declarations for i915_gem.[ch]. Add a fixme comment about the rest of the stuff in i915_gem.h that doesn't really belong there. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/82a353c5c4b52df2354f9413b547c7619a45d92d.1662390010.git.jani.nikula@intel.com
-
Jani Nikula authored
I can't idenfity a single hot path that would require i915_gem_drain_freed_objects() to be inline. Un-inline it. Signed-off-by:
-
Jani Nikula authored
i915_gem_drain_workqueue() is not used on any hot paths. Un-unline it. Replace the do-while with a for loop while at it. Signed-off-by:
-
Jani Nikula authored
The function was removed four years ago in commit 6faf5916 ("drm/i915: Remove HW semaphores for gen7 inter-engine synchronisation"). Finish the job. Signed-off-by:
-
Jani Nikula authored
Apparently the last user of the macro was removed in commit 9c4ce97d ("drm/i915/display: Be explicit in handling the preallocated vma"). Signed-off-by:
-
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:
-
- Sep 05, 2022
-
-
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/5510 Signed-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/5558 Signed-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ä 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:
-
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.com Reviewed-by:
-
- Sep 03, 2022
-
-
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/6205 Signed-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/6205 Signed-off-by:
-
- Sep 02, 2022
-
-
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/6592 Signed-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:
-
