Date: Sun, 01 Oct 2000 22:04:52 +0900 From: Mitsuru IWASAKI <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 Message-ID: <20001001220452O.iwasaki@jp.FreeBSD.org> In-Reply-To: <200009302245.e8UMjmh01156@mass.osd.bsdi.com> References: <20001001065134S.iwasaki@jp.FreeBSD.org> <200009302245.e8UMjmh01156@mass.osd.bsdi.com>
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) Yes :-) > > 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 development experience. 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. - Licence 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 become hard... Thanks 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?20001001220452O.iwasaki>