Re: [Bug #12806] i915 broken STR

Rafael J. Wysocki
2009-03-10T19:25:44Z

On Tuesday 10 March 2009, Eric Anholt wrote:
> On Tue, 2009-03-10 at 14:56 +0100, Rafael J. Wysocki wrote:
> > On Tuesday 10 March 2009, Eric Anholt wrote:
> > > On Sat, 2009-03-07 at 22:28 +0100, Rafael J. Wysocki wrote:
> > > > On Saturday 07 March 2009, Harvey Harrison wrote:
> > > > > On Tue, 2009-03-03 at 20:25 +0100, Rafael J. Wysocki wrote:
> > > > > > This message has been generated automatically as a part of a report
> > > > > > of recent regressions.
> > > > > >
> > > > > > The following bug entry is on the current list of known regressions
> > > > > > from 2.6.28. Please verify if it still should be listed and let me know
> > > > > > (either way).
> > > > > >
> > > > > >
> > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12806
> > > > > > Subject : i915 broken STR
> > > > > > Submitter : Harvey Harrison <harvey.harrison@gmail.com>
> > > > > > Date : 2009-02-28 4:20 (4 days old)
> > > > > > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5669fcacc58bf3a7386057addffd280d75380858
> > > > > > References : http://marc.info/?l=linux-kernel&m=123579487801064&w=4
> > > > > >
> > > > > >
> > > > >
> > > > > This looks to have been a case of old-userspace..upgrading to
> > > > > xorg-intel-video 2.6.1 (ubuntu Jaunty Alpha5) fixes STR here.
> > > >
> > > > Well, thanks, but I'm not really sure if this is a good news.
> > > >
> > > > Jesse, Eric, does it mean we now break resume on anything earlier than 2.6.1
> > > > on the Harvey's hardware?
> > >
> > > There's not much information (dmesg, Xorg.0.log) with this bug -- I'm
> > > guessing he's using KMS, given that that commit was where the problems
> > > started. If so, yes, you really do need good userland for KMS to work.
> >
> > BTW, Is suspend generally supposed to work with KMS and the 2.6.1 (or later) X
> > driver?
>
> I pulled a giant pile of KMS bugfixes into 2.6.2, so I'm not sure about
> 2.6.1.
>
> We've still got some work to do with making our suspend/resume path
> really complete for KMS. We're missing some register setup that UMS
> does, so behavior can be a bit random. The current plan is to switch to
> using the KMS modeset paths for resume, so we hopefully have reliable
> (or at least consistent) mode setting behavior, and then fill those
> remaining register writes in around it. Basically, a separate
> suspend/resume path for KMS, when we have full control of the device.

OK, thanks.

Best,
Rafael