From: Lou Langholtz <ldl@chpc.utah.edu>
To: mlan@cpu.lu
Cc: linuxppc-dev@lists.linuxppc.org
Subject: Re: controlfb.c bug in VRAM bank2 check if bank1
Date: Tue, 12 Oct 1999 01:07:10 -0600 [thread overview]
Message-ID: <3802DE1E.37E49762@chpc.utah.edu> (raw)
In-Reply-To: 199909131813.UAA00324@piglet.cpu.lu
Michel Lanners wrote:
> Hmm... official 2.2.12 does detect my 4 MB... and this is a 7600, so the same
> motherboard as the 7500...
> Michel
Something is wrong then. Using AC's 2.2.13pre15 on my 7500 the driver just doesn't
recognize 4MB of VRAM unless I hack the bank2 check. So either you're not really
getting all 4MB VRAM detected or the 7600 uses a different hardware configuration
than my 7500/100. What does "fbset -i" tell you for size of the frame buffer
device? That the 8500 operates as Andrew Fyfe <bandr@best.com> claimed according
to the comments in one of the patches that someone sent out make sense. The
relevant part of that patch reads:
+ /* According to Andrew Fyfe <bandr@best.com>, the VRAM behaves like so: */
+ /* afyfe: observations from an 8500:
+ * - with 2M vram in bank 1, it appears at offsets 0, 2M and 4M
+ * - with 2M vram in bank 2, it appears only at offset 6M
+ * - with 4M vram, it appears only as a 4M block at offset 0.
+ */
What you're seeing with your 7600 then just doesn't make sense unless it's video
hardware is somehow different than the 7500/100 that I have. The 7500/100 that
I have has only four slots where each slot holds a 1MB VRAM memory module. Is that
the same on the 7600? If the 7600 really has the control video card and yours
really has 4MB VRAM then according to sources the memory must be detectable at
both offset 0, and 6M where the second VRAM bank can actually also handle itself
in a contiguous 4MB block from offset 0. That seems very odd indeed.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~1999-10-12 7:07 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-09-10 15:55 controlfb.c bug in VRAM bank2 check if bank1 Lou Langholtz
1999-09-10 17:08 ` Lou Langholtz
1999-09-10 18:33 ` Michel Lanners
1999-09-12 16:58 ` Lou Langholtz
1999-09-13 18:13 ` Michel Lanners
1999-09-15 15:14 ` Lou Langholtz
1999-10-12 7:07 ` Lou Langholtz [this message]
1999-10-12 7:23 ` Bizarre g++ problem Patrik Jonsson
1999-10-12 6:49 ` controlfb.c bug in VRAM bank2 check if bank1 Lou Langholtz
1999-10-12 14:50 ` Daniel Jacobowitz
1999-10-12 15:36 ` Lou Langholtz
1999-10-13 6:30 ` Geert Uytterhoeven
1999-09-11 10:51 ` Brad Boyer
1999-09-10 20:13 ` Daniel Jacobowitz
1999-09-11 9:23 ` Benjamin Herrenschmidt
1999-09-12 18:10 ` Daniel Jacobowitz
-- strict thread matches above, loose matches on Subject: below --
1999-09-15 17:05 Kevin_Hendricks
1999-09-15 18:26 ` Kevin Puetz
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=3802DE1E.37E49762@chpc.utah.edu \
--to=ldl@chpc.utah.edu \
--cc=linuxppc-dev@lists.linuxppc.org \
--cc=mlan@cpu.lu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.