[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <alpine.LFD.2.00.1012151536510.21167@x980>
Date: Wed, 15 Dec 2010 16:16:15 -0500 (EST)
From: Len Brown <lenb@...nel.org>
To: Jack Steiner <steiner@....com>
Cc: hpa@...or.com, hmh@....eng.br, tony.luck@...il.com,
linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org,
gbeshers@....com
Subject: Re: [PATCH] - Mapping ACPI tables as CACHED
> Do you want me to resend the patch w/o the calls to e820?
Sure.
I think this would be a 1 line-patch in acpi_os_map_memory()
to change ioremap() to ioremap_cache() if ia64 had an ioremap_cache().
Maybe it is a 2-line patch to define ioremap_cache() to ioremap()
in ia64? It appears that ia64 has an ioremap() and an ioremap_nocache()
so presumably this would change no functionalty there.
I actually don't like the original patch wording with map_table_permanent,
since acpi_os_map_memory() is used for more than tables -- any AML
memory opregion will use it, so lets avoid that.
Granted, __acpi_map_table() isn't the best name either,
though it happens to be used only for tables by virtue
of being guarded by testing acpi_gbl_permenent_map.
That said, we don't start using cached mappings until
acpi_gbl_permanent_mmap is set in acpi_early_init(),
(when you see "ACPI Core revision" in dmesg)
I'll bet we can improve the boot sequence so that
some of the stuff we do before we have cached mappings
we can do with cached mappings...
We checksum all the tables, enumerate the CPUs and the APICs
all using non-cached mappings....
thanks,
Len Brown, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists