Not enabling the busmgr and EC is a not particularly useful config at this
point, but the option is available for debugging reasons, and also it
enables us to determine acpi's core interpreter size more easily.
If you are willing to try acpi, I'd recommend everything on for now.
Regards -- Andy
> -----Original Message-----
> From: Alex Bligh - linux-kernel [mailto:[email protected]]
> Sent: Wednesday, October 31, 2001 1:02 PM
> To: Alex Bligh - linux-kernel; Grover, Andrew;
> [email protected]
> Cc: Alex Bligh - linux-kernel
> Subject: RE: 2xQ: Is PM + ACPI but /no/ APM a valid configuration?
> Interru pts enabled in APM set power state?
> Importance: High
>
>
> > For the hard of understanding, such as myself, do you mean the
> > ACPI bus manager (CONFIG_ACPI_BUSMGR)? I had that unset, on
> > the basis of least change, but can try it, or did you mean
> > something else?
>
> This was a stupid question derived from being up too many
> hours. Andrew obviously meant 'embedded controller', the config
> option for which depends on bus manager being selected
> too. Apols.
>
> Is selecting ACPI without these an invalid config? Or just
> on my laptop?
>
> --
> Alex Bligh
>
Andrew,
--On Wednesday, 31 October, 2001 1:33 PM -0800 "Grover, Andrew"
<[email protected]> wrote:
> If you are willing to try acpi, I'd recommend everything on for now.
OK, so I tried the combinations again, and where it says ACPI,
I now mean ACPI + all bells / whistles as suggested. Sadly the net effect
seems to be that it disables any useful power management
functionality, and doesn't fix any broken stuff :-(
Results for T23:
No PM, no ACPI, no APM
suspend works - i.e. doesn't crash on resume,
but 'dumbly' and doesn't restore some PCI states
(unsurprising), clock, etc., and no /proc/apm
etc.
PM, no ACPI, no APM
this seems to work, but debugging the power management
stuff suggests that the PCI drivers are never sent
suspend or resume events, which is causing the
crashes below.
PM, ACPI, no APM
Suspend buttons (all of them) & closing laptop
lid no longer do anything. As there's no apm support,
apm -s doesn't work either, so impossible to test
suspend.
[wierd messages now gone - thanks Andrew.].
PM, no ACPI, APM
Machine hangs on resume.
printk()s tell me that it successfully does
all the pm_send stuff, then calls apm_set_power_state()
(I can see this immediately before the LCD disappears).
But on resume, though the LCD comes back on, it
never gets to the printk() I inserted immediately
afterwards.
I added further printk(s) to immediately after
the segment restore on the bios calls, and indeed
it never appears to return.
PM, ACPI, APM
as above
Also, on advice, I have APM configured to allow
interrupts (IBM laptop). So what happens if a
device interrupts as / because of the resume,
perhaps before the segment registers have
been restored, and certainly before the pm_send
stuff has gone around?
[kernel 2.4.12-ac5 at present]
--
Alex Bligh
Admittedly, I don't know much about APM, though I may have some general
insight..
> No PM, no ACPI, no APM
>
> suspend works - i.e. doesn't crash on resume,
> but 'dumbly' and doesn't restore some PCI states
> (unsurprising), clock, etc., and no /proc/apm
> etc.
/proc/apm is created by the APM driver.
Many drivers have
#ifdef CONFIG_PM
around power management functionality, so you're not going to get that if
none of these are enabled. Even if CONFIG_PM, it's not going to be called
unless APM is up and running.
The BIOS is supposed to restore all the PCI config space, but we all know
how well the BIOS does what it's supposed to reliably.
> PM, no ACPI, no APM
>
> this seems to work, but debugging the power management
> stuff suggests that the PCI drivers are never sent
> suspend or resume events, which is causing the
> crashes below.
The suspend resume events are triggered by the APM subsystem. You won't
get them without it.
> PM, ACPI, no APM
>
> Suspend buttons (all of them) & closing laptop
> lid no longer do anything. As there's no apm support,
> apm -s doesn't work either, so impossible to test
> suspend.
The suspend buttons and lid switch are controlled via GPEs. IIRC, all the
GPEs are disabled by ACPI. If they're not, I know there are no handlers
for them ATM.
ACPI suspend has not been implemented fully yet, so you're not going to
get good results anyway..
-pat
Patrick,
> /proc/apm is created by the APM driver.
Sure.
> around power management functionality, so you're not going to get that if
> none of these are enabled. Even if CONFIG_PM, it's not going to be called
> unless APM is up and running.
Well, actually APM or acpi reading the source, but yes.
> The BIOS is supposed to restore all the PCI config space, but we all know
> how well the BIOS does what it's supposed to reliably.
Indeed :-) I seem to be having difficulty just making it return from
the call at all.
> The suspend resume events are triggered by the APM subsystem. You won't
> get them without it.
The events, yes - or the ACPI subsystem, I think - at least it
seems to send power management events.
> ACPI suspend has not been implemented fully yet, so you're not going to
> get good results anyway..
So it would seem :-)
Is there a good way to debug apm.c BIOS calls (beyond a disassembler)?
--
Alex Bligh
Hi!
> PM, ACPI, no APM
>
> Suspend buttons (all of them) & closing laptop
> lid no longer do anything. As there's no apm support,
> apm -s doesn't work either, so impossible to test
> suspend.
>
> [wierd messages now gone - thanks Andrew.].
That means that ACPI works as expected. Good.
Pavel
--
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.