public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH/RFC] ACPICA: disable ACPI 2.0 _GTS/_BFS support
@ 2008-12-19  9:23 Len Brown
  2008-12-19 16:39 ` Bjorn Helgaas
                   ` (2 more replies)
  0 siblings, 3 replies; 5+ messages in thread
From: Len Brown @ 2008-12-19  9:23 UTC (permalink / raw)
  To: linux-acpi

From: Len Brown <len.brown@intel.com>
Organization: Intel Open Source Technology Center

ACPI 2.0 defined two new methods in the suspend/resume sequence,
_GTS (Going to Sleep) and _BFS (Back from Sleep)

They are optional methods, but if the BIOS supplies them,
the OS is supposed to evaluate them immediately before
writing the register to sleep, and immediately after waking up --
a time when interrupts are disabled.

The spec says that they must be self-contained
methods, not calling any other methods, perhaps
because that they are run under unique conditions?

These methodds are evaluated in Linux by
acpi_evaluate_object(), which always kmalloc's
a return structure to conserve stack space.
But kmalloc with interrupts off is problematic --
do we really want to insist on GFP_ATOMIC here?

Now, several years after ACPI 2.0 was released,
we have yet to observe a single implementation of
_GTS/_BFS in the field -- suggesting that they will
never actually be deployed.

So lets keep Linux simple by removing this
theoretical support for _GTS/_BFS, the only
AML methods that mandated being evaluated
with interrupts disabled.

Signed-off-by: Len Brown <len.brown@intel.com>
---
 drivers/acpi/hardware/hwsleep.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/acpi/hardware/hwsleep.c b/drivers/acpi/hardware/hwsleep.c
index 25dccdf..c209434 100644
--- a/drivers/acpi/hardware/hwsleep.c
+++ b/drivers/acpi/hardware/hwsleep.c
@@ -289,6 +289,7 @@ acpi_status asmlinkage acpi_enter_sleep_state(u8 sleep_state)
 		return_ACPI_STATUS(status);
 	}
 
+#ifdef	ACPI_20_GTS_BFS
 	/* Execute the _GTS method */
 
 	arg_list.count = 1;
@@ -300,6 +301,7 @@ acpi_status asmlinkage acpi_enter_sleep_state(u8 sleep_state)
 	if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {
 		return_ACPI_STATUS(status);
 	}
+#endif
 
 	/* Get current value of PM1A control */
 
@@ -535,6 +537,7 @@ acpi_status acpi_leave_sleep_state_prep(u8 sleep_state)
 		}
 	}
 
+#ifdef	ACPI_20_GTS_BFS
 	/* Execute the _BFS method */
 
 	arg_list.count = 1;
@@ -546,6 +549,7 @@ acpi_status acpi_leave_sleep_state_prep(u8 sleep_state)
 	if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {
 		ACPI_EXCEPTION((AE_INFO, status, "During Method _BFS"));
 	}
+#endif
 
 	return_ACPI_STATUS(status);
 }
-- 
1.6.1.rc3.35.gc0ceb


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

* Re: [PATCH/RFC] ACPICA: disable ACPI 2.0 _GTS/_BFS support
  2008-12-19  9:23 [PATCH/RFC] ACPICA: disable ACPI 2.0 _GTS/_BFS support Len Brown
@ 2008-12-19 16:39 ` Bjorn Helgaas
  2008-12-31  0:16   ` Len Brown
  2008-12-19 17:48 ` Rafael J. Wysocki
  2008-12-22  1:42 ` Zhao Yakui
  2 siblings, 1 reply; 5+ messages in thread
From: Bjorn Helgaas @ 2008-12-19 16:39 UTC (permalink / raw)
  To: Len Brown; +Cc: linux-acpi

On Friday 19 December 2008 02:23:49 am Len Brown wrote:
> ACPI 2.0 defined two new methods in the suspend/resume sequence,
> _GTS (Going to Sleep) and _BFS (Back from Sleep)
> 
> They are optional methods, but if the BIOS supplies them,
> the OS is supposed to evaluate them immediately before
> writing the register to sleep, and immediately after waking up --
> a time when interrupts are disabled.
> 
> ...
> Now, several years after ACPI 2.0 was released,
> we have yet to observe a single implementation of
> _GTS/_BFS in the field -- suggesting that they will
> never actually be deployed.

There are actually some HP ia64 systems that have _GTS.  All
the rx7600-, rx8600-, and Superdome-class systems I looked at
have it.  But in each case, the method is empty, so I don't
know why they even bothered to implement it.

> So lets keep Linux simple by removing this
> theoretical support for _GTS/_BFS, the only
> AML methods that mandated being evaluated
> with interrupts disabled.

Do you want to print a note that _GTS/_BFS exists, but
we're ignoring it?  If some platform comes along that
uses them, a dmesg note might help debug problems.

Bjorn

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

* Re: [PATCH/RFC] ACPICA: disable ACPI 2.0 _GTS/_BFS support
  2008-12-19  9:23 [PATCH/RFC] ACPICA: disable ACPI 2.0 _GTS/_BFS support Len Brown
  2008-12-19 16:39 ` Bjorn Helgaas
@ 2008-12-19 17:48 ` Rafael J. Wysocki
  2008-12-22  1:42 ` Zhao Yakui
  2 siblings, 0 replies; 5+ messages in thread
From: Rafael J. Wysocki @ 2008-12-19 17:48 UTC (permalink / raw)
  To: Len Brown; +Cc: linux-acpi

On Friday, 19 of December 2008, Len Brown wrote:
> From: Len Brown <len.brown@intel.com>
> Organization: Intel Open Source Technology Center
> 
> ACPI 2.0 defined two new methods in the suspend/resume sequence,
> _GTS (Going to Sleep) and _BFS (Back from Sleep)
> 
> They are optional methods, but if the BIOS supplies them,
> the OS is supposed to evaluate them immediately before
> writing the register to sleep, and immediately after waking up --
> a time when interrupts are disabled.
> 
> The spec says that they must be self-contained
> methods, not calling any other methods, perhaps
> because that they are run under unique conditions?
> 
> These methodds are evaluated in Linux by
> acpi_evaluate_object(), which always kmalloc's
> a return structure to conserve stack space.
> But kmalloc with interrupts off is problematic --
> do we really want to insist on GFP_ATOMIC here?

Well, I think we should.

Alternatively, we can keep a preallocated buffer for this purpose.

> Now, several years after ACPI 2.0 was released,
> we have yet to observe a single implementation of
> _GTS/_BFS in the field -- suggesting that they will
> never actually be deployed.
> 
> So lets keep Linux simple by removing this
> theoretical support for _GTS/_BFS, the only
> AML methods that mandated being evaluated
> with interrupts disabled.

I'm not sure if I agree with this approach.

My opinion is that we should be able to execute AML code with interrupts
disabled and there should be means to do that.

The entire irqrouter_resume() thing requires us to evaluate AML with interrupts
disabled and in that particular case it also really _makes_ _sense_.

So, IMO dropping _GTS/_BFS doesn't really buy us anything.

Thanks,
Rafael

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

* Re: [PATCH/RFC] ACPICA: disable ACPI 2.0 _GTS/_BFS support
  2008-12-19  9:23 [PATCH/RFC] ACPICA: disable ACPI 2.0 _GTS/_BFS support Len Brown
  2008-12-19 16:39 ` Bjorn Helgaas
  2008-12-19 17:48 ` Rafael J. Wysocki
@ 2008-12-22  1:42 ` Zhao Yakui
  2 siblings, 0 replies; 5+ messages in thread
From: Zhao Yakui @ 2008-12-22  1:42 UTC (permalink / raw)
  To: Len Brown; +Cc: linux-acpi@vger.kernel.org

On Fri, 2008-12-19 at 17:23 +0800, Len Brown wrote:
> From: Len Brown <len.brown@intel.com>
> Organization: Intel Open Source Technology Center
> 
> ACPI 2.0 defined two new methods in the suspend/resume sequence,
> _GTS (Going to Sleep) and _BFS (Back from Sleep)

Is the purpose of this patch that in course of suspend/resume the ACPI
object won't be evaluated again when irq is disabled? And this can avoid
the preemption point after evaluating the ACPI object.
   
   If so, this issue can be fixed by the patch
   http://bugzilla.kernel.org/attachment.cgi?id=19370&action=view


> 
> They are optional methods, but if the BIOS supplies them,
> the OS is supposed to evaluate them immediately before
> writing the register to sleep, and immediately after waking up --
> a time when interrupts are disabled.
> 
> The spec says that they must be self-contained
> methods, not calling any other methods, perhaps
> because that they are run under unique conditions?
> 
> These methodds are evaluated in Linux by
> acpi_evaluate_object(), which always kmalloc's
> a return structure to conserve stack space.
> But kmalloc with interrupts off is problematic --
> do we really want to insist on GFP_ATOMIC here?
> 
> Now, several years after ACPI 2.0 was released,
> we have yet to observe a single implementation of
> _GTS/_BFS in the field -- suggesting that they will
> never actually be deployed.
> 
> So lets keep Linux simple by removing this
> theoretical support for _GTS/_BFS, the only
> AML methods that mandated being evaluated
> with interrupts disabled.
> 
> Signed-off-by: Len Brown <len.brown@intel.com>
> ---
>  drivers/acpi/hardware/hwsleep.c |    4 ++++
>  1 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/acpi/hardware/hwsleep.c b/drivers/acpi/hardware/hwsleep.c
> index 25dccdf..c209434 100644
> --- a/drivers/acpi/hardware/hwsleep.c
> +++ b/drivers/acpi/hardware/hwsleep.c
> @@ -289,6 +289,7 @@ acpi_status asmlinkage acpi_enter_sleep_state(u8 sleep_state)
>  		return_ACPI_STATUS(status);
>  	}
>  
> +#ifdef	ACPI_20_GTS_BFS
>  	/* Execute the _GTS method */
>  
>  	arg_list.count = 1;
> @@ -300,6 +301,7 @@ acpi_status asmlinkage acpi_enter_sleep_state(u8 sleep_state)
>  	if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {
>  		return_ACPI_STATUS(status);
>  	}
> +#endif
>  
>  	/* Get current value of PM1A control */
>  
> @@ -535,6 +537,7 @@ acpi_status acpi_leave_sleep_state_prep(u8 sleep_state)
>  		}
>  	}
>  
> +#ifdef	ACPI_20_GTS_BFS
>  	/* Execute the _BFS method */
>  
>  	arg_list.count = 1;
> @@ -546,6 +549,7 @@ acpi_status acpi_leave_sleep_state_prep(u8 sleep_state)
>  	if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {
>  		ACPI_EXCEPTION((AE_INFO, status, "During Method _BFS"));
>  	}
> +#endif
>  
>  	return_ACPI_STATUS(status);
>  }


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

* Re: [PATCH/RFC] ACPICA: disable ACPI 2.0 _GTS/_BFS support
  2008-12-19 16:39 ` Bjorn Helgaas
@ 2008-12-31  0:16   ` Len Brown
  0 siblings, 0 replies; 5+ messages in thread
From: Len Brown @ 2008-12-31  0:16 UTC (permalink / raw)
  To: Bjorn Helgaas; +Cc: linux-acpi

On Fri, 19 Dec 2008, Bjorn Helgaas wrote:

> On Friday 19 December 2008 02:23:49 am Len Brown wrote:
> > ACPI 2.0 defined two new methods in the suspend/resume sequence,
> > _GTS (Going to Sleep) and _BFS (Back from Sleep)
> > 
> > They are optional methods, but if the BIOS supplies them,
> > the OS is supposed to evaluate them immediately before
> > writing the register to sleep, and immediately after waking up --
> > a time when interrupts are disabled.
> > 
> > ...
> > Now, several years after ACPI 2.0 was released,
> > we have yet to observe a single implementation of
> > _GTS/_BFS in the field -- suggesting that they will
> > never actually be deployed.
> 
> There are actually some HP ia64 systems that have _GTS.  All
> the rx7600-, rx8600-, and Superdome-class systems I looked at
> have it.  But in each case, the method is empty, so I don't
> know why they even bothered to implement it.

I've seen "place holders" in AML many times.
_SCP is another popular one that is almost never implemented,
but sometimes exists and does nothing -- which is
quite misleading...

> > So lets keep Linux simple by removing this
> > theoretical support for _GTS/_BFS, the only
> > AML methods that mandated being evaluated
> > with interrupts disabled.
> 
> Do you want to print a note that _GTS/_BFS exists, but
> we're ignoring it?  If some platform comes along that
> uses them, a dmesg note might help debug problems.

Good idea.

Probably the smart thing to do would be to print a
message if they exist and are non-empty.
Otherwise we'd have to DMI those HP boxes with
empty methods.

-- Len Brown, Intel Open Source Technology Center



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

end of thread, other threads:[~2008-12-31  0:17 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-12-19  9:23 [PATCH/RFC] ACPICA: disable ACPI 2.0 _GTS/_BFS support Len Brown
2008-12-19 16:39 ` Bjorn Helgaas
2008-12-31  0:16   ` Len Brown
2008-12-19 17:48 ` Rafael J. Wysocki
2008-12-22  1:42 ` Zhao Yakui

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