Re: acpivga(4) v. MI display controls

[David Young <dyoung%pobox.com@localhost>]

On Fri, Oct 15, 2010 at 08:26:34AM +0300, Jukka Ruohonen wrote:
> On Thu, Oct 14, 2010 at 06:50:30PM -0500, David Young wrote:
> > Rather than attaching new nodes at acpi0, the system should let ACPI
> > BIOS inform the autoconfiguration process, which should attach one or
> > more instances of a new, MI device, display(4).  For example:
> > 
> > vga0 at pci0 device ... function ...
> > display0 at vga0: Ext. Monitor, head 0, bios detect (ACPI CRT1)
> > display1 at vga0: TV, head 0, bios detect (ACPI DTV1)
> > display2 at vga0: Unknown Output Device, head 0, bios detect (ACPI LCD)
> >
> > In this way, no single device has two representations in the device tree
> > (think about the consequences, they're not pretty), and every device
> > appears in the most appropriate place in the device tree for the purpose
> > of suspending, resuming, detaching and re-attaching it.

Jukka,

> This was discussed during the development process.

Joerg brought a similar objection as I have, in
<http://mail-index.netbsd.org/tech-kern/2008/12/05/msg003747.html>, but
I have not found any acknowledgement or discussion.  He wrote:

> OK, what this code is doing is essentially attach a device to the acpi
> tree that really refers to a PCI device. Can we please get this to
> attach as child of vga0 by checking for a device matching the PCI
> address of vga0, that also provides _DOD and _DOS. This would prevent
> accessing vga0 on resume before it has been reset.

Joerg calls attention in that last sentence to the possibility of
defects in suspend/resume that arise when a device is represented twice
in the device tree.  Sounds familiar. :-)

> Sure, the above is the
> ideal case. Yet once again I need to remind that we can not hold back
> important acpi(4) work because the perfect abstraction has not arrived,

My intention was not to compare the ACPI implementation against
some ideal, but to compare it with the rough consensus about what
should be done, and to bring attention to real defects in the status
quo.  der Mouse has pointed out that NetBSD already uses the
information from OpenFirmware (OF) to guide autoconfiguration of,
for example, PCI devices.  That's not an ideal, that's running
code! :-) NetBSD should use information from ACPI similarly to OF
information.

> and no one seems to really know how it should be done.

ISTM that more than one developer can, and has, described in a broad
outline how it should be done.  For example, I can outline how
device_register() can be used to put ACPI information into MI device
properties for device-attachment hooks to read back out.  I'm happy to
give more detailed suggestions, too.  I even have some running code for
matching PCI buses and devices with information about corresponding MMIO
extents derived from PCI BIOS.

> The task is not trivial. On modern x86, practically *everything* that
> attachs has an ACPI counterpart. In a way we are thinking this backwards:
> the attachment should perhaps be done via ACPI that has information about
> the "natural" device tree (I recommend to boot with ACPIVERBOSE option and
> observe the output). This is how it is supposedly done in Windows.

I'm not sure I understand what you mean by the "'natural' device tree".
I think you may have drawn a line between "virtual" and "real" device
hierarchies and assigned ACPI to a different category than I would.
Again, I'm not sure I've taken your meaning right.

It's just occurred to me that it may help to form a group to discuss
how BIOS information should be encoded and conveyed from MD code to MI
drivers in NetBSD.  By setting standards, we may help developers on
every port leverage others' knowledge and work.  What do you think?

Dave

-- 
David Young             OJC Technologies
dyoung%ojctech.com@localhost      Urbana, IL * (217) 278-3933