linux-kernel - Re: [PATCH 1/4] drm/arm/malidp: Add modifier definitions for describing Arm Framebuffer Compression (AFBC).

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 9 Jul 2018 15:15:45 +0200
From:   Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>
To:     Ayan Kumar Halder <ayan.halder@....com>, gustavo@...ovan.org,
        seanpaul@...omium.org, airlied@...ux.ie,
        dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Cc:     nd@....com, Rosen Zhelev <rosen.zhelev@....com>
Subject: Re: [PATCH 1/4] drm/arm/malidp: Add modifier definitions for
 describing Arm Framebuffer Compression (AFBC).

Op 06-07-18 om 11:16 schreef Ayan Kumar Halder:
> 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.
>
> Signed-off-by: Rosen Zhelev <rosen.zhelev@....com>
> Signed-off-by: Ayan Kumar halder <ayan.halder@....com>
> Reviewed-by: Brian Starkey <brian.starkey@....com>
> Reviewed-by: Liviu Dudau <liviu.dudau@....com>
> Reviewed-by: James (Qian) Wang <james.qian.wang@....com>
> ---
>  include/uapi/drm/drm_fourcc.h | 83 +++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 83 insertions(+)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index e04613d..af7e9ab 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -183,6 +183,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)
> @@ -405,6 +406,88 @@ extern "C" {
>   */
>  #define DRM_FORMAT_MOD_BROADCOM_VC4_T_TILED fourcc_mod_code(BROADCOM, 1)
Seems drm-misc-next now has a DRM_FORMAT_MOD_BROADCOM_UIF format extra, but that's just noise when applying. :)
> +/*
> + * 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

Acked-by: Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>

But I would put patch 2 last, since that enables the feature without hw support otherwise.