From: "Michel Dänzer" <michel@daenzer.net>
To: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: davidm@hpl.hp.com, "Wiedemeier, Jeff" <Jeff.Wiedemeier@hp.com>,
Dave Jones <davej@codemonkey.org.uk>,
linux-kernel@vger.kernel.org, dri-devel@lists.sourceforge.net
Subject: Re: Improved DRM support for cant_use_aperture platforms
Date: 14 May 2003 12:27:05 +0200 [thread overview]
Message-ID: <1052908024.18105.135.camel@thor> (raw)
In-Reply-To: <20030514134141.A5170@jurassic.park.msu.ru>
On Mit, 2003-05-14 at 11:41, Ivan Kokshaysky wrote:
> On Tue, May 13, 2003 at 09:20:09AM -0700, David Mosberger wrote:
>
> > What's the nature of those "ugly and fragile" hacks? Are you saying
> > that CPU accesses to AGP space aren't remapped in the "normal" (PC)
> > way? Or is it something entirely different?
>
> Ok, you asked for it... :-)
> As you know, Alpha architecture is entirely cache coherent
> by design, i.e. there are no such things as non-cacheable mappings
> or cache flushing in hardware. Native Alpha Titan/Marvel AGP controllers
> are also cache coherent (kind of AGP extension of traditional
> Alpha PCI IOMMU).
> However, the "normal" PC AGP implementation isn't - this applies
> to AMD-751/761 AGP controllers on Nautilus as well.
> The AGP window on these chipsets is accessible by CPU *only* in the
> system memory address space, i.e. it's always cacheable and thus
> totally useless on Alpha.
Set cant_use_aperture and use David's patch then? :)
--
Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer
Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer
next prev parent reply other threads:[~2003-05-14 10:14 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-10 10:09 Improved DRM support for cant_use_aperture platforms David Mosberger
2003-05-10 13:12 ` Dave Jones
2003-05-11 11:43 ` Michel Dänzer
2003-05-11 18:09 ` David Mosberger
2003-05-11 19:55 ` Dave Jones
2003-05-11 21:55 ` Michel Dänzer
2003-05-12 18:53 ` David Mosberger
2003-05-12 19:48 ` [Dri-devel] " Michel Dänzer
2003-05-12 20:19 ` David Mosberger
2003-05-12 21:21 ` Michel Dänzer
2003-05-12 21:51 ` David Mosberger
2003-05-12 21:57 ` Christoph Hellwig
2003-05-12 22:08 ` Andrew Morton
2003-05-12 22:20 ` Christoph Hellwig
2003-05-13 0:34 ` Michel Dänzer
2003-05-13 1:09 ` David Mosberger
2003-05-13 13:33 ` Ivan Kokshaysky
2003-05-13 16:20 ` David Mosberger
2003-05-14 9:41 ` Ivan Kokshaysky
2003-05-14 10:27 ` Michel Dänzer [this message]
2003-05-14 17:09 ` David Mosberger
2003-05-13 7:43 ` David Mosberger
2003-05-14 14:08 ` Michel Dänzer
2003-05-15 15:59 ` David Mosberger
2003-05-15 22:37 ` Michel Dänzer
2003-05-16 23:50 ` [Dri-devel] " Michel Dänzer
2003-05-12 20:40 ` David Mosberger
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=1052908024.18105.135.camel@thor \
--to=michel@daenzer.net \
--cc=Jeff.Wiedemeier@hp.com \
--cc=davej@codemonkey.org.uk \
--cc=davidm@hpl.hp.com \
--cc=dri-devel@lists.sourceforge.net \
--cc=ink@jurassic.park.msu.ru \
--cc=linux-kernel@vger.kernel.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