Re: Problems with the atyfb driver on Power Mac G3

Re: Problems with the atyfb driver on Power Mac G3

[Benjamin Herrenschmidt]

On Fri, Jul 2, 1999, Geert Uytterhoeven
<Geert.Uytterhoeven@cs.kuleuven.ac.be> wrote:

>To get maximum performance, you want a low threshold-empty value and a high
>threshold-full value, because SGRAM is optimized for burst accesses, but
has a
>high latency for the initial access. Higher threshold-empty and lower
>threshold-full values are more conservative and more likely to not
disturb the
>screen, but lower the performance.

What about providing a private ioctl to set those threshold values ? With
a simple command line tool and eventually a pair of sliders on X, this
would allow people to try out and us to collect infos about behaviour of
various values on various configurations, and eventually provide more
conservative default values, and letting the user eventually increase
performances later. 


-- 
           Perso. e-mail: <mailto:bh40@calva.net>
           Work   e-mail: <mailto:benh@mipsys.com>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>




[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Problems with the atyfb driver on Power Mac G3 (Possible fix)

[Eric Dorland]

>>This patch works for me...
>
>It works for me too! I'm so happy! Thanks Tim!

It appears I spoke too soon :( The patch does appear to work flawlessly
when in video mode 13 (832 x 624) but in video mode 15 (1024 x 768) still
has snow. I'm still happy, because I use vmode 13 primarily, but the
problem is not 100% fixed. I think an ioctl, to fiddle with the values,
would still be helpful.

Eric Dorland
mailto:dorland@lords.com



[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Problems with the atyfb driver on Power Mac G3 (Possible fix)

[Geert Uytterhoeven]

On Fri, 9 Jul 1999, Josh Huber wrote:
> Perhaps this is a question for Geert to answer, but it appears as though 2d acceleration is not being used for scrolling text in xterms. As a demonstration, fire up a new xterm, make it real big, and try and ls -lR /
> 
> Now, it's been so long since I've used xpmac that I don't remember wether or not it performed said operation, but perhaps someone could try it out?

I know.

I haven't done anything on ATI acceleration in XF68_FBDev since December 1998.
I just saw the last alpha of the 3.9 branch of XFree86 finally has support for
ATI Mach64, so it may be a good idea to start working again on it (it time
permits)...

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Frame buffer on B+W G3 macs reports wrong display depth

[Kevin B. Hendricks]

Hi,

I really could use some help tracking down a problem.  From looking at
XF86Config and from running xdpyinfo, it seems the XF86 frame buffer server
reports incorrect bit depths which in turn are driving the JDK 1.2 swing
color model crazy!!!

For example, when I put my B+W into millions of color mode, xdpyinfo claims
32 bits for the depth (wrong it is 24, 8 bits for red, green, and blue),
and correctly claims 32 bits per pixel.

It has the same problem under 16 bit color, it claims a depth of 16 when in
reality the depth should be 15, 5 bits each for red, green, and blue
(although still using 16 bits per pixel).

I need to track this down and get it fixed asap to resolve the JDK 1.2
problems.  Note, that the Xpmac server correctly reports the bit depths and
it works fine with JDK 1.2 although it doesn't support the usb keyboard or
mouse correctly.

Does anyone have any ideas of where in all of the Xfree source code I
should begin looking?

Any guidance here would be greatly appreciated.

Thanks,

Kevin




[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Frame buffer on B+W G3 macs reports wrong display depth

[Takashi Oe]

On Tue, 13 Jul 1999, Kevin B. Hendricks wrote:

> Hi,
> 
> I really could use some help tracking down a problem.  From looking at
> XF86Config and from running xdpyinfo, it seems the XF86 frame buffer server
> reports incorrect bit depths which in turn are driving the JDK 1.2 swing
> color model crazy!!!
> 
> For example, when I put my B+W into millions of color mode, xdpyinfo claims
> 32 bits for the depth (wrong it is 24, 8 bits for red, green, and blue),
> and correctly claims 32 bits per pixel.

Can you re-code JDK swing to look at red/green/blue mask infos instead of 
just blindingly using "depth" info?  For both servers, masks are 8 bit
each for 24/32 and 5 bit each for 15/16 with many display cards on Macs.


Takashi Oe


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Problems with the atyfb driver on Power Mac G3

[Geert Uytterhoeven]

On Sun, 15 Aug 1999, Eric Dorland wrote:
> >At 4:28 PM -0400 8/15/99, Eric Dorland wrote:
> >>So now atyclk works, and through some experimenting, I've found that
> >>changing the dsp_on value from 24 to 29 removes all the snow I have been
> >>experiencing, without any noticeable slow down. Hooray! Now, the problem is
> >>that this value does not get retained when switching virtual consoles, ie
> >>whenever I switch virtual consoles or start X the dsp_on value gets reset
> >>back to 24. How can I get this value to stay fixed? Should I just hardcode
> >>it into my own kernel compile?
> >
> >Probably not.  Whenever you change video modes, dsp_on and dsp_off are
> >recalculated from the new parameters; a fixed value will not be right for
> >all situations.
> 
> You're right of course. I would have to modify the calculation in some way.
> Any ideas how?

The first thing is to repeat the experiment with a few samples of the set of
zillions of video modes. Then you have to try to find a relation between all
parameters. aty_dsp_gt() in drivers/video/atyfb.c may be good start, just
assume some of the hardcoded values there are wrong.

If you find the Magic Formula, just let us know :-)

> >If you use the exact same mode (and I mean exact) on all VCs (including the
> >one X is running on), no mode switch will be performed when you change VCs,
> >which should preserve your custom dsp_on setting.
> 
> This, unfortunately, does not seem to be the case. I am using the smae mode
> in all my VCs and X and the dsp_on setting is not preserved. I think that
> the atyfb driver gets re-intialized each time I change VCs.

Atyfb always reprograms the video mode. The optimization of not doing that
wasn't implemented yet.

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Problems with the atyfb driver on Power Mac G3

[Geert Uytterhoeven]

On Tue, 6 Jul 1999, Eric Dorland wrote:
> >What about providing a private ioctl to set those threshold values ? With
> >a simple command line tool and eventually a pair of sliders on X, this
> >would allow people to try out and us to collect infos about behaviour of
> >various values on various configurations, and eventually provide more
> >conservative default values, and letting the user eventually increase
> >performances later.
> 
> Would anyone be willing to write such I beast? I would be more than willing
> to lend a hand (having fair C skills), but I know little about kernel
> hacking and even less about fiddling with video drivers, so I don't know
> how much help I'd be :)

It's on my list. Not the GUI thing of course, but just the ioctl() stuff and a
small program to play with it.

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Problems with the atyfb driver on Power Mac G3

[Geert Uytterhoeven]

[ I typed and sent this mail last monday, but it seems to have gotten lost, so
  I'm retyping and resending it ]

On Sun, 11 Jul 1999, Geert Uytterhoeven wrote:
> On Tue, 6 Jul 1999, Eric Dorland wrote:
> > >What about providing a private ioctl to set those threshold values ? With
> > >a simple command line tool and eventually a pair of sliders on X, this
> > >would allow people to try out and us to collect infos about behaviour of
> > >various values on various configurations, and eventually provide more
> > >conservative default values, and letting the user eventually increase
> > >performances later.
> > 
> > Would anyone be willing to write such I beast? I would be more than willing
> > to lend a hand (having fair C skills), but I know little about kernel
> > hacking and even less about fiddling with video drivers, so I don't know
> > how much help I'd be :)
> 
> It's on my list. Not the GUI thing of course, but just the ioctl() stuff and a
> small program to play with it.

And so I did: not the GUI thing, but a small command line utility. And a patch
for atyfb, of course:

    http://www.cs.kuleuven.ac.be/~geert/bin/atyfb_dsp_debug.tar.gz
	
The things related to the FIFO you can tune with it are

  - DSP loop latency (0-15): SDRAM/SGRAM latency?
  - DSP precision (0-7) for next 3 options, which are actually floating point
    numbers. Atyclk automatically takes care of the conversion, using the
    specified (or current) precision.
  - number of xclocks per display row: this is the ratio between the FIFO
    empty rate (vclk * bpp bits) and the FIFO fill rate (mclk * 64 bits).
  - DSP on threshold: the FIFO starts refilling when less than `on' pixels are
    available in the FIFO.
  - DSP off threshold: the FIFO stops refilling when `off' pixels are
    available in the FIFO.

(this is a combination of the scarse information from the ATI docs and what I
 found out).

`atyclk --help' for a list of options.

Some explanation about how the FIFO works (yes, I really should start writing
a text about graphics board programming, covering topics like

  - The CRT/graphics engine
  - PLL programming
  - The display FIFO
  - Acceleration engine programming (command FIFO, ...)
):

--------------------------------------------------------------------------------
SDRAM/SGRAM are synchronous types of memory. This means they can deliver one
word of data on every clock cycle in burst mode. Unfortunately SDRAM/SGRAM
have high latencies. This means you need s clock cycles to fetch one word of
data, but only s+1 clock cycles for two words, s+2 clock cyles for three
words, and so on. To optimize performance, you better access bursts of many
consecutive words in memory after each other. Random memory access is a
nightmare with SDRAM/SGRAM, since each access takes s clock cycles (s being
much higher than with the old FPM or EDO RAM).

Summarized:

  SDRAM/SGRAM: s/1/1/1
  FPM RAM: s/3/3/3
  EDO RAM: s/2/2/2

The actual numbers may differ, but you can see the point.

The graphics engine has to read from memory to provide the monitor with the
correct display data. But since SDRAM/SGRAM is single-ported memory (unlike
VRAM and WRAM, which are dual-ported), the graphics engine has to share
graphics memory access with the acceleration engine and the CPU.
read/write to that memory.

Graphics engine access has strict `real time' constraints: if it can't read
data when needed, the screen image will be disturbed. To prevent this and to
utilize the burst features of SGRAM, the graphics engine reads from the video
memory through a FIFO. When the FIFO gets empty (below a specified threshold),
data is fetched. When the FIFO gets sufficiently full (above a specified
threshold), video memory access is suspended and the CPU or acceleration
engine are free to do their things.

                  +-------------------------------+
                  |                               |
   w bits at ---> | FIFO with n entries of w bits | ---> bpp bits at
   rate mclk      |                               |      rate vclk
                  +-------------------------------+
                         ^               ^
                         |               |
                      FIFO on         FIFO off
                      threshold       threshold

To get maximum performance, you want a low threshold-empty value and a high
threshold-full value, because SGRAM is optimized for burst accesses, but has a
high latency for the initial access. Higher threshold-empty and lower
threshold-full values are more conservative and more likely to not disturb the
screen, but lower the performance.
--------------------------------------------------------------------------------

For the ATI, we have:

  w = 64 bits
  n = 24 (RAGE/RAGE II/RAGE IIc) or 32 (RAGE PRO) entries
  mclk = memory clock
  vclk = pixel clock

DISCLAIMER: do not use this if you don't understand everything I wrote above!

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Problems with the atyfb driver on Power Mac G3

[Eric Dorland]

>And so I did: not the GUI thing, but a small command line utility. And a patch
>for atyfb, of course:
>
>    http://www.cs.kuleuven.ac.be/~geert/bin/atyfb_dsp_debug.tar.gz

I finally got a chance to apply this patch to my kernel (thanks very much
Geert:). The patch applied cleanly to the 2.2.10 kernel and compiled with
no problems. The atyclk program compiled fine as well, but whenever I try
to use it I get the error:

ioctl ATYIO_CLKR: Invalid argument

Have I missed something? Has anyone else gotten the patch to work?

Eric Dorland
mailto:dorland@lords.com



[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Problems with the atyfb driver on Power Mac G3

[Eric Dorland]

>>And so I did: not the GUI thing, but a small command line utility. And a
>>patch
>>for atyfb, of course:
>>
>>    http://www.cs.kuleuven.ac.be/~geert/bin/atyfb_dsp_debug.tar.gz
>
>I finally got a chance to apply this patch to my kernel (thanks very much
>Geert:). The patch applied cleanly to the 2.2.10 kernel and compiled with
>no problems. The atyclk program compiled fine as well, but whenever I try
>to use it I get the error:
>
>ioctl ATYIO_CLKR: Invalid argument
>
>Have I missed something? Has anyone else gotten the patch to work?

I thought I posted a reply to this message already, but it didn't  appear
to hit the list, so my apologies if you've seen it before.

The above problem I was having with atyclk was not a problem with the patch
at all. I was using BootX 1.1.2, which has an annoying bug in it, which
caused it to always select the first kernel in the list. Upgrading to 1.1.3
cured the problem.

So now atyclk works, and through some experimenting, I've found that
changing the dsp_on value from 24 to 29 removes all the snow I have been
experiencing, without any noticeable slow down. Hooray! Now, the problem is
that this value does not get retained when switching virtual consoles, ie
whenever I switch virtual consoles or start X the dsp_on value gets reset
back to 24. How can I get this value to stay fixed? Should I just hardcode
it into my own kernel compile?

Eric Dorland
mailto:dorland@lords.com



[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Problems with the atyfb driver on Power Mac G3

[Kevin Puetz]

nOn Wed, 30 Jun 1999, Eric Dorland wrote:

> >1st thing for both of you (and other users) - STAY AWAY FROM 2.3.x UNLESS
> >YOU KNOW WHY YOU ARE MOVING TO IT!
> 
> I don't use them. I just booted with 2.3.6 once because it contained the
> latest atyfb driver, to see if it would help. It didn't.

Geert suggested just moving atyfb.c from 2.3.6 into 2.2.10 - that is
definately less risky. But when Linus says developmental release, it
means this version would never have left the project team in a normal
software company.

> >On a happier note, I checked out 2.2.10 today (use -rlinux_2_2 if you use
> >cvs to switch branches), and built it, and the dancing pixels and other
> >artifacts are gone (on a rev 1 G3 desktop with Rage II+, but I had the same
> >symptoms, so maybe the same fix will help).
> 
> I'm glad someone's having some luck :) What settings is the kernel
> reporting (mlck, pll, etc.)?

67/200 (I think, from memory) but this is a Rage II+ not a Rage Pro (It's
a rev 1 box) so the values may not apply to your situation well.

> >I think 2.2.10 has the mach64 work from 2.3.6 backported into it w/o the
> >other potential problems
> 
> I don't think the stock 2.2.10 kernel has the latest drivers in it, but you
> can drop the atyfb.c file from 2.3.6 into a 2.2.10 tree and it should
> compile without problems. I believe someone has a precompiled kernel that
> is like this. I use the 2.2.10 kernel everyday, but the snow persists.

Hmm... it went away for me. Want the vmlinux? I can send it to you if you
want (not that it should be any different than one you built, but...). It
has pretty much normal config+mac-on-linux patches.

> Eric Dorland
> mailto:dorland@lords.com
> 
> 

Kevin Puetz <kp11901@www.cedarnet.org>



[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Problems with the atyfb driver on Power Mac G3

[Kevin Puetz]

1st thing for both of you (and other users) - STAY AWAY FROM 2.3.x UNLESS 
YOU KNOW WHY YOU ARE MOVING TO IT!

this is a _developmental_ branch. It has the potential (and some likelyhood)
to corrupt hard drives occasionally, and otherwise behave erratically at
several points along the way. If you are intending to develop - great. But
if you are a user (like me) who wants to use the system reliably, follow the
2.2.x revisions (currently 2.2.10). Odd minor-numbered versions of Linux are
in a state of flux, and are not necessarily even going to compile
(structural changes may be being distributed for driver authors to work
against while drivers are worked on).

Now, the ? files are not a sign of already done damage. They are harmless
(created by a bug in gmc, the gnome file manager) and can be deleted or
ignored.

On a happier note, I checked out 2.2.10 today (use -rlinux_2_2 if you use
cvs to switch branches), and built it, and the dancing pixels and other
artifacts are gone (on a rev 1 G3 desktop with Rage II+, but I had the same
symptoms, so maybe the same fix will help).

I think 2.2.10 has the mach64 work from 2.3.6 backported into it w/o the
other potential problems

--
+--------------------------------------------------------------------+
|            .-'''''-.       Kevin Puetz                             |
|          .'   _/|   `.                                             |
|         :   =/_/      :    kp11901@cedarnet.org -preferred         |
|        :   _/ |        :   Kevin.Puetz@039-server.pls.uni.edu      |
|       (\  /  ,|        :   webmaster@039-server.pls.uni.edu        |
|        \\/^\/||__     :                                            |
|     _/~`~`""~`"` \_ .'  "Could you please continue the petty       |
|  __/  -'/  `-._ `\_\__   bickering?  I find it - most intriguing." |
|/     /-'`  `\   \  \-.\    --Data, STTNG, "Haven"                  |
+--------------------------------------------------------------------+

----------
>From: "Michael R. Zucca" <mrz5149@acm.ORG>
>To: Eric Dorland <dorland@lords.COM>
>Cc: linuxppc-dev@lists.linuxppc.ORG
>Subject: Re: Problems with the atyfb driver on Power Mac G3
>Date: Tue, Jun 29, 1999, 8:30 PM
>

>
> At 8:44 PM -0400 6/29/99, Eric Dorland wrote:
>>Through playing with the mclk and pll arguments (mclk:68,pll:200) I can
>>reduce the amount of "pixel dancing", but when there is a lot of movement
>>on the screen it is still quite noticable. I got these values from sheer
>>experimenting, and could be slowing cooking my chip for all I know.
>
> I'm experiencing the same problem on my PowerCenter 132 with my ATI VR-Pro.
> I have a feeling that there is a bug in the Rage-Pro support.
>
> I've also had trouble with the acceleration causing garbage on the screen
> in 16 bit mode when I drag windows.
>
> It's entirely possible that we don't have the memory layout quite correct
> or something. To add insult to injury I also have an Adaptec Ultra SCSI PCI
> card and a 4 Gig drive that Linux is booting off of. I've had some random
> files show up like "?:" including the quote characters. Maybe there are
> deeper PCI problems or is this just a bug in the Adaptec driver? (With a
> the R5 2.2.6 kernel and a 2.3.6 custom compile).
>
> I've been meaning to look into the code but I haven't had the time. Anybody
> have some clues? My card *used* to work under 2.1.24 when I added the
> support to the original driver ;-)
>
> _______________________________________________________________________
>  Michael Zucca - mrz5149@acm.org - http://www.mdc.net/~mrz5149/
>  "I will choose a path that's clear. I will choose Freewill. "
>   --Rush, Freewill
> _______________________________________________________________________

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Problems with the atyfb driver on Power Mac G3

[Michael R. Zucca]

At 10:58 PM -0400 6/29/99, Kevin Puetz wrote:

>this is a _developmental_ branch.

As a past contributor and somebody who does this professionally, I
understand the risks and am happily walking on the hot coals of my own
volition. Thanks for the tip, though :-)

>Now, the ? files are not a sign of already done damage. They are harmless
>(created by a bug in gmc, the gnome file manager) and can be deleted or
>ignored.

I didn't know this as I've never had any experience with GNOME. That is one
nasty little bug, though. Those files can be quite the pain to get rid of.

>On a happier note, I checked out 2.2.10 today (use -rlinux_2_2 if you use
>cvs to switch branches), and built it, and the dancing pixels and other
>artifacts are gone (on a rev 1 G3 desktop with Rage II+, but I had the same
>symptoms, so maybe the same fix will help).

I think 2.2.10's driver is just the 2.3.6 driver code. It may be working
for you out of sheer luck or perhaps the fix was enough for Rage II+. The
problem persists on my Rage Pro.

>I think 2.2.10 has the mach64 work from 2.3.6 backported into it w/o the
>other potential problems

Well, as far as I can tell the 2.3.6 fb code only partially solves the
problem. We probe for the MCLK now but perhaps we should also probe for PLL
clock (are we already?). Can't we just get these values from OF? I thought
I saw an entry in the card's device tree for such stuff.

_______________________________________________________________________
 Michael Zucca - mrz5149@acm.org - http://www.mdc.net/~mrz5149/
 "I will choose a path that's clear. I will choose Freewill. "
  --Rush, Freewill
_______________________________________________________________________



[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Problems with the atyfb driver on Power Mac G3

[Eric Dorland]

I posted this message (see below) to the user list, but didn't get much of
a response. Because it's more a bug in the atyfb driver I thought you guys
would have more luck. My apologies if you've seen this message already.


>From reading the list recently, it seems a lot of Powerbook G3 are having
problems with the atyfb driver. I'm also having problems, but with my Power
Mac G3 266 rev. 2 using its onboard Rage Pro card and 2 MB of VRAM. When I
boot up with the kernel argument video=atyfb:vmode:13,cmode:16 I get
"dancing pixels", or snow if you prefer, down one side of the screen as
illustarted by this rather crude drawing:

-------------------------
| .			|
| .			|
| .			|
| .			|
| .			|	The dots are the dancing pixels, which
| .			|	flicker on and off.
| .			|
| .			|
| .			|
-------------------------

These pixels flicker on and off down the left side the screen in an
extremely irritating fashion in the console and X. When I boot up using the
above arguments using the 2.3.6 kernel I get a line stating:

atyfb: 3D RAGE PRO (PQFP, PCI) [0x4750 rev 0x7c] 2M SGRAM, 14.31818 MHz
XTAL, 230 MHz PLL, 100 Mhz MCLK

Through playing with the mclk and pll arguments (mclk:68,pll:200) I can
reduce the amount of "pixel dancing", but when there is a lot of movement
on the screen it is still quite noticable. I got these values from sheer
experimenting, and could be slowing cooking my chip for all I know.

Has anyone with a Power Mac (especially with a similar set up) exprienced
similar problems? Any solutions? BTW the atyfb driver in the 2.1.130 kernel
worked very well, these problems started when I began using the 2.2.x
kernels. Anyone know what might have changed between the two or have a copy
of atyfb.c from the 2.1.130 kernel (Geert maybe :).

PS: I realise I could use "No video driver" and use Xpmac and force mach64
acceleration, but I would much rather use XF68_FBDEV so I can change
resolutions from linux and such. Also, I'm stubborn.

Eric Dorland
mailto:dorland@lords.com



[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Problems with the atyfb driver on Power Mac G3

[Michael R. Zucca]

At 8:44 PM -0400 6/29/99, Eric Dorland wrote:
>Through playing with the mclk and pll arguments (mclk:68,pll:200) I can
>reduce the amount of "pixel dancing", but when there is a lot of movement
>on the screen it is still quite noticable. I got these values from sheer
>experimenting, and could be slowing cooking my chip for all I know.

I'm experiencing the same problem on my PowerCenter 132 with my ATI VR-Pro.
I have a feeling that there is a bug in the Rage-Pro support.

I've also had trouble with the acceleration causing garbage on the screen
in 16 bit mode when I drag windows.

It's entirely possible that we don't have the memory layout quite correct
or something. To add insult to injury I also have an Adaptec Ultra SCSI PCI
card and a 4 Gig drive that Linux is booting off of. I've had some random
files show up like "?:" including the quote characters. Maybe there are
deeper PCI problems or is this just a bug in the Adaptec driver? (With a
the R5 2.2.6 kernel and a 2.3.6 custom compile).

I've been meaning to look into the code but I haven't had the time. Anybody
have some clues? My card *used* to work under 2.1.24 when I added the
support to the original driver ;-)

_______________________________________________________________________
 Michael Zucca - mrz5149@acm.org - http://www.mdc.net/~mrz5149/
 "I will choose a path that's clear. I will choose Freewill. "
  --Rush, Freewill
_______________________________________________________________________



[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]