From: "Hogander, Jouni" <jouni.hogander@intel.com>
To: "intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"Coelho, Luciano" <luciano.coelho@intel.com>
Subject: Re: [Intel-gfx] [PATCH v4 1/4] drm/i915/fbc: Clear frontbuffer busy bits on flip
Date: Mon, 4 Sep 2023 08:40:32 +0000 [thread overview]
Message-ID: <2956b2e6ed7434a38b5a86696efd70baee9212a3.camel@intel.com> (raw)
In-Reply-To: <6d30b3c51b7552035ab772930bb8d3363d2500fa.camel@intel.com>
On Mon, 2023-09-04 at 07:25 +0000, Coelho, Luciano wrote:
> Hi Jouni,
>
> On Fri, 2023-09-01 at 12:34 +0300, Jouni Högander wrote:
> > We are planning to move flush performed from work queue. This
> > means it is possible to have invalidate -> flip -> flush sequence.
> > Handle this by clearing possible busy bits on flip.
> >
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
> > ---
> > drivers/gpu/drm/i915/display/intel_fbc.c | 6 ++----
> > 1 file changed, 2 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
> > b/drivers/gpu/drm/i915/display/intel_fbc.c
> > index 1c6d467cec26..817e5784660b 100644
> > --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> > @@ -1307,11 +1307,9 @@ static void __intel_fbc_post_update(struct
> > intel_fbc *fbc)
> > lockdep_assert_held(&fbc->lock);
> >
> > fbc->flip_pending = false;
> > + fbc->busy_bits = 0;
> >
> > - if (!fbc->busy_bits)
> > - intel_fbc_activate(fbc);
> > - else
> > - intel_fbc_deactivate(fbc, "frontbuffer write");
> > + intel_fbc_activate(fbc);
>
> Can you explain why the call to intel_fbc_deactivate() is not needed
> here anymore? I think it would be a good idea to explain that in the
> commit message. Or, at least, an explanation about it here, so it's
> documented. ;)
We are clearing fbc->busy_bits -> I.e. if(!fbc->busy_bits) is always
taken :
Post plane update is called at the end of the flip. If you consider
case where busy_bits != 0 at this point: it means someone have
initiated frontbuffer write (invalidate) which is not yet completed
(flush from workqueue). That flush pending in workqueue is not valid
anymore as there was a flip and the buffer which was frontbuffer is not
a frontbuffer anymore. Even if the same buffer would be used when doing
a flip the atomic commit would take care of flushing the buffer towards
fbc. Also waiting for dma fences is take caren by the atomic commit
code.
BR,
Jouni Högander
>
> --
> Cheers,
> Luca.
next prev parent reply other threads:[~2023-09-04 8:40 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-01 9:34 [Intel-gfx] [PATCH v4 0/4] Handle dma fences in dirtyfb ioctl Jouni Högander
2023-09-01 9:34 ` [Intel-gfx] [PATCH v4 1/4] drm/i915/fbc: Clear frontbuffer busy bits on flip Jouni Högander
2023-09-04 7:25 ` Coelho, Luciano
2023-09-04 8:40 ` Hogander, Jouni [this message]
2023-09-04 8:52 ` Coelho, Luciano
2023-09-01 9:34 ` [Intel-gfx] [PATCH v4 2/4] drm/i915/psr: " Jouni Högander
2023-09-01 9:34 ` [Intel-gfx] [PATCH v4 3/4] drm/i915: Add new frontbuffer tracking interface to queue flush Jouni Högander
2023-09-01 9:35 ` [Intel-gfx] [PATCH v4 4/4] drm/i915: Handle dma fences in dirtyfb callback Jouni Högander
2023-09-01 11:09 ` [Intel-gfx] [PATCH v4 0/4] Handle dma fences in dirtyfb ioctl Ville Syrjälä
2023-09-04 9:34 ` Hogander, Jouni
2023-09-01 14:47 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for Handle dma fences in dirtyfb ioctl (rev6) Patchwork
2023-09-01 15:04 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-09-02 0:16 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2023-09-04 5:22 ` Hogander, Jouni
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=2956b2e6ed7434a38b5a86696efd70baee9212a3.camel@intel.com \
--to=jouni.hogander@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=luciano.coelho@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.