RE: patch to get latest XFree 4.0 snapshot (xf3918) to work on pp cwith r128

RE: patch to get latest XFree 4.0 snapshot (xf3918) to work on pp cwith r128

[Kevin Hendricks]

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

Hi Kostas,

Here is the patch to fix the cursor for 16bpp and 8bpp for XFree 4.0 r128. (It
is attached). It is almost exactly what you sent to me earlier.

By the way, true 16 bit depth (565) does not work on my machine. The screen
comes up but everything is very very green!

Reverting to 16bpp and 15 depth (555) works fine.

I hope this one makes it into the XFree 4.0 final.

Thanks,

Kevin



--
Kevin B. Hendricks
Associate Professor of Operations and Information Technology
Richard Ivey School of Business, University of Western Ontario
London, Ontario  N6A-3K7  CANADA
khendricks@ivey.uwo.ca, (519) 661-3874, fax: 519-661-3959


[-- Attachment #2: be_cursor.patch.gz --]
[-- Type: application/x-gzip, Size: 586 bytes --]

Re: patch to get latest XFree 4.0 snapshot (xf3918) to work on pp cwith r128

[Michel Dänzer]

Kevin Hendricks wrote:

> Here is the patch to fix the cursor for 16bpp and 8bpp for XFree 4.0 r128.
> (It is attached). It is almost exactly what you sent to me earlier.

This looks a bit complicated to me.

Doesn't it help adding BIT_ORDER_IN_BYTE_MSB_FIRST to the HW cursor flags or
something? It works in the glint driver (look at pm2_accel.c or pm2_dac.c)


> By the way, true 16 bit depth (565) does not work on my machine. The screen
> comes up but everything is very very green!
>
> Reverting to 16bpp and 15 depth (555) works fine.

Does it report the correct RGB weight?


Michel

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: patch to get latest XFree 4.0 snapshot (xf3918) to work on pp cwith r128

[Kostas Gewrgiou]

On Sun, 5 Mar 2000, Michel Dδnzer wrote:

>
>
> Kevin Hendricks wrote:
>
> > Here is the patch to fix the cursor for 16bpp and 8bpp for XFree 4.0 r128.
> > (It is attached). It is almost exactly what you sent to me earlier.
>
> This looks a bit complicated to me.
>
> Doesn't it help adding BIT_ORDER_IN_BYTE_MSB_FIRST to the HW cursor flags or
> something? It works in the glint driver (look at pm2_accel.c or pm2_dac.c)
>

 The hwcursor in aty128 lives in the framebuffer so since writes in the
framebuffer get byteswapped differently depending on the depth we need to
write the cursor with differnt byteswapping depending on the depth.
The other solution is to disable the be mode in the framebuffer before
writing the cursor and then reenable it.

It might be also possible to let the hwcursor layer know about this and do
the right thing (that will be the best way to handle it).

>
> > By the way, true 16 bit depth (565) does not work on my machine. The screen
> > comes up but everything is very very green!
> >
> > Reverting to 16bpp and 15 depth (555) works fine.
>
> Does it report the correct RGB weight?

  The problem here is that aty128fb doesn't support 16 bit depth,
asking for 16 bit will give you 15 bit but fbdevhw fails to detect
this.

>
>
> Michel


  Kostas Gewrgiou


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: patch to get latest XFree 4.0 snapshot (xf3918) to work on pp cwith r128

[Kevin B. Hendricks]

Hi Kostas,

> The hwcursor in aty128 lives in the framebuffer so since writes in the
>framebuffer get byteswapped differently depending on the depth we need to
>write the cursor with differnt byteswapping depending on the depth.
>The other solution is to disable the be mode in the framebuffer before
>writing the cursor and then reenable it.
>
>It might be also possible to let the hwcursor layer know about this and do
>the right thing (that will be the best way to handle it).

Given that changes in cursor images are in no way performance sensitive, I
think the current patch is just fine, don't you especially if we want
something in before xf 4.0 final.

>> > By the way, true 16 bit depth (565) does not work on my machine. The
>>screen
>> > comes up but everything is very very green!
>> >
>> > Reverting to 16bpp and 15 depth (555) works fine.

>  The problem here is that aty128fb doesn't support 16 bit depth,
>asking for 16 bit will give you 15 bit but fbdevhw fails to detect
>this.

Is this true even under x86?  What about in the very latest aty128fb from
the latest 2.3.XX kernel?

I would think true 16 bit (565) would be desirable given it seems to be the
default in the x86 world.

I will look at the aty128fb.c code to see if there is anything easily found.

By the way,  I can not get the Xserver to work if I specifify more than 1
mode in the XF86Config file.  In fact whatever mode I put there is actually
ignored and the mode used by the frame buffer is inherited instead.

So to change resolutions, I have to use fbset (with /etc/fb.modes filled in
properly) and then start of the XFree86 Xserver.

Is this the resolution switching problem you mentioned to me previously?

Should we be using fbset to change resolutions of should the mode line in
/etc/X11/XF86Config actually be used?

Thanks,

Kevin


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: patch to get latest XFree 4.0 snapshot (xf3918) to work on pp cwith r128

[Kostas Gewrgiou]

On Sun, 5 Mar 2000, Kevin B. Hendricks wrote:

> Hi Kostas,
>
> > The hwcursor in aty128 lives in the framebuffer so since writes in the
> >framebuffer get byteswapped differently depending on the depth we need to
> >write the cursor with differnt byteswapping depending on the depth.
> >The other solution is to disable the be mode in the framebuffer before
> >writing the cursor and then reenable it.
> >
> >It might be also possible to let the hwcursor layer know about this and do
> >the right thing (that will be the best way to handle it).
>
> Given that changes in cursor images are in no way performance sensitive, I
> think the current patch is just fine, don't you especially if we want
> something in before xf 4.0 final.
>

 The patch will do for now, after 4.0 is out i'll look for a more general
solution since other drivers will need the same patch and obviously the
generic cursor layer is the place to handle this.

> >> > By the way, true 16 bit depth (565) does not work on my machine. The
> >>screen
> >> > comes up but everything is very very green!
> >> >
> >> > Reverting to 16bpp and 15 depth (555) works fine.
>
> >  The problem here is that aty128fb doesn't support 16 bit depth,
> >asking for 16 bit will give you 15 bit but fbdevhw fails to detect
> >this.
>
> Is this true even under x86?  What about in the very latest aty128fb from
> the latest 2.3.XX kernel?
>

  Yeap its the same in the x86 side as well, atyfb doesn't support 565
either i imagine you remember the jdk problems that we had in xf68_fbdev
because of this.

> I would think true 16 bit (565) would be desirable given it seems to be the
> default in the x86 world.
>
> I will look at the aty128fb.c code to see if there is anything easily found.
>
> By the way,  I can not get the Xserver to work if I specifify more than 1
> mode in the XF86Config file.  In fact whatever mode I put there is actually
> ignored and the mode used by the frame buffer is inherited instead.
>
> So to change resolutions, I have to use fbset (with /etc/fb.modes filled in
> properly) and then start of the XFree86 Xserver.
>
> Is this the resolution switching problem you mentioned to me previously?
>
> Should we be using fbset to change resolutions of should the mode line in
> /etc/X11/XF86Config actually be used?
>

I can have more than one modeline under x86 (i don't have an aty128 in my
mac) (there is a problem while switching with ctrl-alt-+/- once the xserver
is up though, it seems that the stride isn't updated correctly but i didn't
had the time to look at this yet)

Can you build the fbdevhw module with debug messages enabled and check if
you can see why its failing with the extra modelines under ppc ?

> Thanks,
>
> Kevin

  Kostas


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: patch to get latest XFree 4.0 snapshot (xf3918) to work on pp cwith r128

[Geert Uytterhoeven]

On Sun, 5 Mar 2000, Kostas Gewrgiou wrote:
> On Sun, 5 Mar 2000, Kevin B. Hendricks wrote:
> > >> > By the way, true 16 bit depth (565) does not work on my machine. The
> > >>screen
> > >> > comes up but everything is very very green!
> > >> >
> > >> > Reverting to 16bpp and 15 depth (555) works fine.
> >
> > >  The problem here is that aty128fb doesn't support 16 bit depth,
> > >asking for 16 bit will give you 15 bit but fbdevhw fails to detect
> > >this.
> >
> > Is this true even under x86?  What about in the very latest aty128fb from
> > the latest 2.3.XX kernel?
>
>   Yeap its the same in the x86 side as well, atyfb doesn't support 565
> either i imagine you remember the jdk problems that we had in xf68_fbdev
> because of this.

But since Mach64 CT/VT/GT do support RGB 565, adding support for it isn't that
difficult. Patches?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- Linux/{m68k~Amiga,PPC~CHRP} -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: patch to get latest XFree 4.0 snapshot (xf3918) to work on pp cwith r128

[Kostas Gewrgiou]

On Sun, 5 Mar 2000, Geert Uytterhoeven wrote:

> On Sun, 5 Mar 2000, Kostas Gewrgiou wrote:
> >   Yeap its the same in the x86 side as well, atyfb doesn't support 565
> > either i imagine you remember the jdk problems that we had in xf68_fbdev
> > because of this.
>
> But since Mach64 CT/VT/GT do support RGB 565, adding support for it isn't that
> difficult. Patches?
>

 Unfortunately i don't have a mach64 card anymore, i'll take a look in the
xserver side though, right now it looks only in var.bits_per_pixel but this
is set to 16 even in the 555 case so we need to check green.length as well
right ?

> Gr{oetje,eeting}s,
>
> 						Geert
>

  Kostas


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: patch to get latest XFree 4.0 snapshot (xf3918) to work on pp cwith r128

[Geert Uytterhoeven]

On Mon, 6 Mar 2000, Kostas Gewrgiou wrote:
> On Sun, 5 Mar 2000, Geert Uytterhoeven wrote:
> > On Sun, 5 Mar 2000, Kostas Gewrgiou wrote:
> > >   Yeap its the same in the x86 side as well, atyfb doesn't support 565
> > > either i imagine you remember the jdk problems that we had in xf68_fbdev
> > > because of this.
> >
> > But since Mach64 CT/VT/GT do support RGB 565, adding support for it isn't that
> > difficult. Patches?
>
>  Unfortunately i don't have a mach64 card anymore, i'll take a look in the
> xserver side though, right now it looks only in var.bits_per_pixel but this

The X server should be OK, it's atyfb that needs to be patched.

> is set to 16 even in the 555 case so we need to check green.length as well
> right ?

Yes. RGB555 and RGB565 all use 16 bit pixels.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- Linux/{m68k~Amiga,PPC~CHRP} -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: patch to get latest XFree 4.0 snapshot (xf3918) to work on pp cwith r128

[Kevin Hendricks]

Hi Kostas,

I took one more look at the cache flush code for what the loader loads and
would like to make one small change.  The reason is as follows:  if the object
is loaded at an address whose last 5 bits are not 0 (say they are 30 decimal for
the sake of argument and the size is 8 bytes really two cache lines should be
flushed and not just one.  The way it was previously (after your change to
ppc_flush_icache) only 1 cache line was being flushed in this case.

    if(read(fd,ptr,size)!=size)
	FatalError("\n_LoaderFileToMem() read() failed: %s\n",strerror(errno));

#if defined(linux) && defined(__powerpc__)
 {
 int i;
 for (i = 0; i < size; i += 32)
    ppc_flush_icache(ptr+i);

 /* add this line to make sure any partial ending cache line gets flushed too */
 ppc_flush_icache(ptr+size-1)
 }
#endif

#ifdef DEBUGMEM
    ErrorF("=%lx\n",ptr);
#endif


Thanks,

Kevin


--
Kevin B. Hendricks
Associate Professor of Operations and Information Technology
Richard Ivey School of Business, University of Western Ontario
London, Ontario  N6A-3K7  CANADA
khendricks@ivey.uwo.ca, (519) 661-3874, fax: 519-661-3959

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: patch to get latest XFree 4.0 snapshot (xf3918) to work on pp cwithr128

[Kevin B. Hendricks]

Hi,

So Xfree 4.0 final is out but without the very last minute cache flushing
changes Kostas made.

So we should probably get some official patch out there that includes a few
elements:

1. Either:
       - user defined cache line size during compile
   or:
       - flush a cache range in address increments of 8

to handle the variable line cache size

2. And something to figure out if we are on a 601 machine in the
NuBus X100 machines to properly do a "sync or eieio" so that XFree86 4.0
cache flushing and synchronization for io has some chance of working under
MkLinux R1.

David can you tell me how the 601 problems with sync and eieio are
detected and handled in user space apps under MkLinux?

Thanks,

Kevin


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: patch to get latest XFree 4.0 snapshot (xf3918) to work on pp cwithr128

[Kostas Gewrgiou]

On Fri, 10 Mar 2000, Kevin B. Hendricks wrote:

> Hi,
>
> So Xfree 4.0 final is out but without the very last minute cache flushing
> changes Kostas made.
>
> So we should probably get some official patch out there that includes a few
> elements:
>

  What do you mean by official ? The next xfree86 update will have
this fix what more official do you suggest ?

> 1. Either:
>        - user defined cache line size during compile
>    or:
>        - flush a cache range in address increments of 8
>
> to handle the variable line cache size
>

  Glibc assumes a line size of 16 so that will be ok, in any
case the cache flush will be used only in the startup of the
xserver not need to worry about a few extra instructions there
so we can live even with 4byte increments, definitely better than
a compile time option.

> 2. And something to figure out if we are on a 601 machine in the
> NuBus X100 machines to properly do a "sync or eieio" so that XFree86 4.0
> cache flushing and synchronization for io has some chance of working under
> MkLinux R1.
>
> David can you tell me how the 601 problems with sync and eieio are
> detected and handled in user space apps under MkLinux?
>
   Hmm i don't think that xfree86 4.0 will work under mklinux, there
aren't any drivers that will work under mk anymore (xpmac is gone and
the vgahw/fbdev based ones won't work).

> Thanks,
>
> Kevin
>

  Kostas


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: patch to get latest XFree 4.0 snapshot (xf3918) to work on pp cwithr128

[Kevin B. Hendricks]

Hi Kostas,

>> So we should probably get some official patch out there that includes a few
>> elements:
>>
>
>  What do you mean by official ? The next xfree86 update will have
>this fix what more official do you suggest ?
>
>> 1. Either:
>>        - user defined cache line size during compile
>>    or:
>>        - flush a cache range in address increments of 8
>>
>> to handle the variable line cache size

I am confused.  Now that XF 4.0 is out, will quick snapshots continue to be
released?

I just assumed that we would start getting incremental releases 4.0.1,
4.0.2 that would be long in coming (months or more...just like the 3.3.X
series).  If snapshots will continue coming fast, then you are right.  If
snapshots will not be coming (or minor updates will take a few months to
get working), then perhaps an official patch put on the www.linuxppc.org
site or something for Robert Shaw's page so that others who build XF 4.0
from source will have something to fix the cache problems with.

How about just a patch that fixes cache flushing for XFree 4.0 which
assumes cacke line sizes of 16 and ignores 601 problems then that we just
send to the linuxppc-dev mailing list so that it gets archived.

>  Glibc assumes a line size of 16 so that will be ok, in any
>case the cache flush will be used only in the startup of the
>xserver not need to worry about a few extra instructions there
>so we can live even with 4byte increments, definitely better than
>a compile time option.

>   Hmm i don't think that xfree86 4.0 will work under mklinux, there
>aren't any drivers that will work under mk anymore (xpmac is gone and
>the vgahw/fbdev based ones won't work).

Is this true?  So we don't have to worry about 601 processors at all?

Thanks,

Kevin


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: patch to get latest XFree 4.0 snapshot (xf3918) to work on pp cwithr128

[Michael Schmitz]

> Hi Kostas,
>
> >> So we should probably get some official patch out there that includes a few
> >> elements:
> >>
> >
> >  What do you mean by official ? The next xfree86 update will have
> >this fix what more official do you suggest ?
> >
> >> 1. Either:
> >>        - user defined cache line size during compile
> >>    or:
> >>        - flush a cache range in address increments of 8
> >>
> >> to handle the variable line cache size
>
> I am confused.  Now that XF 4.0 is out, will quick snapshots continue to be
> released?

One would sure hope so. The 4.0 X server dies horribly during device
configuration on my Lombard. After feeding it a hand-crafted XF86Config,
it just hangs the machine.

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: patch to get latest XFree 4.0 snapshot (xf3918) to work on ppcwithr128

[Michel Dänzer]

Michael Schmitz wrote:

> > I am confused.  Now that XF 4.0 is out, will quick snapshots continue to
> > be released?
>
> One would sure hope so. The 4.0 X server dies horribly during device
> configuration on my Lombard. After feeding it a hand-crafted XF86Config,
> it just hangs the machine.

Which driver?

With the fbdev driver, you have to specify the bus ID of the graphics chip,
e.g.

    BusID	"0:1:0"


Michel

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: patch to get latest XFree 4.0 snapshot (xf3918) to work on ppcwithr128

[Michael Schmitz]

> > One would sure hope so. The 4.0 X server dies horribly during device
> > configuration on my Lombard. After feeding it a hand-crafted XF86Config,
> > it just hangs the machine.
>
> Which driver?
>
> With the fbdev driver, you have to specify the bus ID of the graphics chip,
> e.g.
>
>     BusID	"0:1:0"

I'll try that. But the results I get with X -probeonly are more than
confusing. After I tosses out most of the driver modules, the probe runs
once or twice, and gets sporadic SIGILL the rest of the time. To the
extent of not succeeding at all for the rest of the day. Or succeeding
only from the console but not from a slogin session (signal 4 in the
slogin session consistently). The signal happens apparently at different
times during X startup - while loading the dbe module, after loading the
fbdevhw module.

The chip was detected on the PCI bus - what's the BusID supposed to do in
this situation? Keep X from probing the other PCI devices?

OK, tried to feed it the BusID (0:17:0 as reported by the probe). Results:
a beep, and the warnings 'invalid mem allocation' and 'invalid IO
allocation'. The IO range smells like a port address range, is that
remapped by the PCI bridge? lspci reports the IO range as disabled. I'll
look into Geerts description of the Mach64 memory layout to figure out
what aperture X tries to use here.

Trying a 'startx' with this config leaves me with the bell on and the
machine hung.

I haven't patched or configured anything in the X source.

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: patch to get latest XFree 4.0 snapshot (xf3918) to work onppcwithr128

[Michel Dänzer]

Michael Schmitz wrote:

> I'll try that. But the results I get with X -probeonly are more than
> confusing. After I tosses out most of the driver modules,

Which drivers? Only r128, fbdev and glint are known to be working on PPC
AFAIK.


> the probe runs once or twice, and gets sporadic SIGILL the rest of the time.
> To the extent of not succeeding at all for the rest of the day. Or
> succeeding only from the console but not from a slogin session (signal 4 in
> the slogin session consistently). The signal happens apparently at different
> times during X startup - while loading the dbe module, after loading the
> fbdevhw module.

This is a known bug in the server's cache flush code. There is a fix worked
out by Kostas Gewrgiou and Kevin Hendricks which unfortunately hasn't made it
into 4.0.


> The chip was detected on the PCI bus - what's the BusID supposed to do in
> this situation? Keep X from probing the other PCI devices?
> OK, tried to feed it the BusID (0:17:0 as reported by the probe). Results:
> a beep, and the warnings 'invalid mem allocation' and 'invalid IO
> allocation'. The IO range smells like a port address range, is that
> remapped by the PCI bridge? lspci reports the IO range as disabled. I'll
> look into Geerts description of the Mach64 memory layout to figure out
> what aperture X tries to use here.

Are you trying to use the driver for Mach64?

Try the fbdev driver with the BusID. (Mach is only minimally accelerated ATM
anyway)


Michel

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: patch to get latest XFree 4.0 snapshot (xf3918) to work on pp cwithr128

[David A. Gatwood]

On Fri, 10 Mar 2000, Kevin B. Hendricks wrote:

> Hi,
>
> So Xfree 4.0 final is out but without the very last minute cache flushing
> changes Kostas made.
>
> So we should probably get some official patch out there that includes a few
> elements:
>
> 1. Either:
>        - user defined cache line size during compile
>    or:
>        - flush a cache range in address increments of 8
>
> to handle the variable line cache size
>
> 2. And something to figure out if we are on a 601 machine in the
> NuBus X100 machines to properly do a "sync or eieio" so that XFree86 4.0
> cache flushing and synchronization for io has some chance of working under
> MkLinux R1.
>
> David can you tell me how the 601 problems with sync and eieio are
> detected and handled in user space apps under MkLinux?

They aren't.  User space apps don't ever flush the cache currently.  In
kernel space, it does this:

#define eieio()         __asm__ volatile("li 0,0; cmpwi 0,0; bne+ 0f;
eieio; 0:" : : : "0")
#define sync()          __asm__ volatile("li 0,0; cmpwi 0,0; bne+ 0f;
sync; 0:" : : : "0")



David


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Help! Getting aty128fb.c to work with newest sawtooth machines

[Kevin Hendricks]

Hi Kostas,

If just received a G4 450 but if I try to use aty128fb.c in any resolution
higher than 1024x768 8bpp it will fail miserably with the screen split into 3
vertical panes.

If I try blindly launching xf 4.0 r128, it inherits the fb mode and I end up
with 3 panes as well.

This is obviously a aty128fb.c problem since it occurs in the console.

I looked at Anthony's code (remember the problem I had earlier when he tried to
read values for the dotclock and xclk out of the of device tree?) and then used
lsprop to print out the graphics card info.

Unfortunately, there were no nice of-tree variables in my G4 tree at all but it
did report my card as a Rage128Pro and not a simple Rage128.

Is a Rage128Pro different from a Rage128 when it comes to setting it up,
register usage, etc or is this simply a problem with the default timings
setting being incorrect for this card?

Interestingly enough, I can boot with aty128fb with 1024x768 and 8bpp and the
console is fine (no 3 panes) and I can then successfully start up XFree4.0 with
r128 acceleration so things do appear to be working under some cases.

Is there any tool (code piece, etc) I can use to probe the timing info as used
under MacOS?

Thanks,

Kevin

 -- Kevin B. Hendricks
Associate Professor of Operations and Information Technology
Richard Ivey School of Business, University of Western Ontario
London, Ontario  N6A-3K7  CANADA
khendricks@ivey.uwo.ca, (519) 661-3874, fax: 519-661-3959

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Help! Getting aty128fb.c to work with newest sawtooth machines

[Kostas Gewrgiou]

On Sat, 11 Mar 2000, Kevin Hendricks wrote:

> Hi Kostas,
>
> If just received a G4 450 but if I try to use aty128fb.c in any resolution
> higher than 1024x768 8bpp it will fail miserably with the screen split into 3
> vertical panes.
>
> If I try blindly launching xf 4.0 r128, it inherits the fb mode and I end up
> with 3 panes as well.
>
> This is obviously a aty128fb.c problem since it occurs in the console.
>
> I looked at Anthony's code (remember the problem I had earlier when he tried to
> read values for the dotclock and xclk out of the of device tree?) and then used
> lsprop to print out the graphics card info.
>
> Unfortunately, there were no nice of-tree variables in my G4 tree at all but it
> did report my card as a Rage128Pro and not a simple Rage128.
>
> Is a Rage128Pro different from a Rage128 when it comes to setting it up,
> register usage, etc or is this simply a problem with the default timings
> setting being incorrect for this card?
>

  Rage128Pro should be the same as Rage128, so its possible that its a
timing issue. We need to find a way to get the correct values for ppc,
i wonder if the OF rom has any info we can use.

> Interestingly enough, I can boot with aty128fb with 1024x768 and 8bpp and the
> console is fine (no 3 panes) and I can then successfully start up XFree4.0 with
> r128 acceleration so things do appear to be working under some cases.
>
> Is there any tool (code piece, etc) I can use to probe the timing info as used
> under MacOS?
>

 Ben's ATIGrab (http://ppclinux.apple.com/~benh/ATIGrab.sit) utility might
help you there, the source is included there and it shouldn't be hard to
modify it to get it working for rage128.

> Thanks,
>
> Kevin
>

  Kostas


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: patch to get latest XFree 4.0 snapshot (xf3918) to work on pp cwith r128

[Kevin Hendricks]

Hi Kostas,

Now that simply changing the xclk value lets both XFree 4.0 r128 and Xpmac work
with the new Rage128Pro cards, it would seem to be a good time to me to try to
figure out how to probe to either calulate or detect the correct timing values
so that aty128fb.c and r128 work for both my Rage128RE card and my Rage128ProPF
card at the same time (call me greedy).

I am going to dive into this next so any ideas or models to follow or hints on
how to do this correctly would be greatly appreciated.

Thanks,

Kevin



--
Kevin B. Hendricks Associate Professor of Operations and Information
Technology Richard Ivey School of Business, University of Western Ontario
London, Ontario  N6A-3K7  CANADA
khendricks@ivey.uwo.ca, (519) 661-3874, fax: 519-661-3959

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: patch to get latest XFree 4.0 snapshot (xf3918) to work on pp cwith r128

[Kevin Hendricks]

Hi Kostas,

There are three interesing tidbits about cache flushing.  One I picked up
recently on the  glibc apha and/or hacker mailing lists.

1. It seems some (many?) embedded ppc systems running linux do not have a cache
line size of 32! It is 8 or 16 or something funny.

2. AFAIK, cache flushing should never cause seg-faults since the associative
array used by the cache will ignore any address ranges not already in the cache.
If that page was never loaded it will not be in the cache.

3. 601 processors may barf(?) on some of these instructions.

So here is a piece of code I always steal when needing to do similar cache
flushing for the jdk and the metrowerks jit.  It is taken from the kernel
arch/ppc/kernel/head.S

I don't think we can access the machine type register in user space (but I am
very unsure about that).

/*
 * Write any modified data cache blocks out to memory
 * and invalidate the corresponding instruction cache blocks.
 * This is a no-op on the 601.
 *
 * flush_icache_range(unsigned long start, unsigned long stop)
 */
_GLOBAL(flush_icache_range)

	mfspr	r5,PVR
	rlwinm	r5,r5,16,16,31
	cmpi	0,r5,1
	beqlr				/* for 601, do nothing */

	li	r5,CACHE_LINE_SIZE-1
	andc	r3,r3,r5
	subf	r4,r3,r4
	add	r4,r4,r5
	srwi.	r4,r4,LG_CACHE_LINE_SIZE
	beqlr
	mtctr	r4
	mr	r6,r3
1:	dcbst	0,r3
	addi	r3,r3,CACHE_LINE_SIZE
	bdnz	1b
	sync				/* wait for dcbst's to get to ram */
	mtctr	r4
2:	icbi	0,r6
	addi	r6,r6,CACHE_LINE_SIZE
	bdnz	2b
	sync
	isync
	blr



I have no idea if the cacheline size and processor values are made available by
the kernel during runtime so that we could use those values.

I will try your changes and let you know.

Thanks,

Kevin


--
Kevin B. Hendricks Associate Professor of Operations and Information Technology
Richard Ivey School of Business, University of Western Ontario London, Ontario
N6A-3K7  CANADA    khendricks@ivey.uwo.ca, (519) 661-3874, fax: 519-661-3959

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: patch to get latest XFree 4.0 snapshot (xf3918) to work on pp cwith r128

[Gabriel Paubert]

	Hi,

> There are three interesing tidbits about cache flushing.  One I picked up
> recently on the  glibc apha and/or hacker mailing lists.
>
> 1. It seems some (many?) embedded ppc systems running linux do not have a cache
> line size of 32! It is 8 or 16 or something funny.

Indeed, and future processors might have larger cache lines. With DDR
SDRAM it would makes sense to perform 8 beat bursts, wider buses might
also become more mainstream.

> 2. AFAIK, cache flushing should never cause seg-faults since the associative
> array used by the cache will ignore any address ranges not already in the cache.
> If that page was never loaded it will not be in the cache.

Wrong, the address is translated by the MMU for most instructions,
otherwise how could you know whether which cache line to flush on a dcbf
with an n-way cache ?

On SMP cores (601,604,7400), the cache control instructions also broadcast
on the bus if the M attribute bit of the translation is set.

There are exceptions to this rule, mostly for icbi: AFAIR icbi is a nop on
601 and flushes all 8 ways of the icache on 750 (which means that
flush_icache_page could actually be optimized to flush all the cache
through HID0 manipulations instead of looping). But icbi is the only
instruction which has such wildly different implementations. OTOH, the
prefetch instructions dcbt and dcbtst actually never trap for a page fault
but I don't think you were referring to these.

> 3. 601 processors may barf(?) on some of these instructions.

No, it does not. It's just that the cache is unified which makes most
coherency functions irrelevant.

> So here is a piece of code I always steal when needing to do similar cache
> flushing for the jdk and the metrowerks jit.  It is taken from the kernel
> arch/ppc/kernel/head.S
>
> I don't think we can access the machine type register in user space (but I am
> very unsure about that).

No, you can't but a 601 will execute it just perfectly. OTOH some system
services or a user/kernel shared page at a fixed address which  would
exportt this kind of service to userland might be nice.

> I have no idea if the cacheline size and processor values are made available by
> the kernel during runtime so that we could use those values.

They should be according to the SYSV ABI reference but I think this was
never implemented.

	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/