Re: PB2000 (pismo) install feedback

This is the old RAMDAC problem of trying to write to the pallete
registers
too soon after setting the index, complicated by an integrated chipset
and
probably PCI I/O write posting as well. It results in the display having
about 8 vertical bands and a big bright spot alternating between them.
It also makes the bubbles in the layers of film making up the LCD show
through so that it looks a bit like when a frame of motion picture film
burns in the projector.

It's very timing sensitive, a slight rearrangment of the code eliminated
the "burnout", but didn't fix the ongoing offb colormap problems. Adding
a small delay between writing the index and the palette value fixed the
colomap problem. I rearranged the code to just set the index once and
then use the palette index register's auto-incrementing to avoid the
index write and delay in the loop, and that worked as well. I think
Ben is planning to use a read back of the index register to ensure the
write is posted and and give enough of a delay.

Does anyone know if any of the ATI chips don't have autoincrementing of
the palette index? That's been a fairly standard feature of RAMDAC's
for a long time. So I was a bit surprised to see the frame buffers
explicitly setting the index on every iteration, especially since
the race between writing the palette index and the data has been
a common problem for a long time.

Henry

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Thu, Mar 23, 2000, Henry Worth [off-list ref] wrote:

It's very timing sensitive, a slight rearrangment of the code eliminated
the "burnout", but didn't fix the ongoing offb colormap problems. Adding
a small delay between writing the index and the palette value fixed the
colomap problem. I rearranged the code to just set the index once and
then use the palette index register's auto-incrementing to avoid the
index write and delay in the loop, and that worked as well. I think
Ben is planning to use a read back of the index register to ensure the
write is posted and and give enough of a delay.

Does anyone know if any of the ATI chips don't have autoincrementing of
the palette index? That's been a fairly standard feature of RAMDAC's
for a long time. So I was a bit surprised to see the frame buffers
explicitly setting the index on every iteration, especially since
the race between writing the palette index and the data has been
a common problem for a long time.

What bugs me is that we have no such delay in aty128fb.c and you didn't
see the problem occur. Looks like a 1 instruction timing (one eieio) is
enough, so I beleive reading back the index is enough. We didn't have
this problem with older r128, so this may be a side effect of the
swadowing of the 2 sets of palette registers in the M3.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Benjamin Herrenschmidt wrote:

On Thu, Mar 23, 2000, Henry Worth [off-list ref] wrote:

quoted

It's very timing sensitive, a slight rearrangment of the code eliminated
the "burnout", but didn't fix the ongoing offb colormap problems. Adding
a small delay between writing the index and the palette value fixed the
colomap problem. I rearranged the code to just set the index once and
then use the palette index register's auto-incrementing to avoid the
index write and delay in the loop, and that worked as well. I think
Ben is planning to use a read back of the index register to ensure the
write is posted and and give enough of a delay.

Does anyone know if any of the ATI chips don't have autoincrementing of
the palette index? That's been a fairly standard feature of RAMDAC's
for a long time. So I was a bit surprised to see the frame buffers
explicitly setting the index on every iteration, especially since
the race between writing the palette index and the data has been
a common problem for a long time.

What bugs me is that we have no such delay in aty128fb.c and you didn't
see the problem occur. Looks like a 1 instruction timing (one eieio) is
enough, so I beleive reading back the index is enough. We didn't have
this problem with older r128, so this may be a side effect of the
swadowing of the 2 sets of palette registers in the M3

Possibly, with the extra control logic and the need to minimize the
gate count and power consumption for a mobile use, the control
logic may be somewhat slower than most modern chips. And with
all the integration and duplication, timing errors may send data
off to some very nasty places. Then again the Pismo and Sawmill
are cranking both CPU and I/O bus speeds up another notch, so
perhaps some of these classic timing issues will start cropping
up again.

The code in aty128fb.c isn't quite as tight as the offb.c
cases. In both aty128fb.c cases there is a statement between the
index out and the data out that does a couple of shifts to form
the palette data value, and there would be no advantage for the
compiler to schedule it before the first out. A quick grep didn't
find the definition for aty_st_8, is it completely identical to
out_8, particularly with the macros used to form the address?

The change from the case fall through to completely seperate
case blocks, which stopped the "burnout" effect in offb, would
have removed a barrier for optimization and register use between
setting the DAC select control and the palette index write.
So the code that didn't create the 'burnout' should have had
even less delay between out's. Which is really puzzling, yet
it was completely recreatable.

Henry

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Ben,

I've found the real problem with the linux-pmac_benh offb.c.
Simple pointer arithmetic problem. This fixes both the
"burnout" effect and the colormap problems.

Henry

*** offb.c.orig4        Sat Mar 25 00:20:05 2000

--- offb.c      Sat Mar 25 00:20:44 2000

***************
*** 914,920 ****
      case cmap_r128:
        /* Set palette index & data */
        out_8(info2->cmap_adr + 0xb0, regno);
!       out_le32((unsigned *)(info2->cmap_adr) + 0xb4,
                (red << 16 | green << 8 | blue));
        break;
      case cmap_M3B:

--- 914,920 ----
      case cmap_r128:
        /* Set palette index & data */
        out_8(info2->cmap_adr + 0xb0, regno);

!       out_le32((unsigned *)(info2->cmap_adr + 0xb4),
                (red << 16 | green << 8 | blue));
        break;
      case cmap_M3B:

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/