All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Thomas Zimmermann <tzimmermann@suse.de>
Cc: David Airlie <airlied@linux.ie>,
	jfalempe@redhat.com, javierm@redhat.com,
	dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/atomic-helper: Don't allocated plane state in CRTC check
Date: Fri, 30 Sep 2022 12:12:09 +0300	[thread overview]
Message-ID: <Yzay6XYpfuZrknUZ@intel.com> (raw)
In-Reply-To: <7e01f298-152c-d2b3-057c-b788c6f577b8@suse.de>

On Fri, Sep 30, 2022 at 11:01:52AM +0200, Thomas Zimmermann wrote:
> Hi,
> 
> thanks for reviewing.
> 
> Am 29.09.22 um 21:03 schrieb Ville Syrjälä:
> > On Thu, Sep 29, 2022 at 04:07:14PM +0200, Thomas Zimmermann wrote:
> >> In drm_atomic_helper_check_crtc_state(), do not add a new plane state
> >> to the global state if it does not exist already. Adding a new plane
> >> state will results in overhead for the plane during the atomic-commit
> >> step.
> >>
> >> For the test in drm_atomic_helper_check_crtc_state() to succeed, it is
> >> important that the CRTC has an enabled primary plane after the commit.
> >> This can be a newly enabled plane or an already enabled plane. So if a
> >> plane is not part of the commit, use the plane's existing state. The new
> >> helper drm_atomic_get_next_plane_state() returns the correct instance.
> >>
> >> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> >> Fixes: d6b9af1097fe ("drm/atomic-helper: Add helper drm_atomic_helper_check_crtc_state()")
> >> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> >> Cc: Jocelyn Falempe <jfalempe@redhat.com>
> >> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> >> Cc: Maxime Ripard <mripard@kernel.org>
> >> Cc: David Airlie <airlied@linux.ie>
> >> Cc: Daniel Vetter <daniel@ffwll.ch>
> >> Cc: dri-devel@lists.freedesktop.org
> >> ---
> >>   drivers/gpu/drm/drm_atomic_helper.c |  4 +---
> >>   include/drm/drm_atomic.h            | 20 ++++++++++++++++++++
> >>   2 files changed, 21 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> >> index 98cc3137c062..463d4f3fa443 100644
> >> --- a/drivers/gpu/drm/drm_atomic_helper.c
> >> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> >> @@ -960,9 +960,7 @@ int drm_atomic_helper_check_crtc_state(struct drm_crtc_state *crtc_state,
> >>   
> >>   			if (plane->type != DRM_PLANE_TYPE_PRIMARY)
> >>   				continue;
> >> -			plane_state = drm_atomic_get_plane_state(state, plane);
> >> -			if (IS_ERR(plane_state))
> >> -				return PTR_ERR(plane_state);
> >> +			plane_state = drm_atomic_get_next_plane_state(state, plane);
> >>   			if (plane_state->fb && plane_state->crtc) {
> > 
> > Hmm. Why this is even looking at these. If the plane is in the crtc's
> > plane_mask then surely plane_state->crtc must already point to this
> > crtc? And I don't think ->fb and ->crtc are allowed to disagree, so
> > if one is set then surely the other one must be as well or we'd
> > return an error at some point somewhere?
> 
> Yeah, the crtc test is done for keeping consistency. Other places also 
> sometimes validate that these fields don't disagree. I'll remove the 
> crtc test in the next version. The fb test is the important one.

What I'm asking how can you have crtc!=NULL && fb==NULL at all here?
Some other plane state check function (can't remember which one
specifically) should have rejected that. So either you're checking
for impossible things, or there is a bug somewhere else. 

So to me it looks like it should be enough to just check the plane_mask
and not even bother looking at the plane state at all.


> 
> > 
> >>   				has_primary_plane = true;
> >>   				break;
> >> diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
> >> index 10b1990bc1f6..4006f2d459e3 100644
> >> --- a/include/drm/drm_atomic.h
> >> +++ b/include/drm/drm_atomic.h
> >> @@ -623,6 +623,26 @@ drm_atomic_get_new_plane_state(struct drm_atomic_state *state,
> >>   	return state->planes[drm_plane_index(plane)].new_state;
> >>   }
> >>   
> >> +/**
> >> + * drm_atomic_get_next_plane_state - get plane state after atomic commit
> >> + * @state: global atomic state object
> >> + * @plane: plane to grab
> >> + *
> >> + * This function returns the plane state that the given plane will have
> >> + * after the atomic commit. This will be the new plane state if the plane
> >> + * is part of the global atomic state, or the current state otherwise.
> >> + */
> >> +static inline struct drm_plane_state *
> >> +drm_atomic_get_next_plane_state(struct drm_atomic_state *state,
> >> +				struct drm_plane *plane)
> >> +{
> >> +	struct drm_plane_state *plane_state = drm_atomic_get_new_plane_state(state, plane);
> >> +
> >> +	if (plane_state)
> >> +		return plane_state;
> >> +	return plane->state;
> > 
> > You're not holding the appropriate lock so that does not look safe. Even
> > if you know somewhere, somehow this sort of thing to be safe I don't
> > think it's a good idea to promote this with any kind of official
> > function because someone will shoot themselves in the foot with it.
> 
> OK. It'll be inlined with locking added.
> 
> Best regards
> Thomas
> 
> > 
> >> +}
> >> +
> >>   /**
> >>    * drm_atomic_get_existing_connector_state - get connector state, if it exists
> >>    * @state: global atomic state object
> >> -- 
> >> 2.37.3
> > 
> 
> -- 
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Ivo Totev




-- 
Ville Syrjälä
Intel

  reply	other threads:[~2022-09-30  9:12 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-29 14:07 [PATCH] drm/atomic-helper: Don't allocated plane state in CRTC check Thomas Zimmermann
2022-09-29 19:03 ` Ville Syrjälä
2022-09-30  9:01   ` Thomas Zimmermann
2022-09-30  9:12     ` Ville Syrjälä [this message]
2022-09-30 10:26       ` Ville Syrjälä
2022-09-30 10:36         ` Thomas Zimmermann
2022-09-30 10:41           ` Ville Syrjälä
2022-09-30 10:27       ` Thomas Zimmermann

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=Yzay6XYpfuZrknUZ@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=airlied@linux.ie \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=javierm@redhat.com \
    --cc=jfalempe@redhat.com \
    --cc=tzimmermann@suse.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.