On Sat, Oct 12, 2013 at 1:19 AM, Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> wrote: > On Fri, 11 Oct 2013 14:34:35 -0700 > Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> wrote: > >> > Ideas: >> > - Make sure all lvds/edp connectors are enabled and bash on all backlight >> > interfaces (with igt_fork it's easy to do that concurrently). >> > - Race the above with output changes: dpms on/off and changing the crtc >> > around. >> > - Race the above with system suspend for bonus points (can be completely >> > stitched together from igt helpers). >> >> Sorry can't volunteer for that now, but those sound like good tests to >> write. > > To clarify per our discussion on IRC. I'll try to make some time next > week to add some tests for this. We'll need them for the further > intel_panel.c work (getting rid of all the bogus save/restore of the > bits sprinkled about now that we don't do display reset). > > But I don't want this fix (once I fix the locking) blocked on > those tests, since they'll probably take me a few days and people are > already using the original version, which is missing the locks for the > backlight class and ASLE call sites. Yeah, I'm happy with this plan. Unfortunately it looks like this is another hornet's nest. So having a bit (and even if it's just a tiny little bit) of automated sanity checking and stress-testing of the locking should help to avoid the "two steps left, one back" dance we so often fall into. So if you have ideas for more effective tests than my quick list just do those, after all you'll know better how to blow this up after a few days of banging your head against the problem than me ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
