From: Damien Lespiau <damien.lespiau@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
"Siluvery, Arun" <arun.siluvery@linux.intel.com>,
Daniel Vetter <daniel@ffwll.ch>,
intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] igt/gem_workarounds: igt to test workaround registers
Date: Thu, 28 Aug 2014 07:13:12 +0100 [thread overview]
Message-ID: <20140828061312.GA5495@strange.ger.corp.intel.com> (raw)
In-Reply-To: <20140828055537.GA28027@nuc-i3427.alporthouse.com>
On Thu, Aug 28, 2014 at 06:55:37AM +0100, Chris Wilson wrote:
> On Wed, Aug 27, 2014 at 11:30:35PM +0100, Damien Lespiau wrote:
> > On Wed, Aug 27, 2014 at 06:52:57PM +0100, Chris Wilson wrote:
> > > > Just to clarify, he was not ok because the list we maintain in the
> > > > test can get out of sync with the workarounds we apply in the driver
> > > > which can be avoided if it is generated by the kernel itself.
> > >
> > > Test driven development would suggest that the test itself maintains its
> > > list. Something I heard Daniel say himself before ;-)
> > >
> > > > It may be ok to maintain the list in the test in this case
> > > > considering the list is fairly small but it is not my call.
> > >
> > > The best thing about independent testing is that it is independent...
> >
> > Well also depends on what you're testing I suppose. It's hard enough to
> > have a complete list of W/As, so two of them is bound to end up in
> > tears. If we are testing that the list of W/As the kernel knows about is
> > indeed applied correctly at init/reset/suspend resume, that's already a
> > good step.
> >
> > Also, that second list in i-g-t is not going to be implemented in
> > complete independence from the kernel tree, it's likely to be the same
> > person doing both sides, ending up copy/pasting a file anyway, no value
> > in doing that. The two lists argument works well if 2 different
> > engineers/teams implement the 2 sides, effective cross-checking the list
> > of W/As as a result, but we don't quite have the people to do that.
>
> The point of the independent test is more that you can ask people to run
> and see if it reports strange things on unknown kernels that might
> explain bugs. There has to be an external list anyway just so that you
> can check off the appropriate w/a.
>
> Putting that second list in the kernel just leads to bugs in the kernel
> as aptly demonstrated by the patch and doesn't lead to those warm fuzzy
> feelings.
Ah, fair, for those points it'd be ok to just isolate the W/As in a
file, decide that the master copy is in the kernel and sync it from the
kernel to i-g-t when it changes. Not the full "independent" testing I
was thinking about with separate people writing code and validation.
--
Damien
next prev parent reply other threads:[~2014-08-28 6:13 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-26 13:50 [PATCH] igt/gem_workarounds: igt to test workaround registers Arun Siluvery
2014-08-27 15:50 ` Daniel Vetter
2014-08-27 15:59 ` Chris Wilson
2014-08-27 16:17 ` Siluvery, Arun
2014-08-27 16:23 ` Chris Wilson
2014-08-27 17:02 ` Siluvery, Arun
2014-08-27 17:52 ` Chris Wilson
2014-08-27 22:30 ` Damien Lespiau
2014-08-28 5:55 ` Chris Wilson
2014-08-28 6:13 ` Damien Lespiau [this message]
2014-08-30 15:22 ` Damien Lespiau
2014-08-30 15:25 ` Damien Lespiau
-- strict thread matches above, loose matches on Subject: below --
2014-08-22 19:42 Arun Siluvery
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=20140828061312.GA5495@strange.ger.corp.intel.com \
--to=damien.lespiau@intel.com \
--cc=arun.siluvery@linux.intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=daniel@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
/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.