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
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.
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
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
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
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
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.
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
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.
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
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
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
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.
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" de
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
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
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 .
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
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
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
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
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
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
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
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
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
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
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
28 matches
Mail list logo
