Date: Sat, 30 Sep 2000 15:45:48 -0700 From: Mike Smith <msmith@freebsd.org> To: Mitsuru IWASAKI <iwasaki@jp.FreeBSD.org> Cc: 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 Message-ID: <200009302245.e8UMjmh01156@mass.osd.bsdi.com> In-Reply-To: Your message of "Sun, 01 Oct 2000 06:51:34 %2B0900." <20001001065134S.iwasaki@jp.FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>>> 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 :-)
Swine. 8)
>> 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?
Well, yes, but you have to go back and re-parse the actual AML. I'm not
even sure if it's safe to assume that the thermal zone is in the same
place in the bytecode (it should be, I guess).
>> 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 went reading through the ACPICA documentation to work this out. They
acually have a very nice technique where they attach the I/O handlers to
a point in the namespace, and then when something attempts I/O, they
travel back up the namespace to the root, looking for the first matching
I/O handler.
This means that when your EC driver finds an embedded controller, you
just attach your I/O handler to the EC object. Then anytime someone
tries to do I/O to the EC, your handler gets called.
I can write the driver easily enough, but I don't know how I/O is
currently handled in the AML interpreter. The more I look at ACPICA, the
more I like the idea of using it, presuming that it actually works...
> 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...
Hmm. I guess I should spend some more time looking at this. I don't
mean to devalue all the work that's been put into the current AML code,
but ACPICA has already solved a lot of the problems that we haven't even
touched yet (Notify, locking, etc...)
--
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also. But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view. [Dr. Fritz Todt]
V I C T O R Y N O T V E N G E A N C E
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200009302245.e8UMjmh01156>