Commit Graph

37 Commits

Author SHA1 Message Date
Matteo Franchin
47170f89f7 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
2020-10-20 20:51:42 +01:00
Ben Davis
94b292b277 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
2020-06-19 13:33:40 +01:00
Daniel Vetter
96227287fd 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: 7ba0fee247 ("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
2019-11-28 11:19:32 +01:00
Daniel Vetter
836b131d2c 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: 05f8bc82fc ("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
2019-11-28 11:15:48 +01:00
Sam Ravnborg
0500c04ea1 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
2019-05-27 18:07:03 +02:00
Maxime Ripard
bf39607c16
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
2019-05-20 13:35:24 +02:00
Maxime Ripard
24c478ead0
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
2019-05-20 13:33:46 +02:00
Maxime Ripard
f3e9632cb6
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
2019-05-20 13:33:11 +02:00
Maxime Ripard
05c452c115
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
2019-05-20 13:32:57 +02:00
Maarten Lankhorst
ff01e6971e drm/fourcc: Fix conflicting Y41x definitions
There has unfortunately been a conflict with the following 3 commits:

commit e9961ab95a
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 7ba0fee247
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 50bf5d7d59
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>
2019-03-21 09:49:04 +01:00
Sean Paul
f435fe83d5 Add support for floating point half-width formats.
-----BEGIN PGP SIGNATURE-----
 
 iQIyBAABCgAdFiEEuXvWqAysSYEJGuVH/lWMcqZwE8MFAlyI50kACgkQ/lWMcqZw
 E8PF0A/4+HGqNO8HztPcaUriV+azhyitfbANnOfAe3uLaZL8irl1FVAnQ7JJKayy
 DJLNMGSUUQqV84qE4utQigHqDuNRjfY7cAyorNGCH4x84dlDoQybbbc+8w7Tfrw6
 U0AE2T5XyNbDfRTzk/mDqSKjr2BVpMtguW0uT3JALEkci0dBzH2rySEHhbtvA0of
 AGFMw3kmrDLQoHoqrRrTss/r8P8bAlKGBkb8NWLQ8S5Eoij4MP8Q27MQfYQp0mek
 iOM4ZM3V69jUkchvNzs/92ILdBA/2FwiE2DsdlIbWaTbAW3A6jM3QY+bP8NVhc4q
 r/MQ6J9qlLDV3sG7uE7fNdW5Z1zV2gUchEu3UhmY4HbqovVuxp5BDbQ0R+iGI7e4
 OQPHOPrdSVU1R2Wc+i7BYilHNNgm4IISu0Mp/lHUEOmv0MDslKRKVdi86Y5VyL3e
 /jzBId0KdBoMkI14GMBjWUL4E7c3i5SGQmMGlf4mZBd2BUHE7sI0HpLXNPoz32AC
 tyZ1cvRYDD2rAZHMArLVVPOGNTqmOPvAUDi5O2Fg1K+iUEyJPpIywZk+/oilpQgk
 sLgDjrQVtH4UAczx3VMO1JZ71dSwjBkZuhJ+yEqQ2gTHhzxuz5ah9xXn9XpmucNe
 YtNqyldfT0FoTEm9upqcxVwS1kgZJx7Cc85UtNLIIYiazSNu2w==
 =NtCi
 -----END PGP SIGNATURE-----

Merge tag 'topic/hdr-formats-2019-03-13' of git://anongit.freedesktop.org/drm/drm-misc into drm-misc-next

Add support for floating point half-width formats.

Signed-off-by: Sean Paul <seanpaul@chromium.org>

From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/00b96cd5-91c7-5677-9620-b138c7a92303@linux.intel.com
2019-03-13 14:08:05 -04:00
Kevin Strasser
88ab9c76d1 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
2019-03-13 11:10:31 +01:00
Ayan Kumar Halder
e9961ab95a 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
2019-03-12 18:25:05 +00:00
Brian Starkey
7ba0fee247 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
2019-03-12 18:24:55 +00:00
Swati Sharma
50bf5d7d59 drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourcc
The following pixel formats are packed format that follows 4:2:2
chroma sampling. For memory represenation each component is
allocated 16 bits each. Thus each pixel occupies 32bit.

Y210:	For each component, valid data occupies MSB 10 bits.
	LSB 6 bits are filled with zeroes.
Y212:	For each component, valid data occupies MSB 12 bits.
	LSB 4 bits are filled with zeroes.
Y216:	For each component valid data occupies 16 bits,
	doesn't require any padding bits.

First 16 bits stores the Y value and the next 16 bits stores one
of the chroma samples alternatively. The first luma sample will
be accompanied by first U sample and second luma sample is
accompanied by the first V sample.

The following pixel formats are packed format that follows 4:4:4
chroma sampling. Channels are arranged in the order UYVA in
increasing memory order.

Y410:	Each color component occupies 10 bits and X component
	takes 2 bits, thus each pixel occupies 32 bits.
Y412:   Each color component is 16 bits where valid data
	occupies MSB 12 bits. LSB 4 bits are filled with zeroes.
	Thus, each pixel occupies 64 bits.
Y416:   Each color component occupies 16 bits for valid data,
	doesn't require any padding bits. Thus, each pixel
	occupies 64 bits.

v3: fixed missing tab for XYUV8888 (JP)

Signed-off-by: Swati Sharma <swati2.sharma@intel.com>
Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1551700595-21481-5-git-send-email-swati2.sharma@intel.com
2019-03-05 12:47:54 +01:00
Randy Li
05f8bc82fc drm/fourcc: Add new P010, P016 video format
P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits per
channel video format.

P012 is a planar 4:2:0 YUV 12 bits per channel

P016 is a planar 4:2:0 YUV with interleaved UV plane, 16 bits per
channel video format.

V3: Added P012 and fixed cpp for P010.
V4: format definition refined per review.
V5: Format comment block for each new pixel format.
V6: reversed Cb/Cr order in comments.
v7: reversed Cb/Cr order in comments of header files, remove
the wrong part of commit message.
V8: reversed V7 changes except commit message and rebased.
v9: used the new properties to describe those format and
rebased.

Cc: Daniel Stone <daniel@fooishbar.org>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>

Signed-off-by: Randy Li <ayaka@soulik.info>
Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com>
Reviewed-by: Ayan Kumar Halder <ayan.halder@arm.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190109195710.28501-2-ayaka@soulik.info
2019-02-08 22:17:08 +01:00
Stanislav Lisovskiy
61e49394a3 drm: Introduce new DRM_FORMAT_XYUV
v5: This is YUV444 packed format same as AYUV, but without alpha,
    as supported by i915.

v6: Removed unneeded initializer for new XYUV format.

v7: Added is_yuv field initialization according to latest
    drm_fourcc format structure initialization changes.

v8: Edited commit message to be more clear about skl+, renamed
    PLANE_CTL_FORMAT_AYUV to PLANE_CTL_FORMAT_XYUV as this format
    doesn't support per-pixel alpha. Fixed minor code issues.

v9: Moved DRM format check to proper place in intel_framebuffer_init.

v10: Changed DRM_FORMAT_XYUV to be DRM_FORMAT_XYUV8888

v11: Fixed rebase conflict, caused by added new formats to drm-tip
     meanwhile.

Reviewed-by: Alexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com>
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
[vsyrjala: Removed stray tab and sorted the formats differently]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181109093916.25858-2-stanislav.lisovskiy@intel.com
2018-11-20 16:20:13 +02:00
Alexandru Gheorghe
697b6b8504 drm/fourcc: Add fourcc for Mali linear tiled formats
Mali-DP implements a number of tiled yuv formats which are not
currently described in drm_fourcc.h.
This adds those definitions and describes their memory layout by
using the newly added char_per_block, block_w, block_h.

Reviewed-by: Brian Starkey <brian.starkey@arm.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Alexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181101151051.1509-3-alexandru-cosmin.gheorghe@arm.com
2018-11-02 09:55:44 +00:00
Alexandru Gheorghe
042bf75384 drm/fourcc: Add char_per_block, block_w and block_h in drm_format_info
For some pixel formats .cpp structure in drm_format info it's not
enough to describe the peculiarities of the pixel layout, for example
tiled formats or packed formats at bit level.

What's implemented here is to add three new members to drm_format_info
that could describe such formats:

- char_per_block[3]
- block_w[3]
- block_h[3]

char_per_block will be put in a union alongside cpp, for transparent
compatibility  with the existing format descriptions.

Regarding, block_w and block_h they are intended to be used through
their equivalent getters drm_format_info_block_width /
drm_format_info_block_height, the reason of the getters is to abstract
the fact that for normal formats block_w and block_h will be unset/0,
but the methods will be returning 1.

Additionally, convenience function drm_format_info_min_pitch had been
added that computes the minimum required pitch for a given pixel
format and buffer width.

Using that the following drm core functions had been updated to
generically handle both block and non-block formats:

- drm_fb_cma_get_gem_addr: for block formats it will just return the
  beginning of the block.
- framebuffer_check: Use the newly added drm_format_info_min_pitch.
- drm_gem_fb_create_with_funcs: Use the newly added
  drm_format_info_min_pitch.
- In places where is not expecting to handle block formats, like fbdev
  helpers I just added some warnings in case the block width/height
  are greater than 1.

Changes since v3:
 - Add helper function for computing the minimum required pitch.
 - Improve/cleanup documentation

Changes since v8:
 - Fixed build on 32bits arm architectures, with:

-       return DIV_ROUND_UP((u64)buffer_width * info->char_per_block[plane],
+       return DIV_ROUND_UP_ULL((u64)buffer_width * info->char_per_block[plane],

Reviewed-by: Brian Starkey <brian.starkey@arm.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Alexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181101170055.5433-1-alexandru-cosmin.gheorghe@arm.com
2018-11-02 09:55:27 +00:00
Daniel Vetter
4af67def3b drm/doc: fix drm_driver_legacy_fb_format
Didn't get updated in a rework of the original patch.

Fixes: 059b5eb5d9 ("drm: move native byte order quirk to new drm_driver_legacy_fb_format function")
Cc: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20181004202446.22905-20-daniel.vetter@ffwll.ch
2018-10-05 18:05:32 +02:00
Gerd Hoffmann
9dd3cb243d drm: move quirk_addfb_prefer_xbgr_30bpp handling to drm_driver_legacy_fb_format too
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20180921134704.12826-7-kraxel@redhat.com
2018-09-25 14:49:50 +02:00
Gerd Hoffmann
059b5eb5d9 drm: move native byte order quirk to new drm_driver_legacy_fb_format function
Turns out we need the pixel format fixup not only for the addfb ioctl,
but also for fbdev emulation code.

Ideally we would place it in drm_mode_legacy_fb_format().  That would
create alot of churn though, and most drivers don't care because they
never ever run on a big endian platform.  So add a new
drm_driver_legacy_fb_format() function instead which looks at the
mode_config->quirk_addfb_prefer_host_byte_order flag.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20180921134704.12826-2-kraxel@redhat.com
2018-09-25 14:49:49 +02:00
Chris Wilson
70109354fe drm: Reject unknown legacy bpp and depth for drm_mode_addfb ioctl
Since this is handling user provided bpp and depth, we need to sanity
check and propagate the EINVAL back rather than assume what the insane
client intended and fill the logs with DRM_ERROR.

v2: Check both bpp and depth match the builtin pixel format, and
introduce a canonical DRM_FORMAT_INVALID to reserve 0 against any future
fourcc.

v3: Mark up DRM_FORMAT_C8 as being {bpp:8, depth:8}

Testcase: igt/kms_addfb_basic/legacy-format
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180905153116.28924-1-chris@chris-wilson.co.uk
2018-09-06 08:07:41 +01:00
Ayan Kumar Halder
ce2d54619a drm/fourcc: Add is_yuv field to drm_format_info to denote if the format is yuv
A lot of drivers duplicate the function to check if a format is yuv or not.
If we add a field (to denote whether the format is yuv or not) in the
drm_format_info table, all the drivers can use this field and it will
prevent duplication of similar logic.

Signed-off-by: Ayan Kumar halder <ayan.halder@arm.com>
Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1531847626-22248-1-git-send-email-ayan.halder@arm.com
2018-07-18 16:56:45 +01:00
Maxime Ripard
4cc4e1b40f
drm/fourcc: Add a alpha field to drm_format_info
There's a bunch of drivers that duplicate the same function to know if a
particular format embeds an alpha component or not.

Let's create a field in the drm_format_info to avoid duplicating that logic
and looking up formats all the time.

Cc: Eric Anholt <eric@anholt.net>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Joonyoung Shim <jy0922.shim@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Mark Yao <mark.yao@rock-chips.com>
Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/9cd9951d147ff810c1f6f68d79e7983361ed6b68.1516617243.git-series.maxime.ripard@free-electrons.com
2018-01-29 12:07:47 +01:00
Daniel Vetter
628d4c46ee Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux into drm-misc-next
Resync with drm-next, I have a patch which currently can't be applied
because drm-misc-next lacked the latest drm/i915 code.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2017-03-23 08:15:55 +01:00
Ville Syrjälä
6a0f9ebfc5 drm: Add mode_config .get_format_info() hook
Allow drivers to return a custom drm_format_info structure for special
fb layouts. We'll use this for the compression control surface in i915.

v2: Fix drm_get_format_info() kernel doc (Laurent)
    Don't pass 'dev' to the new hook (Laurent)
v3: s/compresssion/compression/ (Ben)

Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Link: http://patchwork.freedesktop.org/patch/msgid/20170321181218.10042-4-ville.syrjala@linux.intel.com
2017-03-22 19:45:00 +02:00
Philipp Zabel
ba2b5277dc drm: add RGB formats with separate alpha plane
Some hardware can read the alpha components separately and then
conditionally fetch color components only for non-zero alpha values.
This patch adds fourcc definitions for two-plane RGB formats with an
8-bit alpha channel on a second plane.

Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2017-03-15 15:42:30 +01:00
Eric Engestrom
b3c11ac267 drm: move allocation out of drm_get_format_name()
The function's behaviour was changed in 90844f0004, without changing
its signature, causing people to keep using it the old way without
realising they were now leaking memory.
Rob Clark also noticed it was also allocating GFP_KERNEL memory in
atomic contexts, breaking them.

Instead of having to allocate GFP_ATOMIC memory and fixing the callers
to make them cleanup the memory afterwards, let's change the function's
signature by having the caller take care of the memory and passing it to
the function.
The new parameter is a single-field struct in order to enforce the size
of its buffer and help callers to correctly manage their memory.

Fixes: 90844f0004 ("drm: make drm_get_format_name thread-safe")
Cc: Rob Clark <robdclark@gmail.com>
Cc: Christian König <christian.koenig@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Acked-by: Rob Clark <robdclark@gmail.com>
Acked-by: Sinclair Yeh <syeh@vmware.com> (vmwgfx)
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161112011309.9799-1-eric@engestrom.ch
2016-11-12 14:19:38 +01:00
Laurent Pinchart
488546fc4d drm: Don't export the drm_fb_get_bpp_depth() function
The function is only used by the drm_helper_mode_fill_fb_struct() core
function to fill the drm_framebuffer bpp and depth fields, used by
drivers that haven't been converted to use pixel formats directly yet.
It should not be used by new drivers, so inline it in its only caller.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1476744081-24485-14-git-send-email-laurent.pinchart@ideasonboard.com
2016-10-18 15:24:08 +05:30
Laurent Pinchart
333d2da5b7 drm: WARN when calling drm_format_info() for an unsupported format
The format helpers have historically treated unsupported formats as part
of the default case, returning values that are likely wrong. We can't
change this behaviour now without risking breaking drivers in difficult
to detect ways, but we can WARN on unsupported formats to catch faulty
callers.

The only exception is the framebuffer_check() function that calls
drm_format_info() to validate the format passed from userspace. This is
a valid use case that shouldn't generate a warning.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1476744081-24485-5-git-send-email-laurent.pinchart@ideasonboard.com
2016-10-18 15:21:38 +05:30
Laurent Pinchart
86c238aa51 drm: Implement the drm_format_*() helpers as drm_format_info() wrappers
Turn the drm_format_*() helpers into wrappers around the drm_format_info
lookup function to centralize all format information in a single place.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1476744081-24485-3-git-send-email-laurent.pinchart@ideasonboard.com
2016-10-18 15:21:17 +05:30
Laurent Pinchart
84770cc24f drm: Centralize format information
Various pieces of information about DRM formats (number of planes, color
depth, chroma subsampling, ...) are scattered across different helper
functions in the DRM core. Callers of those functions often need to
access more than a single parameter of the format, leading to
inefficiencies due to multiple lookups.

Centralize all format information in a data structure and create a
function to look up information based on the format 4CC.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1476744081-24485-2-git-send-email-laurent.pinchart@ideasonboard.com
2016-10-18 15:20:34 +05:30
Daniel Vetter
ec5e304747 drm: move drm_mode_legacy_fb_format to drm_fourcc.c
It's part of the drm fourcc handling code, mapping the old depth/bpp
values to new fourcc codes.

Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160829082757.17913-6-daniel.vetter@ffwll.ch
2016-08-29 15:37:28 +02:00
Eric Engestrom
d382814707 drm: remove const attribute to hint at caller that they now own the memory
Signed-off-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2016-08-16 14:06:53 +02:00
Eric Engestrom
90844f0004 drm: make drm_get_format_name thread-safe
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
[danvet: Clarify that the returned pointer must be freed with
kfree().]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2016-08-15 09:25:12 +02:00
Laurent Pinchart
ae4df11a0f drm: Move format-related helpers to drm_fourcc.c
The drm_crtc.c file is a mess, making the ABI documentation confusing
since all functions are in the same bag. Split the format-related
helpers to a new drm_fourcc.c file.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1465466048-2020-1-git-send-email-laurent.pinchart@ideasonboard.com
2016-06-09 11:58:50 +02:00