summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/drm_blend.c
AgeCommit message (Collapse)Author
2020-05-14drm: plane: Verify that no or all planes have a zpos propertyLaurent Pinchart
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 <laurent.pinchart+renesas@ideasonboard.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2020-03-31drm: add docs about the IN_FORMATS plane propertySimon Ser
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 <contact@emersion.fr> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Daniel Stone <daniel@fooishbar.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/mHOtz80Wa-x3A5Lz5ETTM65VUMfW1j6b-iCuvIy1RzOM1EloHPqAb2MnbU8ygZi0ABaLrxuN6pzu0v3QRn83125C0bXuHoo-DQWWEd80fdw=@emersion.fr
2019-10-09drm: two planes with the same zpos have undefined orderingSimon Ser
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 <contact@emersion.fr> Reviewed-by: Pekka Paalanen <ppaalanen@gmail.com> Cc: Marius Vlad <marius.vlad@collabora.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: James Qian Wang <james.qian.wang@arm.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/T5nHrvXH0GKOp6ONaFHk-j2cwEb4_4C_sBz9rNw8mmPACuut-DQqC74HMAFKZH3_Q15E8a3YnmKCxap-djKA71VVZv_T-tFxaB0he13O7yA=@emersion.fr
2019-09-06drm/blend: Define the direction of Z position valuesDaniel Vetter
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 <pekka.paalanen@collabora.com> Cc: Pekka Paalanen <pekka.paalanen@collabora.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Acked-by: Ilia Mirkin <imirkin@alum.mit.edu> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190906144459.16025-1-daniel.vetter@ffwll.ch
2019-05-27drm: drop use of drmP.h in drm/*Sam Ravnborg
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
2018-09-11drm: Clarify DRM_MODE_REFLECT_X/Y documentationAlexandru Gheorghe
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 <alexandru-cosmin.gheorghe@arm.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20180910172946.18539-1-alexandru-cosmin.gheorghe@arm.com
2018-08-24drm: Add per-plane pixel blend mode propertyLowry Li
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 <liviu.dudau@arm.com> Signed-off-by: Lowry Li <lowry.li@arm.com> Signed-off-by: Ayan Kumar Halder <ayan.halder@arm.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/245734/
2018-04-16drm/blend: Add a generic alpha propertyMaxime Ripard
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 <maarten.lankhorst@linux.intel.com> Acked-by: Sean Paul <seanpaul@chromium.org> Reviewed-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.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/6e1ce0db78fcfc407e94913c64819e65109d034d.1523432341.git-series.maxime.ripard@bootlin.com
2018-02-20drm/docs: Align layout of optional plane blending propertiesDaniel Vetter
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 <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20180219225356.24996-2-daniel.vetter@ffwll.ch
2017-12-14drm/atomic-helper: Make zpos property kerneldoc less misleadingThierry Reding
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 <daniel.vetter@ffwll.ch> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171120150959.26913-1-thierry.reding@gmail.com
2017-09-13mm: treewide: remove GFP_TEMPORARY allocation flagMichal Hocko
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 <mhocko@suse.com> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Acked-by: Mel Gorman <mgorman@suse.de> Acked-by: Vlastimil Babka <vbabka@suse.cz> Cc: Matthew Wilcox <willy@infradead.org> Cc: Neil Brown <neilb@suse.de> Cc: "Theodore Ts'o" <tytso@mit.edu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-05-22drm: Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ to UAPIRobert Foss
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_<axis> 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 <robert.foss@collabora.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com> Acked-by: Liviu Dudau <Liviu.Dudau@arm.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170519205017.23307-2-robert.foss@collabora.com
2017-05-22drm/blend: Fix comment typ-oRobert Foss
Fix DRM_REFELCT_Y -> DRM_REFLECT_Y. Signed-off-by: Robert Foss <robert.foss@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170519205017.23307-1-robert.foss@collabora.com
2017-03-06drm/blend: Use new atomic iterator macros.Maarten Lankhorst
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 <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1487256430-7625-6-git-send-email-maarten.lankhorst@linux.intel.com Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2017-03-06drm/atomic: Convert get_existing_state callers to get_old/new_state, v4.Maarten Lankhorst
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 <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/df91a9f9-005e-bcbd-1f74-03c38e1e21dd@linux.intel.com Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2017-01-25drm/kms-core: Use recommened kerneldoc for struct member refsDaniel Vetter
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 <jani.nikula@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170125062657.19270-4-daniel.vetter@ffwll.ch
2016-10-22drm: RIP mode_config->rotation_propertyVille Syrjälä
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ä <ville.syrjala@linux.intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1477077768-4274-4-git-send-email-ville.syrjala@linux.intel.com
2016-10-21drm: Add support for optional per-plane rotation propertyVille Syrjälä
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ä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v1) Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1474907460-10717-4-git-send-email-ville.syrjala@linux.intel.com
2016-09-22drm/doc: Polish plane composition property docsDaniel Vetter
Try to spec a bit more precisely how they all fit together, now that at least the code is for all the additional properties is in one place. Also remove the entries for the standardized properties from the table, because that thing is supremely unmaintaineable. v2: Fix typos Sean spotted. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/1474448370-32227-4-git-send-email-daniel.vetter@ffwll.ch
2016-09-22drm: Conslidate blending properties in drm_blend.[hc]Daniel Vetter
Imo zpos, rotatation, blending eq (once we have it) and all that should be in drm_blend.c, since those are all about how exactly the pixels are rendered onto the CRTC's visible area. Also noticed that one exported function accidentally ended up in drm_crtc_internal.h, move it to the right place too. Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/1474448370-32227-3-git-send-email-daniel.vetter@ffwll.ch
2016-09-19drm/blend: Fix sparse warningsVille Syrjälä
drm/drm_blend.c:207:5: warning: symbol 'drm_atomic_normalize_zpos' was not declared. Should it be static? Cc: Marek Szyprowski <m.szyprowski@samsung.com> Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1474292035-15695-3-git-send-email-ville.syrjala@linux.intel.com
2016-08-16drm/doc: Include new drm_blend.cDaniel Vetter
There's not much point in kerneldoc if it's not included: - It won't show up in the pretty html pages. - The comments itself won't get parsed, which means 0day won't pick up changes, resulting in stale docs fast. Also, uapi really should be core, not helpers, so move drm_blend.c to that. That also means that the zpos normilize function loses it's helper status (and we might as well call it always). For that, EXPORT_SYMBOL. Just spotted while integrating docs and noticing that one was missing. With sphinx there's really no excuse any more to not build the docs and make sure it's all nice! $ make DOCBOOKS="" htmldocs Cc: Marek Szyprowski <m.szyprowski@samsung.com> Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1471034937-651-15-git-send-email-daniel.vetter@ffwll.ch
2016-07-29drm: add generic zpos propertyMarek Szyprowski
version 8: - move drm_blend.o from drm-y to drm_kms_helper-y to avoid EXPORT_SYMBOL(drm_atomic_helper_normalize_zpos) - remove dead function declarations in drm_crtc.h version 7: - remove useless EXPORT_SYMBOL() - better z-order wording in Documentation version 6: - add zpos in gpu documentation file - merge Ville patch about zpos initial value and API improvement. I have split Ville patch between zpos core and drivers version 5: - remove zpos range check and comeback to 0 to N-1 normalization algorithm version 4: - make sure that normalized zpos value is stay in the defined property range and warn user if not This patch adds support for generic plane's zpos property property with well-defined semantics: - added zpos properties to plane and plane state structures - added helpers for normalizing zpos properties of given set of planes - well defined semantics: planes are sorted by zpos values and then plane id value if zpos equals Normalized zpos values are calculated automatically when generic muttable zpos property has been initialized. Drivers can simply use plane_state->normalized_zpos in their atomic_check and/or plane_update callbacks without any additional calls to DRM core. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Compare to Marek's original patch zpos property is now specific to each plane and no more to the core. Normalize function take care of the range of per plane defined range before set normalized_zpos. Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Inki Dae <inki.dae@samsung.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Joonyoung Shim <jy0922.shim@samsung.com> Cc: Seung-Woo Kim <sw0312.kim@samsung.com> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: Tobias Jakobi <tjakobi@math.uni-bielefeld.de> Cc: Gustavo Padovan <gustavo@padovan.org> Cc: vincent.abriou@st.com Cc: fabien.dessenne@st.com Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>