Use x100, or ver * 100 + rel, versions for full IP version checks,
similar to what xe driver does:
- Replace IP_VER(14, 1) inline with 1401, etc.
- Convert DISPLAY_VER_FULL() to DISPLAY_VERx100()
- Convert IS_DISPLAY_VER_FULL() to IS_DISPLAY_VERx100()
- Convert IS_DISPLAY_VER_STEP() to IS_DISPLAY_VERx100_STEP()
This makes ver.rel versions easier to use, follows the xe driver
pattern, and drops the dependency on the IP_VER() macro.
v2: Rebase, drop IP_VER() from xe compat headers
v3: Rebase
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241029155536.753413-1-jani.nikula@intel.com
Use a forward declaration for struct cec_notifier instead of including
media/cec-notifier.h in intel_display_types.h, and only include it where
needed.
Also realize that a lot of places depend on including linux/debugfs.h
via intel_display_types.h -> media/cec-notifier.h -> media/cec.h, and
include that too where needed.
v2: hsw_ips.c also needs debugfs.h (kernel test robot)
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240827104521.4151471-1-jani.nikula@intel.com
Need to take some Xe bo definition in here before
we can add the BMG display 64k aligned size restrictions.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Pull the code to determine the maximum CFB height
into a separate function.
To make this work we need to declare an explicit max height
for all older platforms as well. But that is actually just
the max plane height as pre-HSW hardware supposedly doesn't
have the trick of leaving the extra lines uncompressed.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240705145254.3355-12-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Rename intel_fbc_hw_tracking_covers_screen() to intel_fbc_surface_size_ok()
so that the naming scheme is the same for the surface size vs. plane
size checks. "surface size" is what bspec talks about.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240705145254.3355-7-ville.syrjala@linux.intel.com
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Extract intel_fbc_max_plane_size() from intel_fbc_plane_size_valid().
We'll have another use for this soon in determining how much stolen
memory we'd like to keep reserved for FBC.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240705145254.3355-5-ville.syrjala@linux.intel.com
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
_intel_fbc_cfb_stride() calculates the CFB stride the hardware would
automagically generate from the plane's stride. Rename the function
to intel_fbc_plane_cfb_stride() to better reflect its purpose.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240705145254.3355-4-ville.syrjala@linux.intel.com
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Switch the FBC code over to intel_display from i915, as
much as possible. This is the future direction so that
the display code can be shared between i915 and xe more
cleanly.
Some of the platform checks and the stolen mem facing stiff
still need i915 around though.
v2: Drop some redundant to_i915() casts
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240705145254.3355-3-ville.syrjala@linux.intel.com
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
On BMG-G21 we need to disable fbc due to complications around the WA.
v2:
- Try to handle with i915_drv.h and compat layer. (Rodrigo)
v3:
- For simplicity retreat back to the original design for now.
- Drop the extra \ from the Makefile (Jani)
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Jonathan Cavitt <jonathan.cavitt@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Vinod Govindapillai <vinod.govindapillai@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240703124338.208220-4-matthew.auld@intel.com
Move the handling of the disabling FBC when VT-d is active wa
as part of the intel_fbc_check_plane(). As the hw is still there,
intel_fbc_sanitize should be able to handle the state properly.
v2: update the patch description (Jani Nikula)
v3: fix the return value in wa handling (Jani Nikula)
Bspec: 21664
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240528114826.134958-1-vinod.govindapillai@intel.com
We are going to reuse has_psr2 for panel_replay as well. Rename it
as has_sel_update to avoid confusion.
v3: do not add has_psr check into psr2 case in intel_dp_compute_vsc_sdp
v2: Rebase
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240510093823.3146455-2-jouni.hogander@intel.com
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
