mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
To: Eric Anholt <eric@anholt.net>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Cc: David Airlie <airlied@linux.ie>,
	Maxime Ripard <maxime.ripard@bootlin.com>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	Boris Brezillon <boris.brezillon@bootlin.com>
Subject: Re: [PATCH v2] drm/vc4: Add a debugfs entry to disable/enable the load tracker
Date: Sat, 01 Dec 2018 10:58:57 +0100	[thread overview]
Message-ID: <fb5e3339e23d0191a67d161958b83b3da99b3b30.camel@bootlin.com> (raw)
In-Reply-To: <87r2f2patf.fsf@anholt.net>

Hi Eric,

Le vendredi 30 novembre 2018 à 12:30 -0800, Eric Anholt a écrit :
> Paul Kocialkowski <paul.kocialkowski@bootlin.com> writes:
> 
> > In order to test whether the load tracker is working as expected, we
> > need the ability to compare the commit result with the underrun
> > indication. With the load tracker always enabled, commits that are
> > expected to trigger an underrun are always rejected, so userspace
> > cannot get the actual underrun indication from the hardware.
> > 
> > Add a debugfs entry to disable/enable the load tracker, so that a DRM
> > commit expected to trigger an underrun can go through with the load
> > tracker disabled. The underrun indication is then available to
> > userspace and can be checked against the commit result with the load
> > tracker enabled.
> > 
> > Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> 
> Given that the load tracker is going to be conservative and say things
> will underrun even when they might not in practice, will this actually
> be useful for automated testing?  Or is the intent to make it easier to
> tune the load tracker by disabling it so that you can experiment freely?

The intent here is to be able to compare the load tracker's result with
the underrun indication from the HVS.

The idea is to have the following testing scheme:
1. enable the load tracker
2. try a commit and get the errno if it fails
3. disable the load tracker
4. do the commit
5. wait for vblank and get the underrun indication
6. check that the underrun occurs when errno == -ENOSPC

This way, we can find out when the load tracker gave us a false
positive and refine the load calculation.

Cheers,

Paul


  reply	other threads:[~2018-12-01  9:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-30 16:11 Paul Kocialkowski
2018-11-30 18:57 ` Boris Brezillon
2018-12-01  9:59   ` Paul Kocialkowski
2018-11-30 20:30 ` Eric Anholt
2018-12-01  9:58   ` Paul Kocialkowski [this message]
2018-12-02  7:14   ` Boris Brezillon
2018-12-03 15:54     ` Eric Anholt

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=fb5e3339e23d0191a67d161958b83b3da99b3b30.camel@bootlin.com \
    --to=paul.kocialkowski@bootlin.com \
    --cc=airlied@linux.ie \
    --cc=boris.brezillon@bootlin.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=eric@anholt.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maxime.ripard@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

all inboxes | Powered by JetHome®