wireguard-linux/drivers/gpu/drm/drm_blend.c, branch jd/unified-crypt-queue

drm: two planes with the same zpos have undefined ordering

2019-10-09T18:04:55Z

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:21Z

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

drm: drop use of drmP.h in drm/*

2019-05-27T16:07:03Z

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 Acked-by: Daniel Vetter Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Sean Paul Cc: David Airlie Link: https://patchwork.freedesktop.org/patch/msgid/20190526173535.32701-8-sam@ravnborg.org

drm: Clarify DRM_MODE_REFLECT_X/Y documentation

2018-09-11T10:21:30Z

DRM_MODE_REFLECT_X and DRM_MODE_REFLECT_Y meaning seems a bit unclear to me, so try to clarify that with a bit of ascii graphics. Changes since v1: - Move the ascii graphics in the kerneldoc where all plane properties are already documented and make sure it's properly rendered, suggestested by Daniel Vetter. Signed-off-by: Alexandru Gheorghe Reviewed-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20180910172946.18539-1-alexandru-cosmin.gheorghe@arm.com

drm: Add per-plane pixel blend mode property

2018-08-24T16:31:37Z

Pixel blend modes represent the alpha blending equation selection, describing how the pixels from the current plane are composited with the background. Adds a pixel_blend_mode to drm_plane_state and a blend_mode_property to drm_plane, and related support functions. Defines three blend modes in drm_blend.h. Changes since v1: - Moves the blending equation into the DOC comment - Refines the comments of drm_plane_create_blend_mode_property to not enumerate the #defines, but instead the string values - Uses fg.* instead of pixel.* and plane_alpha instead of plane.alpha Changes since v2: - Refines the comments of drm_plane_create_blend_mode_property: 1) Puts the descriptions (after the ":") on a new line 2) Adds explaining why @supported_modes need PREMUL as default Changes since v3: - Refines drm_plane_create_blend_mode_property(). drm_property_add_enum() can calculate the index itself just fine, so no point in having the caller pass it in. - Since the current DRM assumption is that alpha is premultiplied as default, define DRM_MODE_BLEND_PREMULTI as 0 will be better. - Refines some comments. Changes since v4: - Adds comments in drm_blend.h. - Removes setting default value in drm_plane_create_blend_mode_property() as it is already in __drm_atomic_helper_plane_reset(). - Fixes to use state->pixel_blend_mode instead of using plane->state->pixel_blend_mode in reset function. - Rebases on drm-misc-next. Reviewed-by: Liviu Dudau Signed-off-by: Lowry Li Signed-off-by: Ayan Kumar Halder Reviewed-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/245734/

drm/blend: Add a generic alpha property

2018-04-16T19:17:29Z

Some drivers duplicate the logic to create a property to store a per-plane alpha. This is especially useful if we ever want to support extra protocols for Wayland like: https://lists.freedesktop.org/archives/wayland-devel/2017-August/034741.html Let's create a helper in order to move that to the core. Acked-by: Maarten Lankhorst Acked-by: Sean Paul Reviewed-by: Boris Brezillon Reviewed-by: Eric Anholt Reviewed-by: Laurent Pinchart Reviewed-by: Paul Kocialkowski Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/6e1ce0db78fcfc407e94913c64819e65109d034d.1523432341.git-series.maxime.ripard@bootlin.com

drm/docs: Align layout of optional plane blending properties

2018-02-20T11:10:46Z

Just a bit of drive-by OCD. All the other property docs use enumerations, for some nice visual consistency. It also neatly highlights the property name. Reviewed-by: Thierry Reding Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20180219225356.24996-2-daniel.vetter@ffwll.ch

drm/atomic-helper: Make zpos property kerneldoc less misleading

2017-12-14T13:20:35Z

kerneldoc for drm_plane_create_zpos_property() says that the DRM core will automatically calculate the normalized zpos values, but it doesn't actually do that anymore since commit 38d868e41c4b ("drm: Don't force all planes to be added to the state due to zpos"). Instead, drivers are supposed to explicitly call the drm_atomic_normalize_zpos() function. Change the kerneldoc comment to reflect that. v2: reference the commit that introduced the kerneldoc unclarity Reviewed-by: Daniel Vetter Signed-off-by: Thierry Reding Link: https://patchwork.freedesktop.org/patch/msgid/20171120150959.26913-1-thierry.reding@gmail.com

mm: treewide: remove GFP_TEMPORARY allocation flag

2017-09-14T01:53:16Z

GFP_TEMPORARY was introduced by commit e12ba74d8ff3 ("Group short-lived and reclaimable kernel allocations") along with __GFP_RECLAIMABLE. It's primary motivation was to allow users to tell that an allocation is short lived and so the allocator can try to place such allocations close together and prevent long term fragmentation. As much as this sounds like a reasonable semantic it becomes much less clear when to use the highlevel GFP_TEMPORARY allocation flag. How long is temporary? Can the context holding that memory sleep? Can it take locks? It seems there is no good answer for those questions. The current implementation of GFP_TEMPORARY is basically GFP_KERNEL | __GFP_RECLAIMABLE which in itself is tricky because basically none of the existing caller provide a way to reclaim the allocated memory. So this is rather misleading and hard to evaluate for any benefits. I have checked some random users and none of them has added the flag with a specific justification. I suspect most of them just copied from other existing users and others just thought it might be a good idea to use without any measuring. This suggests that GFP_TEMPORARY just motivates for cargo cult usage without any reasoning. I believe that our gfp flags are quite complex already and especially those with highlevel semantic should be clearly defined to prevent from confusion and abuse. Therefore I propose dropping GFP_TEMPORARY and replace all existing users to simply use GFP_KERNEL. Please note that SLAB users with shrinkers will still get __GFP_RECLAIMABLE heuristic and so they will be placed properly for memory fragmentation prevention. I can see reasons we might want some gfp flag to reflect shorterm allocations but I propose starting from a clear semantic definition and only then add users with proper justification. This was been brought up before LSF this year by Matthew [1] and it turned out that GFP_TEMPORARY really doesn't have a clear semantic. It seems to be a heuristic without any measured advantage for most (if not all) its current users. The follow up discussion has revealed that opinions on what might be temporary allocation differ a lot between developers. So rather than trying to tweak existing users into a semantic which they haven't expected I propose to simply remove the flag and start from scratch if we really need a semantic for short term allocations. [1] http://lkml.kernel.org/r/20170118054945.GD18349@bombadil.infradead.org [akpm@linux-foundation.org: fix typo] [akpm@linux-foundation.org: coding-style fixes] [sfr@canb.auug.org.au: drm/i915: fix up] Link: http://lkml.kernel.org/r/20170816144703.378d4f4d@canb.auug.org.au Link: http://lkml.kernel.org/r/20170728091904.14627-1-mhocko@kernel.org Signed-off-by: Michal Hocko Signed-off-by: Stephen Rothwell Acked-by: Mel Gorman Acked-by: Vlastimil Babka Cc: Matthew Wilcox Cc: Neil Brown Cc: "Theodore Ts'o" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

drm: Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ to UAPI

2017-05-22T07:49:48Z

Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ defines to the UAPI as a convenience. Ideally the DRM_ROTATE_ and DRM_REFLECT_ property ids are looked up through the atomic API, but realizing that userspace is likely to take shortcuts and assume that the enum values are what is sent over the wire. As a result these defines are provided purely as a convenience to userspace applications. Changes since v3: - Switched away from past tense in comments - Add define name change to previously mis-spelled DRM_REFLECT_X comment - Improved the comment for the DRM_MODE_REFLECT_ comment Changes since v2: - Changed define prefix from DRM_MODE_PROP_ to DRM_MODE_ - Fix compilation errors - Changed comment formatting - Deduplicated comment lines - Clarified DRM_MODE_PROP_REFLECT_ comment Changes since v1: - Moved defines from drm.h to drm_mode.h - Changed define prefix from DRM_ to DRM_MODE_PROP_ - Updated uses of the defines to the new prefix - Removed include from drm_rect.c - Stopped using the BIT() macro Signed-off-by: Robert Foss Reviewed-by: Emil Velikov Reviewed-by: Sinclair Yeh Acked-by: Liviu Dudau Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20170519205017.23307-2-robert.foss@collabora.com