Re: acpivga(4) v. MI display controls

[Jukka Ruohonen <jruohonen%iki.fi@localhost>]

On Sat, Oct 16, 2010 at 12:24:12PM +0200, Martin Husemann wrote:
> The main difference that I understood seems to be what you call virtual
> and natural device trees: in OF world we guide the whole autoconfig tree
> along the OF device tree, with differences close to the leafs (i.e. the
> scsibus der Mouse mentioned). At every point during autoconfig we can
> make sure to have enough OF information already available during the
> device_register() call. The only problem we ran into so far, IIRC, is the
> id of FC disks for boot device detection, but we worked around that pretty
> easily.

This seems to be what is needed on x86 as well. The only way to eliminate
such things as PCI_BUS_FIXUP etc. and several existing bus_space(9)
conflicts is probably to parse the firmware tree as the first thing, and
then utilize this information at each attachment step. This is exactly what
I meant by noting that we tend to think this backwards; perhaps ACPI should
drive the autoconfiguration, not vice versa. It is problematic to think
that we can continue as business as usual, and then ACPI drivers go and seek
their real counterparts that have been attached without using ACPI in the
first place.

Another thing is the actual device tree. For instance, currently, even with
the fine work done with pmf(9), in some corner cases we may power off a
device before its children are turned off because the device tree is
partially arbitrary.

> I don't think the auto-config time and in/out distinction you draw
> realy is that relevant. With OF we still can call firmware methods any
> time later, and we could take callbacks (though I don't think there are
> any relevant). ACPI seems to do more in that area, but I fail to see the
> fundamental problem, assuming you manage to get ACPI device tree traversal
> and autoconfig tree building "synchronized" somehow (i.e. have all needed
> ACPI information available for device_register()).

There are certain firmware methods that can be assumed to be universal. 
Examples include so-called power resources, but also wake-up interrupts are
done via the firmware (think: WoL, suspending devices at runtime, etc.).
This means that we likely need to touch such essentials as device_t in
order to device_register() callbacks; we have no a priori knowledge about
the drivers for which the vendor has implemented such firmware methods.

But then we have cases like acpicpu(4). Here the firmware may actually
dynamically at run-time change the I/O addresses we ought to write to or
change the MSR values to be written, observing bus activity is done via the
firmware, and so forth.  While this is not the best of example because CPU
is MD, there are other comparable cases with MI drivers. Particularly, as
is seen with acpivga(4), several ACPI-specific interrupts ("notifys") need
to be delivered to real drivers.

- Jukka.