For NV12 FBs with odd main surface tile-row height the CCS surface
height was incorrectly calculated 1 less than the actual value. Fix this
by rounding up the result of divison. For consistency do the same for
the CCS surface width calculation.
Fixes: b3e57bccd6 ("drm/i915/tgl: Gen-12 render decompression")
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/20211026225105.2783797-2-imre.deak@intel.com
(cherry picked from commit 2ee5ef9c93)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Add support for remapping CCS FBs on ADL-P to remove the restriction
of the power-of-two sized stride and the 2MB surface offset alignment
for these FBs.
We can only remap the tiles on the main surface, not the tiles on the
CCS surface, so userspace has to generate the CCS surface aligning to
the POT size padded main surface stride (by programming the AUX
pagetable accordingly). For the required AUX pagetable setup, this
requires that either the main surface stride is 8 tiles or that the
stride is 16 tiles aligned (= 64 kbytes, the area mapped by one AUX
PTE).
v2:
- Init intel_remapped_info::plane_alignment only for remapped views and
do this from intel_fb_view_init().
Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.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/20210906182715.3915100-6-imre.deak@intel.com
At the moment CCS FB strides must be power-of-two sized, but a follow-up
change will add support remapping these FBs, allowing the FB passed in
by userspace to have a non-POT sized stride. For these remapped FBs we
can only remap the main surface, not the CCS surface. This means that
userspace has to always generate the CCS surface aligning to the POT
stride padded main surface (by setting up the CCS AUX pagetables
accordingly). Adjust the CCS surface stride check to enforce this.
No functional change.
v2:
- Fix the gen12_ccs_aux_stride() is not static sparse warning.
Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.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/20210906182715.3915100-3-imre.deak@intel.com
The tile size for all surface types is 4 kbyte (or 2 kbyte on old
platforms), with the exception of the TGL/ADL CCS surface where the tile
size is 64 bytes. To be able to remap CCS FBs the CCS surface tile needs
to be defined as 4 kbyte as well (the granularity of GTT pages in a
remapped view).
The only place using the dimension of the 64 byte CCS area is the initial
check for the main vs. CCS plane origin coordinate match. To prepare for
adding support for remapping CCS FBs let's call the 64 byte CCS area a
'tile block' and add a helper to retrieve the dimensions for it.
No functional change.
Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.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/20210906182715.3915100-2-imre.deak@intel.com
All DPT FB color plane surface base addresses must be 2MB aligned. On
ADL_P this means that the offsets in CCS FB object must be also 2MB
aligned. Adjusting unaligned offsets for these FBs during commit time
(compensating with the x/y offsets) doesn't work, since the big
alignment would most probably lead to an x/y offset mismatch error
between the main and CCS planes.
We can overcome this limitation by remapping CCS FBs, so that each color
plane is at an aligned offset, leaving x/y for each plane unadjusted
during commit and so not causing an x/y mismatch error. However
remapping for CCS FBs will be done as a follow-up, so for now require
that user space allocates the FB obj with properly aligned planes.
v2: s/SZ_2M/512*4k/ for clarity. (Ville)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210524172703.2113058-1-imre.deak@intel.com
The specification only requires DPT FB strides to be POT aligned, but
there seems to be also a minimum of 8 stride tile requirement. Scanning
out FBs with < 8 stride tiles will result in pipe faults (even though
the stride is POT aligned).
Signed-off-by: Imre Deak <imre.deak@intel.com>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210506161930.309688-10-imre.deak@intel.com
The latest specification removed the support for 90/270 FB rotation on
ADL_P, even though legacy Y-tiled surfaces are supported. Align the code
accordingly.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210506161930.309688-9-imre.deak@intel.com
We can handle the surface alignment of CCS and UV color planes for all
modifiers at one place, so do this. An AUX color plane can be a CCS or a
UV plane, use only the more specific query functions and remove
is_aux_plane() becoming redundant.
While at it add a TODO for linear UV color plane alignments. The spec
requires this to be stride-in-bytes * 64 on all platforms, whereas the
driver uses an alignment of 4k for gen<12 and 256k for gen>=12 for
linear UV planes.
v2:
- Restore previous alignment for linear UV surfaces.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210421173220.3587009-1-imre.deak@intel.com
While converting the rest of the driver to use GRAPHICS_VER() and
MEDIA_VER(), following what was done for display, some discussions went
back on what we did for display:
1) Why is the == comparison special that deserves a separate
macro instead of just getting the version and comparing directly
like is done for >, >=, <=?
2) IS_DISPLAY_RANGE() is weird in that it omits the "_VER" for
brevity. If we remove the current users of IS_DISPLAY_VER(), we
could actually repurpose it for a range check
With (1) there could be an advantage if we used gen_mask since multiple
conditionals be combined by the compiler in a single and instruction and
check the result. However a) INTEL_GEN() doesn't use the mask since it
would make the code bigger everywhere else and b) in the cases it made
sense, it also made sense to convert to the _RANGE() variant.
So here we repurpose IS_DISPLAY_VER() to work with a [ from, to ] range
like was the IS_DISPLAY_RANGE() and convert the current IS_DISPLAY_VER()
users to use == and != operators. Aside from the definition changes,
this was done by the following semantic patch:
@@ expression dev_priv, E1; @@
- !IS_DISPLAY_VER(dev_priv, E1)
+ DISPLAY_VER(dev_priv) != E1
@@ expression dev_priv, E1; @@
- IS_DISPLAY_VER(dev_priv, E1)
+ DISPLAY_VER(dev_priv) == E1
@@ expression dev_priv, from, until; @@
- IS_DISPLAY_RANGE(dev_priv, from, until)
+ IS_DISPLAY_VER(dev_priv, from, until)
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
[Jani: Minor conflict resolve while applying.]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20210413051002.92589-4-lucas.demarchi@intel.com
An upcoming platform has a restriction that the FB stride must be
power-of-two aligned. To support framebuffer layouts that are not in
this layout add a logic that pads the tile rows to the POT aligned size.
The HW won't read the padding PTEs, so these don't have to point to an
allocated address, or even have their valid flag set. So use a NULL PTE
instead for instance the scratch page, which is simple and keeps the SG
table compact.
v2:
- Simplify plane_view_dst_stride(). (Ville)
- Pass pitch_tiles as unsigned int.
v3:
- Drop unintentional s/plane_state->rotation/plane_config->rotation/
change.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210325214808.2071517-24-imre.deak@intel.com
Save some place in the GTT VMAs by using a u16 instead of unsigned int
to store the view dimensions. The maximum FB stride is 256kB which is
4096 tiles in the worst case (yf-tiles), the maximum FB height is 16k
pixels, which is 16384 tiles in the worst case (linear 4x1 tiled FB).
v2:
- Fix worst case tile height formula in commit log. (Ville)
- Add an assign_chk_ovf helper to simplify the related assignments.
v3:
- Enclose params of the assign_chk_ovf macro in parentheses.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210325214808.2071517-21-imre.deak@intel.com
Factor out to a new function the logic to calculate the FB remapping
parameters both during creating the FB and when flipping to it.
v2:
- Keep stride next to offset calculation. (Ville)
- Enclose check_array_bounds macro arguments in parentheses.
v3:
- Rebase on top of the struct intel_fb_view refactoring.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210325214808.2071517-20-imre.deak@intel.com
Instead of copying separately the GTT remapped and color plane view info
from the FB to the plane state, do this by copying the whole
intel_fb_view struct. For this we make sure the FB view state is fully
inited (that is also including the view type) already during FB
creation, so this init is not required during atomic check time. This
also means the we don't need to reset the unused color plane info during
atomic check, as these are already reset during FB creation.
I noticed that initial FBs will only work atm if they are page aligned
(which BIOS most probably always ensures), but add a comment to sanitize
this part once. Also we won't disable the plane if
get_initial_plane_config() failed for some reason (for instance due to
unsupported rotation), add a TODO: comment for this too.
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>
Link: https://patchwork.freedesktop.org/patch/msgid/20210325214808.2071517-19-imre.deak@intel.com
Instead of special casing getting the pitch for the normal view, store
it during FB creation to the FB normal view struct and retrieve it from
there during atomic check, as it's done for the rotated view. A
follow-up patch does the same for a new FB remapped view.
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>
Link: https://patchwork.freedesktop.org/patch/msgid/20210325214808.2071517-18-imre.deak@intel.com
To allow the simplification of FB/plane view computation in the
follow-up patches, unify the corresponding state in the
intel_framebuffer and intel_plane_state structs into a new intel_fb_view
struct.
This adds some overhead to intel_framebuffer as the rotated view will
have now space for 4 color planes instead of the required 2 and it'll
also contain the unused offset for each color_plane info. Imo this is an
acceptable trade-off to get a simplified way of the remap computation.
Use the new intel_fb_view struct for the FB normal view as well, so (in
the follow-up patches) we can remove the special casing for normal view
calculation wrt. the calculation of remapped/rotated views. This also
adds an overhead to the intel_framebuffer struct, as the gtt remap info
and per-color plane offset/pitch is not required for the normal view,
but imo this is an acceptable trade-off as above. The per-color plane
pitch filed will be used by a follow-up patch, so we can retrieve the
pitch for each view in the same way.
No functional changes in this patch.
v2:
- Make the patch have _no functional change_.
(fix skl_check_nv12_aux_surface() and skl_check_main_surface()).
- s/i915_color_plane_view::pitch/stride/ (Ville)
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
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>
Link: https://patchwork.freedesktop.org/patch/msgid/20210325214808.2071517-17-imre.deak@intel.com
Factor out to a new function the logic to calculate an FB plane's
normal-view size.
Instead of using intel_remapped_plane_info, which is related only to
remapping, add a helper to get the tile pitch and rows for an FB plane,
so these helpers can be used both by the normal size calculation and the
remapping code.
Also add a new fb_plane_view_dims struct in which we can pass around the
view (either FB plane or plane source) and tile dimensions conveniently
to functions calculating further view parameters.
v2:
- Add back the +1 tile adjustment for x!=0 in calc_plane_normal_size(). (Ville)
- s/pages/tiles/ in calc_plane_normal_size(). (Ville)
- Add a helper for the plane view width calculation. (Ville)
- Return tiles as unsigned int from calc_plane_normal_size().
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>
Link: https://patchwork.freedesktop.org/patch/msgid/20210325214808.2071517-16-imre.deak@intel.com
Factor out to a new function the logic to convert the FB plane x/y
values to a tile size based offset and new x/y relative to this offset.
This makes intel_fill_fb_info() and intel_plane_remap_gtt() somewhat
more readable.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210325214808.2071517-15-imre.deak@intel.com
Factor out to a new function the logic to convert the FB plane offset to
x/y and check the validity of x/y, with the goal to make
intel_fill_fb_info() more readable.
v2: Use &fb->base instead of a drm_fb alias. (Ville)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210325214808.2071517-14-imre.deak@intel.com
Move the FB plane specific functions from intel_display.c to intel_fb.c.
There's more functions like this, but I leave moving those as well for a
follow up, and for now moving only the ones needed by the end of this
patchset (adding support for padding tile-rows in an FB GGTT view).
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210325214808.2071517-11-imre.deak@intel.com
