For cached objects we can allocate our pages directly in shmem. This
should make it possible(in a later patch) to utilise the existing
i915-gem shrinker code for such objects. For now this is still disabled.
v2(Thomas):
- Add optional try_to_writeback hook for objects. Importantly we need
to check if the object is even still shrinkable; in between us
dropping the shrinker LRU lock and acquiring the object lock it could for
example have been moved. Also we need to differentiate between
"lazy" shrinking and the immediate writeback mode. Also later we need to
handle objects which don't even have mm.pages, so bundling this into
put_pages() would require somehow handling that edge case, hence
just letting the ttm backend handle everything in try_to_writeback
doesn't seem too bad.
v3(Thomas):
- Likely a bad idea to touch the object from the unpopulate hook,
since it's not possible to hold a reference, without also creating
circular dependency, so likely this is too fragile. For now just
ensure we at least mark the pages as dirty/accessed when called from the
shrinker on WILLNEED objects.
- s/try_to_writeback/shrinker_release_pages, since this can do more
than just writeback.
- Get rid of do_backup boolean and just set the SWAPPED flag prior to
calling unpopulate.
- Keep shmem_tt as lowest priority for the TTM LRU bo_swapout walk, since
these just get skipped anyway. We can try to come up with something
better later.
v4(Thomas):
- s/PCI_DMA/DMA/. Also drop NO_KERNEL_MAPPING and NO_WARN, which
apparently doesn't do anything with streaming mappings.
- Just pass along the error for ->truncate, and assume nothing.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Oak Zeng <oak.zeng@intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Acked-by: Oak Zeng <oak.zeng@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211018091055.1998191-2-matthew.auld@intel.com
Break out some shmem backend utils for future reuse by the TTM backend:
shmem_alloc_st(), shmem_free_st() and __shmem_writeback() which we can
use to provide a shmem-backed TTM page pool for cached-only TTM
buffer objects.
Main functional change here is that we now compute the page sizes using
the dma segments rather than using the physical page address segments.
v2(Reported-by: kernel test robot <lkp@intel.com>)
- Make sure we initialise the mapping on the error path in
shmem_get_pages()
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211018091055.1998191-1-matthew.auld@intel.com
UAPI Changes:
- Expose multi-LRC submission interface
Similar to the bonded submission interface but simplified.
Comes with GuC only implementation for now. See kerneldoc
for more details.
Userspace changes: https://github.com/intel/media-driver/pull/1252
- Expose logical engine instance to user
Needed by the multi-LRC submission interface for GuC
Userspace changes: https://github.com/intel/media-driver/pull/1252
Driver Changes:
- Fix blank screen booting crashes when CONFIG_CC_OPTIMIZE_FOR_SIZE=y (Hugh)
- Add support for multi-LRC submission in the GuC backend (Matt B)
- Add extra cache flushing before making pages userspace visible (Matt A, Thomas)
- Mark internal GPU object pages dirty so they will be flushed properly (Matt A)
- Move remaining debugfs interfaces i915_wedged/i915_forcewake_user into gt (Andi)
- Replace the unconditional clflushes with drm_clflush_virt_range() (Ville)
- Remove IS_ACTIVE macro completely (Lucas)
- Improve kerneldocs for cache_dirty (Matt A)
- Add missing includes (Lucas)
- Selftest improvements (Matt R, Ran, Matt A)
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/YXFmLKoq8Fg9JxSd@jlahtine-mobl.ger.corp.intel.com
Future platforms change the location of CCS AUX planes in CCS
framebuffers, so add intel_fb_is_ccs_aux_plane() to query for these
planes independently of the platform. This function can be used
everywhere instead of is_ccs_plane() (or is_ccs_plane() && !cc_plane()),
since all the callers are only interested in CCS AUX planes (and not CCS
color-clear planes).
Add the corresponding intel_fb_is_gen12_ccs_aux_plane(), which can be
used everywhere instead of is_gen12_ccs_plane(), based on the above
explanation.
This change also unexports the is_gen12_ccs_modifier(),
is_gen12_ccs_plane(), is_gen12_ccs_cc_plane() functions as they are only
used in intel_fb.c
v1-v2: Unchanged
v3: (Ville)
- Use ccs_aux instead of the ccs_ctrl term everywhere.
- Use color_plane instead of plane term for FB plane indicies.
v4: Fix version range check. (Jani)
Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211020195138.1841242-10-imre.deak@intel.com
Move the function retrieving the format override information for a given
format/modifier to intel_fb.c. We can store a pointer to the format list
in each modifier's descriptor instead of the corresponding switch/case
logic, avoiding the listing of the modifiers twice.
v1: Unchanged.
v2: Handle invalid modifiers in intel_fb_get_format_info() passed from
userspace. (CI/igt_kms_addfb_basic/addfb25-bad-modifier)
v3: Move lookup_modifier() to the next patch, where it's first used.
Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211020195138.1841242-3-imre.deak@intel.com
Add a table describing all the framebuffer modifiers used by i915 at one
place. This has the benefit of deduplicating the listing of supported
modifiers for each platform and checking the support of these modifiers
on a given plane. This also simplifies in a similar way getting some
attribute for a modifier, for instance checking if the modifier is a
CCS modifier type.
While at it drop the cursor plane filtering from skl_plane_has_rc_ccs(),
as the cursor plane is registered with DRM core elsewhere.
v1: Unchanged.
v2:
- Keep the plane caps calculation in the plane code and pass an enum
with these caps to intel_fb_get_modifiers(). (Ville)
- Get the modifiers calling intel_fb_get_modifiers() in i9xx_plane.c as
well.
v3:
- s/.id/.modifier/ (Ville)
- Keep modifier_desc vs. plane_cap filter conditions consistent. (Ville)
- Drop redundant cursor plane check from skl_plane_has_rc_ccs(). (Ville)
- Use from, until display version fields in modifier_desc instead of a mask. (Jani)
- Unexport struct intel_modifier_desc, separate its decl and init. (Jani)
- Remove enum pipe, plane_id forward decls from intel_fb.h, which are
not needed after v2.
v4:
- Reuse IS_DISPLAY_VER() instead of open-coding it. (Jani)
- Preserve the current modifier order exposed to user space. (Ville)
v5: Use }, { on one line to seperate the descriptor array elements. (Jani)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> (v3)
Link: https://patchwork.freedesktop.org/patch/msgid/20211020195138.1841242-2-imre.deak@intel.com
While the pages can't be swapped out, they can be discarded by the shrinker.
Normally such objects are marked with __I915_MADV_PURGED, which can't be
unset, and therefore requires a new object. For kernel internal objects
this is not true, since the madv hint is reset for our special volatile
objects, such that we can re-acquire new pages, if so desired, without
needing a new object. As a result we should probably be paranoid here
and put the object back into the CPU domain when discarding the pages,
and also correctly set cache_dirty, if required.
Signed-off-by: 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/20211018174508.2137279-8-matthew.auld@intel.com
If the DPCD sink rate values read from the sink are invalid, the
driver will sanitize this in intel_dp_set_common_rates(), by setting a
default 162000 link rate in common rates and printing a WARN().
WARN()s should only be triggered by bugs in the code and not by external
factors like the above (an invalid DPCD injected maliciously or read from a
buggy monitor). So fixup the invalid DPCD sink rate values already and print
an error in this case (since it's still a user visible problem).
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211018094154.1407705-6-imre.deak@intel.com
Atm until the DPCD for a connector is read the max link rate and lane
count params are invalid. If the connector is modeset, in
intel_dp_compute_config(), intel_dp_common_len_rate_limit(max_link_rate)
will return 0, leading to a intel_dp->common_rates[-1] access.
Fix the above by making sure the max link params are always valid.
The above access leads to an undefined behaviour by definition, though
not causing a user visible problem to my best knowledge, see the previous
patch why. Nevertheless it is an undefined behaviour and it triggers a
BUG() in CONFIG_UBSAN builds, hence CC:stable.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211018094154.1407705-4-imre.deak@intel.com
Atm, there are no sink rate values set for DP (vs. eDP) sinks until the
DPCD capabilities are successfully read from the sink. During this time
intel_dp->num_common_rates is 0 which can lead to a
intel_dp->common_rates[-1] (*)
access, which is an undefined behaviour, in the following cases:
- In intel_dp_sync_state(), if the encoder is enabled without a sink
connected to the encoder's connector (BIOS enabled a monitor, but the
user unplugged the monitor until the driver loaded).
- In intel_dp_sync_state() if the encoder is enabled with a sink
connected, but for some reason the DPCD read has failed.
- In intel_dp_compute_link_config() if modesetting a connector without
a sink connected on it.
- In intel_dp_compute_link_config() if modesetting a connector with a
a sink connected on it, but before probing the connector first.
To avoid the (*) access in all the above cases, make sure that the sink
rate table - and hence the common rate table - is always valid, by
setting a default minimum sink rate when registering the connector
before anything could use it.
I also considered setting all the DP link rates by default, so that
modesetting with higher resolution modes also succeeds in the last two
cases above. However in case a sink is not connected that would stop
working after the first modeset, due to the LT fallback logic. So this
would need more work, beyond the scope of this fix.
As I mentioned in the previous patch, I don't think the issue this patch
fixes is user visible, however it is an undefined behaviour by
definition and triggers a BUG() in CONFIG_UBSAN builds, hence CC:stable.
v2: Clear the default sink rates, before initializing these for eDP.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4297
References: https://gitlab.freedesktop.org/drm/intel/-/issues/4298
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211018143417.1452632-1-imre.deak@intel.com
Reading out the DP encoders' DPCD during booting or resume is only
required for enabled encoders: such encoders may be modesetted during
the initial commit and the link training this involves depends on an
initialized DPCD. For DDI encoders reading out the DPCD is skipped, do
the same on pre-DDI platforms.
Atm, the first DPCD readout without a sink connected - which is a likely
scneario if the encoder is disabled - leaves intel_dp->num_common_rates
at 0, which resulted in
intel_dp_sync_state()->intel_dp_max_common_rate()
in a
intel_dp->common_rates[-1]
access. This by definition results in an undefined behaviour, though to
my best knowledge in all HW/compiler configurations it actually results
in accessing the array item type value preceding the array. In this
case the preceding value happens to be intel_dp->num_common_rates,
which is 0, so this issue - by luck - didn't cause a user visible
problem.
Nevertheless it's still an undefined behaviour and in CONFIG_UBSAN
builds leads to a kernel BUG() (which revealed this problem for us),
hence CC:stable.
A related problem in case the encoder is enabled but the sink is not
connected or the DPCD readout fails is fixed by the next patch.
v2: Amend the commit message describing the root cause of the
CONFIG_UBSAN BUG().
Fixes: a532cde31d ("drm/i915/tc: Fix TypeC port init/resume time sanitization")
References: https://gitlab.freedesktop.org/drm/intel/-/issues/4297
Reported-and-tested-by: Mat Jonczyk <mat.jonczyk@o2.pl>
Cc: Mat Jonczyk <mat.jonczyk@o2.pl>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211018094154.1407705-2-imre.deak@intel.com
Reanme intel_ddi_fdi_post_disable() to hsw_fdi_disable() and
relocate it next to all the other code dealing with FDI_RX.
intel_ddi.c has now been cleansed of FDI_RX.
In order to avoid exposing intel_disable_ddi_buf() outside
intel_ddi.c we can just open code the DDI_BUF_CTL write. The
enable side already has all that stuff open coded so
this actually is more symmetric. But we do need to remeber
to bring the intel_wait_ddi_buf_idle() call over from
inside intel_disable_ddi_buf().
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-9-ville.syrjala@linux.intel.com
Reviewed-by: Dave Airlie <airlied@redhat.com>
