Re: Some questions regarding ACPI

[Hasso Tepper <hasso@xxxxxxxxx>]

YONETANI Tomokazu wrote:
> On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> > I'm working on bringing in some laptop (and especially thinkpad)
> > specific ACPI code from FreeBSD into DragonFly. I never touched ACPI
> > stuff before and haven't followed it much either, so I have some
> > questions.
>
> So you want to port some of ACPI support drivers, or to do a fresh port
> of ACPI driver from FreeBSD?

I'm only interested in support drivers and the reason is pure practical - 
newer thinkpads handle less and less hotkeys etc in hardware and require 
support form OS. acpi_ibm and acpi_video are examples of such modules 
which would help a lot of these newer thinkpad users.

acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).

> > * FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in
> >   DragonFly and why?
>
> The current ACPI driver in DragonFly is based on that of FreeBSD as of
> end of June, 2004, plus some fixes brought in later (and ACPICA part
> has been updated twice since then).  That was before they introduced
> the MPSAFE changes into ACPI code, and we use critical section
> (crit_{enter,exit}) in most places (and lockmgr lock in a few place).

Mkay. Will look at more closely.

> > * As far as I can see, PCI integration is commented out in DragonFly.
> >   What's the state of it and why?
>
> When we replaced the implementation taken from FreeBSD 4.x with that
> brought from FreeBSD 5.x, which added the PCI part, many people
> experienced problems until they turned off ACPI completely, or add
> "pci" to "debug.acpi.disabled" loader variable.  AFAIK the PCI part in
> the ACPI driver almost hasn't been adjusted to work with our version of
> PCI code.

I'm afraid that it's beyond my skills, but while looking at acpi_video I 
discovered that it's hard to handle correctly without PCI support.

> > * platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't
> > think that this is something pc32 specific in it and it should work
> > in pc64 laptops as well. Any objections to move it into
> >   dev/acpica5/acpi_toshiba/ ?
>
> In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
> later moved into acpi_support.  That change hasn't hit our tree (in
> fact, we have no acpi support drivers other than that).  It seems that
> FreeBSD has them in dev/acpi_support now, and we for some reason have
> that directory in our CVS repository (but containing no files in it).

I don't see it ;). Makes sense though. So, any objections if I move 
acpi_toshiba into sys/dev/acpi_support and add new acpi_thinkpad there as 
well? 

> > What's the current status of ACPI in general? AFAICS our acpica is
> > quite old - what needs to be done to bring in newer one?
>
> Actually, it's not very important to keep just ACPICA latest, but
> if you bring the ACPI driver from FreeBSD you need to bring ACPICA code
> that matches their version, and it IS important.  And it generally
> requires you much work to just update ACPICA part anyway because of how
> they change things on every release.

Someone else has to do it :).

Thanks for info.


-- 
Hasso