| Message ID | 1438595283-4076-1-git-send-email-tvrtko.ursulin@linux.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 08/03/2015 10:48 AM, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin <tvrtko.ursulin@intel.com> > > Sync up with new kernel features as per commits: > > e3eb3250d84ef97b766312345774367b6a310db8 > 93b81f5102a7cd270a305c2741b17c8d44bb0629 > b5ff6e1637b683d5996ae11ac29afe406c0bee90 > 8c4f83fb1e8bf317e894f62d17a63c32b7a6b75e > 570655b09b065d2fff1b8ab9bdb8308f4c5a05a3 Ping anyone? Can we review and merge this uapi catchup or some existing process will scoop it up at some point? It hasn't happened so far... Regards, Tvrtko > Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> > Cc: dri-devel@lists.freedesktop.org > Cc: Rob Clark <robdclark@gmail.com> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch> > --- > include/drm/drm.h | 1 + > include/drm/drm_fourcc.h | 93 ++++++++++++++++++++++++++++++++++++++++++++++++ > include/drm/drm_mode.h | 11 +++++- > 3 files changed, 104 insertions(+), 1 deletion(-) > > diff --git a/include/drm/drm.h b/include/drm/drm.h > index 167b7b81b0d0..a950b580cd11 100644 > --- a/include/drm/drm.h > +++ b/include/drm/drm.h > @@ -816,6 +816,7 @@ struct drm_event_vblank { > #define DRM_CAP_PRIME 0x5 > #define DRM_CAP_TIMESTAMP_MONOTONIC 0x6 > #define DRM_CAP_ASYNC_PAGE_FLIP 0x7 > +#define DRM_CAP_ADDFB2_MODIFIERS 0x10 > > #define DRM_PRIME_CAP_IMPORT 0x1 > #define DRM_PRIME_CAP_EXPORT 0x2 > diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h > index 85facb0a17cf..63a80ca5ba39 100644 > --- a/include/drm/drm_fourcc.h > +++ b/include/drm/drm_fourcc.h > @@ -127,4 +127,97 @@ > #define DRM_FORMAT_YUV444 fourcc_code('Y', 'U', '2', '4') /* non-subsampled Cb (1) and Cr (2) planes */ > #define DRM_FORMAT_YVU444 fourcc_code('Y', 'V', '2', '4') /* non-subsampled Cr (1) and Cb (2) planes */ > > + > +/* > + * Format Modifiers: > + * > + * Format modifiers describe, typically, a re-ordering or modification > + * of the data in a plane of an FB. This can be used to express tiled/ > + * swizzled formats, or compression, or a combination of the two. > + * > + * The upper 8 bits of the format modifier are a vendor-id as assigned > + * below. The lower 56 bits are assigned as vendor sees fit. > + */ > + > +/* Vendor Ids: */ > +#define DRM_FORMAT_MOD_NONE 0 > +#define DRM_FORMAT_MOD_VENDOR_INTEL 0x01 > +#define DRM_FORMAT_MOD_VENDOR_AMD 0x02 > +#define DRM_FORMAT_MOD_VENDOR_NV 0x03 > +#define DRM_FORMAT_MOD_VENDOR_SAMSUNG 0x04 > +#define DRM_FORMAT_MOD_VENDOR_QCOM 0x05 > +/* add more to the end as needed */ > + > +#define fourcc_mod_code(vendor, val) \ > + ((((u64)DRM_FORMAT_MOD_VENDOR_## vendor) << 56) | (val & 0x00ffffffffffffffULL)) > + > +/* > + * Format Modifier tokens: > + * > + * When adding a new token please document the layout with a code comment, > + * similar to the fourcc codes above. drm_fourcc.h is considered the > + * authoritative source for all of these. > + */ > + > +/* Intel framebuffer modifiers */ > + > +/* > + * Intel X-tiling layout > + * > + * This is a tiled layout using 4Kb tiles (except on gen2 where the tiles 2Kb) > + * in row-major layout. Within the tile bytes are laid out row-major, with > + * a platform-dependent stride. On top of that the memory can apply > + * platform-depending swizzling of some higher address bits into bit6. > + * > + * This format is highly platforms specific and not useful for cross-driver > + * sharing. It exists since on a given platform it does uniquely identify the > + * layout in a simple way for i915-specific userspace. > + */ > +#define I915_FORMAT_MOD_X_TILED fourcc_mod_code(INTEL, 1) > + > +/* > + * Intel Y-tiling layout > + * > + * This is a tiled layout using 4Kb tiles (except on gen2 where the tiles 2Kb) > + * in row-major layout. Within the tile bytes are laid out in OWORD (16 bytes) > + * chunks column-major, with a platform-dependent height. On top of that the > + * memory can apply platform-depending swizzling of some higher address bits > + * into bit6. > + * > + * This format is highly platforms specific and not useful for cross-driver > + * sharing. It exists since on a given platform it does uniquely identify the > + * layout in a simple way for i915-specific userspace. > + */ > +#define I915_FORMAT_MOD_Y_TILED fourcc_mod_code(INTEL, 2) > + > +/* > + * Intel Yf-tiling layout > + * > + * This is a tiled layout using 4Kb tiles in row-major layout. > + * Within the tile pixels are laid out in 16 256 byte units / sub-tiles which > + * are arranged in four groups (two wide, two high) with column-major layout. > + * Each group therefore consits out of four 256 byte units, which are also laid > + * out as 2x2 column-major. > + * 256 byte units are made out of four 64 byte blocks of pixels, producing > + * either a square block or a 2:1 unit. > + * 64 byte blocks of pixels contain four pixel rows of 16 bytes, where the width > + * in pixel depends on the pixel depth. > + */ > +#define I915_FORMAT_MOD_Yf_TILED fourcc_mod_code(INTEL, 3) > + > +/* > + * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks > + * > + * Macroblocks are laid in a Z-shape, and each pixel data is following the > + * standard NV12 style. > + * As for NV12, an image is the result of two frame buffers: one for Y, > + * one for the interleaved Cb/Cr components (1/2 the height of the Y buffer). > + * Alignment requirements are (for each buffer): > + * - multiple of 128 pixels for the width > + * - multiple of 32 pixels for the height > + * > + * For more information: see http://linuxtv.org/downloads/v4l-dvb-apis/re32.html > + */ > +#define DRM_FORMAT_MOD_SAMSUNG_64_32_TILE fourcc_mod_code(SAMSUNG, 1) > + > #endif /* DRM_FOURCC_H */ > diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h > index 69c1ac3cf00c..115f36e452d9 100644 > --- a/include/drm/drm_mode.h > +++ b/include/drm/drm_mode.h > @@ -322,7 +322,8 @@ struct drm_mode_fb_cmd { > __u32 handle; > }; > > -#define DRM_MODE_FB_INTERLACED (1<<0) /* for interlaced framebuffers */ > +#define DRM_MODE_FB_INTERLACED (1<<0) /* for interlaced framebuffers */ > +#define DRM_MODE_FB_MODIFIERS (1<<1) /* enables ->modifer[] */ > > struct drm_mode_fb_cmd2 { > __u32 fb_id; > @@ -343,10 +344,18 @@ struct drm_mode_fb_cmd2 { > * So it would consist of Y as offset[0] and UV as > * offset[1]. Note that offset[0] will generally > * be 0. > + * > + * To accommodate tiled, compressed, etc formats, a per-plane > + * modifier can be specified. The default value of zero > + * indicates "native" format as specified by the fourcc. > + * Vendor specific modifier token. This allows, for example, > + * different tiling/swizzling pattern on different planes. > + * See discussion above of DRM_FORMAT_MOD_xxx. > */ > __u32 handles[4]; > __u32 pitches[4]; /* pitch for each plane */ > __u32 offsets[4]; /* offset of each plane */ > + __u64 modifier[4]; /* ie, tiling, compressed (per plane) */ > }; > > #define DRM_MODE_FB_DIRTY_ANNOTATE_COPY 0x01 >
diff --git a/include/drm/drm.h b/include/drm/drm.h index 167b7b81b0d0..a950b580cd11 100644 --- a/include/drm/drm.h +++ b/include/drm/drm.h @@ -816,6 +816,7 @@ struct drm_event_vblank { #define DRM_CAP_PRIME 0x5 #define DRM_CAP_TIMESTAMP_MONOTONIC 0x6 #define DRM_CAP_ASYNC_PAGE_FLIP 0x7 +#define DRM_CAP_ADDFB2_MODIFIERS 0x10 #define DRM_PRIME_CAP_IMPORT 0x1 #define DRM_PRIME_CAP_EXPORT 0x2 diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h index 85facb0a17cf..63a80ca5ba39 100644 --- a/include/drm/drm_fourcc.h +++ b/include/drm/drm_fourcc.h @@ -127,4 +127,97 @@ #define DRM_FORMAT_YUV444 fourcc_code('Y', 'U', '2', '4') /* non-subsampled Cb (1) and Cr (2) planes */ #define DRM_FORMAT_YVU444 fourcc_code('Y', 'V', '2', '4') /* non-subsampled Cr (1) and Cb (2) planes */ + +/* + * Format Modifiers: + * + * Format modifiers describe, typically, a re-ordering or modification + * of the data in a plane of an FB. This can be used to express tiled/ + * swizzled formats, or compression, or a combination of the two. + * + * The upper 8 bits of the format modifier are a vendor-id as assigned + * below. The lower 56 bits are assigned as vendor sees fit. + */ + +/* Vendor Ids: */ +#define DRM_FORMAT_MOD_NONE 0 +#define DRM_FORMAT_MOD_VENDOR_INTEL 0x01 +#define DRM_FORMAT_MOD_VENDOR_AMD 0x02 +#define DRM_FORMAT_MOD_VENDOR_NV 0x03 +#define DRM_FORMAT_MOD_VENDOR_SAMSUNG 0x04 +#define DRM_FORMAT_MOD_VENDOR_QCOM 0x05 +/* add more to the end as needed */ + +#define fourcc_mod_code(vendor, val) \ + ((((u64)DRM_FORMAT_MOD_VENDOR_## vendor) << 56) | (val & 0x00ffffffffffffffULL)) + +/* + * Format Modifier tokens: + * + * When adding a new token please document the layout with a code comment, + * similar to the fourcc codes above. drm_fourcc.h is considered the + * authoritative source for all of these. + */ + +/* Intel framebuffer modifiers */ + +/* + * Intel X-tiling layout + * + * This is a tiled layout using 4Kb tiles (except on gen2 where the tiles 2Kb) + * in row-major layout. Within the tile bytes are laid out row-major, with + * a platform-dependent stride. On top of that the memory can apply + * platform-depending swizzling of some higher address bits into bit6. + * + * This format is highly platforms specific and not useful for cross-driver + * sharing. It exists since on a given platform it does uniquely identify the + * layout in a simple way for i915-specific userspace. + */ +#define I915_FORMAT_MOD_X_TILED fourcc_mod_code(INTEL, 1) + +/* + * Intel Y-tiling layout + * + * This is a tiled layout using 4Kb tiles (except on gen2 where the tiles 2Kb) + * in row-major layout. Within the tile bytes are laid out in OWORD (16 bytes) + * chunks column-major, with a platform-dependent height. On top of that the + * memory can apply platform-depending swizzling of some higher address bits + * into bit6. + * + * This format is highly platforms specific and not useful for cross-driver + * sharing. It exists since on a given platform it does uniquely identify the + * layout in a simple way for i915-specific userspace. + */ +#define I915_FORMAT_MOD_Y_TILED fourcc_mod_code(INTEL, 2) + +/* + * Intel Yf-tiling layout + * + * This is a tiled layout using 4Kb tiles in row-major layout. + * Within the tile pixels are laid out in 16 256 byte units / sub-tiles which + * are arranged in four groups (two wide, two high) with column-major layout. + * Each group therefore consits out of four 256 byte units, which are also laid + * out as 2x2 column-major. + * 256 byte units are made out of four 64 byte blocks of pixels, producing + * either a square block or a 2:1 unit. + * 64 byte blocks of pixels contain four pixel rows of 16 bytes, where the width + * in pixel depends on the pixel depth. + */ +#define I915_FORMAT_MOD_Yf_TILED fourcc_mod_code(INTEL, 3) + +/* + * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks + * + * Macroblocks are laid in a Z-shape, and each pixel data is following the + * standard NV12 style. + * As for NV12, an image is the result of two frame buffers: one for Y, + * one for the interleaved Cb/Cr components (1/2 the height of the Y buffer). + * Alignment requirements are (for each buffer): + * - multiple of 128 pixels for the width + * - multiple of 32 pixels for the height + * + * For more information: see http://linuxtv.org/downloads/v4l-dvb-apis/re32.html + */ +#define DRM_FORMAT_MOD_SAMSUNG_64_32_TILE fourcc_mod_code(SAMSUNG, 1) + #endif /* DRM_FOURCC_H */ diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h index 69c1ac3cf00c..115f36e452d9 100644 --- a/include/drm/drm_mode.h +++ b/include/drm/drm_mode.h @@ -322,7 +322,8 @@ struct drm_mode_fb_cmd { __u32 handle; }; -#define DRM_MODE_FB_INTERLACED (1<<0) /* for interlaced framebuffers */ +#define DRM_MODE_FB_INTERLACED (1<<0) /* for interlaced framebuffers */ +#define DRM_MODE_FB_MODIFIERS (1<<1) /* enables ->modifer[] */ struct drm_mode_fb_cmd2 { __u32 fb_id; @@ -343,10 +344,18 @@ struct drm_mode_fb_cmd2 { * So it would consist of Y as offset[0] and UV as * offset[1]. Note that offset[0] will generally * be 0. + * + * To accommodate tiled, compressed, etc formats, a per-plane + * modifier can be specified. The default value of zero + * indicates "native" format as specified by the fourcc. + * Vendor specific modifier token. This allows, for example, + * different tiling/swizzling pattern on different planes. + * See discussion above of DRM_FORMAT_MOD_xxx. */ __u32 handles[4]; __u32 pitches[4]; /* pitch for each plane */ __u32 offsets[4]; /* offset of each plane */ + __u64 modifier[4]; /* ie, tiling, compressed (per plane) */ }; #define DRM_MODE_FB_DIRTY_ANNOTATE_COPY 0x01