Re: acpivga(4) v. MI display controls

[Eduardo Horvath <eeh%NetBSD.org@localhost>]

On Sat, 16 Oct 2010, Jukka Ruohonen wrote:

> 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.

I agree with this, even for OF machines.  I've always considered the 
existing scheme using device_register() as an ugly hack, and I hate to 
contemplate the incredibly ugly hoops we had to jump through to make the 
PCI framework function with OF, especially on machines where config space 
accesses to non-existant devices can hang the processor.

What I'd like to see is a device tree generated from the firmware 
information if available driving the autoconfig process.  Any MD 
operations should be done through MI code manipulating properties on the 
device node, which are then trapped by MD code interact with firmware.

Eduardo