Re: acpivga(4) v. MI display controls

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

On Sat, Oct 16, 2010 at 05:45:51PM -0500, David Young wrote:
> > 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?

The canonical example is perhaps the LPC bridge. This is also the case
brought up by Quentin in an earlier revision of this discussion. The
following takes a very specific point of view to demonstrate the issue.

Now raise the abstraction so that we do not talk about any specific chip. 
The so-called "power resource", if it exists, is shared by all devices under
the bridge. The concept of "power resource" itself can be just bad abstractions 
used in the ACPI code, but there are no guarantees that manipulating it
won't turn off the chip (or stop processing in the chip or whatever this may
mean). (Actually, I have seen several systems where turning power resources
on/off actually turns hardware on/off.)

The power resource code implements several sanity checks, namely (a) a
parent can not be turned on/off if its children are not on/off and (b)
reference counting prevents turning anything off if something else is using
the power resource.  Neither (a) nor (b) really works in NetBSD due reasons
mentioned. Because the ACPI tree is not synchronized with the real tree,
none of the devices under the bridge claim the power resource when they
attach. But the real trick is that the firmware may turn a power resource
off for instance when we enter a sleep state. Upon resume, we need to turn
it back on, but we can not do it blindly. Another question is whether we
have sufficient abstractions for device power state in the real tree.

For example, most of the devices are incorrectly attached (to acpi0) here:

            LPC   [06] [  ] (PCI) @ 0x00:0x00:0x1F:0x00 <ichlpcib0>
                SIO   [06] [  ]
                PIC   [06] [  ]
                TIMR  [06] [  ] <attimer1>
                HPET  [06] [  ] <hpet0>
                DMAC  [06] [  ] 
                SPKR  [06] [  ] <pcppi1>
                FPU   [06] [  ] <npx1>
                RTC   [06] [  ]
                KBD   [06] [  ] <pckbc1>
                MOU   [06] [  ] <pckbc2>
                DURT  [06] [ W]
                DLPT  [06] [  ]
                DECP  [06] [  ]
                FIR   [06] [  ]
                TPM   [06] [  ]
                EC    [06] [  ] <acpiec0>
                    PUBS  [11] [  ]
                    BAT0  [06] [  ] <acpibat0>
                    BAT1  [06] [  ]
                    BAT2  [06] [  ]
                    AC    [06] [  ] <acpiacad0>
                    HKEY  [06] [  ] <thinkpad0>

The above example also reveals the devices (in this machine) that reference
the ACPI embedded controller's operation regions. Thus, the three children
should be attached under acpiec(4), or more conservatively, these should at
least never be attached before acpiec(4).

Hope the above made some sense,

Jukka.