From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>,
dri-devel@lists.freedesktop.org,
linux-renesas-soc@vger.kernel.org,
Kieran Bingham <kieran.bingham@ideasonboard.com>
Subject: Re: [PATCH v2 2/2] drm: rcar-du: Clip planes to screen boundaries
Date: Sun, 26 Nov 2017 13:18:46 +0200 [thread overview]
Message-ID: <3602648.r47gg9TK3D@avalon> (raw)
In-Reply-To: <20171116170426.GA10981@intel.com>
Hi Ville,
On Thursday, 16 November 2017 19:04:26 EET Ville Syrjälä wrote:
> On Mon, Nov 13, 2017 at 10:47:00AM +0200, Laurent Pinchart wrote:
> > Unlike the KMS API, the hardware doesn't support planes exceeding the
> > screen boundaries or planes being located fully off-screen. We need to
> > clip plane coordinates to support the use case.
> >
> > Fortunately the DRM core offers the drm_plane_helper_check_state()
> > helper that valides the scaling factor and clips the plane coordinates.
> > Use it to implement the plane atomic check and use the clipped source
> > and destination rectangles from the plane state instead of the unclipped
> > source and CRTC coordinates to configure the device.
> >
> > Signed-off-by: Laurent Pinchart
> > <laurent.pinchart+renesas@ideasonboard.com>
> > ---
> >
> > drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 3 ++-
> > drivers/gpu/drm/rcar-du/rcar_du_plane.c | 37 +++++++++++++++++++++-------
> > drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 10 ++++++---
> > 3 files changed, 39 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c index b492063a6e1f..5685d5af6998
> > 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > @@ -319,7 +319,8 @@ static void rcar_du_crtc_update_planes(struct
> > rcar_du_crtc *rcrtc)>
> > struct rcar_du_plane *plane = &rcrtc->group->planes[i];
> > unsigned int j;
> >
> > - if (plane->plane.state->crtc != &rcrtc->crtc)
> > + if (plane->plane.state->crtc != &rcrtc->crtc ||
> > + !plane->plane.state->visible)
> >
> > continue;
> >
> > /* Insert the plane in the sorted planes array. */
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_plane.c index
> > 4f076c364f25..9cf02b44902d 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> > @@ -570,16 +570,39 @@ int __rcar_du_plane_atomic_check(struct drm_plane
> > *plane,
> > const struct rcar_du_format_info **format)
> > {
> > struct drm_device *dev = plane->dev;
> > + struct drm_crtc_state *crtc_state;
> > + struct drm_rect clip;
> > + int ret;
> >
> > - if (!state->fb || !state->crtc) {
> > + if (!state->crtc) {
> > + /*
> > + * The visible field is not reset by the DRM core but only
> > + * updated by drm_plane_helper_check_state(), set it manually.
> > + */
> > + state->visible = false;
> > *format = NULL;
> > return 0;
> > - }
> > + };
>
> spurious ;
Oops, my bad, I'll fix that.
> > - if (state->src_w >> 16 != state->crtc_w ||
> > - state->src_h >> 16 != state->crtc_h) {
> > - dev_dbg(dev->dev, "%s: scaling not supported\n", __func__);
> > - return -EINVAL;
> > + crtc_state = drm_atomic_get_crtc_state(state->state, state->crtc);
> > + if (IS_ERR(crtc_state))
> > + return PTR_ERR(crtc_state);
> > +
> > + clip.x1 = 0;
> > + clip.y1 = 0;
> > + clip.x2 = crtc_state->adjusted_mode.hdisplay;
> > + clip.y2 = crtc_state->adjusted_mode.vdisplay;
>
> crtc_state->mode would be more correct. I messed that up too in my
> recent vmwgfx fix [1]. But this should probably work just as well
> if you don't have a crtc scaler in your pipeline.
Indeed, my CRTC can't scale, so this works, but I'll fix it nonetheless.
> Also you may want to leave the clip empty when !crtc_state->enable.
> That way you'll be guaranteed to get visible==false. The helper is
> currently a bit broken wrt. the crtc->enable vs. crtc_state->enable.
> I've fixed that in [1] as well but those patches haven't been pushed
> yet.
[1] has landed in drm-misc, I'll rebase this series on top of that, and will
send a pull request when drm-misc gets merged in Dave's tree.
> After getting that stuff in, I'm going to attempt moving this
> clipping stuff entirely into the helper to avoid these kinds of
> mistakes in the future.
Good idea, thanks.
> [1] https://patchwork.freedesktop.org/series/33001/
>
> > +
> > + ret = drm_plane_helper_check_state(state, &clip,
> > + DRM_PLANE_HELPER_NO_SCALING,
> > + DRM_PLANE_HELPER_NO_SCALING,
> > + true, true);
> > + if (ret < 0)
> > + return ret;
> > +
> > + if (!state->visible) {
> > + *format = NULL;
> > + return 0;
> > }
> >
> > *format = rcar_du_format_info(state->fb->format->format);
--
Regards,
Laurent Pinchart
prev parent reply other threads:[~2017-11-26 11:18 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-13 8:46 [PATCH v2 0/2] R-Car DU: Clip planes to screen boundaries Laurent Pinchart
2017-11-13 8:46 ` [PATCH v2 1/2] drm: rcar-du: Share plane atomic check code between Gen2 and Gen3 Laurent Pinchart
2017-11-13 8:47 ` [PATCH v2 2/2] drm: rcar-du: Clip planes to screen boundaries Laurent Pinchart
2017-11-13 8:47 ` Laurent Pinchart
2017-11-16 17:04 ` Ville Syrjälä
2017-11-16 17:04 ` Ville Syrjälä
2017-11-26 11:18 ` Laurent Pinchart [this message]
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=3602648.r47gg9TK3D@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=kieran.bingham@ideasonboard.com \
--cc=laurent.pinchart+renesas@ideasonboard.com \
--cc=linux-renesas-soc@vger.kernel.org \
--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 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.