From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>,
Krzysztof Kozlowski <k.kozlowski@samsung.com>,
linux-samsung-soc@vger.kernel.org,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
Seung-Woo Kim <sw0312.kim@samsung.com>,
dri-devel@lists.freedesktop.org,
Andrzej Hajda <a.hajda@samsung.com>,
Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
Subject: Re: [PATCH v3 2/7] drm/exynos: make zpos property configurable
Date: Wed, 16 Dec 2015 15:48:18 +0200 [thread overview]
Message-ID: <20151216134818.GB4437@intel.com> (raw)
In-Reply-To: <20151216132836.GM30437@phenom.ffwll.local>
On Wed, Dec 16, 2015 at 02:28:36PM +0100, Daniel Vetter wrote:
> On Wed, Dec 16, 2015 at 01:21:43PM +0100, Marek Szyprowski wrote:
> > This patch adds all infrastructure to make zpos plane property
> > configurable from userspace.
> >
> > Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>
> Imo zpos should be a generic atomic property with well-defined semantics
> shared across drivers. So
> - storead (in decoded form) in drm_plane_state
> - common functions to register/attach zpos prop to a plane, with
> full-blown kerneldoc explaining how it should work
> - generic kms igt to validate that interface
>
> One of the big things that always comes up when we talk about zpos is how
> equal zpos should be handled, and how exactly they should be sorted. I
> think for that we should have a drm function which computes a normalized
> zpos. Or the core check code should reject such nonsense.
Yeah I think just having some core check reject the operation if two
planes end up with the same zpos. And zpos should probably just be
in the [0-number_of_planes_on_the_crtc_currently] range? Or maybe
[0-max_number_of_planes_possible_on_the_crtc], or just
[0-total_max_number_of_planes] ? One of the latter two might be sensible
because you could then enable/disable some planes on the crtc without
necessarily touching the zpos for the other planes.
Another complication is how you think about color keying. Eg. if you use
dst keying between the primary plane and some other plane, then it may
make sense to think of the primary being above the other plane and the
colorkey just punches a hole into the primary. But if the planes
otherwise are always ordered with the primary at the botton, then I'm
not sure if exposing zpos and requiring it to be reconfigured for
colorkeying to work would just make things more confusing. But this
decisions might also depend on what happens to pixels on the other plane
that fall outside of the primary plane (assuming the primary can be
non-fullscreen). I don't remember off the top of my head how this works
on Intel hw. The other option I suppose is to define color keying as
just being slightly magic that it can effectively reorder the planes
even though zpos says something else. Not quite sure which is best.
Dst color keying is rather confusing in any case since it may work
only between certain planes (and exactly which planes may depend which
planes are active on the same crtc).
> -Daniel
>
> > ---
> > drivers/gpu/drm/exynos/exynos_drm_drv.h | 4 ++-
> > drivers/gpu/drm/exynos/exynos_drm_plane.c | 51 ++++++++++++++++++++++++++++---
> > 2 files changed, 49 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> > index 588b6763f9c7..f0827dbebb7d 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> > @@ -64,6 +64,7 @@ struct exynos_drm_plane_state {
> > struct exynos_drm_rect src;
> > unsigned int h_ratio;
> > unsigned int v_ratio;
> > + unsigned int zpos;
> > };
> >
> > static inline struct exynos_drm_plane_state *
> > @@ -91,11 +92,12 @@ struct exynos_drm_plane {
> >
> > #define EXYNOS_DRM_PLANE_CAP_DOUBLE (1 << 0)
> > #define EXYNOS_DRM_PLANE_CAP_SCALE (1 << 1)
> > +#define EXYNOS_DRM_PLANE_CAP_ZPOS (1 << 2)
> >
> > /*
> > * Exynos DRM plane configuration structure.
> > *
> > - * @zpos: z-position of the plane.
> > + * @zpos: initial z-position of the plane.
> > * @type: type of the plane (primary, cursor or overlay).
> > * @pixel_formats: supported pixel formats.
> > * @num_pixel_formats: number of elements in 'pixel_formats'.
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c b/drivers/gpu/drm/exynos/exynos_drm_plane.c
> > index fd6cb4cee01a..a2bdab836b50 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
> > @@ -124,6 +124,7 @@ static void exynos_plane_mode_set(struct exynos_drm_plane_state *exynos_state)
> >
> > static void exynos_drm_plane_reset(struct drm_plane *plane)
> > {
> > + struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
> > struct exynos_drm_plane_state *exynos_state;
> >
> > if (plane->state) {
> > @@ -136,6 +137,7 @@ static void exynos_drm_plane_reset(struct drm_plane *plane)
> >
> > exynos_state = kzalloc(sizeof(*exynos_state), GFP_KERNEL);
> > if (exynos_state) {
> > + exynos_state->zpos = exynos_plane->config->zpos;
> > plane->state = &exynos_state->base;
> > plane->state->plane = plane;
> > }
> > @@ -153,6 +155,7 @@ exynos_drm_plane_duplicate_state(struct drm_plane *plane)
> > return NULL;
> >
> > __drm_atomic_helper_plane_duplicate_state(plane, ©->base);
> > + copy->zpos = exynos_state->zpos;
> > return ©->base;
> > }
> >
> > @@ -165,13 +168,53 @@ static void exynos_drm_plane_destroy_state(struct drm_plane *plane,
> > kfree(old_exynos_state);
> > }
> >
> > +static int exynos_drm_plane_atomic_set_property(struct drm_plane *plane,
> > + struct drm_plane_state *state,
> > + struct drm_property *property,
> > + uint64_t val)
> > +{
> > + struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
> > + struct exynos_drm_plane_state *exynos_state =
> > + to_exynos_plane_state(state);
> > + struct exynos_drm_private *dev_priv = plane->dev->dev_private;
> > + const struct exynos_drm_plane_config *config = exynos_plane->config;
> > +
> > + if (property == dev_priv->plane_zpos_property &&
> > + (config->capabilities & EXYNOS_DRM_PLANE_CAP_ZPOS))
> > + exynos_state->zpos = val;
> > + else
> > + return -EINVAL;
> > +
> > + return 0;
> > +}
> > +
> > +static int exynos_drm_plane_atomic_get_property(struct drm_plane *plane,
> > + const struct drm_plane_state *state,
> > + struct drm_property *property,
> > + uint64_t *val)
> > +{
> > + const struct exynos_drm_plane_state *exynos_state =
> > + container_of(state, const struct exynos_drm_plane_state, base);
> > + struct exynos_drm_private *dev_priv = plane->dev->dev_private;
> > +
> > + if (property == dev_priv->plane_zpos_property)
> > + *val = exynos_state->zpos;
> > + else
> > + return -EINVAL;
> > +
> > + return 0;
> > +}
> > +
> > static struct drm_plane_funcs exynos_plane_funcs = {
> > .update_plane = drm_atomic_helper_update_plane,
> > .disable_plane = drm_atomic_helper_disable_plane,
> > .destroy = drm_plane_cleanup,
> > + .set_property = drm_atomic_helper_plane_set_property,
> > .reset = exynos_drm_plane_reset,
> > .atomic_duplicate_state = exynos_drm_plane_duplicate_state,
> > .atomic_destroy_state = exynos_drm_plane_destroy_state,
> > + .atomic_set_property = exynos_drm_plane_atomic_set_property,
> > + .atomic_get_property = exynos_drm_plane_atomic_get_property,
> > };
> >
> > static int
> > @@ -267,8 +310,8 @@ static void exynos_plane_attach_zpos_property(struct drm_plane *plane,
> >
> > prop = dev_priv->plane_zpos_property;
> > if (!prop) {
> > - prop = drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE,
> > - "zpos", 0, MAX_PLANE - 1);
> > + prop = drm_property_create_range(dev, 0, "zpos",
> > + 0, MAX_PLANE - 1);
> > if (!prop)
> > return;
> >
> > @@ -302,9 +345,7 @@ int exynos_plane_init(struct drm_device *dev,
> > exynos_plane->index = index;
> > exynos_plane->config = config;
> >
> > - if (config->type == DRM_PLANE_TYPE_OVERLAY)
> > - exynos_plane_attach_zpos_property(&exynos_plane->base,
> > - config->zpos);
> > + exynos_plane_attach_zpos_property(&exynos_plane->base, config->zpos);
> >
> > return 0;
> > }
> > --
> > 1.9.2
> >
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel OTC
next prev parent reply other threads:[~2015-12-16 13:48 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-16 12:21 [PATCH v3 0/7] drm/exynos: rework layer blending Marek Szyprowski
2015-12-16 12:21 ` [PATCH v3 1/7] drm/exynos: rename zpos to index Marek Szyprowski
2015-12-24 8:15 ` Inki Dae
2015-12-28 12:34 ` Marek Szyprowski
2016-01-04 12:42 ` Inki Dae
2015-12-24 8:21 ` Inki Dae
2015-12-16 12:21 ` [PATCH v3 2/7] drm/exynos: make zpos property configurable Marek Szyprowski
2015-12-16 13:28 ` Daniel Vetter
2015-12-16 13:48 ` Ville Syrjälä [this message]
2015-12-16 13:54 ` Marek Szyprowski
2015-12-16 14:21 ` Daniel Vetter
2015-12-16 14:28 ` Marek Szyprowski
2015-12-17 2:55 ` Joonyoung Shim
2015-12-17 13:05 ` Marek Szyprowski
2015-12-18 0:22 ` Joonyoung Shim
2015-12-16 12:21 ` [PATCH v3 3/7] drm/exynos: mixer: set window priority based on zpos Marek Szyprowski
2015-12-16 12:21 ` [PATCH v3 4/7] drm/exynos: mixer: remove all static blending setup Marek Szyprowski
2015-12-16 12:21 ` [PATCH v3 5/7] drm/exynos: mixer: refactor layer setup Marek Szyprowski
2015-12-17 4:19 ` Joonyoung Shim
2015-12-17 15:54 ` Marek Szyprowski
2015-12-18 0:30 ` Joonyoung Shim
2015-12-16 12:21 ` [PATCH v3 6/7] drm/exynos: mixer: also allow ARGB1555 and ARGB4444 Marek Szyprowski
2015-12-16 12:21 ` [PATCH v3 7/7] drm/exynos: mixer: unify a check for video-processor window Marek Szyprowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151216134818.GB4437@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=a.hajda@samsung.com \
--cc=b.zolnierkie@samsung.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=k.kozlowski@samsung.com \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=sw0312.kim@samsung.com \
--cc=tjakobi@math.uni-bielefeld.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.