RE: please git pull ACPI for 2.6.17

RE: please git pull ACPI for 2.6.17

[Brown, Len]

>is it possible to do so now, still before .17 release?

I think that on April 3rd this was appropriate.
But now 6 weeks later in the release cycle I don't think it is
appropriate to do such a large pull.

I'm assuming this tree will not be pulled until the start of .18.

Jiri,
Is there a specific individual patch that you are wanting to have in
.17?

thanks,
-Len

RE: please git pull ACPI for 2.6.17

[Brown, Len]

>is it possible to do so now, still before .17 release?

I think that on April 3rd this was appropriate.
But now 6 weeks later in the release cycle I don't think it is
appropriate to do such a large pull.

I'm assuming this tree will not be pulled until the start of .18.

Jiri,
Is there a specific individual patch that you are wanting to have in
.17?

thanks,
-Len

Re: please git pull ACPI for 2.6.17

[Jiri Slaby]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Brown, Len napsal(a):
>> is it possible to do so now, still before .17 release?
> 
> I think that on April 3rd this was appropriate.
> But now 6 weeks later in the release cycle I don't think it is
> appropriate to do such a large pull.
It seemed obvious, I just tried it, because there was a complain on bugzilla.
> 
> I'm assuming this tree will not be pulled until the start of .18.
Never mind.
> 
> Jiri,
> Is there a specific individual patch that you are wanting to have in
> .17?
I wanted to have ecdt-uid-hack there, because asus laptops' acpi is defunct, but
as I said, it doesn't matter, 2.6.18-rc1 is not so far.

thanks,
- --
Jiri Slaby         www.fi.muni.cz/~xslaby
\_.-^-._   jirislaby@gmail.com   _.-^-._/
B67499670407CE62ACC8 22A032CC55C339D47A7E
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFEZ3BWMsxVwznUen4RAsk4AKDEhjpLcItL1v1MXe7ZShvTLUmONACgqpG9
uQPOD1X8gS9SX0C2avn8Hj8=
=l1s/
-----END PGP SIGNATURE-----

Resume on Apple Mac Mini

[Linus Torvalds]

It turns out that the Apple Mac Mini comes back from suspend in legacy 
mode.

The simplest and most obvious fix would seem to be the following trivial 
one-liner, which just enables ACPI mode after any suspend event.

Comments? Can anybody see any downsides to just doing something this 
obvious, and doing it unconditionally?  I've seen a much more complicated 
patch that only does this for Apple hardware, but I wouldn't be surprised 
at all if this is more common.

In fact, googling for the symptoms ("nobody cared" and "acpi_irq" and 
"suspend") gives quite a number of hits, so I would not be surprised at 
all if this is not Apple-related at all, but that we should always have 
done this.

Comments? 

		Linus

---
diff --git a/drivers/acpi/sleep/main.c b/drivers/acpi/sleep/main.c
index 56f861e..7b6c146 100644
--- a/drivers/acpi/sleep/main.c
+++ b/drivers/acpi/sleep/main.c
@@ -109,6 +108,11 @@ static int acpi_pm_enter(suspend_state_t
 	local_irq_restore(flags);
 	printk(KERN_DEBUG "Back to C!\n");
 
+	/*
+	 * Make sure we're back in ACPI mode!
+	 */
+	acpi_enable();		
+
 	/* restore processor state
 	 * We should only be here if we're coming back from STR or STD.
 	 * And, in the case of the latter, the memory image should have already

Re: Resume on Apple Mac Mini

[Linus Torvalds]

On Sat, 17 Jun 2006, Linus Torvalds wrote:
>
> It turns out that the Apple Mac Mini comes back from suspend in legacy 
> mode.

Actually, that wasn't it. My debugging patches use the RTC to save off 
information, and that causing a test-kernel to not compile the test, or 
just normal incompetence on my part, made me "confirm" this as working, 
when it isn't.

The thing that does work is to literally just set the SCI_ENABLE bit:

	acpi_set_register(ACPI_BITREG_SCI_ENABLE, 1, ACPI_MTX_DO_NOT_LOCK);

after resume, _not_ the "acpi_enable()".

		Linus

Re: Resume on Apple Mac Mini

[Matthew Garrett]

On Sat, Jun 17, 2006 at 05:35:51PM -0700, Linus Torvalds wrote:

> The thing that does work is to literally just set the SCI_ENABLE bit:
> 
> 	acpi_set_register(ACPI_BITREG_SCI_ENABLE, 1, ACPI_MTX_DO_NOT_LOCK);
> 
> after resume, _not_ the "acpi_enable()".

The ACPI spec says:

"If this is an S2 or S3 wake, then the BIOS restores minimum context of 
the system before jumping to the waking vector. This includes:

...

ACPI registers. SCI_EN bit must be set. All event status/enable bits 
(PM1x_STS, PM1x_EN, GPEx_STS and GPEx_EN) must not be changed by BIOS."

So it seems like either we're doing something slightly wrong on putting 
machines to sleep which is resulting in them waking up without SCI_EN 
being set, or Windows unconditionally enables it and some hardware is 
just broken. Either way, it doesn't seem likely that it'll cause any 
harm.

-- 
Matthew Garrett | mjg59@srcf.ucam.org