From owner-acpi-jp@jp.FreeBSD.org Mon Oct  7 06:32:18 2002
Received: (from daemon@localhost)
	by castle.jp.FreeBSD.org (8.11.6+3.4W/8.11.3) id g96LWI884795;
	Mon, 7 Oct 2002 06:32:18 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from mail.speakeasy.net (mail16.speakeasy.net [216.254.0.216])
	by castle.jp.FreeBSD.org (8.11.6+3.4W/8.11.3) with ESMTP/inet id g96LWF384790
	for <acpi-jp@jp.FreeBSD.org>; Mon, 7 Oct 2002 06:32:16 +0900 (JST)
	(envelope-from jhb@FreeBSD.org)
Received: (qmail 28382 invoked from network); 6 Oct 2002 21:32:14 -0000
Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63])
          (envelope-sender <jhb@FreeBSD.org>)
          by mail16.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP
          for <acpi-jp@jp.FreeBSD.org>; 6 Oct 2002 21:32:14 -0000
Received: from laptop.baldwin.cx (laptop.baldwin.cx [192.168.0.4])
	by server.baldwin.cx (8.12.5/8.12.5) with ESMTP id g96LWBLF051324
	for <acpi-jp@jp.FreeBSD.org>; Sun, 6 Oct 2002 17:32:11 -0400 (EDT)
	(envelope-from jhb@FreeBSD.org)
Message-ID: <XFMail.20021006173216.jhb@FreeBSD.org>
X-Mailer: XFMail 1.5.2 on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <DAD35618-D89A-11D6-86D5-0050E4660701@freebsd.org>
From: John Baldwin <jhb@freebsd.org>
To: acpi-jp@jp.FreeBSD.org
Reply-To: acpi-jp@jp.FreeBSD.org
Precedence: list
Date: Sun, 06 Oct 2002 17:32:16 -0400
X-Sequence: acpi-jp 1883
Subject: [acpi-jp 1883] RE: acpi-jp@jp.FreeBSD.org
Errors-To: owner-acpi-jp@jp.FreeBSD.org
Sender: owner-acpi-jp@jp.FreeBSD.org
X-Originator: jhb@FreeBSD.org
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+020902


On 05-Oct-2002 Michael Smith wrote:
> 
> On Friday, October 4, 2002, at 12:08 PM, Takanori Watanabe wrote:
> 
>>>> devices, to route PCI-PCI bus interrupt, to use ATA bus timing 
>>>> setting
>>>> informations, to handle ACPI PCI hotplug device, and etc.
>>>>
>>> Yes, however we attach things (and under ACPI it is still more or less
>>> expected that you attach things) to the bus that enumerates them.
>>>
>>> PCI bridges enumerate PCI devices, so PCI devices go under PCI 
>>> bridges.
>>>
>>> Stuff that's enumerated by ACPI ends up under ACPI.
>>
>> It is true that ACPI namespace sometimes form odd structure, but
>> ACPI devices often cannot be identified without
>> existing bus enumeration mechanism, especially
>> other than ISA-like devices.
>>
>> So it is meaningful that device tree have nearly same
>> layout as ACPI namespace as far as possible.
> 
> This is nothing more than a convenience to the debugger; since we
> can't guarantee that the ACPI namespace will resemble the device
> tree, we shouldn't expect that it does at all.
> 
> When it comes to matching devices enumerated by means other than
> ACPI with devices in the ACPI namespace, we're talking about PCI
> these days and the _ADR resource is adequate as long as the bus
> number is correct, and ACPI tells us we can get the bus number
> either from _ADR directly or from the device's scope in the ACPI
> namespace.

Er, _ADR is just device and function.  The bus is inherit from the
parent device.
 
>> I don't object some ISA-like devices are direct child of acpi bus.
>> It is  more better that ISA bus children is automatically
>> child of ACPI-bus children.
> 
> Are you suggesting we should have an acpi_isab bus that replaces
> the standard isab and hang the "manually" probed ISA devices off
> it if there is ACPI in the system?  That works for me.

Well, an ACPI driver for PCI-ISA bridges and an ACPI driver for
"isa" busses perhaps. :)  This would allow us to cleanly not use
the PnPBIOS when ACPI is in use for ISA busses.

-- 

John Baldwin <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/
