kernel/linux.git/drivers/gpu/drm/drm_blend.c, branch v6.1.168

drm/doc: Fix comment typo

2022-06-28T05:56:32+00:00

Replace apprpriately with appropriately. Fixes: 1e4d84c6589e9 ("drm/doc: Polish plane composition property docs") Signed-off-by: Marek Vasut Cc: Benjamin Gaignard Cc: Daniel Vetter Cc: Dmitry Baryshkov Cc: Maxime Ripard Cc: Sean Paul Cc: Simon Ser Cc: Ville Syrjälä Signed-off-by: Simon Ser Reviewed-by: Simon Ser Link: https://patchwork.freedesktop.org/patch/msgid/20220628003407.77765-1-marex@denx.de

drm/blend: fix typo in the comment

2022-03-16T08:36:13+00:00

The documentation for drm_rotation_simplify() uses DRM_MODE_ROTATE_X, while it's clear the comment should mention DRM_MODE_REFLECT_X instead. The example passes all flags except the DRM_MODE_REFLECT_X as supported and expects to eliminate this flag. Fixes: c2c446ad2943 ("drm: Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ to UAPI") Signed-off-by: Dmitry Baryshkov Reviewed-by: Simon Ser Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20220316074648.7009-1-dmitry.baryshkov@linaro.org

drm: drm_blend.c: Use tabs for code indents

2021-04-22T08:46:35+00:00

Remove space and use tabs for indent the code to follow the Linux kernel coding conventions. Problem found by checkpatch. Signed-off-by: Beatriz Martins de Carvalho Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/f441188f84aac2f9f72f36a42c88623b16cd1f87.1618828127.git.martinsdecarvalhobeatriz@gmail.com

drm/doc: introduce new section for standard plane properties

2020-12-17T15:56:40+00:00

Introduce a new "Standard Plane Properties" section for properties defined in drm_plane.c. Move the mis-placed IN_FORMATS docs there. Signed-off-by: Simon Ser Reviewed-by: Daniel Vetter Cc: Pekka Paalanen Link: https://patchwork.freedesktop.org/patch/msgid/20201217113220.102271-3-contact@emersion.fr

drm: fix kernel-doc warnings for SCALING_FILTER

2020-11-24T15:36:48+00:00

This patch fixes the following kernel-doc warnings: /home/simon/src/linux/Documentation/gpu/drm-kms:466: ./drivers/gpu/drm/drm_crtc.c:236: WARNING: Unexpected indentation. /home/simon/src/linux/Documentation/gpu/drm-kms:466: ./drivers/gpu/drm/drm_crtc.c:237: WARNING: Block quote ends without a blank line; unexpected unindent. /home/simon/src/linux/Documentation/gpu/drm-kms:472: ./drivers/gpu/drm/drm_blend.c:203: WARNING: Unexpected indentation. /home/simon/src/linux/Documentation/gpu/drm-kms:472: ./drivers/gpu/drm/drm_blend.c:204: WARNING: Block quote ends without a blank line; unexpected unindent. Signed-off-by: Simon Ser Fixes: 5c759eda9b04 ("drm: Introduce plane and CRTC scaling filter properties") Cc: Pankaj Bharadiya Cc: Jani Nikula Cc: Ville Syrjälä Cc: Uma Shankar Acked-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/zJEUxNx4GwiY4FnqlVsuXdAWuH624SQ9VfN54NeH5E@cp7-web-043.plabs.ch

drm: Introduce plane and CRTC scaling filter properties

2020-10-21T09:19:54+00:00

Introduce per-plane and per-CRTC scaling filter properties to allow userspace to select the driver's default scaling filter or Nearest-neighbor(NN) filter for upscaling operations on CRTC and plane. Drivers can set up this property for a plane by calling drm_plane_create_scaling_filter() and for a CRTC by calling drm_crtc_create_scaling_filter(). NN filter works by filling in the missing color values in the upscaled image with that of the coordinate-mapped nearest source pixel value. NN filter for integer multiple scaling can be particularly useful for for pixel art games that rely on sharp, blocky images to deliver their distinctive look. changes since: v6: * Move property doc to existing "Standard CRTC Properties" and "Plane Composition Properties" doc comments (Simon) changes since v3: * Refactor code, add new function for common code (Ville) changes since v2: * Create per-plane and per-CRTC scaling filter property (Ville) changes since v1: * None changes since RFC: * Add separate properties for plane and CRTC (Ville) Link: https://github.com/xbmc/xbmc/pull/18194 Link: https://github.com/xbmc/xbmc/pull/18567 Reviewed-by: Ville Syrjälä Reviewed-by: Uma Shankar Acked-by: Simon Ser Acked-by: Daniel Vetter Signed-off-by: Pankaj Bharadiya Signed-off-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/20201020161427.6941-2-pankaj.laxminarayan.bharadiya@intel.com

drm: plane: Verify that no or all planes have a zpos property

2020-05-13T23:10:52+00:00

The zpos property is used by userspace to sort the order of planes. While the property is not mandatory for drivers to implement, mixing planes with and without zpos confuses userspace, and shall not be allowed. Clarify this in the documentation and warn at runtime if the drivers mixes planes with and without zpos properties. Signed-off-by: Laurent Pinchart Acked-by: Sam Ravnborg Reviewed-by: Daniel Vetter

drm: add docs about the IN_FORMATS plane property

2020-03-31T09:12:42+00:00

This is a standard property attached to planes in drm_universal_plane_init when drm_mode_config.allow_fb_modifiers is true. Signed-off-by: Simon Ser Cc: Daniel Vetter Cc: Daniel Stone Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/mHOtz80Wa-x3A5Lz5ETTM65VUMfW1j6b-iCuvIy1RzOM1EloHPqAb2MnbU8ygZi0ABaLrxuN6pzu0v3QRn83125C0bXuHoo-DQWWEd80fdw=@emersion.fr

drm: two planes with the same zpos have undefined ordering

2019-10-09T18:04:55+00:00

Currently the property docs don't specify whether it's okay for two planes to have the same zpos value and what user-space should expect in this case. The unspoken, legacy rule used in the past was to make user-space figure out the zpos from object IDs. However some drivers break this rule, that's why the ordering is documented as unspecified in case the zpos property is missing. User-space should rely on the zpos property only. There are some cases in which user-space might read identical zpos values for different planes. For instance, in case the property is mutable, user-space might set two planes' zpos to the same value. This is necessary to support user-space using the legacy DRM API where atomic commits are not possible: user-space needs to update the planes' zpos one by one. Because of this, user-space should handle multiple planes with the same zpos. While at it, remove the assumption that zpos is only for overlay planes. Additionally, update the drm_plane_state.zpos docs to clarify that zpos disambiguation via plane object IDs is a recommendation for drivers, not something user-space can rely on. In other words, when user-space sets the same zpos on two planes, drivers should rely on the plane object ID. v2: clarify drm_plane_state.zpos docs (Daniel) v3: zpos is for all planes (Marius, Daniel) v4: completely reword the drm_plane_state.zpos docs to make it clear the recommendation to use plane IDs is for drivers in case user-space uses duplicate zpos values (Pekka) v5: reword commit message (Pekka, James) v6: remove mention of Arm GPUs having planes which can't overlap, because this isn't uAPI yet (Daniel) Signed-off-by: Simon Ser Reviewed-by: Pekka Paalanen Cc: Marius Vlad Cc: Daniel Vetter Cc: James Qian Wang Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/T5nHrvXH0GKOp6ONaFHk-j2cwEb4_4C_sBz9rNw8mmPACuut-DQqC74HMAFKZH3_Q15E8a3YnmKCxap-djKA71VVZv_T-tFxaB0he13O7yA=@emersion.fr

drm/blend: Define the direction of Z position values

2019-09-06T18:23:21+00:00

We forgot that. Proof is the one igt testcase we have: https://gitlab.freedesktop.org/drm/igt-gpu-tools/blob/master/tests/kms_atomic.c#L280 While at it also document that we have immutable zpos properties in some cases. Reported-by: Pekka Paalanen Cc: Pekka Paalanen Reviewed-by: Pekka Paalanen Cc: Ilia Mirkin Acked-by: Ilia Mirkin Reviewed-by: Daniel Stone Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20190906144459.16025-1-daniel.vetter@ffwll.ch