From: Daniel Vetter <daniel@ffwll.ch>
To: Daniel Stone <daniels@collabora.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 11/11] drm: atomic: Add MODE_ID property
Date: Fri, 22 May 2015 16:34:53 +0200 [thread overview]
Message-ID: <20150522143453.GW15256@phenom.ffwll.local> (raw)
In-Reply-To: <1432298094-22239-12-git-send-email-daniels@collabora.com>
On Fri, May 22, 2015 at 01:34:54PM +0100, Daniel Stone wrote:
> Atomic modesetting: now with modesetting support.
>
> Signed-off-by: Daniel Stone <daniels@collabora.com>
> Tested-by: Sean Paul <seanpaul@chromium.org>
> ---
> drivers/gpu/drm/drm_atomic.c | 12 +++++++++++-
> drivers/gpu/drm/drm_crtc.c | 7 +++++++
> include/drm/drm_crtc.h | 1 +
> 3 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 63fc58a..a4ab03a 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -415,10 +415,18 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
> {
> struct drm_device *dev = crtc->dev;
> struct drm_mode_config *config = &dev->mode_config;
> + int ret;
>
> - /* FIXME: Mode prop is missing, which also controls ->enable. */
> if (property == config->prop_active)
> state->active = val;
> + else if (property == config->prop_mode_id) {
> + struct drm_property_blob *mode =
> + drm_property_lookup_blob(dev, val);
> + ret = drm_atomic_set_mode_prop_for_crtc(state, mode);
> + if (mode)
> + drm_property_unreference_blob(mode);
Hm, maybe I need to revisit whether auto-clamping ->active is a good idea.
We need it for legacy helpers, but for atomic userspace this code means
depending upon whether active or mode_id is first in the prop list it will
get clamped or not, which isn't awesome.
Imo that's a good reason to remove the ->active clamping from
set_mode_pop_for_crtc. I guess we can keep it for set_mode_for_crtc since
that's only used internally and in legacy paths. Perhaps with a comment as
to why (and why not in set_mode_prop).
> + return ret;
> + }
> else if (crtc->funcs->atomic_set_property)
> return crtc->funcs->atomic_set_property(crtc, state, property, val);
> else
> @@ -443,6 +451,8 @@ int drm_atomic_crtc_get_property(struct drm_crtc *crtc,
>
> if (property == config->prop_active)
> *val = state->active;
> + else if (property == config->prop_mode_id)
> + *val = (state->mode_blob) ? state->mode_blob->base.id : 0;
> else if (crtc->funcs->atomic_get_property)
> return crtc->funcs->atomic_get_property(crtc, state, property, val);
> else
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index ee87045..8f18412 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -688,6 +688,7 @@ int drm_crtc_init_with_planes(struct drm_device *dev, struct drm_crtc *crtc,
>
> if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
> drm_object_attach_property(&crtc->base, config->prop_active, 0);
> + drm_object_attach_property(&crtc->base, config->prop_mode_id, 0);
> }
>
> return 0;
> @@ -1454,6 +1455,12 @@ static int drm_mode_create_standard_properties(struct drm_device *dev)
> return -ENOMEM;
> dev->mode_config.prop_active = prop;
>
> + prop = drm_property_create_object(dev, DRM_MODE_PROP_ATOMIC,
> + "MODE_ID", DRM_MODE_OBJECT_BLOB);
Ah, here we go. Why not DRM_MODE_PROP_BLOB? Imo confusing to userspace
that some prop blobs are objects and some are old blob props.
-Daniel
> + if (!prop)
> + return -ENOMEM;
> + dev->mode_config.prop_mode_id = prop;
> +
> return 0;
> }
>
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index c54fa4a..3b4d8a4 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -1146,6 +1146,7 @@ struct drm_mode_config {
> struct drm_property *prop_fb_id;
> struct drm_property *prop_crtc_id;
> struct drm_property *prop_active;
> + struct drm_property *prop_mode_id;
>
> /* DVI-I properties */
> struct drm_property *dvi_i_subconnector_property;
> --
> 2.4.1
>
> _______________________________________________
> 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
next prev parent reply other threads:[~2015-05-22 14:32 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-22 12:34 [PATCH 00/11] CRTC state mode property Daniel Stone
2015-05-22 12:34 ` [PATCH 01/11] drm: kerneldoc fixes for blob properties Daniel Stone
2015-05-22 12:34 ` [PATCH 02/11] drm/crtc_helper: Replace open-coded CRTC state helpers Daniel Stone
2015-05-22 12:34 ` [PATCH 03/11] drm: Retain reference to blob properties in lookup Daniel Stone
2015-05-22 14:11 ` Daniel Vetter
2015-05-22 12:34 ` [PATCH 04/11] drm/mode: Validate modes inside drm_crtc_convert_umode Daniel Stone
2015-05-22 12:34 ` [PATCH 05/11] drm/mode: Unstatic kernel-userspace mode conversion Daniel Stone
2015-05-22 12:34 ` [PATCH 06/11] drm: Allow creating blob properties without copy Daniel Stone
2015-05-22 12:34 ` [PATCH 07/11] drm: Return error value from blob creation Daniel Stone
2015-05-22 12:34 ` [PATCH 08/11] drm/mode: Add user blob-creation ioctl Daniel Stone
2015-05-22 12:34 ` [PATCH 09/11] drm: Add drm_atomic_set_mode_for_crtc Daniel Stone
2015-05-22 14:26 ` Daniel Vetter
2015-05-22 12:34 ` [PATCH 10/11] drm/atomic: Add current-mode blob to CRTC state Daniel Stone
2015-05-22 14:30 ` Daniel Vetter
2015-05-22 12:34 ` [PATCH 11/11] drm: atomic: Add MODE_ID property Daniel Stone
2015-05-22 14:34 ` Daniel Vetter [this message]
2015-05-25 13:06 ` Daniel Stone
2015-05-26 6:32 ` Daniel Vetter
2015-05-22 14:35 ` [PATCH 00/11] CRTC state mode property Daniel Vetter
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=20150522143453.GW15256@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=daniels@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox