Use the clean "atomic_state+crtc" approach of passing
arguments to the top level PCH modeset code.
And while at it we can also just pass the whole crtc to
ilk_disable_pch_transcoder().
v2: Elimiate double space between function args (Dave)
Cc: Dave Airlie <airlied@redhat.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211015071625.593-4-ville.syrjala@linux.intel.com
Reviewed-by: Dave Airlie <airlied@redhat.com>
Start moving the code for PCH modeset sequence/etc. to
its own file.
Still not sure about the file name though...
Cc: Dave Airlie <airlied@redhat.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211015071625.593-3-ville.syrjala@linux.intel.com
Reviewed-by: Dave Airlie <airlied@redhat.com>
Move the PCH refclk stuff (including all the LPT/WPT
iCLKIP/CLKOUT_DP things) to its own file.
We also suck in the mPHY programming from intel_fdi.c
since we're the only caller.
Cc: Dave Airlie <airlied@redhat.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211015071625.593-2-ville.syrjala@linux.intel.com
Reviewed-by: Dave Airlie <airlied@redhat.com>
There's no such thing as gen13. It is either display 13
or graphics 13. Don't propagate the gen12 confusion
further.
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211015091650.87270-1-rodrigo.vivi@intel.com
We should stop using the gen name and the "+" to reference
the newer platforms.
And on this case specifically we can simplify the debug
message even further.
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211015091129.83226-1-rodrigo.vivi@intel.com
intel_load_plane_csc_black() is specific to icl+ so deserves
a name reflecting that fact. Also rename the variables to
standard form so I won't get confused reading the code.
v2: icl+ not glk+
Cc: Anshuman Gupta <anshuman.gupta@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Juston Li <juston.li@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211006235704.28894-5-ville.syrjala@linux.intel.com
Reviewed-by: Juston Li <juston.li@intel.com>
We are inside the vblank evade critical section here, racing
against the raster beam. There is no time to print debug
messages.
Cc: Anshuman Gupta <anshuman.gupta@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Juston Li <juston.li@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211006235704.28894-4-ville.syrjala@linux.intel.com
Reviewed-by: Juston Li <juston.li@intel.com>
There's lots of expensive stuff inserted between the PLANE_CTL
and PLANE_SURF writes even though the comment before the PLANE_CTL
write says not to put stuff there. Move it all to a more apporiate
place.
There's also a weird PLANE_COLOR_CTL RMW in there. I guess because
force_black was computed way too late originally, but that is now
sorted.
Cc: Anshuman Gupta <anshuman.gupta@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Juston Li <juston.li@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211006235704.28894-3-ville.syrjala@linux.intel.com
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
No real reason to have this pxp state computation in
intel_atomic_check_planes(). Just stuff it into skl_plane_check().
There was also some funny state copying being done from the
old plane state to the new plane state when the plane is anyway
disabled.
The one thing we presumably must remember to do is copy
over the decrypt state when assigning a Y plane for planar
YCbCr scanout, so that the Y plane's PLANE_SURF will get the
appropriate bit set. The force_black thing should not matter
as I'm pretty sure all that stuff is ignored for the Y plane.
I suppose this was the reason for the odd placement for the
state computation, but I see no reason to deviate from the
standard way of doing these things. This also guarantees
that we don't calculate things differently between the
linked UV and Y plane.
v2: Only do stuff for icl+ since 'force_black' depends
on the plane CSC which is an icl+ feature
Cc: Anshuman Gupta <anshuman.gupta@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Juston Li <juston.li@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211006235704.28894-2-ville.syrjala@linux.intel.com
Reviewed-by: Juston Li <juston.li@intel.com> #v1
A new warning in clang points out a place in this file where a bitwise
OR is being used with boolean types:
drivers/gpu/drm/i915/intel_pm.c:3066:12: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical]
changed = ilk_increase_wm_latency(dev_priv, dev_priv->wm.pri_latency, 12) |
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This construct is intentional, as it allows every one of the calls to
ilk_increase_wm_latency() to occur (instead of short circuiting with
logical OR) while still caring about the result of each call.
To make this clearer to the compiler, use the '|=' operator to assign
the result of each ilk_increase_wm_latency() call to changed, which
keeps the meaning of the code the same but makes it obvious that every
one of these calls is expected to happen.
Link: https://github.com/ClangBuiltLinux/linux/issues/1473
Reported-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Suggested-by: Dávid Bolvanský <david.bolvansky@gmail.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211014211916.3550122-1-nathan@kernel.org
During the review I focused on stop the using of the "+"
to reference the newer platforms, but I forgot that we are
in a process of making things more clear and differentiate
graphics and display versions. So, let me to clean up this
a bit. Also, we don't need any version mentioned in the
config menu entry, only in the help.
Cc: Alan Previn <alan.previn.teres.alexis@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211015090916.82968-1-rodrigo.vivi@intel.com
We don't have hpd support on i8xx/i915 which means hotplug_funcs==NULL.
Let's not oops when loading the driver on one those machines.
v2: Drop the redundant function pointer check (Jani)
Cc: Dave Airlie <airlied@redhat.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Fixes: cd030c7c11 ("drm/i915: constify hotplug function vtable.")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211014090941.12159-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
This memory frequency calculated is only used to check if it is zero,
what is not useful as it will never actually be zero.
Also the calculation is wrong, we should be checking other bit to
select the appropriate frequency multiplier while this code is stuck
with a fixed multiplier.
So here dropping it as whole.
v2:
- Also remove memory frequency calculation for gen9 LP platforms
Cc: Yakui Zhao <yakui.zhao@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Fixes: 5d0c938ec9 ("drm/i915/gen11+: Only load DRAM information from pcode")
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211013010046.91858-1-jose.souza@intel.com
DKL_TX_LOADGEN_SHARING_PMD_DISABLE doesn't even seem to exist,
also the spec says to skip all loadgen stuff.
The code was dead anyway since it wasn't actually writing the value
anywhere.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211006204937.30774-6-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
The snb+ pcode mailbox code is not sideband, so split it out to a
separate file. As can be seen from the #include changes, very few places
use both sideband and pcode.
Code movement only.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: 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/185deb18eb739e5ae019e27834b9997dcc1347bc.1634207064.git.jani.nikula@intel.com
For the time being, neither the power sequencer nor the backlight code
properly support two eDP panels simultaneously. While the software
states will be independent, the same sets of registers will be used for
both eDP panels, clobbering the hardware state and leading to errors.
Gracefully disable dual eDP until proper support has been added.
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Swati Sharma <swati2.sharma@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Swati Sharma <swati2.sharma@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211005175636.24669-1-jani.nikula@intel.com
The VLV/CHV sideband code is pretty distinct from the rest of the
sideband code. Split it out to new vlv_sideband.[ch].
Pure code movement with relevant #include changes, and a tiny checkpatch
fix on top.
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/755ebbbaf01fc6d306b763b6ef60f45e671ba290.1634119597.git.jani.nikula@intel.com
Need to resync drm-intel-next with TTM and PXP stuff from
drm-intel-gt-next that is now in drm/drm-next.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
The 128b/132b channel coding link training uses more straightforward TX
FFE preset values. Reuse voltage tries and max vswing for retry logic.
The delays for 128b/132b are still all wrong, but this is regardless a
step forward.
v2: Fix UHBR rate checks, use intel_dp_is_uhbr() helper
v3:
- Rebase
- Modify intel_dp_adjust_request_changed() and
intel_dp_link_max_vswing_reached() to take 128b/132b into
account. (Ville)
v4:
- Train request printing for TX FFE (Ville)
- Log 8b/10b vs. 128b/132b (Ville)
- Add helper for per-lane max vswing / tx ffe (Ville)
- Name functions with tx_ffe/vswing instead of 128b132b/8b10b
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211011182144.22074-2-jani.nikula@intel.com
Add per-lane abstraction for max vswing reached to make follow-up
cleaner, as this one reverses the conditions.
v2: both conditions need to be true, reverse (Ville)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211011182144.22074-1-jani.nikula@intel.com
UAPI Changes:
- Add uAPI for using PXP protected objects
Mesa changes: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8064
- Add PCI IDs and LMEM discovery/placement uAPI for DG1
Mesa changes: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11584
- Disable engine bonding on Gen12+ except TGL, RKL and ADL-S
Cross-subsystem Changes:
- Merges 'tip/locking/wwmutex' branch (core kernel tip)
- "mei: pxp: export pavp client to me client bus"
Core Changes:
- Update ttm_move_memcpy for async use (Thomas)
Driver Changes:
- Enable GuC submission by default on DG1 (Matt B)
- Add PXP (Protected Xe Path) support for Gen12 integrated (Daniele,
Sean, Anshuman)
See "drm/i915/pxp: add PXP documentation" for details!
- Remove force_probe protection for ADL-S (Raviteja)
- Add base support for XeHP/XeHP SDV (Matt R, Stuart, Lucas)
- Handle DRI_PRIME=1 on Intel igfx + Intel dgfx hybrid graphics setup (Tvrtko)
- Use Transparent Hugepages when IOMMU is enabled (Tvrtko, Chris)
- Implement LMEM backup and restore for suspend / resume (Thomas)
- Report INSTDONE_GEOM values in error state for DG2 (Matt R)
- Add DG2-specific shadow register table (Matt R)
- Update Gen11/Gen12/XeHP shadow register tables (Matt R)
- Maintain backward-compatible nested batch behavior on TGL+ (Matt R)
- Add new LRI reg offsets for DG2 (Akeem)
- Initialize unused MOCS entries to device specific values (Ayaz)
- Track and use the correct UC MOCS index on Gen12 (Ayaz)
- Add separate MOCS table for Gen12 devices other than TGL/RKL (Ayaz)
- Simplify the locking and eliminate some RCU usage (Daniel)
- Add some flushing for the 64K GTT path (Matt A)
- Mark GPU wedging on driver unregister unrecoverable (Janusz)
- Major rework in the GuC codebase, simplify locking and add docs (Matt B)
- Add DG1 GuC/HuC firmwares (Daniele, Matt B)
- Remember to call i915_sw_fence_fini on guc_state.blocked (Matt A)
- Use "gt" forcewake domain name for error messages instead of "blitter" (Matt R)
- Drop now duplicate LMEM uAPI RFC kerneldoc section (Daniel)
- Fix early tracepoints for requests (Matt A)
- Use locked access to ctx->engines in set_priority (Daniel)
- Convert gen6/gen7/gen8 read operations to fwtable (Matt R)
- Drop gen11/gen12 specific mmio write handlers (Matt R)
- Drop gen11 specific mmio read handlers (Matt R)
- Use designated initializers for init/exit table (Kees)
- Fix syncmap memory leak (Matt B)
- Add pretty printing for buddy allocator state debug (Matt A)
- Fix potential error pointer dereference in pinned_context() (Dan)
- Remove IS_ACTIVE macro (Lucas)
- Static code checker fixes (Nathan)
- Clean up disabled warnings (Nathan)
- Increase timeout in i915_gem_contexts selftests 5x for GuC submission (Matt B)
- Ensure wa_init_finish() is called for ctx workaround list (Matt R)
- Initialize L3CC table in mocs init (Sreedhar, Ayaz, Ram)
- Get PM ref before accessing HW register (Vinay)
- Move __i915_gem_free_object to ttm_bo_destroy (Maarten)
- Deduplicate frequency dump on debugfs (Lucas)
- Make wa list per-gt (Venkata)
- Do not define dummy vma in stack (Venkata)
- Take pinning into account in __i915_gem_object_is_lmem (Matt B, Thomas)
- Do not report currently active engine when describing objects (Tvrtko)
- Fix pdfdocs build error by removing nested grid from GuC docs (Akira)
- Remove false warning from the rps worker (Tejas)
- Flush buffer pools on driver remove (Janusz)
- Fix runtime pm handling in i915_gem_shrink (Maarten)
- Rework TTM object initialization slightly (Thomas)
- Use fixed offset for PTEs location (Michal Wa)
- Verify result from CTB (de)register action and improve error messages (Michal Wa)
- Fix bug in user proto-context creation that leaked contexts (Matt B)
- Re-use Gen11 forcewake read functions on Gen12 (Matt R)
- Make shadow tables range-based (Matt R)
- Ditch the i915_gem_ww_ctx loop member (Thomas, Maarten)
- Use NULL instead of 0 where appropriate (Ville)
- Rename pci/debugfs functions to respect file prefix (Jani, Lucas)
- Drop guc_communication_enabled (Daniele)
- Selftest fixes (Thomas, Daniel, Matt A, Maarten)
- Clean up inconsistent indenting (Colin)
- Use direction definition DMA_BIDIRECTIONAL instead of
PCI_DMA_BIDIRECTIONAL (Cai)
- Add "intel_" as prefix in set_mocs_index() (Ayaz)
From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/YWAO80MB2eyToYoy@jlahtine-mobl.ger.corp.intel.com
Signed-off-by: Dave Airlie <airlied@redhat.com>
- fbdev/efifb: Release PCI device's runtime PM ref during FB destr\
oy (Imre)
i915 Core Driver Changes:
- Only access SFC_DONE in media when not fused off for graphics 12 and newer.
- Double Memory latency values from pcode for DG2 (Matt Roper)
- ADL-S PCI ID update (Tejas)
- New DG1 PCI ID (Jose)
- Fix regression with uncore refactoring (Dave)
i915 Display Changes:
- ADL-P display (XE_LPD) fixes and updates (Ankit, Jani, Matt Roper, Anusham, Jose, Imre, Vandita)
- DG2 display fixes (Ankit, Jani)
- Expand PCH_CNP tweaked display workaround to all newer displays (Anshuman)
- General display simplifications and clean-ups (Jani, Swati, Jose, Ville)
- PSR Clean-ups, dropping support for BDW/HSD and enable PSR2 selective fetch by default (Jose, Gwan-gyeong)
- Nuke ORIGIN_GTT (Jose)
- Return proper DPRX link training result (Lee)
- FBC related refactor and fixes (Ville)
- Yet another attempt to solve the fast+narrow vs slow+wide eDP link training (Kai-Heng)
- DP 2.0 preparation work (Jani)
- Silence __iomem sparse warn (Ville)
- Clean up DPLL stuff (Ville)
- Fix various dp/edp max rates (Matt Atwood, Animesh, Jani)
- Remove VBT ddi_port_info caching (Jani)
- DSI driver improvements (Lee)
- HDCP fixes (Juston)
- Associate ACPI connector nodes with connector entries (Heikki)
- Add support for out-of-bound hotplug events (Hans)
- VESA vendor block and drm/i915 MSO use of it (Jani)
- Fixes for bigjoiner (Ville)
- Update memory bandwidth parameters (RK)
- DMC related fixes (Chris, Jose)
- HDR related fixes and improvements (Tejas)
- g4x/vlv/chv CxSR/wm fixes/cleanups (Ville)
- Use BIOS provided value for RKL Audio's HDA link (Kai-Heng)
- Fix the dsc check while selecting min_cdclk (Vandita)
- Split and constify vtable (Dave)
- Add ww context to intel_dpt_pin (Maarten)
- Fix bdb version check (Lukasz)
- DP per-lane drive settings prep work and other DP fixes (Ville)
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEEbSBwaO7dZQkcLOKj+mJfZA7rE8oFAmFbTsgACgkQ+mJfZA7r
E8onwQf/QLOtlY0Al7oVEQrWu7I6vzajyQz6oGbj3rTNMG6m/sDNCgKZaNmxRnQo
O+YjccMW/dnsFhSqckm8JzQUrHPSmDExBu+HGSkxNTod7UYVEEd0MYETnBShF4hv
vwoPgRuzny5+jEDuBv9GBD/6d2su9Hl/OWTQ/YPjdJKyIWLjKhbxET7FExlV6MtG
I80OyJSaV2L4EAgPT5TBSAXvzeUFAevw2O9aOSI+rTtAOfXI7TkB7E38Tjzc7uSd
YN9/43NXoJYVB9yhVXKJgK90COMSREFv/lUupSXqN/W5lOD4xLg0W6vD6kKX5Z4T
IrfvR6T5Cz+OfwSLUlzmWeO+l9VcqQ==
=9tCx
-----END PGP SIGNATURE-----
Merge tag 'drm-intel-next-2021-10-04' of git://anongit.freedesktop.org/drm/drm-intel into drm-next
Cross-subsystem Changes:
- fbdev/efifb: Release PCI device's runtime PM ref during FB destr\
oy (Imre)
i915 Core Driver Changes:
- Only access SFC_DONE in media when not fused off for graphics 12 and newer.
- Double Memory latency values from pcode for DG2 (Matt Roper)
- ADL-S PCI ID update (Tejas)
- New DG1 PCI ID (Jose)
- Fix regression with uncore refactoring (Dave)
i915 Display Changes:
- ADL-P display (XE_LPD) fixes and updates (Ankit, Jani, Matt Roper, Anusham, Jose, Imre, Vandita)
- DG2 display fixes (Ankit, Jani)
- Expand PCH_CNP tweaked display workaround to all newer displays (Anshuman)
- General display simplifications and clean-ups (Jani, Swati, Jose, Ville)
- PSR Clean-ups, dropping support for BDW/HSD and enable PSR2 selective fetch by default (Jose, Gwan-gyeong)
- Nuke ORIGIN_GTT (Jose)
- Return proper DPRX link training result (Lee)
- FBC related refactor and fixes (Ville)
- Yet another attempt to solve the fast+narrow vs slow+wide eDP link training (Kai-Heng)
- DP 2.0 preparation work (Jani)
- Silence __iomem sparse warn (Ville)
- Clean up DPLL stuff (Ville)
- Fix various dp/edp max rates (Matt Atwood, Animesh, Jani)
- Remove VBT ddi_port_info caching (Jani)
- DSI driver improvements (Lee)
- HDCP fixes (Juston)
- Associate ACPI connector nodes with connector entries (Heikki)
- Add support for out-of-bound hotplug events (Hans)
- VESA vendor block and drm/i915 MSO use of it (Jani)
- Fixes for bigjoiner (Ville)
- Update memory bandwidth parameters (RK)
- DMC related fixes (Chris, Jose)
- HDR related fixes and improvements (Tejas)
- g4x/vlv/chv CxSR/wm fixes/cleanups (Ville)
- Use BIOS provided value for RKL Audio's HDA link (Kai-Heng)
- Fix the dsc check while selecting min_cdclk (Vandita)
- Split and constify vtable (Dave)
- Add ww context to intel_dpt_pin (Maarten)
- Fix bdb version check (Lukasz)
- DP per-lane drive settings prep work and other DP fixes (Ville)
Signed-off-by: Dave Airlie <airlied@redhat.com>
# gpg: Signature made Tue 05 Oct 2021 04:58:16 AEST
# gpg: using RSA key 6D207068EEDD65091C2CE2A3FA625F640EEB13CA
# gpg: Good signature from "Rodrigo Vivi <rodrigo.vivi@intel.com>" [unknown]
# gpg: aka "Rodrigo Vivi <rodrigo.vivi@gmail.com>" [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 6D20 7068 EEDD 6509 1C2C E2A3 FA62 5F64 0EEB 13CA
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/YVtPk6llsxBFiw7W@intel.com
UAPI Changes:
- Allow empty drm leases for creating separate GEM namespaces.
Cross-subsystem Changes:
- Slightly rework dma_buf_poll.
- Add dma_resv_for_each_fence_unlocked to iterate, and use it inside
the lockless dma-resv functions.
Core Changes:
- Allow devm_drm_of_get_bridge to build without CONFIG_OF for compile testing.
- Add more DP2 headers.
- fix CONFIG_FB dependency in fb_helper.
- Add DRM_FORMAT_R8 to drm_format_info, and helpers for RGB332 and RGB888.
- Fix crash on a 0 or invalid EDID.
Driver Changes:
- Apply and revert DRM_MODESET_LOCK_ALL_BEGIN.
- Add mode_valid to ti-sn65dsi86 bridge.
- Support multiple syncobjs in v3d.
- Add R8, RGB332 and RGB888 pixel formats to GUD.
- Use devm_add_action_or_reset in dw-hdmi-cec.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEuXvWqAysSYEJGuVH/lWMcqZwE8MFAmFdfuwACgkQ/lWMcqZw
E8OTgg/+Nmsqhj1tsbSCWF1yx81CXHVSOhExPaMl+GPs6+y+sZ+U2rN99dnbULvA
U56eOmjc8FvgmK89BwhSYNt++QYIRRpzjBGlCYm4bwpgqFOmYsK+en35PYMwHdxM
Ke8newhzqa6/detvjX52igddZzrBv1Cs8aXuV5rw7Dg0ivlSlQUV0MO8JYwCliWI
arRT8bg7wzUzhyRZqwqOqKXjvRirqBlFjJmvfL0WgHevZbzYuXbn4eWCUgCVthMH
pU9QgK6FMW912pBxVppDO2aTDmNvqwj1BsB3RFfRuqS/JJ4s/gf39JxsipnI+/qn
kPxZVFzzonR8Nl6h9sPi1jZrcVDCBebFgyG8hSgIVb/09U7AVYomtP18VKeh8yCy
Pp4iQINqOcyMPmXKF491LIL92dcXZAIRaRQFKc/ZSHcfIDA7ZB1+7zf1ixBjlxjP
GqtjLbmPspI2DzBRlTFEdf58jvX70E5nFYdQyYcy3VprJHuqEgL5PKz2Xcnve6R0
dEkGA2vMrGtb23YyjbFTNfkdvg9WYXze9HbQLt7kc8mI77TugkG0/rCcwv5pEEu3
WSwqMeb+5H+7va4AI715MoXbxgnCba2zPTUm1s8kSqTK0Oighc/vWcnnJ4iVuEGE
8Xt8AIIYUtccufR6ujucVUh7nju2ZOnFE7S92LybnGnByAIADfM=
=qxpr
-----END PGP SIGNATURE-----
Merge tag 'drm-misc-next-2021-10-06' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
drm-misc-next for v5.16:
UAPI Changes:
- Allow empty drm leases for creating separate GEM namespaces.
Cross-subsystem Changes:
- Slightly rework dma_buf_poll.
- Add dma_resv_for_each_fence_unlocked to iterate, and use it inside
the lockless dma-resv functions.
Core Changes:
- Allow devm_drm_of_get_bridge to build without CONFIG_OF for compile testing.
- Add more DP2 headers.
- fix CONFIG_FB dependency in fb_helper.
- Add DRM_FORMAT_R8 to drm_format_info, and helpers for RGB332 and RGB888.
- Fix crash on a 0 or invalid EDID.
Driver Changes:
- Apply and revert DRM_MODESET_LOCK_ALL_BEGIN.
- Add mode_valid to ti-sn65dsi86 bridge.
- Support multiple syncobjs in v3d.
- Add R8, RGB332 and RGB888 pixel formats to GUD.
- Use devm_add_action_or_reset in dw-hdmi-cec.
Signed-off-by: Dave Airlie <airlied@redhat.com>
# gpg: Signature made Wed 06 Oct 2021 20:48:12 AEST
# gpg: using RSA key B97BD6A80CAC4981091AE547FE558C72A67013C3
# gpg: Good signature from "Maarten Lankhorst <maarten.lankhorst@linux.intel.com>" [expired]
# gpg: aka "Maarten Lankhorst <maarten@debian.org>" [expired]
# gpg: aka "Maarten Lankhorst <maarten.lankhorst@canonical.com>" [expired]
# gpg: Note: This key has expired!
# Primary key fingerprint: B97B D6A8 0CAC 4981 091A E547 FE55 8C72 A670 13C3
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/2602f4e9-a8ac-83f8-6c2a-39fd9ca2e1ba@linux.intel.com
Add a function for checking source MST support. Drop intel_dp->can_mst
and use intel_dp->mst_mgr.cbs to indicate the same. It's the single
point of truth without additional state variables. In code, "source
support" is also self-documenting as opposed to the vague "can mst".
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211006101618.22066-1-jani.nikula@intel.com
Limit the supported UHBR rates based on the repeater support, if there
are repeaters.
This should be done in DP helper level, but that requires an overhaul of
the LTTPR handling, as the max rate is not enough to represent how
128b/132b rates may be masked along the way.
Curiously, the spec says:
* Shall be cleared to 00h when operating in 8b/10b Link Layer.
* Each LTTPR on the way back to the DPTX shall clear the bits that do
not correspond to the LTTPR's current bit rate.
It's rather vague if we can reliably use the field at this time due to
the wording "operating" and "current". But it would seem bizarre to have
to wait until trying to operate a 128b/132b link layer at a certain bit
rate to figure this out.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211007105727.18439-1-jani.nikula@intel.com
When trying to bring IS_ACTIVE to linux/kconfig.h I thought it wouldn't
provide much value just encapsulating it in a boolean context. So I also
added the support for handling undefined macros as the IS_ENABLED()
counterpart. However the feedback received from Masahiro Yamada was that
it is too ugly, not providing much value. And just wrapping in a boolean
context is too dumb - we could simply open code it.
As detailed in commit babaab2f47 ("drm/i915: Encapsulate kconfig
constant values inside boolean predicates"), the IS_ACTIVE macro was
added to workaround a compilation warning. However after checking again
our current uses of IS_ACTIVE it turned out there is only
1 case in which it triggers a warning in clang (due
-Wconstant-logical-operand) and 2 in smatch. All the others
can simply use the shorter version, without wrapping it in any macro.
So here I'm dialing all the way back to simply removing the macro. That
single case hit by clang can be changed to make the constant come first,
so it doesn't think it's mask:
- if (context && CONFIG_DRM_I915_FENCE_TIMEOUT)
+ if (CONFIG_DRM_I915_FENCE_TIMEOUT && context)
As talked with Dan Carpenter, that logic will be added in smatch as
well, so it will also stop warning about it.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Masahiro Yamada <masahiroy@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20211005171728.3147094-1-lucas.demarchi@intel.com
The UHBR check was using > instead of >=. Use the helper instead to
avoid mistakes. Also always use the non-UHBR values for HDMI.
v2: Use intel_crtc_has_dp_encoder() && intel_dp_is_uhbr() (Ville)
Fixes: 2817efaeb6 ("drm/i915/dg2: add SNPS PHY translations for UHBR link rates")
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211007124201.18686-1-jani.nikula@intel.com
As per the comment on top of acpi_evaluate_dsm():
| * Evaluate device's _DSM method with specified GUID, revision id and
| * function number. Caller needs to free the returned object.
We should free the returned object of acpi_evaluate_dsm() to avoid memory
leakage. Otherwise the kmemleak splat will be triggered at boot time (if we
compile kernel with CONFIG_DEBUG_TEST_DRIVER_REMOVE=y).
Fixes: 8e55f99c51 ("drm/i915: Invoke another _DSM to enable MUX on HP Workstation laptops")
Cc: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210906033541.862-1-yuzenghui@huawei.com
I suppose intel_dp_dump_link_status() might be useful for diagnosing
link training failures. Hoever we only call from the channel EQ phase
currently. Let's call it from the CR phase as well.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211004170535.4173-6-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
Unify all debug prints during link training to include information
on both the encoder and the LTTPR. We unify the format to something
like "[ENCODER:1:FOO][LTTPR 1] Something something". Though not
sure if those brackets around the dp_phy just make it look like
line noise? I'll accept suggestions on better formatting.
I'm slightly on the fence about also including the connector,
but technically only the DPRX is the SST connector (ie.
intel_dp->attached_connector). I suppose you could think of it
as the branch device/whatever in the topology, and we're training
the link leading to it. So that could argue for its inclusion.
But it's all getting a bit long alrady, so not going to do it
I think.
v2: Keep the connector name in the final passed/failed debug print
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211004170535.4173-5-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
Currently we consider the max vswing reached when we transmit a
the max voltage level, but we don't consider pre-emphasis at all.
This kinda matches older DP specs that only had some vague text
about transmitting the maximum voltage swing. Latest versions
now say something vague about consider the sum of the vswing
and pre-emphasis fields in the ADJUST_REQUEST_LANE registers.
Very vague, and super confusing especially the fact that it
talks about transmitted voltgage swing in the same sentence
as it say to look at the requested values.
Also glanced at the link CTS spec, and that one seems to have
tests that assume contradicting behaviour. Some say to consider
just the vswing level we transmit, others say to check for
sum of transmitted vswing+preemph being 3.
So let's try to take some kind of sane middle ground here.
I think what could make sense is only consider max vswing
reached if MAX_SWING_REACHED==1 _and_ vswing+preemph==3.
That will allow things to go all the way up to vswing 3 +
pre-emph 0 or vswing 2 + pre-emph 1, depending on what
the maximum supported vswing is. Only considering the sum
of vswing+pre-emph doesn't make much sense to me since
we could terminate too early if the sink requests eg.
vswing 0 + pre-emph 3. And if we'd stick to the current
code we could terminate too early of the sink asks for
vswing 2 + pre-emph 0 when vswing level 3 is not supported.
Side note: I don't really understand why any of this stuff is
"specified" at all. There is already a limit of 5 attempts at
the same vswing+pre-emph level, and a total limit of 10
attempts. So might as well stick to the same max 5 attempts
across the board IMO.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211004170535.4173-2-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
In short this makes i915 work for hybrid setups (DRI_PRIME=1 with Mesa)
when rendering is done on Intel dgfx and scanout/composition on Intel
igfx.
Before this patch the driver was not quite ready for that setup, mainly
because it was able to emit a semaphore wait between the two GPUs, which
results in deadlocks because semaphore target location in HWSP is neither
shared between the two, nor mapped in both GGTT spaces.
To fix it the patch adds an additional check to a couple of relevant code
paths in order to prevent using semaphores for inter-engine
synchronisation when relevant objects are not in the same GGTT space.
v2:
* Avoid adding rq->i915. (Chris)
v3:
* Use GGTT which describes the limit more precisely.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211005113135.768295-1-tvrtko.ursulin@linux.intel.com
The "digi_port" pointer can't be NULL and we have already dereferenced
it so checking for NULL is not necessary. Delete the check.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211004103737.GC25015@kili
Set number of engines before attempting to create contexts so the
function free_engines can clean up properly. Also check return of
alloc_engines for NULL.
v2:
(Tvrtko)
- Send as stand alone patch
(John Harrison)
- Check for alloc_engines returning NULL
v3:
(Checkpatch / Tvrtko)
- Remove braces around single line if statement
Cc: Jason Ekstrand <jason@jlekstrand.net>
Fixes: d4433c7600 ("drm/i915/gem: Use the proto-context to handle create parameters (v5)")
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211001155825.6762-1-matthew.brost@intel.com
Since the VT-d vs. async flip issues are plaguing a wider range
of supported hw let's try to minimize the impact on normal
operation by flipping the relevant chicken bits on and off
as needed. I presume there is some power/perf impact on since
this is reducing some prefetching I think.
Cc: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210930190943.17547-2-ville.syrjala@linux.intel.com
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Looks like skl/bxt/derivatives also need the plane stride
stretch w/a when using async flips and VT-d is enabled, or
else we get corruption on screen. To my surprise this was
even documented in bspec, but only as a note on the
CHICHKEN_PIPESL register description rather than on the
w/a list.
So very much the same thing as on HSW/BDW, except the bits
moved yet again.
Cc: stable@vger.kernel.org
Cc: Karthik B S <karthik.b.s@intel.com>
Fixes: 55ea1cb178 ("drm/i915: Enable async flips in i915")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210930190943.17547-1-ville.syrjala@linux.intel.com
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
