On Fri, Oct 13, 2017 at 01:32:58PM -0700, Oscar Mateo wrote: > > > On 10/12/2017 05:40 AM, Petri Latvala wrote: > > On Wed, Oct 11, 2017 at 11:15:40AM -0700, Oscar Mateo wrote: > > > Apart from context based workarounds, we can now also test for global > > > MMIO and whitelisting ones. > > > > > > Do take into account that this test does not guarantee that all known > > > WAs for a given platform are applied. It only checks that the WAs the > > > kernel does know about are correctly applied (e.g. they didn't get > > > lost on a GPU reset or a suspend/resume). > > > > > > v2: > > > - Do not wait for the GPU unnecessarily (Chris) > > > - Make a comment that this tests only looks for regressions (Chris) > > > > > > Signed-off-by: Oscar Mateo <oscar.mateo@xxxxxxxxx> > > > Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > > Cc: Mika Kuoppala <mika.kuoppala@xxxxxxxxxxxxxxx> > > > > Subjectprefix didn't contain i-g-t so CI did not pick this up. > > > > Thanks for the heads up, Petri. I forgot to add the label, but it doesn't > matter that much because this patch is going to fail CI until the companion > patches make it to the KMD (is there a BKM to deal with this situation?). That still tests if it builds in the CI environment, whether it affects other tests, and shows how the failure behaves. How is the test supposed to behave on older kernels, like stable releases (4.4.x, 4.12.x, etc)? Is "fail" proper for kernels without the KMD changes required, instead of producing a skip? If that is the case, the best story is to keep sending the patch towards CI, collect reviews, possibly resend for one more CI run after kernel changes have landed to see lights turn green, land tests. If the test is behaving well with "broken" kernels it can even be landed before the kernel changes, if the used interfaces already exist in kernel upstream. -- Petri Latvala _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
