Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80 |
|
#
6fb6c979 |
| 23-Nov-2022 |
Geert Uytterhoeven <geert@linux-m68k.org> |
drm/fourcc: Add missing big-endian XRGB1555 and RGB565 formats
As of commit eae06120f1974e1a ("drm: refuse ADDFB2 ioctl for broken bigendian drivers"), drivers must set the quirk_addfb_prefer_host_b
drm/fourcc: Add missing big-endian XRGB1555 and RGB565 formats
As of commit eae06120f1974e1a ("drm: refuse ADDFB2 ioctl for broken bigendian drivers"), drivers must set the quirk_addfb_prefer_host_byte_order quirk to make the drm_mode_addfb() compat code work correctly on big-endian machines.
While that works fine for big-endian XRGB8888 and ARGB8888, which are mapped to the existing little-endian BGRX8888 and BGRA8888 formats, it does not work for big-endian XRGB1555 and RGB565, as the latter are not listed in the format database.
Fix this by adding the missing formats. Limit this to big-endian platforms, as there is currently no need to support these formats on little-endian platforms.
Fixes: 6960e6da9cec3f66 ("drm: fix drm_mode_addfb() on big endian machines.") Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/3ee1f8144feb96c28742b22384189f1f83bcfc1a.1669221671.git.geert@linux-m68k.org
show more ...
|
Revision tags: v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68 |
|
#
b230555f |
| 13-Sep-2022 |
Brian Starkey <brian.starkey@arm.com> |
drm/fourcc: Fix vsub/hsub for Q410 and Q401
These formats are not subsampled, but that means hsub and vsub should be 1, not 0.
Fixes: 94b292b27734 ("drm: drm_fourcc: add NV15, Q410, Q401 YUV format
drm/fourcc: Fix vsub/hsub for Q410 and Q401
These formats are not subsampled, but that means hsub and vsub should be 1, not 0.
Fixes: 94b292b27734 ("drm: drm_fourcc: add NV15, Q410, Q401 YUV formats") Reported-by: George Kennedy <george.kennedy@oracle.com> Reported-by: butt3rflyh4ck <butterflyhuangxx@gmail.com> Signed-off-by: Brian Starkey <brian.starkey@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220913144306.17279-1-brian.starkey@arm.com
show more ...
|
Revision tags: v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54 |
|
#
b92db7e4 |
| 08-Jul-2022 |
Geert Uytterhoeven <geert@linux-m68k.org> |
drm/fourcc: Add DRM_FORMAT_D[1248]
As Rn covers single-channel formats with a direct relationship between channel value and brightness, and Cn can be any colors, there are currently no fourcc codes
drm/fourcc: Add DRM_FORMAT_D[1248]
As Rn covers single-channel formats with a direct relationship between channel value and brightness, and Cn can be any colors, there are currently no fourcc codes to describe single-channel formats with an inverse relationship between channel value and brightness.
Introduce fourcc codes for a single-channel frame buffer format with two, four, sixteen, or 256 brightness ("darkness") levels, where there is an inverse relationship between channel value and brightness.
As the number of bits per pixel may be less than eight, some of these formats rely on proper block handling for the calculation of bits per pixel and pitch.
The fill order (the order in which multiple pixels are packed in a byte) is the same order as used for grayscale (2, 4, and 16 levels) images in the PNG specification, Version 1.2. This order is also the recommended and default order (FillOrder = 1) for bilevel and grayscale (16 levels) images in the TIFF 6.0 Specification, and is also used for monochrome images in the PBM file format, monochrome Linux frame buffer logos, and BDF and PSF (Linux kernel) font files.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/6119f3abeda9baaa88652843960adc032da276b4.1657294931.git.geert@linux-m68k.org
show more ...
|
#
d093100b |
| 08-Jul-2022 |
Geert Uytterhoeven <geert@linux-m68k.org> |
drm/fourcc: Add DRM_FORMAT_R[124]
Introduce fourcc codes for single-channel frame buffer formats with two, four, and sixteen brightness levels, where there is a direct relationship between channel v
drm/fourcc: Add DRM_FORMAT_R[124]
Introduce fourcc codes for single-channel frame buffer formats with two, four, and sixteen brightness levels, where there is a direct relationship between channel value and brightness.
As the number of bits per pixel is less than eight, these rely on proper block handling for the calculation of bits per pixel and pitch.
The fill order (the order in which multiple pixels are packed in a byte) is the same order as used for grayscale (2, 4, and 16 levels) images in the PNG specification, Version 1.2. This order is also the recommended and default order (FillOrder = 1) for bilevel and grayscale (16 levels) images in the TIFF 6.0 Specification, and is also used for monochrome images in the PBM file format, monochrome Linux frame buffer logos, and BDF and PSF (Linux kernel) font files.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/96561a88e53c59cac72e66642bf4c097aacefd18.1657294931.git.geert@linux-m68k.org
show more ...
|
#
e5bd7e3e |
| 08-Jul-2022 |
Geert Uytterhoeven <geert@linux-m68k.org> |
drm/fourcc: Add DRM_FORMAT_C[124]
Introduce fourcc codes for color-indexed frame buffer formats with two, four, and sixteen colors, and provide a mapping from bits per pixel and depth to fourcc code
drm/fourcc: Add DRM_FORMAT_C[124]
Introduce fourcc codes for color-indexed frame buffer formats with two, four, and sixteen colors, and provide a mapping from bits per pixel and depth to fourcc codes.
As the number of bits per pixel is less than eight, these rely on proper block handling for the calculation of bits per pixel and pitch.
The fill order (the order in which multiple pixels are packed in a byte) is the same order as used for indexed-color (2, 4, and 16 colors) images in the PNG specification, Version 1.2. This order is also the recommended and default order (FillOrder = 1) for palette-color (16 colors) images in the TIFF 6.0 Specification, and is also used for 16-color Linux frame buffer logos.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/3d88ca7ad32ff3ff3469c10f0b36c312ea233a33.1657294931.git.geert@linux-m68k.org
show more ...
|
#
dc1dc76b |
| 08-Jul-2022 |
Geert Uytterhoeven <geert@linux-m68k.org> |
drm/fourcc: Add drm_format_info.is_color_indexed flag
Add a flag to struct drm_format_info to indicate if a format is color-indexed, similar to the existing .is_yuv flag.
This way generic code and
drm/fourcc: Add drm_format_info.is_color_indexed flag
Add a flag to struct drm_format_info to indicate if a format is color-indexed, similar to the existing .is_yuv flag.
This way generic code and drivers can just check this flag, instead of checking against a list of fourcc formats.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/90cd390b2b4d481661f966de7b504f1702d80dfd.1657294931.git.geert@linux-m68k.org
show more ...
|
#
96dc635d |
| 08-Jul-2022 |
Geert Uytterhoeven <geert@linux-m68k.org> |
drm/fourcc: Add drm_format_info_bpp() helper
Add a helper to retrieve the actual number of bits per pixel for a plane, taking into account the number of characters and pixels per block for tiled for
drm/fourcc: Add drm_format_info_bpp() helper
Add a helper to retrieve the actual number of bits per pixel for a plane, taking into account the number of characters and pixels per block for tiled formats.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/1cae5ebc28513ec1c91c66b00647ce3ca23bfba7.1657294931.git.geert@linux-m68k.org
show more ...
|
Revision tags: v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9 |
|
#
006ea1b5 |
| 15-Dec-2021 |
Dave Stevenson <dave.stevenson@raspberrypi.com> |
drm/fourcc: Add packed 10bit YUV 4:2:0 format
Adds a format that is 3 10bit YUV 4:2:0 samples packed into a 32bit word (with 2 spare bits).
Supported on Broadcom BCM2711 chips.
Signed-off-by: Dave
drm/fourcc: Add packed 10bit YUV 4:2:0 format
Adds a format that is 3 10bit YUV 4:2:0 samples packed into a 32bit word (with 2 spare bits).
Supported on Broadcom BCM2711 chips.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20211215091739.135042-2-maxime@cerno.tech
show more ...
|
Revision tags: v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15 |
|
#
31fa8cbc |
| 27-Oct-2021 |
Laurent Pinchart <laurent.pinchart@ideasonboard.com> |
drm: Add R10 and R12 FourCC
Add FourCCs for 10- and 12-bit red formats with padding to 16 bits. They correspond to the V4L2 10- and 12-bit greyscale (V4L2_PIX_FMT_Y10 and V4L2_PIX_FMT_Y12) formats,
drm: Add R10 and R12 FourCC
Add FourCCs for 10- and 12-bit red formats with padding to 16 bits. They correspond to the V4L2 10- and 12-bit greyscale (V4L2_PIX_FMT_Y10 and V4L2_PIX_FMT_Y12) formats, as well as the Bayer formats with the same bit depth (V4L2_PIX_FMT_SBGGR{10,12} and all other Bayer pattern permutations).
These formats are not used by any kernel driver at this point, but need to be exposed to applications by libcamera, which uses DRM FourCCs for pixel formats.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211027233140.12268-1-laurent.pinchart@ideasonboard.com
show more ...
|
Revision tags: v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9 |
|
#
a0b1d355 |
| 29-Sep-2021 |
Noralf Trønnes <noralf@tronnes.org> |
drm/fourcc: Add R8 to drm_format_info
Add an entry in drm_format_info for the existing format DRM_FORMAT_R8.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Thomas Zimmermann <tzimmer
drm/fourcc: Add R8 to drm_format_info
Add an entry in drm_format_info for the existing format DRM_FORMAT_R8.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210929191201.34456-2-noralf@tronnes.org
show more ...
|
Revision tags: v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25 |
|
#
ff92ecf5 |
| 19-Mar-2021 |
Mario Kleiner <mario.kleiner.de@gmail.com> |
drm/fourcc: Add 16 bpc fixed point framebuffer formats.
These are 16 bits per color channel unsigned normalized formats. They are supported by at least AMD display hw, and suitable for direct scanou
drm/fourcc: Add 16 bpc fixed point framebuffer formats.
These are 16 bits per color channel unsigned normalized formats. They are supported by at least AMD display hw, and suitable for direct scanout of Vulkan swapchain images in the format VK_FORMAT_R16G16B16A16_UNORM.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
show more ...
|
#
b066c72e |
| 16-May-2021 |
Sakari Ailus <sakari.ailus@linux.intel.com> |
drm: Remove drm_get_format_name()
The %p4cc printk format modifier was recently added to print fourcc codes, replacing drm_get_format_name(). The function is no longer needed, so remove it.
Signed-
drm: Remove drm_get_format_name()
The %p4cc printk format modifier was recently added to print fourcc codes, replacing drm_get_format_name(). The function is no longer needed, so remove it.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Petr Mladek <pmladek@suse.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210516121315.30321-4-tzimmermann@suse.de
show more ...
|
Revision tags: v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14, v5.10, v5.8.17, v5.8.16, v5.8.15 |
|
#
47170f89 |
| 12-Oct-2020 |
Matteo Franchin <matteo.franchin@arm.com> |
drm/fourcc: Add AXBXGXRX106106106106 format
Add ABGR format with 10-bit components packed in 64-bit per pixel. This format can be used to handle VK_FORMAT_R10X6G10X6B10X6A10X6_UNORM_4PACK16 on littl
drm/fourcc: Add AXBXGXRX106106106106 format
Add ABGR format with 10-bit components packed in 64-bit per pixel. This format can be used to handle VK_FORMAT_R10X6G10X6B10X6A10X6_UNORM_4PACK16 on little-endian architectures.
Signed-off-by: Matteo Franchin <matteo.franchin@arm.com> Reviewed-by: Brian Starkey <brian.starkey@arm.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201012164043.23630-1-matteo.franchin@arm.com
show more ...
|
Revision tags: v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44 |
|
#
94b292b2 |
| 01-Jun-2020 |
Ben Davis <ben.davis@arm.com> |
drm: drm_fourcc: add NV15, Q410, Q401 YUV formats
DRM_FORMAT_NV15 is a 2 plane format suitable for linear and 16x16 block-linear memory layouts (DRM_FORMAT_MOD_SAMSUNG_16_16_TILE). The format is sim
drm: drm_fourcc: add NV15, Q410, Q401 YUV formats
DRM_FORMAT_NV15 is a 2 plane format suitable for linear and 16x16 block-linear memory layouts (DRM_FORMAT_MOD_SAMSUNG_16_16_TILE). The format is similar to P010 with 4:2:0 sub-sampling but has no padding between components. Instead, luminance and chrominance samples are grouped into 4s so that each group is packed into an integer number of bytes:
YYYY = UVUV = 4 * 10 bits = 40 bits = 5 bytes
The '15' suffix refers to the optimum effective bits per pixel which is achieved when the total number of luminance samples is a multiple of 8.
Q410 and Q401 are both 3 plane non-subsampled formats with 16 bits per component, but only 10 bits are used and 6 are padded. 'Q' is chosen as the first letter to denote 3 plane YUV444, (and is the next letter along from P which is usually 2 plane).
V2: Updated block_w of NV15 to {4, 2, 0} V3: Updated commit message to include specific modifier name
NV15: Tested-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Brian Starkey <brian.starkey@arm.com> Signed-off-by: Ben Davis <ben.davis@arm.com> Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200601162817.18230-1-ben.davis@arm.com
show more ...
|
Revision tags: v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14 |
|
#
96227287 |
| 26-Nov-2019 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fourcc: Fill out all block sizes for P210
0 means 1 as the default, but it's mighty confusing if the block size for the first plane is spelled out explicitly, but not for the 2nd plane.
No cc:
drm/fourcc: Fill out all block sizes for P210
0 means 1 as the default, but it's mighty confusing if the block size for the first plane is spelled out explicitly, but not for the 2nd plane.
No cc: stable because this is just confusion, but 0 functional issue.
Acked-by: Liviu Dudau <liviu.dudau@arm.com> Fixes: 7ba0fee247ee ("drm/fourcc: Add AFBC yuv fourccs for Mali") Cc: Brian Starkey <brian.starkey@arm.com> Cc: Ayan Kumar Halder <ayan.halder@arm.com> Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Alyssa Rosenzweig <alyssa@rosenzweig.io> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191126091414.226070-2-daniel.vetter@ffwll.ch
show more ...
|
#
836b131d |
| 26-Nov-2019 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fourcc: Fill out all block sizes for P10/12/16
0 means 1 as the default, but it's mighty confusing if the block size for the first plane is spelled out explicitly, but not for the 2nd plane.
No
drm/fourcc: Fill out all block sizes for P10/12/16
0 means 1 as the default, but it's mighty confusing if the block size for the first plane is spelled out explicitly, but not for the 2nd plane.
No cc: stable because this is just confusion, but 0 functional issue.
Acked-by: Liviu Dudau <liviu.dudau@arm.com> Fixes: 05f8bc82fc42 ("drm/fourcc: Add new P010, P016 video format") Cc: Daniel Stone <daniel@fooishbar.org> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Randy Li <ayaka@soulik.info> Cc: Clint Taylor <clinton.a.taylor@intel.com> Cc: Ayan Kumar Halder <ayan.halder@arm.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191126091414.226070-1-daniel.vetter@ffwll.ch
show more ...
|
Revision tags: v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10, v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4, v5.2.3, v5.2.2, v5.2.1, v5.2, v5.1.16, v5.1.15, v5.1.14, v5.1.13, v5.1.12, v5.1.11, v5.1.10, v5.1.9, v5.1.8, v5.1.7, v5.1.6 |
|
#
0500c04e |
| 26-May-2019 |
Sam Ravnborg <sam@ravnborg.org> |
drm: drop use of drmP.h in drm/*
The use of the drmP.h header file is deprecated. Remove use from all files in drm/* so people do not look there and follow a bad example.
Build tested allyesconfig,
drm: drop use of drmP.h in drm/*
The use of the drmP.h header file is deprecated. Remove use from all files in drm/* so people do not look there and follow a bad example.
Build tested allyesconfig,allmodconfig on x86, arm etc. Including alpha that is as always more challenging than the rest.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Daniel Vetter <daniel@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Link: https://patchwork.freedesktop.org/patch/msgid/20190526173535.32701-8-sam@ravnborg.org
show more ...
|
Revision tags: v5.1.5, v5.1.4, v5.1.3 |
|
#
bf39607c |
| 16-May-2019 |
Maxime Ripard <maxime.ripard@bootlin.com> |
drm/fourcc: Pass the format_info pointer to drm_format_plane_width/height
So far, the drm_format_plane_height/width functions were operating on the format's fourcc and was doing a lookup to retrieve
drm/fourcc: Pass the format_info pointer to drm_format_plane_width/height
So far, the drm_format_plane_height/width functions were operating on the format's fourcc and was doing a lookup to retrieve the drm_format_info structure and return the cpp.
However, this is inefficient since in most cases, we will have the drm_format_info pointer already available so we shouldn't have to perform a new lookup. Some drm_fourcc functions also already operate on the drm_format_info pointer for that reason, so the API is quite inconsistent there.
Let's follow the latter pattern and remove the extra lookup while being a bit more consistent.
In order to be extra consistent, also rename that function to drm_format_info_plane_cpp and to a static function in the header to match the current policy. The parameters order have also be changed to match the other functions prototype.
Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/514af1d489d80b8b1767e3716b663ce5103da6eb.1558002671.git-series.maxime.ripard@bootlin.com
show more ...
|
#
24c478ea |
| 16-May-2019 |
Maxime Ripard <maxime.ripard@bootlin.com> |
drm/fourcc: Pass the format_info pointer to drm_format_plane_cpp
So far, the drm_format_plane_cpp function was operating on the format's fourcc and was doing a lookup to retrieve the drm_format_info
drm/fourcc: Pass the format_info pointer to drm_format_plane_cpp
So far, the drm_format_plane_cpp function was operating on the format's fourcc and was doing a lookup to retrieve the drm_format_info structure and return the cpp.
However, this is inefficient since in most cases, we will have the drm_format_info pointer already available so we shouldn't have to perform a new lookup. Some drm_fourcc functions also already operate on the drm_format_info pointer for that reason, so the API is quite inconsistent there.
Let's follow the latter pattern and remove the extra lookup while being a bit more consistent. In order to be extra consistent, also rename that function to drm_format_info_plane_cpp and to a static function in the header to match the current policy.
Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/32aa13e53dbc98a90207fd290aa8e79f785fb11e.1558002671.git-series.maxime.ripard@bootlin.com
show more ...
|
#
f3e9632c |
| 16-May-2019 |
Maxime Ripard <maxime.ripard@bootlin.com> |
drm: Remove users of drm_format_(horz|vert)_chroma_subsampling
drm_format_horz_chroma_subsampling and drm_format_vert_chroma_subsampling are basically a lookup in the drm_format_info table plus an a
drm: Remove users of drm_format_(horz|vert)_chroma_subsampling
drm_format_horz_chroma_subsampling and drm_format_vert_chroma_subsampling are basically a lookup in the drm_format_info table plus an access to the hsub and vsub fields of the appropriate entry.
Most drivers are using this function while having access to the entry already, which means that we will perform an unnecessary lookup. Removing the call to these functions is therefore more efficient.
Some drivers will not have access to that entry in the function, but in this case the overhead is minimal (we just have to call drm_format_info() to perform the lookup) and we can even avoid multiple, inefficient lookups in some places that need multiple fields from the drm_format_info structure.
This is amplified by the fact that most of the time the callers will have to retrieve both the vsub and hsub fields, meaning that they would perform twice the lookup.
Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/6b3cceb8161e2c1d40c2681de99202328b0a8abc.1558002671.git-series.maxime.ripard@bootlin.com
show more ...
|
#
05c452c1 |
| 16-May-2019 |
Maxime Ripard <maxime.ripard@bootlin.com> |
drm: Remove users of drm_format_num_planes
drm_format_num_planes() is basically a lookup in the drm_format_info table plus an access to the num_planes field of the appropriate entry.
Most drivers a
drm: Remove users of drm_format_num_planes
drm_format_num_planes() is basically a lookup in the drm_format_info table plus an access to the num_planes field of the appropriate entry.
Most drivers are using this function while having access to the entry already, which means that we will perform an unnecessary lookup. Removing the call to drm_format_num_planes is therefore more efficient.
Some drivers will not have access to that entry in the function, but in this case the overhead is minimal (we just have to call drm_format_info() to perform the lookup) and we can even avoid multiple, inefficient lookups in some places that need multiple fields from the drm_format_info structure.
Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/5ffcec9d14a50ed538e37d565f546802452ee672.1558002671.git-series.maxime.ripard@bootlin.com
show more ...
|
Revision tags: v5.1.2, v5.1.1, v5.0.14, v5.1, v5.0.13, v5.0.12, v5.0.11, v5.0.10, v5.0.9, v5.0.8, v5.0.7, v5.0.6, v5.0.5, v5.0.4 |
|
#
ff01e697 |
| 19-Mar-2019 |
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> |
drm/fourcc: Fix conflicting Y41x definitions
There has unfortunately been a conflict with the following 3 commits:
commit e9961ab95af81b8d29054361cd5f0c575102cf87 Author: Ayan Kumar Halder <ayan.ha
drm/fourcc: Fix conflicting Y41x definitions
There has unfortunately been a conflict with the following 3 commits:
commit e9961ab95af81b8d29054361cd5f0c575102cf87 Author: Ayan Kumar Halder <ayan.halder@arm.com> Date: Fri Nov 9 17:21:12 2018 +0000 drm: Added a new format DRM_FORMAT_XVYU2101010
commit 7ba0fee247ee7a36b3bfbed68f6988d980aa3aa3 Author: Brian Starkey <brian.starkey@arm.com> Date: Fri Oct 5 10:27:00 2018 +0100
drm/fourcc: Add AFBC yuv fourccs for Mali
and
commit 50bf5d7d595fd0705ef3785f80e679b6da501e5b Author: Swati Sharma <swati2.sharma@intel.com> Date: Mon Mar 4 17:26:33 2019 +0530
drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourcc
Unfortunately gcc didn't warn about the redefinitions, because the double defines were the set to same value, and gcc apparently no longer warns about that.
Fix this by using new XYVU for i915, without alpha, and making the Y41x definitions match msdn, with alpha.
Fortunately we caught it early, and the conflict hasn't even landed in drm-next yet.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Brian Starkey <Brian.Starkey@arm.com> Cc: Swati Sharma <swati2.sharma@intel.com> Cc: Ayan Kumar Halder <ayan.halder@arm.com> Cc: malidp@foss.arm.com Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: Dave Airlie <airlied@linux.ie> Cc: Liviu Dudau <Liviu.Dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190319121702.6814-1-maarten.lankhorst@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com> #irc Acked-by: Sean Paul <sean@poorly.run> Reviewed-by: Ayan Kumar halder <ayan.halder@arm.com>
show more ...
|
Revision tags: v5.0.3, v4.19.29, v5.0.2 |
|
#
88ab9c76 |
| 12-Mar-2019 |
Kevin Strasser <kevin.strasser@intel.com> |
drm/fourcc: Add 64 bpp half float formats
Add 64 bpp 16:16:16:16 half float pixel formats. Each 16 bit component is formatted in IEEE-754 half-precision float (binary16) 1:5:10 MSb-sign:exponent:fra
drm/fourcc: Add 64 bpp half float formats
Add 64 bpp 16:16:16:16 half float pixel formats. Each 16 bit component is formatted in IEEE-754 half-precision float (binary16) 1:5:10 MSb-sign:exponent:fraction form.
This patch attempts to address the feedback provided when 2 of these formats were previosly proposed: https://patchwork.kernel.org/patch/10072545/
v2: - Fixed cpp (Ville) - Added detail pixel formatting (Ville) - Ordered formats in header (Ville)
v5: - .depth should be 0 for new formats (Maarten)
Cc: Tina Zhang <tina.zhang@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Kevin Strasser <kevin.strasser@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1552437513-22648-2-git-send-email-kevin.strasser@intel.com
show more ...
|
Revision tags: v4.19.28, v5.0.1, v4.19.27, v5.0, v4.19.26, v4.19.25, v4.19.24, v4.19.23, v4.19.22, v4.19.21, v4.19.20, v4.19.19, v4.19.18, v4.19.17, v4.19.16, v4.19.15, v4.19.14, v4.19.13, v4.19.12, v4.19.11, v4.19.10, v4.19.9, v4.19.8, v4.19.7, v4.19.6, v4.19.5, v4.19.4, v4.18.20, v4.19.3, v4.18.19, v4.19.2, v4.18.18 |
|
#
e9961ab9 |
| 09-Nov-2018 |
Ayan Kumar Halder <ayan.halder@arm.com> |
drm: Added a new format DRM_FORMAT_XVYU2101010
This new format is supported by DP550 and DP650
Changes since v3 (series): - Added the ack - Rebased on the latest drm-misc-next
Signed-off-by: Ayan
drm: Added a new format DRM_FORMAT_XVYU2101010
This new format is supported by DP550 and DP650
Changes since v3 (series): - Added the ack - Rebased on the latest drm-misc-next
Signed-off-by: Ayan Kumar halder <ayan.halder@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Link: https://patchwork.freedesktop.org/patch/291758/?series=57895&rev=1
show more ...
|
Revision tags: v4.18.17, v4.19.1, v4.19, v4.18.16, v4.18.15, v4.18.14, v4.18.13 |
|
#
7ba0fee2 |
| 05-Oct-2018 |
Brian Starkey <brian.starkey@arm.com> |
drm/fourcc: Add AFBC yuv fourccs for Mali
As we look to enable AFBC using DRM format modifiers, we run into problems which we've historically handled via vendor-private details (i.e. gralloc, on And
drm/fourcc: Add AFBC yuv fourccs for Mali
As we look to enable AFBC using DRM format modifiers, we run into problems which we've historically handled via vendor-private details (i.e. gralloc, on Android).
AFBC (as an encoding) is fully flexible, and for example YUV data can be encoded into 1, 2 or 3 encoded "planes", much like the linear equivalents. Component order is also meaningful, as AFBC doesn't necessarily care about what each "channel" of the data it encodes contains. Therefore ABGR8888 and RGBA8888 can be encoded in AFBC with different representations. Similarly, 'X' components may be encoded into AFBC streams in cases where a decoder expects to decode a 4th component.
In addition, AFBC is a licensable IP, meaning that to support the ecosystem we need to ensure that _all_ AFBC users are able to describe the encodings that they need. This is much better achieved by preserving meaning in the fourcc codes when they are combined with an AFBC modifier.
In essence, we want to use the modifier to describe the parameters of the AFBC encode/decode, and use the fourcc code to describe the data being encoded/decoded.
To do anything different would be to introduce redundancy - we would need to duplicate in the modifier information which is _already_ conveyed clearly and non-ambigiously by a fourcc code.
I hope that for RGB this is non-controversial. (BGRA8888 + MODIFIER_AFBC) is a different format from (RGBA8888 + MODIFIER_AFBC).
Possibly more controversial is that (XBGR8888 + MODIFIER_AFBC) is different from (BGR888 + MODIFIER_AFBC). I understand that in some schemes it is not the case - but in AFBC it is so.
Where we run into problems is where there are not already fourcc codes which represent the data which the AFBC encoder/decoder is processing. To that end, we want to introduce new fourcc codes to describe the data being encoded/decoded, in the places where none of the existing fourcc codes are applicable.
Where we don't support an equivalent non-compressed layout, or where no "obvious" linear layout exists, we are proposing adding fourcc codes which have no associated linear layout - because any layout we proposed would be completely arbitrary.
Some formats are following the naming conventions from [2].
The summary of the new formats is: DRM_FORMAT_VUY888 - Packed 8-bit YUV 444. Y followed by U then V. DRM_FORMAT_VUY101010 - Packed 10-bit YUV 444. Y followed by U then V. No defined linear encoding. DRM_FORMAT_Y210 - Packed 10-bit YUV 422. Y followed by U (then Y) then V. 10-bit samples in 16-bit words. DRM_FORMAT_Y410 - Packed 10-bit YUV 444, with 2-bit alpha. DRM_FORMAT_P210 - Semi-planar 10-bit YUV 422. Y plane, followed by interleaved U-then-V plane. 10-bit samples in 16-bit words. DRM_FORMAT_YUV420_8BIT - Packed 8-bit YUV 420. Y followed by U then V. No defined linear encoding DRM_FORMAT_YUV420_10BIT - Packed 10-bit YUV 420. Y followed by U then V. No defined linear encoding
Please also note that in the absence of AFBC, we would still need to add Y410, Y210 and P210.
Full rationale follows:
YUV 444 8-bit, 1-plane ---------------------- The currently defined AYUV format encodes a 4th alpha component, which makes it unsuitable for representing a 3-component YUV 444 AFBC stream.
The proposed[1] XYUV format which is supported by Mali-DP in linear layout is also unsuitable, because the component order is the opposite of the AFBC version, and it encodes a 4th 'X' component.
DRM_FORMAT_VUY888 is the "obvious" format for a 3-component, packed, YUV 444 8-bit format, with the component order which our HW expects to encode/decode. It conforms to the same naming convention as the existing packed YUV 444 format. The naming here is meant to be consistent with DRM_FORMAT_AYUV and DRM_FORMAT_XYUV[1]
YUV 444 10-bit, 1-plane ----------------------- There is no currently-defined YUV 444 10-bit format in drm_fourcc.h, irrespective of number of planes.
The proposed[1] XVYU2101010 format which is supported by Mali-DP in linear layout uses the wrong component order, and also encodes a 4th 'X' component, which doesn't match the AFBC version of YUV 444 10-bit which we support.
DRM_FORMAT_Y410 is the same layout as XVYU2101010, but with 2 bits of alpha. This format is supported with linear layout by Mali GPUs. The naming follows[2].
There is no "obvious" linear encoding for a 3-component 10:10:10 packed format, and so DRM_FORMAT_VUY101010 defines a component order, but not a bit encoding. Again, the naming is meant to be consistent with DRM_FORMAT_AYUV.
YUV 422 8-bit, 1-plane ---------------------- The existing DRM_FORMAT_YUYV (and the other component orders) are single-planar YUV 422 8-bit formats. Following the convention of the component orders of the RGB formats, YUYV has the correct component order for our AFBC encoding (Y followed by U followed by V). We can use YUYV for AFBC YUV 422 8-bit.
YUV 422 10-bit, 1-plane ----------------------- There is no currently-defined YUV 422 10-bit format in drm_fourcc.h
DRM_FORMAT_Y210 is analogous to YUYV, but with 10-bits per sample packed into the upper 10-bits of 16-bit samples. This format is supported in both linear and AFBC by Mali GPUs.
YUV 422 10-bit, 2-plane ----------------------- The recently defined DRM_FORMAT_P010 format is a 10-bit semi-planar YUV 420 format, which has the correct component ordering for an AFBC 2-plane YUV 420 buffer. The linear layout contains meaningless padding bits, which will not be encoded in an AFBC stream.
YUV 420 8-bit, 1-plane ---------------------- There is no currently defined single-planar YUV 420, 8-bit format in drm_fourcc.h. There's differing opinions on whether using the existing fourcc-implied n_planes where possible is a good idea or not when using modifiers.
For me, it's much more "obvious" to use NV12 for 2-plane AFBC and YUV420 for 3-plane AFBC. This keeps the aforementioned separation between the AFBC codec settings (in the modifier) and the pixel data format (in the fourcc). With different vendors using AFBC, this helps to ensure that there is no confusion in interoperation. It also ensures that the AFBC modifiers describe AFBC itself (which is a licensable component), and not implementation details which are not defined by AFBC.
The proposed[1] X0L0 format which Mali-DP supports with Linear layout is unsuitable, as it contains a 4th 'X' component, and our AFBC decoder expects only 3 components.
To that end, we propose a new YUV 420 8-bit format. There is no "obvious" linear encoding for a 3-component 8:8:8, 420, packed format, and so DRM_FORMAT_YUV420_8BIT defines a component order, but not a bit encoding. I'm happy to hear different naming suggestions.
YUV 420 8-bit, 2-, 3-plane -------------------------- These already exist, we can use NV12 and YUV420.
YUV 420 10-bit, 1-plane ----------------------- As above, no current definition exists, and X0L2 encodes a 4th 'X' channel.
Analogous to DRM_FORMAT_YUV420_8BIT, we define DRM_FORMAT_YUV420_10BIT.
[1] https://lists.freedesktop.org/archives/dri-devel/2018-July/184598.html [2] https://docs.microsoft.com/en-us/windows/desktop/medfound/10-bit-and-16-bit-yuv-video-formats
Changes since RFC v1: - Fix confusing subsampling vs bit-depth X:X:X notation in descriptions (danvet) - Rename DRM_FORMAT_AVYU1101010 to DRM_FORMAT_Y410 (Lisa Wu) - Add drm_format_info structures for the new formats, using the new 'bpp' field for those with non-integer bytes-per-pixel - Rebase, including Juha-Pekka Heikkila's format definitions
Changes since RFC v2: - Rebase on top of latest changes in drm-misc-next - Change the description of DRM_FORMAT_P210 in __drm_format_info and drm_fourcc.h so as to make it consistent with other DRM_FORMAT_PXXX formats.
Changes since v3: - Added the ack - Rebased on the latest drm-misc-next
Signed-off-by: Brian Starkey <brian.starkey@arm.com> Signed-off-by: Ayan Kumar Halder <ayan.halder@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Link: https://patchwork.freedesktop.org/patch/291759/?series=57895&rev=1
show more ...
|