- 16 Feb, 2022 12 commits
-
-
Matt Roper authored
The random order of register definitions we have today causes a lot of confusion and unintentional duplication when new registers/bits are added to the driver. Let's order the GT register file by MMIO offset A couple duplicated/unused register definitions are dropped while doing this re-order: GEN11_GT_INTR_DW{0,1}, GEN11_IIR_REG{0,1}_SELECTOR, and GEN11_INTR_IDENTITY_REG{0,1} aren't used anywhere in the driver because we have other parameterized macros referencing those registers. Signed-off-by:Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
Matt Atwood <matthew.s.atwood@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220209051140.1599643-7-matthew.d.roper@intel.com
-
Matt Roper authored
Switch all register offsets to use lowercase hex values for consistency. Also strip any unnecessary leading 0's. For example, "_MMIO(0x0D08)" becomes "_MMIO(0xd08)." Signed-off-by:
-
Matt Roper authored
There's a lot of inconsistent spacing and indentation in our register definitions. Let's clean things up a bit and follow some consistent rules: * "#define" always starts in column 0 * There's exactly one space between '#define' and the name of a register. * There's exactly three spaces between '#define' and the name of a bit/bitfield. * Tabs (no spaces) are used between a definition name and its value; the value starts on column 48 unless the name is too long, in which case a single tab is used. Final diff for this patch is empty if whitespace is ignored: $ git diff -w $ Signed-off-by: -
Matt Roper authored
We have both a parameterized RING_MI_MODE() macro and an RCS-specific MI_MODE; drop the latter and use the former everywhere. Signed-off-by:
-
Matt Roper authored
These SFC registers were defined in an unusual way, taking an engine as a parameter rather than an engine MMIO base offset. Let's adjust them to match the style used by other per-engine registers and move them to intel_engine_regs.h. While doing this move, we can drop GEN12_HCP_SFC_FORCED_LOCK completely; it was intended for use in an early version of a hardware workaround, but was no longer necessary by the time the workaround was finalized. It is not used anywhere in the driver. Signed-off-by:
-
Matt Roper authored
Due to some mistaken merge conflict resolution, we wound up with a copy of VDBOX_CGCTL3F18 in both intel_engine_regs.h and intel_gt_regs.h. Since this is a per-engine register, referenced relative to an engine's base offset, drop the copy from intel_gt_regs.h Signed-off-by:
-
Ville Syrjälä authored
intel_sagv_{pre,post}_plane_update() can accidentally forget to bail out early on pre-icl and proceed down the icl+ codepath at the end of the function. Fortunately it'll bail out before it gets too far due to old_qgv_mask==new_qgv_mask==0 so no real bug here. But lets make the code less confusing anyway. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220214091811.13725-5-ville.syrjala@linux.intel.comReviewed-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
-
Ville Syrjälä authored
adlp+ adds some extra bits to the QGV point mask. The code attempts to handle that but forgot to actually make sure we can store those bits in the bw state. Fix it. Cc: stable@vger.kernel.org Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Fixes: 192fbfb7 ("drm/i915: Implement PSF GV point support") Signed-off-by:
-
Ville Syrjälä authored
We treat SSKPD as a 64 bit register. Add the support macros to define/extract bits in such registers. v2: Fix 32bit builds Signed-off-by:
Jani Nikula <jani.nikula@intel.com>
-
Ville Syrjälä authored
Use the {active,scaled}_planes bitmasks from the crtc state rather than poking at the plane state directly. One step towards eliminating the last use of the somewhat questionble intel_atomic_crtc_state_for_each_plane_state() macro which peeks into the plane state without actually holding the plane mutex. Signed-off-by: -
Ville Syrjälä authored
Add another plane bitmask, this time tracking which planes are scaled. This is going to be useful in ILK watermark computations, and skl+ pipe scaler assignments. Signed-off-by:
-
Ville Syrjälä authored
Exfiltrate intel_plane_atomic_calc_changes() and its friends from intel_display.c to intel_atomic_plane.c since that is a much better fit. While at it also nuke the official looking kernel docs for intel_wm_need_update() and flag it for eventual destruction so that people don't get any wrong ideas about using it in new code. Signed-off-by:
-
- 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:
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:
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:
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 12 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:
-
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:
-
