[PATCH 10/27] drm/atomic-helper: nonblocking commit support

[Daniel Vetter]

On Wed, Jun 8, 2016 at 5:54 PM, Chris Wilson <chris at chris-wilson.co.uk> 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