Move all DPFC_CHICKEN programming into intel_fbc_program_workarounds().
We already have one thing programmed there, whereas the rest is strewn
about in intel_display_wa_apply() and init_clock_gating(). Since we have
a single place doing all the programming (and it's serialized by the
crtc commits) there should be no danger of rmw races.
Other FBC related workarounds also exist, but those require fiddling
with other registers that may also get programmed from other places,
so we'll need to think harder what to do with those.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240123090051.29818-2-ville.syrjala@linux.intel.com
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Only display workarounds 0391 and 0475 call for disabling
FBC with render compression, and those are listed only for
pre-prod SKL steppings. So it should be safe to enable
FB+CCS on production hardware.
AFAIK CCS is limited to 50% bandwidth reduction (perhaps
clear color can do better?). FBC can exceed that number
by quite a bit, given the right kind of framebuffer
contents. So piling on both kinds of compressions could
still make sense.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10125
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240123090244.30025-1-ville.syrjala@linux.intel.com
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
In earlier versions, FBC was restricted if PSR2 is enabled. From
xe2lpd onwards no such restrictions are needed anymore.
HSD: 14014305387
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231110093225.39573-2-vinod.govindapillai@intel.com
IVB Bspec says:
"Frame Buffer Compression is only supported with memory surfaces of 4096 lines
or less and pipe source sizes of 4096 pixels by 2048 lines or less. "
so seems like we should be able to bump the offset+size limit to
at least 4kx4k. Make it so.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231117171833.25816-3-ville.syrjala@linux.intel.com
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Do separate checks for the visible plane size vs. the surface
size (which I take to mean offset+size). For now both use the
same max w/h, but we can relax the surface size limits as
a followup.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231117171833.25816-1-ville.syrjala@linux.intel.com
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
FIFO underruns are observed when FBC is enabled on plane 2 or
plane 3. Recommended WA is to update the FBC enabling sequence.
The plane binding register bits need to be updated separately
before programming the FBC enable bit.
Bspec: 74151
Reviewed-by: Mika Kahola <mika.kahola@intel.com> #v3
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231111114320.87277-2-vinod.govindapillai@intel.com
Carve up pixel_format_is_valid() into per-platform variants to
make it easier to see what limits are actually being imposed.
Note that the XRGB1555 can be dropped from the g4x+ variant
since the plane no longer supports that format anyway.
TODO: maybe go for vfuncs later
v2: Update for lnl changes
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> #v1
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231003194256.28569-5-ville.syrjala@linux.intel.com
Carve up rotation_is_valid() into per-platform variants to
make it easier to see what limits are actually being imposed.
TODO: maybe go for vfuncs later
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231003194256.28569-4-ville.syrjala@linux.intel.com
Carve up tiling_is_valid() into per-platform variants to
make it easier to see what limits are actually being imposed.
TODO: maybe go for vfuncs later
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231003194256.28569-3-ville.syrjala@linux.intel.com
Carve up stride_is_valid() into per-platform variants to
make it easier to see what limits are actually being imposed.
TODO: maybe go for vfuncs later
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231003194256.28569-2-ville.syrjala@linux.intel.com
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.
Reviewed-by: Swati Sharma <swati2.sharma@intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231003194256.28569-1-ville.syrjala@linux.intel.com
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
Bspec: 69560
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230922133003.150578-2-vinod.govindapillai@intel.com
We are planning to move flush performed from work queue. This
means it is possible to have invalidate -> flip -> flush sequence.
Handle this by clearing possible busy bits on flip.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230901093500.3463046-2-jouni.hogander@intel.com
Stepping-specific display behavior shouldn't be tied to MTL as a
platform, but rather specifically to the Xe_LPD+ IP. Future non-MTL
platforms may re-use this IP and will need to follow the exact same
logic and apply the same workarounds. IS_MTL_DISPLAY_STEP() is dropped
in favor of a new macro IS_DISPLAY_IP_STEP() that only checks the
display IP version.
v2:
- Rename macro to IS_DISPLAY_IP_STEP for consistency with the
corresponding GT macro and handle steppings the same way.
v3:
- Drop the automatic "STEP_" pasting.
v4:
- Implement IS_DISPLAY_IP_STEP on top of IS_DISPLAY_IP_RANGE /
IS_DISPLAY_STEP building blocks and make the parameters from/until
instead of begin/fixed. (Jani)
- Fix usage details in comment.
v5:
- Tweak macro comment. (Gustavo)
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230821180619.650007-17-matthew.d.roper@intel.com
As a preparation for Xe move HW fence details away from intel_fbc code.
Add new functions to check support for legacy fencing and fence id and use
these in fbc code. Xe doesn't support legacy fencing.
v2: Fix intel_gt_support_legacy_fencing macro
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Nirmoy Das <nirmoy.das@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230614051731.745821-4-jouni.hogander@intel.com
As a preparation for Xe change stolen memory initialization check to be
done in use-time instead of during initialization.
In case of xe, stolen memory is initialised much later so it can't be
checked during init. There is no specific reason to check this in init for
i915 either -> perform the check in use-time. This also gives us benefit
fbc_no_reason reporting missing initialization being reason for disabled
fbc.
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Jeevan B <jeevan.b@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230614051731.745821-3-jouni.hogander@intel.com
We are preparing for Xe. Xe stolen memory handling differs from i915 so we
want to move stolen memory handling details into i915_gem_stolen.
Also add a common type for fbc compressed fb and use it from fbc code
instead of underlying type directly. This way we can have common type
i915_stolen_fb for both i915 and Xe.
v2: Fix couple of checkpatch warnings
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Nirmoy Das <nirmoy.das@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230614051731.745821-2-jouni.hogander@intel.com
In order to avoid flush_scheduled_work() usage, add a dedicated
workqueue in the drm_i915_private structure. In this way, we don't
need to use the system queue anymore.
This change is mostly mechanical and based on Tetsuo's original
patch[1].
v6 by Jani:
- Also create unordered_wq for mock device
Link: https://patchwork.freedesktop.org/series/114608/ [1]
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/c816ebe17ef08d363981942a096a586a7658a65e.1686231190.git.jani.nikula@intel.com
Prepare for re-enabling -Wunused-but-set-variable.
for_each_new_intel_plane_in_state() requires passing in a struct
intel_plane_state pointer, which it uses, but in many places this leads
to warning about unused but set variables. Annotate them with
__maybe_unused.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/438ff3b257b7f85ecca5750ae8687336faee0a79.1685119007.git.jani.nikula@intel.com
Move the runtime info specific to display into display-specific
structures as has already been done with the constant display info.
v2:
- Rename __runtime to __runtime_defaults for more clarity on the
purpose. (Andrzej)
- Move introduction of DISPLAY_INFO() to previous patch. (Andrzej)
- Drop NO_DISPLAY macro. (Andrzej)
v3:
- Use "{}" instead of "{ 0 }" for empty struct init. (Jani)
Cc: Andrzej Hajda <andrzej.hajda@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230523195609.73627-4-matthew.d.roper@intel.com
A lot of places include i915_reg.h implicitly via i915_irq.h, which gets
included implicitly via intel_display_trace.h. Remove the includes from
the headers, and include i915_reg.h and i915_irq.h explicitly where
needed.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230419094243.366821-1-jani.nikula@intel.com
Using DEFINE_SIMPLE_ATTRIBUTE macro with the debugfs_create_file()
function adds the overhead of introducing a proxy file operation
functions to wrap the original read/write inside file removal protection
functions. This adds significant overhead in terms of introducing and
managing the proxy factory file operations structure and function
wrapping at runtime.
As a replacement, a combination of DEFINE_DEBUGFS_ATTRIBUTE macro paired
with debugfs_create_file_unsafe() is suggested to be used instead. The
DEFINE_DEBUGFS_ATTRIBUTE utilises debugfs_file_get() and
debugfs_file_put() wrappers to protect the original read and write
function calls for the debug attributes. There is no need for any
runtime proxy file operations to be managed by the debugfs core.
Following coccicheck make command helped identify this change:
make coccicheck M=drivers/gpu/drm/i915/ MODE=patch COCCI=./scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci
Signed-off-by: Deepak R Varma <drv@mailo.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/5d26e924ec8dea21925c77fa79a2bf2a34cef705.1673451705.git.drv@mailo.com
This patch introduces initial workarounds for mtl platform
v2: switch IS_MTL_DISPLAY_STEP to use IS_METEORLAKE from testing display
ver. (Tvrtko)
v3: clerical issues, extend 16015201720 to mtl. (MattR)
v4: make sure 16015201720 includes display 13. (MattR)
Bspec: 66624
Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com>
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221209220543.502047-1-matthew.s.atwood@intel.com
Prefer our own intel_crtc_needs_modeset() wrapper to
drm_atomic_crtc_needs_modeset() whenever we are dealing
with the intel_ types instead of drm_ types. Makes things
a bit neater in general.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221031214037.1636-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Replace the somewhat obscure crtc_state.update_pipe checks
with a more descriptive thing. Also nicely matches the
intel_crtc_needs_modeset() counterpart for full modesets.
v2: Handle one more case in the fbc code
Reviewed-by: Jani Nikula <jani.nikula@intel.com> #v1
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221021162442.27283-2-ville.syrjala@linux.intel.com
Remove the old tales about 90/270 degree rotation
effectively preventing FBC. That hasn't been true since
we stopped demanding the fence is present in
commit 691f7ba58d ("drm/i915/display/fbc: Make fences
a nice-to-have for GEN9+")
Also fix up the multiline comment formatting while at it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220916165206.1499-2-ville.syrjala@linux.intel.com
Reviewed-by: Luca Coeho <luciano.coelho@intel.com>
Replace the mutex_is_locked() stuff with lockdep_assert_held() since
that's what it's there for.
Also sprinkle these around so that we have more or less
mirrored coverage for the enable vs. disable instead of the
current situation where the asserts seem to be more or less
randomly thrown around.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220620182917.10765-2-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Move the flip_pending assignment into __intel_fbc_post_update()
from intel_fbc_post_update(). Now mirrors the pre_update() side.
The only reason the assignment was in the higher level function
is that we used to call __intel_fbc_post_update() from elsewhere
as well. That got cleaned up in commit b39d2c6202 ("drm/i915/fbc:
Call intel_fbc_activate() directly from frontbuffer flush")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220620182917.10765-1-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
drm_crtc.h has no need for drm_blend.h, so don't include it.
Avoids useless rebuilds of the entire universe when
touching drm_blend.h.
Quite a few placs do currently depend on drm_blend.h without
actually including it directly. All of those need to be fixed
up.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220613200317.11305-4-ville.syrjala@linux.intel.com
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Acked-by: Jani Nikula <jani.nikula@intel.com>
intel_fbc_check_plane() is supposed to an int, not a boolean.
So replace the bogus 'return false's with the correct 'return 0's.
These were accidental copy-paste mistakes when the code got moved
into intel_fbc_check_plane() from somewhere else tht did return
a boolean.
No functional issue here since false==0.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220413152852.7336-2-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
plane_state->uapi.crtc is not what we want to be looking at.
If bigjoiner is used hw.crtc is what tells us what crtc the plane
is supposedly using.
Not an actual problem on current hardware as the only FBC capable
pipe (A) can't be a bigjoiner slave and thus uapi.crtc==hw.crtc
always here. But when we get more FBC instances this will become
actually important.
Fixes: 2e6c99f886 ("drm/i915/fbc: Nuke lots of crap from intel_fbc_state_cache")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220413152852.7336-1-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Let's make sure FBC is always disabled when we start to take
over the hardware state.
I suspect this should never really happen, since the only time
when we really should be taking over with the display already
active is when the previous state was progammed by the BIOS,
which likely shouldn't use FBC. This could be driver init,
or S4 resume when the boot kernel doesn't load i915. But I
suppose no harm in keeping this code around for exra safety
since it's quite trivial.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220315140001.1172-7-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
By the time intel_fbc_global_disable() gets called during driver
teardown we should have already disabled all the crtcs, so
no way FBC should be enabled at this point.
And I have no idea what the other user (i915_restore_display())
is even trying to achieve.
So let's just throw intel_fbc_global_disable() into the bin.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220315140001.1172-6-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Don't issue a nuke from frontbuffer flush while a flip is pending.
This avoids the DSPADDR/DSPSURF rmw abuse from the pre-snb nuke
from racing with the DSPADDR/DSPSURF write being performed by
the flip/plane update. The flip itself will already cause the nuke
so a double nuke is redundant.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220315140001.1172-4-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
