[PATCH] [Karmic SRU] [Lucid] drm/i915: Fix sync to vblank when VGA output is turned off

[Alberto Milone]

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

I hope both facts (especially the latter) can fully convince you, and if they 
don't, I'll try harder ;)

Regards,

-- 
Alberto Milone
Sustaining Engineer (system)
Foundations Team
Canonical OEM Services