Bug 1837

The radeonfb driver in kernel24-2.4.20-alt0.8-up is broken.  It gives
garbage on the screen when doing many operations (browsing text files
with \'less\', editing the command line, ...).  Even clearing the screen
does not work - it leaves some garbage (and sometimes does not clear
anything at all).

Looking at the source, I have found several problems (and tried to fix
them - the patch is attached):

1. A very common bug (it is also present in the aty128fb driver - see
#992; also likely to be present in clgenfb, pm2fb, tdfxfb, tridentfb,
sisfb): putting fbcon_cfb* functions directly into the display_switch
structure when some other functions use the accelerator.  This does not
work correctly - radeon_engine_idle() must always be called before
directly accessing the framebuffer memory (which fbcon_cfb* functions
do).

I have added wrappers for all fbcon_cfb* functions which call
radeon_engine_idle().

2. A similar bug: missing fb_rasterimg handler (which should wait for
the accelerator operations to complete).  I have added such handler to
the driver.

3. radeon_engine_init() was not called after changing the video mode,
therefore the accelerated functions did not work after fbset.  I have
added call to radeon_engine_init() in radeonfb_set_var(), after
radeon_load_video_mode().

4. The accelerator initialization sequence in radeon_engine_init() has a
nasty bug: OUTREG(DSTCACHE_MODE, 0) does not do what is expected because
the value of DSTCACHE_MODE is wrong - so a write into some unrelated
register is performed, and this screws up even X (started when the
framebuffer driver is active).

I have added the correct define RB2D_DSTCACHE_MODE (taken from the
XFree86 radeon driver).

5. The accelerator reset sequence in _radeon_engine_reset() also did not
work: after X was started, the correct framebuffer display could not be
restored (the result was either a blank screen or some garbage).  I have
noticed that the XFree86 radeon driver does the reset differently (it
contains a comment stating that resetting HDP thru RBBM_SOFT_RESET does
not work).  I have implemented the same reset sequence as in the XFree86
driver - this fixed the problem.

This bug did not show up until the problem 3 above was corrected,
because the accelerator reset was not performed except during the module
initialization.

6. The initialization of DEFAULT_PITCH_OFFSET in radeon_engine_init()
was causing problems.  After fixing the previously mentioned bugs, the
driver mostly worked without X, but after starting X and switching back
to the console the machine crashed and rebooted after starting \'less\'
and displaying about two pages of text.  (This problem also did not show
up until fixing the problem 3 above, for the same reason.)

I have replaced the initialization of DEFAULT_PITCH_OFFSET with the code
taken from the XFree86 radeon driver (which, BTW, also contains the same
old code, but commented out with #if 0); this fixed the problem.

7. After changing the video mode with fbset (setting some other
resolution) the screen sometimes was not updated properly (showing the
previous contents of the screen, but as garbage due to changed line
length).  The problem was that radeonfb_set_var() called info->changevar
too early - before actually setting the video mode and updating the
accelerator state.  Because of this, the update_screen() call inside the
changevar handler could not redraw the console contents.

I have moved the call to info->changevar to the proper place - after the
video mode setup.

8. After modifying the video mode with fbset without changing the
resolution (e.g., \'fbset -move left\' or something similar - so that the
screen size will not change) the screen offset was not updated properly.
Example: press Enter enough times so that the screen will be scrolled,
then run \'fbset -move left\' - the top of the scrollback buffer will be
shown instead of the expected screen contents.

There were several things involved here:

  - radeonfb_set_var() did not handle var->xoffset and var->yoffset
    fields properly - in fact, they were ignored completely, and
    CRTC_OFFSET was set to 0.  I have added the call to
    radeonfb_pan_display() after radeon_load_video_mode() to set the
    screen offset properly.

  - radeonfb_set_var() did not check var->yoffset when determining if
    info->changevar should be called (according to the code in fbgen.c,
    this field should be compared with the old value).  I have added the
    needed check to the calculation of chgvar.

  - radeonfb_pan_display() did not save the specified var->xoffset and
    var->yoffset values anywhere, except writing them to the chip (in
    fact, xoffset was not implemented at all).  Because of this, the
    above comparison in radeonfb_set_var() did not work, and
    radeonfb_get_var() did not return the correct offset values.  I have
    added the code to save the offsets, and also added support for
    xoffset (it is needed for XFree86 when using the UseFBDev option).

9. I also have performed several minor fixes:

  - Added call to radeon_engine_init() in _radeon_fifo_wait() and
    _radeon_engine_idle(), if the operation is timed out (the XFree86
    driver does this to try to recover from accelerator lockup).

  - Removed an unused dp_cntl = DST_LAST_PEL from fbcon_radeon_bmove().

  - Added apparently missing rinfo->ram.tr2w = 1 to the SDR SGRAM memory
    parameters.



The changes were tested with the Gigabyte GV-AP64D card (Radeon 8500LE
[QL], 64M DDR SDRAM), both in the console-only mode and together with X
(with the accelerated \"radeon_gatos\" driver, with and without UseFBDev,
but without DRI).

Working together with DRI support in X was _not_ tested.
---

---