[Intel-gfx] [PATCH 1/2] drm/i915: make backlight functions take a connector v3

[Daniel Vetter]

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
>>> 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