Re: ACPI megapatch
> > 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!). Welcome to acpi-jp ML, Andrew and Mike! I've just tried acpica-bsd-20001003, this is greater than before :-) It seems GPE events are handled correctly on my PORTEGE. BTW, System sleep transition and PowerResource manipulation are not implemented yet where we have done already. # I'm not sure we did in right way though :-) How is the status on them? May I try to implement them porting our old code? > > OK, I have a patch for AcpiOsSleep and AcpiOsSleepUsec which I was > > involed in recently. > > Thanks, I've incorporated it. Ack, thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI megapatch
> 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
> 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
#include
#include
+#include
/*
* 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
> 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
> > > 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
> > 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
> > > 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
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
> >>> 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
>>> 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
Re: ACPI megapatch
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
> > 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
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
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
Re: ACPI megapatch
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
> 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
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
> 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
> 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
> > > I'd like to move and rename them as I said in my previous mail, > > > -> > > > shared by both kernel and userland programs > > > -> > > > 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 , > 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
> >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
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 http://www.planet.sci.kobe-u.ac.jp/~takawata/key.html"> Public Key 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
> 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
Hi, > > I'd like to move and rename them as I said in my previous mail, > > -> > > shared by both kernel and userland programs > > -> > > 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 , 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-jp 692] Re: ACPI megapatch
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
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 and > > in terms of functionality. > I'd like to move and rename them as I said in my previous mail, > -> > shared by both kernel and userland programs > -> > 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 megapatch
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 and > in terms of functionality. I'd like to move and rename them as I said in my previous mail, -> shared by both kernel and userland programs -> 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
