- 18 Nov, 2020 11 commits
-
-
Maarten Lankhorst authored
We need to look at hw.fb for the framebuffer, and add the translation for the slave_plane_state. With these changes we set the correct rectangle on the bigjoiner slave, and don't set incorrect src/dst/visibility on the slave plane. v2: * Manual rebase (Manasi) v3: * hw.rotation instead of uapi.rotation (Ville) Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com> Reviewed-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-11-manasi.d.navare@intel.com
-
Ville Syrjälä authored
When using bigjoiner userspace is only controlling the "master" plane, so use its uapi state for the "slave" plane as well. hw.crtc needs a bit of magic since we don't want to copy that from the uapi state (as it points to the wrong pipe for the "slave " plane). Instead we pass the right crtc in explicitly but only assign it when the uapi state indicates the plane to be logically enabled (ie. uapi.crtc != NULL). Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Ville Syrjälä authored
Make sure both the bigjoiner "master" and "slave" plane are in the state whenever either of them is in the state. Signed-off-by:
-
Ville Syrjälä authored
Make sure both crtcs participating in the bigjoiner stuff are in the state. Signed-off-by:
-
Manasi Navare authored
Skip iterating over bigjoiner slaves, only the master has the state we care about. Add the width of the bigjoiner slave to the reconstructed fb. Hide the bigjoiner slave to userspace, and double the mode on bigjoiner master. And last, disable bigjoiner slave from primary if reconstruction fails. v3: * Fix the ddi_get_config slave error (Ankit Nautiyal) v2: * Unsupported bigjoiner config for initial fb (Ville) Signed-off-by:
Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-7-manasi.d.navare@intel.com
-
Manasi Navare authored
Enabling is done in a special sequence and so should plane updates be. Ideally the end user never notices the second pipe is used. This way ideally everything will be tear free, and updates are really atomic as userspace expects it. This uses generic modeset_enables() calls like trans port sync but still has special handling for disable since for slave we should not disable things like encoder, plls that are not enabled for slave. Signed-off-by:
-
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:
-
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 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:
-
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 6 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:
-
