[Intel-gfx] [PATCH 1/2] drm/i915: make backlight functions take a connector v3
daniel at ffwll.ch
Sat Oct 12 02:06:10 CEST 2013
On Sat, Oct 12, 2013 at 1:55 AM, Daniel Vetter <daniel at ffwll.ch> wrote:
> On Sat, Oct 12, 2013 at 1:19 AM, Jesse Barnes <jbarnes at virtuousgeek.org> wrote:
>> On Fri, 11 Oct 2013 14:34:35 -0700
>> Jesse Barnes <jbarnes at virtuousgeek.org> 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
>> 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
At least for gem issues this has been SOP.
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
More information about the Intel-gfx