mirror of
https://github.com/Motorhead1991/qemu.git
synced 2025-08-05 08:43:55 -06:00
linux-headers: update
Update to Linux upstream commit 2ad0d5269970 ("Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net") Signed-off-by: Cornelia Huck <cohuck@redhat.com>
This commit is contained in:
parent
c61177881c
commit
d36f7de829
15 changed files with 284 additions and 17 deletions
|
@ -182,6 +182,7 @@ 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
|
||||
/* add more to the end as needed */
|
||||
|
||||
#define DRM_FORMAT_RESERVED ((1ULL << 56) - 1)
|
||||
|
@ -297,6 +298,19 @@ extern "C" {
|
|||
*/
|
||||
#define DRM_FORMAT_MOD_SAMSUNG_64_32_TILE fourcc_mod_code(SAMSUNG, 1)
|
||||
|
||||
/*
|
||||
* Qualcomm Compressed Format
|
||||
*
|
||||
* Refers to a compressed variant of the base format that is compressed.
|
||||
* Implementation may be platform and base-format specific.
|
||||
*
|
||||
* Each macrotile consists of m x n (mostly 4 x 4) tiles.
|
||||
* Pixel data pitch/stride is aligned with macrotile width.
|
||||
* 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)
|
||||
|
||||
/* Vivante framebuffer modifiers */
|
||||
|
||||
/*
|
||||
|
@ -383,6 +397,23 @@ extern "C" {
|
|||
#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_THIRTYTWO_GOB \
|
||||
fourcc_mod_code(NVIDIA, 0x15)
|
||||
|
||||
/*
|
||||
* Some Broadcom modifiers take parameters, for example the number of
|
||||
* vertical lines in the image. Reserve the lower 32 bits for modifier
|
||||
* type, and the next 24 bits for parameters. Top 8 bits are the
|
||||
* vendor code.
|
||||
*/
|
||||
#define __fourcc_mod_broadcom_param_shift 8
|
||||
#define __fourcc_mod_broadcom_param_bits 48
|
||||
#define fourcc_mod_broadcom_code(val, params) \
|
||||
fourcc_mod_code(BROADCOM, ((((uint64_t)params) << __fourcc_mod_broadcom_param_shift) | val))
|
||||
#define fourcc_mod_broadcom_param(m) \
|
||||
((int)(((m) >> __fourcc_mod_broadcom_param_shift) & \
|
||||
((1ULL << __fourcc_mod_broadcom_param_bits) - 1)))
|
||||
#define fourcc_mod_broadcom_mod(m) \
|
||||
((m) & ~(((1ULL << __fourcc_mod_broadcom_param_bits) - 1) << \
|
||||
__fourcc_mod_broadcom_param_shift))
|
||||
|
||||
/*
|
||||
* Broadcom VC4 "T" format
|
||||
*
|
||||
|
@ -404,6 +435,151 @@ extern "C" {
|
|||
*/
|
||||
#define DRM_FORMAT_MOD_BROADCOM_VC4_T_TILED fourcc_mod_code(BROADCOM, 1)
|
||||
|
||||
/*
|
||||
* Broadcom SAND format
|
||||
*
|
||||
* This is the native format that the H.264 codec block uses. For VC4
|
||||
* HVS, it is only valid for H.264 (NV12/21) and RGBA modes.
|
||||
*
|
||||
* The image can be considered to be split into columns, and the
|
||||
* columns are placed consecutively into memory. The width of those
|
||||
* columns can be either 32, 64, 128, or 256 pixels, but in practice
|
||||
* only 128 pixel columns are used.
|
||||
*
|
||||
* The pitch between the start of each column is set to optimally
|
||||
* switch between SDRAM banks. This is passed as the number of lines
|
||||
* of column width in the modifier (we can't use the stride value due
|
||||
* to various core checks that look at it , so you should set the
|
||||
* stride to width*cpp).
|
||||
*
|
||||
* Note that the column height for this format modifier is the same
|
||||
* for all of the planes, assuming that each column contains both Y
|
||||
* and UV. Some SAND-using hardware stores UV in a separate tiled
|
||||
* image from Y to reduce the column height, which is not supported
|
||||
* with these modifiers.
|
||||
*/
|
||||
|
||||
#define DRM_FORMAT_MOD_BROADCOM_SAND32_COL_HEIGHT(v) \
|
||||
fourcc_mod_broadcom_code(2, v)
|
||||
#define DRM_FORMAT_MOD_BROADCOM_SAND64_COL_HEIGHT(v) \
|
||||
fourcc_mod_broadcom_code(3, v)
|
||||
#define DRM_FORMAT_MOD_BROADCOM_SAND128_COL_HEIGHT(v) \
|
||||
fourcc_mod_broadcom_code(4, v)
|
||||
#define DRM_FORMAT_MOD_BROADCOM_SAND256_COL_HEIGHT(v) \
|
||||
fourcc_mod_broadcom_code(5, v)
|
||||
|
||||
#define DRM_FORMAT_MOD_BROADCOM_SAND32 \
|
||||
DRM_FORMAT_MOD_BROADCOM_SAND32_COL_HEIGHT(0)
|
||||
#define DRM_FORMAT_MOD_BROADCOM_SAND64 \
|
||||
DRM_FORMAT_MOD_BROADCOM_SAND64_COL_HEIGHT(0)
|
||||
#define DRM_FORMAT_MOD_BROADCOM_SAND128 \
|
||||
DRM_FORMAT_MOD_BROADCOM_SAND128_COL_HEIGHT(0)
|
||||
#define DRM_FORMAT_MOD_BROADCOM_SAND256 \
|
||||
DRM_FORMAT_MOD_BROADCOM_SAND256_COL_HEIGHT(0)
|
||||
|
||||
/* Broadcom UIF format
|
||||
*
|
||||
* This is the common format for the current Broadcom multimedia
|
||||
* blocks, including V3D 3.x and newer, newer video codecs, and
|
||||
* displays.
|
||||
*
|
||||
* The image consists of utiles (64b blocks), UIF blocks (2x2 utiles),
|
||||
* and macroblocks (4x4 UIF blocks). Those 4x4 UIF block groups are
|
||||
* stored in columns, with padding between the columns to ensure that
|
||||
* moving from one column to the next doesn't hit the same SDRAM page
|
||||
* bank.
|
||||
*
|
||||
* To calculate the padding, it is assumed that each hardware block
|
||||
* and the software driving it knows the platform's SDRAM page size,
|
||||
* number of banks, and XOR address, and that it's identical between
|
||||
* all blocks using the format. This tiling modifier will use XOR as
|
||||
* necessary to reduce the padding. If a hardware block can't do XOR,
|
||||
* the assumption is that a no-XOR tiling modifier will be created.
|
||||
*/
|
||||
#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.
|
||||
*/
|
||||
#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.
|
||||
*/
|
||||
#define AFBC_FORMAT_MOD_BLOCK_SIZE_MASK 0xf
|
||||
#define AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 (1ULL)
|
||||
#define AFBC_FORMAT_MOD_BLOCK_SIZE_32x8 (2ULL)
|
||||
|
||||
/*
|
||||
* 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)
|
||||
|
||||
#if defined(__cplusplus)
|
||||
}
|
||||
#endif
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue