| Message ID | 20211012221245.2609670-1-matthew.d.roper@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | drm/i915/uapi: Add comment clarifying purpose of I915_TILING_* values | expand |
Looks good to me. Reviewed-by: Caz Yokoyama <caz.yokoyama@intel.com> -caz On Tue, 2021-10-12 at 15:12 -0700, Matt Roper wrote: > The I915_TILING_* values in our uapi header are intended solely for > use > with the old get_tiling/set_tiling ioctls that operate on hardware > de-tiling fences; all other uapi communication about tiling types is > done via framebuffer modifiers rather than with these old values. > > On newer Intel platforms detiling fences no longer exist so the old > get_tiling/set_tiling ioctls are no longer usable and will always > return > -EOPNOTSUPP. This means there's no reason to add new tiling types > (such > as the Tile4 format introduced by Xe_HP) to the uapi header > here. Any > kernel-internal code that needs to represent tiling format should > either > rely on framebuffer modifiers (as the display code does) or use some > kind of non-uapi enum (as the GEM blt selftest now does). > > References: > https://patchwork.freedesktop.org/patch/456656/?series=95308 > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> > Signed-off-by: Matt Roper <matthew.d.roper@intel.com> > --- > include/uapi/drm/i915_drm.h | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/include/uapi/drm/i915_drm.h > b/include/uapi/drm/i915_drm.h > index aa2a7eccfb94..9b8e61163c39 100644 > --- a/include/uapi/drm/i915_drm.h > +++ b/include/uapi/drm/i915_drm.h > @@ -1522,6 +1522,12 @@ struct drm_i915_gem_caching { > #define I915_TILING_NONE 0 > #define I915_TILING_X 1 > #define I915_TILING_Y 2 > +/* > + * Do not add new tiling types here. The I915_TILING_* values are > for > + * de-tiling fence registers that no longer exist on modern > platforms. Although > + * the hardware may support new types of tiling in general (e.g., > Tile4), we > + * do not need to add them to the uapi that is specific to now- > defunct ioctls. > + */ > #define I915_TILING_LAST I915_TILING_Y > > #define I915_BIT_6_SWIZZLE_NONE 0
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h index aa2a7eccfb94..9b8e61163c39 100644 --- a/include/uapi/drm/i915_drm.h +++ b/include/uapi/drm/i915_drm.h @@ -1522,6 +1522,12 @@ struct drm_i915_gem_caching { #define I915_TILING_NONE 0 #define I915_TILING_X 1 #define I915_TILING_Y 2 +/* + * Do not add new tiling types here. The I915_TILING_* values are for + * de-tiling fence registers that no longer exist on modern platforms. Although + * the hardware may support new types of tiling in general (e.g., Tile4), we + * do not need to add them to the uapi that is specific to now-defunct ioctls. + */ #define I915_TILING_LAST I915_TILING_Y #define I915_BIT_6_SWIZZLE_NONE 0
The I915_TILING_* values in our uapi header are intended solely for use with the old get_tiling/set_tiling ioctls that operate on hardware de-tiling fences; all other uapi communication about tiling types is done via framebuffer modifiers rather than with these old values. On newer Intel platforms detiling fences no longer exist so the old get_tiling/set_tiling ioctls are no longer usable and will always return -EOPNOTSUPP. This means there's no reason to add new tiling types (such as the Tile4 format introduced by Xe_HP) to the uapi header here. Any kernel-internal code that needs to represent tiling format should either rely on framebuffer modifiers (as the display code does) or use some kind of non-uapi enum (as the GEM blt selftest now does). References: https://patchwork.freedesktop.org/patch/456656/?series=95308 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> --- include/uapi/drm/i915_drm.h | 6 ++++++ 1 file changed, 6 insertions(+)