linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Benjamin C.R. LaHaise" <blah@kvack.org>
To: Timur Tabi <ttabi@interactivesi.com>
Cc: Linux MM mailing list <linux-mm@kvack.org>
Subject: Re: pgd/pmd/pte and x86 kernel virtual addresses
Date: Fri, 25 Aug 2000 23:59:03 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.3.96.1000825235248.27724A-100000@kanga.kvack.org> (raw)
In-Reply-To: <20000825185716Z131186-247+10@kanga.kvack.org>

On Fri, 25 Aug 2000, Timur Tabi wrote:

> If I use ioremap_nocache(), I effectively have two virtual pointers to the same
> physical pointer.  The first is the normal virtual pointer for kernel memory,
> and the second is the one returned by ioremap_nocache().  I was under the
> understanding that caching is enabled on physical pages only, so it shouldn't
> matter which virtual address I use.  Is that correct?

No.  Depending on which virtual address you use, you will get different
behaviour (cached vs not).

> MTRR's are not an option, because chances are we won't have any free MTRR's to
> work with.  Besides, I can do what I want on Windows 2000 without MTRR's.  My
> driver is for a device which sits on the memory bus itself and responds to
> memory reads/writes.  If I can't disable caching, I can't talk to the device.

Ummm, then why is it in the range of normally cachable memory?  On Pentium
class machines there is a signal which indicates if a given memory access
is cachable/not.  On P6/later K6s/K7s you must use the MTRRs.

> The odd thing is that ioremap_nocache() did work at one point, but not any
> more, and I can't figure out why.

Technically ioremap should only be used on io addresses.  What in
particular is not working -- is the mapping incorrect, or is the mapping
being cached?  If the mapping is still being cached from previous
accesses, you will need to flush the CPU's cache of any stale cache lines.

		-ben

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

  reply	other threads:[~2000-08-26  3:59 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-08-24 23:21 Timur Tabi
2000-08-24 23:43 ` Benjamin C.R. LaHaise
2000-08-25 15:25   ` Timur Tabi
2000-08-25 16:45     ` Benjamin C.R. LaHaise
2000-08-25 16:40       ` Timur Tabi
2000-08-25 16:59         ` Benjamin C.R. LaHaise
2000-08-25 18:46           ` Timur Tabi
2000-08-26  3:59             ` Benjamin C.R. LaHaise [this message]
2000-08-28 23:09             ` Stephen C. Tweedie
2000-08-29 15:31               ` Timur Tabi

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=Pine.LNX.3.96.1000825235248.27724A-100000@kanga.kvack.org \
    --to=blah@kvack.org \
    --cc=linux-mm@kvack.org \
    --cc=ttabi@interactivesi.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