Date: Thu, 15 Jul 2004 12:18:09 -0700 From: Nate Lawson <nate@root.org> To: John Baldwin <jhb@FreeBSD.org> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/acpica acpi_pci.c Message-ID: <40F6D871.1090207@root.org> In-Reply-To: <200407151418.01839.jhb@FreeBSD.org> References: <200406231508.i5NF8egh052377@repoman.freebsd.org> <200406231122.04154.jhb@FreeBSD.org> <20040715161403.GA741@laptop.6bone.nl> <200407151418.01839.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[Followups to the acpi list]
John Baldwin wrote:
> On Thursday 15 July 2004 12:14 pm, Mark Santcroos wrote:
>>You forgot to mention that this commit breaks acpi_video ;-)
>>
>>The fact that "\_SB_.PCI0.AGP_.VID_" now no longer is "unknown", means that
>>it is not probed anymore.
>>
>>The result of that is that acpi_video can't attach anymore of course.
>
> That's because acpi_video is really a PCI driver. :) The device it is
> attaching too is a PCI device, not an ACPI device, hence the confusion. I
> have some early work started on a vga_pci driver that would have child
> devices like acpi_video0, drm0, agp0 (for Intel onboard graphics), and dpms0.
I ran into this fundamental mismatch in building the infrastructure for
the floppy attachment. You might have an ACPI handle namespace like this:
_SB
PCI0
LPC
FDC0
FDD0
FOOBAR
USB0
With a FreeBSD device hierarchy of:
acpi0
fdc0
fd0
foobar
pcib0
pci0
uhci0
Currently, we start with a flat device space when probing children:
acpi0
pci0
isa0
fdc0
fd0
foobar
uhci0
And then let each bus driver rework its children. PCI updates its child
handles (USB0), deleting the initial device and adding a new one. FDC
does the same thing.
John is right in that acpi_video needs to attach to video_pci and not
acpi directly. The new acpi_scan_children method should help do this
without creating binary dependencies between drivers.
--
-Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40F6D871.1090207>