Add a wrapper around intel_step_name that takes in driver data as an
argument. This wrapper will help maintain compatibility with the
proposed xe driver.
Ville Syrjälä [Mon, 9 Oct 2023 14:58:28 +0000 (17:58 +0300)]
drm/i915: Fix VLV color state readout
VLV was missed when the color.get_config() hook was added.
Remedy that.
Not really sure what the final plan here was since a bunch of
color related readout was left in intel_display.c anyway,
but that's for anothr day to figure out...
Remove redundant intel_connector NULL check. Having it here just
creates further confusion and also the variable already gets
dereferenced before the aforementioned NULL check
Ville Syrjälä [Wed, 4 Oct 2023 15:56:03 +0000 (18:56 +0300)]
drm/i915: Simplify snps/c10x DPLL state checker calling convetion
Passing in the atomic state + crtc state is a bit weird. The latter
can be just the crtc (which is the normal calling convention used
in a lot of other places).
Ville Syrjälä [Thu, 5 Oct 2023 12:27:13 +0000 (15:27 +0300)]
drm/i915: Simplify watermark state checker calling convention
There is never any reason to pass in both the crtc and its state
as one can always dig out the crtc from its state. But for more
consistency across the whole state checker let's just pass the
overall atomic state+crtc here as well.
Ville Syrjälä [Wed, 4 Oct 2023 15:55:57 +0000 (18:55 +0300)]
drm/i915: Stop clobbering old crtc state during state check
The state checker overwrites the old crtc state with the
current hardware state. While that does save a kmalloc() it seems
rather dubious as there might still be something that we need
in the old crtc state.
Stop doing that and just allocate a temporary state for the state
checker. Should the extra malloc during the commit phase turn out
too annoying we could of course preallocate one for each crtc, but
let's proceed with the straightforward approch for now.
And while at it let's mark the new crtc state as const to make
sure the state checker doesn't mess it up.
Ville Syrjälä [Wed, 4 Oct 2023 15:55:56 +0000 (18:55 +0300)]
drm/i915/psr: Unify PSR pre/post plane update hooks
intel_psr_pre_plane_update() operates on a per-crtc level, whereas
intel_psr_post_plane_update() operates on the whole atomic commit,
for no real reason that I can see. Adjust intel_psr_post_plane_update()
to match the intel_psr_pre_plane_update() approach.
Ville Syrjälä [Tue, 3 Oct 2023 19:42:51 +0000 (22:42 +0300)]
drm/i915/fbc: Remove ancient 16k plane stride limit
The 16k max plane stride limit seems to be originally from
i965gm, and no explicit limit has been specified since (g4x+).
So let's assume the max plane stride itself is a suitable limit
also for the more recent FBC hardware.
In fact even for i965gm the max X-tiled stride is also 16k so
technically we don't need the check there either, but let's
keep it there anyway since it's explicitly mentioned in the
spec. Gen2/3 have more strict limits checked separately.
drm/i915/pmu: Use local64_try_cmpxchg in i915_pmu_event_read
Use local64_try_cmpxchg instead of local64_cmpxchg (*ptr, old, new) == old
in i915_pmu_event_read. x86 CMPXCHG instruction returns success in ZF flag,
so this change saves a compare after cmpxchg (and related move instruction
in front of cmpxchg).
Also, try_cmpxchg implicitly assigns old *ptr value to "old" when cmpxchg
fails. There is no need to re-read the value in the loop.
No functional change intended.
Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: David Airlie <airlied@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Uros Bizjak <ubizjak@gmail.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230703150859.6176-1-ubizjak@gmail.com
Uma Shankar [Fri, 29 Sep 2023 07:43:06 +0000 (13:13 +0530)]
drm/i915/display: Created exclusive version of vga decode setup
Current vga arbiter implementation in i915 needs a re-design.
The current approach would cause real problems if anyone actually
needs to talk another GPU using legacy VGA resources.
The main issue is that X becomes a slideshow if it thinks there
are multiple GPUs that have VGA decoding enabled as it insists
on adjusting the VGA routing pretty much for every little operation
involving any of the GPUs.
The cleanup will be planned for i915. Meanwhile to focus on Xe
upstreaming and have a cleaner separation, the said functionality
is being moved to a different file exclusive for i915. Xe driver
will re-use rest of the display code from i915.
v2: Addressed Jani Nikula's review comments.
v3: Dropped a duplicate function (Jani)
v4: Updated commit message with reasoning as sugested by Ville.
Imre Deak [Fri, 29 Sep 2023 15:49:29 +0000 (18:49 +0300)]
drm/i915/dp_mst: Make sure pbn_div is up-to-date after sink reconnect
Atm the MST encoder config computation may use an out-of-date pbn_div
value, if the sink is unplugged and a sink is replugged with different
link rate/lane count capabilities. The current way of reinitializing
pbn_div depends on pbn_div getting cleared via intel_atomic_check() ->
drm_dp_mst_atomic_check() ->
drm_dp_mst_atomic_check_payload_alloc_limits(), however the clearing
won't happen if the sink got unplugged (and hence
drm_dp_mst_topology_mgr::mst_state being false).
To fix the above, simply update pbn_div unconditionally during config
computation, making pbn_div always match the link rate and lane count.
This is to eliminate all cases of "*ERROR* LSPCON mode hasn't settled",
followed by link training errors. Intel engineers recommended increasing
this timeout and that does resolve the issue.
On some CometLake-based device designs the Parade PS175 takes more than
400ms to settle in PCON mode. 100 reboot trials on one device resulted
in a median settle time of 440ms and a maximum of 444ms. Even after
increasing the timeout to 500ms, 2% of devices still had this error. So
this increases the timeout to 800ms.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9443 Signed-off-by: Pablo Ceballos <pceballos@google.com> Signed-off-by: Niko Tsirakis <ntsirakis@google.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231002204709.761089-1-ntsirakis@google.com
Ville Syrjälä [Tue, 3 Oct 2023 20:06:19 +0000 (23:06 +0300)]
drm/i915: Introduce for_each_shared_dpll()
No one really cares how we store the shared_dplls. Currently
it happens to be an array, but we could change that to a more
flexible scheme at some point. Hide the implementation details
behind an iterator macro.
The slight downside is the pll variable moving out of the
loop scope, but maybe someday soon we'll start to convert
everything over to having declarations within for-statements...
Ville Syrjälä [Tue, 3 Oct 2023 20:06:18 +0000 (23:06 +0300)]
drm/i915: Decouple I915_NUM_PLLS from PLL IDs
Stop assuming the size of PLL ID based bitmask is restricted
to I915_NUM_PLLS bits. This is the last thing coupling the
two things together and thus artificially limiting PLL IDs.
We could just pass any arbitrary (large enough) size to
for_each_set_bit() and be done with it, but the WARN
requiring the caller to not pass in a bogus bitmask seems
potentially useful to keep around. So let's just calculate
the full bitmask on the spot.
And while at it let's assert that the PLL IDs will fit
into the bitmask we use for them.
TODO: could also get rid of I915_NUM_PLLS entirely and just
dynamically allocate i915->shared_dplls[] and state->shared_dpll[].
But that would involve error handling in the modeset init path. Uff.
Ville Syrjälä [Tue, 3 Oct 2023 20:06:17 +0000 (23:06 +0300)]
drm/i915: Stop requiring PLL index == PLL ID
There's no good reason to keep around this PLL index == PLL ID
footgun. Get rid of it.
Both i915->shared_dplls[] and state->shared_dpll[] are indexed
by the same thing now, which is just the index we get at
initialization from dpll_mgr->dpll_info[]. The rest is all about
PLL IDs now.
v2: Add pll->index to mimic drm_crtc & co.
Remove the comment saying ID should match the index
v3: s/i/pll->index/ in debugfs loop (Jani)
Jani Nikula [Tue, 3 Oct 2023 12:42:09 +0000 (15:42 +0300)]
drm/i915: separate display runtime info init
Move display related functionality from intel_device_info_runtime_init()
to intel_display_device_info_runtime_init() and call the latter from the
top level.
drm/i915/lnl: possibility to enable FBC on first three planes
In LNL onwards, FBC can be associated to the first three planes.
FBC will be enabled on planes first come first served basis
until the userspace can select one of these FBC capable planes
explicitly.
v2:
- avoid fbc->state.plane check in intel_fbc_check_plane (Ville)
- simplify plane binding register writes (Matt)
- Update the subject to reflect that fbc can be enabled only in
the first three planes (Matt)
v3:
- use icl_is_hdr_plane(), use wrapper macro for plane binding
register access, comments update and patch split (Ville)
v4:
- update to the plane binding register access macro
Dave Airlie [Mon, 2 Oct 2023 20:02:29 +0000 (06:02 +1000)]
Merge tag 'drm-intel-gt-next-2023-09-28' of git://anongit.freedesktop.org/drm/drm-intel into drm-next
Driver Changes:
Fixes/improvements/new stuff:
- Fix TLB-Invalidation seqno store [mtl] (Alan Previn)
- Force a reset on internal GuC error [guc] (John Harrison)
- Define GSC fw [gsc] (Daniele Ceraolo Spurio)
- Update workaround 14016712196 [dg2/mtl] (Tejas Upadhyay)
- Mark requests for GuC virtual engines to avoid use-after-free (Andrzej Hajda)
- Add Wa_14015150844 [dg2/mtl] (Shekhar Chauhan)
- Prevent error pointer dereference (Dan Carpenter)
- Add Wa_18022495364 [tgl,adl,rpl] (Dnyaneshwar Bhadane)
- Fix GuC PMU by moving execlist stats initialization to execlist specific setup (Umesh Nerlige Ramappa)
- Fix PXP firmware load [pxp/mtl] (Alan Previn)
- Fix execution/context state of PXP contexts (Alan Previn)
- Limit the length of an sg list to the requested length (Matthew Wilcox)
- Fix reservation address in ggtt_reserve_guc_top [guc] (Javier Pello)
- Add Wa_18028616096 [dg2] (Shekhar Chauhan)
- Get runtime pm in busyness worker only if already active [guc/pmu] (Umesh Nerlige Ramappa)
- Don't set PIPE_CONTROL_FLUSH_L3 for aux inval (Nirmoy Das)
Future platform enablement:
- Fix and consolidate some workaround checks, make others IP version based [mtl] (Matt Roper)
- Replace Meteorlake subplatforms with IP version checks (Matt Roper)
- Adding DeviceID for Arrowlake-S under MTL [mtl] (Nemesa Garg)
- Run relevant bits of debugfs drop_caches per GT (Tvrtko Ursulin)
Miscellaneous:
- Remove Wa_15010599737 [dg2] (Shekhar Chauhan)
- Align igt_spinner_create_request with hangcheck [selftests] (Jonathan Cavitt)
- Remove pre-production workarounds [dg2] (Matt Roper)
- Tidy some workaround definitions (Matt Roper)
- Wait longer for tasks in migrate selftest [gt] (Jonathan Cavitt)
- Skip WA verification for GEN7_MISCCPCTL on DG2 [gt] (Andrzej Hajda)
- Silence injected failure in the load via GSC path [huc] (Daniele Ceraolo Spurio)
- Refactor deprecated strncpy (Justin Stitt)
- Update RC6 mask for mtl_drpc [debugfs/mtl] (Badal Nilawar)
- Remove a static inline that requires including i915_drv.h [gt] (Jani Nikula)
- Remove inlines from i915_gem_execbuffer.c [gem] (Jani Nikula)
- Remove gtt_offset from stream->oa_buffer.head/.tail [perf] (Ashutosh Dixit)
- Do not disable preemption for resets (Tvrtko Ursulin)
Let's introduce the basic documentation about CCS.
While doing that, also removed the legacy execution flag name. That flag
simply doesn't exist for CCS and it is not needed on current context
submission. Those flag names are only needed on legacy context,
while on new ones we only need to pass the engine ID.
It is worth mention that this documentation should probably live with
the engine definitions rather than in the i915.rst file directly and
that more updates are likely need in this section. But this should
come later.
v2: Overall improvements from Matt and Tvrtko.
Fixes: 944823c94639 ("drm/i915/xehp: Define compute class and engine") Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Sushma Venkatesh Reddy <sushma.venkatesh.reddy@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230926165107.23440-1-rodrigo.vivi@intel.com
Jani Nikula [Tue, 12 Sep 2023 11:06:28 +0000 (14:06 +0300)]
drm/i915: define I915 during i915 driver build
The xe driver will reuse i915 display code by compiling it separately as
part of xe. We'll want to be able to distinguish between building the
i915 display code for i915 and xe. Define I915 when building i915.
Cc: David Airlie <airlied@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/97558201836115b91cbe32840239df855d0c2e4c.1694514689.git.jani.nikula@intel.com
drm/i915: Warn on if set frontbuffer return value is not NULL on release
i915_gem_object_set_frontbuffer returns set frontbuffer pointer. When we
are releasing frontbuffer we are clearing the pointer from the object. Warn
on if return value is not null.
v3: Check i915_gem_object_set_frontbuffer return value separately
v2: Instead of ignoring do drm_WARN_ON
Dave Airlie [Thu, 28 Sep 2023 22:27:00 +0000 (08:27 +1000)]
Merge tag 'drm-misc-next-2023-09-27' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
drm-misc-next for v6.7-rc1:
UAPI Changes:
- drm_file owner is now updated during use, in the case of a drm fd
opened by the display server for a client, the correct owner is
displayed.
- Qaic gains support for the QAIC_DETACH_SLICE_BO ioctl to allow bo
recycling.
Cross-subsystem Changes:
- Disable boot logo for au1200fb, mmpfb and unexport logo helpers.
Only fbcon should manage display of logo.
- Update freescale in MAINTAINERS.
- Add some bridge files to bridge in MAINTAINERS.
- Update gma500 driver repo in MAINTAINERS to point to drm-misc.
Core Changes:
- Move size computations to drm buddy allocator.
- Make drm_atomic_helper_shutdown(NULL) a nop.
- Assorted small fixes in drm_debugfs, DP-MST payload addition error handling.
- Fix DRM_BRIDGE_ATTACH_NO_CONNECTOR handling.
- Handle bad (h/v)sync_end in EDID by clipping to htotal.
- Build GPUVM as a module.
Driver Changes:
- Simple drivers don't need to cache prepared result.
- Call drm_atomic_helper_shutdown() in shutdown/unbind for a whole lot
more drm drivers.
- Assorted small fixes in amdgpu, ssd130x, bridge/it6621, accel/qaic,
nouveau, tc358768.
- Add NV12 for komeda writeback.
- Add arbitration lost event to synopsis/dw-hdmi-cec.
- Speed up s/r in nouveau by not restoring some big bo's.
- Assorted nouveau display rework in preparation for GSP-RM,
especially related to how the modeset sequence works and
the DP sequence in relation to link training.
- Update anx7816 panel.
- Support NVSYNC and NHSYNC in tegra.
- Allow multiple power domains in simple driver.
Imre Deak [Thu, 21 Sep 2023 19:51:59 +0000 (22:51 +0300)]
drm/i915/fdi: Recompute state for affected CRTCs on FDI links
Recompute the state of all CRTCs on an FDI link during a modeset that
may be affected by the modeset of other CRTCs on the same link. This
ensures that each CRTC on the link maximizes its BW use (after another
CRTC is disabled).
In practice this means recomputing pipe B's config on IVB if pipe C gets
disabled.
v2:
- Add the change recomputing affected CRTC states in a separate patch.
(Ville)
v3: (Ville)
- Constify old and new crtc states.
- Check for fused off pipe C.
- Fix new vs. old crtc state mixup.
- Drop check for pipe C's enabled state.
Imre Deak [Thu, 21 Sep 2023 19:51:58 +0000 (22:51 +0300)]
drm/i915/fdi: Improve FDI BW sharing between pipe B and C
At the moment modesetting pipe C on IVB will fail if pipe B uses 4 FDI
lanes. Make the BW sharing more dynamic by trying to reduce pipe B's
link bpp in this case, until pipe B uses only up to 2 FDI lanes.
For this instead of the encoder compute config retry loop - which
reduced link bpp only for the encoder's pipe - reduce the maximum link
bpp for pipe B/C as required after all CRTC states are computed and
recompute the CRTC states with the new bpp limit.
Atm, all FDI encoder's compute config function returns an error if a BW
constrain prevents increasing the pipe bpp value. The corresponding
crtc_state->bw_constrained check can be replaced with checking
crtc_state->max_link_bpp_x16, add TODO comments for this. SDVO is an
exception where this case is only handled in the outer config retry
loop, failing the modeset with a WARN, add a FIXME comment to handle
this in the encoder code similarly to other encoders.
v2:
- Don't assume that a CRTC is already in the atomic state, while
reducing its link bpp.
- Add DocBook description to intel_fdi_atomic_check_link().
v3:
- Enable BW management for FDI links in a separate patch. (Ville)
v4: (Ville)
- Fail the SDVO encoder config computation if it doesn't support the
link bpp limit.
- Add TODO: comments about checking link_bpp_x16 instead of
bw_constrained.
v5:
- Replace link bpp limit check with a FIXME: comment in
intel_sdvo_compute_config(). (Ville)
Imre Deak [Thu, 21 Sep 2023 19:51:57 +0000 (22:51 +0300)]
drm/i915: Add helpers for BW management on shared display links
At the moment a modeset fails if the config computation of a pipe can't
fit its required BW to the available link BW even though the limitation
may be resolved by reducing the BW requirement of other pipes.
To improve the above this patch adds helper functions checking the
overall BW limits after all CRTC states have been computed. If the check
fails the maximum link bpp for a selected pipe will be reduced and all
the CRTC states will be recomputed until either the overall BW limit
check passes, or further bpp reduction is not possible (because all
pipes/encoders sharing the link BW reached their minimum link bpp).
Atm, the MST encoder allocates twice the required BW for YUV420 format
streams. A follow-up patchset will fix that, add a code comment about
this.
This change prepares for upcoming patches enabling the above BW
management on FDI and MST links.
v2:
- Rename intel_crtc_state::max_link_bpp to max_link_bpp_x16 and
intel_link_bw_limits::max_bpp to max_bpp_x16. (Jani)
v3:
- Add the helper functions in a separate patch. (Ville)
- Add the functions to intel_link_bw.c instead of intel_atomic.c (Ville)
- Return -ENOSPC instead of -EINVAL to userspace in case of a link BW
limit failure.
v4:
- Make intel_atomic_check_config() static.
v5: (Ville)
- Rename intel_link_bw_limits::min_bpp_pipes to min_bpp_reached_pipes
and intel_link_bw_reset_pipe_limit_to_min() to
intel_link_bw_set_min_bpp_for_pipe().
- Rename pipe_bpp to link_bpp in intel_link_bw_reduce_bpp().
- Add FIXME: comment about MST encoder's YUV420 BW allocation and
tracking the link bpp limit accordingly.
v6:
- Move intel_link_bw_compute_pipe_bpp() to intel_fdi.c (Ville)
- WARN_ON(BIT(pipe) & min_bpp_reached_pipes) in
intel_link_bw_set_bpp_limit_for_pipe(). (Ville)
- Rename intel_link_bw_set_min_bpp_for_pipe() to
intel_link_bw_set_bpp_limit_for_pipe() and
intel_link_bw_limits::min_bpp_reached_pipes to
bpp_limit_reached_pipes. (Ville)
- Remove unused header includes.
Imre Deak [Thu, 21 Sep 2023 19:51:56 +0000 (22:51 +0300)]
drm/i915: Factor out a helper to check/compute all the CRTC states
Factor out intel_atomic_check_config() to check and compute all the CRTC
states. This will be used by a follow up patch to recompute/check the
state until required by BW limitations between CRTCs.
Imre Deak [Thu, 21 Sep 2023 19:51:55 +0000 (22:51 +0300)]
drm/i915: Rename intel_modeset_all_pipes() to intel_modeset_all_pipes_late()
Rename intel_modeset_all_pipes() to intel_modeset_all_pipes_late() to
clarify when the function can be called (vs.
intel_modeset_pipes_in_mask_early()).
Imre Deak [Thu, 21 Sep 2023 19:51:54 +0000 (22:51 +0300)]
drm/i915: Add helper to modeset a set of pipes
Add intel_modeset_pipes_in_mask_early() to modeset a provided set of
pipes, used in a follow-up patch.
As opposed to intel_modeset_all_pipes() which modesets only the active
pipes - others don't requiring programming the HW - modeset all enabled
pipes in intel_modeset_pipes_in_mask_early() which may need to recompute
their state even if they are not active (that is in the DPMS off state).
While at it add DocBook descriptions for the two exported functions.
v2:
- Add a flag controlling if active planes are force updated as well.
- Add DockBook descriptions.
v3:
- For clarity use _early/_late suffixes for the exported functions
instead of the update_active_planes parameter. (Ville)
v4:
- In intel_modeset_pipes_in_mask_early() update only the crtc
flags relevant to the early phase. (Ville)
- Rename intel_modeset_all_pipes() in a separate patch.
Imre Deak [Thu, 21 Sep 2023 19:51:53 +0000 (22:51 +0300)]
drm/i915/dp: Limit the output link bpp in DSC mode
Limit the output link bpp in DSC mode to the link_config_limits
link.min_bpp_x16 .. max_bpp_x16 range the same way it's done in non-DSC
mode. Atm this doesn't make a difference, the link bpp range being
0 .. max pipe bpp, but a follow-up patch will need a way to reduce max
link bpp below its current value.
v2:
- Add to_bpp_int_roundup() instead of open coding it. (Jani)
Imre Deak [Thu, 21 Sep 2023 19:51:52 +0000 (22:51 +0300)]
drm/i915/dp: Update the link bpp limits for DSC mode
In non-DSC mode the link bpp can be set in 2*3 bpp steps in the pipe bpp
range, while in DSC mode it can be set in 1/16 bpp steps to any value
up to the maximum pipe bpp. Update the limits accordingly in both modes
to prepare for a follow-up patch which may need to reduce the max link
bpp value and starts to check the link bpp limits in DSC mode as well.
While at it add more detail to the link limit debug print and print it
also for DSC mode.
v2:
- Add to_bpp_frac_dec() instead of open coding it. (Jani)
v3: (Ville)
- Add BPP_X16_FMT / BPP_X16_ARG.
- Add TODO: comment about initializing the DSC link bpp limits earlier.
Imre Deak [Thu, 21 Sep 2023 19:51:51 +0000 (22:51 +0300)]
drm/i915/dp: Skip computing a non-DSC link config if DSC is needed
Computing the non-DSC mode link config is redundant once it's determined
that DSC will be needed, so skip computing it. In a follow-up patch this
simplifies setting the link limits which are dependent on the DSC vs.
non-DSC mode.
While at it sanitize the debug print about the MST DSC fallback path,
making it similar to the SST DSC one.
Imre Deak [Thu, 21 Sep 2023 19:51:50 +0000 (22:51 +0300)]
drm/i915/dp: Track the pipe and link bpp limits separately
A follow-up patch will need to limit the output link bpp both in the
non-DSC and DSC configuration, so track the pipe and link bpp limits
separately in the link_config_limits struct.
Use .4 fixed point format for link bpp matching the 1/16 bpp granularity
in DSC mode and for now keep this limit matching the pipe bpp limit.
v2: (Jani)
- Add to_bpp_int(), to_bpp_x16() helpers instead of opencoding them.
- Rename link_config_limits::link.min/max_bpp to min/max_bpp_x16.
Imre Deak [Thu, 21 Sep 2023 19:51:49 +0000 (22:51 +0300)]
drm/i915/dp: Factor out helpers to compute the link limits
Factor out helpers that DP / DP_MST encoders can use to compute the link
rate/lane count and bpp limits. A follow-up patch will call these to
recalculate the limits if DSC compression is required.
Ville Syrjälä [Tue, 6 Jun 2023 19:15:02 +0000 (22:15 +0300)]
drm/i915/dsb: Use DEwake to combat PkgC latency
Normally we could be in a deep PkgC state all the way up to the
point when DSB starts its execution at the transcoders undelayed
vblank. The DSB will then have to wait for the hardware to
wake up before it can execute anything. This will waste a huge
chunk of the vblank time just waiting, and risks the DSB execution
spilling into the vertical active period. That will be very bad,
especially when programming the LUTs as the anti-collision logic
will cause DSB to corrupt LUT writes during vertical active.
To avoid these problems we can instruct the DSB to pre-wake the
display engine on a specific scanline so that everything will
be 100% ready to go when we hit the transcoder's undelayed vblank.
One annoyance is that the scanline is specified as just that,
a single scanline. So if we happen to start the DSB execution
after passing said scanline no DEwake will happen and we may drop
back into some PkgC state before reaching the transcoder's undelayed
vblank. To prevent that we'll use the "force DEwake" bit to manually
force the display engine to stay awake. We'll then have to clear
the force bit again after the DSB is done (the force bit remains
effective even when the DSB is otherwise disabled).
Ville Syrjälä [Tue, 6 Jun 2023 19:15:01 +0000 (22:15 +0300)]
drm/i915: Introduce intel_crtc_scanline_to_hw()
Add a helper to convert our idea of a scanline to the hw's idea
of the same scanline (ie. apply crtc->scanline_offset in reverse).
We'll need this to tell the DSB do stuff on a specific scanline.
Ville Syrjälä [Tue, 6 Jun 2023 19:14:59 +0000 (22:14 +0300)]
drm/i915/dsb: Evade transcoder undelayed vblank when using DSB
We want to start the DSB execution from the transcoder's undelayed
vblank, so in order to guarantee atomicity with the all the other
mmio register writes we need to evade both vblanks.
Note that currently we don't add any vblank delay, so this is
effectively a nop. But in the future when we start to program
double buffered registers from the DSB we'll need to delay the
pipe's vblank to provide the register programming "window2"
for the DSB.
Ville Syrjälä [Tue, 6 Jun 2023 19:14:57 +0000 (22:14 +0300)]
drm/i915/dsb: Load LUTs using the DSB during vblank
Loading LUTs with the DSB outside of vblank doesn't really
work due to the palette anti-collision logic. Apparently the
DSB register writes don't get stalled like CPU mmio writes
do and instead we end up corrupting the LUT entries. Disabling
the anti-collision logic would allow us to successfully load
the LUT outside of vblank, but presumably that risks the LUT
reads from the scanout (temporarily) getting corrupted data
from the LUT instead.
The anti-collision logic isn't active during vblank so that
is when we can successfully load the LUT with the DSB. That is
what we want to do anyway to avoid tearing.
Ville Syrjälä [Tue, 6 Jun 2023 19:14:55 +0000 (22:14 +0300)]
drm/i915/dsb: Add support for non-posted DSB registers writes
Writing specific transcoder registers (and as it turns out, the
legacy LUT as well) via DSB needs a magic sequence to emit
non-posted register writes. Add a helper for this.
Ville Syrjälä [Tue, 6 Jun 2023 19:14:47 +0000 (22:14 +0300)]
drm/i915/dsb: Use non-locked register access
Avoid the locking overhead for DSB registers. We don't need the locks
and intel_dsb_commit() in particular needs to be called from the
vblank evade critical section and thus needs to be fast.
Commit ade8a0f59844 ("drm/i915: Make all GPU resets atomic") added a
preempt disable section over the hardware reset callback to prepare the
driver for being able to reset from atomic contexts.
In retrospect I can see that the work item at a time was about removing
the struct mutex from the reset path. Code base also briefly entertained
the idea of doing the reset under stop_machine in order to serialize
userspace mmap and temporary glitch in the fence registers (see eb8d0f5af4ec ("drm/i915: Remove GPU reset dependence on struct_mutex"),
but that never materialized and was soon removed in 2caffbf11762
("drm/i915: Revoke mmaps and prevent access to fence registers across
reset") and replaced with a SRCU based solution.
As such, as far as I can see, today we still have a requirement that
resets must not sleep (invoked from submission tasklets), but no need to
support invoking them from a truly atomic context.
Given that the preemption section is problematic on RT kernels, since the
uncore lock becomes a sleeping lock and so is invalid in such section,
lets try and remove it. Potential downside is that our short waits on GPU
to complete the reset may get extended if CPU scheduling interferes, but
in practice that probably isn't a deal breaker.
In terms of mechanics, since the preemption disabled block is being
removed we just need to replace a few of the wait_for_atomic macros into
busy looping versions which will work (and not complain) when called from
non-atomic sections.
v2:
* Fix timeouts which are now in us. (Andi)
* Update one comment as a drive by. (Andi)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris.p.wilson@intel.com> Cc: Paul Gortmaker <paul.gortmaker@windriver.com> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Cc: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230926100855.61722-1-tvrtko.ursulin@linux.intel.com
i915/guc: Get runtime pm in busyness worker only if already active
Ideally the busyness worker should take a gt pm wakeref because the
worker only needs to be active while gt is awake. However, the gt_park
path cancels the worker synchronously and this complicates the flow if
the worker is also running at the same time. The cancel waits for the
worker and when the worker releases the wakeref, that would call gt_park
and would lead to a deadlock.
The resolution is to take the global pm wakeref if runtime pm is already
active. If not, we don't need to update the busyness stats as the stats
would already be updated when the gt was parked.
Note:
- We do not requeue the worker if we cannot take a reference to runtime
pm since intel_guc_busyness_unpark would requeue the worker in the
resume path.
- If the gt was parked longer than time taken for GT timestamp to roll
over, we ignore those rollovers since we don't care about tracking the
exact GT time. We only care about roll overs when the gt is active and
running workloads.
- There is a window of time between gt_park and runtime suspend, where
the worker may run. This is acceptable since the worker will not find
any new data to update busyness.
v2: (Daniele)
- Edit commit message and code comment
- Use runtime pm in the worker
- Put runtime pm after enabling the worker
- Use Link tag and add Fixes tag
v3: (Daniele)
- Reword commit and comments and add details
Jani Nikula [Fri, 22 Sep 2023 10:56:45 +0000 (13:56 +0300)]
drm/i915/dp: refactor aux_ch_name()
Convert aux_ch_name() to a helper that prints a string to a caller
provided buffer, and use it to get more consistent aux channel
debugs. Now that all users of aux_ch_name() are in intel_dp_aux.c, we
can make it static too.
Ashutosh Dixit [Wed, 20 Sep 2023 04:02:11 +0000 (21:02 -0700)]
drm/i915/perf: Remove gtt_offset from stream->oa_buffer.head/.tail
There is no reason to add gtt_offset to the cached head/tail pointers
stream->oa_buffer.head and stream->oa_buffer.tail. This causes the code to
constantly add gtt_offset and subtract gtt_offset and is error
prone.
It is much simpler to maintain stream->oa_buffer.head and
stream->oa_buffer.tail without adding gtt_offset to them and just allow for
the gtt_offset when reading/writing from/to HW registers.
v2: Minor tweak to commit message due to dropping patch in previous series
projects / mirror_ubuntu-kernels.git / log