On Sat, Oct 12, 2013 at 1:55 AM, Daniel Vetter <daniel@xxxxxxxx> wrote: > 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 ;-) Aside: For patch that fix existing bugs where we can directly reproduce the issue in upstream with a test (e.g. tiling after resume broken) I prefer to first commit the testcase to igt and then wait 2-3 days. If the testcase is ready with the patch this can nicely overlap with the patch review and allows us to check the robustness of the testcase: If QA doesn't file a new bug, something isn't quite working (either in the test or with QA), and we need to figure out what's wrong. At least for gem issues this has been SOP. -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
