<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/include/uapi/drm/drm_fourcc.h, branch v6.1</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>drm/fourcc: Add formats for packed YUV 4:4:4 AVUY and XVUY permutations</title>
<updated>2022-07-18T08:00:32+00:00</updated>
<author>
<name>Laurent Pinchart</name>
<email>laurent.pinchart@ideasonboard.com</email>
</author>
<published>2022-06-16T18:52:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=53618649ca6ded3222b24e8d25a09be30a197577'/>
<id>53618649ca6ded3222b24e8d25a09be30a197577</id>
<content type='text'>
Add FourCCs for two missing permutations of the packed YUV 4:4:4 color
components, namely AVUY and XVUY.

These formats are needed by the NXP i.MX8 ISI. While the ISI is
supported by a V4L2 device (corresponding formats have been submitted to
V4L2), it is handled in userspace by libcamera, which uses DRM FourCCs
for pixel formats.

Signed-off-by: Laurent Pinchart &lt;laurent.pinchart@ideasonboard.com&gt;
Reviewed-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Maxime Ripard &lt;maxime@cerno.tech&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20220616185210.22018-1-laurent.pinchart@ideasonboard.com
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add FourCCs for two missing permutations of the packed YUV 4:4:4 color
components, namely AVUY and XVUY.

These formats are needed by the NXP i.MX8 ISI. While the ISI is
supported by a V4L2 device (corresponding formats have been submitted to
V4L2), it is handled in userspace by libcamera, which uses DRM FourCCs
for pixel formats.

Signed-off-by: Laurent Pinchart &lt;laurent.pinchart@ideasonboard.com&gt;
Reviewed-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Maxime Ripard &lt;maxime@cerno.tech&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20220616185210.22018-1-laurent.pinchart@ideasonboard.com
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge drm/drm-next into drm-misc-next</title>
<updated>2022-07-13T08:33:00+00:00</updated>
<author>
<name>Maxime Ripard</name>
<email>maxime@cerno.tech</email>
</author>
<published>2022-07-13T08:33:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=4de395f2c632c31c575f72d49d4f4389c99dab68'/>
<id>4de395f2c632c31c575f72d49d4f4389c99dab68</id>
<content type='text'>
I need to have some vc4 patches merged in -rc4, but drm-misc-next is
only at -rc2 for now.

Signed-off-by: Maxime Ripard &lt;maxime@cerno.tech&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
I need to have some vc4 patches merged in -rc4, but drm-misc-next is
only at -rc2 for now.

Signed-off-by: Maxime Ripard &lt;maxime@cerno.tech&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'amd-drm-next-5.20-2022-07-05' of https://gitlab.freedesktop.org/agd5f/linux into drm-next</title>
<updated>2022-07-12T01:07:32+00:00</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@redhat.com</email>
</author>
<published>2022-07-12T01:07:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=344feb7ccf764756937cfd74fa4ac5caba069c99'/>
<id>344feb7ccf764756937cfd74fa4ac5caba069c99</id>
<content type='text'>
amd-drm-next-5.20-2022-07-05:

amdgpu:
- Various spelling and grammer fixes
- Various eDP fixes
- Various DMCUB fixes
- VCN fixes
- GMC 11 fixes
- RAS fixes
- TMZ support for GC 10.3.7
- GPUVM TLB flush fixes
- SMU 13.0.x updates
- DCN 3.2 Support
- DCN 3.2.1 Support
- MES updates
- GFX11 modifiers support
- USB-C fixes
- MMHUB 3.0.1 support
- SDMA 6.0 doorbell fixes
- Initial devcoredump support
- Enable high priority gfx queue on asics which support it
- Enable GPU reset for SMU 13.0.4
- OLED display fixes
- MPO fixes
- DC frame size fixes
- ASPM support for PCIE 7.4/7.6
- GPU reset support for SMU 13.0.0
- GFX11 updates
- VCN JPEG fix
- BACO support for SMU 13.0.7
- VCN instance handling fix
- GFX8 GPUVM TLB flush fix
- GPU reset rework
- VCN 4.0.2 support
- GTT size fixes
- DP link training fixes
- LSDMA 6.0.1 support
- Various backlight fixes
- Color encoding fixes
- Backlight config cleanup
- VCN 4.x unified queue cleanup

amdkfd:
- MMU notifier fixes
- Updates for GC 10.3.6 and 10.3.7
- P2P DMA support using dma-buf
- Add available memory IOCTL
- SDMA 6.0.1 fix
- MES fixes
- HMM profiler support

radeon:
- License fix
- Backlight config cleanup

UAPI:
- Add available memory IOCTL to amdkfd
  Proposed userspace: https://www.mail-archive.com/amd-gfx@lists.freedesktop.org/msg75743.html
- HMM profiler support for amdkfd
  Proposed userspace: https://lists.freedesktop.org/archives/amd-gfx/2022-June/080805.html

Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
From: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20220705212633.6037-1-alexander.deucher@amd.com
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
amd-drm-next-5.20-2022-07-05:

amdgpu:
- Various spelling and grammer fixes
- Various eDP fixes
- Various DMCUB fixes
- VCN fixes
- GMC 11 fixes
- RAS fixes
- TMZ support for GC 10.3.7
- GPUVM TLB flush fixes
- SMU 13.0.x updates
- DCN 3.2 Support
- DCN 3.2.1 Support
- MES updates
- GFX11 modifiers support
- USB-C fixes
- MMHUB 3.0.1 support
- SDMA 6.0 doorbell fixes
- Initial devcoredump support
- Enable high priority gfx queue on asics which support it
- Enable GPU reset for SMU 13.0.4
- OLED display fixes
- MPO fixes
- DC frame size fixes
- ASPM support for PCIE 7.4/7.6
- GPU reset support for SMU 13.0.0
- GFX11 updates
- VCN JPEG fix
- BACO support for SMU 13.0.7
- VCN instance handling fix
- GFX8 GPUVM TLB flush fix
- GPU reset rework
- VCN 4.0.2 support
- GTT size fixes
- DP link training fixes
- LSDMA 6.0.1 support
- Various backlight fixes
- Color encoding fixes
- Backlight config cleanup
- VCN 4.x unified queue cleanup

amdkfd:
- MMU notifier fixes
- Updates for GC 10.3.6 and 10.3.7
- P2P DMA support using dma-buf
- Add available memory IOCTL
- SDMA 6.0.1 fix
- MES fixes
- HMM profiler support

radeon:
- License fix
- Backlight config cleanup

UAPI:
- Add available memory IOCTL to amdkfd
  Proposed userspace: https://www.mail-archive.com/amd-gfx@lists.freedesktop.org/msg75743.html
- HMM profiler support for amdkfd
  Proposed userspace: https://lists.freedesktop.org/archives/amd-gfx/2022-June/080805.html

Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
From: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20220705212633.6037-1-alexander.deucher@amd.com
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/fourcc: Add DRM_FORMAT_D[1248]</title>
<updated>2022-07-09T13:36:07+00:00</updated>
<author>
<name>Geert Uytterhoeven</name>
<email>geert@linux-m68k.org</email>
</author>
<published>2022-07-08T18:20:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=b92db7e4fe740daab858366faff1f992d53d3ff4'/>
<id>b92db7e4fe740daab858366faff1f992d53d3ff4</id>
<content type='text'>
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 &lt;geert@linux-m68k.org&gt;
Reviewed-by: Javier Martinez Canillas &lt;javierm@redhat.com&gt;
Signed-off-by: Sam Ravnborg &lt;sam@ravnborg.org&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/6119f3abeda9baaa88652843960adc032da276b4.1657294931.git.geert@linux-m68k.org
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;geert@linux-m68k.org&gt;
Reviewed-by: Javier Martinez Canillas &lt;javierm@redhat.com&gt;
Signed-off-by: Sam Ravnborg &lt;sam@ravnborg.org&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/6119f3abeda9baaa88652843960adc032da276b4.1657294931.git.geert@linux-m68k.org
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/fourcc: Add DRM_FORMAT_R[124]</title>
<updated>2022-07-09T13:35:55+00:00</updated>
<author>
<name>Geert Uytterhoeven</name>
<email>geert@linux-m68k.org</email>
</author>
<published>2022-07-08T18:20:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=d093100b425df6fe400881f2e62c3f0be7bf18cf'/>
<id>d093100b425df6fe400881f2e62c3f0be7bf18cf</id>
<content type='text'>
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 &lt;geert@linux-m68k.org&gt;
Reviewed-by: Javier Martinez Canillas &lt;javierm@redhat.com&gt;
Signed-off-by: Sam Ravnborg &lt;sam@ravnborg.org&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/96561a88e53c59cac72e66642bf4c097aacefd18.1657294931.git.geert@linux-m68k.org
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;geert@linux-m68k.org&gt;
Reviewed-by: Javier Martinez Canillas &lt;javierm@redhat.com&gt;
Signed-off-by: Sam Ravnborg &lt;sam@ravnborg.org&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/96561a88e53c59cac72e66642bf4c097aacefd18.1657294931.git.geert@linux-m68k.org
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/fourcc: Clarify the meaning of single-channel "red"</title>
<updated>2022-07-09T13:08:45+00:00</updated>
<author>
<name>Geert Uytterhoeven</name>
<email>geert@linux-m68k.org</email>
</author>
<published>2022-07-08T18:20:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=8aba4d30520ed656065eb36f0628109bdea385ee'/>
<id>8aba4d30520ed656065eb36f0628109bdea385ee</id>
<content type='text'>
Traditionally, the first channel has been called the "red" channel, but
the fourcc values for single-channel "red" formats can also be used for
other single-channel formats with a direct relationship between channel
value and brightness, like grayscale.

Signed-off-by: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
Reviewed-by: Javier Martinez Canillas &lt;javierm@redhat.com&gt;
Signed-off-by: Sam Ravnborg &lt;sam@ravnborg.org&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/31d1792f26707a7270347e9916b4103470d2b192.1657294931.git.geert@linux-m68k.org
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Traditionally, the first channel has been called the "red" channel, but
the fourcc values for single-channel "red" formats can also be used for
other single-channel formats with a direct relationship between channel
value and brightness, like grayscale.

Signed-off-by: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
Reviewed-by: Javier Martinez Canillas &lt;javierm@redhat.com&gt;
Signed-off-by: Sam Ravnborg &lt;sam@ravnborg.org&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/31d1792f26707a7270347e9916b4103470d2b192.1657294931.git.geert@linux-m68k.org
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/fourcc: Add DRM_FORMAT_C[124]</title>
<updated>2022-07-09T13:02:50+00:00</updated>
<author>
<name>Geert Uytterhoeven</name>
<email>geert@linux-m68k.org</email>
</author>
<published>2022-07-08T18:20:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=e5bd7e3e4a68f0befe53f59954b25eec9a792d60'/>
<id>e5bd7e3e4a68f0befe53f59954b25eec9a792d60</id>
<content type='text'>
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 &lt;geert@linux-m68k.org&gt;
Reviewed-by: Pekka Paalanen &lt;pekka.paalanen@collabora.com&gt;
Reviewed-by: Javier Martinez Canillas &lt;javierm@redhat.com&gt;
Signed-off-by: Sam Ravnborg &lt;sam@ravnborg.org&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/3d88ca7ad32ff3ff3469c10f0b36c312ea233a33.1657294931.git.geert@linux-m68k.org
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;geert@linux-m68k.org&gt;
Reviewed-by: Pekka Paalanen &lt;pekka.paalanen@collabora.com&gt;
Reviewed-by: Javier Martinez Canillas &lt;javierm@redhat.com&gt;
Signed-off-by: Sam Ravnborg &lt;sam@ravnborg.org&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/3d88ca7ad32ff3ff3469c10f0b36c312ea233a33.1657294931.git.geert@linux-m68k.org
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/fourcc: Document the Intel CCS modifiers' CC plane expected pitch</title>
<updated>2022-06-28T11:53:18+00:00</updated>
<author>
<name>Imre Deak</name>
<email>imre.deak@intel.com</email>
</author>
<published>2022-06-23T14:49:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=882d90310f04f3f90753653b8787fb4d309fbbdf'/>
<id>882d90310f04f3f90753653b8787fb4d309fbbdf</id>
<content type='text'>
The driver expects the pitch of the Intel CCS CC color planes to be
64 bytes aligned, adjust the modifier descriptions accordingly.

Cc: Nanley Chery &lt;nanley.g.chery@intel.com&gt;
Signed-off-by: Imre Deak &lt;imre.deak@intel.com&gt;
Reviewed-by: Nanley Chery &lt;nanley.g.chery@intel.com&gt;
Reviewed-by: Jordan Justen &lt;jordan.l.justen@intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20220623144955.2486736-1-imre.deak@intel.com
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The driver expects the pitch of the Intel CCS CC color planes to be
64 bytes aligned, adjust the modifier descriptions accordingly.

Cc: Nanley Chery &lt;nanley.g.chery@intel.com&gt;
Signed-off-by: Imre Deak &lt;imre.deak@intel.com&gt;
Reviewed-by: Nanley Chery &lt;nanley.g.chery@intel.com&gt;
Reviewed-by: Jordan Justen &lt;jordan.l.justen@intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20220623144955.2486736-1-imre.deak@intel.com
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/fourcc: fix integer type usage in uapi header</title>
<updated>2022-06-23T21:21:38+00:00</updated>
<author>
<name>Carlos Llamas</name>
<email>cmllamas@google.com</email>
</author>
<published>2022-06-21T20:39:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=3d313f09f31490cec9d5251b59adeb6542c944cc'/>
<id>3d313f09f31490cec9d5251b59adeb6542c944cc</id>
<content type='text'>
Kernel uapi headers are supposed to use __[us]{8,16,32,64} types defined
by &lt;linux/types.h&gt; as opposed to 'uint32_t' and similar. See [1] for the
relevant discussion about this topic. In this particular case, the usage
of 'uint64_t' escaped headers_check as these macros are not being called
here. However, the following program triggers a compilation error:

  #include &lt;drm/drm_fourcc.h&gt;

  int main()
  {
  	unsigned long x = AMD_FMT_MOD_CLEAR(RB);
  	return 0;
  }

gcc error:
  drm.c:5:27: error: ‘uint64_t’ undeclared (first use in this function)
      5 |         unsigned long x = AMD_FMT_MOD_CLEAR(RB);
        |                           ^~~~~~~~~~~~~~~~~

This patch changes AMD_FMT_MOD_{SET,CLEAR} macros to use the correct
integer types, which fixes the above issue.

  [1] https://lkml.org/lkml/2019/6/5/18

Fixes: 8ba16d599374 ("drm/fourcc: Add AMD DRM modifiers.")
Signed-off-by: Carlos Llamas &lt;cmllamas@google.com&gt;
Reviewed-by: Simon Ser &lt;contact@emersion.fr&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Kernel uapi headers are supposed to use __[us]{8,16,32,64} types defined
by &lt;linux/types.h&gt; as opposed to 'uint32_t' and similar. See [1] for the
relevant discussion about this topic. In this particular case, the usage
of 'uint64_t' escaped headers_check as these macros are not being called
here. However, the following program triggers a compilation error:

  #include &lt;drm/drm_fourcc.h&gt;

  int main()
  {
  	unsigned long x = AMD_FMT_MOD_CLEAR(RB);
  	return 0;
  }

gcc error:
  drm.c:5:27: error: ‘uint64_t’ undeclared (first use in this function)
      5 |         unsigned long x = AMD_FMT_MOD_CLEAR(RB);
        |                           ^~~~~~~~~~~~~~~~~

This patch changes AMD_FMT_MOD_{SET,CLEAR} macros to use the correct
integer types, which fixes the above issue.

  [1] https://lkml.org/lkml/2019/6/5/18

Fixes: 8ba16d599374 ("drm/fourcc: Add AMD DRM modifiers.")
Signed-off-by: Carlos Llamas &lt;cmllamas@google.com&gt;
Reviewed-by: Simon Ser &lt;contact@emersion.fr&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/amd: Add GFX11 modifiers support to AMDGPU (v3)</title>
<updated>2022-06-03T20:43:38+00:00</updated>
<author>
<name>Aurabindo Pillai</name>
<email>aurabindo.pillai@amd.com</email>
</author>
<published>2022-02-21T20:33:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=543036a2de71f14f8ad566c858e5e9ff61736a86'/>
<id>543036a2de71f14f8ad566c858e5e9ff61736a86</id>
<content type='text'>
GFX11 IP introduces new tiling mode. Various combinations of DCC
settings are possible and the most preferred settings must be exposed
for optimal use of the hardware.

add_gfx11_modifiers() is based on recommendation from Marek for the
preferred tiling modifier that are most efficient for the hardware.

v2: microtiling fix noticed by Marek
v3: keep Z tiling check

Signed-off-by: Aurabindo Pillai &lt;aurabindo.pillai@amd.com&gt;
Acked-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
GFX11 IP introduces new tiling mode. Various combinations of DCC
settings are possible and the most preferred settings must be exposed
for optimal use of the hardware.

add_gfx11_modifiers() is based on recommendation from Marek for the
preferred tiling modifier that are most efficient for the hardware.

v2: microtiling fix noticed by Marek
v3: keep Z tiling check

Signed-off-by: Aurabindo Pillai &lt;aurabindo.pillai@amd.com&gt;
Acked-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
