Re: radeonfb on pegasos powerpc motherboard and X endianess problem

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.

quoted

quoted

  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).

quoted

quoted

  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.