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.
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:
I hope both facts (especially the latter) can fully convince you, and if they
don't, I'll try harder
Sustaining Engineer (system)
Canonical OEM Services
kernel-team mailing list