- 15 Feb, 2022 6 commits
-
-
Ville Syrjälä authored
Get rid of the inflexible bigjoiner_linked_crtc pointer thing and just track things as a bitmask of pipes instead. We can also nuke the bigjoiner_slave boolean as the role of the pipe can be determined from its position in the bitmask. It might be possible to nuke the bigjoiner boolean as well if we make encoder.compute_config() do the bitmask assignment directly for the master pipe. But for now I left that alone so that encoer.compute_config() will just flag the state as needing bigjoiner, and the intel_atomic_check_bigjoiner() is still responsible for determining the bitmask. But that may have to change as the encoder may be in the best position to determine how exactly we should populate the bitmask. Most places that just looked at the single bigjoiner_linked_crtc now iterate over the whole bitmask, eliminating the singular slave pipe assumption. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220203183823.22890-11-ville.syrjala@linux.intel.comReviewed-by:
Manasi Navare <manasi.d.navare@intel.com>
-
Ville Syrjälä authored
Return both the master and slave pipe bitmasks from enabled_bigjoiner_pipes(). We'll have use for both during readout soon. Signed-off-by:
-
Ville Syrjälä authored
Convert a few hand roller for_each_intel_crtc_in_pipe_mask() to the real thing. Signed-off-by:
-
Ville Syrjälä authored
Often using pipes is more convenient than crtc indices. Convert the current for_each_intel_crtc_mask() to take a pipe mask instead of a crtc index mask, and rename it to for_each_intel_crtc_in_pipe_mask() to make it clear what it does. The current users of for_each_intel_crtc_mask() don't really care which kind of mask we use, but for other uses a pipe mask if better. Signed-off-by:
-
Ville Syrjälä authored
Introduce helpers to query whether the crtc is the slave/master for bigjoiner. This decouples most places from the exact state layout we use to track this relationship, allowing us to change and extend it more easily. Performed with cocci: @@ expression S, E; @@ ( S->bigjoiner_slave = E; | - S->bigjoiner_slave + intel_crtc_is_bigjoiner_slave(S) ) @@ expression S, E; @@ ( - E && S->bigjoiner && !intel_crtc_is_bigjoiner_slave(S) + E && intel_crtc_is_bigjoiner_master(S) | - S->bigjoiner && !intel_crtc_is_bigjoiner_slave(S) + intel_crtc_is_bigjoiner_master(S) ) @@ expression S; @@ - (intel_crtc_is_bigjoiner_master(S)) + intel_crtc_is_bigjoiner_master(S) @@ expression S, E1, E2, E3; @@ - intel_crtc_is_bigjoiner_slave(S) ? E1 : S->bigjoiner ? E2 : E3 + intel_crtc_is_bigjoiner_slave(S) ? E1 : intel_crtc_is_bigjoiner_master(S) ? E2 : E3 @@ typedef bool; @@ + bool intel_crtc_is_bigjoiner_slave(const struct intel_crtc_state *crtc_state) + { + return crtc_state->bigjoiner_slave; + } + intel_master_crtc(...) {...} @@ typedef bool; @@ + bool intel_crtc_is_bigjoiner_master(const struct intel_crtc_state *crtc_state) + { + return crtc_state->bigjoiner && !crtc_state->bigjoiner_slave; + } + intel_master_crtc(...) {...} @@ typedef bool; identifier S; @@ - bool is_trans_port_sync_mode(const struct intel_crtc_state *S); + bool is_trans_port_sync_mode(const struct intel_crtc_state *state); + bool intel_crtc_is_bigjoiner_slave(const struct intel_crtc_state *crtc_state); + bool intel_crtc_is_bigjoiner_master(const struct intel_crtc_state *crtc_state); Signed-off-by:Ankit Nautiyal <ankit.k.nautiyal@intel.com>
-
Chuansheng Liu authored
Current DMC_DEBUG3(_MMIO(0x101090)) address is for TGL, it is wrong for DG1. Just like commit 5bcc95ca ("drm/i915/dg1: Update DMC_DEBUG register"), correct this issue for DG1 platform to avoid wrong register being read. BSpec: 49788 v2: fix "not wrong" typo. (Jani) Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Chuansheng Liu <chuansheng.liu@intel.com> Signed-off-by:
-
- 14 Feb, 2022 10 commits
-
-
Jani Nikula authored
Group and sort includes in i915_drv.h similar to other places. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Acked-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/679923380d4757fed4e3a4c4bed80e40b9fdaeec.1644507885.git.jani.nikula@intel.com
-
Jani Nikula authored
It's fairly difficult to ensure these are actually not needed due to indirect includes via other files. However, it's easier to add them back as needed and, most importantly, where needed instead of exhaustively proving they're unnecessary. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Jani Nikula authored
Include drm_fourcc.h, drm_plane.h, and drm_color_mgmt.h where needed, so we can drop the includes for drm_atomic.h and drm_fourcc.h from i915_drv.h, reducing the build dependencies. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Jani Nikula authored
Don't include shmem_fs.h in i915_drv.h, reducing the build dependencies. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Jani Nikula authored
Include it only in files that use it. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Jani Nikula authored
Limit the scope of struct drm_i915_file_private to the files that actually need it. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Jani Nikula authored
It doesn't help much, as i915_drv.h includes i915_gpu_error.h, but it's a step in the right direction. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Jani Nikula authored
Move the function next to the only user. Arguably it's perhaps not the best place, but it's much better than having a static inline in a header. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Jani Nikula authored
Move the function next to the only user. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Jani Nikula authored
We already have the gem/i915_gem_domain.c file. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
- 11 Feb, 2022 24 commits
-
-
Ville Syrjälä authored
Remove all the dead code from icl_ddi_bigjoiner_pre_enable(). Signed-off-by:
-
Ville Syrjälä authored
Currently the bigjoiner state copy logic is kind of a byzantine mess. Clean it up to operate in the following manner during a full modeset: 1) master uapi -> hw state copy 2) master hw -> slave hw state copy And during a non-modeset update we do: 1) master uapi -> hw state light copy 2) master hw -> slave hw state light copy I think that is now easier to reason about since we never do any kind of master uapi -> slave hw state copy short circuit that could happen previously. Obviously this does now depend on the master uapi->hw copy always happening before the master hw -> slave hw copy, but that is guaranteed by the fact that we always add both crtcs to the state early, the crtcs are registered in pipe order (so the compute_config loop happens in pipe order), and the hardware requires the master pipe has to be lower than the slave pipe as well. And for good measure we shall add a check+WARN for this before doing the bigjoiner crtc assignment. v2: Fix uapi.ctm vs. hw.ctm copy-paste fail Signed-off-by:
-
Ville Syrjälä authored
There's some weird junk in intel_atomic_check_bigjoiner() that's trying to look at the old crtc state's bigjoiner usage for some reason. That code is totally unnecessary, and maybe even actively harmful. Not entirely sure which since it's such a mess that I can't actually wrap my brain around what it ends up doing. Either way, thanks to intel_bigjoiner_add_affected_crtcs() all of the old bigjoiner crtcs are guaranteed to be in the state already if any one of them is in the state. Also if any one of those crtcs got flagged for a modeset, then all of them will have been flagged, and the bigjoiner links will have been detached via kill_bigjoiner_slave(). So there is no need to look examing any old bigjoiner usage in intel_atomic_check_bigjoiner(). All we have to care about is whether bigjoiner is needed for the new state, and whether we can get the slave crtc we need. Signed-off-by:
-
Ville Syrjälä authored
We seem to be missing a few things from the bigjoiner state copy. Namely hw.mode isn't getting copied (which probably causes PIPESRC to be misconfigured), CTM/LUTs aren't getting copied (which could cause the pipe to produced incorrect output), and we also forgot to copy over the color_mgmt_changed flag so potentially we fail to do the actual CTM/LUT programming (assuming we aren't doing a full modeset or fastset). Fix it all. v2: Fix uapi.ctm vs. hw.ctm copy-paste fail Signed-off-by:
-
Ville Syrjälä authored
The core doesn't flag scaling_filter prop changes as needing a modeset. That doesn't work for us since we only reprogram the pipe scaler during full modesets and fastsets. So we need to flag the prop change as a modeset ourselves. Assuming nothing else has changed the operation will get promoted (demoted?) to a fastset later. Signed-off-by:
-
Ville Syrjälä authored
Reuse intel_hdmi_tmds_clock() for DP->HDMI TMDS clock calculations. Signed-off-by:
-
Ville Syrjälä authored
Just loop over the possible bpc values instead of using an ugly if construct. A slight change in behaviour is that we now call intel_hdmi_{source,sink}_bpc_possible() even for 8bpc, but that is fine since 8bpc is always supported. Signed-off-by: -
Ville Syrjälä authored
Extract the dbuf slice data_rate calculation into a small helper. Should make it a bit easier to handle the different color planes of planar formats correctly. Signed-off-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
-
Ville Syrjälä authored
Replace some copy-pasta with a function. Signed-off-by:
-
Ville Syrjälä authored
Collect a bit of the stuff used during the plane ddb allocation into a struct we can pass around. Signed-off-by:
-
Ville Syrjälä authored
We are currently computing the relative data rates as src_size * scale_factor where scale_factor is src_size / dst_size. Thus relative data rate is src_size * src_size / dst_size, which is just utter nonsense. What we really seem to want is just a reasonable estimate on how much data will be fetched which is just src_size. So let's do that instead. Signed-off-by:
-
Ville Syrjälä authored
Extract a small helper to populate a ddb entry. Signed-off-by:
-
Ville Syrjälä authored
skl_ddb_entry_init_from_hw() has no need for dev_priv. Signed-off-by:
-
Jani Nikula authored
We already have the gem/i915_gem_create.c file. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Jani Nikula authored
We already have the gem/i915_gem_dmabuf.c file. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Ville Syrjälä authored
commit c50df701 ("drm/i915: Enable rpm wakeref tracking whether runtime pm is enabled or not") enabled wakeref tracking even for the mock device. Turns out that has somewhat significant overhead, and on the glacial Core m3's we have in CI the vma selftests are now exceeding the allotted time budget. So let's disable the wakeref tracking once again for the mock device in order to avoid blowing up the selftest runtime. Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Acked-by:
Tomi Sarvela <tomi.p.sarvela@intel.com> Signed-off-by:
-
Jani Nikula authored
Remove the duplicates. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Jani Nikula authored
We already have the i915_gem_internal.c file. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Jani Nikula authored
128b/132b supports using 64 slots starting from 0, while 8b/10b reserves slot 0 for metadata. Commit d6c6a76f ("drm: Update MST First Link Slot Information Based on Encoding Format") added support for updating the topology state accordingly, and commit 41724ea2 ("drm/amd/display: Add DP 2.0 MST DM Support") started using it in the amd driver. This feels more than a little cumbersome, especially updating the information in atomic check. For i915, add the update to MST connector .compute_config hook rather than iterating over all MST managers and connectors in global mode config .atomic_check. Fingers crossed. v3: - Propagate errors from intel_dp_mst_update_slots() (Ville) v2: - Update in .compute_config() not .atomic_check (Ville) Cc: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by:
Lyude Paul <lyude@redhat.com> Reviewed-by:
-
Jani Nikula authored
Abstract link status check to a function that takes 128b/132b and 8b/10b into account, and use it. Also dump link status on failures. Cc: Uma Shankar <uma.shankar@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Jani Nikula authored
The DP 2.0 errata completely overhauls the 128b/132b link training, with no provisions for backward compatibility with the original DP 2.0 specification. The changes are too intrusive to consider reusing the same code for both 8b/10b and 128b/132b, mainly because the LTTPR channel equalisation is done concurrently instead of serialized. NOTES: * It's a bit unclear when to wait for DP_INTERLANE_ALIGN_DONE and per-lane DP_LANE_SYMBOL_LOCKED. Figure xx4 in the SCR implies the LANEx_CHANNEL_EQ_DONE sequence may end with either 0x77,0x77,0x85 *or* 0x33,0x33,0x84 (for four lane configuration in DPCD 0x202..0x204) i.e. without the above bits set. Text elsewhere seems contradictory or incomplete. * We read entire link status (6 bytes) everywhere instead of individual DPCD addresses. * There are some subtle ambiguities or contradictions in the order of some DPCD access and TPS signal enables/disables. It's also not clear whether these are significant. v4: - Wait for intra-hop clear after link training end (Ville) - Wait instead of single check for intra-hop clear before link train v3: - Use msecs_to_jiffies_timeout() (Ville) - Read status at the beginning of interlane align done loop (Ville) - Try to simplify timeout flag use where possible (Ville) v2: - Always try one last time after timeouts to avoid races (Ville) - Extend timeout to cover the entire LANEx_EQ_DONE sequence (Ville) - Also check for eq interlane align done in LANEx_CDS_DONE Sequence (Ville) - Check for Intra-hop status before link training Cc: Uma Shankar <uma.shankar@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Jani Nikula authored
Call it from the higher level function, as it will be shared between two code paths. Cc: Uma Shankar <uma.shankar@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Jani Nikula authored
Add some of the new additions from DP 2.0 E11. Cc: Uma Shankar <uma.shankar@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/ec9c1b94858de36b9f4ef6c197effa4ca667afc3.1643878928.git.jani.nikula@intel.com
-
Jani Nikula authored
The DP 2.0 errata redefines link training. There are some new status bits, and some of the old ones need to be checked independently. Add helpers to do this. Cc: Uma Shankar <uma.shankar@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
