On Wed, Jun 8, 2016 at 5:54 PM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: > > On Wed, Jun 08, 2016 at 05:05:04PM +0200, Daniel Vetter wrote: >> On Wed, Jun 08, 2016 at 04:44:24PM +0200, Maarten Lankhorst wrote: >> > Op 08-06-16 om 14:19 schreef Daniel Vetter: >> > > Once that's done stall can be set to false in swap_states. >> > > >> > > Features: Contains bugs because totally untested. >> > ^I Hope not.. >> >> Indeed, tested on iirc 5 drivers now. Will remove when merging. > > What new tests were written for bugs uncovered when developing your > series? :) Must be one or two corner cases left untouched... Most of the discovered bugs are failing to handle events as atomic expects it too, and the coverage is that the new helpers are super-strict in enforcing this. They create events for any kind of modeset (even blocking ones), and if the driver fails to signal it properly the ioctl call stalls until it times out after 10s. So I believe that the driver-side is sufficiently covered with runtime checks already. The other bit is the correctness of the helpers themselves. And I think for that it doesn't matter much what kind of atomic commits we do, but how badly. IOW I believe the existing igt coverage (especially after the various extensions already done) is good enough. E.g. this does fixes the -EBUSY checks in kms_flip on all !i915 drivers (since no one bothered to implement that particular bit of evolved uapi ever really). And kms_flip makes sure it works and keeps working. Same for other corner cases. At least I think I didn't spot any bugs that igt didn't catch. Hence: Testcase: igt/kms_flip/* Testcase: igt/kms_cursor* Testcase: igt/kms*plane* But the main one is kms_flip - this is one shockingly nasty testcase ;-) > How much stubbing do we need to write a test-drm-atomic module that just > exercised the various paths with a fake device and so fail in a > controlled manner? With all the recent efforts to no-op out callbacks propably very little. The big thing to appeal igt is that vblank events are sensibly spaced, which needs a rearming hrtimer. There's always discussions going on whether virtual hardware should do that faking already (weston runs in a busy-loop without that), and if we have this in a nice little helper almost no code would be required. Not sure how much value that has, since the real atomic tests is checking for tearing, and that needs CRC checksums. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
