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
On 10/20/2010 09:01, Jukka Ruohonen wrote:
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
This is the other main difference to OF: on ports using OF, it is
always available. ACPI on i386 is not (yet).
It's not quite as simple as ports using OF and ports not using OF.
For example, while I have personal experience with only the one unit,
On Fri, Oct 15, 2010 at 07:53:53PM -0500, David Young 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
On Fri, Oct 15, 2010 at 08:29:57AM -0400, der Mouse wrote:
ACPI may be the source of the information, but that doesn't mean it has
to be how the autoconf tree is constructed.
Compare and contrast with how NetBSD/sparc uses the OF (or is it OBP?
I'm not sure) device tree to drive autoconf,
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
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
On Fri, Oct 15, 2010 at 08:26:34AM +0300, Jukka Ruohonen wrote:
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
On Fri, Oct 15, 2010 at 08:26:34AM +0300, Jukka Ruohonen wrote:
This was discussed during the development process.
Where?
Martin
On Fri, Oct 15, 2010 at 10:10:18AM +0200, Martin Husemann wrote:
On Fri, Oct 15, 2010 at 08:26:34AM +0300, Jukka Ruohonen wrote:
This was discussed during the development process.
Where?
Already when this was first presented in 2008:
On 10/15/2010 01:50, 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).
How would display(4) relate to wsdisplay(4) in this approach?
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
On 15.10.10 01:50, David Young wrote:
It's important to be able to control display switching and brightness,
but I don't think that those functions should reside in acpivga(4) and
acpiout(4) devices under acpi(4). For example, I read in somebody's
dmesg today:
acpivga0 at acpi0 (GFX0):
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 ...
14 matches
Mail list logo
