Xorg on Fujitsu "Lime" with MPC5200b?

Xorg on Fujitsu "Lime" with MPC5200b?

[Bill Gatliff]

Guys:


I'm not quite sure where to ask this question, but all my attempts
elsewhere have come up short, so...

Put simply, I have an MPC5200b platform with a Fujitsu "Lime" GDC, and
I'm trying to run Debian squeeze's xorg on it.

Actually, I *have* Debian squeeze's xorg running on the platform just
fine, with a 2.6.34-rc1 kernel (kernel.org).  Problem is, every single
diagonal line is very blocky--- not smooth at all.  I used to think this
was a problem with X's fonts, but now I don't think so because the mouse
cursor's diagonal lines also look equally bad.

It's almost as if any time the platform tries to draw a diagonal line,
truncation/rounding errors are causing it problems in figuring out which
pixels to turn on and off.

A non-Linux kernel on this hardware, running a non-X GUI, seems to work
fine so I think the hardware isn't the problem.

Anyone have any suggestions on where to start with this one?  Anyone
else running a similar configuration with any success?  I'm completely
lost, and running out of hair *fast*...


Thanks!


b.g.

-- 
Bill Gatliff
bgat@billgatliff.com

Re: Xorg on Fujitsu "Lime" with MPC5200b?

[Benjamin Herrenschmidt]

On Wed, 2010-04-14 at 22:07 -0500, Bill Gatliff wrote:
> 
> Anyone have any suggestions on where to start with this one?  Anyone
> else running a similar configuration with any success?  I'm completely
> lost, and running out of hair *fast*...

Most probably endian bugs in the Lime driver ...

Cheers,
Ben.

Re: Xorg on Fujitsu "Lime" with MPC5200b?

[Roman Fietze]

Hallo Bill,

On Thursday 15 April 2010 05:07:08 Bill Gatliff wrote:

> Actually, I *have* Debian squeeze's xorg running on the platform just
> fine, with a 2.6.34-rc1 kernel (kernel.org).  Problem is, every single
> diagonal line is very blocky--- not smooth at all.

I'm 95% sure it's an endianess problem, on our boards we had to modify
the X11 driver. What I did was swapping bytes when updating the device
from the shadowfb inside programs/Xserver/miext/shadow/shpacked.c


Roman

=2D-=20
Roman Fietze                Telemotive AG B=FCro M=FChlhausen
Breitwiesen                              73347 M=FChlhausen
Tel.: +49(0)7335/18493-45        http://www.telemotive.de

Re: Xorg on Fujitsu "Lime" with MPC5200b?

[Anatolij Gustschin]

On Wed, 14 Apr 2010 22:07:08 -0500
Bill Gatliff <bgat@billgatliff.com> wrote:

> Put simply, I have an MPC5200b platform with a Fujitsu "Lime" GDC, and
> I'm trying to run Debian squeeze's xorg on it.
> 
> Actually, I *have* Debian squeeze's xorg running on the platform just
> fine, with a 2.6.34-rc1 kernel (kernel.org).  Problem is, every single
> diagonal line is very blocky--- not smooth at all.  I used to think this
> was a problem with X's fonts, but now I don't think so because the mouse
> cursor's diagonal lines also look equally bad.
> 
> It's almost as if any time the platform tries to draw a diagonal line,
> truncation/rounding errors are causing it problems in figuring out which
> pixels to turn on and off.

On all PowerPC based boards with Lime (PPC440EPx, MPC85xx) I have seen so
far there is a similar problem with direct access to the frame buffer in
16-bit mode.

> A non-Linux kernel on this hardware, running a non-X GUI, seems to work
> fine so I think the hardware isn't the problem.

It is possible that this non-X GUI doesn't access the frame buffer directly
but only uses the accelerated driver for rendering. In this case all
drawing is done by Lime itself triggered by 32-bit accesses to the
drawing command FIFO.

> Anyone have any suggestions on where to start with this one?  Anyone
> else running a similar configuration with any success?  I'm completely
> lost, and running out of hair *fast*...

You probably have to fix Xorg driver for swapping.

Anatolij

Re: Xorg on Fujitsu "Lime" with MPC5200b?

[Bill Gatliff]

Roman Fietze wrote:
> Hallo Bill,
>
> On Thursday 15 April 2010 05:07:08 Bill Gatliff wrote:
>
>   
>> Actually, I *have* Debian squeeze's xorg running on the platform just
>> fine, with a 2.6.34-rc1 kernel (kernel.org).  Problem is, every single
>> diagonal line is very blocky--- not smooth at all.
>>     
>
> I'm 95% sure it's an endianess problem, on our boards we had to modify
> the X11 driver. What I did was swapping bytes when updating the device
> from the shadowfb inside programs/Xserver/miext/shadow/shpacked.c
>   

Are you talking about this code here?

    void
    shadowUpdatePacked (ScreenPtr pScreen,
                        shadowBufPtr pBuf)
    {
    ...
                    while (i--)
                        *win++ = *sha++;



Do I endian-swap each *sha?  Or, do I reorder the sha array before
dereferencing it (e.g. each *sha is right, but adjacent ones are in the
wrong order)?


b.g.

-- 
Bill Gatliff
bgat@billgatliff.com

Re: Xorg on Fujitsu "Lime" with MPC5200b?

[Roman Fietze]

Hello Bill,

On Thursday 15 April 2010 15:01:59 Bill Gatliff wrote:

> Are you talking about this code here?
>=20
>     void
>     shadowUpdatePacked (ScreenPtr pScreen,
>                         shadowBufPtr pBuf)
>     {
>     ...
>                     while (i--)
>                         *win++ =3D *sha++;

Yes. I added a routine like

/* Swap frame buffer bytes in 32 bit value.  */
static __inline unsigned int
fbbits_swap32(unsigned int __bsx)
{
    return ((((__bsx) & 0xff000000) >> 8) | (((__bsx) & 0x00ff0000) << 8) |
	    (((__bsx) & 0x0000ff00) >> 8) | (((__bsx) & 0x000000ff) << 8));
}


Then I added void shadowUpdatePackedSwapped16() and
shadowUpdatePackedSwapped32() which I was using instead of the
original *Weak functions, which in turn uses the above swap routine
when copying from shadow to the device.

If you want I can post (in the ML) or mail you the files that I
changed. A diff probably won't help a lot, because I think we changed
more than that, and we are using a pretty old XFree version.


Roman

=2D-=20
Roman Fietze                Telemotive AG B=FCro M=FChlhausen
Breitwiesen                              73347 M=FChlhausen
Tel.: +49(0)7335/18493-45        http://www.telemotive.de

Re: Xorg on Fujitsu "Lime" with MPC5200b?

[Bill Gatliff]

[-- Attachment #1: Type: text/plain, Size: 1079 bytes --]

I would love it if you posted your code! Thanks!!

b.g.

On Apr 15, 2010 8:53 AM, "Roman Fietze" <roman.fietze@telemotive.de> wrote:

Hello Bill,


On Thursday 15 April 2010 15:01:59 Bill Gatliff wrote:

> Are you talking about this code here?
>
...
Yes. I added a routine like

/* Swap frame buffer bytes in 32 bit value.  */
static __inline unsigned int
fbbits_swap32(unsigned int __bsx)
{
   return ((((__bsx) & 0xff000000) >> 8) | (((__bsx) & 0x00ff0000) << 8) |
           (((__bsx) & 0x0000ff00) >> 8) | (((__bsx) & 0x000000ff) << 8));
}


Then I added void shadowUpdatePackedSwapped16() and
shadowUpdatePackedSwapped32() which I was using instead of the
original *Weak functions, which in turn uses the above swap routine
when copying from shadow to the device.

If you want I can post (in the ML) or mail you the files that I
changed. A diff probably won't help a lot, because I think we changed
more than that, and we are using a pretty old XFree version.



Roman

-- 
Roman Fietze Telemotive AG Büro Mühlhausen
Breitwiesen ...

[-- Attachment #2: Type: text/html, Size: 1460 bytes --]

Re: Xorg on Fujitsu "Lime" with MPC5200b?

[Bill Gatliff]

Roman Fietze wrote:
> Then I added void shadowUpdatePackedSwapped16() and
> shadowUpdatePackedSwapped32() which I was using instead of the
> original *Weak functions, which in turn uses the above swap routine
> when copying from shadow to the device.
>   

I'm not sure what the *Weak stuff is doing.  Can I just hack
shadowUpdatePacked() itself?


b.g.

-- 
Bill Gatliff
bgat@billgatliff.com

Re: Xorg on Fujitsu "Lime" with MPC5200b?

[Bill Gatliff]

Roman Fietze wrote:
> Yes. I added a routine like
>
> /* Swap frame buffer bytes in 32 bit value.  */
> static __inline unsigned int
> fbbits_swap32(unsigned int __bsx)
> {
>     return ((((__bsx) & 0xff000000) >> 8) | (((__bsx) & 0x00ff0000) << 8) |
> 	    (((__bsx) & 0x0000ff00) >> 8) | (((__bsx) & 0x000000ff) << 8));
> }
>   

I baked the above code into shadowUpdatePacked(), and it didn't seem to
help anything--- my icewm mouse cursor was still quite jagged, as was
all the text on the screen (clock widget, etc).  So I replaced the above
code with a return 0, and the icewm desktop went completely black--- and
everything else remained unchanged.

Apparently, there are several similar modifications that need to be
made, i.e. the shadowUpdatePacked() function isn't the only way to the
framebuffer memory?  I'm really looking forward to seeing your code, as
I have no idea how to even identify the places that need hacking.  I
understand the utility of the hack, however.

Makes me think that we're all just soldering this chip down to the wrong
data lines, and makes me wonder if there isn't an "endianness bit" in
the memory bus controller that can undo this damage for us.  I know I've
seen such a bit in other SoCs...


Thanks!


b.g.

-- 
Bill Gatliff
bgat@billgatliff.com

Re: Xorg on Fujitsu "Lime" with MPC5200b?

[Roman Fietze]

[-- Attachment #1: Type: Text/Plain, Size: 677 bytes --]

Hello Bill,

On Thursday 15 April 2010 22:14:09 Bill Gatliff wrote:

> I'm not sure what the *Weak stuff is doing. Can I just hack
> shadowUpdatePacked() itself?

I think so. But take care if you want to use that code on other
systems or without shadowfb. If I search for shadowUpdatePacked, then
I'll find it in quite some other locations.


Roman

-- 
Roman Fietze                Telemotive AG Büro Mühlhausen
Breitwiesen                              73347 Mühlhausen
Tel.: +49(0)7335/18493-45        http://www.telemotive.de

Amtsgericht Ulm                                HRB 541321
Vorstand:
Peter Kersten, Markus Fischer, Franz Diller, Markus Stolz

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Xorg on Fujitsu "Lime" with MPC5200b?

[Roman Fietze]

Hello Bill,

On Thursday 15 April 2010 18:07:03 Bill Gatliff wrote:

> I would love it if you posted your code! Thanks!!

In this source file I just added my own routines:

Index: programs/Xserver/hw/xfree86/drivers/fbdev/fbdev.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=2D-- programs/Xserver/hw/xfree86/drivers/fbdev/fbdev.c   (revision 6)
+++ programs/Xserver/hw/xfree86/drivers/fbdev/fbdev.c   (revision 7)
@@ -139,8 +139,8 @@
        "shadowInit",
        "shadowSetup",
        "shadowUpdatePacked",
=2D       "shadowUpdatePackedSwapped16Weak",
=2D       "shadowUpdatePackedSwapped32Weak",
+       "shadowUpdatePackedSwapped16",
+       "shadowUpdatePackedSwapped32",
        "shadowUpdateRotatePacked",
        NULL
 };
@@ -619,6 +619,7 @@
        ScrnInfoPtr pScrn =3D xf86Screens[pScreen->myNum];
        FBDevPtr fPtr =3D FBDEVPTR(pScrn);
        VisualPtr visual;
+       ShadowUpdateProc pupdate;
        int init_picture =3D 0;
        int ret,flags,width,height;
=20
@@ -794,7 +795,7 @@
                xf86DrvMsg(pScrn->scrnIndex, X_WARNING,
                           "RENDER extension initialisation failed.\n");
=20
=2D       pupdate =3D pScrn->bitsPerPixel > 16 ? shadowUpdatePackedSwapped3=
2Weak() :
 shadowUpdatePackedSwapped16Weak();
+       pupdate =3D pScrn->bitsPerPixel > 16 ? shadowUpdatePackedSwapped32 =
: shado
wUpdatePackedSwapped16;
=20
        if (fPtr->shadowFB &&=20
            (!shadowSetup(pScreen) || !shadowAdd(pScreen, NULL,


=2D-------------------------------

And here's my complete programs/Xserver/miext/shadow/shpacked.c


/*
 * $XFree86: xc/programs/Xserver/miext/shadow/shpacked.c,v 1.5 2001/10/28 0=
3:34:16 tsi Exp $
 *
 * Copyright =A9 2000 Keith Packard
 *
 * Permission to use, copy, modify, distribute, and sell this software and =
its
 * documentation for any purpose is hereby granted without fee, provided th=
at
 * the above copyright notice appear in all copies and that both that
 * copyright notice and this permission notice appear in supporting
 * documentation, and that the name of Keith Packard not be used in
 * advertising or publicity pertaining to distribution of the software with=
out
 * specific, written prior permission.  Keith Packard makes no
 * representations about the suitability of this software for any purpose. =
 It
 * is provided "as is" without express or implied warranty.
 *
 * KEITH PACKARD DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
 * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
 * EVENT SHALL KEITH PACKARD BE LIABLE FOR ANY SPECIAL, INDIRECT OR
 * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF U=
SE,
 * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
 * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 * PERFORMANCE OF THIS SOFTWARE.
 */

#include    <byteswap.h>
#include    <unistd.h>

#include    "X.h"
#include    "scrnintstr.h"
#include    "windowstr.h"
#include    "font.h"
#include    "dixfontstr.h"
#include    "fontstruct.h"
#include    "mi.h"
#include    "regionstr.h"
#include    "globals.h"
#include    "gcstruct.h"
#include    "shadow.h"
#include    "fb.h"

void
shadowUpdatePacked (ScreenPtr	    pScreen,
		    shadowBufPtr    pBuf)
{
    RegionPtr	damage =3D &pBuf->damage;
    PixmapPtr	pShadow =3D pBuf->pPixmap;
    int		nbox =3D REGION_NUM_RECTS (damage);
    BoxPtr	pbox =3D REGION_RECTS (damage);
    FbBits	*shaBase, *shaLine, *sha;
    FbStride	shaStride;
    int		scrBase, scrLine, scr;
    int		shaBpp;
    int		shaXoff, shaYoff; /* XXX assumed to be zero */
    int		x, y, w, h, width;
    int         i;
    FbBits	*winBase =3D NULL, *win;
    CARD32      winSize;

    fbGetDrawable (&pShadow->drawable, shaBase, shaStride, shaBpp, shaXoff,=
 shaYoff);
    while (nbox--)
    {
	x =3D pbox->x1 * shaBpp;
	y =3D pbox->y1;
	w =3D (pbox->x2 - pbox->x1) * shaBpp;
	h =3D pbox->y2 - pbox->y1;

	scrLine =3D (x >> FB_SHIFT);
	shaLine =3D shaBase + y * shaStride + (x >> FB_SHIFT);
				  =20
	x &=3D FB_MASK;
	w =3D (w + x + FB_MASK) >> FB_SHIFT;
=09
	while (h--)
	{
	    winSize =3D 0;
	    scrBase =3D 0;
	    width =3D w;
	    scr =3D scrLine;
	    sha =3D shaLine;
	    while (width) {
		/* how much remains in this window */
		i =3D scrBase + winSize - scr;
		if (i <=3D 0 || scr < scrBase)
		{
		    winBase =3D (FbBits *) (*pBuf->window) (pScreen,
							  y,
							  scr * sizeof (FbBits),
							  SHADOW_WINDOW_WRITE,
							  &winSize,
							  pBuf->closure);
		    if(!winBase)
			return;
		    scrBase =3D scr;
		    winSize /=3D sizeof (FbBits);
		    i =3D winSize;
		}
		win =3D winBase + (scr - scrBase);
		if (i > width)
		    i =3D width;
		width -=3D i;
		scr +=3D i;

		while (i--)
		    *win++ =3D *sha++;
	    }
	    shaLine +=3D shaStride;
	    y++;
	}
	pbox++;
    }
}


/* Swap frame buffer bytes in 32 bit value.  */
static __inline unsigned int
fbbits_swap32(unsigned int __bsx)
{
    return ((((__bsx) & 0xff000000) >> 8) | (((__bsx) & 0x00ff0000) << 8) |
	    (((__bsx) & 0x0000ff00) >> 8) | (((__bsx) & 0x000000ff) << 8));
}

void
shadowUpdatePackedSwapped16 (ScreenPtr	    pScreen,
			     shadowBufPtr    pBuf)
{
    RegionPtr	damage =3D &pBuf->damage;
    PixmapPtr	pShadow =3D pBuf->pPixmap;
    int		nbox =3D REGION_NUM_RECTS (damage);
    BoxPtr	pbox =3D REGION_RECTS (damage);
    FbBits	*shaBase, *shaLine, *sha;
    FbStride	shaStride;
    int		scrBase, scrLine, scr;
    int		shaBpp;
    int		shaXoff, shaYoff; /* XXX assumed to be zero */
    int		x, y, w, h, width;
    int         i;
    FbBits	*winBase =3D NULL, *win;
    CARD32      winSize;

    /* fprintf(stderr, "#### %s() nbox=3D%d sizof(*win)=3D%u\n", __FUNCTION=
__, nbox, sizeof(*win)); */

    fbGetDrawable (&pShadow->drawable, shaBase, shaStride, shaBpp, shaXoff,=
 shaYoff);
    while (nbox--)
    {
	x =3D pbox->x1 * shaBpp;
	y =3D pbox->y1;
	w =3D (pbox->x2 - pbox->x1) * shaBpp;
	h =3D pbox->y2 - pbox->y1;

	/* fprintf(stderr, "####\t%s: x=3D%d y=3D%d w=3D%d h=3D%d\n", __FUNCTION__=
, x, y, w, h); */

	scrLine =3D (x >> FB_SHIFT);
	shaLine =3D shaBase + y * shaStride + (x >> FB_SHIFT);
				  =20
	x &=3D FB_MASK;
	w =3D (w + x + FB_MASK) >> FB_SHIFT;
=09
	while (h--)
	{
	    winSize =3D 0;
	    scrBase =3D 0;
	    width =3D w;
	    scr =3D scrLine;
	    sha =3D shaLine;
	    while (width) {
		/* how much remains in this window */
		i =3D scrBase + winSize - scr;
		if (i <=3D 0 || scr < scrBase)
		{
		    winBase =3D (FbBits *) (*pBuf->window) (pScreen,
							  y,
							  scr * sizeof (FbBits),
							  SHADOW_WINDOW_WRITE,
							  &winSize,
							  pBuf->closure);
		    if(!winBase)
			return;
		    scrBase =3D scr;
		    winSize /=3D sizeof (FbBits);
		    i =3D winSize;
		}
		win =3D winBase + (scr - scrBase);
		if (i > width)
		    i =3D width;
		width -=3D i;
		scr +=3D i;

#if 1
		/* TODO: check which one of these solutions is
		 * faster. Allthough swab probably uses optimized PPC
		 * operations, the fbbits_swap32 solution uses 32 bit
		 * PCI accesses, so the result isn't that clear.
		 */
		while (i--)
		    *win++ =3D fbbits_swap32(*sha++);
#else
		swab(sha, win, i * sizeof(*win));
#endif
	    }
	    shaLine +=3D shaStride;
	    y++;
	}
	pbox++;
    }
}


void
shadowUpdatePackedSwapped32 (ScreenPtr	    pScreen,
			     shadowBufPtr    pBuf)
{
    RegionPtr	damage =3D &pBuf->damage;
    PixmapPtr	pShadow =3D pBuf->pPixmap;
    int		nbox =3D REGION_NUM_RECTS (damage);
    BoxPtr	pbox =3D REGION_RECTS (damage);
    FbBits	*shaBase, *shaLine, *sha;
    FbStride	shaStride;
    int		scrBase, scrLine, scr;
    int		shaBpp;
    int		shaXoff, shaYoff; /* XXX assumed to be zero */
    int		x, y, w, h, width;
    int         i;
    FbBits	*winBase =3D NULL, *win;
    CARD32      winSize;

    /* fprintf(stderr, "#### %s() nbox=3D%d sizof(*win)=3D%u\n", __FUNCTION=
__, nbox, sizeof(*win)); */

    fbGetDrawable (&pShadow->drawable, shaBase, shaStride, shaBpp, shaXoff,=
 shaYoff);
    while (nbox--)
    {
	x =3D pbox->x1 * shaBpp;
	y =3D pbox->y1;
	w =3D (pbox->x2 - pbox->x1) * shaBpp;
	h =3D pbox->y2 - pbox->y1;

	/* fprintf(stderr, "####\t%s: x=3D%d y=3D%d w=3D%d h=3D%d\n", __FUNCTION__=
, x, y, w, h); */

	scrLine =3D (x >> FB_SHIFT);
	shaLine =3D shaBase + y * shaStride + (x >> FB_SHIFT);
				  =20
	x &=3D FB_MASK;
	w =3D (w + x + FB_MASK) >> FB_SHIFT;
=09
	while (h--)
	{
	    winSize =3D 0;
	    scrBase =3D 0;
	    width =3D w;
	    scr =3D scrLine;
	    sha =3D shaLine;
	    while (width) {
		/* how much remains in this window */
		i =3D scrBase + winSize - scr;
		if (i <=3D 0 || scr < scrBase)
		{
		    winBase =3D (FbBits *) (*pBuf->window) (pScreen,
							  y,
							  scr * sizeof (FbBits),
							  SHADOW_WINDOW_WRITE,
							  &winSize,
							  pBuf->closure);
		    if(!winBase)
			return;
		    scrBase =3D scr;
		    winSize /=3D sizeof (FbBits);
		    i =3D winSize;
		}
		win =3D winBase + (scr - scrBase);
		if (i > width)
		    i =3D width;
		width -=3D i;
		scr +=3D i;

		while (i--)
		    *win++ =3D bswap_32(*sha++);
	    }
	    shaLine +=3D shaStride;
	    y++;
	}
	pbox++;
    }
}


Roman

=2D-=20
Roman Fietze                Telemotive AG B=FCro M=FChlhausen
Breitwiesen                              73347 M=FChlhausen
Tel.: +49(0)7335/18493-45        http://www.telemotive.de

Re: Xorg on Fujitsu "Lime" with MPC5200b?

[Roman Fietze]

Hello Bill,

On Friday 16 April 2010 04:51:38 Bill Gatliff wrote:

> Apparently, there are several similar modifications that need to be
> made, ...

I'm SW-Engineer, so I assume HW, that's always a good bet. ;)

Please take care, that I forgot to tell you that my X server runs well
on a Futjitsu 86295 chip, also connected to a MPC5200(B). I silently
assumed that those two are identical in terms of byte ordering and
(non) existant automatic byte swapping.

At least, when you get a black screen when copying out nothing, you
might be able to copy over some fixed pattern to find out what bits
cause what, e.g. start writing 0x03 and shift that pattern left every
16 scanlines.

In what mode is your X server running? 16/24/32 bit? DirectColor, etc?


Roman

=2D-=20
Roman Fietze                Telemotive AG B=FCro M=FChlhausen
Breitwiesen                              73347 M=FChlhausen
Tel.: +49(0)7335/18493-45        http://www.telemotive.de

Re: Xorg on Fujitsu "Lime" with MPC5200b?

[Michel Dänzer]

On Fre, 2010-04-16 at 08:14 +0200, Roman Fietze wrote:=20
>=20
> On Thursday 15 April 2010 18:07:03 Bill Gatliff wrote:
>=20
> > I would love it if you posted your code! Thanks!!
>=20
> In this source file I just added my own routines:
>=20
> Index: programs/Xserver/hw/xfree86/drivers/fbdev/fbdev.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- programs/Xserver/hw/xfree86/drivers/fbdev/fbdev.c   (revision 6)
> +++ programs/Xserver/hw/xfree86/drivers/fbdev/fbdev.c   (revision 7)
> @@ -139,8 +139,8 @@
>         "shadowInit",
>         "shadowSetup",
>         "shadowUpdatePacked",
> -       "shadowUpdatePackedSwapped16Weak",
> -       "shadowUpdatePackedSwapped32Weak",
> +       "shadowUpdatePackedSwapped16",
> +       "shadowUpdatePackedSwapped32",
>         "shadowUpdateRotatePacked",
>         NULL
>  };
> @@ -619,6 +619,7 @@
>         ScrnInfoPtr pScrn =3D xf86Screens[pScreen->myNum];
>         FBDevPtr fPtr =3D FBDEVPTR(pScrn);
>         VisualPtr visual;
> +       ShadowUpdateProc pupdate;
>         int init_picture =3D 0;
>         int ret,flags,width,height;
> =20
> @@ -794,7 +795,7 @@
>                 xf86DrvMsg(pScrn->scrnIndex, X_WARNING,
>                            "RENDER extension initialisation failed.\n");
> =20
> -       pupdate =3D pScrn->bitsPerPixel > 16 ? shadowUpdatePackedSwapped3=
2Weak() :
>  shadowUpdatePackedSwapped16Weak();
> +       pupdate =3D pScrn->bitsPerPixel > 16 ? shadowUpdatePackedSwapped3=
2 : shado
> wUpdatePackedSwapped16;
> =20
>         if (fPtr->shadowFB &&=20
>             (!shadowSetup(pScreen) || !shadowAdd(pScreen, NULL,

I hope you're aware that this really just hacks around the kernel
framebuffer device not exposing the framebuffer to userspace according
to the fbdev interface (see struct fb_bitfield
in /usr/include/linux/fb.h), and this will affect everything else using
the framebuffer device as well.

It would be better to handle this in the kernel framebuffer device,
either via hardware byte swapping facilities if available, or otherwise
e.g. via FB_DEFERRED_IO.


--=20
Earthling Michel D=C3=A4nzer           |                http://www.vmware.c=
om
Libre software enthusiast         |          Debian, X and DRI developer

Re: Xorg on Fujitsu "Lime" with MPC5200b?

[Gabriel Paubert]

On Thu, Apr 15, 2010 at 03:53:53PM +0200, Roman Fietze wrote:
> Hello Bill,
> 
> On Thursday 15 April 2010 15:01:59 Bill Gatliff wrote:
> 
> > Are you talking about this code here?
> > 
> >     void
> >     shadowUpdatePacked (ScreenPtr pScreen,
> >                         shadowBufPtr pBuf)
> >     {
> >     ...
> >                     while (i--)
> >                         *win++ = *sha++;
> 
> Yes. I added a routine like
> 
> /* Swap frame buffer bytes in 32 bit value.  */
> static __inline unsigned int
> fbbits_swap32(unsigned int __bsx)
> {
>     return ((((__bsx) & 0xff000000) >> 8) | (((__bsx) & 0x00ff0000) << 8) |
> 	    (((__bsx) & 0x0000ff00) >> 8) | (((__bsx) & 0x000000ff) << 8));
> }

I don't see the difference with:

	return (((__bsx & 0xff00ff00)>> 8) | ((__bsx & 0x00ff00ff) << 8));

for which the compiler (GCC 4.3.2) generates better code (GCC 4.3.2) as shown.

In the first case:

.L3:
        lwzx 9,3,8
        rlwinm 0,9,8,0,7
        rlwinm 11,9,24,8,15
        rlwinm 10,9,24,24,31
        or 0,0,11
        or 0,0,10
        rlwinm 9,9,8,16,23
        or 0,0,9
        stwx 0,4,8
        addi 8,8,4
        bdnz .L3

in the second:

.L9:
        lwzx 0,3,11
        and 9,0,10
        and 0,0,8
        slwi 0,0,8
        srwi 9,9,8
        or 0,0,9
        stwx 0,4,11
        addi 11,11,4
        bdnz .L9

saving 2 instructions. AFAIR the MPC5200 is based on a 603e core, 
so the integer instructions have to go to the single integer unit that
can handle them (the second IU can only handle add and cmp), so the
mimimum is 5 clocks/iteration versus 7. Even with two IU (or 3), the 
second code has better latency.

	Gabriel