From: Kevin Hendricks <hidden> Date: 2000-03-04 18:55:34
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
From: Michel D�nzer <hidden> Date: 2000-03-05 13:42:43
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/
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).
quoted
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.
From: Kevin B. Hendricks <hidden> Date: 2000-03-05 16:58:13
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.
quoted
quoted
By the way, true 16 bit depth (565) does not work on my machine. The
screen
quoted
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/
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.
quoted
quoted
quoted
By the way, true 16 bit depth (565) does not work on my machine. The
screen
quoted
comes up but everything is very very green!
Reverting to 16bpp and 15 depth (555) works fine.
quoted
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 ?
By the way, true 16 bit depth (565) does not work on my machine. The
screen
quoted
comes up but everything is very very green!
Reverting to 16bpp and 15 depth (555) works fine.
quoted
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/
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 ?
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/
From: Kevin Hendricks <hidden> Date: 2000-03-09 02:41:22
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/
From: Kevin Hendricks <hidden> Date: 2000-03-09 03:11:31
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/
From: Gabriel Paubert <hidden> Date: 2000-03-09 11:04:34
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/
From: Kevin Hendricks <hidden> Date: 2000-03-11 14:38:39
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/
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.
From: Kevin Hendricks <hidden> Date: 2000-03-14 01:12:33
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/