drm: Export drm_plane_has_format()

Export drm_plane_has_format() so that drivers can use it.

v2: add kerneldoc

Reviewed-by: Jani Nikula <[email protected]>
Reviewed-by: Daniel Vetter <daniel.v

drm: Export drm_plane_has_format()

Export drm_plane_has_format() so that drivers can use it.

v2: add kerneldoc

Reviewed-by: Jani Nikula <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Daniel Vetter <[email protected]>
Acked-by: Daniel Stone <[email protected]>
Acked-by: Thomas Zimmermann <[email protected]>

show more ...

drm: Rename drm_plane_check_pixel_format() to drm_plane_has_format()

Rename drm_plane_check_pixel_format() to drm_plane_has_format()
and change the return type accordingly. Allows one to write
more

drm: Rename drm_plane_check_pixel_format() to drm_plane_has_format()

Rename drm_plane_check_pixel_format() to drm_plane_has_format()
and change the return type accordingly. Allows one to write
more natural code.

Also matches drm_any_plane_has_format() better.

Reviewed-by: Jani Nikula <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Daniel Vetter <[email protected]>
Acked-by: Thomas Zimmermann <[email protected]>

show more ...

drm: Fix plane SIZE_HINTS property docs

Fix the typos in the plane SIZE_HINTS kernel docs.

Reported-by: Stephen Rothwell <[email protected]>
Fixes: 9677547d8362 ("drm: Introduce plane SIZE_HINTS

drm: Fix plane SIZE_HINTS property docs

Fix the typos in the plane SIZE_HINTS kernel docs.

Reported-by: Stephen Rothwell <[email protected]>
Fixes: 9677547d8362 ("drm: Introduce plane SIZE_HINTS property")
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Dmitry Baryshkov <[email protected]>

show more ...

drm: Introduce plane SIZE_HINTS property

Add a new immutable plane property by which a plane can advertise
a handful of recommended plane sizes. This would be mostly exposed
by cursor planes as a sl

drm: Introduce plane SIZE_HINTS property

Add a new immutable plane property by which a plane can advertise
a handful of recommended plane sizes. This would be mostly exposed
by cursor planes as a slightly more capable replacement for
the DRM_CAP_CURSOR_WIDTH/HEIGHT caps, which can only declare
a one size fits all limit for the whole device.

Currently eg. amdgpu/i915/nouveau just advertize the max cursor
size via the cursor size caps. But always using the max sized
cursor can waste a surprising amount of power, so a better
strategy is desirable.

Most other drivers don't specify any cursor size at all, in
which case the ioctl code just claims that 64x64 is a great
choice. Whether that is actually true is debatable.

A poll of various compositor developers informs us that
blindly probing with setcursor/atomic ioctl to determine
suitable cursor sizes is not acceptable, thus the
introduction of the new property to supplant the cursor
size caps. The compositor will now be free to select a
more optimal cursor size from the short list of options.

Note that the reported sizes (either via the property or the
caps) make no claims about things such as plane scaling. So
these things should only really be consulted for simple
"cursor like" use cases.

Userspace consumer in the form of mutter seems ready:
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3165

v2: Try to add some docs
v3: Specify that value 0 is reserved for future use (basic idea from Jonas)
Drop the note about typical hardware (Pekka)
v4: Update the docs to indicate the list is "in order of preference"
Add a a link to the mutter MR
v5: Limit to cursors only for now (Simon)

Cc: Jonas Ådahl <[email protected]>
Cc: Sameer Lattannavar <[email protected]>
Reviewed-by: Sebastian Wick <[email protected]>
Reviewed-by: Simon Ser <[email protected]>
Acked-by: Daniel Stone <[email protected]>
Acked-by: Harry Wentland <[email protected]>
Acked-by: Pekka Paalanen <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

drm: Don't unref the same fb many times by mistake due to deadlock handling

If we get a deadlock after the fb lookup in drm_mode_page_flip_ioctl()
we proceed to unref the fb and then retry the whole

drm: Don't unref the same fb many times by mistake due to deadlock handling

If we get a deadlock after the fb lookup in drm_mode_page_flip_ioctl()
we proceed to unref the fb and then retry the whole thing from the top.
But we forget to reset the fb pointer back to NULL, and so if we then
get another error during the retry, before the fb lookup, we proceed
the unref the same fb again without having gotten another reference.
The end result is that the fb will (eventually) end up being freed
while it's still in use.

Reset fb to NULL once we've unreffed it to avoid doing it again
until we've done another fb lookup.

This turned out to be pretty easy to hit on a DG2 when doing async
flips (and CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y). The first symptom I
saw that drm_closefb() simply got stuck in a busy loop while walking
the framebuffer list. Fortunately I was able to convince it to oops
instead, and from there it was easier to track down the culprit.

Cc: [email protected]
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Acked-by: Javier Martinez Canillas <[email protected]>

show more ...

Revert "drm: Introduce pixel_source DRM plane property"

This reverts commit e50e5fed41c7eed2db4119645bf3480ec43fec11.

Although the Solid Fill planes patchset got all reviews and
acknowledgements, i

Revert "drm: Introduce pixel_source DRM plane property"

This reverts commit e50e5fed41c7eed2db4119645bf3480ec43fec11.

Although the Solid Fill planes patchset got all reviews and
acknowledgements, it doesn't fulfill requirements for the new uABI. It
has neither corresponding open-source userspace implementation nor the
IGT tests coverage. Reverting this patchset until userspace obligations
are fulfilled.

Acked-by: Simon Ser <[email protected]>
Acked-by: Maxime Ripard <[email protected]>
Signed-off-by: Dmitry Baryshkov <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

Revert "drm/atomic: Add solid fill data to plane state dump"

This reverts commit e86413f5442ee094e66b3e75f2d3419ed0df9520.

Although the Solid Fill planes patchset got all reviews and
acknowledgemen

Revert "drm/atomic: Add solid fill data to plane state dump"

This reverts commit e86413f5442ee094e66b3e75f2d3419ed0df9520.

Although the Solid Fill planes patchset got all reviews and
acknowledgements, it doesn't fulfill requirements for the new uABI. It
has neither corresponding open-source userspace implementation nor the
IGT tests coverage. Reverting this patchset until userspace obligations
are fulfilled.

Acked-by: Simon Ser <[email protected]>
Acked-by: Maxime Ripard <[email protected]>
Signed-off-by: Dmitry Baryshkov <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

drm/atomic: Add solid fill data to plane state dump

Add solid_fill property data to the atomic plane state dump.

Reviewed-by: Dmitry Baryshkov <[email protected]>
Acked-by: Harry Wentland

drm/atomic: Add solid fill data to plane state dump

Add solid_fill property data to the atomic plane state dump.

Reviewed-by: Dmitry Baryshkov <[email protected]>
Acked-by: Harry Wentland <[email protected]>
Acked-by: Sebastian Wick <[email protected]>
Signed-off-by: Jessica Zhang <[email protected]>
Signed-off-by: Dmitry Baryshkov <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

drm: Introduce pixel_source DRM plane property

Add support for pixel_source property to drm_plane and related
documentation. In addition, force pixel_source to
DRM_PLANE_PIXEL_SOURCE_FB in DRM_IOCTL

drm: Introduce pixel_source DRM plane property

Add support for pixel_source property to drm_plane and related
documentation. In addition, force pixel_source to
DRM_PLANE_PIXEL_SOURCE_FB in DRM_IOCTL_MODE_SETPLANE as to not break
legacy userspace.

This enum property will allow user to specify a pixel source for the
plane. Possible pixel sources will be defined in the
drm_plane_pixel_source enum.

Currently, the only pixel sources are DRM_PLANE_PIXEL_SOURCE_FB (the
default value) and DRM_PLANE_PIXEL_SOURCE_NONE.

Acked-by: Dmitry Baryshkov <[email protected]>
Acked-by: Pekka Paalanen <[email protected]>
Acked-by: Harry Wentland <[email protected]>
Acked-by: Sebastian Wick <[email protected]>
Acked-by: Simon Ser <[email protected]>
Signed-off-by: Jessica Zhang <[email protected]>
Signed-off-by: Dmitry Baryshkov <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

drm/plane: Extend damage tracking kernel-doc

The "Damage Tracking Properties" section in the documentation doesn't have
info about the two type of damage handling: frame damage vs buffer damage.

Ad

drm/plane: Extend damage tracking kernel-doc

The "Damage Tracking Properties" section in the documentation doesn't have
info about the two type of damage handling: frame damage vs buffer damage.

Add it to the section and mention that helpers only support frame damage,
and how drivers handling buffer damage can indicate that the damage clips
should be ignored.

Also add references to further documentation about the two damage types.

Suggested-by: Simon Ser <[email protected]>
Signed-off-by: Javier Martinez Canillas <[email protected]>
Reviewed-by: Simon Ser <[email protected]>
Reviewed-by: Thomas Zimmermann <[email protected]>
Reviewed-by: Zack Rusin <[email protected]>
Acked-by: Sima Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

drm: Introduce documentation for hotspot properties

To clarify the intent and reasoning behind the hotspot properties
introduce userspace documentation that goes over cursor handling
in para-virtual

drm: Introduce documentation for hotspot properties

To clarify the intent and reasoning behind the hotspot properties
introduce userspace documentation that goes over cursor handling
in para-virtualized environments.

The documentation is generic enough to not special case for any
specific hypervisor and should apply equally to all.

Signed-off-by: Zack Rusin <[email protected]>
Acked-by: Pekka Paalanen <[email protected]>
Reviewed-by: Javier Martinez Canillas <[email protected]>
Signed-off-by: Michael Banack <[email protected]>
Signed-off-by: Javier Martinez Canillas <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

drm: Remove legacy cursor hotspot code

Atomic modesetting supports mouse cursor offsets via the hotspot
properties that are created on cursor planes. All drivers which
support hotspots are atomic an

drm: Remove legacy cursor hotspot code

Atomic modesetting supports mouse cursor offsets via the hotspot
properties that are created on cursor planes. All drivers which
support hotspots are atomic and the legacy code has been implemented
in terms of the atomic properties as well.

Due to the above the lagacy cursor hotspot code is no longer used or
needed and can be removed.

Signed-off-by: Zack Rusin <[email protected]>
Cc: Maarten Lankhorst <[email protected]>
Cc: Maxime Ripard <[email protected]>
Cc: Thomas Zimmermann <[email protected]>
Cc: David Airlie <[email protected]>
Cc: Daniel Vetter <[email protected]>
Reviewed-by: Javier Martinez Canillas <[email protected]>
Signed-off-by: Javier Martinez Canillas <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

drm/atomic: Add support for mouse hotspots

Atomic modesetting code lacked support for specifying mouse cursor
hotspots. The legacy kms DRM_IOCTL_MODE_CURSOR2 had support for setting
the hotspot but

drm/atomic: Add support for mouse hotspots

Atomic modesetting code lacked support for specifying mouse cursor
hotspots. The legacy kms DRM_IOCTL_MODE_CURSOR2 had support for setting
the hotspot but the functionality was not implemented in the new atomic
paths.

Due to the lack of hotspots in the atomic paths userspace compositors
completely disable atomic modesetting for drivers that require it (i.e.
all paravirtualized drivers).

This change adds hotspot properties to the atomic codepaths throughtout
the DRM core and will allow enabling atomic modesetting for virtualized
drivers in the userspace.

Signed-off-by: Zack Rusin <[email protected]>
Cc: Maarten Lankhorst <[email protected]>
Cc: Maxime Ripard <[email protected]>
Cc: Thomas Zimmermann <[email protected]>
Cc: David Airlie <[email protected]>
Cc: Daniel Vetter <[email protected]>
Reviewed-by: Javier Martinez Canillas <[email protected]>
Signed-off-by: Javier Martinez Canillas <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

drm: Disable the cursor plane on atomic contexts with virtualized drivers

Cursor planes on virtualized drivers have special meaning and require
that the clients handle them in specific ways, e.g. th

drm: Disable the cursor plane on atomic contexts with virtualized drivers

Cursor planes on virtualized drivers have special meaning and require
that the clients handle them in specific ways, e.g. the cursor plane
should react to the mouse movement the way a mouse cursor would be
expected to and the client is required to set hotspot properties on it
in order for the mouse events to be routed correctly.

This breaks the contract as specified by the "universal planes". Fix it
by disabling the cursor planes on virtualized drivers while adding
a foundation on top of which it's possible to special case mouse cursor
planes for clients that want it.

Disabling the cursor planes makes some kms compositors which were broken,
e.g. Weston, fallback to software cursor which works fine or at least
better than currently while having no effect on others, e.g. gnome-shell
or kwin, which put virtualized drivers on a deny-list when running in
atomic context to make them fallback to legacy kms and avoid this issue.

Signed-off-by: Zack Rusin <[email protected]>
Fixes: 681e7ec73044 ("drm: Allow userspace to ask for universal plane list (v2)")
Cc: <[email protected]> # v5.4+
Cc: Maarten Lankhorst <[email protected]>
Cc: Maxime Ripard <[email protected]>
Cc: Thomas Zimmermann <[email protected]>
Cc: David Airlie <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Dave Airlie <[email protected]>
Cc: Gerd Hoffmann <[email protected]>
Cc: Hans de Goede <[email protected]>
Cc: Gurchetan Singh <[email protected]>
Cc: Chia-I Wu <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Acked-by: Pekka Paalanen <[email protected]>
Reviewed-by: Javier Martinez Canillas <[email protected]>
Acked-by: Simon Ser <[email protected]>
Signed-off-by: Javier Martinez Canillas <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

drm/docs: Explicitly document default CRTC background behavior

Add a paragraph explaining that the default behavior for areas which
are not covered by planes or where planes are blending with the CR

drm/docs: Explicitly document default CRTC background behavior

Add a paragraph explaining that the default behavior for areas which
are not covered by planes or where planes are blending with the CRTC
background, is black.

This is alluded to in the "pixel blend mode" property docs, but not
called out explicitly.

Reviewed-by: Simon Ser <[email protected]>
Signed-off-by: Sean Paul <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

drm/plane: Allocate planes with drm_universal_plane_alloc()

Provide drm_univeral_plane_alloc() to allocate and initialize a
plane. Code for non-atomic drivers uses this pattern. Convert them to
the

drm/plane: Allocate planes with drm_universal_plane_alloc()

Provide drm_univeral_plane_alloc() to allocate and initialize a
plane. Code for non-atomic drivers uses this pattern. Convert them to
the new function. The modeset helpers contain a quirk for handling their
color formats differently. Set the flag outside plane allocation.

The new function is already deprecated to some extend. Drivers should
rather use drmm_univeral_plane_alloc() or drm_universal_plane_init().

v2:
* kerneldoc fixes (Javier)
* grammar fixes in commit message

Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: Javier Martinez Canillas <[email protected]>
Reviewed-by: Lyude Paul <[email protected]> # nouveau
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

drm/plane: Remove drm_plane_init()

Open-code drm_plane_init() and remove the function from DRM. The
implementation of drm_plane_init() is a simple wrapper around a call
to drm_universal_plane_init()

drm/plane: Remove drm_plane_init()

Open-code drm_plane_init() and remove the function from DRM. The
implementation of drm_plane_init() is a simple wrapper around a call
to drm_universal_plane_init(), so drivers can just use that instead.

Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: Javier Martinez Canillas <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Reviewed-by: Lyude Paul <[email protected]> # nouveau
Acked-by: Jyri Sarha <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

drm/plane: Move range check for format_count earlier

While the check for format_count > 64 in __drm_universal_plane_init()
shouldn't be hit (it's a WARN_ON), in its current position it will then
lea

drm/plane: Move range check for format_count earlier

While the check for format_count > 64 in __drm_universal_plane_init()
shouldn't be hit (it's a WARN_ON), in its current position it will then
leak the plane->format_types array and fail to call
drm_mode_object_unregister() leaking the modeset identifier. Move it to
the start of the function to avoid allocating those resources in the
first place.

Signed-off-by: Steven Price <[email protected]>
Signed-off-by: Liviu Dudau <[email protected]>
Link: https://lore.kernel.org/dri-devel/[email protected]/

show more ...

drm: add support modifiers for drivers whose planes only support linear layout

The LINEAR modifier is advertised as default if a driver doesn't specify
modifiers.

v2:
- rebase to the latest master

drm: add support modifiers for drivers whose planes only support linear layout

The LINEAR modifier is advertised as default if a driver doesn't specify
modifiers.

v2:
- rebase to the latest master branch (5.16.0+)
+ "drm/plane: Make format_mod_supported truly optional" patch [1]
[1] https://patchwork.freedesktop.org/patch/467940/?series=98255&rev=3

v3:
- change the order as follows:
1. add fb_modifiers_not_supported flag
2. add default modifiers
3. remove allow_fb_modifiers flag

v5:
- change default_modifiers array from non-static to static
- remove terminator in default_modifiers array
- use ARRAY_SIZE to get the format_modifier_count
- update sanity check in plane init func to use the
fb_modifiers_not_supported
- modify kernel docs

Signed-off-by: Tomohito Esaki <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

drm/plane: Make format_mod_supported truly optional

The documentation for "drm_plane_funcs.format_mod_supported" reads:

This *optional* hook is used for the DRM to determine if the given
format

drm/plane: Make format_mod_supported truly optional

The documentation for "drm_plane_funcs.format_mod_supported" reads:

This *optional* hook is used for the DRM to determine if the given
format/modifier combination is valid for the plane. This allows the
DRM to generate the correct format bitmask (which formats apply to
which modifier), and to validate modifiers at atomic_check time.

*If not present*, then any modifier in the plane's modifier
list is allowed with any of the plane's formats.

However, where the function is not present, an invalid IN_FORMATS blob
property with modifiers but no formats is exposed to user-space.

This breaks the latest Weston [1]. For testing purposes, I extracted the
affected code to a standalone program [2].

Make "create_in_format_blob" behave as documented.

[1] https://gitlab.freedesktop.org/wayland/weston/-/blob/9.0/libweston/backend-drm/kms.c#L431
[2] https://github.com/JoseExposito/drm-sandbox/blob/main/in_formats.c

Signed-off-by: José Expósito <[email protected]>
Reviewed-by: Simon Ser <[email protected]>
Signed-off-by: Simon Ser <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

drm: Fix typo in comments

fix typo for drm

v1->v2:
respin with the change "iff ==> implies that"

Signed-off-by: Cai Huoqing <[email protected]>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll

drm: Fix typo in comments

fix typo for drm

v1->v2:
respin with the change "iff ==> implies that"

Signed-off-by: Cai Huoqing <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

drm/plane: Move drm_plane_enable_fb_damage_clips into core

We're trying to have a fairly strict split between core functionality
that defines the uapi, including the docs, and the helper functions t

drm/plane: Move drm_plane_enable_fb_damage_clips into core

We're trying to have a fairly strict split between core functionality
that defines the uapi, including the docs, and the helper functions to
implement it.

Move drm_plane_enable_fb_damage_clips and associated kerneldoc into
drm_plane from drm_damage_helper.c to fix this.

Reviewed-by: José Roberto de Souza <[email protected]>
Cc: Ville Syrjälä <[email protected]>
Cc: Gwan-gyeong Mun <[email protected]>
Cc: José Roberto de Souza <[email protected]>
Cc: Hans de Goede <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Cc: Maarten Lankhorst <[email protected]>
Cc: Maxime Ripard <[email protected]>
Cc: Thomas Zimmermann <[email protected]>
Cc: David Airlie <[email protected]>
Cc: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

drm/plane: check that fb_damage is set up when used

There's two stages of manual upload/invalidate displays:
- just handling dirtyfb and uploading the entire fb all the time
- looking at damage clip

drm/plane: check that fb_damage is set up when used

There's two stages of manual upload/invalidate displays:
- just handling dirtyfb and uploading the entire fb all the time
- looking at damage clips

In the latter case we support it through fbdev emulation (with
fb_defio), atomic property, and with the dirtfy clip rects.

Make sure at least the atomic property is set up as the main official
interface for this. Ideally we'd also check that
drm_atomic_helper_dirtyfb() is used and that fbdev defio is set up,
but that's quite a bit harder to do. Ideas very much welcome.

From a cursor audit drivers seem to be getting this right mostly, but
better to make sure. At least no one is bypassing the accessor
function.

v2:
- use drm_warn_once with a meaningful warning string (José)
- don't splat in the atomic check code for everyone (intel-gfx-ci)

Reviewed-by: José Roberto de Souza <[email protected]> (v1)
Cc: Ville Syrjälä <[email protected]>
Cc: Gwan-gyeong Mun <[email protected]>
Cc: José Roberto de Souza <[email protected]>
Cc: Hans de Goede <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Cc: Maarten Lankhorst <[email protected]>
Cc: Maxime Ripard <[email protected]>
Cc: Thomas Zimmermann <[email protected]>
Cc: David Airlie <[email protected]>
Cc: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

drm/modifiers: Enforce consistency between the cap an IN_FORMATS

It's very confusing for userspace to have to deal with inconsistencies
here, and some drivers screwed this up a bit. Most just ommitt

drm/modifiers: Enforce consistency between the cap an IN_FORMATS

It's very confusing for userspace to have to deal with inconsistencies
here, and some drivers screwed this up a bit. Most just ommitted the
format list when they meant to say that only linear modifier is
allowed, but some also meant that only implied modifiers are
acceptable (because actually none of the planes registered supported
modifiers).

Now that this is all done consistently across all drivers, document
the rules and enforce it in the drm core.

v2:
- Make the capability a link (Simon)
- Note that all is lost before 5.1.

v3:
- Use drm_WARN_ON (Lyude)

Acked-by: Pekka Paalanen <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
Reviewed-by: Lyude Paul <[email protected]>
Acked-by: Maxime Ripard <[email protected]>
Cc: Simon Ser <[email protected]>
Reviewed-by: Lucas Stach <[email protected]>
Cc: Pekka Paalanen <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Cc: Maarten Lankhorst <[email protected]>
Cc: Maxime Ripard <[email protected]>
Cc: Thomas Zimmermann <[email protected]>
Cc: David Airlie <[email protected]>
Cc: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

drm: Switch to %p4cc format modifier

Switch DRM drivers from drm_get_format_name() to %p4cc. This gets rid of a
large number of temporary variables at the same time.

Signed-off-by: Sakari Ailus <sa

drm: Switch to %p4cc format modifier

Switch DRM drivers from drm_get_format_name() to %p4cc. This gets rid of a
large number of temporary variables at the same time.

Signed-off-by: Sakari Ailus <[email protected]>
Reviewed-by: Petr Mladek <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Acked-by: Thomas Zimmermann <[email protected]>
Signed-off-by: Thomas Zimmermann <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...