dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2 3/6] drm/plane: Add optional ->atomic_disable() callback
Date: Fri, 16 Jan 2015 15:35:10 +0100	[thread overview]
Message-ID: <20150116143508.GA7775@ulmo.nvidia.com> (raw)
In-Reply-To: <20141125122634.GB25711@phenom.ffwll.local>


[-- Attachment #1.1: Type: text/plain, Size: 4310 bytes --]

On Tue, Nov 25, 2014 at 01:26:34PM +0100, Daniel Vetter wrote:
> On Tue, Nov 25, 2014 at 12:57:04PM +0100, Thierry Reding wrote:
> > On Tue, Nov 25, 2014 at 12:45:46PM +0100, Thierry Reding wrote:
> > > On Tue, Nov 25, 2014 at 12:22:34PM +0100, Daniel Vetter wrote:
> > > > On Tue, Nov 25, 2014 at 12:09:46PM +0100, Thierry Reding wrote:
> > [...]
> > > > > +/*
> > > > > + * drm_plane_disabled - check whether a plane is being disabled
> > > > > + * @plane: plane object
> > > > > + * @old_state: previous atomic state
> > > > > + *
> > > > > + * Checks the atomic state of a plane to determine whether it's being disabled
> > > > > + * or not. This also WARNs if it detects an invalid state (both CRTC and FB
> > > > > + * need to either both be NULL or both be non-NULL).
> > > > > + *
> > > > > + * RETURNS:
> > > > > + * True if the plane is being disabled, false otherwise.
> > > > > + */
> > > > > +static inline bool drm_plane_disabled(struct drm_plane *plane,
> > > > > +				      struct drm_plane_state *old_state)
> > > > > +{
> > [...]
> > > > > +	return (!old_state || old_state->crtc) && !plane->state->crtc;
> > > > 
> > > > The !old_state check here confused me a bit, until I've realized that you
> > > > use this for transitional helpers too. What about adding
> > > > 
> > > > 	/* Cope with NULL old_state for transitional helpers. */
> > > > 
> > > > right above?
> > > 
> > > Sounds good.
> > 
> > When I now thought about the reason again it took me a while to
> > reconstruct, so I figured I'd be extra verbose and used this:
> > 
> > 	/*
> > 	 * When using the transitional helpers, old_state may be NULL. If so,
> > 	 * we know nothing about the current state and have to assume that it
> > 	 * might be enabled.
> > 	 */
> > 
> > Does that sound accurate and sufficient to you?
> 
> Hm, thinking about this some more this will result in a slight difference
> in behaviour, at least when drivers just use the helper ->reset functions
> but don't disable everything:
> - With transitional helpers we assume we know nothing and call
>   ->atomic_disable.
> - With atomic old_state->crtc == NULL in the same situation right after
>   boot-up, but we asssume the plane is really off and _dont_ call
>   ->atomic_disable.
> 
> Should we instead check for (old_state && old_state->crtc) and state that
> drivers need to make sure they don't have stuff hanging around?

I don't think we can check for old_state because otherwise this will
always return false, whereas we really want it to force-disable planes
that could be on (lacking any more accurate information). For
transitional helpers anyway.

For the atomic helpers, old_state will never be NULL, but I'd assume
that the driver would reconstruct the current state in ->reset().

> Or maybe just a note that there's a difference in behaviour here?

One other option would be to split this up into two functions:

	- drm_plane_helper_disabling() which is called from
	  drm_plane_helper_commit() and checks for the validity of
	  old_state

	- drm_atomic_plane_disabling() which is called from
	  drm_atomic_helper_commit_planes() and doesn't have to check
	  for the validity of old_state because it's always valid.

On second thought, that doesn't really help because the very first call
would still not know whether old_state->crtc is NULL because it's just
the default or because the plane is really disabled.

So I think the only sane solution to this would be to either have the
drivers reconstruct the correct value for state->crtc in ->reset() or
make sure to comply with the semantics that planes are initially
considered to be disabled.

Maybe complementing the above comment like this would help:

	/*
	 * When using the transitional helpers, old_state may be NULL. If so,
	 * we know nothing about the current state and have to assume that it
	 * might be enabled. This usually happens only on the very first call
	 * of the drm_plane_helper_commit() helper.
	 *
	 * When using the atomic helpers, old_state won't be NULL. Therefore
	 * this check assumes that either the driver will have reconstructed
	 * the current state in ->reset() or that the driver will have taken
	 * measures to disable all planes.
	 */

Thierry

[-- Attachment #1.2: Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2015-01-16 14:35 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-25 11:09 [PATCH v2 1/6] drm/plane: Pass old state to ->atomic_update() Thierry Reding
2014-11-25 11:09 ` [PATCH v2 2/6] drm/plane: Add missing kerneldoc Thierry Reding
2014-11-25 11:09 ` [PATCH v2 3/6] drm/plane: Add optional ->atomic_disable() callback Thierry Reding
2014-11-25 11:22   ` Daniel Vetter
2014-11-25 11:45     ` Thierry Reding
2014-11-25 11:57       ` Thierry Reding
2014-11-25 12:26         ` Daniel Vetter
2015-01-16 14:35           ` Thierry Reding [this message]
2015-01-16 14:53             ` Thierry Reding
2015-01-17  3:48               ` Daniel Vetter
2015-01-17  4:56                 ` Thierry Reding
2014-11-25 12:27       ` Daniel Vetter
2014-11-25 11:09 ` [PATCH v2 4/6] drm: Make drm_atomic_helper.h standalone includible Thierry Reding
2014-11-25 11:09 ` [PATCH v2 5/6] drm: Make drm_atomic.h " Thierry Reding
2014-11-25 11:09 ` [PATCH v2 6/6] drm: Free atomic state during cleanup Thierry Reding

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=20150116143508.GA7775@ulmo.nvidia.com \
    --to=thierry.reding@gmail.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel@ffwll.ch \
    --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;
as well as URLs for NNTP newsgroup(s).