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

[Peter Clifton]

On Thu, 2007-10-11 at 21:43 -0700, Bryce Harrington wrote:
> On Thu, Oct 11, 2007 at 05:19:28PM -0700, Jesse Barnes wrote:
> > On Wednesday, October 10, 2007, Bryce Harrington wrote:
> > > Commenting out this loop seems to resolve the issue.
> > > What is this loop for, and what do we risk by not having it?
> > 
> > The loop is needed for modes where we use the pallet.  But this might be 
> > a timing issue.  Can you try replacing the two pallet restore loops 
> > with delay loops of various kinds?  That would indicate whether the 
> > time it takes to restore the pallet is exposing a bug elsewhere.  
> > Alternately, you could add some small delays to the pallet restoration 
> > itself in the unlikely event that the pallet registers don't like to be 
> > written too quickly.
> 
> I tried adding a usleep(20) inside the loops, but the issue still came
> up (seemed like it took more attempts than normal to trigger, but that
> is hard to judge).
> 
> I'll also try replacing the pallet restore loops.

I've tried moving that loop above the rest of the restore code, as
elsewhere there was a comment that clocks need to be on for that to work
- and I wondered if we need time for clocks to stabilise after restoring
all the DPLL regs. I thought it helped, but no.. still crashes
eventually.

I have tried adding POSTING_READ(..) calls after any of the register
restores which had POSTING_READ(..) protection elsewhere in the code,
but this doesn't seem to help either.

> Could you also explain a bit more about what this pallet is?

I'm not sure how it sits physically in the video pipeline, but its
basically used to look up colours or gamma correction? values.

NB.. if you comment the palette restore completely, you'll see colours
in text mode are all grey-scale after a VT switch, so its not ideal!

Peter C