From: Andi Kleen <ak@muc.de>
To: Terence Ripperda <tripperda@nvidia.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: PAT support
Date: Tue, 13 Apr 2004 02:01:33 +0200 [thread overview]
Message-ID: <m3n05gu4o2.fsf@averell.firstfloor.org> (raw)
In-Reply-To: <1KifY-uA-7@gated-at.bofh.it> (Terence Ripperda's message of "Tue, 13 Apr 2004 00:40:06 +0200")
Terence Ripperda <tripperda@nvidia.com> writes:
Hi Terence,
> this current patch includes the original PAT support and the new
> cachemap mechanism. note that the cachemap mechanism does not
> actually change any caching attributes, it only keeps track of the
> attributes and tests regions. I think the end idea would be that
> drivers would use the normal
> ioremap/change_page_attr/remap_page_range mechanisms like they
> already do, and these mechanisms would in turn use cachemap to make
> sure there's no conflicts. I'm completely open to how any specific
> details should work, and any changes needed to be made.
Looks good for starting. The patch could use some minor cleanup still,
but it should be good enough for testing.
As for an interface - i still think it would be cleaner to just
call it from change_page_attr(). Then other users only need to
call a single function. But that's easily changed.
To make it really useful I think we need ioremap_wrcomb() and support
in the bus/pci mmap function (the PCI layer already has ioctls for this,
they are just ignored on i386 right). Then the X server could
start using it.
Without any users the testing coverage would be probably not too good,
but it needs some testing in the real world before it could
be merged first. Maybe it could be simply hooked into the AGP
driver and into some DRM driver. Then people would start testing
it at least.
-Andi
next parent reply other threads:[~2004-04-13 0:01 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1KifY-uA-7@gated-at.bofh.it>
2004-04-13 0:01 ` Andi Kleen [this message]
2004-04-13 16:21 ` PAT support Terence Ripperda
2004-04-14 0:58 ` Andi Kleen
2004-04-16 18:07 ` Terence Ripperda
2004-04-17 0:42 ` Andi Kleen
2004-04-19 22:54 ` Terence Ripperda
2004-04-20 18:51 ` Andi Kleen
2004-04-21 23:19 ` Terence Ripperda
2004-04-22 4:21 ` Andi Kleen
2004-04-15 4:11 ` Eric W. Biederman
2004-04-15 16:38 ` Andi Kleen
2004-04-15 18:39 ` Eric W. Biederman
2004-04-15 21:38 Albert Cahalan
-- strict thread matches above, loose matches on Subject: below --
2004-04-13 5:34 Manfred Spraul
2004-04-13 14:02 ` Pavel Machek
2004-04-13 16:40 ` Terence Ripperda
2004-04-15 4:05 ` Eric W. Biederman
2004-04-12 22:29 Terence Ripperda
2004-04-13 8:36 ` Andy Whitcroft
2004-04-13 16:50 ` Terence Ripperda
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=m3n05gu4o2.fsf@averell.firstfloor.org \
--to=ak@muc.de \
--cc=linux-kernel@vger.kernel.org \
--cc=tripperda@nvidia.com \
/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