public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Anholt <eric@anholt.net>
To: Paul Kocialkowski <paul.kocialkowski@bootlin.com>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Cc: David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
	Maxime Ripard <maxime.ripard@bootlin.com>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	Eben Upton <eben@raspberrypi.org>,
	Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Subject: Re: [PATCH v4 3/4] drm/vc4: Detect and ignore underruns caused by out-of-sync dlists
Date: Wed, 06 Feb 2019 15:51:26 -0800	[thread overview]
Message-ID: <875ztwlblt.fsf@anholt.net> (raw)
In-Reply-To: <20190206144906.24304-4-paul.kocialkowski@bootlin.com>

[-- Attachment #1: Type: text/plain, Size: 1094 bytes --]

Paul Kocialkowski <paul.kocialkowski@bootlin.com> writes:

> When the pipeline is reconfigured with a different mode, changes take
> effect immediately for the CRTC and encoder while the HVS takes some
> time to switch the active display list. This results in a period of
> time where the pipeline is out of sync, that is very likely to cause
> an underrun to be reported. Because the underrun is not related to the
> new configuration, reporting it to userspace is a false positive.

This seems like a serious issue.  How are we enabling a CRTC with the
corresponding HVS still scanning out old contents?  Did we need to wait
for HVS to finish its old frame when we turned off the CRTC, so it's
ready to receive the START when it's been set up with the new dlist and
the CRTC is turned back on?  Or maybe do some sort of reset of that
dlist when a crtc is being enabled?

If we can't sort that out, it feels to me like we should be enabling the
interrupts from the flip_done path (when we know that the HVS is
scanning out the new frame) instead of trying to mitigate enabling them
too early.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

  reply	other threads:[~2019-02-06 23:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-06 14:49 [PATCH v4 0/4] drm/vc4: Add a load tracker Paul Kocialkowski
2019-02-06 14:49 ` [PATCH v4 1/4] drm/vc4: Report HVS underrun errors Paul Kocialkowski
2019-02-06 23:51   ` Eric Anholt
2019-02-06 14:49 ` [PATCH v4 2/4] drm/vc4: Add a load tracker to prevent HVS underflow errors Paul Kocialkowski
2019-02-06 14:49 ` [PATCH v4 3/4] drm/vc4: Detect and ignore underruns caused by out-of-sync dlists Paul Kocialkowski
2019-02-06 23:51   ` Eric Anholt [this message]
2019-02-20 14:30     ` Paul Kocialkowski
2019-02-06 14:49 ` [PATCH v4 4/4] drm/vc4: Add a debugfs entry to disable/enable the load tracker Paul Kocialkowski

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=875ztwlblt.fsf@anholt.net \
    --to=eric@anholt.net \
    --cc=airlied@linux.ie \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=eben@raspberrypi.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maxime.ripard@bootlin.com \
    --cc=paul.kocialkowski@bootlin.com \
    --cc=thomas.petazzoni@bootlin.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