CONFIG_PM, CONFIG_ACPI, CONFIG_ACPI_SLEEP

CONFIG_PM, CONFIG_ACPI, CONFIG_ACPI_SLEEP

[Len Brown]

Today it is possible to build with
CONFIG_PM=n
CONFIG_ACPI=y
(however, CONFIG_ACPI_SLEEP does depend on CONFIG_PM)

Seems that the solution to the kexec poweroff issue
is simpler if ACPI can depend on CONFIG_PM being present:
http://bugzilla.kernel.org/show_bug.cgi?id=4041

Why shouldn't CONFIG_ACPI depend on CONFIG_PM
Why shouldn't CONFIG_ACPI_SLEEP simply be CONFIG_ACPI

I can't think of any good reasons not to simplify here, can you?

thanks,
-Len




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: CONFIG_PM, CONFIG_ACPI, CONFIG_ACPI_SLEEP

[Nigel Cunningham]

Hi.

On Thu, 2005-03-10 at 06:02, Len Brown wrote:
> Today it is possible to build with
> CONFIG_PM=n
> CONFIG_ACPI=y
> (however, CONFIG_ACPI_SLEEP does depend on CONFIG_PM)
> 
> Seems that the solution to the kexec poweroff issue
> is simpler if ACPI can depend on CONFIG_PM being present:
> http://bugzilla.kernel.org/show_bug.cgi?id=4041
> 
> Why shouldn't CONFIG_ACPI depend on CONFIG_PM
> Why shouldn't CONFIG_ACPI_SLEEP simply be CONFIG_ACPI
> 
> I can't think of any good reasons not to simplify here, can you?

That sounds confusing to me. I thought that ACPI was much more than just
power management. Doesn't it include IRQ routing, device enumeration and
so on too?

Regards,

Nigel
-- 
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com
Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028;  Mob: +61 (417) 100 574

Maintainer of Suspend2 Kernel Patches http://suspend2.net



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

RE: CONFIG_PM, CONFIG_ACPI, CONFIG_ACPI_SLEEP

[Brown, Len]

 
>> Why shouldn't CONFIG_ACPI depend on CONFIG_PM
>> Why shouldn't CONFIG_ACPI_SLEEP simply be CONFIG_ACPI
>> 
>> I can't think of any good reasons not to simplify here, can you?
>
>That sounds confusing to me. I thought that ACPI was much more 
>than just power management. Doesn't it include IRQ routing, device 
>enumeration and so on too?

Yes, ACPI does a lot of configuration too -- but there really isn't any
concept of having the config part of ACPI without having the power
management part.

The real question is if CONFIG_PM=n is an interesting configuration on
ACPI-enabled systems.  I'm thinking that a couple of years ago it was,
but today everybody is using CONFIG_PM=y.

thanks,
-Len


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click

RE: CONFIG_PM, CONFIG_ACPI, CONFIG_ACPI_SLEEP

[Nigel Cunningham]

Hi.

On Thu, 2005-03-10 at 14:36, Brown, Len wrote:
>  >> Why shouldn't CONFIG_ACPI depend on CONFIG_PM
> >> Why shouldn't CONFIG_ACPI_SLEEP simply be CONFIG_ACPI
> >> 
> >> I can't think of any good reasons not to simplify here, can you?
> >
> >That sounds confusing to me. I thought that ACPI was much more 
> >than just power management. Doesn't it include IRQ routing, device 
> >enumeration and so on too?
> 
> Yes, ACPI does a lot of configuration too -- but there really isn't any
> concept of having the config part of ACPI without having the power
> management part.
> 
> The real question is if CONFIG_PM=n is an interesting configuration on
> ACPI-enabled systems.  I'm thinking that a couple of years ago it was,
> but today everybody is using CONFIG_PM=y.

I think 'everybody' is an overstatement. If I put things in the wrong
place such that I break CONFIG_PM=n, I hear about it. That said, I do
agree that CONFIG_PM=y can increasingly be taken for granted.

Perhaps there's an issue somewhere else though. After all, I'd be
surprised if you argued that CONFIG_ACPI_FAN was a power management
function. Maybe ACPI config options could be split up a little so that
those related to PM did come under CONFIG_PM, and those related to PNP
or whatever else could appear elsewhere? Of course I'm speaking as
someone who doesn't know exactly how closely all of this functionality
inter-relates, so what makes sense to me might not make sense to you :>

Nigel
-- 
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com
Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028;  Mob: +61 (417) 100 574

Maintainer of Suspend2 Kernel Patches http://suspend2.net



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

RE: CONFIG_PM, CONFIG_ACPI, CONFIG_ACPI_SLEEP

[Brown, Len]

>-----Original Message-----
>From: Nigel Cunningham [mailto:ncunningham-3EexvZdKGZRWk0Htik3J/w@public.gmane.org] 

>I think 'everybody' is an overstatement. If I put things in the wrong
>place such that I break CONFIG_PM=n, I hear about it. That said, I do
>agree that CONFIG_PM=y can increasingly be taken for granted.

I linux there is somebody someplace using every possible configuration
-- if it makes sense or not.  So the strategy is to delete the
configurations that don't make much sense so we don't get sidetracked
into supporting things that are unimportant to nearly all users.

>Perhaps there's an issue somewhere else though. After all, I'd be
>surprised if you argued that CONFIG_ACPI_FAN was a power management
>function.

Actually, the fan is definitely a power management function -- think
active/passive cooling, power zones, cpu speeds etc.

But there are other "run time" ACPI functions that are not technically
power management, such as hot plug support.

> Maybe ACPI config options could be split up a little so that
>those related to PM did come under CONFIG_PM, and those related to PNP
>or whatever else could appear elsewhere? Of course I'm speaking as
>someone who doesn't know exactly how closely all of this functionality
>inter-relates, so what makes sense to me might not make sense to you :>

We used to sort of try to do this, but it turned out to be a bad idea.
The ACPI interpreter is required for configuration, so deleting power
management doesn't save you much.  The power management policy drivers
(like fan) are individually configurable, so you can Y/N/M them
independently.

Today the only ACPI thing that depends on PM is the ACPI sleep code.
But sleep and poweroff are very similar, and we'd like to be able to
count on some PM functionality for poweroff in ACPI mode.

thanks,
-Len


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click

Re: CONFIG_PM, CONFIG_ACPI, CONFIG_ACPI_SLEEP

[Sergio Monteiro Basto]

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

Hi, I had write about it on Apr/May 2004,

Because "Accidentally, I compile ACPI without CONFIG_PM on one Dell
something dual Pentium III and power off didn't work." 

For me this was a bug that has been introduced when ACPI enter in 2.4
because, before that, if I recall correctly  
"we couldn't compile ACPI without define CONFIG_PM"

Conclusion, to simplify, on kernel configuration, I propose to force
that (for compile ACPI we need define CONFIG_PM) (again?) with this
little patch on attach. 

thanks,

On Thu, 2005-03-10 at 09:15 +1100, Nigel Cunningham wrote:
> Hi.
> 
> On Thu, 2005-03-10 at 06:02, Len Brown wrote:
> > Today it is possible to build with
> > CONFIG_PM=n
> > CONFIG_ACPI=y
> > (however, CONFIG_ACPI_SLEEP does depend on CONFIG_PM)
> > 
> > Seems that the solution to the kexec poweroff issue
> > is simpler if ACPI can depend on CONFIG_PM being present:
> > http://bugzilla.kernel.org/show_bug.cgi?id=4041
> > 
> > Why shouldn't CONFIG_ACPI depend on CONFIG_PM
> > Why shouldn't CONFIG_ACPI_SLEEP simply be CONFIG_ACPI
> > 
> > I can't think of any good reasons not to simplify here, can you?
> 
> That sounds confusing to me. I thought that ACPI was much more than just
> power management. Doesn't it include IRQ routing, device enumeration and
> so on too?

yes, but we can say "ACPI without PM doesn't exist"

> 
> Regards,
> 
> Nigel
-- 
Sérgio M.B.

[-- Attachment #2: configopti-24.diff --]
[-- Type: text/x-patch, Size: 805 bytes --]

--- linux-2.4.26s/arch/i386/config.in.orig	2004-04-29 23:38:38.000000000 +0100
+++ linux-2.4.26s/arch/i386/config.in	2004-04-29 23:40:58.000000000 +0100
@@ -360,7 +360,7 @@
 bool 'Power Management support' CONFIG_PM
 
 dep_tristate '  Advanced Power Management BIOS support' CONFIG_APM $CONFIG_PM
-if [ "$CONFIG_APM" != "n" ]; then
+if [ "$CONFIG_APM" != "n" -a "$CONFIG_PM" = "y" ]; then
    bool '    Ignore USER SUSPEND' CONFIG_APM_IGNORE_USER_SUSPEND
    bool '    Enable PM at boot time' CONFIG_APM_DO_ENABLE
    bool '    Make CPU Idle calls when idle' CONFIG_APM_CPU_IDLE
@@ -370,7 +370,9 @@
    bool '    Use real mode APM BIOS call to power off' CONFIG_APM_REAL_MODE_POWER_OFF
 fi
 
-source drivers/acpi/Config.in
+if [ "$CONFIG_PM" = "y" ]; then
+	source drivers/acpi/Config.in
+fi
 
 endmenu