From mboxrd@z Thu Jan 1 00:00:00 1970 From: Damien Lespiau Subject: Re: [PATCH] igt/gem_workarounds: igt to test workaround registers Date: Thu, 28 Aug 2014 07:13:12 +0100 Message-ID: <20140828061312.GA5495@strange.ger.corp.intel.com> References: <1409061028-5087-1-git-send-email-arun.siluvery@linux.intel.com> <20140827155016.GW15520@phenom.ffwll.local> <20140827155911.GM13629@nuc-i3427.alporthouse.com> <53FE0487.2010607@linux.intel.com> <20140827162325.GO13629@nuc-i3427.alporthouse.com> <53FE0F17.4090401@linux.intel.com> <20140827175257.GP13629@nuc-i3427.alporthouse.com> <20140827223035.GB27540@strange.ger.corp.intel.com> <20140828055537.GA28027@nuc-i3427.alporthouse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by gabe.freedesktop.org (Postfix) with ESMTP id 1A7406E5E1 for ; Wed, 27 Aug 2014 23:13:43 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20140828055537.GA28027@nuc-i3427.alporthouse.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Chris Wilson , "Siluvery, Arun" , Daniel Vetter , intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org 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