From: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
To: davidm@hpl.hp.com
Cc: "Wiedemeier, Jeff" <Jeff.Wiedemeier@hp.com>,
"Michel Dänzer" <michel@daenzer.net>,
"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: Wed, 14 May 2003 13:41:41 +0400 [thread overview]
Message-ID: <20030514134141.A5170@jurassic.park.msu.ru> (raw)
In-Reply-To: <16065.6969.137647.391163@napali.hpl.hp.com>; from davidm@napali.hpl.hp.com on Tue, May 13, 2003 at 09:20:09AM -0700
On Tue, May 13, 2003 at 09:20:09AM -0700, David Mosberger wrote:
> Ivan> Note that some Alphas may have "cant_use_aperture" cleared.
>
> "Interesting".
Yep. ;-)
> If cant_use_aperture isn't set, my patch won't help, but it shouldn't
> hurt anything either. I.e., you should be no worse off than before.
Sure. Basically, I'll only need to re-diff.
> 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.
Fortunately, AMD northbridges (at least 761) have some features
that allow *limited* access to system memory, including AGP space,
through EV6 non-cacheable IO address space (using "magic" 16 Gb offset).
Limitations:
- quadword writes corrupt ECC.
EV6 doesn't generate ECC for IO space, but the chipset expects ECC
from CPU on full quad writes (narrower writes are ok since the chipset
does read-modify-write and updates ECC by itself).
This wouldn't be a big deal since nobody should access pages mapped
into AGP, but there are occasional speculative loads which hit data
with bad ECC that causing the machine checks. So I must handle these
machine checks properly - check that the page is AGP and then either
scrub the affected location to fix ECC or dismiss the machine check.
- according to AMD specs, reads to this "non-cacheable" region are
not supported. Not quite true, as quadword loads (ldq/ldq_u) do work
(verified on 761, 751 needs testing). Narrower loads indeed don't work.
Fortunately, AGP space reads seem to be sort of exotic (in both
kernel and userspace drivers), so they can be easily found and converted
to ldq/ldq_u.
In addition I cannot trust PALcode error handler on UP1500 - sometimes it
does bogus things...
By now I have all this crap running more or less stable with
radeon 7200 card. Machine check handling needs some improvements though.
Ivan.
next prev parent reply other threads:[~2003-05-14 9:29 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 [this message]
2003-05-14 10:27 ` Michel Dänzer
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=20030514134141.A5170@jurassic.park.msu.ru \
--to=ink@jurassic.park.msu.ru \
--cc=Jeff.Wiedemeier@hp.com \
--cc=davej@codemonkey.org.uk \
--cc=davidm@hpl.hp.com \
--cc=dri-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=michel@daenzer.net \
/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).