[PATCH] More radeonfb fixes

[PATCH] More radeonfb fixes

[Benjamin Herrenschmidt]

Here's a new patch against 2.4.20 and 2.4.21-pre7 which brings more
fixes to radeonfb:

- Fix the M6 video RAM workaround
- Some bits in the PM code were flipped, fix that.
- RB2D_DSTCACHE_MODE shouldn't be cleared on r300 (and
  maybe not on others according to a comment in XFree, but
  we keep working code for now).
- Re-change the pitch workaround. We now align the pitch
  when accel is enabled for a given mode, and we don't when
  accel is disabled. That should properly deal with all cases
  and allows us to remove the "special case" accel code
- Bring in XFree workaround to not write the same value to
  the PLL (can cause blanking of some panels)
- Bring in some of Peter Horton fixes (accel reset, cleanups)
  still some more to get in though...
- Properly reset accel engine on each console switch so
  we work around switching from XFree leaving it in a weird
  state. Also extend the comparison of values causing us to
  reload the mode on console switch.

NOTE: The 2.4.20 patch no longer mess with non related entries
in pci_ids.h, however the 2.4.21 patch still adds a couple of
new ones not related to radeons, but that should be harmless.

Patches available at:

http://www.penguinppc.org/~benh/radeonfb-041103-2.4.20.diff
http://www.penguinppc.org/~benh/radeonfb-041103-2.4.21-pre7.diff

Ben.

[HINTS] Re: More radeonfb fixes

[Petr Baudis]

Hello,

Dear diary, on Fri, Apr 11, 2003 at 02:03:13PM CEST, I got a letter,
where Benjamin Herrenschmidt <benh@kernel.crashing.org> told me, that...
> Here's a new patch against 2.4.20 and 2.4.21-pre7 which brings more
> fixes to radeonfb:
> 
> - Fix the M6 video RAM workaround
> - Some bits in the PM code were flipped, fix that.
> - RB2D_DSTCACHE_MODE shouldn't be cleared on r300 (and
>   maybe not on others according to a comment in XFree, but
>   we keep working code for now).
> - Re-change the pitch workaround. We now align the pitch
>   when accel is enabled for a given mode, and we don't when
>   accel is disabled. That should properly deal with all cases
>   and allows us to remove the "special case" accel code
> - Bring in XFree workaround to not write the same value to
>   the PLL (can cause blanking of some panels)
> - Bring in some of Peter Horton fixes (accel reset, cleanups)
>   still some more to get in though...
> - Properly reset accel engine on each console switch so
>   we work around switching from XFree leaving it in a weird
>   state. Also extend the comparison of values causing us to
>   reload the mode on console switch.

thanks a lot, this patch solved my quite annoying framebuffer problems with the
stock 2.4.21rc1 radeonfb driver on ATI Radeon 7000 w/ 64MB RAM :-).

If you are interested in some bugreports and don't want to read the following
semi-minihowto, please just look for the [PERHAPS-BUGREPORT] string.

In order to give advice to the fellow googlers possibly seeing this in
archives: if you have annoying long delays when switching between consoles or
the video mode you specify on the cmdline carefully results in just an ugly
mess,

* before trying anything out, something about modes and refresh rates (does NOT
  cover interlaced modes):

  - fbset excepts modes in the format of <X>x<Y>-<refreshrate>, while kernel
    excepts the modes in the format of <X>x<Y>[-<depth>][@<refreshrate>. Beware
    this difference. More about modes on commandline below.

  - the kernel and fbset modes database is not in sync. You may find it useful
    to add

mode "1024x768-85"
    # D: 98.902 MHz, H: 70.243 kHz, V: 85.454 Hz
    geometry 1024 768 1024 768 8
    timings 10111 192 32 34 14 160 6
endmode

    to your /etc/fb.modes --- it is the highest refresh rate my monitor
    supports for this resolution.

  - when you want to convert a modedb record from kernel to fb.modes format,
    look into the modedb database at drivers/video/modedb.c, the structure
    format is described in include/linux/fb.h. Probably the easiest way is to
    do variation of

fbset -xres 1024 -yres 768 -depth 24 -match -left .... -hslen ....

    with the values filled accordingly to the structure. Then run

fbset

    and insert the output (ONLY the lines shown above in the example) to
    /etc/fb.modes.

  - the most common refresh rates appear to be 60,70,85 ; kernel has also 76,
    while fbset knows about 75 ; obviously not all rates can be used with all
    resolutions, this is basically what I use with 1024x768 --- I think at
    least 60 should work with almost everything, though.

* try this patch

* be careful when including any vga=... parameters; if it doesn't work, try to
  remove them

* when something does not work, try to login blindly and type

fbset 800x600-60

  (or some other mode known to work). If nothing does happen, try to switch to
  some other console and back (however that probably means you are still using
  the old and broken driver).

* be careful when specifying the mode string at the kernel (lilo) commandline:

  - generally, the parameter will look like

video=radeon:<mode>

    (some more flags can follow, comma-separated)

  - you should always specify the refresh rate, otherwise the highest possible
    one could be used and your monitor may not handle it.

[PERHAPS-BUGREPORT]

  - BE CAREFUL when specifying depth! This is basically where I was most burnt,
    I kept specifying 24 but for some strange reason, this did very strange
    things here. If you will specify some other depth (8,15,16,32,...), you may
    experience problems with cursor (or it just won't work at all ;) --- it
    could have different colors (which will change by time), eventually
    disappearing completely (this could mean it just went black..?).

    The best solution is probably not to specify the depth at all. Apparently,
    24 is used by default, but it seems to work when chosen defaultly :^).

  - this is what I use:

video=radeon:1024x768@85

* don't try to use anything svgalibish. SvgaLib appears not to play well with
  Radeon's framebuffer w/ default configuration (I've managed to run zgv along
  nvidia fb) (or maybe it cannot handle Radeon at all..?) and it will complain
  about some register not being set high enough (admittelly, I didn't yet
  attempt to fix that and see what happens). The main thing is though that it
  leaves the card in some unknown mode and monitor goes sleep. See below.

* when you will have your Radeon in some weird state (after trying to run some
  svgalibish application or naively selecting vesa video output in mplayer or
  so..), you can either:

[PERHAPS-BUGREPORT]

  - startx or switch to X and back if you have it already running. This will
    repair it, but it won't reset all the flags (ie. accel), so you will get
    delays when switching to the affected console caused by video mode changes.

  - fbset on the affected console, which will also properly reset all these
    flags. You can obviously first get usable console by letting X to reset it
    and then running fbset on it, if you like to see what are you typing. Note
    that you should reset the console to the same mode you are running on the
    other consoles, otherwise you won't get rid of that delays.

[PERHAPS-BUGREPORT]

* you will have that ugly video mode change also the first time you switch to
  some console. This appears to be a bug, I think it could be fixed quite
  easily. You can either live with it or fix it or workaround it by doing
  something smart with for, seq and chvt in your rc scripts (let this be a
  homework ;-).


It is just a mix of generic fb usage advices and Radeon-specific ones... well,
what I had to discover by myself in the last few hours ;-). Perhaps it could
find a comfortable place in Documentation/fb/, dunno.

Kind regards,

-- 
 
				Petr "Pasky" Baudis
.
A man once asked Mozart how to write a symphony. Mozart told him to study at
the conservatory for six or eight years, then apprentice with a composer for
four or five more years, then begin writing a few sonatas, pieces for string
quartets, piano concertos, etc. and in another four or five years he would be
ready to try a full symphony. The man said, "But Mozart, didn't you write a
symphony at age eight?" Mozart replied, "Yes, but I didn't have to ask how."
.
Stuff: http://pasky.ji.cz/

Re: [HINTS] Re: More radeonfb fixes

[Benjamin Herrenschmidt]

> 
> thanks a lot, this patch solved my quite annoying framebuffer problems with the
> stock 2.4.21rc1 radeonfb driver on ATI Radeon 7000 w/ 64MB RAM :-).

Good ;)

> If you are interested in some bugreports and don't want to read the following
> semi-minihowto, please just look for the [PERHAPS-BUGREPORT] string.
> 
> In order to give advice to the fellow googlers possibly seeing this in
> archives: if you have annoying long delays when switching between consoles or
> the video mode you specify on the cmdline carefully results in just an ugly
> mess,

Known. I have to work on this next

> [PERHAPS-BUGREPORT]
> 
>   - BE CAREFUL when specifying depth! This is basically where I was most burnt,
>     I kept specifying 24 but for some strange reason, this did very strange
>     things here. If you will specify some other depth (8,15,16,32,...), you may
>     experience problems with cursor (or it just won't work at all ;) --- it
>     could have different colors (which will change by time), eventually
>     disappearing completely (this could mean it just went black..?).
> 
>     The best solution is probably not to specify the depth at all. Apparently,
>     24 is used by default, but it seems to work when chosen defaultly :^).

8 is the default and works fine. 15,16 and 32 work but the cursor isn't
properly rendered, this is a known fbdev problem in 2.4, I'll probably
fix it by implementing HW cursor support in radeonfb. 24 bpp is a weird
mode that isn't really supported by the driver

> * when you will have your Radeon in some weird state (after trying to run some
>   svgalibish application or naively selecting vesa video output in mplayer or
>   so..), you can either:
> 
> [PERHAPS-BUGREPORT]
> 
>   - startx or switch to X and back if you have it already running. This will
>     repair it, but it won't reset all the flags (ie. accel), so you will get
>     delays when switching to the affected console caused by video mode changes.
> 
>   - fbset on the affected console, which will also properly reset all these
>     flags. You can obviously first get usable console by letting X to reset it
>     and then running fbset on it, if you like to see what are you typing. Note
>     that you should reset the console to the same mode you are running on the
>     other consoles, otherwise you won't get rid of that delays.

What is a bug ? the delays ? The fact that some apps leave garbage ? The
former is normal when an actual mode switch occurs. The later is a
problem with apps that bang the HW (and with X as well in some cases as
it will occasionally fuck up the accel engine configuration).

The problem is that currently, the fbcon/fbdev interface doesn't provide
a hook for fbdev's to force a restore of the mode & engine setting when
an app leaves the KD_GRAPHICS mode.
 
> [PERHAPS-BUGREPORT]
> 
> * you will have that ugly video mode change also the first time you switch to
>   some console. This appears to be a bug, I think it could be fixed quite
>   easily. You can either live with it or fix it or workaround it by doing
>   something smart with for, seq and chvt in your rc scripts (let this be a
>   homework ;-).

The "new" consoles aren't initialized, thus the driver do a mode change
when switching to them. Well... I can try to fix that...
> 
> It is just a mix of generic fb usage advices and Radeon-specific ones... well,
> what I had to discover by myself in the last few hours ;-). Perhaps it could
> find a comfortable place in Documentation/fb/, dunno.
> 
> Kind regards,
-- 
Benjamin Herrenschmidt <benh@kernel.crashing.org>