[lkml]   [2001]   [Jan]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: ioremap_nocache problem?
From: David Wragg <>
Gcc: nnfolder:mail.sent
--text follows this line--
Roman Zippel <> writes:
> On Tue, 23 Jan 2001, Mark Mokryn wrote:
> > ioremap_nocache does the following:
> > return __ioremap(offset, size, _PAGE_PCD);

You have a point.

It would be nice if ioremap took a argument indicating the desired
memory type -- normal, nocache, write-through, write-combining, etc.
Then it could look in an architecture-specific table to get the
appropriate page flags for that type.

(x86 processors with PAT and IA64 can set write-combining through page
flags. x86 processors with MTRRs but not PAT would need a more
elaborate implementation for write-combining.)

> >
> > However, in drivers/char/mem.c (2.4.0), we see the following:
> >
> > /* On PPro and successors, PCD alone doesn't always mean
> > uncached because of interactions with the MTRRs. PCD | PWT
> > means definitely uncached. */
> > if (boot_cpu_data.x86 > 3)
> > prot |= _PAGE_PCD | _PAGE_PWT;
> >
> > Does this mean ioremap_nocache() may not do the job?
> ioremap creates a new mapping that shouldn't interfere with MTRR, whereas
> you can map a MTRR mapped area into userspace. But I'm not sure if it's
> correct that no flag is set for boot_cpu_data.x86 <= 3...

The boot_cpu_data.x86 > 3 test is there because the 386 doesn't have

David Wragg
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:18    [W:0.069 / U:2.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site