From owner-freebsd-current  Sat Sep 30 14:52:17 2000
Delivered-To: freebsd-current@freebsd.org
Received: from tasogare.imasy.or.jp (tasogare.imasy.or.jp [202.227.24.5])
	by hub.freebsd.org (Postfix) with ESMTP
	id 002AA37B502; Sat, 30 Sep 2000 14:52:13 -0700 (PDT)
Received: from localhost (iwasaki.imasy.or.jp [202.227.24.92])
	by tasogare.imasy.or.jp (8.10.2+3.3W/3.7W-tasogare/smtpfeed 1.07) with ESMTP id e8ULqAr43935;
	Sun, 1 Oct 2000 06:52:10 +0900 (JST)
	(envelope-from iwasaki@jp.FreeBSD.org)
To: msmith@freebsd.org
Cc: iwasaki@jp.FreeBSD.org, haro@tk.kubota.co.jp,
	takawata@shidahara1.planet.sci.kobe-u.ac.jp, current@freebsd.org,
	acpi-jp@jp.FreeBSD.org
Subject: Re: ACPI megapatch 
In-Reply-To: <200009301958.e8UJwWh00606@mass.osd.bsdi.com>
References: <20001001042705H.iwasaki@jp.FreeBSD.org>
	<200009301958.e8UJwWh00606@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: <20001001065134S.iwasaki@jp.FreeBSD.org>
Date: Sun, 01 Oct 2000 06:51:34 +0900
From: Mitsuru IWASAKI <iwasaki@jp.FreeBSD.org>
X-Dispatcher: imput version 20000228(IM140)
Lines: 46
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Hi,

> > Cool.  On some machine, thermal management requires Embedded Controller I/O.
> > Anybody working on this?
> 
> Yeah.  I just discovered that I need this. 
> 
> I haven't look at how operation regions are handled, so I'm not sure how 
> hard it's going to be to implement the hooks necessary for this.

Some VAIOs, ThinkPads require this too, luckily my PORTEGE doesn't. 
I can test the thermal management code earlier :-)

> There is another major problem here too.
> 
> Some complete idiot in the ACPI team decided that the "right" way to 
> implement hysteresis for the temperature settings was to have the system 
> send a Notify(zone, 0x80) to the thermal zone and then have it re-parse 
> it's AML to discover new settings.  This means that you need to keep a 
> pointer to the *original* location of the AML for at least some methods 
> inside a thermal zone, if not the entire zone itself.
> 
> My laptop does this too.  8(

PowerResource code keeps pointers to the PowerResource objects, then
finds a pointer to methods of the object dynamically.  Can we do it in
similar way for thermal management?

> I haven't looked at the ACPICA code yet, but it wouldn't surprise me if 
> all the embedded controller stuff is already supported there.  How bad do 
> you think it's going to be to make it work?  You've already looked at the 
> modifications that the Linux people have made - were they just bug fixes, 
> or are there serious problems with the code?

I didn't read closer, but I couldn't find any embedded controller
stuff in both linux-2.4.0-test8 and acpica-unix-20000901 except for
definitions in header files.
Subsystem/Include/acinterp.h:AcpiAmlEmbeddedControllerSpaceHandler in acpica,
drivers/acpi/include/interp.h:acpi_aml_embedded_controller_space_handler in linux.

I guess this function will be implemented in interpreter/amregion.c in future.

Last time I compared only few files and found many differences between
them not only for naming.  I think these two used the same code
originally, but enhanced separately.  Now that it's difficult to
compare them...


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message