From owner-acpi-jp@jp.freebsd.org  Wed Dec 27 02:43:51 2000
Received: (from daemon@localhost)
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) id CAA02709;
	Wed, 27 Dec 2000 02:43:51 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from tasogare.imasy.or.jp (daemon@tasogare.imasy.or.jp [202.227.24.5])
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) with ESMTP id CAA02704
	for <acpi-jp@jp.freebsd.org>; Wed, 27 Dec 2000 02:43:50 +0900 (JST)
	(envelope-from iwasaki@jp.FreeBSD.org)
Received: from localhost (iwasaki.imasy.or.jp [202.227.24.92])
	by tasogare.imasy.or.jp (8.11.1+3.4W/3.7W-tasogare/smtpfeed 1.07) with ESMTP id eBQHhmk28990
	for <acpi-jp@jp.freebsd.org>; Wed, 27 Dec 2000 02:43:48 +0900 (JST)
	(envelope-from iwasaki@jp.FreeBSD.org)
To: acpi-jp@jp.freebsd.org
In-Reply-To: <200012261440.eBQEeZj86154@mass.osd.bsdi.com>
References: <20001222001625L.iwasaki@jp.FreeBSD.org>
	<200012261440.eBQEeZj86154@mass.osd.bsdi.com>
X-Mailer: Mew version 1.94.1 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20001227024346T.iwasaki@jp.FreeBSD.org>
Date: Wed, 27 Dec 2000 02:43:46 +0900
From: Mitsuru IWASAKI <iwasaki@jp.freebsd.org>
X-Dispatcher: imput version 20000228(IM140)
Lines: 79
Reply-To: acpi-jp@jp.freebsd.org
Precedence: list
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+000315
X-Sequence: acpi-jp 1000
Subject: [acpi-jp 1000] Re: Generalised power-management interface (was
 Re: Some power device driver. ) 
Errors-To: owner-acpi-jp@jp.freebsd.org
Sender: owner-acpi-jp@jp.freebsd.org
X-Originator: iwasaki@jp.freebsd.org

Thanks mike, I've put new version at
http://people.FreeBSD.org/~iwasaki/acpi/power-20001227.tar.gz

This includes generalized power management interface of acpi_cmbat
ported Matsuda-san's acpibatt with some modifications, and
standby/suspend/hibernation state transition (of course I made things
simple :-).
Also I added new options to acpibatt to set/get full charged battery
time to/from acpi_cmbat so that acpibatt calculate battery time event
when acline is on-line.

Matsuda-san, I made changes on acpibatt utility, mainly cleanup.
Could you check them?

> Well, "OSPM" is just "operating system power management", referring to 
> the OS component in the power management scheme.  I don't like the name 
> much either, but it's not really incompatible with APM per se.
[snip]
> > How about "genpm" ?
> 
> /dev/power ?

Sounds good.  I like this one :-)

> > Also I've been considering to integrate UPS too into this framework in future.
> > # Yes it would be more difficult, but has some advantages in terms of
> > # application program development effort, I believe.
> 
> I could see useful ways in which UPS support might want to integrate with 
> generic platform power management, certainly.

Yes. The biggest problem is that I don't have UPS and my knowledge on
UPS is almost zero :-).

> > It's possible and nicer, but I would say no.  linker_set seems to be
> > unavailable in other BSDs (even in compat_linux of NetBSD).
> 
> Then these other BSD's can use their own way of doing things.  FreeBSD 
> uses linker sets for this; they can patch main() or however they do it.

I just want to reduce my effort when I help them who are willing to port
our code :-)

> > I want to reduce FreeBSD specific part as much as possible, and to have
> > simple and reasonable ioctl handler registering interface.
> > Any improvements are welcome :-)
> 
> You could probably just make a function call to register the ioctl 
> handler.

OK, just start with simple one, then improve it later.

> > >  - set power consumption policy to "high" or "low"
> > 
> > Yes.  I don't know the reason of stop calling apm_cpu()/apm_idle(),
> > but should we make it configurable?
> 
> This is an APM-specific quirk, and should be configured with an 
> APM-specific tool.

We can try this later.

> > >  - put the system into a "suspend" and/or a "sleep" state
> > 
> > Yes, I think it's easy.

This have been implemented in this version.

> > > I think the interface that's been proposed actually covers almost all of 
> > > this, so perhaps it's not really too specialised either.
> > 
> > OK, I think having event notification mechanism would be enough for 
> > the generic power management interface adding to this.
> 
> Event notification is definitely worth having, yes.

Anyone want to try this?

Thanks!
