- 18 Feb, 2022 12 commits
-
-
Ville Syrjälä authored
The CHV CGM CSC registers are single buffered and so we may have to write them from the vblank worker, which imposes very tight dealines. Drop the pointless locking for the register accessess to reduce the overhead. All the other registers we bash from the vblank worker (LUTs) were already made lockless earlier. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220202111616.1579-3-ville.syrjala@linux.intel.comReviewed-by:
Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
-
Ville Syrjälä authored
The pipe/output CSC register writes don't need to be locked since all the registers are suitably isolated to their own cachelines. So eliminate the locks to reduce the overhead during the vblank evade critical section. Signed-off-by:
-
Ville Syrjälä authored
We don't want any RMWs in the part of the commit that happens under vblank evasion. Eventually we want to use the DSB to handle that and it can't read registers at all. Also reads are just slowing us down needlessly. Let's move the whole PIPE_CHICKEN stuff out from the critical section since we don't have anything there that needs to be syncrhonized with other plane/pipe registers. If we ever need to add such things then we have to move it back, but without doing any reads. TODO: should look into eliminating the RMW anyway... Signed-off-by:
-
José Roberto de Souza authored
PSR2 workaround required when mode has delayed vblank. BSpec: 52890 BSpec: 49421 Cc: Jouni Högander <jouni.hogander@intel.com> Reviewed-by:
Jouni Högander <jouni.hogander@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220210185223.95399-2-jose.souza@intel.com
-
José Roberto de Souza authored
Grouping inside of the same if all the programing sequences and workarounds of PSR2. The order of programing changed in intel_psr_enable_source() but it will not affect PSR2 as at this point PSR2_ENABLE is still disabled. Cc: Jouni Högander <jouni.hogander@intel.com> Signed-off-by:
-
José Roberto de Souza authored
A new programming step was added to combo and TC PLL sequences. If override_AFC_startup is set in VBT, driver should overwrite AFC_startup value to 0x0 or 0x7 in PLL's div0 register. The current understating is that only TGL needs this and all other display 12 and newer platforms will have a older VBT or a newer VBT with override_AFC_startup set to 0 but in any case there is a drm_warn_on_once() to let us know if this is not true. v2: - specification updated, now AFC can be override to 0x0 or 0x7 - not using a union for div0 (Imre) - following previous wrong vbt naming: bits instead of bytes (Imre) BSpec: 49204 BSpec: 20122 BSpec: 49968 BSpec: 71360 Cc: Imre Deak <imre.deak@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Imre Deak authored
BIOS may leave a TypeC PHY in a connected state even though the corresponding port is disabled. This will prevent any hotplug events from being signalled (after the monitor deasserts and then reasserts its HPD) until the PHY is disconnected and so the driver will not detect a connected sink. Rebooting with the PHY in the connected state also results in a system hang. Fix the above by disconnecting TypeC PHYs on disabled ports. Before commit 64851a32 the PHY connected state was read out even for disabled ports and later the PHY got disconnected as a side effect of a tc_port_lock/unlock() sequence (during connector probing), hence recovering the port's hotplug functionality. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5014 Fixes: 64851a32 ("drm/i915/tc: Add a mode for the TypeC PHY's disconnected state") Cc: <stable@vger.kernel.org> # v5.16+ Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Jani Nikula authored
The variable should obviously be local, not static. Fixes: a421d8a9 ("drm/i915/dp: rewrite DP 2.0 128b/132b link training based on errata") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220217083938.3587465-1-jani.nikula@intel.com
-
Ville Syrjälä authored
Use REG_GENMASK() & co. for ilk+ watermark registers. v2: Stick to the current bitmask sizes (Jani) Fix "watermarm" typo (Jani) Reviewed-by: -
Ville Syrjälä authored
No reason the high level intel_update_crtc() needs to know that there is something magical about the commit order of planes between different platforms. So let's hide that detail even better. In order to keep to somewhat consistent naming between things we shall call this intel_crtc_planes_update_arm() to match the plane->update_arm() vfunc naming convention. And let's rename the noarm counterpart to intel_crtc_planes_update_noarm() to more clearly associate it with the plane->update_noarm() vfunc. v2: Change the naming convention a bit Reviewed-by:
-
Ville Syrjälä authored
Give names to the SSKPD/MLTR fields, and use the REG_GENMASK* and REG_FIELD_GET*. Also drop the bogus non-mirrored SSKP register define. v2: Rebase due to intel_mchbar_regs.h Leave gen6_check_mch_setup() in place for the moment Reviewed-by: -
Matt Roper authored
We need to use phy_name() to convert the PHY value into a human-readable character in the error message. Fixes: a6a12811 ("drm/i915/dg2: Wait for SNPS PHY calibration during display init") Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
Swathi Dhanavanthri <swathi.dhanavanthri@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220215163545.2175730-1-matthew.d.roper@intel.com
-
- 17 Feb, 2022 6 commits
-
-
Jani Nikula authored
Prefer forward declarations over includes if possible. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220214173810.2108975-2-jani.nikula@intel.com
-
Jani Nikula authored
Move the static inline next to the only caller. Signed-off-by:
-
Jani Nikula authored
As all access to struct intel_fbdev guts is nicely stowed away in intel_fbdev.c, we can hide the struct definition there too. Reviewed-by:
-
Jani Nikula authored
Wrap accessing struct intel_fbdev guts in a helper. v2: s/intel_fbdev_to_framebuffer/intel_fbdev_framebuffer/g (Ville) Reviewed-by:
-
Tong Zhang authored
drm/i915 adds some extra cflags, namely -Wall, which causes instances of -Wformat-security to appear when building with clang, even though this warning is turned off kernel-wide in the main Makefile: drivers/gpu/drm/i915/gt/intel_gt.c:983:2: error: format string is not a string literal (potentially insecure) [-Werror,-Wformat-security] GEM_TRACE("ERROR\n"); ^~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/i915/i915_gem.h:76:24: note: expanded from macro 'GEM_TRACE' #define GEM_TRACE(...) trace_printk(__VA_ARGS__) ^~~~~~~~~~~~~~~~~~~~~~~~~ ./include/linux/kernel.h:369:3: note: expanded from macro 'trace_printk' do_trace_printk(fmt, ##__VA_ARGS__); \ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./include/linux/kernel.h:383:30: note: expanded from macro 'do_trace_printk' __trace_bprintk(_THIS_IP_, trace_printk_fmt, ##args); \ ^~~~~~~~~~~~~~~~ drivers/gpu/drm/i915/gt/intel_gt.c:983:2: note: treat the string as an argument to avoid this This does not happen with GCC because it does not enable -Wformat-security with -Wall. Disable -Wformat-security within the i915 Makefile so that these warnings do not show up with clang. Signed-off-by:Tong Zhang <ztong0001@gmail.com> Reviewed-by:
Nathan Chancellor <nathan@kernel.org> Signed-off-by:
-
Jani Nikula authored
As the excessive #includes from i915_drv.h were axed, kvmgt.c build started failing. Add the necessary #include where needed. Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Fixes: 14da21cc ("drm/i915: axe lots of unnecessary includes from i915_drv.h") Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: Zhi Wang <zhi.a.wang@intel.com> Cc: intel-gvt-dev@lists.freedesktop.org Signed-off-by:
Zhi Wang <zhi.a.wang@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220215122030.2741656-1-jani.nikula@intel.com
-
- 16 Feb, 2022 15 commits
-
-
Matt Roper authored
The new header from the previous commit didn't get added after a conflict resolution...let's add it now. Fixes: e30e6c7b ("drm/i915: Move MCHBAR registers to their own header") Signed-off-by:
-
Matt Roper authored
Registers that exist within the MCH BAR and are mirrored into the GPU's MMIO space are a good candidate to separate out into their own header. For reference, the mirror of the MCH BAR starts at the following locations in the graphics MMIO space (the end of the MCHBAR range differs slightly on each platform): * Pre-gen6: 0x10000 * Gen6-Gen11 + RKL: 0x140000 v2: - Create separate patch to swtich a few register definitions to be relative to the MCHBAR mirror base. - Drop upper bound of MCHBAR mirror from commit message; there are too many different combinations between various platforms to list out, and the documentation is spotty for the older pre-gen6 platforms anyway. Bspec: 134, 51771 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Suggested-by:
-
Matt Roper authored
A few of our MCH registers are defined with absolute register offsets. For consistency, let's switch their definitions to be relative offsets from MCHBAR_MIRROR_BASE. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Suggested-by:
-
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 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: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:
-
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 1 commit
-
-
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:
-
