Added a new scrolling mode (SCROLL_PAN_REDRAW) to fbcon that should greatly
benefit unaccelerated drivers such as VESA fbdev.  An increase of 3-10 times
in scrolling speed can be expected.

Currently, fbcon has 4 different scrolling methods (1-4).  Potentially, we can
have 6.  This patch implements SCROLL_PAN_REDRAW (5).  SCROLL_WRAP_REDRAW (6)
is still unimplemented.

Scroll Mode		Operation	YPan	YWrap
+++++++++++++++++++++++++++++++++++++++++++++++++++++
1. SCROLL_ACCEL		copyarea	No	No
2. SCROLL_REDRAW	imageblit	No	No
3. SCROLL_PAN		copyarea	Yes	No
4. SCROLL_WRAP		copyarea	No	Yes
5. SCROLL_PAN_REDRAW 	imageblit	Yes	No	
6. SCROLL_WRAP_REDRAW	imageblit	No	Yes
+++++++++++++++++++++++++++++++++++++++++++++++++++++
Note 1:  I've changed the nomenclature to increase clarity:

SCROLL_ACCEL = SCROLL_MOVE
SCROLL_REDRAW = SCROLL_REDRAW
SCROLL_PAN = SCROLL_PAN_MOVE
SCROLL_WRAP = SCROLL_WRAP_MOVE

To demonstrate the effect of each of the scrolling methods on
an unaccelerated PCI/AGP-based driver (vesafb), I used a simple
benchmark (time cat linux/MAINTAINERS - a 50K text file). The
framebuffer is set at:

1024x768-8bpp, 8x16 font, yres_virtual = 2*yres

1. SCROLL_MOVE:
real    5m50.277s
user    0m0.001s
sys     5m50.227s

Almost 6 minutes for a 50K text file.  Using soft copyarea on a
PCI-based card is just too slow (because copyarea has to 
read from the framebuffer memory).

2. SCROLL_PAN_MOVE
scrollmode: SCROLL_PAN
real    0m8.592s
user    0m0.000s
sys     0m8.586s

Using ypan with copyarea dramatically improves the scrolling.  However, the
scrolling action is jerky (fast during the panning stages, slows down during
the copyarea stages).

3. SCROLL_REDRAW (this is the default scrolling mode)
real    0m3.189s
user    0m0.000s
sys     0m3.170s

Simply eliminating the copyarea, even without ypanning, makes it faster than
SCROLL_PAN_MOvE.  Plus, the scrolling action is smoother.

So, if we combine YPanning with imageblit (PAN_REDRAW), we get this:

4. SCROLL_PAN_REDRAW
real    0m0.520s
user    0m0.000s
sys     0m0.518s

That's almost 6x faster than SCROLL_REDRAW.  Increasing the amount of video
RAM still increases the speed, but not very dramatically.  Higher than 16 MB,
the increase is negligible.

Using an accelerated driver, we see almost the same effect but not as
dramatically:

1. SCROLL_MOVE - accel
real    0m3.112s
user    0m0.000s
sys     0m3.112s

2. SCROLL_REDRAW - accel
real    0m2.604s
user    0m0.000s
sys     0m2.603s

Redraw is still faster than move, but not much.

3. SCROLL_PAN_MOVE - accel
real    0m0.203s
user    0m0.000s
sys     0m0.202s

4. SCROLL_PAN_REDRAW - accel
real    0m0.326s
user    0m0.002s
sys     0m0.323s

This is one exception.  If panning is enabled, move is actually faster than
redraw.  As to why, I don't know.

So based on the above, fbcon will choose the scrolling method based on the
following preference:

Ypan/Ywrap > accel imageblit > accel copyarea >
soft imageblit > (soft copyarea)

Note 2: Exception: accel copyarea > accel imageblit if Pan/Wrap is enabled.

Note 3: soft copyarea will be avoided by fbcon as much as possible unless
there is a specific override, ie., FBINFO_READS_FAST flag is set.  If this
flag is set, fbcon will prefer copyarea over imageblit, accel or soft.

As a final note, in order for fbcon to use the best scrolling method, the
low-level drivers must provide the correct hinting by setting the
FBINFO_HWACCEL_* flags.

To vesafb users: boot vesafb like this for fastest scrolling action:

video=vesafb:ypan,vram:16
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>