- 18 Nov, 2020 5 commits
-
-
Manasi Navare authored
Make vdsc work when no output is enabled. The big joiner needs VDSC on the slave, so enable it and set the appropriate bits. So remove encoder usage from dsc functions. Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com> Reviewed-by:
Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-5-manasi.d.navare@intel.com
-
Maarten Lankhorst authored
When the clock is higher than the dotclock, try with 2 pipes enabled. If we can enable 2, then we will go into big joiner mode, and steal the adjacent crtc. This only links the crtc's in software, no hardware or plane programming is done yet. Blobs are also copied from the master's crtc_state, so it doesn't depend at commit time on the other crtc_state. v6: * Enable dSC for any mode->hdisplay > 5120 v5: * Remove intel_dp_max_dotclock (Manasi) v4: * Fixes in intel_crtc_compute_config (Ville) v3: * Manual Rebase (Manasi) Changes since v1: - Rename pipe timings to transcoder timings, as they are now different. Changes since v2: - Rework bigjoiner checks; always disable slave when recalculating master. No need to have a separate bigjoiner pass any more. - Use pipe_mode instead of transcoder_mode, to clean up the code. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Maarten Lankhorst authored
Small changes to intel_dp_mode_valid(), allow listing modes that can only be supported in the bigjoiner configuration, which is not supported yet. v13: * Allow bigjoiner if hdisplay >5120 v12: * slice_count logic simplify (Ville) * Fix unnecessary changes in downstream_mode_valid (Ville) v11: * Make intel_dp_can_bigjoiner non static so it can be used in intel_display (Manasi) v10: * Simplify logic (Ville) * Allow bigjoiner on edp (Ville) v9: * Restric Bigjoiner on PORT A (Ville) v8: * use source dotclock for max dotclock (Manasi) v7: * Add can_bigjoiner() helper (Ville) * Pass bigjoiner to plane_size validation (Ville) v6: * Rebase after dp_downstream mode valid changes (Manasi) v5: * Increase max plane width to support 8K with bigjoiner (Maarten) v4: * Rebase (Manasi) Changes since v1: - Disallow bigjoiner on eDP. Changes since v2: - Rename intel_dp_downstream_max_dotclock to intel_dp_max_dotclock, and split off the downstream and source checking to its own function. (Ville) v3: * Rebase (Manasi) Signed-off-by:
-
Ville Syrjälä authored
When doing the plane state copy from the UV plane to the Y plane let's just copy the hw state directly instead of using the original uapi state. The UV plane has already had its uapi state copied into its hw state, so this extra detour via the uapi state for the Y plane is pointless. Signed-off-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
-
Ville Syrjälä authored
I totally fumbled the ?: usage when generating the DDI encoder names. Reverse the things that need reversing, and to make it a bit less messy add a few macros to hide the arithmetic on the port enums. Cc: Jani Nikula <jani.nikula@linux.intel.com> Fixes: 2d709a5a ("drm/i915: Give DDI encoders even better names") Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com>
-
- 17 Nov, 2020 2 commits
-
-
Bob Paauwe authored
The WA specifies that we need to toggle a SDE chicken bit on and then off as the final step in preparation for s0ix entry. Bspec: 33450 Bspec: 8402 However, something is happening after we toggle the bit that causes the WA to be invalidated. This makes dispcnlunit1_cp_xosc_clkreq active being already in s0ix state i.e SLP_S0 counter incremented. Tweaking the Wa_14010685332 by setting the bit on suspend and clearing it on resume turns down the dispcnlunit1_cp_xosc_clkreq. B.Spec has Documented this tweaked sequence of WA as an alternative. Let keep this tweaked WA for Gen11 platforms and keep untweaked WA for other platforms which never observed this issue. v2 (MattR): - Change the comment on the workaround to give PCH names rather than platform names. Although the bspec is setup to list workarounds by platform, the hardware team has confirmed that the actual issue being worked around here is something that was introduced back in the Cannon Lake PCH and carried forward to subsequent PCH's. - Extend the untweaked version of the workaround to include PCH_CNP as well. Note that since PCH_CNP is used to represent CMP, this will apply on CML and some variants of RKL too. - Cap the untweaked version of the workaround so that it won't apply to "fake" PCH's (i.e., DG1). The issue we're working around really is an issue in the PCH itself, not the South Display, so it shouldn't apply when there isn't a real PCH. v3: - use intel_de_rmw(). [Rodrigo] Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:Bob Paauwe <bob.j.paauwe@intel.com> Signed-off-by:
Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201110121700.4338-1-anshuman.gupta@intel.comReviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Ville Syrjälä authored
EDID can declare the maximum supported bpc up to 16, and apparently there are displays that do so. Currently we assume 12 bpc is tha max. Fix the assumption and toss in a MISSING_CASE() for any other value we don't expect to see. This fixes modesets with a display with EDID max bpc > 12. Previously any modeset would just silently fail on platforms that didn't otherwise limit this via the max_bpc property. In particular we don't add the max_bpc property to HDMI ports on gmch platforms, and thus we would see the raw max_bpc coming from the EDID. I suppose we could already adjust this to also allow 16bpc, but seeing as no current platform supports that there is little point. Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2632Signed-off-by:
José Roberto de Souza <jose.souza@intel.com>
-
- 16 Nov, 2020 12 commits
-
-
Ville Syrjälä authored
Move cnl_get_ddi_pll() into a better spot from between icl_get_ddi_pll() and dg1_get_ddi_pll(). Also reorder the calls to the skl and bxt functions because ocd. Signed-off-by:
Imre Deak <imre.deak@intel.com>
-
Ville Syrjälä authored
Currently the DPLL .get_freq() uses pll->state.hw_state which is not the thing we actually read out (except during driver load/resume). Outside of that pll->state.hw_state is just the thing we committed last time around. During state check we just read the thing into crtc_state->dpll_hw_state, so that is what we should use for calculating the DPLL output frequency. I think we used to do this so that the results of the readout were actually used, but somehow it got changed when the .get_freq() refactoring happened. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Ville Syrjälä authored
On icl+ we want to populate both crtc_state.{shared_dpll,dpll_hw_state} and crtc_state.port_dplls[] during readout, whereas on pre-icl we want to leave the latter stuff untouched. Rather than adding more ifs into hsw_get_ddi_port_state() to copy the DPLL hw state around let's just move the whole dpll readout into hsw_get_ddi_dpll() & co. Slightly repetitive, but meh. Signed-off-by: -
Ville Syrjälä authored
Add a wrapper for the pll .get_hw_state() vfunc. Makes life a bit less miserable when you don't have to worry where the function pointer is stored. Signed-off-by:
-
Ville Syrjälä authored
Replace skl_adjusted_plane_pixel_rate() with the generic intel_plane_pixel_rate(). The two should produce identical results. Signed-off-by:
-
Ville Syrjälä authored
Store the relative data rate for planes in the crtc state so that we don't have to use intel_atomic_crtc_state_for_each_plane_state() to compute it even for the planes that are no part of the current state. Should probably just nuke this stuff entirely an use the normal plane data rate instead. The two are slightly different since this relative data rate doesn't factor in the actual pixel clock, so it's a bit odd thing to even call a "data rate". And since the watermarks are computed based on the actual data rate anyway I don't really see what the point of this relative data rate is. But that's for the future... Signed-off-by:
-
Ville Syrjälä authored
In order to remove intel_atomic_crtc_state_for_each_plane_state() from skl_crtc_can_enable_sagv() we can simply precompute whether each wm level can tolerate the SAGV block time latency or not. This has the nice side benefit that we remove the duplicated wm level latency calculation. In fact the copy of that code we had in skl_crtc_can_enable_sagv() didn't even handle WaIncreaseLatencyIPCEnabled/Display WA #1141 whereas the copy in skl_compute_plane_wm() did. So now we just have the one copy which handles all the w/as. Signed-off-by:
-
Ville Syrjälä authored
Document what each of the "raw" vs. "optimal" vs. "intermediate" watermarks do. Signed-off-by:
-
Ville Syrjälä authored
intel_atomic_crtc_state_for_each_plane_state() peeks at the plane's current state without holding the plane's mutex, trusting that the crtc's mutex will protect it. In practice that does work since our planes can't move between pipes, but it sets a bad example. intel_atomic_crtc_state_for_each_plane_state() also relies on crtc_state.uapi.plane_mask which may be full of lies when it comes to the bigjoiner stuff, so soon we can't use it as is anyway. So best to just get rid of it entirely. Which we can easily do by switching to the g4x/vlv "raw" watermark approach. Later on we should even be able to move the "raw" watermark computation into the normal .plane_check() code, leaving only the merging/clamping of the final watermarks to the later stages. But that will require adjusting the ilk+ wm code similarly as well. Signed-off-by:
-
Ville Syrjälä authored
Pass the whole intel_atomic_state to skl_build_pipe_wm() and skl_allocate_pipe_ddb() so we can start to iterate stuff containerd in the commit. Signed-off-by:
-
Manasi Navare authored
No functional changes here, just adds a from_crtc_state as a prep for bigjoiner v2: * More prep with intel_atomic_state (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Manasi Navare authored
No functional changes, to align with previous cleanups pass intel_atomic_state instead of drm_atomic_state. Also pass this intel_atomic_state with crtc_state to some of the atomic_check functions. v2: * Squash some changes from next patch (Ville) Signed-off-by:
-
- 13 Nov, 2020 6 commits
-
-
Maarten Lankhorst authored
With bigjoiner, there will be 2 pipes driving 2 halves of 1 transcoder, because of this, we need a pipe_mode for various calculations, including for example watermarks, plane clipping, etc. v10: * remove redundant pipe_mode assignment (Ville) v9: * pipe_mode in state dump nd state check (Ville) v8: * Add pipe_mode in readout in verify_crtc_state (Ville) v7: * Remove redundant comment (Ville) * Just keep mode instead of pipe_mode (Ville) v6: * renaming in separate function, only pipe_mode here (Ville) * Add description (Maarten) v5: * Rebase (Manasi) v4: * Manual rebase (Manasi) v3: * Change state to crtc_state, fix rebase err (Manasi) v2: * Manual Rebase (Manasi) Signed-off-by:
-
Ville Syrjälä authored
Collect up a bunch of derived state "readout" into a common helper, which we can call from both intel_encoder_get_config() and intel_crtc_get_pipe_config(). Signed-off-by:
-
Ville Syrjälä authored
Generalize intel_mode_from_pipe_config() to work on any two arbitrary modes. Also relocate the code for the future, and make it static since it's not needed elsewhere. Signed-off-by:
-
Ville Syrjälä authored
No reason to make the callers of intel_crtc_get_pipe_config() populate hw.active. Let's do it in intel_crtc_get_pipe_config() itself. hw.enable we leave up to the callers since it's slightly different for readout vs. state check. Signed-off-by:
-
Manasi Navare authored
Create a new function intel_crtc_get_pipe_config() that calls platform specific hooks for get_pipe_config() No functional change here. Suggested-by:
-
Manasi Navare authored
No functional changes, create a separate intel_encoder_get_config() function that calls encoder->get_config hook. This is needed so that later we can add beigjoienr related readout here. Signed-off-by:
-
- 12 Nov, 2020 3 commits
-
-
Manasi Navare authored
No functional changes. This patch just moves some mode checks around to prepare for adding bigjoiner related mode validation Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
José Roberto de Souza authored
Just following what we do in many other places, DG1 is a exception so move it to the top instead of add it inside of INTEL_GEN(dev_priv) >= 12. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by:
-
José Roberto de Souza authored
DC9 has a separate HW flow from the rest of the DC states and it is available in GEN9 LP platforms and on GEN11 and newer, so here moving the assignment of the mask to a single conditional block to simplifly code. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by:
-
- 11 Nov, 2020 7 commits
-
-
Lucas De Marchi authored
Now that hpd/display related calls are split from the rest in intel_irq_init(), skip all of that in case we don't have display. Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Lucas De Marchi authored
In intel_irq_init() move what's display/hpd related after what is gt and guc. This makes it easier to support !HAS_DISPLAY() in future. Signed-off-by:
-
Lucas De Marchi authored
Use the convention of new platforms first. No need to special case HAS_GMCH() since that stopped being true at the lattest on gen8 (for cherryview). Signed-off-by:
-
Jani Nikula authored
!HAS_DISPLAY() implies !HAS_OVERLAY(), skipping overlay setup anyway, so return earlier from intel_modeset_init() for clarity. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
José Roberto de Souza authored
Display is always disabled and enabled when resetting any engine, but if there is no display it should not do anything with display and only reset the needed engines. Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Lucas De Marchi authored
Rename intel_finish_reset to intel_display_finish_reset, so it's clear from gt/ that we are calling out the display code. Signed-off-by:
-
Lucas De Marchi authored
Rename intel_prepare_reset to intel_display_prepare_reset, so it's clear from gt/ that we are calling out the display code. Signed-off-by:
-
- 10 Nov, 2020 1 commit
-
-
Ville Syrjälä authored
Reduce this maintenance nightmare a bit by converting the plane min/max width/height stuff into vfuncs. Now, if I could just think of a nice way to also use this for intel_mode_valid_max_plane_size()... Signed-off-by:
Aditya Swarup <aditya.swarup@intel.com>
-
- 09 Nov, 2020 2 commits
-
-
Tejas Upadhyay authored
JSL has update in vswing table for eDP. BSpec: 21257 Changes since V1: - Fixed few checkpatch errors Cc: Souza Jose <jose.souza@intel.com> Signed-off-by:Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com> Reviewed-by:
-
Lucas De Marchi authored
DG1 uses 2 registers for the ddi clock mapping, with PHY A and B using DPCLKA_CFGCR0 and PHY C and D using DPCLKA1_CFGCR0. Hide this behind a single macro that chooses the correct register according to the phy being accessed, use the correct bitfields for each pll/phy and implement separate functions for DG1 since it doesn't share much with ICL/TGL anymore. The previous values were correct for PHY A and B since they were using the same register as before and the bitfields were matching. v2: Add comment and try to simplify DG1_DPCLKA* macros by reusing previous ones v3: - Fix DG1_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK() after wrong macro reuse - Move phy -> id map to a separate macro (Aditya) - Remove DG1_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK where not required (Aditya) - Use drm_WARN_ON Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Clinton Taylor <Clinton.A.Taylor@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Aditya Swarup <aditya.swarup@intel.com> Signed-off-by:
-
- 06 Nov, 2020 2 commits
-
-
Ville Syrjälä authored
To help diagnose modifier related issues let's include that information in the various state dumps. Cc: Simon Ser <contact@emersion.fr> Signed-off-by:
Simon Ser <contact@emersion.fr>
-
Ville Syrjälä authored
Sort the EHL/JSL PCI IDs numerically. Some order seems better than randomness. v2: Deal with the JSL vs. EHL split v3: Rebase due to 0x4500 removal Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> #v1 Signed-off-by:
-
