- 17 Apr, 2024 11 commits
-
-
Ville Syrjälä authored
Start making the GMCH DPLL code a bit more like the more modern platforms by separating out the DPLL hw state readout from the rest of the pipe readout. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412182703.19916-8-ville.syrjala@linux.intel.comReviewed-by:
Jani Nikula <jani.nikula@intel.com>
-
Ville Syrjälä authored
Let's not repeat ourselves so much and pull the entire PCH DPLL FP register value calculation into its own function. Signed-off-by:
-
Ville Syrjälä authored
Pull the code to calculate PCH DPLL tuning factor into its own function. Helps declutter ilk_update_pll_dividers(). Signed-off-by:
-
Ville Syrjälä authored
Spinkle local PLL hw_state variables into various low level PLL functions. Will make subsequent changes cleaner when we don't have to touch so many places when renaming struct members and whatnot. Signed-off-by:
-
Ville Syrjälä authored
We have zero consistency in out PLL state naming scheme. Try to unify things a bit by using 'dpll_hw_state' for high level stuff and just 'hw_state' for low level stuff. Currently both are the same, but I want to unionize intel_dpll_hw_state at which point using different names can make it more clear whether we're talking about the whole union or just the embedded platform specific struct. Signed-off-by:
-
Ville Syrjälä authored
Since we now have the printer around for intel_dpll_dump_hw_state() use it for all the other PLL prints as well. Just to make the thing looks less crazy. Signed-off-by:
-
Ville Syrjälä authored
Just use intel_dpll_dump_hw_state() instead of hand rolling it. Signed-off-by:
-
Luca Coelho authored
We only need DMC wakelocks when we allow DC5 and DC6 states. Add the calls to enable and disable DMC wakelock accordingly. Reviewed-by:
Uma Shankar <uma.shankar@intel.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412094148.808179-5-luciano.coelho@intel.comSigned-off-by:
-
Luca Coelho authored
This feature should be disabled by default until properly tested and mature. Add a module parameter to enable the feature for testing, while keeping it disabled by default for now. Reviewed-by:
-
Luca Coelho authored
Only allow running DMC wakelock code if the display version is 20 or greater. Also check if DMC is loaded before enabling. Reviewed-by:
-
Luca Coelho authored
In order to reduce the DC5->DC2 restore time, wakelocks have been introduced in DMC so the driver can tell it when registers and other memory areas are going to be accessed and keep their respective blocks awake. Implement this in the driver by adding the concept of DMC wakelocks. When the driver needs to access memory which lies inside pre-defined ranges, it will tell DMC to set the wakelock, access the memory, then wait for a while and clear the wakelock. The wakelock state is protected in the driver with spinlocks to prevent concurrency issues. BSpec: 71583 Signed-off-by:
-
- 11 Apr, 2024 7 commits
-
-
Vidya Srinivas authored
We need bigjoiner support with MST functionality for MST monitor resolutions > 5K to work. Adding support for the same. v2: Addressed review comments from Jani. Revert rejection of MST bigjoiner modes and add functionality v3: Fixed pipe_mismatch WARN for mst_master_transcoder Credits-to: Manasi Navare <navaremanasi@chromium.org> v4: Utilize intel_crtc_joined_pipe_mask() also for handling bigjoiner slave pipes for MST case(Stan) [v5: vsyrjala: chunked the modeset squence stuff out, removed bogus mst master transcoder hack, keep mgr_lock near the full_pbn check] [v6: vsyrjala: Calculate DSC slices correctly for bigjoiner (Imre)] Reviewed-by:Manasi Navare <navaremanasi@chromium.org> Reviewed-by:
Arun R Murthy <arun.r.murthy@intel.com> Signed-off-by:
Vidya Srinivas <vidya.srinivas@intel.com> Co-developed-by:
-
Ville Syrjälä authored
Loop over all joined pipes at relevant points in the MST modeset sequence. Carved out from Vidya's earlier big patch, with naming/etc. changed to match the earlier hsw_crtc_enable() stuff. Reviewed-by:
-
Stanislav Lisovskiy authored
Handle only bigjoiner masters in skl_commit_modeset_enables/disables, slave crtcs should be handled by master hooks. Same for encoders. That way we can also remove a bunch of checks like intel_crtc_is_bigjoiner_slave. v2: - Moved skl_pfit_enable, intel_dsc_enable, intel_crtc_vblank_on to intel_enable_ddi, so that it is now finally symmetrical with the disable case, because currently for some weird reason we are calling those from skl_commit_modeset_enables, while for the disable case those are called from the ddi disable hooks. v3: - Create intel_ddi_enable_hdmi_or_sst symmetrical to intel_ddi_post_disable_hdmi_or_sst and move it also under non-mst check. v4: - Fix intel_enable_ddi sequence - Call intel_crtc_update_active_timings for slave pipes as well [v5: vsyrjala: Use the name 'pipe_crtc' for the per-pipe crtc pointer Use consistent style and naming Protect macro arguments properly Drop superfluous changes to the modeset sequence, this now follows the old non-joiner sequence 100% apart from just looping in places] Signed-off-by:Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Tested-by:
-
Ville Syrjälä authored
Reorganize the crtc disable path to only deal with the master pipes/transcoders in intel_old_crtc_state_disables() and offload the handling of joined pipes to hsw_crtc_disable(). This makes the whole thing much more sensible since we can actually control the order in which we do the per-pipe vs. per-transcoder modeset steps. v2: Use the name 'pipe_crtc' for the per-pipe crtc pointer Tested-by:
-
Ville Syrjälä authored
Unify the master vs. slave handling in intel_ddi_post_disable_hdmi_or_sst() by looping over all the pipes in one go. This also lets us move the intel_crtc_vblank_off() calls to happen in a consistent place vs. the transcoder disable. Previously we did the master vs. slaves on different sides of that. v2: Use the name 'pipe_crtc' for the per-pipe crtc pointer Tested-by:
-
Ville Syrjälä authored
Extract the "not-MST" stuff from intel_ddi_post_disable() so that the whole thing isn't so cluttered. The bigjoiner slave handling was outside of the !MST check, but it really should have been inside it as its the counterpart to the master handling inside the check. So we pull that in as well. There is no functional change here as we don't currently support bigjoiner+MST anyway. v2: Rebase v3: Actually extract the slave code as claimed in the commit message (presumably a rebase fail in v2) Tested-by: -
Jouni Högander authored
Intel_dp->link_rate is not yet set at this point. Instead use crtc_state->port_clock. Fixes: 0dd21f83 ("drm/i915/psr: Silence period and lfps half cycle") Signed-off-by:
Jouni Högander <jouni.hogander@intel.com> Reviewed-by:
Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240409085759.178235-1-jouni.hogander@intel.com
-
- 10 Apr, 2024 7 commits
-
-
Imre Deak authored
Add a workaround to fix BS (blank start) to BS jitter fixes on non-UHBR MST/FEC and UHBR links. Bspec doesn't provide an actual WA ID for this. Bspec: 65448, 50054 Reviewed-by:
Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240129175533.904590-7-imre.deak@intel.com
-
Imre Deak authored
Disable the workaround inserting an SF symbol between the last DSC EOC symbol and the subsequent BS symbol. The WA is enabled by default - based on the register's reset value - and Bspec requires disabling it explicitly. Bspec doesn't provide an actual WA ID for this. Bspec: 50054, 65448, 68849 Reviewed-by:
-
Imre Deak authored
Add a workaround to fix timing issues on links with DSC enabled - presumedly related to the audio functionality. Bspec requires enabling this workaround if audio is enabled on ADLP, however Windows enables it whenever DSC is enabled ADLP onwards; follow Windows. Bspec: 50490, 55424 v2: Fix WA code comment formatting. (Ankit) Reviewed-by:
-
Imre Deak authored
Add a workaround to fix BS-BS jitter issues on MST links, aligning DPT/DPTP MTPs. Bspec: 50050, 55424 Reviewed-by:
-
Imre Deak authored
Add a workaround to fix BS jitter issues on MST links if the HBLANK period is less than 1 MTP. The WA applies only to UHBR rates while on non-UHBR the specification requires disabling it explicitly - presumedly because the register's reset value has the WA enabled. Bspec: 50050, 55424 Reviewed-by:
-
Imre Deak authored
Add a workaround to fix BS (blank start) to BS jitter issues on MST links when FEC is enabled. Neither Bspec requires this nor Windows clears the WA when disabling the output - presumedly because CHICKEN_MISC_3 gets reset after disabling the pipe/transcoder - so follow suit. Bspec: 50050, 55424 Reviewed-by:
-
Jani Nikula authored
Continue with placing debugfs next to the implementation. Reviewed-by:
-
- 09 Apr, 2024 13 commits
-
-
Ville Syrjälä authored
Add a small helper to compute the set of pipes that the current crtc is using. And we have at least one trivial place in intel_ddi_update_active_dpll() where we can use it immediately, so let's do that. v2: Use the name 'pipe_crtc' for the per-pipe crtc pointer Tested-by:
-
Ville Syrjälä authored
Pass the connector explicitly to intel_dp_need_bigjoiner() so that it'll actually check the correct place for the bigjoiner force flag. Tested-by:
-
Ville Syrjälä authored
intel_dp_mst_compute_config() is missing the "does the joiner need DSC?" check despite claiming to have a lot of other joiner/dsc stuff in there (albeit disabled). Replicate the logic from the SST side. TODO: refactor all this duplicated code! Tested-by:
-
Ville Syrjälä authored
Pull the "does joiner need DSC?" check into a helper. MST will want to use this too at some point. Tested-by:
-
Ville Syrjälä authored
Rename intel_dp_can_bigjoiner() to intel_dp_has_bigjoiner() to better reflect its function. Tested-by:
Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by:
-
Jani Nikula authored
Prefer common check_add_overflow() from overflow.h over the locally rolled versions of it. While check_add_overflow() does require a variable to assign to, unlike add_overflows_t(), it's still better than having multiple versions around. Cc: Kees Cook <keescook@chromium.org> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240405202625.2525671-1-jani.nikula@intel.comSigned-off-by:
-
Jani Nikula authored
The info is related to display, and should be placed under i915->display. Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Jani Nikula authored
The info is related to display, and should be placed under i915->display. Reviewed-by:
-
Jani Nikula authored
The info is related to display, and should be placed under i915->display. Reviewed-by:
-
Jani Nikula authored
The info is related to display, and should be placed under i915->display. Start a new irq sub-substruct. Reviewed-by:
-
Jani Nikula authored
The info is related to display, and should be placed under i915->display. Reviewed-by:
-
Jani Nikula authored
The info is related to display, and should be placed under i915->display. Reviewed-by:
-
Jani Nikula authored
The same info is available in i915_cdclk_info. Reviewed-by:
-
- 08 Apr, 2024 2 commits
-
-
Ville Syrjälä authored
With bigjoiner the master crtc is the one that will send out the uapi event/etc. We want that to happen after all the slaves are done, so let's try to do the commits in reverse order so that the master comes last. Even worse, the modeset helper will simply complete the commit on the slave pipe immediately as it consider the crtc to be inactive (it can't see our crtc_state->hw.active/etc.). With regular sync updates this generally doesn't matter all that much as the slave pipe should typically finish its work during the same frame as the master pipe. However in case the slave pipe's commit slips into the next frame we end up in a bit of trouble. This is most visible with either async flips (currently disabled with bigjoiner exactly for this reason), and DSB gamma updates. With DSB the problem happens because the DSB itself will wait until the next start vblank before starting to execute. So if the master pipe already finished its commit and the DSB on the slave pipe is still waiting for the next vblank we will assume the DSB as gotten stuck and terminate it. Reversing the commit order should ameliarate this for the most part as the master pipe is guaranteed to start its commit after the slave pipe started. The one thing that can still screw us over is the fact that we aren't necessarily going to commit the pipes in the reverse order as the actual order is dictated by the DDB overlap avoidance. But that can only happen while other pipes are being enabled/disabled, and so in the normal steady state we should be safe. The full fix will involve making the commit machinery aware of the slave pipes and not finish their commits prematurely. But that will involve a bit more work than this. And this commit order reversal will still be beneficial to avoid userspace getting an -EBUSY from the following page flip if the second pipe's commit does stretch into the next frame. Signed-off-by:
-
Ville Syrjälä authored
Currently intel_modeset_pipe_config_late() is called after the bigjoiner state copy, and it will actually not do anything for bigjoiner slaves. This can lead to a mismatched state between the master and slave. The two things that we do in the encoder .compute_config_late() hook are mst master transcoder and port sync master transcoder elections. So if either of either MST or port sync is combined with bigjoiner then we can see the mismatch. Currently this problem is more or less theoretical; MST+bigjoiner has not been implemented yet, and port sync+bigjoiner would require a tiled display with >5k tiles (or a very high dotclock per tile). Although we do have kms_tiled_display in igt which can fake a tiled display, and we can now force bigjoiner via debugfs, so it is possible to trigger this if you try hard enough. Reorder the code such that intel_modeset_pipe_config_late() will be called before the bigjoiner state copy happens so that both pipes will end up with the same state. Tested-by:
-
