From: Shaohua Li <shaohua.li@intel.com>
To: Len Brown <lenb@kernel.org>
Cc: Jack Steiner <steiner@sgi.com>, "hpa@zytor.com" <hpa@zytor.com>,
Henrique de Moraes Holschuh <hmh@hmh.eng.br>,
"tony.luck@gmail.com" <tony.luck@gmail.com>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"gbeshers@sgi.com" <gbeshers@sgi.com>
Subject: Re: [PATCH] ACPI: use ioremap_cache()
Date: Tue, 28 Dec 2010 11:21:00 +0800 [thread overview]
Message-ID: <1293506460.10593.43.camel@sli10-conroe> (raw)
In-Reply-To: <alpine.LFD.2.00.1012170307080.20940@x980>
On Fri, 2010-12-17 at 16:08 +0800, Len Brown wrote:
> From: Len Brown <len.brown@intel.com>
>
> Although the temporary boot-time ACPI table mappings
> were set up with CPU caching enabled, the permanent table
> mappings and AML run-time region memory accesses were
> set up with ioremap(), which on x86 is a synonym for
> ioremap_nocache().
>
> Changing this to ioremap_cache() improves performance as
> seen when accessing the tables via acpidump,
> or /sys/firmware/acpi/tables. It should also improve
> AML run-time performance.
>
> No change on ia64.
>
> Reported-by: Jack Steiner <steiner@sgi.com>
> Signed-off-by: Len Brown <len.brown@intel.com>
> ---
> arch/ia64/include/asm/io.h | 5 +++++
> drivers/acpi/osl.c | 6 +++---
> 2 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/arch/ia64/include/asm/io.h b/arch/ia64/include/asm/io.h
> index cc8335e..009a7e0 100644
> --- a/arch/ia64/include/asm/io.h
> +++ b/arch/ia64/include/asm/io.h
> @@ -426,6 +426,11 @@ extern void __iomem * ioremap_nocache (unsigned long offset, unsigned long size)
> extern void iounmap (volatile void __iomem *addr);
> extern void __iomem * early_ioremap (unsigned long phys_addr, unsigned long size);
> extern void early_iounmap (volatile void __iomem *addr, unsigned long size);
> +static inline void __iomem * ioremap_cache (unsigned long phys_addr, unsigned long size)
> +{
> + return ioremap(unsigned long phys_addr, unsigned long size);
> +}
> +
>
> /*
> * String version of IO memory access ops:
> diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
> index 966fedd..85eba53 100644
> --- a/drivers/acpi/osl.c
> +++ b/drivers/acpi/osl.c
> @@ -324,7 +324,7 @@ acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
>
> pg_off = round_down(phys, PAGE_SIZE);
> pg_sz = round_up(phys + size, PAGE_SIZE) - pg_off;
> - virt = ioremap(pg_off, pg_sz);
> + virt = ioremap_cache(pg_off, pg_sz);
> if (!virt) {
> kfree(map);
> return NULL;
> @@ -646,7 +646,7 @@ acpi_os_read_memory(acpi_physical_address phys_addr, u32 * value, u32 width)
> virt_addr = acpi_map_vaddr_lookup(phys_addr, size);
> rcu_read_unlock();
> if (!virt_addr) {
> - virt_addr = ioremap(phys_addr, size);
> + virt_addr = ioremap_cache(phys_addr, size);
> unmap = 1;
> }
> if (!value)
> @@ -682,7 +682,7 @@ acpi_os_write_memory(acpi_physical_address phys_addr, u32 value, u32 width)
> virt_addr = acpi_map_vaddr_lookup(phys_addr, size);
> rcu_read_unlock();
> if (!virt_addr) {
> - virt_addr = ioremap(phys_addr, size);
> + virt_addr = ioremap_cache(phys_addr, size);
> unmap = 1;
> }
blindly map the range as cache is not ok. for example:
OperationRegion (RCRB, SystemMemory, 0xFED1C000, 0x4000)
Field (RCRB, DWordAcc, Lock, Preserve)
{
Offset (0x1000),
Offset (0x3000),
Offset (0x3404),
HPAS, 2,
, 5,
HPAE, 1,
Offset (0x3418),
, 1,
PATD, 1,
SATD, 1,
SMBD, 1,
HDAD, 1,
A97D, 1,
Offset (0x341A),
RP1D, 1,
RP2D, 1,
RP3D, 1,
RP4D, 1,
RP5D, 1,
RP6D, 1
}
RCRB is a memory mapped io. In ICH, it's chipset configuration
registers. this range can't be cached.
I thought we should add a check like
if page is E820_RAM or E820_ACPI then
cached_map
else
uncached_map
we have page_is_ram() API which just checks E820_RAM, I thought we can
add a new API to check E820_ACPI.
Thanks,
Shaohua
next prev parent reply other threads:[~2010-12-28 3:21 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-14 22:09 [PATCH] - Mapping ACPI tables as CACHED Jack Steiner
2010-12-14 22:58 ` H. Peter Anvin
2010-12-14 23:22 ` Len Brown
2010-12-15 0:26 ` H. Peter Anvin
2010-12-15 2:27 ` Jack Steiner
2010-12-15 4:17 ` H. Peter Anvin
2010-12-15 0:04 ` Len Brown
2010-12-15 1:18 ` H. Peter Anvin
2010-12-15 2:40 ` Len Brown
2010-12-15 2:41 ` Jack Steiner
2010-12-15 4:03 ` Len Brown
2010-12-15 4:35 ` Len Brown
2010-12-15 6:17 ` H. Peter Anvin
2010-12-15 16:46 ` Jack Steiner
2010-12-15 21:16 ` Len Brown
2010-12-15 22:18 ` H. Peter Anvin
2010-12-17 2:54 ` Len Brown
2010-12-17 8:08 ` [PATCH] ACPI: use ioremap_cache() Len Brown
2010-12-27 19:42 ` Tony Luck
2010-12-27 20:12 ` H. Peter Anvin
2010-12-28 3:21 ` Shaohua Li [this message]
2010-12-28 3:35 ` H. Peter Anvin
2010-12-28 5:02 ` Shaohua Li
2010-12-28 20:12 ` H. Peter Anvin
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=1293506460.10593.43.camel@sli10-conroe \
--to=shaohua.li@intel.com \
--cc=gbeshers@sgi.com \
--cc=hmh@hmh.eng.br \
--cc=hpa@zytor.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=steiner@sgi.com \
--cc=tony.luck@gmail.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