From: Matt Sealey <matt@genesi-usa.com>
To: Jon Smirl <jonsmirl@gmail.com>
Cc: ppc-dev <linuxppc-dev@ozlabs.org>
Subject: Re: radeonfb, dedicate memory to something else
Date: Tue, 22 Jul 2008 09:31:14 +0100 [thread overview]
Message-ID: <48859AD2.6050404@genesi-usa.com> (raw)
In-Reply-To: <9e4733910807200826m22b676aewa89de8df9fd6da33@mail.gmail.com>
Jon Smirl wrote:
> On 7/20/08, Matt Sealey <matt@genesi-usa.com> wrote:
>> Hi guys,
>>
>> I know this isn't a PPC question, but since some of the RadeonFB developers
>> live here I thought best (and it's about a PPC platform).
>>
>> Is there any way to hack up the RadeonFB driver - or anything related - to
>> reserve portions of the memory for a "fake" MTD or so, and still use the
>> Radeon as a graphics device? What I am talking about basically is turning
>> a 64MB Radeon card into a 32MB Radeon card, or a 128MB one into a 64MB
>> card..
>
> Somebody write this long ago. Maybe around 2000. That's all I
> remember. I think they made the video memory into a ram disk.
Yeah making it into a ramdisk precludes the use of the card as a video card
though.. this is what I am trying to get around. If fbdev and X can cooperate
on believing that a 64MB card is a 32MB card, then the upper 32MB can be used
to attach the MTD "ram" driver at a certain address (maybe we can even make a
hacky stub driver that recognizes this configuration based on OF tree..)
There are obvious limitations in that the Pegasos/Efika firmware only will
map 128MB of video memory, and the PCI BAR is limited to 256MB chunks anyway,
but that shouldn't matter. I just wonder, how it can be done that radeonfb
or other graphics drivers can be told "please only use the first 32MB" and
then either manually or automatically, map the rest as ramdisk.
> I believe there is more to it, the GART window may be smaller than the
> total RAM on the card. You need to use the GART to map in the
> appropriate pieces.
The problem here is the PCI bus on the Efika is a PCI bus, with an AGP
riser. It doesn't add any AGP functionality like real GART on the host
controller side, so there is nothing to map system memory into AGP's
view of the system.. it always confused me how "pcigart" is meant to
work and how an AGP GART does anything different to how PCI works in
the first place (the documentation/spec doesn't make it that clear in
my opinion :)
You would certainly know better than I..
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
next prev parent reply other threads:[~2008-07-22 8:31 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-20 10:03 radeonfb, dedicate memory to something else Matt Sealey
2008-07-20 15:26 ` Jon Smirl
2008-07-22 8:31 ` Matt Sealey [this message]
2008-07-22 8:52 ` Michel Dänzer
2008-07-22 9:05 ` Matt Sealey
2008-07-22 14:25 ` Jon Smirl
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=48859AD2.6050404@genesi-usa.com \
--to=matt@genesi-usa.com \
--cc=jonsmirl@gmail.com \
--cc=linuxppc-dev@ozlabs.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 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.