Subject: Re: Apm_emulation and proper suspend
From: Richard Purdie <rpurdie@openedhand.com>
To: Kristoffer Ericson <kristoffer.ericson@gmail.com>
Cc: rjw@sisk.pl, linux-main <linux-kernel@vger.kernel.org>
In-Reply-To: <20080221123318.41273a1f.Kristoffer.ericson@gmail.com>
References: <20080221123318.41273a1f.Kristoffer.ericson@gmail.com>
Content-Type: text/plain
Date: Thu, 21 Feb 2008 11:59:45 +0000
Message-Id: <1203595185.9329.12.camel@dax.rpnet.com>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1718
Lines: 37

On Thu, 2008-02-21 at 12:33 +0100, Kristoffer Ericson wrote:
> I'm reworking a couple of apm drivers and for whatever reason it
> doesn't seem to update my /proc/apm_bios. I was under the impression
> that it should do that when apm_bios was catted? Currently I have a
> value that never change. I export my get_power_status.. function
> properly but doesn't seem to touch it. I noticed that Richard had the
> extern int (void..apm_get_power) (...) declare an extra time (once in
> apm-emulation.h and another inside sharpsl.c), is that needed?

It should be removed from sharpsl.c in that case. The code was written
when the apm emulation code was arm specific and looked rather
different.

> Also, is apm the "brains" behind the suspend/resume interactions? By
> that I mean, should suspend be initiated through apm functions
> in order to be proper? I've tried to find examples but the best source
> of suspend related code is Richards code on sharp machines.

APM means you can can notify userspace of the suspend/resume events and
have some kind of interaction there through apmd. It gives a mechanism
where both userspace and kernel space can queue suspend requests and
where userspace can veto a voluntary suspend.

You can also suspend the system through "echo mem > /sys/power/state" in
userspace or calling pm_suspend() in kernel space but this doesn't give
anything else the opportunity to know about the event which is why we
still have apm.

Cheers,

Richard

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/