dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	Tomi Valkeinen <tomi.valkeinen@ti.com>,
	dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/omap: check plane size
Date: Fri, 29 Apr 2016 00:52:30 +0300	[thread overview]
Message-ID: <4143854.kUxbyzqqt6@avalon> (raw)
In-Reply-To: <20160428183018.GI4329@intel.com>

Hi Ville,

On Thursday 28 Apr 2016 21:30:18 Ville Syrjälä wrote:
> On Wed, Apr 27, 2016 at 11:02:17PM +0300, Laurent Pinchart wrote:
> > On Wednesday 27 Apr 2016 20:29:24 Ville Syrjälä wrote:
> >> On Wed, Apr 27, 2016 at 06:30:19PM +0300, Laurent Pinchart wrote:
> >>> On Tuesday 26 Apr 2016 13:16:42 Tomi Valkeinen wrote:
> >>>> At the moment we don't check the plane input/output sizes, which can
> >>>> lead to DSS HW errors when invalid values are given from the
> >>>> userspace.
> >>>> 
> >>>> Add a check so that the sizes are > 0.
> >>>> 
> >>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> >>> 
> >>> I don't think it makes sense to have an empty source or destination
> >>> rectangle for any driver, not just omapdrm. Shouldn't this check be
> >>> added to drm_atomic_plane_check() instead ?
> >> 
> >> It's perfectly legal. Just means you're supposed to turn the plane off.
> > 
> > Where is that documented ?
> 
> Do we have uapi docs?

My point, really :-)

> > I thought turning the plane off was done by setting
> > the framebuffer to NULL (in which case the src and crtc coordinates must
> > of course be ignored) ?
> 
> That's another way. However setting the fb to 0 is a bit different, as
> then you're not holding a ref on the fb (nor does it get pinned etc.).
> So eg. if you want to make sure that you really can pin the fb, but
> want to have the plane disabled for a bit, you could just the clear out
> the coordinates.
> 
> Also from an implementation POV it's no different than the plane just
> getting clipped away entirely, so supporting this way of disabling a
> plane has no extra cost really.

This really needs to be captured in a uapi documentation, this is the first 
time I hear about that feature, and I'm pretty sure I'm not the only one. We 
can't expect drivers to implement a consistent behaviour if the expected 
behaviour isn't documented.

> >>>> ---
> >>>> 
> >>>>  drivers/gpu/drm/omapdrm/omap_plane.c | 6 ++++++
> >>>>  1 file changed, 6 insertions(+)
> >>>> 
> >>>> diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c
> >>>> b/drivers/gpu/drm/omapdrm/omap_plane.c index
> >>>> 93ee538a99f5..fa9e5086eb65
> >>>>> 100644
> >>>> --- a/drivers/gpu/drm/omapdrm/omap_plane.c
> >>>> +++ b/drivers/gpu/drm/omapdrm/omap_plane.c
> >>>> @@ -168,6 +168,12 @@ static int omap_plane_atomic_check(struct
> >>>> drm_plane
> >>> *plane, if (IS_ERR(crtc_state))
> >>>> 
> >>>>  		return PTR_ERR(crtc_state);
> >>>> 
> >>>> +	if (state->src_w == 0 || state->src_h == 0)
> >>>> +		return -EINVAL;
> >>>> +
> >>>> +	if (state->crtc_w == 0 || state->crtc_h == 0)
> >>>> +		return -EINVAL;
> >>>> +
> >>>> 
> >>>>  	if (state->crtc_x < 0 || state->crtc_y < 0)
> >>>>  	
> >>>>  		return -EINVAL;

-- 
Regards,

Laurent Pinchart

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

  reply	other threads:[~2016-04-28 21:52 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-26 10:16 [PATCH] drm/omap: check plane size Tomi Valkeinen
2016-04-27 15:30 ` Laurent Pinchart
2016-04-27 17:29   ` Ville Syrjälä
2016-04-27 20:02     ` Laurent Pinchart
2016-04-28 18:30       ` Ville Syrjälä
2016-04-28 21:52         ` Laurent Pinchart [this message]
2016-04-29  7:03           ` 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=4143854.kUxbyzqqt6@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=tomi.valkeinen@ti.com \
    --cc=ville.syrjala@linux.intel.com \
    /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