[PATCH] mach64: fix console corruption in 24bpp mode

Mikulas Patocka mpatocka at redhat.com
Sat Aug 25 19:48:14 UTC 2018



On Sun, 19 Aug 2018, Ville Syrjälä wrote:

> On Fri, Aug 17, 2018 at 03:15:52PM -0400, Mikulas Patocka wrote:
> > There's console font corruption when using the mach64 driver in 24bpp
> > mode.
> > 
> > In 24bpp mode, the mach64 accelerator is set up for 8-bpp mode (with
> > horizontal width and stride multiplied by 3). In this mode, the
> > accelerator can't even possibly support color expansion. Consquently, we
> > have to use an unaccelerated function cfb_imageblit for color expansion.
> 
> Hmm. I would think it should work just fine since we feed in each bit
> three times and the hw 24bpp rotate thing should take care of selecting
> the right component.
> 
> -               if (M64_HAS(HW_TRIPLE) && image->width % 8 == 0)
> +               if (M64_HAS(HW_TRIPLE) && width % 8 == 0)
> 		                        pix_width |= DP_HOST_TRIPLE_EN;
> perhaps?

This doesn't have any effect (width is image->width * 3 and multiplication 
by 3 doesn't affect divisibility by 8).

But I have looked at it deeper and I realized that we could fix the screen 
corruption and use the accelerator in 24bpp mode. I'll send the patches in 
following emails.

There's endianity problem in the code that does manual bit triple in 
atyfb_imageblit (I am using this driver on sparc64). After fixing this, 
some of the corruption is fixed, but not all of it (there's still 
corruption when the screen is scrolled).

Another bug is that the function atyfb_imageblit is reading the 
accelerator registers without waiting for the idle engine - so it reads 
some indetermediate value of some previous command. I reworked the 
accelerator functions so that they don't read the registers at all. After 
fixing these two bugs, I don't observe any corruption at all.

I also noticed that loading the bitmap is inefficient - for every word 
written, the driver reads the fifo status register and these reads are 
slow and cannot be queued. I improved the function wait_for_fifo, so that 
if there's more space than we need, it remembers the surplus and it 
doesn't have to read the register next time.

Mikulas


More information about the dri-devel mailing list