[PATCH] don't suspend/resume 8xx chips

[PATCH] don't suspend/resume 8xx chips

[Jesse Barnes]

Recent testing has turned up some bugs in the new Intel suspend/resume code 
for old, 8xx chipsets.  So for 2.6.25 it probably makes sense to apply this 
patch, which should prevent the new code from getting called on those 
chipsets.  We should have this fixed soon, but not in time for 2.6.25 
unfortunately.  Note that this patch (along with the suspend/resume code in 
general) could use more testing.

Signed-off-by:  Jesse Barnes <jesse.barnes@intel.com>

diff --git a/drivers/char/drm/i915_dma.c b/drivers/char/drm/i915_dma.c
index e9d6663..6964a28 100644
--- a/drivers/char/drm/i915_dma.c
+++ b/drivers/char/drm/i915_dma.c
@@ -762,6 +762,11 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long
        unsigned long base, size;
        int ret = 0, mmio_bar = IS_I9XX(dev) ? 0 : 1;

+       if (!IS_I9XX(dev)) {
+               dev->driver->suspend = NULL;
+               dev->driver->resume = NULL;
+       }
+
        /* i915 has 4 more counters */
        dev->counters += 4;
        dev->types[6] = _DRM_STAT_IRQ;

Re: [PATCH] don't suspend/resume 8xx chips

[Soren Hansen]

[-- Attachment #1: Type: text/plain, Size: 880 bytes --]

On Wed, Mar 26, 2008 at 04:28:12PM -0700, Jesse Barnes wrote:
> Recent testing has turned up some bugs in the new Intel suspend/resume code 
> for old, 8xx chipsets.  So for 2.6.25 it probably makes sense to apply this 
> patch, which should prevent the new code from getting called on those 
> chipsets.  We should have this fixed soon, but not in time for 2.6.25 
> unfortunately.  Note that this patch (along with the suspend/resume code in 
> general) could use more testing.

I've tested this patch on two different laptops: A Uniwill 223 and an
IBM Thinkpad X40. Both have Intel 855 graphics. The former now suspends
and hibernates just fine (it fails without the patch). The latter works
both with and without the patch.

-- 
Soren Hansen               | 
Virtualisation specialist  | Ubuntu Server Team
Canonical Ltd.             | http://www.ubuntu.com/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] don't suspend/resume 8xx chips

[Pavel Machek]

On Wed 2008-03-26 16:28:12, Jesse Barnes wrote:
> Recent testing has turned up some bugs in the new Intel suspend/resume code 
> for old, 8xx chipsets.  So for 2.6.25 it probably makes sense to apply this 
> patch, which should prevent the new code from getting called on those 
> chipsets.  We should have this fixed soon, but not in time for 2.6.25 
> unfortunately.  Note that this patch (along with the suspend/resume code in 
> general) could use more testing.
> 
> Signed-off-by:  Jesse Barnes <jesse.barnes@intel.com>
> 
> diff --git a/drivers/char/drm/i915_dma.c b/drivers/char/drm/i915_dma.c
> index e9d6663..6964a28 100644
> --- a/drivers/char/drm/i915_dma.c
> +++ b/drivers/char/drm/i915_dma.c
> @@ -762,6 +762,11 @@ int i915_driver_load(struct drm_device *dev, unsigned 
> long
>         unsigned long base, size;
>         int ret = 0, mmio_bar = IS_I9XX(dev) ? 0 : 1;
> 
> +       if (!IS_I9XX(dev)) {
> +               dev->driver->suspend = NULL;
> +               dev->driver->resume = NULL;
> +       }
> +

Are you sure your driver needs no state saving?

Maybe register suspend that printks, returns error?
							Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH] don't suspend/resume 8xx chips

[Jesse Barnes]

On Friday, March 28, 2008 7:40 am Pavel Machek wrote:
> On Wed 2008-03-26 16:28:12, Jesse Barnes wrote:
> > Recent testing has turned up some bugs in the new Intel suspend/resume
> > code for old, 8xx chipsets.  So for 2.6.25 it probably makes sense to
> > apply this patch, which should prevent the new code from getting called
> > on those chipsets.  We should have this fixed soon, but not in time for
> > 2.6.25 unfortunately.  Note that this patch (along with the
> > suspend/resume code in general) could use more testing.
> >
> > Signed-off-by:  Jesse Barnes <jesse.barnes@intel.com>
> >
> > diff --git a/drivers/char/drm/i915_dma.c b/drivers/char/drm/i915_dma.c
> > index e9d6663..6964a28 100644
> > --- a/drivers/char/drm/i915_dma.c
> > +++ b/drivers/char/drm/i915_dma.c
> > @@ -762,6 +762,11 @@ int i915_driver_load(struct drm_device *dev,
> > unsigned long
> >         unsigned long base, size;
> >         int ret = 0, mmio_bar = IS_I9XX(dev) ? 0 : 1;
> >
> > +       if (!IS_I9XX(dev)) {
> > +               dev->driver->suspend = NULL;
> > +               dev->driver->resume = NULL;
> > +       }
> > +
>
> Are you sure your driver needs no state saving?
>
> Maybe register suspend that printks, returns error?

No, there's definitely state we'd like to save/restore, but 8xx chips are 
tricky and we won't have them working before 2.6.25-final.  This patch 
preserves old behavior for 8xx chips and allows 9xx chips to properly survive 
suspend/resume events, so I don't think a printk is necessary.

Jesse

Re: [PATCH] don't suspend/resume 8xx chips

[Jesse Barnes]

On Thursday, March 27, 2008 1:38 am Soren Hansen wrote:
> On Wed, Mar 26, 2008 at 04:28:12PM -0700, Jesse Barnes wrote:
> > Recent testing has turned up some bugs in the new Intel suspend/resume
> > code for old, 8xx chipsets.  So for 2.6.25 it probably makes sense to
> > apply this patch, which should prevent the new code from getting called
> > on those chipsets.  We should have this fixed soon, but not in time for
> > 2.6.25 unfortunately.  Note that this patch (along with the
> > suspend/resume code in general) could use more testing.
>
> I've tested this patch on two different laptops: A Uniwill 223 and an
> IBM Thinkpad X40. Both have Intel 855 graphics. The former now suspends
> and hibernates just fine (it fails without the patch). The latter works
> both with and without the patch.

Soren, can you give the current DRM tree a try or apply the patch in 
http://cgit.freedesktop.org/mesa/drm/commit/?id=cb33133ef354b77a8cf06b16ce95a0babbe8bc6f?  
I'm hoping it'll fix the one machine that had a problem and not break the 
other. :)  I tested it on my new 855 machine and it fixes things here...

Thanks,
Jesse