Re: radeonfb on pegasos powerpc motherboard and X endianess problem

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

On Thu, Jun 05, 2003 at 01:42:30PM +0200, Benjamin Herrenschmidt wrote:
> 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.

Mmm, i think i am just a bit lost with all the ppc kernel trees ...
Which one should i work on.


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

Ok.

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

Mmm, anyway, once it work well, it is not needed that much anymore. I
will look into this once i have booted a more recent tree, and start
cleaning up patches.

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

Ok, will do that.

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

I don't know about the radeon driver exactly but the glint driver i did
work on did a mode setup when comming from the VT switch, after having
saved the registers it touches for the consoles benefit. It then
proceeded to reinitialize the accel pipeline, complete with a sync and
all. I guess newer hardware have easier way to do this, and this doesn't
speak about the DRI case, but probably all the X driver do it such. When
switching back, they restore the registers they have touched, more
probably only the mode setting registers, and don't care about the accel
regs, since text mode don't touch them.

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

Yep.

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

Not really, because when the card is in vga text mode, it couldn't care
less about accel engine, right ?

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

Well, There are fbdev specific Enter/Leave VT functions, which could be
different, but i also understand what you mean. Not all developpers
think like that though, and David even told me he was not against fbdev.

And then, there will be chance to change things for 5.0, if we have
specific needs.

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

Ok, so it must be another kind of problems, but then, my matrox board,
which Geert (or someone else) said did run on his chrp board, did not
work well for me.

Thanks,

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.