Re: radeonfb on pegasos powerpc motherboard and X endianess problem

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Thu, 2003-06-05 at 10:19, Sven Luther wrote:

> Err, is that the same devel tree as the one in linuxppc_2_4_devel ?

No, it's linuxppc_2_4_benh bk, though you can use rsync to extract
just radeonfb from rsync.penguinppc.org::benh-devel.

> And no, i cannot really try it out, i need to port the pop+pegasos
> patches first.
> 
> BTW, i have some questions about this :
> 
>   1) i think the hackyiness nature of it was because they simply #if 0
>   ed out code that didn't fit them, so doing proper #if CONFIG_PEGASOS
>   should clean this out, or was there also other kind of hackiness.

Ì don't have it all in mind now, send me your patches when you are
done and I'll tell you more.

>   2) head.S has some code which i guess is for early serial logging or
>   something such. I guess such a thing can never be part of the official
>   tree, right ?

That depends... It can be done cleanly without hacking head.S I beleive,
but I need to look at the code to tell you exactly

>   3) arch/ppc/platforms/chrp_setup.c got patched about io_block_mapping,
>   but this doesn't seem to exist anymore in the current
>   linuxppc_2_4_devel tree. Whatever happened to it, and what replaces it ?

You probably don't need it. Just ioremap what need to be ioremap'ed and
avoid any hard coded virtual addresses and things should be just fine.

> > >   2) when running X with the UseFBDev option the colors are bad, i guess
> > >   it is an endianess problem. (with and without accel)
> > 
> > What radeon card is this ?
> 
> Radeon 9000 non-pro (and thus fanless).
> 
> > >   3) When running X without the UseFBDev option, the colors are good,
> > >   but i get garbage when i return to the console. Not exactly garbage,
> > >   at first it is ok, but when i enter a line or somehow pan the screen,
> > >   the corruption start. Doing a vt switch and back redraws a clean
> > >   screen.
> > 
> > Known problem. This is actually a bit nasty. X doesn't fully restore the
> > engine state (and it's in fact quite difficult to know in which state
> > it should restore it) and there's no hook in the fbdev layer for
> > restoring things like that when switching from KD_GRAPHICS back to
> > KD_TEXT. I'm thinking about adding such a hook in 2.5. Usually, a VT
> > switch will trigger a restore of the engine state, at least it will
> > with my version of the driver.
> 
> Mmm, so is this a problem in the X server or in the fbdev driver ? I
> understand that you will fix this in the fbdev since you have a more
> difficult time doing it in the X driver, but this does mean that the X
> driver will do a partial save/restore, and that fbdev will then do a
> full save/restore ? Seems overkill to me. We can either fix it in the
> fbdev driver (which will know which registers the fbdev needs to backup)
> or in the X driver (which will know about which register x needs to
> backup).

Not exactly. I'm not sure X can restore the engine state exactly
(maybe it can, but imho, it's a bit overkill). I tend to think that
the fbdev shall do it as it's very much easier. On one side, X would
have to backup & restore an insane amount of registers, on the other
side, fbdev can just re-init the engine to the state it wants in a few
dozen lines of code.

So my idea was to fix the fbdev interface so that fbdev's in general
have a hook when a console witch from KD_GRAPHICS to KD_TEXT (that
is basically when fbcon gets back control) so things can be reset
properly.  

> Maybe it would be nice if the fbdev driver could save/restore the fbdev
> used registers, and tell the X driver by a information hook that it did
> do the saving, and then the X driver would not need to save/restore the
> registers when UseFBDev was used.

X already save/restore things related to mode setting. The accel engine
is another problem (and not related to use of UseFBDev or not, the
problem is the same in both cases).

I don't think any of such 'hooks' in the fbdev<->X interface will be
ever accepted by X folks like Marc Aurele ;) (He never allowed fbdev
support to be added to the mach64 driver for example)

> Ah, so it is not true that one chrp, the northbridge did the endianess
> conversion transparently ?

No. There are strict rules on how endianess has to be dealt between 
a BE CPU and the PCI bus, and afaik, all PPCs do it properly.

Ben.


-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.