kernel/drivers/gpu/drm/drm_blend.c, branch linux-4.17.y

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

drm/blend: Fix comment typ-o

2017-05-22T07:44:36Z

Fix DRM_REFELCT_Y -> DRM_REFLECT_Y. Signed-off-by: Robert Foss Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20170519205017.23307-1-robert.foss@collabora.com

drm/blend: Use new atomic iterator macros.

2017-03-06T10:43:43Z

There are new iterator macros that annotate whether the new or old state should be used. This is better than using a state that depends on whether it's called before or after swap. For clarity, also rename the variables from $obj_state to (old,new)_$obj_state as well. Signed-off-by: Maarten Lankhorst Link: http://patchwork.freedesktop.org/patch/msgid/1487256430-7625-6-git-send-email-maarten.lankhorst@linux.intel.com Reviewed-by: Laurent Pinchart Tested-by: Laurent Pinchart

drm/atomic: Convert get_existing_state callers to get_old/new_state, v4.

2017-03-06T10:43:05Z

This is a straightforward conversion that converts all the users of get_existing_state in atomic core to use get_old_state or get_new_state Changes since v1: - Fix using the wrong state in drm_atomic_helper_update_legacy_modeset_state. Changes since v2: - Use the correct state in disable_outputs() Changes since v3: - Rebase for link status training. Signed-off-by: Maarten Lankhorst Link: http://patchwork.freedesktop.org/patch/msgid/df91a9f9-005e-bcbd-1f74-03c38e1e21dd@linux.intel.com Reviewed-by: Laurent Pinchart Tested-by: Laurent Pinchart

drm/kms-core: Use recommened kerneldoc for struct member refs

2017-01-25T15:30:34Z

I just learned that &struct_name.member_name works and looks pretty even. It doesn't (yet) link to the member directly though, which would be really good for big structures or vfunc tables (where the per-member kerneldoc tends to be long). Also some minor drive-by polish where it makes sense, I read a lot of docs ... v2: Review from Eric. Cc: Jani Nikula Cc: Chris Wilson Reviewed-by: Eric Engestrom Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20170125062657.19270-4-daniel.vetter@ffwll.ch

drm: RIP mode_config->rotation_property

2016-10-22T08:42:11Z

Now that all drivers have been converted over to the per-plane rotation property, we can just nuke the global rotation property. v2: Rebase due to BIT(),__builtin_ffs() & co. Deal with superfluous code shuffling Signed-off-by: Ville Syrjälä Reviewed-by: Joonas Lahtinen Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1477077768-4274-4-git-send-email-ville.syrjala@linux.intel.com

drm: Add support for optional per-plane rotation property

2016-10-21T16:23:50Z

Not all planes on the system may support the same rotations/reflections, so make it possible to create a separate property for each plane. This way userspace gets told exactly which rotations/reflections are possible for each plane. v2: Add drm_plane_create_rotation_property() helper v3: Drop the BIT(), __builtin_ffs(x) - 1, Moar WARNs for bad parameters Deal with superfluous code shuffling Signed-off-by: Ville Syrjälä Reviewed-by: Chris Wilson (v1) Reviewed-by: Joonas Lahtinen Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1474907460-10717-4-git-send-email-ville.syrjala@linux.intel.com