915gm/945gm/XAA lockup with gray blocks when switching video mode

[Keith Packard]

On Fri, 2007-10-12 at 21:09 +0100, Peter Clifton wrote:

> > -   for(i = 0; i < 256; i++) {
> > -      OUTREG(PALETTE_A + (i << 2), pI830->savePaletteA[i]);
> > +   if ((INREG(PIPEACONF) & PIPEACONF_ENABLE)) {
> > +      for(i = 0; i < 256; i++) {
> > +         OUTREG(PALETTE_A + (i << 2), pI830->savePaletteA[i]);
> > +      }
> >     }

I wondered if that might not be the fix we needed. Thanks for exploring
this and verifying that the problem goes away in this case.

> I didn't want to delve
> into how complex it might be to deliberately program both pipelines just
> for the sake of restoring their palette regs.

Fixing this to bring the pipe back up won't be that hard, and now we
know precisely when we'll need to do this. We've got code that sets a
fixed 640x480 mode on a pipe just for this purpose (i8xx machines have
lots of cases like this).

> The "correct"? fix might be to save the palette regs when the crtc
> pipleine is first used by the X11 driver, then re-program it before we
> shut it off. That way, only palettes which have been touched are
> re-programmed.

I'd prefer that the driver know how to save and restore the complete
state of the chip at one time, rather than distributing this knowledge
across various execution contexts.

> This would only manifest if X11 starts with some pipeline(s) disabled,
> then X11 enables both over the course of its runtime (and set their
> palettes). And.. then the BIOS would need to use both pipelines again.

We should at least make sure we know how to save and restore the
complete graphics state. It's a simple statement, and easy to verify.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20071013/c8d1722b/attachment.pgp>