Bug#825840: Possible fix for colour invertion on ATY,Rockhopper2

[lsorense@csclub.uwaterloo.ca (Lennart Sorensen)]

On Tue, Oct 04, 2016 at 08:20:13AM +0200, Mathieu Malaterre wrote:
> Hi,
> 
> > Well it seems ATY,Rockhopper2 (not Rockhopper) in the Mac Mini is in fact
> > a Radeon, and the way the radeonfb driver handles the pallete appears
> > to match the cmap_radeon in offb, so perhaps this would work in offb.c
> 
> I had time to test this patch yesterday night. It did not work using
> `cmap_radeon` codepath. I even tried changing:
> 
> out_le32(par->cmap_adr + 0xb4, (red << 16 | green << 8 | blue));
> 
> into:
> 
> out_le32(par->cmap_adr + 0xb4, (blue << 16 | green << 8 | red));
> 
> I am also thinking we are not looking at the right code.
> 
> I can see my `printk` messages so I know we are entering the
> `cmap_radeon` codepath.

Well radeonfb uses:

                        OUTREG(PALETTE_INDEX, pindex);
                        OUTREG(PALETTE_DATA, (red << 16) |
                               (green << 8) | blue);

which is :

		writel(pindex, (rinfo->mmio_base)+0x00B0)
		writel((red << 16) | (green << 8) | blue), (rinfo->mmio_base)+0x00B4)

offb in cmap_radeon mode uses:
                out_8(par->cmap_adr + 0xb0, regno);
                out_le32(par->cmap_adr + 0xb4, (red << 16 | green << 8 | blue));

Not sure if using out_8 for the index versus using a 32 bit write makes
a difference.  I highly doubt it.

The memory being mapped is 0x4000 in size for radeonfb and 0x2000 in offb.
For the colour table that sounds plenty big.

Of course radeonfb is using pci functions to get the memory range while
offb uses OF calls.  The dmesg output I have seen so far seems to indicate
these are both returning the same thing, so that is not likely to be
the problem.

As for radeon driver, it appears to me that it pretty much always runs
32 bit truecolor, which should solve any palette problems by not using
them.

-- 
Len Sorensen