[PATCH] [Karmic SRU] [Lucid] drm/i915: Fix sync to vblank when VGA output is turned off
Stefan Bader
stefan.bader at canonical.com
Wed Dec 16 15:42:00 UTC 2009
Alberto Milone wrote:
> On Wednesday 09 Dec 2009 14:52:41 you wrote:
>> Alberto Milone wrote:
>>> Hi all,
>>>
>>> SRU Justification:
>>>
>>> The problem described in this email was reported in a private OEM bug
>>> report for Dell and has been solved by upstream. It's a regression in the
>>> drm code which causes a massive system slowdown if we turn off the VGA
>>> output.
>>>
>>> The patch is sane and minimal and is available in the drm-intel branch
>>> and in the linux-next branch (see the link to the commit in the bug
>>> report).
>>>
>>> I have applied (and slightly adapted, as it didn't apply cleanly to our
>>> lucid and karmic git branches) and tested the patch successfully in
>>> Karmic.
>>>
>>> The integration of this patch is very important for our Dell projects and
>>> for the Ubuntu desktop at large.
>>>
>>> Please include the attached patch in both Karmic and Lucid ASAP.
>>>
>>> Bug #494461
>>>
>>> Thanks in advance for your time.
>>>
>>> Regards,
>> This should actually have gone to stable as well as it fixes a regression.
>> Also the description sounds like the integration path should be stable as
>> well (as long as that is open).
>> The patch itself looks like it changes semantics of an exported function.
>> Before additional calls to drm_vblank_get() would return ok and increment
>> the ref count. After the change, additional calls will return an error and
>> not increment the count. On the good side it seems that function is only
>> used within drm_irq.c and the usage seems to be ok to handle that change.
>> Currently not 100% convinced to ack, but might get convinced.
>>
>> -Stefan
>>
>> -Stefan
>>
>
> Hi Stefan,
>
> I discussed this with Jesse (who reviewed the patch). It's ok to return an
> error in drm_vblank_get().
>
> Think of the case in which a client (a direct rendered 3d app such as compiz
> or a game) tries to wait on a pipe that is off (e.g. due to dpms), the client
> would do so, but if the pipe went off after a client waited, the client might
> never wake up. Furthermore if a pipe went off we might not catch it for a
> while. For this reason it's ok to return the error to the client.
>
> Furthermore the patch seems to be in the stable branch too:
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6-
> stable.git;a=commit;h=778c902640530371a169ad1c03566e7c51b09874
Just to note, this is the unified stable tree, which is not
stable. I believe it has Linus tree as master and stable branches
which, as I was told, get automatically created from the real
stable trees.
-Stefan
> I hope both facts (especially the latter) can fully convince you, and if they
> don't, I'll try harder ;)
>
> Regards,
>
More information about the kernel-team
mailing list