Re: radeonfb on pegasos powerpc motherboard and X endianess problem

[Sven Luther <sven.luther@wanadoo.fr>]

On Thu, Jun 05, 2003 at 09:59:47AM +0200, Benjamin Herrenschmidt wrote:
> On Wed, 2003-06-04 at 16:54, Sven Luther wrote:
> > Hello,
> > 
> > I finally have a working pegasos motherboard as well as a working kernel
> > with a 1.6 radeonfb. I have also installed Daniel Stone's X 4.3.0
> > debian/sid packages, and notice the following :
> > 
> >   1) radeonfb works fine in 8bpp and 32bpp but depth 15 and 16 only give
> >   me some very dark grey.
> 
> Can you try my devel tree version ?
> 
> (rsync.penguinppc.org::benh-devel)

Err, is that the same devel tree as the one in linuxppc_2_4_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.

  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 ?

  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 ?

  4) drivers/ide/ide-pci.c also is no more to be found in the current
  tree.

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

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.

> > So, i think something is wrong. The kernel was forked around the
> > 2.4.18-rc4 time in a messy way, i am actually working on bringing the
> > patch in sync with the newer ppc trees. Matroxfb also had problems and
> > Petr told me that it probably was an endianess issue back then. I am
> > using a Radeon 9000 board.
> 
> Ok, there is a problem with older radeonfb's on these regarding
> endianness, newer driver should work.

Ok, i will test again once i have finished the porting of the pegasos
patches.

> > So, since this is a pegasos, based on the pop specification, which in
> > turn are related to the chrp ones, and i was told that most chrp
> > motherboard did endianess inversion in the northbridge or something
> > such, and i believe that the pegasos doesn't do so, is it possible that
> > this is the cause, and that XFree86 know how to program the graphic card
> > to do endianess conversion, and fbdev knows not, or maybe that the
> > XFree86 radeon driver doesn't know how to act exactly and accidentally
> > reverts the endianess conversion or something such.
> > 
> > Using the fbdev driver in xfree86, i get a seemingly working X, but the
> > background X image is yellowish and the mode is not set correctly it is
> > correct, but the image is a bit smaller than the screen, and centered or
> > moved to the right.
> > 
> > Does someone know with more exactitude what the situation is exactly
> > with regard the kernel and endianess conversion with the different
> > powerpc subarches.
> 
> Endianness shouldn't be related to the subarch at all

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

Friendly,

Sven Luther


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