linux.git/include/uapi/drm/drm_fourcc.h, branch v5.14

drm/fourcc: Add 16 bpc fixed point framebuffer formats.

2021-05-27T19:00:47+00:00

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ä 
Signed-off-by: Mario Kleiner 
Signed-off-by: Alex Deucher

Merge tag 'drm-intel-next-2021-01-27' of git://anongit.freedesktop.org/drm/drm-intel into drm-next

2021-01-29T07:05:15+00:00

- HDCP 2.2 and HDCP 1.4 Gen12 DP MST support (Anshuman)
- Fix DP vswing settings and handling (Imre, Ville)
- Various display code clean-up (Jani, Ville)
- Various display refactoring, including split out of pps, aux, and fdi (Ja\
ni, Dave)
- Add DG1 missing workarounds (Jose)
- Fix display color conversion (Chris, Ville)
- Try to guess PCH type even without ISA bridge (Zhenyu)
- More backlight refactor (Lyude)
- Support two CSC module on gen11 and later (Lee)
- Async flips for all ilk+ platforms (Ville)
- Clear color support for TGL (RK)
- Add a helper to read data from a GEM object page (Imre)
- VRR/Adaptive Sync Enabling on DP/eDP for TGL+ (Manasi, Ville Aditya)

Signed-off-by: Dave Airlie 

From: Rodrigo Vivi 
Link: https://patchwork.freedesktop.org/patch/msgid/20210127140822.GA711686@intel.com

drm/framebuffer: Format modifier for Intel Gen 12 render compression with Clear Color

2021-01-22T13:57:28+00:00

Gen12 display can decompress surfaces compressed by render engine with
Clear Color, add a new modifier as the driver needs to know the surface
was compressed by render engine.

V2: Description changes as suggested by Rafael.
V3: Mention the Clear Color size of 64 bits in the comments(DK)
v4: Fix trailing whitespaces
v5: Explain Clear Color in the documentation.
v6: Documentation Nitpicks(Nanley)

Cc: Ville Syrjala 
Cc: Dhinakaran Pandiyan 
Cc: Kalyan Kondapally 
Cc: Rafael Antognolli 
Cc: Nanley Chery 
Signed-off-by: Radhakrishna Sripada 
Signed-off-by: Imre Deak 
Acked-by: Daniel Vetter 
Acked-by: Jani Nikula 
Acked-by: Nanley Chery 
Reviewed-by: Mika Kahola 
Link: https://patchwork.freedesktop.org/patch/msgid/20210114201314.783648-2-imre.deak@intel.com

drm/fourcc: fix Amlogic format modifier masks

2021-01-12T14:52:43+00:00

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 
Fixes: d6528ec88309 ("drm/fourcc: Add modifier definitions for describing Amlogic Video Framebuffer Compression")
Cc: Neil Armstrong 
Cc: Sam Ravnborg 
Cc: Kevin Hilman 
Cc: Daniel Vetter 
Acked-by: Neil Armstrong 
Link: https://patchwork.freedesktop.org/patch/msgid/20210110125103.15447-1-contact@emersion.fr

drm/fourcc: fix AMD modifiers PACKERS field doc

2020-11-16T17:20:13+00:00

This field doesn't alias with BANK_XOR_BITS: PACKERS is bits 27:29 while
BANK_XOR_BITS is bits 24:26.

Fixes: 8ba16d599374 ("drm/fourcc: Add AMD DRM modifiers.")
Reviewed-by: Bas Nieuwenhuizen 
Signed-off-by: Simon Ser 
Cc: Bas Nieuwenhuizen 
Cc: Alex Deucher 
Cc: Daniel Vetter 
Signed-off-by: Alex Deucher

drm/fourcc: add table describing AMD modifiers bit layout

2020-11-13T22:29:47+00:00

The table describes how each bit in the u64 value is used. Explicitly
state which values a field can take if we have defines for them. Also
add a note when a field isn't always populated.

Forcing people to update the table when changing the bit layout should
make it more obvious when there's a mistake, I hope.

If we get to the point where the bit layout gets more complicated, it
might be worth it to split the table into multiple tables (e.g. one for
GFX8, one for GFX9+, and so on).

Signed-off-by: Simon Ser 
Cc: Bas Nieuwenhuizen 
Cc: Alex Deucher 
Cc: Daniel Vetter 
Signed-off-by: Alex Deucher

drm/fourcc: Fix modifier field mask for AMD modifiers.

2020-11-13T22:29:47+00:00

The DCC_MAX_COMPRESSED_BLOCK has to contain one of
AMD_FMT_MOD_DCC_BLOCK_* and with 3 values this doesn't
fit in 1 bit.

Fix this cleanly while it is only in drm-next.

Fixes: 8ba16d599374 ("drm/fourcc: Add AMD DRM modifiers.")
Reviewed-by: Alex Deucher 
Signed-off-by: Bas Nieuwenhuizen 
Signed-off-by: Alex Deucher

Merge tag 'amd-drm-next-5.11-2020-11-05' of git://people.freedesktop.org/~agd5f/linux into drm-next

2020-11-10T07:48:47+00:00

amd-drm-next-5.11-2020-11-05:

amdgpu:
- Add initial support for Vangogh
- Add support for Green Sardine
- Add initial support for Dimgrey Cavefish
- Scatter/Gather display support for Renoir
- Updates for Sienna Cichlid
- Updates for Navy Flounder
- SMU7 power improvements
- Modifier support for gfx9+
- CI BACO fixes
- Arcturus SMU fixes
- Lots of code cleanups
- DC fixes
- Kernel doc fixes
- Add more GPU HW client information to page fault error logging
- MPO clock tuning for RV
- FP fixes for DCN3 on ARM and PPC

radeon:
- Expose voltage via hwmon on Sumo APUs

amdkfd:
- Fix unique id handling
- Misc fixes

From: Alex Deucher 
Link: https://patchwork.freedesktop.org/patch/msgid/20201105222749.201798-1-alexander.deucher@amd.com

drm/fourcc: Add AMD DRM modifiers.

2020-10-30T18:27:22+00:00

This adds modifiers for GFX9+ AMD GPUs.

As the modifiers need a lot of parameters I split things out in
getters and setters.
  - Advantage: simplifies the code a lot
  - Disadvantage: Makes it harder to check that you're setting all
                  the required fields.

The tiling modes seem to change every generation, but the structure
of what each tiling mode is good for stays really similar. As such
the core of the modifier is
 - the tiling mode
 - a version. Not explicitly a GPU generation, but splitting out
   a new set of tiling equations.

Sometimes one or two tiling modes stay the same and for those we
specify a canonical version.

Then we have a bunch of parameters on how the compression works.
Different HW units have different requirements for these and we
actually have some conflicts here.

e.g. the render backends need a specific alignment but the display
unit only works with unaligned compression surfaces. To work around
that we have a DCC_RETILE option where both an aligned and unaligned
compression surface are allocated and a writer has to sync the
aligned surface to the unaligned surface on handoff.

Finally there are some GPU parameters that participate in the tiling
equations. These are constant for each GPU on the rendering/texturing
side. The display unit is very flexible however and supports all
of them :|

Some estimates:
 - Single GPU, render+texture: ~10 modifiers
 - All possible configs in a gen, display: ~1000 modifiers
 - Configs of actually existing GPUs in a gen: ~100 modifiers

For formats with a single plane everything gets put in a separate
DRM plane. However, this doesn't fit for some YUV formats, so if
the format has >1 plane, we let the driver pack the surfaces into
1 DRM plane per format plane.

This way we avoid X11 rendering onto the frontbuffer with DCC, but
still fit into 4 DRM planes.

Signed-off-by: Bas Nieuwenhuizen 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher

drm: deprecate DRM_FORMAT_MOD_NONE

2020-10-26T17:34:36+00:00

DRM_FORMAT_MOD_NONE is in the list of vendors, which is pretty
confusing. We already have DRM_FORMAT_MOD_VENDOR_NONE. Move it down in
the list of format modifiers.

DRM_FORMAT_MOD_NONE is an alias for DRM_FORMAT_MOD_LINEAR, however the
name is confusing: NONE doesn't mean that the modifier is implicit,
instead it means that the layout is linear. Deprecate it.

Signed-off-by: Simon Ser 
Reviewed-by: Bas Nieuwenhuizen 
Reviewed-by: Pekka Paalanen 
Acked-by: Daniel Vetter 
Link: https://patchwork.freedesktop.org/patch/msgid/a2j8KTgc26k5QniSAhDSTgCw4XWZhmsNHwG8UVa6U@cp4-web-014.plabs.ch