public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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


       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