All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
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: Sun, 12 Sep 1999 10:58:30 -0600	[thread overview]
Message-ID: <37DBDBB6.4B608A42@chpc.utah.edu> (raw)
In-Reply-To: 199909101833.UAA17210@piglet.cpu.lu


Michel Lanners wrote:

> On  10 Sep, this message from Lou Langholtz echoed through cyberspace:
> > After getting an extra 2MB VRAM for my PowerMac7500 and seeing that only
> > 2MB were still being recognized (despite having just added the 2MB to
> > total to 4MB VRAM), I dug into the controlfb.c code from 2.2.11 and
> > 2.2.12 and made the following changes to get all 4MB VRAM recognized:
>
> > <  out_8(&p->frame_buffer[0x600000], 0xa5);
> > <  out_8(&p->frame_buffer[0x600001], 0x38);
> > ---
> >>  out_8(&p->frame_buffer[0x200000], 0xa5);
> >>  out_8(&p->frame_buffer[0x200001], 0x38);
>
> Hmm, if I remember right, there have been half a dozen patch pairs that
> changed 0x600000 to 0x200000 and back over the years ;-)
>
> I guess it's time to clear thgis up once and for all. By the way, I do
> have 4 MB of VRAM, and all of it is detected with the current version
> of controlfb.....

If I had a spare PowerMac 7500 I'd love to test every combo and see what gets
detected where. Unfortunately I don't, but hope someone else can do this
instead and get conclusive info that we need. It concerns me too that people
with 8500's (that seem to have the same graphics card) seem to observe
different behavior in detection.

What version of controlfb are you using? Current from the 2.2 kernel tree,
2.3 kernel tree, or 2.2 or 2.3 from vger, or even somewhere else. 2.2.12
wouldn't detect all 4MB VRAM in my 7500 box. I'm sorry but I haven't kept up
very well with all the different distributions of source. Let me know which
release then you use and I'll eagerely check it out ;-)

> Michel . . .


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

  reply	other threads:[~1999-09-12 16:58 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 [this message]
1999-09-13 18:13     ` Michel Lanners
1999-09-15 15:14       ` Lou Langholtz
1999-10-12  7:07       ` Lou Langholtz
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=37DBDBB6.4B608A42@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.