YONETANI Tomokazu wrote:
quoted text > 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).
quoted text > > * 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.
quoted text > > * 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.
quoted text > > * 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?
quoted text > > 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
