From owner-acpi-jp@jp.FreeBSD.org Tue Oct  8 04:23:05 2002
Received: (from daemon@localhost)
	by castle.jp.FreeBSD.org (8.11.6+3.4W/8.11.3) id g97JN5035751;
	Tue, 8 Oct 2002 04:23:05 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from mail.speakeasy.net (mail11.speakeasy.net [216.254.0.211])
	by castle.jp.FreeBSD.org (8.11.6+3.4W/8.11.3) with ESMTP/inet id g97JN3335746
	for <acpi-jp@jp.FreeBSD.org>; Tue, 8 Oct 2002 04:23:03 +0900 (JST)
	(envelope-from jhb@FreeBSD.org)
Received: (qmail 24505 invoked from network); 7 Oct 2002 19:23:01 -0000
Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63])
          (envelope-sender <jhb@FreeBSD.org>)
          by mail11.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP
          for <acpi-jp@jp.FreeBSD.org>; 7 Oct 2002 19:23:01 -0000
Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1])
	by server.baldwin.cx (8.12.6/8.12.6) with ESMTP id g97JMxn5003117;
	Mon, 7 Oct 2002 15:22:59 -0400 (EDT)
	(envelope-from jhb@FreeBSD.org)
Message-ID: <XFMail.20021007152303.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: <4C8322EE-DA26-11D6-B432-0050E4660701@freebsd.org>
From: John Baldwin <jhb@freebsd.org>
To: Michael Smith <msmith@freebsd.org>
Cc: acpi-jp@jp.FreeBSD.org
Reply-To: acpi-jp@jp.FreeBSD.org
Precedence: list
Date: Mon, 07 Oct 2002 15:23:03 -0400
X-Sequence: acpi-jp 1885
Subject: [acpi-jp 1885] 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 07-Oct-2002 Michael Smith wrote:
> 
> On Sunday, October 6, 2002, at 02:32 PM, John Baldwin wrote:
> 
>>> 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.
> 
> Er, that's what I just *said*.
> 
> My point about having to use _ADR in place of _BBN is important
> though, since the code in acpi_pci.c isn't right.  It's meant to
> deal with cases like this:
> 
> Scope(\_SB_) {
>      Device(PCI0) {
>          Name(_HID, 0x030ad041)
>          Name(_UID, 0x0)
>          Name(_BBN, 0x0)
>          Name(_ADR, 0x1)
> ...
>      Device(PCI1) {
>          Name(_HID, 0x030ad041)
>          Name(_UID, 0x1)
>          Name(_BBN, 0x0)
>          Name(_ADR, 0x2)
> 
> Where BBN is clearly wrong on the second bus. (Intel KOA platform
> ASL).
> 
> However, from looking at more ASL I *think* that I came to the
> wrong conclusion about what _ADR is meant to mean here.  The
> strict interpretation of _ADR can only be made in the scope
> of the device's parent, but that would lead you to expect that
> it would be the same as _UID in this case.
> 
> So is it giving us the PCI config space addresses of the bridges?
> The example above has nodes with _ADR 0, 1, 2 and 3 elsewhere as well...

I think it is giving us the config space address of the bridge on bus
0 which we could then use to read the bus number?  Well, maybe. :(
According to the Shanley PCI book, Host-PCI bridges aren't required to
export their configuration registers in config space but may do it in
I/O or memory mapped I/O space instead.  Perhaps I am misinterpreting it
though:

"With the possible exception of the host/PCI bridge, every PCI function
 must implement PCI configuration space within which its PCI configuration
 registers reside.  The host/PCI bridge could implement these registers,
 in PCI configuration space (this is most often the case), in IO space
 (much too crowded), or in memory space."

(The "With the ... host/PCI bridge," part at the beginning is supposedly
 new in the 2.2 spec, this paragraph is taken from the 4th edition of
 PCI System Architecture page 351.)

>>>> 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.
> 
> You don't appear to get it.  There won't be "an ACPI driver for PCI-ISA
> bridges" because the PCI-ISA bridge is enumerated in PCI space.  There
> *may* be a node for it in the ACPI namespace, but it's not required and
> there's no way to identify it if there is (without probing PCI space
> and then using _ADR to hook it up, which means you might as well just
> have a PCI probe function like we already do).

Well, with the ACPI PCI bus driver for "pci" that we now have, any PCI
device can do an 'acpi_GetHandle()' to see if it is a device that is
enumerated in ACPI or not.  This is how the ACPI PCI-PCI bridge driver
does its probe routine.  You could have an ACPI ISA bus that maintained
similar ivars for its children as well as using ACPI namespace below
itself to enumerate and attach child devices.  You could then have an
ACPI-aware PCI-ISA bridge that allowed the child "isa" device to read
its handle as an ivar as well as an acpi_isab driver for ISA busses that
don't appear in PCI space (like in markm@'s laptop) that also exported
it's handle asn a ivar to its child.  Then you could have three "isa"
drivers:

1) An ACPI ISA driver that uses ACPI to enumerate PnP devices below its
   handle and attach them.
2) A PNPBIOS ISA driver that returns a lower match priority than the
   ACPI ISA driver (so that the ACPI driver is preferred) that only
   probes true if the PnPBIOS is present and uses PnPBIOS to enumerate
   child PnP devices.
3) A generic ISA driver that just attaches child devices instantiated
   via hints.  Note that both 1) and 2) would support hint devices as
   well, but that could be done by 1) and 2) calling methods from 3)
   as a form of inheritance.

This cleanly allows us to get away from things like sabotaging the
PnPBIOS pointer in the ACPI case as a hack to disable the PnPBIOS
code.

-- 

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