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
next prev parent 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