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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox