Latest ACPI megapatch update

[Mike Smith]

 http://people.freebsd.org/~msmith/acpica-bsd-20001008.tar.gz

New in this patch:

 - Fixes for the EC code (error handling)
 - Fixes for power/sleep button handling (should work for both
   control method and fixed buttons)
 - Host:PCI bridges are now detected and attached using ACPI rather than
   by rummaging in PCI configuration space.  (If this fails, we fall back
   to the old techniques).
 - Print the current temperature in detected thermal zones (just cosmetic,
   and reveals that some machines are a bit confused already).

Comments, suggestions, bugfixes, etc. welcome as per usual.  It looks 
like we will be switching to this codebase fairly soon (the acpi-jp folks 
have been discussing this), so anyone with an interest in it is 
encouraged to tinker.

There is a known problem with this code and the Dell Inspiron 7500 (and 
possibly other laptops with similar BIOS AML) which I'm trying to fix.  
Don't expect it to work there yet. 8)


-- 
... 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ACPI megapatch

[Mike Smith]

   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.
  
  Indeed.  I've just taken the hard path to start with, and got the kernel 
  integration (mostly) resolved.  Fortunately, the ACPICA code includes a 
  complete user-space ACPI interpreter for just this purpose.  I think some 
  of their test code has rotted a bit (eg. their AcpiDump tool), but it 
  shouldn't be too hard to get this going.
 
 I and acpi-jp folks discussed ACPICA migration last night, there is no
 objections so far.  Most of them agreed that evaluation must be done
 at least.  Some people already started lerning ACPICA with documents and
 source code.
 Mike, I'm feeling we need to have a migration plan.  Do you have any
 plan on this?

I have an enormous patch that I can put up later tonight on Freefall.

I have the ACPICA 2915 release fully integrated, and I've ported 
their sample OSPM components just for fun (there are problems with these,
and I think we will only want them as examples).  I also ported their 
ACPI dump utility, but it's output is much uglier than ours.

The Intel code is clean, and the operating system interfaces are well 
documented.  I've mailed a promising contact at Intel to see how they
feel about accepting our changes.

There is still a lot of work to be done.  I want to at least have one 
sample acpi child device ready - I'll try converting their thermal 
management OSPM component so that you can play with it. 8)

(There is a chicken-and-egg problem with their bus manager component and 
the embedded controller support which means that I still have a hot 
laptop.  Grrr. 8)

 # I have to learn first before my participation to the discussion :-)

I hope that you will find ACPICA well documented.  You should read the 
developer's guide first, as it contains lots of very useful information.

   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.
  
  This would be very difficult.
 
 OK, but I'll try, this will be my private project.  I won't complain
 anything if most of the code is deleted after migration.  I hope I'll
 get some understanding on ACPICA programming.

I think that it will be easier just to adapt existing code to the new 
interfaces than to write a compatibility layer.

  The Intel licence on the "generic Unix" version of ACPICA is suitable for 
  direct inclusion in FreeBSD.  I'm not sure that the Intel code shouldn't 
  be in sys/contrib *anyway*.
 
 I see.  I found that we may have additional license terms, but I leave
 it to your discretion.

The additional terms are just Intel's legal department trying to make the 
BSD license look big and scary. 8)  We've talked to Intel about this same 
license text in other contexts before; it is the same as the 4-clause BSD 
license.

  Given how much work the Intel people went through just to get their code 
  into the Linux kernel, I think they will find us *much* more friendly. 8)
 
 # Welcome new committers from Intel :-)

Now *that* would be *nice*. 8)


-- 
... 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ACPI megapatch

[Mike Smith]

 I have an enormous patch that I can put up later tonight on Freefall.

Actually, I couldn't make CVS do what I wanted, so it's a big tarball 
with an itty-bitty little patch instead.

This requires an up-to-date -current kernel (for the pci_cfgreg changes, 
etc.)

I haven't done anything special with newbus attachments yet, and the 
embedded controller stuff is still broken, but this should compile and 
run.  It needs resource management work (only interrupts are handled 
correctly) and lots of event handlers and so on, but it should be a good 
foundation to start with.

Comments and suggestions would definitely be appreciated.

 http://people.freebsd.org/~msmith/acpica-bsd-20001002.tar.gz

-- 
... 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ACPI megapatch

[Mitsuru IWASAKI]

 Actually, I couldn't make CVS do what I wanted, so it's a big tarball 
 with an itty-bitty little patch instead.
 
 This requires an up-to-date -current kernel (for the pci_cfgreg changes, 
 etc.)
 
 I haven't done anything special with newbus attachments yet, and the 
 embedded controller stuff is still broken, but this should compile and 
 run.  It needs resource management work (only interrupts are handled 
 correctly) and lots of event handlers and so on, but it should be a good 
 foundation to start with.

Great!  This is really great!!  I didn't think we can have ACPICA
kernel so earlier.

 Comments and suggestions would definitely be appreciated.
 
  http://people.freebsd.org/~msmith/acpica-bsd-20001002.tar.gz

OK, I have a patch for AcpiOsSleep and AcpiOsSleepUsec which I was
involed in recently.
For Semaphore, mtx_* (ported from BSD/OS?) is used in your implementation.
I just wonder if NetBSD people will use traditional lock...

--- OsdSchedule.c-  Mon Oct  2 18:20:32 2000
+++ OsdSchedule.c   Mon Oct  2 18:34:24 2000
@@ -36,6 +36,7 @@
 #include sys/kernel.h
 #include sys/malloc.h
 #include sys/taskqueue.h
+#include machine/clock.h
 
 /*
  * This is a little complicated due to the fact that we need to build and then
@@ -112,11 +113,20 @@
 void
 AcpiOsSleep (UINT32 Seconds, UINT32 Milliseconds)
 {
-tsleep(NULL, 0, "acpislp", (Seconds * hz) + Milliseconds / (1000 * hz));
+inttimo;
+
+timo = (Seconds * hz) + Milliseconds / (1000 * hz);
+if (timo == 0) /* 0 means no timeout... */
+   timo = 1;
+tsleep(NULL, 0, "acpislp", timo);
 }
 
 void
 AcpiOsSleepUsec (UINT32 Microseconds)
 {
-tsleep(NULL, 0, "acpislp", Microseconds / (100 * hz));
+if (Microseconds  1000) { /* the interpreter will be released */
+   AcpiOsSleep(0, Microseconds / 1000);
+} else {
+   DELAY(Microseconds);
+}
 }


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ACPI megapatch

[Mike Smith]

 Great!  This is really great!!  I didn't think we can have ACPICA
 kernel so earlier.

Well, let's see if it works right first.  8)  I hear from Intel that they 
plan to release a new code revision today, so I will be updating when 
they do.  I also hear that Andrew Grover (the chap at Intel that's been 
answering my mails) has just joined acpi-jp (G'day!).

  Comments and suggestions would definitely be appreciated.
  
   http://people.freebsd.org/~msmith/acpica-bsd-20001002.tar.gz
 
 OK, I have a patch for AcpiOsSleep and AcpiOsSleepUsec which I was
 involed in recently.

Thanks, I've incorporated it.

 For Semaphore, mtx_* (ported from BSD/OS?) is used in your implementation.
 I just wonder if NetBSD people will use traditional lock...

I guess that depends on how they decide to thread their kernel.  Right 
now, the code can be built entirely unthreaded and that might be their 
best option.  At some point, they'll have to bite the bullet and 
implement some synchronisation primitives of their own.  If they have any 
common sense, they'll use the BSD/OS model as we have (or some variant on 
it).

-- 
... 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ACPI megapatch

[Mitsuru IWASAKI]

  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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ACPI megapatch

[Warner Losh]

In message [EMAIL PROTECTED] Mitsuru IWASAKI writes:
: Thanks Shiozaki-san, I think `reg' is short for registers of the
: target chip, correct?

Yes.  Traditionally fooreg.h has "hardware" definitions on it.  Device
registers, flag masks and other such things.  Both OLDCARD and NEWCARD
do this.

: How about kernel/userland shareable stuff like ioctl?

Traditionally, these have been placed in fooio.h.

The reason that foo.h hasn't been used more is, as pointed out
earlier, foo.h is generated by config.

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ACPI megapatch

[Mike Smith]

   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...

/me crosses his fingers

  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.

Indeed.  I've just taken the hard path to start with, and got the kernel 
integration (mostly) resolved.  Fortunately, the ACPICA code includes a 
complete user-space ACPI interpreter for just this purpose.  I think some 
of their test code has rotted a bit (eg. their AcpiDump tool), but it 
shouldn't be too hard to get this going.

 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.

This would be very difficult.

 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)

Ack.  I'll bear that in mind.

  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?

The Intel licence on the "generic Unix" version of ACPICA is suitable for 
direct inclusion in FreeBSD.  I'm not sure that the Intel code shouldn't 
be in sys/contrib *anyway*.

  - 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...

If we do things right, we should have little trouble with this.  We have 
some pretty good relations with the right parts of Intel, and as long as 
we keep the code changes clean, they should be happy to accept them.

Given how much work the Intel people went through just to get their code 
into the Linux kernel, I think they will find us *much* more friendly. 8)

-- 
... 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ACPI megapatch

[Mitsuru IWASAKI]

  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.
 
 Indeed.  I've just taken the hard path to start with, and got the kernel 
 integration (mostly) resolved.  Fortunately, the ACPICA code includes a 
 complete user-space ACPI interpreter for just this purpose.  I think some 
 of their test code has rotted a bit (eg. their AcpiDump tool), but it 
 shouldn't be too hard to get this going.

I and acpi-jp folks discussed ACPICA migration last night, there is no
objections so far.  Most of them agreed that evaluation must be done
at least.  Some people already started lerning ACPICA with documents and
source code.
Mike, I'm feeling we need to have a migration plan.  Do you have any
plan on this?
# I have to learn first before my participation to the discussion :-)

  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.
 
 This would be very difficult.

OK, but I'll try, this will be my private project.  I won't complain
anything if most of the code is deleted after migration.  I hope I'll
get some understanding on ACPICA programming.

  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?
 
 The Intel licence on the "generic Unix" version of ACPICA is suitable for 
 direct inclusion in FreeBSD.  I'm not sure that the Intel code shouldn't 
 be in sys/contrib *anyway*.

I see.  I found that we may have additional license terms, but I leave
it to your discretion.

   - 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...
 
 If we do things right, we should have little trouble with this.  We have 
 some pretty good relations with the right parts of Intel, and as long as 
 we keep the code changes clean, they should be happy to accept them.

OK.

 Given how much work the Intel people went through just to get their code 
 into the Linux kernel, I think they will find us *much* more friendly. 8)

# Welcome new committers from Intel :-)


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ACPI megapatch

[Mitsuru IWASAKI]

Hi,

 Ok.  Based on all the suggestions, received today, and some more ideas 
 besides, here's the latest megapatch.
 
  - Move all register I/O into a new file
  - Move event handling into a new file
  - Move headers to acpivar/acpireg/acpiio
  - Move find-RSDT and find-ACPI-owened-memory into acpi_machdep
  - Allocate all resources (except OperationRegions in AML) using
real resources.  AML fix will now be easy though.
  - Remove all ACPI #ifdefs
  - Minor style and commenting fixes
  - Removed unnecessary #includes
 
 Please test this; there are lots of opportunities for error in these 
 changes.  In particular, I am afraid that I may have broken I/O from AML 

I did test it, S1, S5 transition, PowerResource On/OFF and GPE handling
by kernel thread, everything seems OK!
I think nobody has objections for your commit.  I also have something to
commit (SleepOp/StallOp, acpi_disable_events()), I'll do it after you.

 bytecode.  Hopefully with this committed I can finally get to work on the 
 thermal management. 8)

Cool.  On some machine, thermal management requires Embedded Controller I/O.
Anybody working on this?


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ACPI megapatch

[Mike Smith]

  Please test this; there are lots of opportunities for error in these 
  changes.  In particular, I am afraid that I may have broken I/O from AML 
 
 I did test it, S1, S5 transition, PowerResource On/OFF and GPE handling
 by kernel thread, everything seems OK!
 I think nobody has objections for your commit.  I also have something to
 commit (SleepOp/StallOp, acpi_disable_events()), I'll do it after you.

Ok, thanks.  I do it in a moment.

  bytecode.  Hopefully with this committed I can finally get to work on the 
  thermal management. 8)
 
 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.

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(

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?

-- 
... 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ACPI megapatch

[Mitsuru IWASAKI]

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-2901 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ACPI megapatch

[Mike Smith]

 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-2901 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

ACPI megapatch

[Mike Smith]

Here's the latest ACPI megapatch:

 - Move all the register I/O into a separate file
 - Made all the I/O spaces use proper bus resources
 - Allocate the resources in machine-dependant code
 - Map ACPI-used memory in machine-dependant code
 - Create a machine-dependant "acpiprobe" device which just knows
   how to find and set up ACPI for the machine-independant code
 - Remove all the ACPI #ifdefs from non-ACPI code
 - Minor style and commenting fixes

Issues outstanding:

 - Need to remove superfluous headers
 - Need to decide the correct split between sys/acpi.h and 
   sys/dev/acpi/acpi.h in terms of functionality.

Comments, etc. all welcome as usual.




Index: conf/files
===
RCS file: /host/fs/local0/cvs/src/sys/conf/files,v
retrieving revision 1.416
diff -u -r1.416 files
--- conf/files  2000/09/23 22:21:39 1.416
+++ conf/files  2000/09/27 10:17:04
@@ -75,7 +75,8 @@
 #dev/aac/aac_debug.c   optional aac
 dev/aac/aac_disk.c optional aac
 dev/aac/aac_pci.c  optional aac pci
-dev/acpi/acpi.ccount acpi
+dev/acpi/acpi.coptional acpi
+dev/acpi/acpi_io.c optional acpi
 dev/acpi/acpi_powerres.c   optionalacpi
 dev/acpi/aml/aml_amlmem.c  optionalacpi
 dev/acpi/aml/aml_common.c  optionalacpi
Index: dev/acpi/acpi.c
===
RCS file: /host/fs/local0/cvs/src/sys/dev/acpi/acpi.c,v
retrieving revision 1.14
diff -u -r1.14 acpi.c
--- dev/acpi/acpi.c 2000/09/27 05:43:53 1.14
+++ dev/acpi/acpi.c 2000/09/29 07:54:01
@@ -52,7 +52,6 @@
 #include sys/rman.h
 
 #include sys/acpi.h
-
 #include dev/acpi/acpi.h /* for softc */
 
 #include dev/acpi/aml/aml_amlmem.h
@@ -63,38 +62,14 @@
 #include dev/acpi/aml/aml_parse.h
 #include dev/acpi/aml/aml_memman.h
 
-#include machine/acpi_machdep.h  /* for ACPI_BUS_SPACE_IO */
-
-/*
- * ACPI pmap subsystem
- */
-#define ACPI_SMAP_MAX_SIZE 16
-
-struct ACPIaddr {
-   int entries;
-   struct {
-   vm_offset_t pa_base;
-   vm_offset_t va_base;
-   vm_size_t   size;
-   u_int32_t   type;
-   } t [ACPI_SMAP_MAX_SIZE];
-};
-
-static void acpi_pmap_init(void);
-static void acpi_pmap_release(void);
-static vm_offset_t  acpi_pmap_ptv(vm_offset_t pa);
-static vm_offset_t  acpi_pmap_vtp(vm_offset_t va);
-static void acpi_free(struct acpi_softc *sc);
 
 /*
  * These items cannot be in acpi_softc because they are be initialized
  * before probing for the device.
  */
 
-static struct  ACPIaddr acpi_addr;
+struct ACPIaddr acpi_addr;
 struct ACPIrsdp *acpi_rsdp;
-static int acpi_port;
-static int acpi_irq;
 
 /* Character device */
 
@@ -122,32 +97,8 @@
 };
 
 /* 
- * ACPI register I/O 
+ * Miscellaneous utility functions 
  */
-#defineACPI_REGISTER_INPUT 0
-#defineACPI_REGISTER_OUTPUT1
-static void acpi_register_input(u_int32_t ioaddr,
-   u_int32_t *value, u_int32_t size);
-static void acpi_register_output(u_int32_t ioaddr,
-u_int32_t *value, u_int32_t size);
-static void acpi_enable_disable(acpi_softc_t *sc, boolean_t enable);
-static void acpi_io_pm1_status(acpi_softc_t *sc, boolean_t io,
-  u_int32_t *a, u_int32_t *b);
-static void acpi_io_pm1_enable(acpi_softc_t *sc, boolean_t io,
-  u_int32_t *a, u_int32_t *b);
-static void acpi_io_pm1_control(acpi_softc_t *sc, boolean_t io,
-   u_int32_t *a, u_int32_t *b);
-static void acpi_io_pm2_control(acpi_softc_t *sc, boolean_t io, u_int32_t *val);
-static void acpi_io_pm_timer(acpi_softc_t *sc, boolean_t io, u_int32_t *val);
-static void acpi_io_gpe0_status(acpi_softc_t *sc, boolean_t io, u_int32_t *val);
-static void acpi_io_gpe0_enable(acpi_softc_t *sc, boolean_t io, u_int32_t *val);
-static void acpi_io_gpe1_status(acpi_softc_t *sc, boolean_t io, u_int32_t *val);
-static void acpi_io_gpe1_enable(acpi_softc_t *sc, boolean_t io, u_int32_t *val);
-
-/* 
- * Miscellous utility functions 
- */
-static int  acpi_sdt_checksum(struct ACPIsdt * sdt);
 static void acpi_handle_dsdt(acpi_softc_t *sc);
 static void acpi_handle_facp(acpi_softc_t *sc, struct ACPIsdt *facp);
 static int  acpi_handle_rsdt(acpi_softc_t *sc);
@@ -164,8 +115,7 @@
 /* 
  * ACPI events
  */
-static void acpi_process_event(acpi_softc_t *sc,
-  u_int32_t status_a, u_int32_t status_b,
+static void acpi_process_event(acpi_softc_t *sc, u_int32_t status_e,
   u_int32_t status_0, u_int32_t status_1);
 static void acpi_intr(void *data);
 static void acpi_enable_events(acpi_softc_t *sc);
@@ -174,22 +124,22 @@
 /*
  * Bus interface 
  */
-static int  acpi_send_pm_event(acpi_softc_t *sc

Re: ACPI megapatch

[Mitsuru IWASAKI]

Thanks a lot mike, these are mostly acceptable for me.

 Here's the latest ACPI megapatch:
 
  - Move all the register I/O into a separate file

Agreed.

  - Made all the I/O spaces use proper bus resources
  - Allocate the resources in machine-dependant code

I prefer previous patch because most of the code in i386/acpi_machdep.c
can be shared with IA64 I think.

  - Map ACPI-used memory in machine-dependant code

Agreed.

  - Create a machine-dependant "acpiprobe" device which just knows
how to find and set up ACPI for the machine-independant code

I think only machine-dependant sub-routines should be in acpi_machdep.c,
the rest common code should be moved back to dev/acpi/acpi.c.
The first half of acpiprobe_identify() is trying to find rsdp, so
renaming it to acpi_find_rsdp() (returns struct ACPIrsdp * or NULL),
moving the rest of acpiprobe_identify() to dev/acpi/acpi.c:acpi_identify()
and calling acpi_find_rsdp() from acpi_identify() would be better for me.
acpiprobe_mapmem() seems machine-dependant, so just renaming (acpi_mapmem() ?)
would be enough.
acpiprobe_facp(), I think, is MI, should be moved dev/acpi/acpi.c and
renamed (acpi_find_facp() ?).

In summary, my suggestions are
 - i386/i386/acpi_machdep.c
acpi_find_rsdp() and acpi_mapmem()
 - dev/acpi/acpi.c
acpi_identify() and acpi_find_facp()

  - Remove all the ACPI #ifdefs from non-ACPI code
  - Minor style and commenting fixes

Completely agreed.

 Issues outstanding:
 
  - Need to remove superfluous headers
  - Need to decide the correct split between sys/acpi.h and 
sys/dev/acpi/acpi.h in terms of functionality.

I'd like to move and rename them as I said in my previous mail,
sys/acpi.h - sys/dev/acpi/acpi.h
shared by both kernel and userland programs
sys/dev/acpi/acpi.h - sys/dev/acpi/acpivar.h
shared within kernel code (acpi stuff and related drivers)

That's my rough understanding, but I could be wrong :-)

Thanks


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ACPI megapatch

[T.SHIOZAKI]

From: Mitsuru IWASAKI [EMAIL PROTECTED]
Subject: [acpi-jp 691] Re: ACPI megapatch
Date: Fri, 29 Sep 2000 22:05:17 +0900
Message-ID: [EMAIL PROTECTED]

  Issues outstanding:
   - Need to remove superfluous headers
   - Need to decide the correct split between sys/acpi.h and 
 sys/dev/acpi/acpi.h in terms of functionality.
 I'd like to move and rename them as I said in my previous mail,
 sys/acpi.h - sys/dev/acpi/acpi.h
   shared by both kernel and userland programs
 sys/dev/acpi/acpi.h - sys/dev/acpi/acpivar.h
   shared within kernel code (acpi stuff and related drivers)

IMHO, it's desirable to use the name "acpi.h", because of conflict
with the file dumped by /usr/sbin/config.

I love :
  fooreg.h : device dependent and implementation independent
 structures, macros, and others.
  foovar.h : implementation dependent ones.


--
Takuya SHIOZAKI



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: [acpi-jp 692] Re: ACPI megapatch

[T.SHIOZAKI]

From: "T.SHIOZAKI" [EMAIL PROTECTED]
Subject: [acpi-jp 692] Re: ACPI megapatch
Date: Fri, 29 Sep 2000 22:41:39 +0900 (JST)
Message-ID: [EMAIL PROTECTED]

 IMHO, it's desirable to use the name "acpi.h", because of conflict

Sorry, "it's desirable to avoid using ...".


--
Takuya SHIOZAKI



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ACPI megapatch

[Mitsuru IWASAKI]

Hi,

  I'd like to move and rename them as I said in my previous mail,
  sys/acpi.h - sys/dev/acpi/acpi.h
  shared by both kernel and userland programs
  sys/dev/acpi/acpi.h - sys/dev/acpi/acpivar.h
  shared within kernel code (acpi stuff and related drivers)
 
 IMHO, it's desirable to use the name "acpi.h", because of conflict
 with the file dumped by /usr/sbin/config.
 
 I love :
   fooreg.h : device dependent and implementation independent
  structures, macros, and others.
   foovar.h : implementation dependent ones.

Thanks Shiozaki-san, I think `reg' is short for registers of the
target chip, correct?  In ACPI's case, PM1 register and some such
and maybe definitions for ACPI tables.
How about kernel/userland shareable stuff like ioctl?  for example,
usb(4) has this kind of definitions in dev/usb/usb.h, not in usbreg.h.
Is this a special case violating the guideline?
I think we can distinguish them like "usb.h" and dev/usb/usb.h,
also we will stop generating acpi.h in kernel build directory.

Thanks


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ACPI megapatch

[Mitsuru IWASAKI]

 In summary, my suggestions are
  - i386/i386/acpi_machdep.c
   acpi_find_rsdp() and acpi_mapmem()
  - dev/acpi/acpi.c
   acpi_identify() and acpi_find_facp()

Here is a patch for your megapatch at
http://people.FreeBSD.org/~iwasaki/acpi/patch-for-megapatch.diff
I'll be happy if you accept and commit this :-)

Thanks!


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ACPI megapatch

[takawata]

In message [EMAIL PROTECTED], Mitsuru IWASAKI wrote:
 In summary, my suggestions are
  - i386/i386/acpi_machdep.c
  acpi_find_rsdp() and acpi_mapmem()
  - dev/acpi/acpi.c
  acpi_identify() and acpi_find_facp()

Here is a patch for your megapatch at
http://people.FreeBSD.org/~iwasaki/acpi/patch-for-megapatch.diff
I'll be happy if you accept and commit this :-)


I think it is better bus attachment code is in MD part than in MI part.
And MD bus attachment code calls MI bus attachment code.

For example,Current acpi_probe code rename to acpi_probesubr and
 call it from acpi_probe in acpi_machdep.c . 

And probe method and identify method should not be confused.
Memory area check etc can be in MD acpi probe code.

Takanori Watanabe
a href="http://www.planet.sci.kobe-u.ac.jp/~takawata/key.html"
Public Key/a
Key fingerprint =  2C 51 E2 78 2C E1 C5 2D  0F F1 20 A3 11 3A 62 2A 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ACPI megapatch

[Mitsuru IWASAKI]

 Here is a patch for your megapatch at
 http://people.FreeBSD.org/~iwasaki/acpi/patch-for-megapatch.diff
 I'll be happy if you accept and commit this :-)
 
 
 I think it is better bus attachment code is in MD part than in MI part.
 And MD bus attachment code calls MI bus attachment code.
 
 For example,Current acpi_probe code rename to acpi_probesubr and
  call it from acpi_probe in acpi_machdep.c . 

Hmm, I think you're talking about BI/BD.  Most of ACPI code must be
shared between IA32/IA64 (even bus interface code). Difference between
them is very limited, we can put them in acpi_machdep.c.  I like this
model.  NetBSD's pci code take this one (dev/pci/pci.c has MI code
like pcimattach(), arch/*/pci/pci_machdep.c have a set of MD
sub-routines for the specific machine architecture such as
pci_conf_read().).  I'm not sure this is correct or not, but it seems
reasonable for me.

 And probe method and identify method should not be confused.
 Memory area check etc can be in MD acpi probe code.

Yes, I think it's in acpi_machdep.c :-)
if not, which one?

Thanks


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ACPI megapatch

[Mike Smith]

   I'd like to move and rename them as I said in my previous mail,
   sys/acpi.h - sys/dev/acpi/acpi.h
 shared by both kernel and userland programs
   sys/dev/acpi/acpi.h - sys/dev/acpi/acpivar.h
 shared within kernel code (acpi stuff and related drivers)
  
  IMHO, it's desirable to use the name "acpi.h", because of conflict
  with the file dumped by /usr/sbin/config.
  
  I love :
fooreg.h : device dependent and implementation independent
   structures, macros, and others.
foovar.h : implementation dependent ones.
 
 Thanks Shiozaki-san, I think `reg' is short for registers of the
 target chip, correct?  In ACPI's case, PM1 register and some such
 and maybe definitions for ACPI tables.
 How about kernel/userland shareable stuff like ioctl?  for example,
 usb(4) has this kind of definitions in dev/usb/usb.h, not in usbreg.h.
 Is this a special case violating the guideline?
 I think we can distinguish them like "usb.h" and dev/usb/usb.h,
 also we will stop generating acpi.h in kernel build directory.

Typically you would have:

acpivar.h   Data structures defined by implementation
acpireg.h   Data structures defined by interface
acpiio.hInterface to userland

Since we're all in agreement, I'll move to these.

-- 
... 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ACPI megapatch

[Mike Smith]

 Thanks a lot mike, these are mostly acceptable for me.
 
   - Made all the I/O spaces use proper bus resources
   - Allocate the resources in machine-dependant code
 
 I prefer previous patch because most of the code in i386/acpi_machdep.c
 can be shared with IA64 I think.

I'm not so sure about that.  I suspect that the IA64 code is going to be
using the 'generic address' structures and the x-fields in eg. the FACT.
It won't be using the bios signature search either, or the int15
interface.  Realistically, the code in acpi_machdep.c is very simple.a

I also think that if I'm going to continue to use a private identify 
method to attach ACPI (IMO a good idea) then I want to keep its 
implementation as separate from the 'generic' ACPI code as possible.  The 
pmap interface and one checksum routine is all that the current division 
uses, and that's fairly clean.

   - Create a machine-dependant "acpiprobe" device which just knows
 how to find and set up ACPI for the machine-independant code
 
 I think only machine-dependant sub-routines should be in acpi_machdep.c,
 the rest common code should be moved back to dev/acpi/acpi.c.
 The first half of acpiprobe_identify() is trying to find rsdp, so
 renaming it to acpi_find_rsdp() (returns struct ACPIrsdp * or NULL),
 moving the rest of acpiprobe_identify() to dev/acpi/acpi.c:acpi_identify()
 and calling acpi_find_rsdp() from acpi_identify() would be better for me.
 acpiprobe_mapmem() seems machine-dependant, so just renaming (acpi_mapmem() ?)
 would be enough.
 acpiprobe_facp(), I think, is MI, should be moved dev/acpi/acpi.c and
 renamed (acpi_find_facp() ?).

That would be possible, but as I mentioned above, adding support for the 
generic-address formats is going to make things *very* messy.

I get a strong feeling that whoever was responsible for making sure that 
ACPI stayed sensible has quit or been fired.  There are a lot of recent 
changes that are just plain *stupid*.

-- 
... 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ACPI megapatch

[Mike Smith]

 And probe method and identify method should not be confused.
 Memory area check etc can be in MD acpi probe code.

Can you explain what you mean here a bit more?  The FACT lookup and 
resource establishment need to be done in the identify routine, not the 
probe routine...

-- 
... 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ACPI megapatch

[Mitsuru IWASAKI]

Hi,

  I prefer previous patch because most of the code in i386/acpi_machdep.c
  can be shared with IA64 I think.
 
 I'm not so sure about that.  I suspect that the IA64 code is going to be
 using the 'generic address' structures and the x-fields in eg. the FACT.
 It won't be using the bios signature search either, or the int15
 interface.  Realistically, the code in acpi_machdep.c is very simple.a
 
 I also think that if I'm going to continue to use a private identify 
 method to attach ACPI (IMO a good idea) then I want to keep its 
 implementation as separate from the 'generic' ACPI code as possible.  The 
 pmap interface and one checksum routine is all that the current division 
 uses, and that's fairly clean.

OK, understood.  How about having MD sub-routine in the same interface
(say acpi_set_resources() or acpi_create_instance() or whatever) for
i386 and ia64?  Then generic ACPI identify method calls suitable
sub-routine depending on machine architecture.

 - i386/i386/acpi_machdep.c
acpi_set_resources() (ex-acpiprobe_identify())
 - ia64/ia64/acpi_machdep.c
acpi_set_resources()

 - dev/acpi/acpi.c
acpi_identify()
this is quite simple, just do simple error checking and
call acpi_set_resources() then return.

Is this good for you too?


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ACPI megapatch

[Mike Smith]

 OK, understood.  How about having MD sub-routine in the same interface
 (say acpi_set_resources() or acpi_create_instance() or whatever) for
 i386 and ia64?  Then generic ACPI identify method calls suitable
 sub-routine depending on machine architecture.
 
  - i386/i386/acpi_machdep.c
   acpi_set_resources() (ex-acpiprobe_identify())
  - ia64/ia64/acpi_machdep.c
   acpi_set_resources()
 
  - dev/acpi/acpi.c
   acpi_identify()
   this is quite simple, just do simple error checking and
   call acpi_set_resources() then return.
 
 Is this good for you too?

It's closer.  I just realised that we need a way of creating resources 
for SystemIO and SystemMemory AML objects as well.  I think I've worked 
this out too; I'll try to get it worked out today and send you a patch 
this evening.  I'm following your request to get the bus-dependant parts 
split out, but I do *not* think that we should be committing any of the 
NetBSD code to the FreeBSD source tree (this has been a failure in the 
past), or vice versa.

Meanwhile, my laptop is getting very hot. 8)

-- 
... 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ACPI megapatch

[Mike Smith]

Ok.  Based on all the suggestions, received today, and some more ideas 
besides, here's the latest megapatch.

 - Move all register I/O into a new file
 - Move event handling into a new file
 - Move headers to acpivar/acpireg/acpiio
 - Move find-RSDT and find-ACPI-owened-memory into acpi_machdep
 - Allocate all resources (except OperationRegions in AML) using
   real resources.  AML fix will now be easy though.
 - Remove all ACPI #ifdefs
 - Minor style and commenting fixes
 - Removed unnecessary #includes

Please test this; there are lots of opportunities for error in these 
changes.  In particular, I am afraid that I may have broken I/O from AML 
bytecode.  Hopefully with this committed I can finally get to work on the 
thermal management. 8)




 acpi.diff.gz

... 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

Re: ACPI megapatch

[Mike Smith]

As Iwasaki-san pointed out, I left acpi_event.c out of the previous 
megapatch.  Rather than resend the entire thing, you can fetch the 
complete patch from:

  http://people.freebsd.org/~msmith/acpi-2929.diff.gz

Regards,
-- 
... 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message