> > 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
> 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 th
> 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 controlle
> 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
> > > 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
> > > k
> > 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 port
> > > 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
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.
> >>> 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
>>> 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 necessar
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 necessar
> > 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 objecti
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
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 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
> 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
>
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 bio
> 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 ac
> 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 su
> > > 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 th
> >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
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/
> 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 a
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
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 d
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 bet
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
27 matches
Mail list logo
