Re: acpivga(4) v. MI display controls

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

On Sat, Oct 16, 2010 at 03:22:52PM +0300, 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.

It sounds like your idea of ACPI's role in autoconfiguration is not
too different from Martin's and mine, but you may be using different
language to describe it.

I think that ACPI should definitely guide autoconfiguration, if ACPI is
available.

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

What devices do you have in mind?

Dave

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