> >>> 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)
> > 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 also think it shoud be...
> 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.
Yes, we can have large benefit by migrating to ACPICA. I suggest that
we make ACPICA version of AML interpreter run in userland as a
debugger for the first evaluation. By doing this work we can make
sure it works actually on FreeBSD and estimate the work volume of
kernel porting. Also we know the amldb is very useful from our
Another suggestion is that this migration should be done prudently.
During ACPICA porting, we add ACPICA compatible wrappers to current
aml code (e.g. AcpiWalkNamespace() -> aml_apply_foreach_found_objects())
and modify acpi driver code so that we migrate to ACPICA smoothly.
BTW, last time Watanabe-san tried to write EC stuff, but unfortunately
his laptop was broken *twice* by testing.
Be careful, otherwise your Dell will go to the hospital 8)
> 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...)
OK, before making our decision, I want to make sure something.
Linux folks apply GPL for it. Is it possible to apply BSD style
licence for FreeBSD version of ACPICA? or should we put it sys/contrib?
- Support from Intel
My major concern is this one. I wonder whether our local changes
for ACPICA can feed back to original code. If not, maintenance will
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message