public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
* state of some x86 acpi patches
@ 2008-12-16 19:19 Jeremy Fitzhardinge
  2008-12-16 19:25 ` Ingo Molnar
  2008-12-18 13:44 ` Andi Kleen
  0 siblings, 2 replies; 15+ messages in thread
From: Jeremy Fitzhardinge @ 2008-12-16 19:19 UTC (permalink / raw)
  To: Brown, Len, Yinghai Lu, linux-acpi; +Cc: Ingo Molnar

[-- Attachment #1: Type: text/plain, Size: 247 bytes --]

Hi Len,

Have you seen these three patches?  Do they look OK to you?

Yinghai Lu improve the third patch ("acpi: remove final __acpi_map_table 
mapping before setting acpi_gbl_permanent_mmap"), which I think Ingo 
sent you instead.

Thanks,
    J

[-- Attachment #2: x86-__acpi_map_table-use-early_ioremap.patch --]
[-- Type: text/plain, Size: 3252 bytes --]

Subject: x86: use early_ioremap in __acpi_map_table

__acpi_map_table effectively reimplements early_ioremap().  Rather
than have that duplication, just implement it in terms of
early_ioremap().

However, unlike early_ioremap(), __acpi_map_table just maintains a
single mapping which gets replaced each call, and has no corresponding
unmap function.  Implement this by just removing the previous mapping
each time its called.  Unfortunately, this will leave a stray mapping
at the end.

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
 arch/x86/include/asm/acpi.h      |    3 ---
 arch/x86/include/asm/fixmap_32.h |    4 ----
 arch/x86/include/asm/fixmap_64.h |    4 ----
 arch/x86/kernel/acpi/boot.c      |   27 +++++++--------------------
 4 files changed, 7 insertions(+), 31 deletions(-)

===================================================================
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -121,8 +121,8 @@
  */
 char *__init __acpi_map_table(unsigned long phys, unsigned long size)
 {
-	unsigned long base, offset, mapped_size;
-	int idx;
+	static char *prev_map;
+	static unsigned long prev_size;
 
 	if (!phys || !size)
 		return NULL;
@@ -130,26 +130,13 @@
 	if (phys+size <= (max_low_pfn_mapped << PAGE_SHIFT))
 		return __va(phys);
 
-	offset = phys & (PAGE_SIZE - 1);
-	mapped_size = PAGE_SIZE - offset;
-	clear_fixmap(FIX_ACPI_END);
-	set_fixmap(FIX_ACPI_END, phys);
-	base = fix_to_virt(FIX_ACPI_END);
+	if (prev_map)
+		early_iounmap(prev_map, prev_size);
 
-	/*
-	 * Most cases can be covered by the below.
-	 */
-	idx = FIX_ACPI_END;
-	while (mapped_size < size) {
-		if (--idx < FIX_ACPI_BEGIN)
-			return NULL;	/* cannot handle this */
-		phys += PAGE_SIZE;
-		clear_fixmap(idx);
-		set_fixmap(idx, phys);
-		mapped_size += PAGE_SIZE;
-	}
+	prev_size = size;
+	prev_map = early_ioremap(phys, size);
 
-	return ((unsigned char *)base + offset);
+	return prev_map;
 }
 
 #ifdef CONFIG_PCI_MMCONFIG
===================================================================
--- a/arch/x86/include/asm/acpi.h
+++ b/arch/x86/include/asm/acpi.h
@@ -102,9 +102,6 @@
 	acpi_noirq = 1;
 }
 
-/* Fixmap pages to reserve for ACPI boot-time tables (see fixmap.h) */
-#define FIX_ACPI_PAGES 4
-
 extern int acpi_gsi_to_irq(u32 gsi, unsigned int *irq);
 
 static inline void acpi_noirq_set(void) { acpi_noirq = 1; }
===================================================================
--- a/arch/x86/include/asm/fixmap_32.h
+++ b/arch/x86/include/asm/fixmap_32.h
@@ -99,10 +99,6 @@
 			(__end_of_permanent_fixed_addresses & 255),
 	FIX_BTMAP_BEGIN = FIX_BTMAP_END + NR_FIX_BTMAPS*FIX_BTMAPS_NESTING - 1,
 	FIX_WP_TEST,
-#ifdef CONFIG_ACPI
-	FIX_ACPI_BEGIN,
-	FIX_ACPI_END = FIX_ACPI_BEGIN + FIX_ACPI_PAGES - 1,
-#endif
 #ifdef CONFIG_PROVIDE_OHCI1394_DMA_INIT
 	FIX_OHCI1394_BASE,
 #endif
===================================================================
--- a/arch/x86/include/asm/fixmap_64.h
+++ b/arch/x86/include/asm/fixmap_64.h
@@ -50,10 +50,6 @@
 	FIX_PARAVIRT_BOOTMAP,
 #endif
 	__end_of_permanent_fixed_addresses,
-#ifdef CONFIG_ACPI
-	FIX_ACPI_BEGIN,
-	FIX_ACPI_END = FIX_ACPI_BEGIN + FIX_ACPI_PAGES - 1,
-#endif
 #ifdef CONFIG_PROVIDE_OHCI1394_DMA_INIT
 	FIX_OHCI1394_BASE,
 #endif

[-- Attachment #3: x86-acpi-always-map.patch --]
[-- Type: text/plain, Size: 878 bytes --]

Subject: x86: always explicitly map acpi memory

Always map acpi tables, rather than assuming we can use the normal
linear mapping to access the acpi tables.  This is necessary in a
virtual environment where the linear mappings are to pseudo-physical
memory, but the acpi tables exist at a real physical address.  It
doesn't hurt to map in the normal non-virtual case, so just do it
unconditionally.

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
 arch/x86/kernel/acpi/boot.c |    3 ---
 1 file changed, 3 deletions(-)

===================================================================
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -126,9 +126,6 @@
 
 	if (!phys || !size)
 		return NULL;
-
-	if (phys+size <= (max_low_pfn_mapped << PAGE_SHIFT))
-		return __va(phys);
 
 	if (prev_map)
 		early_iounmap(prev_map, prev_size);

[-- Attachment #4: acpi-clear-__acpi_map_table-mapping.patch --]
[-- Type: text/plain, Size: 1491 bytes --]

Subject: acpi: remove final __acpi_map_table mapping before setting acpi_gbl_permanent_mmap

On x86, __acpi_map_table uses early_ioremap() to create the mapping,
replacing the previous mapping with a new one.  Once enough of the
kernel is up an running it switches to using normal ioremap().  At
that point, we need to clean up the final mapping to avoid a warning
from the early_ioremap subsystem.

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
 arch/x86/kernel/acpi/boot.c |    8 +++++---
 drivers/acpi/bus.c          |    6 ++++++
 2 files changed, 11 insertions(+), 3 deletions(-)

===================================================================
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -124,11 +124,13 @@
 	static char *prev_map;
 	static unsigned long prev_size;
 
+	if (prev_map) {
+		early_iounmap(prev_map, prev_size);
+		prev_map = NULL;
+	}
+
 	if (!phys || !size)
 		return NULL;
-
-	if (prev_map)
-		early_iounmap(prev_map, prev_size);
 
 	prev_size = size;
 	prev_map = early_ioremap(phys, size);
===================================================================
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -650,6 +650,12 @@
 	if (!acpi_strict)
 		acpi_gbl_enable_interpreter_slack = TRUE;
 
+	/*
+	 * Doing a zero-sized mapping will clear out the previous
+	 * __acpi_map_table() mapping, if any.
+	 */
+	__acpi_map_table(0, 0);
+
 	acpi_gbl_permanent_mmap = 1;
 
 	status = acpi_reallocate_root_table();

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: state of some x86 acpi patches
  2008-12-16 19:19 state of some x86 acpi patches Jeremy Fitzhardinge
@ 2008-12-16 19:25 ` Ingo Molnar
  2008-12-31 23:38   ` Len Brown
  2008-12-18 13:44 ` Andi Kleen
  1 sibling, 1 reply; 15+ messages in thread
From: Ingo Molnar @ 2008-12-16 19:25 UTC (permalink / raw)
  To: Jeremy Fitzhardinge; +Cc: Brown, Len, Yinghai Lu, linux-acpi


* Jeremy Fitzhardinge <jeremy@goop.org> wrote:

> Hi Len,
>
> Have you seen these three patches?  Do they look OK to you?
>
> Yinghai Lu improve the third patch ("acpi: remove final __acpi_map_table 
> mapping before setting acpi_gbl_permanent_mmap"), which I think Ingo 
> sent you instead.

Len,

i asked about these patches before too - and if that's fine with you we'd 
just queue them up in the x86 tree (like we did before the .28 merge 
window). Most of the impact will be on x86. So an Acked-by from you would 
be fine to start this.

	Ingo

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: state of some x86 acpi patches
  2008-12-16 19:19 state of some x86 acpi patches Jeremy Fitzhardinge
  2008-12-16 19:25 ` Ingo Molnar
@ 2008-12-18 13:44 ` Andi Kleen
  2008-12-18 19:46   ` Jeremy Fitzhardinge
  1 sibling, 1 reply; 15+ messages in thread
From: Andi Kleen @ 2008-12-18 13:44 UTC (permalink / raw)
  To: Jeremy Fitzhardinge; +Cc: Brown, Len, Yinghai Lu, linux-acpi, Ingo Molnar

Jeremy Fitzhardinge <jeremy@goop.org> writes:
>
> However, unlike early_ioremap(), __acpi_map_table just maintains a
> single mapping which gets replaced each call, and has no corresponding
> unmap function.  Implement this by just removing the previous mapping
> each time its called.  Unfortunately, this will leave a stray mapping
> at the end.

Stray mappings are dangerous. They can lead to illegal cache aliases
later. Better avoid them.

I guess ACPI could call a cleanup function after it's done with
all early mappings.

-Andi


-- 
ak@linux.intel.com

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: state of some x86 acpi patches
  2008-12-18 13:44 ` Andi Kleen
@ 2008-12-18 19:46   ` Jeremy Fitzhardinge
  2008-12-18 21:47     ` Ingo Molnar
  0 siblings, 1 reply; 15+ messages in thread
From: Jeremy Fitzhardinge @ 2008-12-18 19:46 UTC (permalink / raw)
  To: Andi Kleen; +Cc: Brown, Len, Yinghai Lu, linux-acpi, Ingo Molnar

Andi Kleen wrote:
> Jeremy Fitzhardinge <jeremy@goop.org> writes:
>   
>> However, unlike early_ioremap(), __acpi_map_table just maintains a
>> single mapping which gets replaced each call, and has no corresponding
>> unmap function.  Implement this by just removing the previous mapping
>> each time its called.  Unfortunately, this will leave a stray mapping
>> at the end.
>>     
>
> Stray mappings are dangerous. They can lead to illegal cache aliases
> later. Better avoid them.
>
> I guess ACPI could call a cleanup function after it's done with
> all early mappings.
>   

Right.  But Yinghai (I think) went through and made all the acpi 
mappings get properly mapped and unmapped, so my patch is moot.

    J

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: state of some x86 acpi patches
  2008-12-18 19:46   ` Jeremy Fitzhardinge
@ 2008-12-18 21:47     ` Ingo Molnar
  0 siblings, 0 replies; 15+ messages in thread
From: Ingo Molnar @ 2008-12-18 21:47 UTC (permalink / raw)
  To: Jeremy Fitzhardinge; +Cc: Andi Kleen, Brown, Len, Yinghai Lu, linux-acpi


* Jeremy Fitzhardinge <jeremy@goop.org> wrote:

> Andi Kleen wrote:
>> Jeremy Fitzhardinge <jeremy@goop.org> writes:
>>   
>>> However, unlike early_ioremap(), __acpi_map_table just maintains a
>>> single mapping which gets replaced each call, and has no corresponding
>>> unmap function.  Implement this by just removing the previous mapping
>>> each time its called.  Unfortunately, this will leave a stray mapping
>>> at the end.
>>>     
>>
>> Stray mappings are dangerous. They can lead to illegal cache aliases
>> later. Better avoid them.
>>
>> I guess ACPI could call a cleanup function after it's done with
>> all early mappings.
>>   
>
> Right.  But Yinghai (I think) went through and made all the acpi 
> mappings get properly mapped and unmapped, so my patch is moot.

yes, right.

	Ingo

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: state of some x86 acpi patches
  2008-12-16 19:25 ` Ingo Molnar
@ 2008-12-31 23:38   ` Len Brown
  2009-01-01  6:49     ` Jeremy Fitzhardinge
  0 siblings, 1 reply; 15+ messages in thread
From: Len Brown @ 2008-12-31 23:38 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: Jeremy Fitzhardinge, Yinghai Lu, linux-acpi

On Tue, 16 Dec 2008, Ingo Molnar wrote:

> 
> * Jeremy Fitzhardinge <jeremy@goop.org> wrote:
> 
> > Hi Len,
> >
> > Have you seen these three patches?  Do they look OK to you?
> >
> > Yinghai Lu improve the third patch ("acpi: remove final __acpi_map_table 
> > mapping before setting acpi_gbl_permanent_mmap"), which I think Ingo 
> > sent you instead.
> 
> Len,
> 
> i asked about these patches before too - and if that's fine with you we'd 
> just queue them up in the x86 tree (like we did before the .28 merge 
> window). Most of the impact will be on x86. So an Acked-by from you would 
> be fine to start this.

Sorry for the delay.
I recall reading your e-mail on this and thought I replied to it,
but for some reason I found neither your original message nor
my reply when I searched my archives today.

But I did recall Ingo making a branch for this one, and so looking
at remotes/origin/acpi-for-len in ingo's tree...

It isn't immediately clear to me what problem this patch series solves,
and thus it is hard to judge how important this is.

It touches a lot of files, and it is going to run into a bunch of merge 
conflicts.

I'm not thrilled that the first part of the series makes changes
which are then undone by the later part of the series --
that doesn't help w/ conflict resolution...

The change to tbxface.c is an ACPICA API change.
It looks reasonable and it might be the right change,
but it is extra work -- we should sync with Bob
when he gets back from break.

So, this one is sort of a headache, how important is it?

thanks,
-- Len Brown, Intel Open Source Technology Center


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: state of some x86 acpi patches
  2008-12-31 23:38   ` Len Brown
@ 2009-01-01  6:49     ` Jeremy Fitzhardinge
  2009-01-02 15:39       ` Ingo Molnar
  0 siblings, 1 reply; 15+ messages in thread
From: Jeremy Fitzhardinge @ 2009-01-01  6:49 UTC (permalink / raw)
  To: Len Brown; +Cc: Ingo Molnar, Yinghai Lu, linux-acpi

Len Brown wrote:
> On Tue, 16 Dec 2008, Ingo Molnar wrote:
>
>   
>> * Jeremy Fitzhardinge <jeremy@goop.org> wrote:
>>
>>     
>>> Hi Len,
>>>
>>> Have you seen these three patches?  Do they look OK to you?
>>>
>>> Yinghai Lu improve the third patch ("acpi: remove final __acpi_map_table 
>>> mapping before setting acpi_gbl_permanent_mmap"), which I think Ingo 
>>> sent you instead.
>>>       
>> Len,
>>
>> i asked about these patches before too - and if that's fine with you we'd 
>> just queue them up in the x86 tree (like we did before the .28 merge 
>> window). Most of the impact will be on x86. So an Acked-by from you would 
>> be fine to start this.
>>     
>
> Sorry for the delay.
> I recall reading your e-mail on this and thought I replied to it,
> but for some reason I found neither your original message nor
> my reply when I searched my archives today.
>
> But I did recall Ingo making a branch for this one, and so looking
> at remotes/origin/acpi-for-len in ingo's tree...
>
> It isn't immediately clear to me what problem this patch series solves,
> and thus it is hard to judge how important this is.
>
> It touches a lot of files, and it is going to run into a bunch of merge 
> conflicts.
>
> I'm not thrilled that the first part of the series makes changes
> which are then undone by the later part of the series --
> that doesn't help w/ conflict resolution...
>
> The change to tbxface.c is an ACPICA API change.
> It looks reasonable and it might be the right change,
> but it is extra work -- we should sync with Bob
> when he gets back from break.
>
> So, this one is sort of a headache, how important is it?
>   

Well, there's several aspects to this series:

The important one from my perspective is using early_ioremap to map the 
acpi memory, rather than using a private mapping function; this is 
necessary when running under Xen, so that the right memory gets mapped.

This in itself is pretty straightforward, but it raises a few issues.  
One is that the acpi code doesn't properly unmap its mapped memory, but 
relies on a "new mapping replaces old" semantic.  Putting a wrapper 
around early_ioremap to emulate this is fairly straightforward, but it 
does leave one trailing mapping, which causes early_ioremap to raise a 
warning.

I addressed this warning by putting in a hook to unmap the last 
mapping.  This was simple, but pretty hackish.  Yinghai went the extra 
distance by making the acpi code properly pair map and unmap calls on 
all the resources it needs, doing away with the "new map unmaps 
previous" behaviour, and cleaning up the warning in the process.

Thanks,
    J

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: state of some x86 acpi patches
  2009-01-01  6:49     ` Jeremy Fitzhardinge
@ 2009-01-02 15:39       ` Ingo Molnar
  2009-01-02 22:28         ` Len Brown
  2009-01-28 23:45         ` Jeremy Fitzhardinge
  0 siblings, 2 replies; 15+ messages in thread
From: Ingo Molnar @ 2009-01-02 15:39 UTC (permalink / raw)
  To: Jeremy Fitzhardinge; +Cc: Len Brown, Yinghai Lu, linux-acpi


* Jeremy Fitzhardinge <jeremy@goop.org> wrote:

> Len Brown wrote:
>> On Tue, 16 Dec 2008, Ingo Molnar wrote:
>>
>>   
>>> * Jeremy Fitzhardinge <jeremy@goop.org> wrote:
>>>
>>>     
>>>> Hi Len,
>>>>
>>>> Have you seen these three patches?  Do they look OK to you?
>>>>
>>>> Yinghai Lu improve the third patch ("acpi: remove final 
>>>> __acpi_map_table mapping before setting acpi_gbl_permanent_mmap"), 
>>>> which I think Ingo sent you instead.
>>>>       
>>> Len,
>>>
>>> i asked about these patches before too - and if that's fine with you 
>>> we'd just queue them up in the x86 tree (like we did before the .28 
>>> merge window). Most of the impact will be on x86. So an Acked-by from 
>>> you would be fine to start this.
>>>     
>>
>> Sorry for the delay.
>> I recall reading your e-mail on this and thought I replied to it,
>> but for some reason I found neither your original message nor
>> my reply when I searched my archives today.
>>
>> But I did recall Ingo making a branch for this one, and so looking
>> at remotes/origin/acpi-for-len in ingo's tree...
>>
>> It isn't immediately clear to me what problem this patch series solves,
>> and thus it is hard to judge how important this is.
>>
>> It touches a lot of files, and it is going to run into a bunch of merge 
>> conflicts.
>>
>> I'm not thrilled that the first part of the series makes changes
>> which are then undone by the later part of the series --
>> that doesn't help w/ conflict resolution...
>>
>> The change to tbxface.c is an ACPICA API change.
>> It looks reasonable and it might be the right change,
>> but it is extra work -- we should sync with Bob
>> when he gets back from break.
>>
>> So, this one is sort of a headache, how important is it?
>>   
>
> Well, there's several aspects to this series:
>
> The important one from my perspective is using early_ioremap to map the 
> acpi memory, rather than using a private mapping function; this is 
> necessary when running under Xen, so that the right memory gets mapped.
>
> This in itself is pretty straightforward, but it raises a few issues.  
> One is that the acpi code doesn't properly unmap its mapped memory, but 
> relies on a "new mapping replaces old" semantic.  Putting a wrapper 
> around early_ioremap to emulate this is fairly straightforward, but it 
> does leave one trailing mapping, which causes early_ioremap to raise a 
> warning.
>
> I addressed this warning by putting in a hook to unmap the last mapping.  
> This was simple, but pretty hackish.  Yinghai went the extra distance by 
> making the acpi code properly pair map and unmap calls on all the 
> resources it needs, doing away with the "new map unmaps previous" 
> behaviour, and cleaning up the warning in the process.

yes, that end result is the desired state of things. We did run with this 
for several months and resolved all the cases that needed fixing, but 
dropped them when the ACPI tree moved out from under us.

Can resurrect it if Len feels OK about the concept. Len, you shouldnt 
worry about conflicts - we can do it after the ACPI changes of this merge 
window are upstream so there should be no conflict trouble at all. How 
does that sound?

	Ingo

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: state of some x86 acpi patches
  2009-01-02 15:39       ` Ingo Molnar
@ 2009-01-02 22:28         ` Len Brown
  2009-01-28 23:45         ` Jeremy Fitzhardinge
  1 sibling, 0 replies; 15+ messages in thread
From: Len Brown @ 2009-01-02 22:28 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: Jeremy Fitzhardinge, Yinghai Lu, linux-acpi

> yes, that end result is the desired state of things. We did run with this 
> for several months and resolved all the cases that needed fixing, but 
> dropped them when the ACPI tree moved out from under us.
> 
> Can resurrect it if Len feels OK about the concept. Len, you shouldnt 
> worry about conflicts - we can do it after the ACPI changes of this merge 
> window are upstream so there should be no conflict trouble at all. How 
> does that sound?

Sounds great!

thanks,
Len Brown, Intel Open Source Technology Center

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: state of some x86 acpi patches
  2009-01-02 15:39       ` Ingo Molnar
  2009-01-02 22:28         ` Len Brown
@ 2009-01-28 23:45         ` Jeremy Fitzhardinge
  2009-01-29  1:10           ` Yinghai Lu
  1 sibling, 1 reply; 15+ messages in thread
From: Jeremy Fitzhardinge @ 2009-01-28 23:45 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: Len Brown, Yinghai Lu, linux-acpi

Ingo Molnar wrote:
> yes, that end result is the desired state of things. We did run with this 
> for several months and resolved all the cases that needed fixing, but 
> dropped them when the ACPI tree moved out from under us.
>
> Can resurrect it if Len feels OK about the concept. Len, you shouldnt 
> worry about conflicts - we can do it after the ACPI changes of this merge 
> window are upstream so there should be no conflict trouble at all. How 
> does that sound?
>   

Doesn't look like these changes made it in this time.  Did they get 
overlooked, or did some other problem come up?  Or did you want me to 
dig them up?

Thanks,
    J

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: state of some x86 acpi patches
  2009-01-28 23:45         ` Jeremy Fitzhardinge
@ 2009-01-29  1:10           ` Yinghai Lu
  2009-02-07  2:58             ` Jeremy Fitzhardinge
  0 siblings, 1 reply; 15+ messages in thread
From: Yinghai Lu @ 2009-01-29  1:10 UTC (permalink / raw)
  To: Jeremy Fitzhardinge; +Cc: Ingo Molnar, Len Brown, linux-acpi

[-- Attachment #1: Type: text/plain, Size: 787 bytes --]

Jeremy Fitzhardinge wrote:
> Ingo Molnar wrote:
>> yes, that end result is the desired state of things. We did run with
>> this for several months and resolved all the cases that needed fixing,
>> but dropped them when the ACPI tree moved out from under us.
>>
>> Can resurrect it if Len feels OK about the concept. Len, you shouldnt
>> worry about conflicts - we can do it after the ACPI changes of this
>> merge window are upstream so there should be no conflict trouble at
>> all. How does that sound?
>>   
> 
> Doesn't look like these changes made it in this time.  Did they get
> overlooked, or did some other problem come up?  Or did you want me to
> dig them up?
> 
> Thanks,
>    J


please check attached that are updated to today tip/master with ingo's genapic patchset..

YH

[-- Attachment #2: acpi_use_early_ioremap_1.patch --]
[-- Type: text/x-patch, Size: 3921 bytes --]

commit ac77f220e5b99e8d7bfeae21516b4ac8736c266c
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sun Sep 7 15:21:18 2008 -0700

    x86: use early_ioremap in __acpi_map_table
    
    __acpi_map_table() effectively reimplements early_ioremap().  Rather
    than have that duplication, just implement it in terms of
    early_ioremap().
    
    However, unlike early_ioremap(), __acpi_map_table() just maintains a
    single mapping which gets replaced each call, and has no corresponding
    unmap function.  Implement this by just removing the previous mapping
    each time its called.  Unfortunately, this will leave a stray mapping
    at the end.
    
    Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

---
 arch/x86/include/asm/acpi.h      |    3 ---
 arch/x86/include/asm/fixmap_32.h |    4 ----
 arch/x86/include/asm/fixmap_64.h |    4 ----
 arch/x86/kernel/acpi/boot.c      |   29 ++++++++---------------------
 4 files changed, 8 insertions(+), 32 deletions(-)

Index: linux-2.6/arch/x86/kernel/acpi/boot.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/acpi/boot.c
+++ linux-2.6/arch/x86/kernel/acpi/boot.c
@@ -108,8 +108,8 @@ enum acpi_irq_model_id acpi_irq_model =
  */
 char *__init __acpi_map_table(unsigned long phys, unsigned long size)
 {
-	unsigned long base, offset, mapped_size;
-	int idx;
+	static char *prev_map;
+	static unsigned long prev_size;
 
 	if (!phys || !size)
 		return NULL;
@@ -117,26 +117,13 @@ char *__init __acpi_map_table(unsigned l
 	if (phys+size <= (max_low_pfn_mapped << PAGE_SHIFT))
 		return __va(phys);
 
-	offset = phys & (PAGE_SIZE - 1);
-	mapped_size = PAGE_SIZE - offset;
-	clear_fixmap(FIX_ACPI_END);
-	set_fixmap(FIX_ACPI_END, phys);
-	base = fix_to_virt(FIX_ACPI_END);
-
-	/*
-	 * Most cases can be covered by the below.
-	 */
-	idx = FIX_ACPI_END;
-	while (mapped_size < size) {
-		if (--idx < FIX_ACPI_BEGIN)
-			return NULL;	/* cannot handle this */
-		phys += PAGE_SIZE;
-		clear_fixmap(idx);
-		set_fixmap(idx, phys);
-		mapped_size += PAGE_SIZE;
-	}
+	if (prev_map)
+		early_iounmap(prev_map, prev_size);
 
-	return ((unsigned char *)base + offset);
+	prev_size = size;
+	prev_map = early_ioremap(phys, size);
+
+	return prev_map;
 }
 
 #ifdef CONFIG_PCI_MMCONFIG
Index: linux-2.6/arch/x86/include/asm/acpi.h
===================================================================
--- linux-2.6.orig/arch/x86/include/asm/acpi.h
+++ linux-2.6/arch/x86/include/asm/acpi.h
@@ -102,9 +102,6 @@ static inline void disable_acpi(void)
 	acpi_noirq = 1;
 }
 
-/* Fixmap pages to reserve for ACPI boot-time tables (see fixmap.h) */
-#define FIX_ACPI_PAGES 4
-
 extern int acpi_gsi_to_irq(u32 gsi, unsigned int *irq);
 
 static inline void acpi_noirq_set(void) { acpi_noirq = 1; }
Index: linux-2.6/arch/x86/include/asm/fixmap_32.h
===================================================================
--- linux-2.6.orig/arch/x86/include/asm/fixmap_32.h
+++ linux-2.6/arch/x86/include/asm/fixmap_32.h
@@ -95,10 +95,6 @@ enum fixed_addresses {
 			(__end_of_permanent_fixed_addresses & 255),
 	FIX_BTMAP_BEGIN = FIX_BTMAP_END + NR_FIX_BTMAPS*FIX_BTMAPS_SLOTS - 1,
 	FIX_WP_TEST,
-#ifdef CONFIG_ACPI
-	FIX_ACPI_BEGIN,
-	FIX_ACPI_END = FIX_ACPI_BEGIN + FIX_ACPI_PAGES - 1,
-#endif
 #ifdef CONFIG_PROVIDE_OHCI1394_DMA_INIT
 	FIX_OHCI1394_BASE,
 #endif
Index: linux-2.6/arch/x86/include/asm/fixmap_64.h
===================================================================
--- linux-2.6.orig/arch/x86/include/asm/fixmap_64.h
+++ linux-2.6/arch/x86/include/asm/fixmap_64.h
@@ -50,10 +50,6 @@ enum fixed_addresses {
 	FIX_PARAVIRT_BOOTMAP,
 #endif
 	__end_of_permanent_fixed_addresses,
-#ifdef CONFIG_ACPI
-	FIX_ACPI_BEGIN,
-	FIX_ACPI_END = FIX_ACPI_BEGIN + FIX_ACPI_PAGES - 1,
-#endif
 #ifdef CONFIG_PROVIDE_OHCI1394_DMA_INIT
 	FIX_OHCI1394_BASE,
 #endif

[-- Attachment #3: acpi_use_early_ioremap_2.patch --]
[-- Type: text/x-patch, Size: 1197 bytes --]

commit c95f866ed97595a48b3dcbb6d265d5f1ae37866e
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sun Sep 7 15:21:19 2008 -0700

    x86: always explicitly map acpi memory
    
    Always map acpi tables, rather than assuming we can use the normal
    linear mapping to access the acpi tables.  This is necessary in a
    virtual environment where the linear mappings are to pseudo-physical
    memory, but the acpi tables exist at a real physical address.  It
    doesn't hurt to map in the normal non-virtual case, so just do it
    unconditionally.
    
    Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

---
 arch/x86/kernel/acpi/boot.c |    3 ---
 1 file changed, 3 deletions(-)

Index: linux-2.6/arch/x86/kernel/acpi/boot.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/acpi/boot.c
+++ linux-2.6/arch/x86/kernel/acpi/boot.c
@@ -114,9 +114,6 @@ char *__init __acpi_map_table(unsigned l
 	if (!phys || !size)
 		return NULL;
 
-	if (phys+size <= (max_low_pfn_mapped << PAGE_SHIFT))
-		return __va(phys);
-
 	if (prev_map)
 		early_iounmap(prev_map, prev_size);
 

[-- Attachment #4: acpi_use_early_ioremap_3.patch --]
[-- Type: text/x-patch, Size: 2108 bytes --]

commit 5c48856148e7b02257a663f49128544814a07255
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Thu Sep 11 14:33:16 2008 -0700

    acpi: remove final __acpi_map_table mapping before setting acpi_gbl_permanent_mmap
    
    On x86, __acpi_map_table uses early_ioremap() to create the mapping,
    replacing the previous mapping with a new one.  Once enough of the
    kernel is up an running it switches to using normal ioremap().  At
    that point, we need to clean up the final mapping to avoid a warning
    from the early_ioremap subsystem.
    
    This can be removed after all the instances in the ACPI code are fixed
    that rely on early-ioremap's implicit overmapping of previously
    mapped tables.
    
    Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
    Cc: Andi Kleen <andi@firstfloor.org>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

---
 arch/x86/kernel/acpi/boot.c |    8 +++++---
 drivers/acpi/bus.c          |    6 ++++++
 2 files changed, 11 insertions(+), 3 deletions(-)

Index: linux-2.6/arch/x86/kernel/acpi/boot.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/acpi/boot.c
+++ linux-2.6/arch/x86/kernel/acpi/boot.c
@@ -111,12 +111,14 @@ char *__init __acpi_map_table(unsigned l
 	static char *prev_map;
 	static unsigned long prev_size;
 
+	if (prev_map) {
+		early_iounmap(prev_map, prev_size);
+		prev_map = NULL;
+	}
+
 	if (!phys || !size)
 		return NULL;
 
-	if (prev_map)
-		early_iounmap(prev_map, prev_size);
-
 	prev_size = size;
 	prev_map = early_ioremap(phys, size);
 
Index: linux-2.6/drivers/acpi/bus.c
===================================================================
--- linux-2.6.orig/drivers/acpi/bus.c
+++ linux-2.6/drivers/acpi/bus.c
@@ -694,6 +694,12 @@ void __init acpi_early_init(void)
 	if (!acpi_strict)
 		acpi_gbl_enable_interpreter_slack = TRUE;
 
+	/*
+	 * Doing a zero-sized mapping will clear out the previous
+	 * __acpi_map_table() mapping, if any.
+	 */
+	__acpi_map_table(0, 0);
+
 	acpi_gbl_permanent_mmap = 1;
 
 	status = acpi_reallocate_root_table();

[-- Attachment #5: acpi_use_early_ioremap_4.patch --]
[-- Type: text/x-patch, Size: 10015 bytes --]

commit 5560cb0d955aad89ea0001baa0da675dba97650b
Author: Yinghai Lu <yhlu.kernel@gmail.com>
Date:   Sun Sep 14 02:33:13 2008 -0700

    acpi/x86: introduce __apci_map_table, v4
    
    to prevent wrongly overwriting fixmap that still want to use.
    
    ACPI used to rely on low mappings being all linearly mapped and
    grew a habit: it never really unmapped certain kinds of tables
    after use.
    
    This can cause problems - for example the hypothetical case
    when some spurious access still references it.
    
    v2: remove prev_map and prev_size in __apci_map_table
    v3: let acpi_os_unmap_memory() call early_iounmap too, so remove extral calling to
    	early_acpi_os_unmap_memory
    v4: fix typo in one acpi_get_table_with_size calling
    
    Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

---
 arch/ia64/kernel/acpi.c       |    4 ++++
 arch/x86/kernel/acpi/boot.c   |   17 +++++++----------
 drivers/acpi/acpica/tbxface.c |   17 ++++++++++++++---
 drivers/acpi/bus.c            |    6 ------
 drivers/acpi/osl.c            |   11 +++++++++--
 drivers/acpi/tables.c         |   20 ++++++++++++++------
 include/acpi/acpiosxf.h       |    1 +
 include/acpi/acpixf.h         |    4 ++++
 include/linux/acpi.h          |    1 +
 9 files changed, 54 insertions(+), 27 deletions(-)

Index: linux-2.6/arch/ia64/kernel/acpi.c
===================================================================
--- linux-2.6.orig/arch/ia64/kernel/acpi.c
+++ linux-2.6/arch/ia64/kernel/acpi.c
@@ -199,6 +199,10 @@ char *__init __acpi_map_table(unsigned l
 	return __va(phys_addr);
 }
 
+char *__init __acpi_unmap_table(unsigned long virt_addr, unsigned long size)
+{
+}
+
 /* --------------------------------------------------------------------------
                             Boot-time Table Parsing
    -------------------------------------------------------------------------- */
Index: linux-2.6/arch/x86/kernel/acpi/boot.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/acpi/boot.c
+++ linux-2.6/arch/x86/kernel/acpi/boot.c
@@ -108,21 +108,18 @@ enum acpi_irq_model_id acpi_irq_model =
  */
 char *__init __acpi_map_table(unsigned long phys, unsigned long size)
 {
-	static char *prev_map;
-	static unsigned long prev_size;
-
-	if (prev_map) {
-		early_iounmap(prev_map, prev_size);
-		prev_map = NULL;
-	}
 
 	if (!phys || !size)
 		return NULL;
 
-	prev_size = size;
-	prev_map = early_ioremap(phys, size);
+	return early_ioremap(phys, size);
+}
+void __init __acpi_unmap_table(char *map, unsigned long size)
+{
+	if (!map || !size)
+		return;
 
-	return prev_map;
+	early_iounmap(map, size);
 }
 
 #ifdef CONFIG_PCI_MMCONFIG
Index: linux-2.6/drivers/acpi/bus.c
===================================================================
--- linux-2.6.orig/drivers/acpi/bus.c
+++ linux-2.6/drivers/acpi/bus.c
@@ -694,12 +694,6 @@ void __init acpi_early_init(void)
 	if (!acpi_strict)
 		acpi_gbl_enable_interpreter_slack = TRUE;
 
-	/*
-	 * Doing a zero-sized mapping will clear out the previous
-	 * __acpi_map_table() mapping, if any.
-	 */
-	__acpi_map_table(0, 0);
-
 	acpi_gbl_permanent_mmap = 1;
 
 	status = acpi_reallocate_root_table();
Index: linux-2.6/drivers/acpi/osl.c
===================================================================
--- linux-2.6.orig/drivers/acpi/osl.c
+++ linux-2.6/drivers/acpi/osl.c
@@ -274,12 +274,19 @@ EXPORT_SYMBOL_GPL(acpi_os_map_memory);
 
 void acpi_os_unmap_memory(void __iomem * virt, acpi_size size)
 {
-	if (acpi_gbl_permanent_mmap) {
+	if (acpi_gbl_permanent_mmap)
 		iounmap(virt);
-	}
+	else
+		__acpi_unmap_table(virt, size);
 }
 EXPORT_SYMBOL_GPL(acpi_os_unmap_memory);
 
+void early_acpi_os_unmap_memory(void __iomem * virt, acpi_size size)
+{
+	if (!acpi_gbl_permanent_mmap)
+		__acpi_unmap_table(virt, size);
+}
+
 #ifdef ACPI_FUTURE_USAGE
 acpi_status
 acpi_os_get_physical_address(void *virt, acpi_physical_address * phys)
Index: linux-2.6/drivers/acpi/tables.c
===================================================================
--- linux-2.6.orig/drivers/acpi/tables.c
+++ linux-2.6/drivers/acpi/tables.c
@@ -181,14 +181,15 @@ acpi_table_parse_entries(char *id,
 	struct acpi_subtable_header *entry;
 	unsigned int count = 0;
 	unsigned long table_end;
+	acpi_size tbl_size;
 
 	if (!handler)
 		return -EINVAL;
 
 	if (strncmp(id, ACPI_SIG_MADT, 4) == 0)
-		acpi_get_table(id, acpi_apic_instance, &table_header);
+		acpi_get_table_with_size(id, acpi_apic_instance, &table_header, &tbl_size);
 	else
-		acpi_get_table(id, 0, &table_header);
+		acpi_get_table_with_size(id, 0, &table_header, &tbl_size);
 
 	if (!table_header) {
 		printk(KERN_WARNING PREFIX "%4.4s not present\n", id);
@@ -206,8 +207,10 @@ acpi_table_parse_entries(char *id,
 	       table_end) {
 		if (entry->type == entry_id
 		    && (!max_entries || count++ < max_entries))
-			if (handler(entry, table_end))
+			if (handler(entry, table_end)) {
+				early_acpi_os_unmap_memory((char *)table_header, tbl_size);
 				return -EINVAL;
+			}
 
 		entry = (struct acpi_subtable_header *)
 		    ((unsigned long)entry + entry->length);
@@ -217,6 +220,7 @@ acpi_table_parse_entries(char *id,
 		       "%i found\n", id, entry_id, count - max_entries, count);
 	}
 
+	early_acpi_os_unmap_memory((char *)table_header, tbl_size);
 	return count;
 }
 
@@ -241,17 +245,19 @@ acpi_table_parse_madt(enum acpi_madt_typ
 int __init acpi_table_parse(char *id, acpi_table_handler handler)
 {
 	struct acpi_table_header *table = NULL;
+	acpi_size tbl_size;
 
 	if (!handler)
 		return -EINVAL;
 
 	if (strncmp(id, ACPI_SIG_MADT, 4) == 0)
-		acpi_get_table(id, acpi_apic_instance, &table);
+		acpi_get_table_with_size(id, acpi_apic_instance, &table, &tbl_size);
 	else
-		acpi_get_table(id, 0, &table);
+		acpi_get_table_with_size(id, 0, &table, &tbl_size);
 
 	if (table) {
 		handler(table);
+		early_acpi_os_unmap_memory(table, tbl_size);
 		return 0;
 	} else
 		return 1;
@@ -265,8 +271,9 @@ int __init acpi_table_parse(char *id, ac
 static void __init check_multiple_madt(void)
 {
 	struct acpi_table_header *table = NULL;
+	acpi_size tbl_size;
 
-	acpi_get_table(ACPI_SIG_MADT, 2, &table);
+	acpi_get_table_with_size(ACPI_SIG_MADT, 2, &table, &tbl_size);
 	if (table) {
 		printk(KERN_WARNING PREFIX
 		       "BIOS bug: multiple APIC/MADT found,"
@@ -275,6 +282,7 @@ static void __init check_multiple_madt(v
 		       "If \"acpi_apic_instance=%d\" works better, "
 		       "notify linux-acpi@vger.kernel.org\n",
 		       acpi_apic_instance ? 0 : 2);
+		early_acpi_os_unmap_memory(table, tbl_size);
 
 	} else
 		acpi_apic_instance = 0;
Index: linux-2.6/drivers/acpi/acpica/tbxface.c
===================================================================
--- linux-2.6.orig/drivers/acpi/acpica/tbxface.c
+++ linux-2.6/drivers/acpi/acpica/tbxface.c
@@ -365,7 +365,7 @@ ACPI_EXPORT_SYMBOL(acpi_unload_table_id)
 
 /*******************************************************************************
  *
- * FUNCTION:    acpi_get_table
+ * FUNCTION:    acpi_get_table_with_size
  *
  * PARAMETERS:  Signature           - ACPI signature of needed table
  *              Instance            - Which instance (for SSDTs)
@@ -377,8 +377,9 @@ ACPI_EXPORT_SYMBOL(acpi_unload_table_id)
  *
  *****************************************************************************/
 acpi_status
-acpi_get_table(char *signature,
-	       u32 instance, struct acpi_table_header **out_table)
+acpi_get_table_with_size(char *signature,
+	       u32 instance, struct acpi_table_header **out_table,
+	       acpi_size *tbl_size)
 {
        u32 i;
        u32 j;
@@ -408,6 +409,7 @@ acpi_get_table(char *signature,
 		    acpi_tb_verify_table(&acpi_gbl_root_table_list.tables[i]);
 		if (ACPI_SUCCESS(status)) {
 			*out_table = acpi_gbl_root_table_list.tables[i].pointer;
+			*tbl_size = acpi_gbl_root_table_list.tables[i].length;
 		}
 
 		if (!acpi_gbl_permanent_mmap) {
@@ -420,6 +422,15 @@ acpi_get_table(char *signature,
 	return (AE_NOT_FOUND);
 }
 
+acpi_status
+acpi_get_table(char *signature,
+	       u32 instance, struct acpi_table_header **out_table)
+{
+	acpi_size tbl_size;
+
+	return acpi_get_table_with_size(signature,
+		       instance, out_table, &tbl_size);
+}
 ACPI_EXPORT_SYMBOL(acpi_get_table)
 
 /*******************************************************************************
Index: linux-2.6/include/acpi/acpiosxf.h
===================================================================
--- linux-2.6.orig/include/acpi/acpiosxf.h
+++ linux-2.6/include/acpi/acpiosxf.h
@@ -144,6 +144,7 @@ void __iomem *acpi_os_map_memory(acpi_ph
 				acpi_size length);
 
 void acpi_os_unmap_memory(void __iomem * logical_address, acpi_size size);
+void early_acpi_os_unmap_memory(void __iomem * virt, acpi_size size);
 
 #ifdef ACPI_FUTURE_USAGE
 acpi_status
Index: linux-2.6/include/acpi/acpixf.h
===================================================================
--- linux-2.6.orig/include/acpi/acpixf.h
+++ linux-2.6/include/acpi/acpixf.h
@@ -130,6 +130,10 @@ acpi_get_table_header(acpi_string signat
 		      struct acpi_table_header *out_table_header);
 
 acpi_status
+acpi_get_table_with_size(acpi_string signature,
+	       u32 instance, struct acpi_table_header **out_table,
+	       acpi_size *tbl_size);
+acpi_status
 acpi_get_table(acpi_string signature,
 	       u32 instance, struct acpi_table_header **out_table);
 
Index: linux-2.6/include/linux/acpi.h
===================================================================
--- linux-2.6.orig/include/linux/acpi.h
+++ linux-2.6/include/linux/acpi.h
@@ -79,6 +79,7 @@ typedef int (*acpi_table_handler) (struc
 typedef int (*acpi_table_entry_handler) (struct acpi_subtable_header *header, const unsigned long end);
 
 char * __acpi_map_table (unsigned long phys_addr, unsigned long size);
+void __init __acpi_unmap_table(char *map, unsigned long size);
 int early_acpi_boot_init(void);
 int acpi_boot_init (void);
 int acpi_boot_table_init (void);

[-- Attachment #6: revert_fix_es7000_compiling.patch --]
[-- Type: text/x-patch, Size: 1158 bytes --]

---
 arch/x86/kernel/es7000_32.c |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

Index: linux-2.6/arch/x86/kernel/es7000_32.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/es7000_32.c
+++ linux-2.6/arch/x86/kernel/es7000_32.c
@@ -287,24 +287,31 @@ int __init find_unisys_acpi_oem_table(un
 {
 	struct acpi_table_header *header = NULL;
 	int i = 0;
+	acpi_size tbl_size;
 
-	while (ACPI_SUCCESS(acpi_get_table("OEM1", i++, &header))) {
+	while (ACPI_SUCCESS(acpi_get_table_with_size("OEM1", i++, &header, &tbl_size))) {
 		if (!memcmp((char *) &header->oem_id, "UNISYS", 6)) {
 			struct oem_table *t = (struct oem_table *)header;
 
 			oem_addrX = t->OEMTableAddr;
 			oem_size = t->OEMTableSize;
+			early_acpi_os_unmap_memory(header, tbl_size);
 
 			*oem_addr = (unsigned long)__acpi_map_table(oem_addrX,
 								    oem_size);
 			return 0;
 		}
+		early_acpi_os_unmap_memory(header, tbl_size);
 	}
 	return -1;
 }
 
 void __init unmap_unisys_acpi_oem_table(unsigned long oem_addr)
 {
+	if (!oem_addr)
+		return;
+
+	__acpi_unmap_table((char *)oem_addr, oem_size);
 }
 #endif
 

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: state of some x86 acpi patches
  2009-01-29  1:10           ` Yinghai Lu
@ 2009-02-07  2:58             ` Jeremy Fitzhardinge
  2009-02-07  3:18               ` Yinghai Lu
  0 siblings, 1 reply; 15+ messages in thread
From: Jeremy Fitzhardinge @ 2009-02-07  2:58 UTC (permalink / raw)
  To: Yinghai Lu; +Cc: Ingo Molnar, Len Brown, linux-acpi

Yinghai Lu wrote:
> Jeremy Fitzhardinge wrote:
>   
>> Ingo Molnar wrote:
>>     
>>> yes, that end result is the desired state of things. We did run with
>>> this for several months and resolved all the cases that needed fixing,
>>> but dropped them when the ACPI tree moved out from under us.
>>>
>>> Can resurrect it if Len feels OK about the concept. Len, you shouldnt
>>> worry about conflicts - we can do it after the ACPI changes of this
>>> merge window are upstream so there should be no conflict trouble at
>>> all. How does that sound?
>>>   
>>>       
>> Doesn't look like these changes made it in this time.  Did they get
>> overlooked, or did some other problem come up?  Or did you want me to
>> dig them up?
>>
>> Thanks,
>>    J
>>     
>
>
> please check attached that are updated to today tip/master with ingo's genapic patchset..
>   

The look OK, but they didn't get merged into tip/master?

    J

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: state of some x86 acpi patches
  2009-02-07  2:58             ` Jeremy Fitzhardinge
@ 2009-02-07  3:18               ` Yinghai Lu
  2009-02-08  0:09                 ` Jeremy Fitzhardinge
  0 siblings, 1 reply; 15+ messages in thread
From: Yinghai Lu @ 2009-02-07  3:18 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Jeremy Fitzhardinge, Len Brown, linux-acpi,
	linux-kernel@vger.kernel.org

Jeremy Fitzhardinge wrote:
> Yinghai Lu wrote:
>> Jeremy Fitzhardinge wrote:
>>  
>>> Ingo Molnar wrote:
>>>    
>>>> yes, that end result is the desired state of things. We did run with
>>>> this for several months and resolved all the cases that needed fixing,
>>>> but dropped them when the ACPI tree moved out from under us.
>>>>
>>>> Can resurrect it if Len feels OK about the concept. Len, you shouldnt
>>>> worry about conflicts - we can do it after the ACPI changes of this
>>>> merge window are upstream so there should be no conflict trouble at
>>>> all. How does that sound?
>>>>         
>>> Doesn't look like these changes made it in this time.  Did they get
>>> overlooked, or did some other problem come up?  Or did you want me to
>>> dig them up?
>>>
>>> Thanks,
>>>    J
>>>     
>>
>>
>> please check attached that are updated to today tip/master with ingo's
>> genapic patchset..
>>   
> 
> The look OK, but they didn't get merged into tip/master?
> 
Ingo is too busy...
It seems Len already agreed those patches can go through tip.

Ingo?

YH

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: state of some x86 acpi patches
  2009-02-07  3:18               ` Yinghai Lu
@ 2009-02-08  0:09                 ` Jeremy Fitzhardinge
  2009-02-09 12:37                   ` Ingo Molnar
  0 siblings, 1 reply; 15+ messages in thread
From: Jeremy Fitzhardinge @ 2009-02-08  0:09 UTC (permalink / raw)
  To: Yinghai Lu
  Cc: Ingo Molnar, Len Brown, linux-acpi, linux-kernel@vger.kernel.org

Yinghai Lu wrote:
> Ingo is too busy...
> It seems Len already agreed those patches can go through tip.
>   

OK, I have them prepared as a branch off tip/git pullable from:

The following changes since commit 82eda818f26cbef2b0a6bf6580e52645af62e4fd:
  Ingo Molnar (1):
        Merge branch 'core/locking'

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git acpi/map

Jeremy Fitzhardinge (3):
      x86: use early_ioremap in __acpi_map_table
      x86: always explicitly map acpi memory
      acpi: remove final __acpi_map_table mapping before setting acpi_gbl_permanent_mmap

Yinghai Lu (2):
      acpi/x86: introduce __apci_map_table, v4
      revert_fix_es7000_compiling

 arch/ia64/kernel/acpi.c          |    4 ++++
 arch/x86/include/asm/acpi.h      |    3 ---
 arch/x86/include/asm/fixmap_32.h |    4 ----
 arch/x86/include/asm/fixmap_64.h |    4 ----
 arch/x86/kernel/acpi/boot.c      |   33 ++++++++-------------------------
 arch/x86/kernel/es7000_32.c      |    9 ++++++++-
 drivers/acpi/acpica/tbxface.c    |   17 ++++++++++++++---
 drivers/acpi/osl.c               |   11 +++++++++--
 drivers/acpi/tables.c            |   20 ++++++++++++++------
 include/acpi/acpiosxf.h          |    1 +
 include/acpi/acpixf.h            |    4 ++++
 include/linux/acpi.h             |    1 +
 12 files changed, 63 insertions(+), 48 deletions(-)

	J

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: state of some x86 acpi patches
  2009-02-08  0:09                 ` Jeremy Fitzhardinge
@ 2009-02-09 12:37                   ` Ingo Molnar
  0 siblings, 0 replies; 15+ messages in thread
From: Ingo Molnar @ 2009-02-09 12:37 UTC (permalink / raw)
  To: Jeremy Fitzhardinge, Len Brown
  Cc: Yinghai Lu, linux-acpi, linux-kernel@vger.kernel.org


* Jeremy Fitzhardinge <jeremy@goop.org> wrote:

> Yinghai Lu wrote:
>> Ingo is too busy...
>> It seems Len already agreed those patches can go through tip.
>>   
>
> OK, I have them prepared as a branch off tip/git pullable from:
>
> The following changes since commit 82eda818f26cbef2b0a6bf6580e52645af62e4fd:
>  Ingo Molnar (1):
>        Merge branch 'core/locking'
>
> are available in the git repository at:
>
>  git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git acpi/map
>
> Jeremy Fitzhardinge (3):
>      x86: use early_ioremap in __acpi_map_table
>      x86: always explicitly map acpi memory
>      acpi: remove final __acpi_map_table mapping before setting acpi_gbl_permanent_mmap
>
> Yinghai Lu (2):
>      acpi/x86: introduce __apci_map_table, v4
>      revert_fix_es7000_compiling
>
> arch/ia64/kernel/acpi.c          |    4 ++++
> arch/x86/include/asm/acpi.h      |    3 ---
> arch/x86/include/asm/fixmap_32.h |    4 ----
> arch/x86/include/asm/fixmap_64.h |    4 ----
> arch/x86/kernel/acpi/boot.c      |   33 ++++++++-------------------------
> arch/x86/kernel/es7000_32.c      |    9 ++++++++-
> drivers/acpi/acpica/tbxface.c    |   17 ++++++++++++++---
> drivers/acpi/osl.c               |   11 +++++++++--
> drivers/acpi/tables.c            |   20 ++++++++++++++------
> include/acpi/acpiosxf.h          |    1 +
> include/acpi/acpixf.h            |    4 ++++
> include/linux/acpi.h             |    1 +
> 12 files changed, 63 insertions(+), 48 deletions(-)

Ok, pulled into tip:x86/acpi, thanks guys!

Len: i've added your Ack to the ACPI commits.

	Ingo

---------------------->
commit b825e6cc7b1401862531df497a4a4daff8102ed5
Author: Yinghai Lu <yhlu.kernel@gmail.com>
Date:   Sat Feb 7 15:39:41 2009 -0800

    x86, es7000: fix ACPI table mappings
    
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

diff --git a/arch/x86/kernel/es7000_32.c b/arch/x86/kernel/es7000_32.c
index 53699c9..71d7be6 100644
--- a/arch/x86/kernel/es7000_32.c
+++ b/arch/x86/kernel/es7000_32.c
@@ -292,24 +292,31 @@ int __init find_unisys_acpi_oem_table(unsigned long *oem_addr)
 {
 	struct acpi_table_header *header = NULL;
 	int i = 0;
+	acpi_size tbl_size;
 
-	while (ACPI_SUCCESS(acpi_get_table("OEM1", i++, &header))) {
+	while (ACPI_SUCCESS(acpi_get_table_with_size("OEM1", i++, &header, &tbl_size))) {
 		if (!memcmp((char *) &header->oem_id, "UNISYS", 6)) {
 			struct oem_table *t = (struct oem_table *)header;
 
 			oem_addrX = t->OEMTableAddr;
 			oem_size = t->OEMTableSize;
+			early_acpi_os_unmap_memory(header, tbl_size);
 
 			*oem_addr = (unsigned long)__acpi_map_table(oem_addrX,
 								    oem_size);
 			return 0;
 		}
+		early_acpi_os_unmap_memory(header, tbl_size);
 	}
 	return -1;
 }
 
 void __init unmap_unisys_acpi_oem_table(unsigned long oem_addr)
 {
+	if (!oem_addr)
+		return;
+
+	__acpi_unmap_table((char *)oem_addr, oem_size);
 }
 #endif
 

commit 7d97277b754d3ee098a5ec69b6aaafb00c94e2f2
Author: Yinghai Lu <yhlu.kernel@gmail.com>
Date:   Sat Feb 7 15:39:41 2009 -0800

    acpi/x86: introduce __apci_map_table, v4
    
    to prevent wrongly overwriting fixmap that still want to use.
    
    ACPI used to rely on low mappings being all linearly mapped and
    grew a habit: it never really unmapped certain kinds of tables
    after use.
    
    This can cause problems - for example the hypothetical case
    when some spurious access still references it.
    
    v2: remove prev_map and prev_size in __apci_map_table
    v3: let acpi_os_unmap_memory() call early_iounmap too, so remove extral calling to
    early_acpi_os_unmap_memory
    v4: fix typo in one acpi_get_table_with_size calling
    
    Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
    Acked-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

diff --git a/arch/ia64/kernel/acpi.c b/arch/ia64/kernel/acpi.c
index d541671..2363ed1 100644
--- a/arch/ia64/kernel/acpi.c
+++ b/arch/ia64/kernel/acpi.c
@@ -199,6 +199,10 @@ char *__init __acpi_map_table(unsigned long phys_addr, unsigned long size)
 	return __va(phys_addr);
 }
 
+char *__init __acpi_unmap_table(unsigned long virt_addr, unsigned long size)
+{
+}
+
 /* --------------------------------------------------------------------------
                             Boot-time Table Parsing
    -------------------------------------------------------------------------- */
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 7217834..4c2aaea 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -121,21 +121,18 @@ enum acpi_irq_model_id acpi_irq_model = ACPI_IRQ_MODEL_PIC;
  */
 char *__init __acpi_map_table(unsigned long phys, unsigned long size)
 {
-	static char *prev_map;
-	static unsigned long prev_size;
-
-	if (prev_map) {
-		early_iounmap(prev_map, prev_size);
-		prev_map = NULL;
-	}
 
 	if (!phys || !size)
 		return NULL;
 
-	prev_size = size;
-	prev_map = early_ioremap(phys, size);
+	return early_ioremap(phys, size);
+}
+void __init __acpi_unmap_table(char *map, unsigned long size)
+{
+	if (!map || !size)
+		return;
 
-	return prev_map;
+	early_iounmap(map, size);
 }
 
 #ifdef CONFIG_PCI_MMCONFIG
diff --git a/drivers/acpi/acpica/tbxface.c b/drivers/acpi/acpica/tbxface.c
index c3e841f..ab0aff3 100644
--- a/drivers/acpi/acpica/tbxface.c
+++ b/drivers/acpi/acpica/tbxface.c
@@ -365,7 +365,7 @@ ACPI_EXPORT_SYMBOL(acpi_unload_table_id)
 
 /*******************************************************************************
  *
- * FUNCTION:    acpi_get_table
+ * FUNCTION:    acpi_get_table_with_size
  *
  * PARAMETERS:  Signature           - ACPI signature of needed table
  *              Instance            - Which instance (for SSDTs)
@@ -377,8 +377,9 @@ ACPI_EXPORT_SYMBOL(acpi_unload_table_id)
  *
  *****************************************************************************/
 acpi_status
-acpi_get_table(char *signature,
-	       u32 instance, struct acpi_table_header **out_table)
+acpi_get_table_with_size(char *signature,
+	       u32 instance, struct acpi_table_header **out_table,
+	       acpi_size *tbl_size)
 {
        u32 i;
        u32 j;
@@ -408,6 +409,7 @@ acpi_get_table(char *signature,
 		    acpi_tb_verify_table(&acpi_gbl_root_table_list.tables[i]);
 		if (ACPI_SUCCESS(status)) {
 			*out_table = acpi_gbl_root_table_list.tables[i].pointer;
+			*tbl_size = acpi_gbl_root_table_list.tables[i].length;
 		}
 
 		if (!acpi_gbl_permanent_mmap) {
@@ -420,6 +422,15 @@ acpi_get_table(char *signature,
 	return (AE_NOT_FOUND);
 }
 
+acpi_status
+acpi_get_table(char *signature,
+	       u32 instance, struct acpi_table_header **out_table)
+{
+	acpi_size tbl_size;
+
+	return acpi_get_table_with_size(signature,
+		       instance, out_table, &tbl_size);
+}
 ACPI_EXPORT_SYMBOL(acpi_get_table)
 
 /*******************************************************************************
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index fb1be7b..765fd1c 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -694,12 +694,6 @@ void __init acpi_early_init(void)
 	if (!acpi_strict)
 		acpi_gbl_enable_interpreter_slack = TRUE;
 
-	/*
-	 * Doing a zero-sized mapping will clear out the previous
-	 * __acpi_map_table() mapping, if any.
-	 */
-	__acpi_map_table(0, 0);
-
 	acpi_gbl_permanent_mmap = 1;
 
 	status = acpi_reallocate_root_table();
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index b3193ec..d1dd516 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -274,12 +274,19 @@ EXPORT_SYMBOL_GPL(acpi_os_map_memory);
 
 void acpi_os_unmap_memory(void __iomem * virt, acpi_size size)
 {
-	if (acpi_gbl_permanent_mmap) {
+	if (acpi_gbl_permanent_mmap)
 		iounmap(virt);
-	}
+	else
+		__acpi_unmap_table(virt, size);
 }
 EXPORT_SYMBOL_GPL(acpi_os_unmap_memory);
 
+void early_acpi_os_unmap_memory(void __iomem * virt, acpi_size size)
+{
+	if (!acpi_gbl_permanent_mmap)
+		__acpi_unmap_table(virt, size);
+}
+
 #ifdef ACPI_FUTURE_USAGE
 acpi_status
 acpi_os_get_physical_address(void *virt, acpi_physical_address * phys)
diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
index a885295..fec1ae3 100644
--- a/drivers/acpi/tables.c
+++ b/drivers/acpi/tables.c
@@ -181,14 +181,15 @@ acpi_table_parse_entries(char *id,
 	struct acpi_subtable_header *entry;
 	unsigned int count = 0;
 	unsigned long table_end;
+	acpi_size tbl_size;
 
 	if (!handler)
 		return -EINVAL;
 
 	if (strncmp(id, ACPI_SIG_MADT, 4) == 0)
-		acpi_get_table(id, acpi_apic_instance, &table_header);
+		acpi_get_table_with_size(id, acpi_apic_instance, &table_header, &tbl_size);
 	else
-		acpi_get_table(id, 0, &table_header);
+		acpi_get_table_with_size(id, 0, &table_header, &tbl_size);
 
 	if (!table_header) {
 		printk(KERN_WARNING PREFIX "%4.4s not present\n", id);
@@ -206,8 +207,10 @@ acpi_table_parse_entries(char *id,
 	       table_end) {
 		if (entry->type == entry_id
 		    && (!max_entries || count++ < max_entries))
-			if (handler(entry, table_end))
+			if (handler(entry, table_end)) {
+				early_acpi_os_unmap_memory((char *)table_header, tbl_size);
 				return -EINVAL;
+			}
 
 		entry = (struct acpi_subtable_header *)
 		    ((unsigned long)entry + entry->length);
@@ -217,6 +220,7 @@ acpi_table_parse_entries(char *id,
 		       "%i found\n", id, entry_id, count - max_entries, count);
 	}
 
+	early_acpi_os_unmap_memory((char *)table_header, tbl_size);
 	return count;
 }
 
@@ -241,17 +245,19 @@ acpi_table_parse_madt(enum acpi_madt_type id,
 int __init acpi_table_parse(char *id, acpi_table_handler handler)
 {
 	struct acpi_table_header *table = NULL;
+	acpi_size tbl_size;
 
 	if (!handler)
 		return -EINVAL;
 
 	if (strncmp(id, ACPI_SIG_MADT, 4) == 0)
-		acpi_get_table(id, acpi_apic_instance, &table);
+		acpi_get_table_with_size(id, acpi_apic_instance, &table, &tbl_size);
 	else
-		acpi_get_table(id, 0, &table);
+		acpi_get_table_with_size(id, 0, &table, &tbl_size);
 
 	if (table) {
 		handler(table);
+		early_acpi_os_unmap_memory(table, tbl_size);
 		return 0;
 	} else
 		return 1;
@@ -265,8 +271,9 @@ int __init acpi_table_parse(char *id, acpi_table_handler handler)
 static void __init check_multiple_madt(void)
 {
 	struct acpi_table_header *table = NULL;
+	acpi_size tbl_size;
 
-	acpi_get_table(ACPI_SIG_MADT, 2, &table);
+	acpi_get_table_with_size(ACPI_SIG_MADT, 2, &table, &tbl_size);
 	if (table) {
 		printk(KERN_WARNING PREFIX
 		       "BIOS bug: multiple APIC/MADT found,"
@@ -275,6 +282,7 @@ static void __init check_multiple_madt(void)
 		       "If \"acpi_apic_instance=%d\" works better, "
 		       "notify linux-acpi@vger.kernel.org\n",
 		       acpi_apic_instance ? 0 : 2);
+		early_acpi_os_unmap_memory(table, tbl_size);
 
 	} else
 		acpi_apic_instance = 0;
diff --git a/include/acpi/acpiosxf.h b/include/acpi/acpiosxf.h
index a62720a..ab0b85c 100644
--- a/include/acpi/acpiosxf.h
+++ b/include/acpi/acpiosxf.h
@@ -144,6 +144,7 @@ void __iomem *acpi_os_map_memory(acpi_physical_address where,
 				acpi_size length);
 
 void acpi_os_unmap_memory(void __iomem * logical_address, acpi_size size);
+void early_acpi_os_unmap_memory(void __iomem * virt, acpi_size size);
 
 #ifdef ACPI_FUTURE_USAGE
 acpi_status
diff --git a/include/acpi/acpixf.h b/include/acpi/acpixf.h
index c8e8cf4..cc40102 100644
--- a/include/acpi/acpixf.h
+++ b/include/acpi/acpixf.h
@@ -130,6 +130,10 @@ acpi_get_table_header(acpi_string signature,
 		      struct acpi_table_header *out_table_header);
 
 acpi_status
+acpi_get_table_with_size(acpi_string signature,
+	       u32 instance, struct acpi_table_header **out_table,
+	       acpi_size *tbl_size);
+acpi_status
 acpi_get_table(acpi_string signature,
 	       u32 instance, struct acpi_table_header **out_table);
 
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 6fce2fc..d59f0fa 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -79,6 +79,7 @@ typedef int (*acpi_table_handler) (struct acpi_table_header *table);
 typedef int (*acpi_table_entry_handler) (struct acpi_subtable_header *header, const unsigned long end);
 
 char * __acpi_map_table (unsigned long phys_addr, unsigned long size);
+void __init __acpi_unmap_table(char *map, unsigned long size);
 int early_acpi_boot_init(void);
 int acpi_boot_init (void);
 int acpi_boot_table_init (void);

commit 05876f88ed9a66b26af613e222795ae790616252
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 7 15:39:40 2009 -0800

    acpi: remove final __acpi_map_table mapping before setting acpi_gbl_permanent_mmap
    
    On x86, __acpi_map_table uses early_ioremap() to create the mapping,
    replacing the previous mapping with a new one.  Once enough of the
    kernel is up an running it switches to using normal ioremap().  At
    that point, we need to clean up the final mapping to avoid a warning
    from the early_ioremap subsystem.
    
    This can be removed after all the instances in the ACPI code are fixed
    that rely on early-ioremap's implicit overmapping of previously
    mapped tables.
    
    Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
    Acked-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 5424a18..7217834 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -124,12 +124,14 @@ char *__init __acpi_map_table(unsigned long phys, unsigned long size)
 	static char *prev_map;
 	static unsigned long prev_size;
 
+	if (prev_map) {
+		early_iounmap(prev_map, prev_size);
+		prev_map = NULL;
+	}
+
 	if (!phys || !size)
 		return NULL;
 
-	if (prev_map)
-		early_iounmap(prev_map, prev_size);
-
 	prev_size = size;
 	prev_map = early_ioremap(phys, size);
 
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 765fd1c..fb1be7b 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -694,6 +694,12 @@ void __init acpi_early_init(void)
 	if (!acpi_strict)
 		acpi_gbl_enable_interpreter_slack = TRUE;
 
+	/*
+	 * Doing a zero-sized mapping will clear out the previous
+	 * __acpi_map_table() mapping, if any.
+	 */
+	__acpi_map_table(0, 0);
+
 	acpi_gbl_permanent_mmap = 1;
 
 	status = acpi_reallocate_root_table();

commit eecb9a697f0b790e5840dae8a8b866bea49a86ee
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 7 15:39:38 2009 -0800

    x86: always explicitly map acpi memory
    
    Always map acpi tables, rather than assuming we can use the normal
    linear mapping to access the acpi tables.  This is necessary in a
    virtual environment where the linear mappings are to pseudo-physical
    memory, but the acpi tables exist at a real physical address.  It
    doesn't hurt to map in the normal non-virtual case, so just do it
    unconditionally.
    
    Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
    Acked-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index c518599..5424a18 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -127,9 +127,6 @@ char *__init __acpi_map_table(unsigned long phys, unsigned long size)
 	if (!phys || !size)
 		return NULL;
 
-	if (phys+size <= (max_low_pfn_mapped << PAGE_SHIFT))
-		return __va(phys);
-
 	if (prev_map)
 		early_iounmap(prev_map, prev_size);
 

commit 1c14fa4937eb73509e07ac12bf8db1fdf4c42a59
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 7 15:39:38 2009 -0800

    x86: use early_ioremap in __acpi_map_table
    
    __acpi_map_table() effectively reimplements early_ioremap().  Rather
    than have that duplication, just implement it in terms of
    early_ioremap().
    
    However, unlike early_ioremap(), __acpi_map_table() just maintains a
    single mapping which gets replaced each call, and has no corresponding
    unmap function.  Implement this by just removing the previous mapping
    each time its called.  Unfortunately, this will leave a stray mapping
    at the end.
    
    Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h
index 9830681..4518dc5 100644
--- a/arch/x86/include/asm/acpi.h
+++ b/arch/x86/include/asm/acpi.h
@@ -102,9 +102,6 @@ static inline void disable_acpi(void)
 	acpi_noirq = 1;
 }
 
-/* Fixmap pages to reserve for ACPI boot-time tables (see fixmap.h) */
-#define FIX_ACPI_PAGES 4
-
 extern int acpi_gsi_to_irq(u32 gsi, unsigned int *irq);
 
 static inline void acpi_noirq_set(void) { acpi_noirq = 1; }
diff --git a/arch/x86/include/asm/fixmap_32.h b/arch/x86/include/asm/fixmap_32.h
index c7115c1..047d9ba 100644
--- a/arch/x86/include/asm/fixmap_32.h
+++ b/arch/x86/include/asm/fixmap_32.h
@@ -95,10 +95,6 @@ enum fixed_addresses {
 			(__end_of_permanent_fixed_addresses & 255),
 	FIX_BTMAP_BEGIN = FIX_BTMAP_END + NR_FIX_BTMAPS*FIX_BTMAPS_SLOTS - 1,
 	FIX_WP_TEST,
-#ifdef CONFIG_ACPI
-	FIX_ACPI_BEGIN,
-	FIX_ACPI_END = FIX_ACPI_BEGIN + FIX_ACPI_PAGES - 1,
-#endif
 #ifdef CONFIG_PROVIDE_OHCI1394_DMA_INIT
 	FIX_OHCI1394_BASE,
 #endif
diff --git a/arch/x86/include/asm/fixmap_64.h b/arch/x86/include/asm/fixmap_64.h
index 00a30ab..298d9ba 100644
--- a/arch/x86/include/asm/fixmap_64.h
+++ b/arch/x86/include/asm/fixmap_64.h
@@ -50,10 +50,6 @@ enum fixed_addresses {
 	FIX_PARAVIRT_BOOTMAP,
 #endif
 	__end_of_permanent_fixed_addresses,
-#ifdef CONFIG_ACPI
-	FIX_ACPI_BEGIN,
-	FIX_ACPI_END = FIX_ACPI_BEGIN + FIX_ACPI_PAGES - 1,
-#endif
 #ifdef CONFIG_PROVIDE_OHCI1394_DMA_INIT
 	FIX_OHCI1394_BASE,
 #endif
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index d37593c..c518599 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -121,8 +121,8 @@ enum acpi_irq_model_id acpi_irq_model = ACPI_IRQ_MODEL_PIC;
  */
 char *__init __acpi_map_table(unsigned long phys, unsigned long size)
 {
-	unsigned long base, offset, mapped_size;
-	int idx;
+	static char *prev_map;
+	static unsigned long prev_size;
 
 	if (!phys || !size)
 		return NULL;
@@ -130,26 +130,13 @@ char *__init __acpi_map_table(unsigned long phys, unsigned long size)
 	if (phys+size <= (max_low_pfn_mapped << PAGE_SHIFT))
 		return __va(phys);
 
-	offset = phys & (PAGE_SIZE - 1);
-	mapped_size = PAGE_SIZE - offset;
-	clear_fixmap(FIX_ACPI_END);
-	set_fixmap(FIX_ACPI_END, phys);
-	base = fix_to_virt(FIX_ACPI_END);
+	if (prev_map)
+		early_iounmap(prev_map, prev_size);
 
-	/*
-	 * Most cases can be covered by the below.
-	 */
-	idx = FIX_ACPI_END;
-	while (mapped_size < size) {
-		if (--idx < FIX_ACPI_BEGIN)
-			return NULL;	/* cannot handle this */
-		phys += PAGE_SIZE;
-		clear_fixmap(idx);
-		set_fixmap(idx, phys);
-		mapped_size += PAGE_SIZE;
-	}
+	prev_size = size;
+	prev_map = early_ioremap(phys, size);
 
-	return ((unsigned char *)base + offset);
+	return prev_map;
 }
 
 #ifdef CONFIG_PCI_MMCONFIG

^ permalink raw reply related	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2009-02-09 12:37 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-12-16 19:19 state of some x86 acpi patches Jeremy Fitzhardinge
2008-12-16 19:25 ` Ingo Molnar
2008-12-31 23:38   ` Len Brown
2009-01-01  6:49     ` Jeremy Fitzhardinge
2009-01-02 15:39       ` Ingo Molnar
2009-01-02 22:28         ` Len Brown
2009-01-28 23:45         ` Jeremy Fitzhardinge
2009-01-29  1:10           ` Yinghai Lu
2009-02-07  2:58             ` Jeremy Fitzhardinge
2009-02-07  3:18               ` Yinghai Lu
2009-02-08  0:09                 ` Jeremy Fitzhardinge
2009-02-09 12:37                   ` Ingo Molnar
2008-12-18 13:44 ` Andi Kleen
2008-12-18 19:46   ` Jeremy Fitzhardinge
2008-12-18 21:47     ` Ingo Molnar

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox