Commit ff14d06b authored by Vivek Kasireddy's avatar Vivek Kasireddy Committed by Lionel Landwerlin

drm-uapi: Update headers from drm-next

Pull new updates from drm-next as of the following commit:

commit a5f2fafece141ef3509e686cea576366d55cabb6
Merge: 71f4e45a4ed3 860433ed2a55
Author: Dave Airlie <airlied@redhat.com>
Date:   Wed Feb 20 12:16:30 2019 +1000

    Merge https://gitlab.freedesktop.org/drm/msm into drm-next
Signed-off-by: 's avatarVivek Kasireddy <vivek.kasireddy@intel.com>
Reviewed-by: 's avatarLionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: 's avatarTapani Pälli <tapani.palli@intel.com>
Reviewed-by: 's avatarEric Engestrom <eric.engestrom@intel.com>
parent 78fb3fd1
......@@ -13,9 +13,9 @@ $ make headers_install INSTALL_HDR_PATH=/path/to/install
The last update was done at the following kernel commit :
commit 78230c46ec0a91dd4256c9e54934b3c7095a7ee3
Merge: b65bd4031156 037f03155b7d
commit a5f2fafece141ef3509e686cea576366d55cabb6
Merge: 71f4e45a4ed3 860433ed2a55
Author: Dave Airlie <airlied@redhat.com>
Date: Wed Mar 21 14:07:03 2018 +1000
Date: Wed Feb 20 12:16:30 2019 +1000
Merge tag 'omapdrm-4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux into drm-next
Merge https://gitlab.freedesktop.org/drm/msm into drm-next
......@@ -674,6 +674,22 @@ struct drm_get_cap {
*/
#define DRM_CLIENT_CAP_ATOMIC 3
/**
* DRM_CLIENT_CAP_ASPECT_RATIO
*
* If set to 1, the DRM core will provide aspect ratio information in modes.
*/
#define DRM_CLIENT_CAP_ASPECT_RATIO 4
/**
* DRM_CLIENT_CAP_WRITEBACK_CONNECTORS
*
* If set to 1, the DRM core will expose special connectors to be used for
* writing back to memory the scene setup in the commit. Depends on client
* also supporting DRM_CLIENT_CAP_ATOMIC
*/
#define DRM_CLIENT_CAP_WRITEBACK_CONNECTORS 5
/** DRM_IOCTL_SET_CLIENT_CAP ioctl argument type */
struct drm_set_client_cap {
__u64 capability;
......
......@@ -30,11 +30,50 @@
extern "C" {
#endif
/**
* DOC: overview
*
* In the DRM subsystem, framebuffer pixel formats are described using the
* fourcc codes defined in `include/uapi/drm/drm_fourcc.h`. In addition to the
* fourcc code, a Format Modifier may optionally be provided, in order to
* further describe the buffer's format - for example tiling or compression.
*
* Format Modifiers
* ----------------
*
* Format modifiers are used in conjunction with a fourcc code, forming a
* unique fourcc:modifier pair. This format:modifier pair must fully define the
* format and data layout of the buffer, and should be the only way to describe
* that particular buffer.
*
* Having multiple fourcc:modifier pairs which describe the same layout should
* be avoided, as such aliases run the risk of different drivers exposing
* different names for the same data format, forcing userspace to understand
* that they are aliases.
*
* Format modifiers may change any property of the buffer, including the number
* of planes and/or the required allocation size. Format modifiers are
* vendor-namespaced, and as such the relationship between a fourcc code and a
* modifier is specific to the modifer being used. For example, some modifiers
* may preserve meaning - such as number of planes - from the fourcc code,
* whereas others may not.
*
* Vendors should document their modifier usage in as much detail as
* possible, to ensure maximum compatibility across devices, drivers and
* applications.
*
* The authoritative list of format modifier codes is found in
* `include/uapi/drm/drm_fourcc.h`
*/
#define fourcc_code(a, b, c, d) ((__u32)(a) | ((__u32)(b) << 8) | \
((__u32)(c) << 16) | ((__u32)(d) << 24))
#define DRM_FORMAT_BIG_ENDIAN (1<<31) /* format is big endian instead of little endian */
/* Reserve 0 for the invalid format specifier */
#define DRM_FORMAT_INVALID 0
/* color index */
#define DRM_FORMAT_C8 fourcc_code('C', '8', ' ', ' ') /* [7:0] C */
......@@ -112,6 +151,21 @@ extern "C" {
#define DRM_FORMAT_VYUY fourcc_code('V', 'Y', 'U', 'Y') /* [31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian */
#define DRM_FORMAT_AYUV fourcc_code('A', 'Y', 'U', 'V') /* [31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
#define DRM_FORMAT_XYUV8888 fourcc_code('X', 'Y', 'U', 'V') /* [31:0] X:Y:Cb:Cr 8:8:8:8 little endian */
/*
* packed YCbCr420 2x2 tiled formats
* first 64 bits will contain Y,Cb,Cr components for a 2x2 tile
*/
/* [63:0] A3:A2:Y3:0:Cr0:0:Y2:0:A1:A0:Y1:0:Cb0:0:Y0:0 1:1:8:2:8:2:8:2:1:1:8:2:8:2:8:2 little endian */
#define DRM_FORMAT_Y0L0 fourcc_code('Y', '0', 'L', '0')
/* [63:0] X3:X2:Y3:0:Cr0:0:Y2:0:X1:X0:Y1:0:Cb0:0:Y0:0 1:1:8:2:8:2:8:2:1:1:8:2:8:2:8:2 little endian */
#define DRM_FORMAT_X0L0 fourcc_code('X', '0', 'L', '0')
/* [63:0] A3:A2:Y3:Cr0:Y2:A1:A0:Y1:Cb0:Y0 1:1:10:10:10:1:1:10:10:10 little endian */
#define DRM_FORMAT_Y0L2 fourcc_code('Y', '0', 'L', '2')
/* [63:0] X3:X2:Y3:Cr0:Y2:X1:X0:Y1:Cb0:Y0 1:1:10:10:10:1:1:10:10:10 little endian */
#define DRM_FORMAT_X0L2 fourcc_code('X', '0', 'L', '2')
/*
* 2 plane RGB + A
......@@ -141,6 +195,27 @@ extern "C" {
#define DRM_FORMAT_NV24 fourcc_code('N', 'V', '2', '4') /* non-subsampled Cr:Cb plane */
#define DRM_FORMAT_NV42 fourcc_code('N', 'V', '4', '2') /* non-subsampled Cb:Cr plane */
/*
* 2 plane YCbCr MSB aligned
* index 0 = Y plane, [15:0] Y:x [10:6] little endian
* index 1 = Cr:Cb plane, [31:0] Cr:x:Cb:x [10:6:10:6] little endian
*/
#define DRM_FORMAT_P010 fourcc_code('P', '0', '1', '0') /* 2x2 subsampled Cr:Cb plane 10 bits per channel */
/*
* 2 plane YCbCr MSB aligned
* index 0 = Y plane, [15:0] Y:x [12:4] little endian
* index 1 = Cr:Cb plane, [31:0] Cr:x:Cb:x [12:4:12:4] little endian
*/
#define DRM_FORMAT_P012 fourcc_code('P', '0', '1', '2') /* 2x2 subsampled Cr:Cb plane 12 bits per channel */
/*
* 2 plane YCbCr MSB aligned
* index 0 = Y plane, [15:0] Y little endian
* index 1 = Cr:Cb plane, [31:0] Cr:Cb [16:16] little endian
*/
#define DRM_FORMAT_P016 fourcc_code('P', '0', '1', '6') /* 2x2 subsampled Cr:Cb plane 16 bits per channel */
/*
* 3 plane YCbCr
* index 0: Y plane, [7:0] Y
......@@ -183,6 +258,9 @@ extern "C" {
#define DRM_FORMAT_MOD_VENDOR_QCOM 0x05
#define DRM_FORMAT_MOD_VENDOR_VIVANTE 0x06
#define DRM_FORMAT_MOD_VENDOR_BROADCOM 0x07
#define DRM_FORMAT_MOD_VENDOR_ARM 0x08
#define DRM_FORMAT_MOD_VENDOR_ALLWINNER 0x09
/* add more to the end as needed */
#define DRM_FORMAT_RESERVED ((1ULL << 56) - 1)
......@@ -298,6 +376,15 @@ extern "C" {
*/
#define DRM_FORMAT_MOD_SAMSUNG_64_32_TILE fourcc_mod_code(SAMSUNG, 1)
/*
* Tiled, 16 (pixels) x 16 (lines) - sized macroblocks
*
* This is a simple tiled layout using tiles of 16x16 pixels in a row-major
* layout. For YCbCr formats Cb/Cr components are taken in such a way that
* they correspond to their 16x16 luma block.
*/
#define DRM_FORMAT_MOD_SAMSUNG_16_16_TILE fourcc_mod_code(SAMSUNG, 2)
/*
* Qualcomm Compressed Format
*
......@@ -309,7 +396,7 @@ extern "C" {
* Pixel data height is aligned with macrotile height.
* Entire pixel data buffer is aligned with 4k(bytes).
*/
#define DRM_FORMAT_MOD_QCOM_COMPRESSED fourcc_mod_code(QCOM, 1)
#define DRM_FORMAT_MOD_QCOM_COMPRESSED fourcc_mod_code(QCOM, 1)
/* Vivante framebuffer modifiers */
......@@ -498,6 +585,128 @@ extern "C" {
*/
#define DRM_FORMAT_MOD_BROADCOM_UIF fourcc_mod_code(BROADCOM, 6)
/*
* Arm Framebuffer Compression (AFBC) modifiers
*
* AFBC is a proprietary lossless image compression protocol and format.
* It provides fine-grained random access and minimizes the amount of data
* transferred between IP blocks.
*
* AFBC has several features which may be supported and/or used, which are
* represented using bits in the modifier. Not all combinations are valid,
* and different devices or use-cases may support different combinations.
*
* Further information on the use of AFBC modifiers can be found in
* Documentation/gpu/afbc.rst
*/
#define DRM_FORMAT_MOD_ARM_AFBC(__afbc_mode) fourcc_mod_code(ARM, __afbc_mode)
/*
* AFBC superblock size
*
* Indicates the superblock size(s) used for the AFBC buffer. The buffer
* size (in pixels) must be aligned to a multiple of the superblock size.
* Four lowest significant bits(LSBs) are reserved for block size.
*
* Where one superblock size is specified, it applies to all planes of the
* buffer (e.g. 16x16, 32x8). When multiple superblock sizes are specified,
* the first applies to the Luma plane and the second applies to the Chroma
* plane(s). e.g. (32x8_64x4 means 32x8 Luma, with 64x4 Chroma).
* Multiple superblock sizes are only valid for multi-plane YCbCr formats.
*/
#define AFBC_FORMAT_MOD_BLOCK_SIZE_MASK 0xf
#define AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 (1ULL)
#define AFBC_FORMAT_MOD_BLOCK_SIZE_32x8 (2ULL)
#define AFBC_FORMAT_MOD_BLOCK_SIZE_64x4 (3ULL)
#define AFBC_FORMAT_MOD_BLOCK_SIZE_32x8_64x4 (4ULL)
/*
* AFBC lossless colorspace transform
*
* Indicates that the buffer makes use of the AFBC lossless colorspace
* transform.
*/
#define AFBC_FORMAT_MOD_YTR (1ULL << 4)
/*
* AFBC block-split
*
* Indicates that the payload of each superblock is split. The second
* half of the payload is positioned at a predefined offset from the start
* of the superblock payload.
*/
#define AFBC_FORMAT_MOD_SPLIT (1ULL << 5)
/*
* AFBC sparse layout
*
* This flag indicates that the payload of each superblock must be stored at a
* predefined position relative to the other superblocks in the same AFBC
* buffer. This order is the same order used by the header buffer. In this mode
* each superblock is given the same amount of space as an uncompressed
* superblock of the particular format would require, rounding up to the next
* multiple of 128 bytes in size.
*/
#define AFBC_FORMAT_MOD_SPARSE (1ULL << 6)
/*
* AFBC copy-block restrict
*
* Buffers with this flag must obey the copy-block restriction. The restriction
* is such that there are no copy-blocks referring across the border of 8x8
* blocks. For the subsampled data the 8x8 limitation is also subsampled.
*/
#define AFBC_FORMAT_MOD_CBR (1ULL << 7)
/*
* AFBC tiled layout
*
* The tiled layout groups superblocks in 8x8 or 4x4 tiles, where all
* superblocks inside a tile are stored together in memory. 8x8 tiles are used
* for pixel formats up to and including 32 bpp while 4x4 tiles are used for
* larger bpp formats. The order between the tiles is scan line.
* When the tiled layout is used, the buffer size (in pixels) must be aligned
* to the tile size.
*/
#define AFBC_FORMAT_MOD_TILED (1ULL << 8)
/*
* AFBC solid color blocks
*
* Indicates that the buffer makes use of solid-color blocks, whereby bandwidth
* can be reduced if a whole superblock is a single color.
*/
#define AFBC_FORMAT_MOD_SC (1ULL << 9)
/*
* AFBC double-buffer
*
* Indicates that the buffer is allocated in a layout safe for front-buffer
* rendering.
*/
#define AFBC_FORMAT_MOD_DB (1ULL << 10)
/*
* AFBC buffer content hints
*
* Indicates that the buffer includes per-superblock content hints.
*/
#define AFBC_FORMAT_MOD_BCH (1ULL << 11)
/*
* Allwinner tiled modifier
*
* This tiling mode is implemented by the VPU found on all Allwinner platforms,
* codenamed sunxi. It is associated with a YUV format that uses either 2 or 3
* planes.
*
* With this tiling, the luminance samples are disposed in tiles representing
* 32x32 pixels and the chrominance samples in tiles representing 32x64 pixels.
* The pixel order in each tile is linear and the tiles are disposed linearly,
* both in row-major order.
*/
#define DRM_FORMAT_MOD_ALLWINNER_TILED fourcc_mod_code(ALLWINNER, 1)
#if defined(__cplusplus)
}
#endif
......
......@@ -93,6 +93,15 @@ extern "C" {
#define DRM_MODE_PICTURE_ASPECT_NONE 0
#define DRM_MODE_PICTURE_ASPECT_4_3 1
#define DRM_MODE_PICTURE_ASPECT_16_9 2
#define DRM_MODE_PICTURE_ASPECT_64_27 3
#define DRM_MODE_PICTURE_ASPECT_256_135 4
/* Content type options */
#define DRM_MODE_CONTENT_TYPE_NO_DATA 0
#define DRM_MODE_CONTENT_TYPE_GRAPHICS 1
#define DRM_MODE_CONTENT_TYPE_PHOTO 2
#define DRM_MODE_CONTENT_TYPE_CINEMA 3
#define DRM_MODE_CONTENT_TYPE_GAME 4
/* Aspect ratio flag bitmask (4 bits 22:19) */
#define DRM_MODE_FLAG_PIC_AR_MASK (0x0F<<19)
......@@ -102,6 +111,10 @@ extern "C" {
(DRM_MODE_PICTURE_ASPECT_4_3<<19)
#define DRM_MODE_FLAG_PIC_AR_16_9 \
(DRM_MODE_PICTURE_ASPECT_16_9<<19)
#define DRM_MODE_FLAG_PIC_AR_64_27 \
(DRM_MODE_PICTURE_ASPECT_64_27<<19)
#define DRM_MODE_FLAG_PIC_AR_256_135 \
(DRM_MODE_PICTURE_ASPECT_256_135<<19)
#define DRM_MODE_FLAG_ALL (DRM_MODE_FLAG_PHSYNC | \
DRM_MODE_FLAG_NHSYNC | \
......@@ -173,8 +186,9 @@ extern "C" {
/*
* DRM_MODE_REFLECT_<axis>
*
* Signals that the contents of a drm plane is reflected in the <axis> axis,
* Signals that the contents of a drm plane is reflected along the <axis> axis,
* in the same way as mirroring.
* See kerneldoc chapter "Plane Composition Properties" for more details.
*
* This define is provided as a convenience, looking up the property id
* using the name->prop id lookup is the preferred method.
......@@ -338,6 +352,7 @@ enum drm_mode_subconnector {
#define DRM_MODE_CONNECTOR_VIRTUAL 15
#define DRM_MODE_CONNECTOR_DSI 16
#define DRM_MODE_CONNECTOR_DPI 17
#define DRM_MODE_CONNECTOR_WRITEBACK 18
struct drm_mode_get_connector {
......@@ -873,6 +888,25 @@ struct drm_mode_revoke_lease {
__u32 lessee_id;
};
/**
* struct drm_mode_rect - Two dimensional rectangle.
* @x1: Horizontal starting coordinate (inclusive).
* @y1: Vertical starting coordinate (inclusive).
* @x2: Horizontal ending coordinate (exclusive).
* @y2: Vertical ending coordinate (exclusive).
*
* With drm subsystem using struct drm_rect to manage rectangular area this
* export it to user-space.
*
* Currently used by drm_mode_atomic blob property FB_DAMAGE_CLIPS.
*/
struct drm_mode_rect {
__s32 x1;
__s32 y1;
__s32 x2;
__s32 y2;
};
#if defined(__cplusplus)
}
#endif
......
......@@ -412,6 +412,14 @@ typedef struct drm_i915_irq_wait {
int irq_seq;
} drm_i915_irq_wait_t;
/*
* Different modes of per-process Graphics Translation Table,
* see I915_PARAM_HAS_ALIASING_PPGTT
*/
#define I915_GEM_PPGTT_NONE 0
#define I915_GEM_PPGTT_ALIASING 1
#define I915_GEM_PPGTT_FULL 2
/* Ioctl to query kernel params:
*/
#define I915_PARAM_IRQ_ACTIVE 1
......@@ -529,6 +537,28 @@ typedef struct drm_i915_irq_wait {
*/
#define I915_PARAM_CS_TIMESTAMP_FREQUENCY 51
/*
* Once upon a time we supposed that writes through the GGTT would be
* immediately in physical memory (once flushed out of the CPU path). However,
* on a few different processors and chipsets, this is not necessarily the case
* as the writes appear to be buffered internally. Thus a read of the backing
* storage (physical memory) via a different path (with different physical tags
* to the indirect write via the GGTT) will see stale values from before
* the GGTT write. Inside the kernel, we can for the most part keep track of
* the different read/write domains in use (e.g. set-domain), but the assumption
* of coherency is baked into the ABI, hence reporting its true state in this
* parameter.
*
* Reports true when writes via mmap_gtt are immediately visible following an
* lfence to flush the WCB.
*
* Reports false when writes via mmap_gtt are indeterminately delayed in an in
* internal buffer and are _not_ immediately visible to third parties accessing
* directly via mmap_cpu/mmap_wc. Use of mmap_gtt as part of an IPC
* communications channel when reporting false is strongly disadvised.
*/
#define I915_PARAM_MMAP_GTT_COHERENT 52
typedef struct drm_i915_getparam {
__s32 param;
/*
......@@ -1456,9 +1486,73 @@ struct drm_i915_gem_context_param {
#define I915_CONTEXT_MAX_USER_PRIORITY 1023 /* inclusive */
#define I915_CONTEXT_DEFAULT_PRIORITY 0
#define I915_CONTEXT_MIN_USER_PRIORITY -1023 /* inclusive */
/*
* When using the following param, value should be a pointer to
* drm_i915_gem_context_param_sseu.
*/
#define I915_CONTEXT_PARAM_SSEU 0x7
__u64 value;
};
/**
* Context SSEU programming
*
* It may be necessary for either functional or performance reason to configure
* a context to run with a reduced number of SSEU (where SSEU stands for Slice/
* Sub-slice/EU).
*
* This is done by configuring SSEU configuration using the below
* @struct drm_i915_gem_context_param_sseu for every supported engine which
* userspace intends to use.
*
* Not all GPUs or engines support this functionality in which case an error
* code -ENODEV will be returned.
*
* Also, flexibility of possible SSEU configuration permutations varies between
* GPU generations and software imposed limitations. Requesting such a
* combination will return an error code of -EINVAL.
*
* NOTE: When perf/OA is active the context's SSEU configuration is ignored in
* favour of a single global setting.
*/
struct drm_i915_gem_context_param_sseu {
/*
* Engine class & instance to be configured or queried.
*/
__u16 engine_class;
__u16 engine_instance;
/*
* Unused for now. Must be cleared to zero.
*/
__u32 flags;
/*
* Mask of slices to enable for the context. Valid values are a subset
* of the bitmask value returned for I915_PARAM_SLICE_MASK.
*/
__u64 slice_mask;
/*
* Mask of subslices to enable for the context. Valid values are a
* subset of the bitmask value return by I915_PARAM_SUBSLICE_MASK.
*/
__u64 subslice_mask;
/*
* Minimum/Maximum number of EUs to enable per subslice for the
* context. min_eus_per_subslice must be inferior or equal to
* max_eus_per_subslice.
*/
__u16 min_eus_per_subslice;
__u16 max_eus_per_subslice;
/*
* Unused for now. Must be cleared to zero.
*/
__u32 rsvd;
};
enum drm_i915_oa_format {
I915_OA_FORMAT_A13 = 1, /* HSW only */
I915_OA_FORMAT_A29, /* HSW only */
......
This diff is collapsed.
......@@ -52,6 +52,14 @@ extern "C" {
*
* This asks the kernel to have the GPU execute an optional binner
* command list, and a render command list.
*
* The L1T, slice, L2C, L2T, and GCA caches will be flushed before
* each CL executes. The VCD cache should be flushed (if necessary)
* by the submitted CLs. The TLB writes are guaranteed to have been
* flushed by the time the render done IRQ happens, which is the
* trigger for out_sync. Any dirtying of cachelines by the job (only
* possible using TMU writes) must be flushed by the caller using the
* CL's cache flush commands.
*/
struct drm_v3d_submit_cl {
/* Pointer to the binner command list.
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment