Linux kernel stable tree (mirror) https://git.radix-linux.su/kernel/linux.git/atom?h=v5.10.257 2023-01-14T09:15:29+00:00 2023-01-14T09:15:29+00:00 Dave Stevenson dave.stevenson@raspberrypi.com 2021-12-15T09:17:37+00:00 urn:sha1:6f6a99fb620dc09e424986aa9c3492bb74a138bf [ Upstream commit 006ea1b5822f9019bd722ffc6242bc0880879e3d ] 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 Stable-dep-of: b230555f3257 ("drm/fourcc: Fix vsub/hsub for Q410 and Q401") Signed-off-by: Sasha Levin <sashal@kernel.org> 2021-03-04T10:37:38+00:00 Simon Ser contact@emersion.fr 2021-01-10T12:51:03+00:00 urn:sha1:26297e1710d269b9573b5ab8b4072d79be9cf3cc [ Upstream commit cc3283f8f41f741fbaef63d0503d8fb4a7919100 ] The comment says the layout and options use 8 bits, and the shift uses 8 bits. However the mask is 0xf, ie. 0b00001111 (4 bits). This could be surprising when introducing new layouts or options that take more than 4 bits, as this would silently drop the high bits. Make the masks consistent with the comment and the shift. Found when writing a drm_info patch [1]. [1]: https://github.com/ascent12/drm_info/pull/67 Signed-off-by: Simon Ser <contact@emersion.fr> Fixes: d6528ec88309 ("drm/fourcc: Add modifier definitions for describing Amlogic Video Framebuffer Compression") Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210110125103.15447-1-contact@emersion.fr Signed-off-by: Sasha Levin <sashal@kernel.org> 2020-07-27T07:29:51+00:00 Neil Armstrong narmstrong@baylibre.com 2020-07-23T09:05:50+00:00 urn:sha1:da3a9e9a6aa96ef589c153078f66e0646bf06b55 Fix the Amlogic Video Framebuffer Compression modifier macro to correctly add the layout options, a pair of parenthesis was missing. Fixes: d6528ec88309 ("drm/fourcc: Add modifier definitions for describing Amlogic Video Framebuffer Compression") Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200723090551.27529-1-narmstrong@baylibre.com 2020-07-06T13:58:26+00:00 Brian Starkey brian.starkey@arm.com 2020-06-26T16:48:00+00:00 urn:sha1:9ac2b63791ef63935c71e2a7f5444a1118c4d084 In cases such as DRM_FORMAT_MOD_SAMSUNG_16_16_TILE, the modifier describes a generic pixel re-ordering which can be applicable to multiple vendors. Define an alias: DRM_FORMAT_MOD_GENERIC_16_16_TILE, which can be used to describe this layout in a vendor-neutral way, and add a comment about the expected usage of such "generic" modifiers. Changes in v2: - Move note about future cases to comment (Daniel) Signed-off-by: Brian Starkey <brian.starkey@arm.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200626164800.11595-1-brian.starkey@arm.com 2020-07-03T08:12:27+00:00 Neil Armstrong narmstrong@baylibre.com 2020-07-03T08:07:23+00:00 urn:sha1:d6528ec883096e7ccdb08257bcc45670bc878519 Amlogic uses a proprietary lossless image compression protocol and format for their hardware video codec accelerators, either video decoders or video input encoders. It considerably reduces memory bandwidth while writing and reading frames in memory. The underlying storage is considered to be 3 components, 8bit or 10-bit per component, YCbCr 420, single plane : - DRM_FORMAT_YUV420_8BIT - DRM_FORMAT_YUV420_10BIT This modifier will be notably added to DMA-BUF frames imported from the V4L2 Amlogic VDEC decoder. This introduces the basic layout composed of: - a body content organized in 64x32 superblocks with 4096 bytes per superblock in default mode. - a 32 bytes per 128x64 header block This layout is tranferrable between Amlogic SoCs supporting this modifier. The Memory Saving option exist changing the layout superblock size to save memory when using 8bit components pixels size. Finally is also adds the Scatter Memory layout, meaning the header contains IOMMU references to the compressed frames content to optimize memory access and layout. In this mode, only the header memory address is needed, thus the content memory organization is tied to the current producer execution and cannot be saved/dumped neither transferrable between Amlogic SoCs supporting this modifier. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Tested-by: Kevin Hilman <khilman@baylibre.com> Reviewed-by: Kevin Hilman <khilman@baylibre.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200703080728.25207-2-narmstrong@baylibre.com 2020-06-29T10:16:26+00:00 Maarten Lankhorst maarten.lankhorst@linux.intel.com 2020-06-29T10:15:51+00:00 urn:sha1:60e9eabf41fa916d2ef68c5bf929197975917578 Some conflicts with ttm_bo->offset removal, but drm-misc-next needs updating to v5.8. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> 2020-06-19T12:35:24+00:00 Ben Davis ben.davis@arm.com 2020-04-30T08:32:20+00:00 urn:sha1:79ce058032c391b12af928b1e30abf92482a270f AFBC has a mode that guarantees use of AFBC with an uncompressed payloads, we add a new modifier to support this mode. V2: updated modifier comment Signed-off-by: Ben Davis <ben.davis@arm.com> Acked-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200430083220.17347-1-ben.davis@arm.com 2020-06-19T12:33:40+00:00 Ben Davis ben.davis@arm.com 2020-06-01T16:28:17+00:00 urn:sha1:94b292b277343190175d39172c903c0c5fb814f1 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 2020-05-22T00:53:33+00:00 James Jones jajones@nvidia.com 2019-12-11T20:55:47+00:00 urn:sha1:82c8c4ddcae74460f4ea484ab9ad97ddb466e469 Builds upon the existing NVIDIA 16Bx2 block linear format modifiers by adding more "fields" to the existing parameterized DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK format modifier macro that allow fully defining a unique-across- all-NVIDIA-hardware bit layout using a minimal set of fields and values. The new modifier macro DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D is effectively backwards compatible with the existing macro, introducing a superset of the previously definable format modifiers. Backwards compatibility has two quirks. First, the zero value for the "kind" field, which is implied by the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK macro, must be special cased in drivers and assumed to map to the pre-Turing generic kind of 0xfe, since a kind of "zero" is reserved for linear buffer layouts on all GPUs. Second, it is assumed backwards compatibility is only needed when running on Tegra GPUs, and specifically Tegra GPUs prior to Xavier. This is based on two assertions: -Tegra GPUs prior to Xavier used a slightly different raw bit layout than desktop GPUs, making it impossible to directly share block linear buffers between the two. -Support for the existing block linear modifiers was incomplete, making them useful only for exporting buffers created by nouveau and importing them to Tegra DRM as framebuffers for scan out. There was no support for adding framebuffers using format modifiers in nouveau, nor importing dma-buf/PRIME GEM objects into nouveau userspace drivers with modifiers in Mesa. Hence it is assumed the prior modifiers were not intended for use on desktop GPUs, and as a corollary, were not intended to support sharing block linear buffers across two different NVIDIA GPUs. v2: - Added canonicalize helper function v3: - Added additional bit to compression field to support Tesla (NV5x,G8x,G9x,GT1xx,GT2xx) class chips. Signed-off-by: James Jones <jajones@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> 2020-05-08T10:12:58+00:00 Mika Kahola mika.kahola@intel.com 2020-05-06T12:08:27+00:00 urn:sha1:50b6f619a099af6dfe06e958bfa08d46440ea788 Make an additional note on DRM format modifiers for x and y tiling. These format modifiers are defined for BDW+ platforms and therefore definition is not valid for older gens. This is due to address swizzling for tiled surfaces is no longer used. For newer platforms main memory controller has a more effective address swizzling algorithm. v2: Rephrase comment (Daniel) Signed-off-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200506120827.12250-1-mika.kahola@intel.com