Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Message-ID: <fb5e3339e23d0191a67d161958b83b3da99b3b30.camel@bootlin.com>
Subject: Re: [PATCH v2] drm/vc4: Add a debugfs entry to disable/enable the
 load tracker
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>
Date:   Sat, 01 Dec 2018 10:58:57 +0100
In-Reply-To: <87r2f2patf.fsf@anholt.net>
References: <20181130161104.16352-1-paul.kocialkowski@bootlin.com>
         <87r2f2patf.fsf@anholt.net>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.2 
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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