From: "Stephen C. Tweedie" <sct@redhat.com>
To: Timur Tabi <ttabi@interactivesi.com>
Cc: Jeff Hartmann <jhartmann@valinux.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: ioremap_nocache problem?
Date: Fri, 26 Jan 2001 10:43:46 +0000 [thread overview]
Message-ID: <20010126104346.D11607@redhat.com> (raw)
In-Reply-To: <3A6D5D28.C132D416@sangate.com> <20010123165117Z131182-221+34@kanga.kvack.org> <20010123165117Z131182-221+34@kanga.kvack.org> <20010125155345Z131181-221+38@kanga.kvack.org> <20010125165001Z132264-460+11@vger.kernel.org> <E14LpvQ-0008Pw-00@mail.valinux.com> <3A7066A1.5030608@valinux.com> <20010125175027Z131219-222+40@kanga.kvack.org>
In-Reply-To: <20010125175027Z131219-222+40@kanga.kvack.org>; from ttabi@interactivesi.com on Thu, Jan 25, 2001 at 11:53:01AM -0600
Hi,
On Thu, Jan 25, 2001 at 11:53:01AM -0600, Timur Tabi wrote:
>
> > As in an MMIO aperture? If its MMIO on the bus you should be able to
> > just call ioremap with the bus address. By nature of it being outside
> > of real ram, it should automatically be uncached (unless you've set an
> > MTRR over that region saying otherwise).
>
> It's not outside of real RAM. The device is inside real RAM (it sits on the
> DIMM itself), but I need to poke through the entire 4GB range to see how it
> responds.
kmap() is designed for that, not ioremap(). Is it absolutely
essential that your mapping is uncached? If so, extending kmap() to
support kmap_nocache() would seem to make a lot more sense than using
ioremap(): kmap is there for temporarily poking around in high memory,
whereas ioremap is really intended to be used for persistent maps.
--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
WARNING: multiple messages have this Message-ID (diff)
From: "Stephen C. Tweedie" <sct@redhat.com>
To: Timur Tabi <ttabi@interactivesi.com>
Cc: Jeff Hartmann <jhartmann@valinux.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: ioremap_nocache problem?
Date: Fri, 26 Jan 2001 10:43:46 +0000 [thread overview]
Message-ID: <20010126104346.D11607@redhat.com> (raw)
In-Reply-To: <20010125175027Z131219-222+40@kanga.kvack.org>; from ttabi@interactivesi.com on Thu, Jan 25, 2001 at 11:53:01AM -0600
Hi,
On Thu, Jan 25, 2001 at 11:53:01AM -0600, Timur Tabi wrote:
>
> > As in an MMIO aperture? If its MMIO on the bus you should be able to
> > just call ioremap with the bus address. By nature of it being outside
> > of real ram, it should automatically be uncached (unless you've set an
> > MTRR over that region saying otherwise).
>
> It's not outside of real RAM. The device is inside real RAM (it sits on the
> DIMM itself), but I need to poke through the entire 4GB range to see how it
> responds.
kmap() is designed for that, not ioremap(). Is it absolutely
essential that your mapping is uncached? If so, extending kmap() to
support kmap_nocache() would seem to make a lot more sense than using
ioremap(): kmap is there for temporarily poking around in high memory,
whereas ioremap is really intended to be used for persistent maps.
--Stephen
--
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/
next prev parent reply other threads:[~2001-01-26 10:46 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-01-23 10:30 ioremap_nocache problem? Mark Mokryn
2001-01-23 10:30 ` Mark Mokryn
2001-01-23 16:53 ` Timur Tabi
2001-01-25 15:16 ` Stephen C. Tweedie
2001-01-25 15:16 ` Stephen C. Tweedie
2001-01-25 15:56 ` Timur Tabi
2001-01-25 16:44 ` Roman Zippel
2001-01-25 16:44 ` Roman Zippel
2001-01-25 16:49 ` Timur Tabi
2001-01-26 10:39 ` Stephen C. Tweedie
2001-01-26 10:39 ` Stephen C. Tweedie
2001-01-25 16:49 ` Timur Tabi
2001-01-25 17:04 ` Jeff Hartmann
2001-01-25 17:04 ` Jeff Hartmann
2001-01-25 17:11 ` Timur Tabi
2001-01-25 17:11 ` Timur Tabi
[not found] ` <E14LpvQ-0008Pw-00@mail.valinux.com>
2001-01-25 17:47 ` Jeff Hartmann
2001-01-25 17:47 ` Jeff Hartmann
2001-01-25 17:53 ` Timur Tabi
2001-01-26 10:43 ` Stephen C. Tweedie [this message]
2001-01-26 10:43 ` Stephen C. Tweedie
2001-01-26 16:32 ` Eric W. Biederman
2001-01-26 19:22 ` Timur Tabi
2001-01-25 17:53 ` Timur Tabi
2001-01-25 18:13 ` Jeff Hartmann
2001-01-25 18:13 ` Jeff Hartmann
2001-01-25 18:18 ` Timur Tabi
2001-01-25 18:18 ` Timur Tabi
[not found] ` <E14Lqyt-0003z6-00@mail.valinux.com>
2001-01-25 18:46 ` Jeff Hartmann
2001-01-25 18:46 ` Jeff Hartmann
[not found] ` <200101251556.f0PFuPd01743@mail.redhat.com>
2001-01-26 10:37 ` Stephen C. Tweedie
2001-01-26 10:37 ` Stephen C. Tweedie
2001-01-25 15:56 ` Timur Tabi
2001-01-23 16:53 ` Timur Tabi
2001-01-23 18:12 ` Roman Zippel
2001-01-23 18:12 ` Roman Zippel
2001-01-23 18:38 ` Timur Tabi
2001-01-24 0:50 ` David Wragg
2001-01-24 0:50 ` David Wragg, David Wragg
2001-01-24 15:14 ` Timur Tabi
2001-01-24 15:14 ` Timur Tabi
[not found] ` <E14LRce-0008FU-00@diver.doc.ic.ac.uk>
2001-01-24 15:39 ` David Wragg
2001-01-24 15:39 ` David Wragg
2001-01-23 18:38 ` Timur Tabi
2001-01-24 1:01 ` David Wragg
2001-01-24 1:01 ` David Wragg
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=20010126104346.D11607@redhat.com \
--to=sct@redhat.com \
--cc=jhartmann@valinux.com \
--cc=linux-kernel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.