From: Benjamin Herrenschmidt <bh40@calva.net>
To: "Hendricks, Kevin" <khendricks@ivey.uwo.ca>,
<linuxppc-dev@lists.linuxppc.org>
Subject: Re: asm statement in include/asm not ansi conform
Date: Fri, 1 Sep 2000 18:14:32 +0200 [thread overview]
Message-ID: <20000901161432.8125@mailhost.mipsys.com> (raw)
In-Reply-To: <39AFCE61.7D68ED0C@ivey.uwo.ca>
>As I remember things, the xf4 code does do a simple check to see if
there is a
>bios present. I once enabled this code and found out on my B+W G3
machine, it
>passed that bios test but read completely bogus values (even if you converted
>the data for endian issues) whereas on my G4, it completely failed the simple
>bios check that was present.
Yes, we need a better check since OF code also begins with aa55. It looks
like on the newer machines, the ATI card ROM doesn't contain the OF code
but older cards did.
>Without a real xf86 card with a bios present to play with, there is really no
>way to try and devise a better test. Even if a bios is present, wouldn't OF
>still do the initialization?
I don't think OF will do anything but assign base addresses.
>I think we should submit it as is and ifdef it to powerpc and forget about it
>until we find out what is up.
>
>By the way, either way, the values calculated by that code should be fine (as
>long as the main code clock rate is 2950) whether intialized by OF or an
>actual
>bios so no real harm should be done (certainly better than their hardcoded
>values used now).
There is at least one r128 based PCI card for Mac that uses a different
clock rate. I think we should (for the future at least) add code to
aty128fb to recongnize it and return proper values from a private ioctl.
That wouldn't help users not using aty128fb, but on Macs, I beleive those
will be rare.
Ben.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2000-09-01 16:14 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-08-30 17:48 asm statement in include/asm not ansi conform Marc Dietrich
2000-08-30 18:12 ` Michel Dänzer
2000-08-31 16:09 ` Marc Dietrich
2000-08-31 16:18 ` Michel Dänzer
2000-09-01 10:22 ` Timothy A. Seufert
2000-09-01 11:44 ` Michel Dänzer
2000-09-01 14:37 ` Benjamin Herrenschmidt
2000-09-01 14:47 ` Michel Dänzer
2000-09-01 15:03 ` Hendricks, Kevin
2000-09-01 15:25 ` Benjamin Herrenschmidt
2000-09-01 15:24 ` Benjamin Herrenschmidt
2000-09-01 15:42 ` Hendricks, Kevin
2000-09-01 16:14 ` Benjamin Herrenschmidt [this message]
2000-09-01 20:13 ` Geert Uytterhoeven
2000-09-02 14:37 ` Michel Dänzer
2000-09-05 9:48 ` Timothy A. Seufert
2000-08-31 16:24 ` Benjamin Herrenschmidt
2000-09-01 9:19 ` Marc Dietrich
2000-09-01 10:48 ` Michel Dänzer
2000-09-01 11:03 ` Benjamin Herrenschmidt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20000901161432.8125@mailhost.mipsys.com \
--to=bh40@calva.net \
--cc=khendricks@ivey.uwo.ca \
--cc=linuxppc-dev@lists.linuxppc.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).