From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Jyri Sarha <jsarha@ti.com>
Cc: praneeth@ti.com, dri-devel@lists.freedesktop.org,
peter.ujfalusi@ti.com, tomi.valkeinen@ti.com,
laurent.pinchart@ideasonboard.com
Subject: Re: [PATCH v2] drm/tidss: dispc: Rewrite naive plane positioning code
Date: Wed, 12 Feb 2020 16:33:54 +0200 [thread overview]
Message-ID: <20200212143354.GC13686@intel.com> (raw)
In-Reply-To: <397e6686-40de-4205-e958-8592b1c3cc6e@ti.com>
On Wed, Feb 12, 2020 at 04:08:11PM +0200, Jyri Sarha wrote:
> On 12/02/2020 15:59, Jyri Sarha wrote:
> > The old implementation of placing planes on the CRTC while configuring
> > the planes was naive and relied on the order in which the planes were
> > configured, enabled, and disabled. The situation where a plane's zpos
> > was changed on the fly was completely broken. The usual symptoms of
> > this problem was scrambled display and a flood of sync lost errors,
> > when a plane was active in two layers at the same time, or a missing
> > plane, in case when a layer was accidentally disabled.
> >
> > The rewrite takes a more straight forward approach when HW is
> > concerned. The plane positioning registers are in the CRTC (actually
> > OVR) register space and it is more natural to configure them in one go
> > while configuring the CRTC. To do this we need to make sure we have
> > all the planes on updated CRTCs in the new atomic state to be
> > committed. This is done by calling drm_atomic_add_affected_planes() in
> > crtc_atomic_check().
> >
> > Signed-off-by: Jyri Sarha <jsarha@ti.com>
> > ---
> > drivers/gpu/drm/tidss/tidss_crtc.c | 55 ++++++++++++++++++++++++++++-
> > drivers/gpu/drm/tidss/tidss_dispc.c | 55 +++++++++++------------------
> > drivers/gpu/drm/tidss/tidss_dispc.h | 5 +++
> > 3 files changed, 79 insertions(+), 36 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/tidss/tidss_crtc.c b/drivers/gpu/drm/tidss/tidss_crtc.c
> > index 032c31ee2820..f7c5fd1094a8 100644
> > --- a/drivers/gpu/drm/tidss/tidss_crtc.c
> > +++ b/drivers/gpu/drm/tidss/tidss_crtc.c
> ...
> > @@ -108,7 +110,54 @@ static int tidss_crtc_atomic_check(struct drm_crtc *crtc,
> > return -EINVAL;
> > }
> >
> > - return dispc_vp_bus_check(dispc, hw_videoport, state);
> > + ret = dispc_vp_bus_check(dispc, hw_videoport, state);
> > + if (ret)
> > + return ret;
> > +
> > + /* Add unchanged planes on this crtc to state for zpos update. */
> > + return drm_atomic_add_affected_planes(state->state, crtc);
>
> Is this a correct way to use drm_atomic_add_affected_planes()?
>
> I saw that some other drivers implement their own mode_config
> atomic_check() and have this call there in
> for_each_new_crtc_in_state()-loop, but I thought it should be fine to
> call it in crtc_atomic_check().
You seem to be using drm_atomic_helper_check_planes(), which means
crtc.atomic_check() gets called after plane.atomic_check(). So this
might be good or bad depending on whether you'd like the planes you
add here to go through their .atomic_check() or not.
--
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-02-12 14:34 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-12 13:59 [PATCH v2] drm/tidss: dispc: Rewrite naive plane positioning code Jyri Sarha
2020-02-12 14:08 ` Jyri Sarha
2020-02-12 14:33 ` Ville Syrjälä [this message]
2020-02-12 18:01 ` Jyri Sarha
2020-02-12 20:28 ` Daniel Vetter
2020-02-13 9:03 ` Jyri Sarha
2020-02-13 9:19 ` Daniel Vetter
2020-02-13 10:03 ` Jyri Sarha
2020-02-13 10:25 ` Daniel Vetter
2020-02-13 10:59 ` Laurent Pinchart
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=20200212143354.GC13686@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=jsarha@ti.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=peter.ujfalusi@ti.com \
--cc=praneeth@ti.com \
--cc=tomi.valkeinen@ti.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.